Minecraft Forums

So after a bit more refining, tweaking, etc, I now have a mostly complete flow algorithm. Fluid interactions now use interfaces and are mapped on a block by block basis. There is a separate method allowing you to block/handle the flow into certain blocks, and lots more override-able methods to get block properties and behaviors. Also the entire data structure is interfaced, meaning that it should be a lot easier to follow how everything goes together.

Now I can start trying to fix all the other problems

EDIT: Will also divert some attention and;

- Make a new timestamps mod
- Make a standalone scaffolds mod (mostly this is done, it's just not standalone)
- Make a standalone day extension mod (same as above).

Quote from 4HeadTiger»

Armok... LOL. That is gold.

- No rainwater flooding yet. Will make this a config option.
- Farms as in, plants consuming water? This is something I've wanted to do for a while (also, grass + water = tall grass).
- No diagonal flow, 4 directions is plenty
- Water will probably be movable with pistons (this already worked [mostly] in the old code).
- Trapdoors allow vertical flow, so do fences and iron bars. Horizontal flow is possible, but not implemented (in the new code).

Unrelated, I finally settled on a pressure heuristic. It seems fairly efficient - not quite as fast as I'd have liked, but I couldn't think of a faster way. Regardless, config option will be added.

woohoo i hope you soon give the sign for a new test.

oh and i forgot one: is it multiplayer-compatible?

I'd test it anyway

Quote from Pvt_Pirate»

oh and i forgot one: is it multiplayer-compatible?

Ummm... Well... it works on a server, but eats a lot of bandwidth.

Reducing the bandwidth is on the todo list, but it's a fairly big job, so I've been putting it off lol (need to make everything work properly in SSP first).

I am not engls so I try ok I am Africans so I du my best to talk to you

Quote from Pvt_Pirate»

woohoo i hope you soon give the sign for a new test.

oh and i forgot one: is it multiplayer-compatible?

I'd test it anyway

I've got it running on my server. With the water update speed as low as it goes, it's usable over a 1mbps uplink, barely. If the server's got decent bandwidth, or you're running on a LAN, multiplayer works fine. Make sure to install the mod on the clients too.

Quote from Keybounce»

I suspect that if the block update radius can be significantly larger than the server view radius, it should behave well enough on a server.

So, if server view radius is 10 (and, due to some minecraft bugs, SMP only behaves properly at that value), and update radius could be 14, that should permit enough flow to happen before it gets sent to the client.

(Not tested, obviously)

---

I wonder if it's possible to only set "send to client" if a water block being updated is within N chunks.

Currently, when blocks change, they get flagged (in the old version, they get flagged directly. In the new version, I've got some placeholder methods that just dump them in a queue, which is emptied from the server).

When a block is flagged, it is added to a list, and the chunk is marked as 'needing an update'. When the chunk receives an update (any chunk within the player's view distance that needs an update), this list is emptied and the blocks are put into packets.

It only sends blocks that need to be sent. Furthermore, the packets are not too bad as far as compression goes. The easiest solution, is shaping up to be; using a special system to actually flag the block changes manually at different times.

EDIT: This being said, I might add an optional ASM module to speed up the update system. It seems like it might slow down a LOT when flagging large numbers of updates in the same chunk. Every time it adds an update, it iterates over the list of flagged coordinates to see if this coordinate already exists. As such, adding N updates, means we test the update list N(N-1)/2 times LOL.

And the block updater is fixed a lot better.

- Fluid updates can be given distance-based priorities (not done, still fiddling with scheduling system, currently ALL chunks update within the far radius)
- Block updates/chunk updates can be deferred to later ticks.

Interestingly, this last one doesn't just let server owners control bandwidth more precisely, but also, greatly reduces the work for a number of other systems (the client<=>server does significantly less processing, the TCP controllers handle far less data, the renderers redraw significantly fewer chunks, etc). I still need to tweak it so that you can actually tell it how to stage the updates conveniently from a config file, but this part is comparatively easy.

Now to see if I can't stop the FillBucket event from exploding the game

Yay I interfaced everything else, and removed all the thread safety (I was using a different thread distribution strategy, but something was messed up and rather than writing it again, I decided to interface this part as well, and put a placeholder class that works properly. That being said, while there is a chance of data racing when using more than one thread, I am not sure whether this will actually cause any *problems*).

Pressure works pretty fast, needs minor tweaks, can be completely disabled in config (when the config works, that is). I also figured out how to fix the fluid height levels thing, it turns out: there was a forge feature that could do this all along :D.

Also I finally got around to pushing everything to a public repository. It's still a long way from done, there are some serious bugs here and there, and a few things might change significantly (read: I might replace the entire thread management system and a large part of the update flagging system). But it's hereif anyone wants to look.

https://bitbucket.org/4HeadTiger/minecraft-finite-fluids-v2.0/overview

(if you want to clone or fork the repo at some point, I don't recommend doing so right now mind you, please read the IMPORTANT thing. You need to do a couple of quick steps or it will not compile).

EDIT: Oh, and it turns out one of my crashes that I just couldn't figure out yesterday, was being caused by: water breaking tall grass, flowers, etc, and dropping them as items. Yep. Water pops flower off => server explodes.

Quote from Keybounce»

So, I've been meaning to ask this for a while now. During initialization, you run a dos shell. Why? Can I just delete that, or do windows system need that for something?

Oh yeah, that. It can go.

I noticed it as well a while back lol. I have utterly no idea why I put it there.

Quote from Keybounce»

So forge actually has this wonder:

public final class AsynchronousExecutor<p, t,="" c,="" e="" extends="" throwable=""> {

It has support for synchronous/asynchronous execution. So you could do stuff on a background thread, and pile what needs to be done by the main server thread back to it.

No clue where the docs are, I found it while stepping through the server tick.

Forge has no docs lol. It's just this endless gift that keeps on giving. Just a couple of days ago, I made a class called IFluidUpdater, and the intellisense stuff revealed something in Forge called "IFluid". Curious, I had a look, and what did I find, but a method that lets you control exactly where the surface of a fluid block is. Hence one of the longest standing issues in this mod was solved in 30 seconds.

That being said the async executor is one thing that I did know about. I just don't want to use it - I have more control within my own system (I already send a *lot* of stuff back, it's the only way to avoid crashes without rewriting half of the vanilla engine). If someone wants to make it use the async executors instead, they are free to replace the relevant IThreadManager instances. Provided all the methods work as described by the interfaces, then it should work just fine.

Lol, I think that one is fixed in a different branch, I remember finding a couple of those at some point (IIRC I copy pasted the same thing in a couple of places). Also, bug-fixes like this from the old code probably don't apply anymore. If you check the new repo, you will see that nearly everything has been completely rewritten

Also, the old branch... for some reason, I think it's not up to date with the .jar I actually compiled, and certainly there are inconsistencies between the pressure branches and the master branch (I wrote the pressure branches later, and changeda lot of things in these branches).

Anyway. I just cleaned up a heap more code in the new repo. Added a bit more commenting to a few places as well. Am going to update the OP big time.

EDIT: Now displacement is working as well

Also, one updater thread appears to be ample for SSP most of the time, 2-3 are better when draining oceans though. Because everything is threaded, there is no lagging or stuttering. Also, there don't seem to be any issues when adjacent chunk objects are updated simultaneously with no threadsafety.

So, what effect would sublclassing vanilla's BlockFluid have?

Quote from Keybounce»

Correct; your published jar does not correspond to any single commit, but has stuff from at least three.

(In fairness, I think it's only three, but I haven't spent the time to verify).

¯\(°_o)/¯

Quote from lperkins2»

So, what effect would sublclassing vanilla's BlockFluid have?

Vanilla's BlockFluid... Just to be sure, do you mean net.minecraft.block.BlockLiquid? This is what the current code subclasses, although, I think KB had to subclass BlockLiquidDynamic to prevent an invalid cast exception from some mod or another.