Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[1.12.2] [SOLVED] Multiblock chunk load


Recommended Posts

I currently have a working multiblock with a mixture of ticking and non-ticking TEs.

The main block (heart/master) is a ticking TE with a public method interruptStructure which basically tells it to do a scan of the multiblock.

All the other blocks are non-ticking TEs which when block.onBlockAdded is called, find the nearest reachable heart and call master.interruptStructure. They do something similar for when the block/te is invalidated.

So I've got a way to say hello-block.onBlockAdded and goodbye-te.invalidate

 

This seems to work nicely until someone builds the multiblock over a chunk boundary :(

 

The problems occurs when the player moves away from the multiblock and returns.

When the first chunk loads and it contains the heart, then the heart does an initial scan and fails since some of the multiblock is in the unloaded chunk.

The player moves further forward, the next chunk loads and then the rest of the multiblock is loaded, but cannot say hello because there is no block.onBlockAdded for a chunk load.

 

My solution - which I don't like - is to make them all tickable, then on the first tick of the non-heart blocks, find the master and poke it. All subsequent ticks for that TE are then no-ops.

But of course I've just registered possibly 60 new ticking TEs per multiblock - which doesn't seem right.

 

So does anyone have any suggestions of a way to fix this that doesn't involve making them all ITickable?

 

Possible alternative: Keep track of which chunks have heart TEs and then when a neighbouring chunk loads, use that list to force the heart to rescan.

 

Thanks

Ipsis

Edited by Ipsissimus418
Change title to solved
Link to post
Share on other sites

So TileEntity::validate did the trick.

 

First try it got called on both the server and the client - which created a very impressive stack overflow.

Limiting that to the server - which is where I needed to do it - allowed me to walk to the master.

 

One initial concern was the algorithm I use to walk to the master was travelling over other TEs in the same chunk which had not yet had their validate methods called yet. However as I only use their position to determine the path and never try to access them, I don't think that is an issue.

 

I'm now horribly embarrassed for investigating every other method in block and TE and completely overlooking the "validate" one.

 

Thanks diesieben07

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



  • Recently Browsing

    No registered users viewing this page.

  • Posts

    • oh, ok. So it isn't a forge thing, sorry for taking your time then.
    • This is a core issue in vanilla that has existed since its inception. They way that Items are rendered, is that the edge strip is generated by the CPU, by guessing where the GPU will place the pixels of the forward facing texture. Then the main texture is applied as one quad over top of it. The small white you see is where rounding errors happen and the CPU/GPU are disagreeing. There is no way to fix it beyond building a full model {not cheating like vanilla does and using one quad for the front of the item} This happens in every Minecraft version Modded or not, it varies based on Texture, CPU/GPU combo, and many other things.  
    • I believe this is the log you're asking for, but correct me if i'm wrong. This is from the "latest" txt in the log folder that forge creates after running the jar. Thanks for the help btw!
    • Ok so apparently this bug only seems to happen in 1.16 and up... it's not present in any versions below those specific ones... but apparently, there seems to be an issue with texture stitching in the forge 1.16.4 version 35.1.37, or for that matter any 1.16+ forge version... I have an Intel Iris 1536 MB graphics card and a 2.6 GHz Dual-Core Intel Core i5 processor, and it may need to be updated, an un-updated driver might be the cause of the texture issue, I don't really know, but it seems to be on forge's end more than anything. I'll include an image showing the texture issue if that helps. Also, can someone look into this please? Note: Open the images in a new tab and zoom in ( CMD + on mac, CTRL + on Windows) to see the white lines/gaps in more detail.https://imgur.com/a/INB6g4c
    • Hello everyone!   I'm working on a tree model visualizer object, that can draw a tree dynamically to the screen regardless of how many nodes or subtrees there are. The user can move the display with dragging, and here comes the problem I have. I need every object that is outside of the object to be hidden, like on the advancement screen in vanilla, however, no matter how hard I looked at the vanilla code, I wasn't being able to figure out a way to do this. Right now, my objects are visible outside of the object. That is what I don't want to happen How would I be able to make this happen? Any help is appreciated!
  • Topics

  • Who's Online (See full list)

×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.