Conversation
Many functionality changes, added a config file for configuring new performance enhancement features. Also added "fix" to the recursive and unnecessary calculations caused by large bodies of water "eg: oceans of any type for instance" and "fixes" the need for infinite water. Oceans now fill infinitely into sea level (y62). Changelog for nerds: Added update per tick limiter Added queue for missed or unprocessed updates Added configuration file for editing these values, defaults are set to a rather high amount at the moment Optimized logic where needed Added bandaid fix for oceans and infinite water
There was a problem hiding this comment.
Isn't there an inbuilt config system in Forge?
There was a problem hiding this comment.
There is I believe, I just made a class cause I didn't know how to use it lol
|
|
||
| // Get the configuration | ||
| ArchimedesFluidsConfig config = ArchimedesFluidsConfig.getInstance(); | ||
| int maxUpdatesPerTick = config.getMaxUpdatesPerTick(); | ||
| int queueCleanInterval = config.getQueueCleanInterval(); | ||
|
|
||
| // Reset the updates processed counter for each tick | ||
| int updatesProcessed = 0; | ||
|
|
||
| // Process updates from the queue, up to the specified limit. | ||
| while (updatesProcessed < maxUpdatesPerTick && !updateQueue.isEmpty()) { | ||
| BlockPos updatePos = updateQueue.poll(); | ||
| // Implement your custom logic here for processing updates from the queue | ||
| updatesProcessed++; | ||
| } | ||
|
|
||
| // Enqueue the current position for future processing only if the queue size is below the configured limit | ||
| if (updateQueue.size() < config.getMaxQueueSize()) { | ||
| updateQueue.offer(pos); | ||
| } else { | ||
| // Optionally, you can log a message or take some action when the queue is full | ||
| // For example, you can skip adding to the queue or remove old entries | ||
| } | ||
|
|
||
| // Optionally clean the queue at regular intervals | ||
| if (queueCleanInterval > 0 && level.getGameTime() % queueCleanInterval == 0) { | ||
| cleanQueue(); // Implement this method based on your queue cleaning logic | ||
| } | ||
| } | ||
|
|
||
| private void cleanQueue() { | ||
| final int MAX_QUEUE_SIZE = ArchimedesFluidsConfig.getInstance().getMaxQueueSize(); // Get the max queue size from the config | ||
|
|
||
| // Limit the size of the queue | ||
| while (updateQueue.size() > MAX_QUEUE_SIZE) { | ||
| updateQueue.poll(); // Remove the oldest elements to maintain the size limit | ||
| } | ||
|
|
||
| // Additional cleaning logic can be added here if needed | ||
| // For example, you might want to remove positions that are no longer relevant for updates | ||
| // This might depend on the specific logic of your fluid dynamics and the state of the world | ||
| } | ||
|
|
There was a problem hiding this comment.
Yes those were for your or any additional editors benefit so the code can be reviewed
The sea level can be changed by data packs or other mods if I'm not mistaken
|
With
do you mean a situation where the water levels are like this: Which causes the surrounding water to flow into the one spot constantly, moving it around. Because if that is the case, would it be better to just check for a situation like that and just not move the water? |
| // Limit the size of the queue | ||
| while (updateQueue.size() > MAX_QUEUE_SIZE) { | ||
| updateQueue.poll(); // Remove the oldest elements to maintain the size limit | ||
| } |
There was a problem hiding this comment.
Is this necessary since the queue can never grow over the max size?
There was a problem hiding this comment.
That was more of a just in case section, and to keep logic from being lost to really old requests. It made more sense to reallocate the oldest requests to make way for newer ones so that the flowing logic didn't have massive amounts of input lag before an interaction (like placing a bucket of water or block) and that it would be less noticable in the offchance the queue max was hit. For instance, if that was not there, and the max queue was hit when placing a water bucket, that update would just be discarded and lead to unintended and frankly, clearly noticable issue by the end user. With that check, the water bucket gets placed as normal and meshes into the other updates which were old enough to probably have been rendered unnecssary anyway.
Alrighty, so. The reason I had that added, was mostly because yes it would flow constantly and never stop. I tried that implementing a check that ran when an update occured. But the amount of extra computation it added for each check (which were specifically designed to be as optimized as possible with as little computation as necessary to allow massive amounts of water to equalize in a reasonable amount of time) it was more feasible to implement it as is |
|
In addition, it was also to "solve" the issue of water availability in survival. Since infinite water sources no longer exist, and are still largely necessary to gameplay, the ocean seemed a suitable fit for allowing "new" water sources to exist by cancelling the transfer decrease to effectively multiply the amount of water to emulate an actual ocean equalizing in surface level. The only issue is it needs better logic to notice when extra blobs of water get caught above that level and don't get equalized. However since they are hard to seperate from intended filling (like from a player) it made it difficult to arrive to a solution that made sense |
|
Is water availability a problem in survival? Oceans already had so much water that it was practically infinite. Could it also be better to have it so that instead of the water level always becoming 8, it instead would be that the water level can increase, but not decrease? |
The reason I had it like that is to speed up the rate of filling like tremendously. If it always becomes 8 that leads to a lot less calculation than introducing more less than source blocks. |
The queue system has been moved from the per block tick function to a per level tick function. The queue system didn't actually do anything previously.
2 participants
Many functionality changes, added a config file for configuring new performance enhancement features. Also added "fix" to the recursive and unnecessary calculations caused by large bodies of water "eg: oceans of any type for instance" and "fixes" the need for infinite water. Oceans now fill infinitely into sea level (y62). As always, feel free to ask questions or make modifications as needed.
Changelog for nerds:
Added update per tick limiter
Added queue for missed or unprocessed updates
Added configuration file for editing these values, defaults are set to a rather high amount at the moment Optimized logic where needed
Added bandaid fix for oceans and infinite water
Added batched updates for fluidpool
Added scheduled queue cleaning