I'm doing a fluids mod; who cares this isn't relevant.
A problem I am encountering is that when huge numbers of fluid blocks are updating at the same time; it can massively impact client-server bandwidth AND force the client to constantly re-render huge numbers of blocks.
This is bad, and while I can do things to minimize the total number of block changes and optimize the block renderer, I'm really hoping that there is some way, either client or server side (though ideally server side), to easily mark a chunk to ~not~ be updated in a given tick. Essentially; while the server updates the chunk internally once every tick; the client may only be alerted to changes on every 5th tick (rather than every tick).
Note that the situations in which we get enough block updates to cause problems; the player is highly unlikely to be doing anything that could suffer from not updating the chunks; such as tearing a hole in the ocean and watching thousands of water blocks fall out of the world.
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Hmm probably noobish/obvious, but I take it you already know about RenderWorldEvent - "Fired when 16x16x16 chunk area is being redrawn". That's client side only though obviously and I imagine it's not easy to cancel such a thing.
Couldn't find anything about a "Chunk Update event", again I'm sure you spent a long time already looking for such a thing xD
Mmm, the problem is that whether I should render/send the chunk again or not really depends on the server, and while I could send this data to the client and so on with nbt, then try to have force the client to skip the rendering things in the aforementioned event (or w/e), it doesn't solve the problem of spamming the server bandwidth by sending the blocks in the first place (as in; so long as the water goes where it needs to be then there isn't a problem).
I'm just hoping there is a really simple approach to doing this that someone with more Forge experience can direct me towards. My alternative is some really nasty code to override most of the vanilla system and handle it all myself.
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Fair enough. Aborting on client side makes no sense yeah, the client has no idea if the chunk update is important or not - only the server (where you're doing your work from) would yeah.
Maybe it'd be worthwhile to ask on the Forge forums. Since they've done their own work on that parallel chunk loading stuff, hopefully a dev notices and can point you in the right direction.
Either way, I dig into the code and there seems to be no such event for such a thing. Then again I couldn't even find the specific code that handles the chunk update queue so *shrugs*
I'll stop trying to help with things that are clearly beyond me now Good luck though!
lol @ TE's for fluids. Quick estimate says that I sometimes have up to 1 million fluid active fluid blocks . Using TE's would not be a good idea
But w/e, I'm starting to think that simply not marking the blocks is where I'll end up at. It's just a pain, since I'll probably have to implement something to ensure that the blocks do get updated eventually (where not marking them in say, every 2nd tick, would not work well if the block doesn't get changed again at a good time).
I'll have a play with it, but I am concerned about the complexity of ensuring that the update does actually occur eventually. I'd much rather have the option to defer the sending of a chunk until a later time (like what happens with distant chunks, where from about 32 blocks distance chunks update much less often, and after about 64 blocks distance; not at all). I think I could do it pretty easily with core modding, but...
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
I'm doing a fluids mod; who cares this isn't relevant.
A problem I am encountering is that when huge numbers of fluid blocks are updating at the same time; it can massively impact client-server bandwidth AND force the client to constantly re-render huge numbers of blocks.
This is bad, and while I can do things to minimize the total number of block changes and optimize the block renderer, I'm really hoping that there is some way, either client or server side (though ideally server side), to easily mark a chunk to ~not~ be updated in a given tick. Essentially; while the server updates the chunk internally once every tick; the client may only be alerted to changes on every 5th tick (rather than every tick).
Note that the situations in which we get enough block updates to cause problems; the player is highly unlikely to be doing anything that could suffer from not updating the chunks; such as tearing a hole in the ocean and watching thousands of water blocks fall out of the world.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Couldn't find anything about a "Chunk Update event", again I'm sure you spent a long time already looking for such a thing xD
I'm just hoping there is a really simple approach to doing this that someone with more Forge experience can direct me towards. My alternative is some really nasty code to override most of the vanilla system and handle it all myself.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Maybe it'd be worthwhile to ask on the Forge forums. Since they've done their own work on that parallel chunk loading stuff, hopefully a dev notices and can point you in the right direction.
Either way, I dig into the code and there seems to be no such event for such a thing. Then again I couldn't even find the specific code that handles the chunk update queue so *shrugs*
I'll stop trying to help with things that are clearly beyond me now Good luck though!
But w/e, I'm starting to think that simply not marking the blocks is where I'll end up at. It's just a pain, since I'll probably have to implement something to ensure that the blocks do get updated eventually (where not marking them in say, every 2nd tick, would not work well if the block doesn't get changed again at a good time).
I'll have a play with it, but I am concerned about the complexity of ensuring that the update does actually occur eventually. I'd much rather have the option to defer the sending of a chunk until a later time (like what happens with distant chunks, where from about 32 blocks distance chunks update much less often, and after about 64 blocks distance; not at all). I think I could do it pretty easily with core modding, but...
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.