Minecraft Forums

Quote from lperkins2»

Hm, updating when no players online (or no players in that dimension) sounds great. What are the odds you could provide a code snippet to point me in the right direction with that? I'll see if I can implement it in RFO2.

RFO2 adds something called an Observer, which is treated in a similar way to players (i.e, updates all chunks near the observer). So one option (probably the best imo) is simply to make a chunk loader and register it as an observer (which you could then place wherever you wanted to perform fluid updates).

The relevant parts of the code should be... the server tick event in the mod's container class (RFOMain or RFOCore or whatever).

Quote from Keybounce»

I hate java.

Quick question: In integer math, what is (-8 / n), where n is much bigger than -8?

Well, up to n=256, it's -1.

At n=512, it's 0.

I have code expecting the rounding to actually *work* at n=(1<<20).

That definitely shouldn't be happening. According to the Java specification, Integer division rounds towards 0.

Therefore (-8 / n ) should be equal to 0 for any |n| > 8.

https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.17.2

You should check the output when doing division in your IDE, and then compare it to the output of the same code running on a website like this (which works as expected for me, i.e -8 / 256 = 0);
http://www.tutorialspoint.com/compile_java_online.php

Re Lava, umm, the viscosity code determines the minimum content of a block before that block can flow. The lava flow rate is slowed down, basically by using modulus to skip block updates (aka, update the block only once every Nth sweep). I don't know why it would be eating performance though... I wonder if lava is spamming lighting updates or something?

Quote from Snipe13051»

---

Quote from lperkins2»

-

I'm reasonably sure that it already does most of the things you say - I remember looking through it, and it was nowhere near as bad as I was expecting, which is why I didn't do custom packets after all.

Blocks are already stored relative to the chunk, the blocks are only 4-5 bytes each, and the only per-block optimization available, would be to reduce the 12+4 bits of ID+meta into a simpler fluid ID + meta (which would be ~3 bytes per block). By ordering the blocks, I could get it slightly lower, to 2 bytes per block, with a 3-4 byte header for each ordered section.

So there are definitely some savings that can be made, in the order of 30-50% depending on how I do it, but equally, bandwidth isn't a serious issue for the mod anymore, so it got pushed down the list a little bit.

@Snipe

Umm... possibly probably. Oil certainly used to do something like that in my older builds, but I thought I fixed it. Can you figure out where the oil is coming from?

Quote from lperkins2»

-

No custom packets. I was going to, but then I got lazy and decided to just use the vanilla updater with some really boring update staging (near chunks update more, far chunks update less). It's mostly the same result as using a custom packet, though I suppose a custom packet could maybe use some hacks and a ZipStream to compress it a tiny bit more.

The main reason for it needing the mod on the client is because I added some other client side stuff (blocks and TE's, also I think I was experimenting with the client side rendering stuffs at one point, etc). It shouldn't be that hard to turn it into a server mod if people think that that would be a good idea though.

The pressure... no idea why it doesn't work. Just to be sure, pressure only works if you are using the rewrite of the mod, and will not work if you are using any of the jars linked in the OP of this thread.
Link: https://bitbucket.org/4HeadTiger/minecraft-finite-fluids-v2.0

The viscosity shouldn't be an issue. Even with just 2-3 blocks worth of head, pressure should travel tens of blocks. That being said, there may be some kind of counting big messing with it somehow...

Umm... probably it needs more debugging

1. Firstly, test if the problem occurs in a superflat world with no other fluids in the surrounding chunks. If it does work in superflat, then it may be an issue with the way pressure is cleared, which I don't know how to fix (someone else might, but I don't).

2. Test the levels of the blocks. Basically, place a redstone torch inside of a fluid block to print the level+pressure+etc to the Java console (NOT chat). With regards to pressure, a block can only flow upwards if it is full, and has pressure > 0 (only full blocks can hold and provide pressure, so it's worth checking all of the blocks involved).

X O X
X O X
X O X X U X
X O O O O X
X X X X X X

X  0 X
X 15 X         <==  25 > 0 [air] , so water should flow out
X 30 X X X 25 X  
X 45 44 43 42 X
X X X X X X X X

Quote from Keybounce»

Alright, modding question: How would I save per-chunk fluid data out in the save file, as well as per-world cache data (or would saving/loading the per-chunk data solve the lack of per-world data)?

ChunkData events. They work sort of like the Chunk load/unload events, but they fire when the chunk is saved or loaded to/from the disk, and they give you an NBT compound which you can put stuff in.

For per-world data, well, it *should* be possible to fit all of the data into the chunks themselves, but if you do need per-world storage, then WorldSavedData is the best way of doing that (just google, there should be lots of threads etc talking about it).

Quote from lperkins2»

How hard would it be to modify such that a reduction in the number of authorized threads causes them to quietly quit early? The deadlock issue seems only to show up on world save, which my server does once every half hour. If I could be assured of the threads going away, or even pausing the water processing entirely for a minute before the save, it would let me ramp the water speed up to near real values.

Not very... Have a look in FluidUpdater#notifyChunkComplete(), that's probably the best place to start.

Quote from lperkins2»

So, if I set it to multithreadded, how long after I set it back to only one worker thread will it take to stop using the other workers?

iirc it should just not restart the threads after they die (they die if there are no updates in the queue, which usually happens at the end of a sweep, but there's a minor issue I've been meaning to address, where it's possible for the next sweep to start before the previous sweep ends [I haven't addressed it yet, since it's part of a larger issue where threads die and are restarted more than necessary])

Will make a note of this. Threading issues are annoying. I haven't seen this happen before - were you testing on integrated client-server or were you running the server in a different instance?

Also not entirely sure where to start (unless I made a mistake, the threads shouldn't acquire new chunks till releasing old chunks... it's possible I messed something up, I think I know roughly where to look. It's also possible that the thread is simply being neglected, so you could try making it use a fair lock just in case).

Quote from lperkins2»

-

Quote from lperkins2»

So, if I understand correctly how RFO2 works, all the 'heavy lifting' is done in com.mcfht.rfo.datastructure.ChunkData?

Give or take, though it may depend a little bit on how you define 'heavy lifting'.

The ChunkData object has a method like; "performAllUpdates()". This method gets called by the worker threads (which are managed by the Fluid Updater and Thread Manager). Inside this method, we find all of the blocks that need to be updated. For each block, we then defer to a method like "doFlow(...)" inside of the class for that block (BlockFiniteFluid), which contains the flow algorithm.

So...

- The flow algorithm is handled in the BlockFiniteFluid instance
- Block updates are flagged and processed through the ChunkData instance
- Relevant chunks are processed by the Fluid Updater (specifically, into queues which are processed by the threads)
- RFO plugs into the Fluid Updater during the Server Tick.

Keep in mind, at some point I might be forced to redo some of the collision and motion stuff. There seem to be some problems syncing the ship between client and server, also vertical collisions are playing up (players bounce/vibrate when ships move vertically).

Re running it in a dev environment, what you have to do is enable coremods. Funny things were happening when I set it up myself, to make it work I had to add this to the VM arguments;

-Dfml.coreMods.load=cuchaz.ships.core.CoreModPlugin

Re carpenters blocks. Wow that looks pretty neat. Makes me wonder about implementing slightly more advanced aerodynamics as well...

You can do anything you want with a coremod, but then it might be incompatible with other mods (and/or other mods would need to know about your custom API, or else they wouldn't work).

Adding to Forge solves that problem - but as you say, contributing to forge might not be the smoothest of processes (I've never actually tried it - but I've read the guide and it doesn't seem thaaat hard. Getting the PR accepted might be another story).

Quote from Keybounce»

How does the rewrite handle liquids that flow at different rates? Eg: Lava is slower than water, concrete would probably have a different flow rate from either.

IIRC flow rate is determined by viscosity, which you define when you create the fluid (basically, how runny the fluid is). [note that I did NOT use realistic viscosity coefficients, you sort of have to guess and check, but there are a few examples which can help with this]