One thing I've noticed is that keybounce's version causes major block lag if there is a massive flood while 4HT's version build posted a page or two back just lowers the framerate a little but yields no block lag.
It's because RFO2 uses a custom packet to send the water block updates, and throttles the number of updates it sends at a time to something reasonable. Adding that sort of thing was a major part of the reason for doing the rewrite.
That makes perfect sense then. Does anyone have benchmark results from running on a server/LAN? I can't find the RAM to my other motherboard so I can't test.
Benchmarks aren't easy for something like this, too much going on to get a good measurement, but I'm running it on a semi-public server and have some instrumentation results from that. RFO1 takes about 1 mbps per connection if you are near a large body of moving water. You can sorta decrease that via the configs, but the configs down't work super well, and if you've got pumps running, they just make it take longer for the traffic to build up. It also significantly impacted server performance (about 20ms/tick worth), even though it runs in its own thread, the post server tick event got slowed way down.
RFO2 takes about 80kbps in the aftermath of setting off a small IC2 nuke in a deep ocean. It throttles itself quite effectively too, so I had a hard time even getting a figure for how much tick time it takes up, less than 1 ms normally. It does load a cpu core pretty heavily if there's water moving, more if you give it more than one thread. The only issue is water moves sluggishly unless you run 3 or more threads, at least on my 3.8 ghz phenom II.
When you say major block lag in my version, what do you mean?
If you are referring to a flood causing massive block update notices to the client, then yea, there's no way to solve that in my version.
If it's anything else, that should be solved as soon as I make time to get another dev round to fix that last water spread bug (water flowing in swamps that runs into vines will crash the game for "safety".)
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
RFO1 is the version Keybounce is maintaining. It was 4HeadTiger's initial version, which he abandoned when he hit some severe technical limits. Keybounce took over and got it into a working state, while 4Head started a rewrite to fix the performance issues.
There is both the unavoidable client lag with large number of block updates, it's mostly fine in SSP or over a LAN, not so good across the internet. I've not checked RFO1's performance in a while, but from 4Head's description, RFO2 uses a slightly more efficient algorithm, and does a much better job queuing updates to avoid post-server-tick-event lag.
RFO1 does have the advantage of being a server-side-only mod, since it doesn't use any custom packets. It also probably has slightly better inter-mod compatibility.
That would make sense, I had players report chats taking forever to show up too. Watch the network usage and you'll probably see it above 1 mbps; the client can't process the data packets fast enough to keep up, the block on the server gets broken almost instantly, but the clients don't find out about it.
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.
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Well, about the picture of you draining the ocean. Although I am very concerned for the safety of those squids (just realized how weird "squid" looks just looking over the letters), I think the more pressing matter is the safety of my pc as it brings those aquatic creature's lives to an end, at least in that fassion. How long would it take to calculate the movement for all that water?
Ah, I stand corrected. It actually would save a massive amount of bandwidth to use an optimized custom packet, galacticraft did it for sealed air and it cut the lag spikes down a bunch. The normal update packet sends the full block position, block type, and metadata for every changed block. The block updates for RFO will either be a Blocks.water or Blocks.air, which saves one integer out of 4. Also, the block position can be sent relative to a reference point, which cuts the size of the x/z coord down from 4 bytes to 1, allowing for 256x256 block updates per packet. Finally, the updates can be sorted by metadata value, which adds a 72 byte header for specifying the total number of each fluid level, and saves 1 byte per block sent. All told, it takes it from 14 bytes per block to a header + 3 per block. For 1000 block updates, it saves 13 kb, and cuts the packet size by 79%. Of course, the more updates are happening at once, the larger the bandwidth savings.
Just staging the updates is enough to avoid the serious lag induced by wild updates, but it does cause the client to get a bit out of sync with the server, especially if you have a long view distance. I'll probably see about writing a custom packet for the updater when I get a bit of free time.
I don't think having it server-side only is that big of an advantage, so I wouldn't worry about it.
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?
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Sounds like what I ran into with Streams at one point. Where a Streams block was next to air, a normal water block would spawn (so you could have a vanilla river off of a stream).
Needless to say, that caused problems. It's also why I have the config to have mod water absorb extra water -- think waterfalls in Streams.
(Yes, that means if you are not careful with your rivers off a Stream, it still happens. Should document that.)
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
I am currently using the form by keybounce which is the only version I get to work. But anyway I am wondering if rain is suppose to fill up holes? I drained a little pond and wanted to see if the rain would fill it back in but the water level didn't change or go back up. So I am wonder if blocks above sea level are able to be filled up for is this feature not available?
The SIMPLE rainfall only refills up to "sea level". I don't remember if I do it everywhere, or only where the base ground level is less than 0. EDIT: 0 or lower. So beaches (0) will rain.
Sea level is accurate in the overworld, and "good enough", but not perfect, elsewhere.
Recently realized issue: 1, it will probably try to rain/refill the void in the end, and 2, it will waste time in the nether before realizing it has a roof. Oh, and 3: Your "no seas" mystcraft ages will flood.
NB: The rainfall code is horribly slow. I have time today. Lets see what I can do.
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
Eclipse question: How do I find all references to FluidManager.Delegator? FluidManager is a public class, and Delegator is a public static member. I thought it was "References -> Workspace" (aka command-shift-G), but that only finds the declaration line,
"public static Delegator delegator = new Delegator();"
EDIT: Never mind. Highlight "delegator" first, not "Delegator".
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
One thing I've noticed is that keybounce's version causes major block lag if there is a massive flood while 4HT's version build posted a page or two back just lowers the framerate a little but yields no block lag.
It's because RFO2 uses a custom packet to send the water block updates, and throttles the number of updates it sends at a time to something reasonable. Adding that sort of thing was a major part of the reason for doing the rewrite.
That makes perfect sense then. Does anyone have benchmark results from running on a server/LAN? I can't find the RAM to my other motherboard so I can't test.
Benchmarks aren't easy for something like this, too much going on to get a good measurement, but I'm running it on a semi-public server and have some instrumentation results from that. RFO1 takes about 1 mbps per connection if you are near a large body of moving water. You can sorta decrease that via the configs, but the configs down't work super well, and if you've got pumps running, they just make it take longer for the traffic to build up. It also significantly impacted server performance (about 20ms/tick worth), even though it runs in its own thread, the post server tick event got slowed way down.
RFO2 takes about 80kbps in the aftermath of setting off a small IC2 nuke in a deep ocean. It throttles itself quite effectively too, so I had a hard time even getting a figure for how much tick time it takes up, less than 1 ms normally. It does load a cpu core pretty heavily if there's water moving, more if you give it more than one thread. The only issue is water moves sluggishly unless you run 3 or more threads, at least on my 3.8 ghz phenom II.
Dude...look at the name of the thread you're posting on.
This is a very cool idea. Wish you luck on the development
When you say major block lag in my version, what do you mean?
If you are referring to a flood causing massive block update notices to the client, then yea, there's no way to solve that in my version.
If it's anything else, that should be solved as soon as I make time to get another dev round to fix that last water spread bug (water flowing in swamps that runs into vines will crash the game for "safety".)
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
RFO1 is the version Keybounce is maintaining. It was 4HeadTiger's initial version, which he abandoned when he hit some severe technical limits. Keybounce took over and got it into a working state, while 4Head started a rewrite to fix the performance issues.
There is both the unavoidable client lag with large number of block updates, it's mostly fine in SSP or over a LAN, not so good across the internet. I've not checked RFO1's performance in a while, but from 4Head's description, RFO2 uses a slightly more efficient algorithm, and does a much better job queuing updates to avoid post-server-tick-event lag.
RFO1 does have the advantage of being a server-side-only mod, since it doesn't use any custom packets. It also probably has slightly better inter-mod compatibility.
What I mean by block lag is when I mine any kind of block it takes nearly 5 seconds for it to "pop" into a drop.
That would make sense, I had players report chats taking forever to show up too. Watch the network usage and you'll probably see it above 1 mbps; the client can't process the data packets fast enough to keep up, the block on the server gets broken almost instantly, but the clients don't find out about it.
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.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Well, about the picture of you draining the ocean. Although I am very concerned for the safety of those squids (just realized how weird "squid" looks just looking over the letters), I think the more pressing matter is the safety of my pc as it brings those aquatic creature's lives to an end, at least in that fassion. How long would it take to calculate the movement for all that water?
Ah, I stand corrected. It actually would save a massive amount of bandwidth to use an optimized custom packet, galacticraft did it for sealed air and it cut the lag spikes down a bunch. The normal update packet sends the full block position, block type, and metadata for every changed block. The block updates for RFO will either be a Blocks.water or Blocks.air, which saves one integer out of 4. Also, the block position can be sent relative to a reference point, which cuts the size of the x/z coord down from 4 bytes to 1, allowing for 256x256 block updates per packet. Finally, the updates can be sorted by metadata value, which adds a 72 byte header for specifying the total number of each fluid level, and saves 1 byte per block sent. All told, it takes it from 14 bytes per block to a header + 3 per block. For 1000 block updates, it saves 13 kb, and cuts the packet size by 79%. Of course, the more updates are happening at once, the larger the bandwidth savings.
Just staging the updates is enough to avoid the serious lag induced by wild updates, but it does cause the client to get a bit out of sync with the server, especially if you have a long view distance. I'll probably see about writing a custom packet for the updater when I get a bit of free time.
I don't think having it server-side only is that big of an advantage, so I wouldn't worry about it.
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...
possiblyprobably. 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?I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
If it seemed to happen near a fountain, then it's probably from the default fluid-fluid displacement interaction... probably...
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Sounds like what I ran into with Streams at one point. Where a Streams block was next to air, a normal water block would spawn (so you could have a vanilla river off of a stream).
Needless to say, that caused problems. It's also why I have the config to have mod water absorb extra water -- think waterfalls in Streams.
(Yes, that means if you are not careful with your rivers off a Stream, it still happens. Should document that.)
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
I am currently using the form by keybounce which is the only version I get to work. But anyway I am wondering if rain is suppose to fill up holes? I drained a little pond and wanted to see if the rain would fill it back in but the water level didn't change or go back up. So I am wonder if blocks above sea level are able to be filled up for is this feature not available?
Thanks!
Come over and check out Wulf Hollow Server!
http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/mod-packs/2723091-wulf-hollow-v1-0-1-custom-recipes-friendly-players
Only blocks bellow a certain height will fill with rain.
The SIMPLE rainfall only refills up to "sea level". I don't remember if I do it everywhere, or only where the base ground level is less than 0. EDIT: 0 or lower. So beaches (0) will rain.
Sea level is accurate in the overworld, and "good enough", but not perfect, elsewhere.
Recently realized issue: 1, it will probably try to rain/refill the void in the end, and 2, it will waste time in the nether before realizing it has a roof. Oh, and 3: Your "no seas" mystcraft ages will flood.
NB: The rainfall code is horribly slow. I have time today. Lets see what I can do.
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
Eclipse question: How do I find all references to FluidManager.Delegator? FluidManager is a public class, and Delegator is a public static member. I thought it was "References -> Workspace" (aka command-shift-G), but that only finds the declaration line,
"public static Delegator delegator = new Delegator();"
EDIT: Never mind. Highlight "delegator" first, not "Delegator".
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?