Minecraft Forums

Quote from Keybounce»

What do you mean "old games"? That's exactly what you can do in Minecraft now.

yes, but i meant like in old shooters it was a method of getting an enemy that otherwise would be meant to get you before you could see him.
to me, minecraft isn't a shooter and i actually didn't know the renderer handled it that way, because i just never had any reason to care for it.
anyway, would it mean a complete rewrite or just a small change in the render projection method to get circular render?
and about circular chunk calculation: on old machines, even a chunk calculation reduction of only 4 chunks can make the difference between 30fps and 10fps.

Quote from Martititi»

Hey people. =)
It's been again a long time. What's happened by now?
I read 4HeadTiger got pumps working?

I guess it means you're working again on the mod?

(By the way, any other news from the other mods you talked about in the
past (Sun, Moon and Minecraftia positions relative to the time...)?

Quote from 4HeadTiger»

Near and far should both be circular. Circular means less updates - significantly fewer chunks in the far volume - and also means that the near radius aligns with the redrawing prioritization. There's no advantage to a square update region, other than alignment with random ticks, which doesn't matter since I need a custom random ticker anyway.

If there is an active mod that uses ASM to hook the vanilla interaction, well, it will be fine in the old code, but not in the new code, and I'm not going out of my way this far to support the ASM hacks of other mods.

This is why we have APIs and reflection. Take Glenn's Gases for example. Should I bend over backwards to support his ASM hacks, or should I just use his API (or reflection) to make his gases with my own code?

i just remember old games where the drawingdistance was limited and to make it look better, they added fog, but if you wanted to view just 2-3 meter through that drawdistance (eg see that sniper through the fog) you just had to turn you view until he was at the corner of your screen and you could see him again.
everything that uses the player as center should be with a radius and not square.

Quote from 4HeadTiger»

I've also thought about this one. Each block can (currently) has an
integer number of fluid values, and it wouldn't be hard to add up when
fluid is taken and made within certain systems.

The only problem
is, if evaporation is required for rain, then the frequency of rain
will be proportional to the amount of exposed fluid. A dry biome like a
Mesa, next to a river or an ocean, will get lots of rain. A wet biome
like a jungle, without any nearby rivers and few nearby lakes, could get
very little rain.

The other problem is, water being where it
shouldn't. Evaporation helps, but it might be tricky to have it avoid
emptying things like lakes. Making grass drink water is another way
(i.e, tall grass and flowers occasionally die, which clears space on top
of grass blocks, which can drink water to make more tall grass). Throw
in a few special blocks to suck water up (such as a "stormwater drain")
to help the player keep their base and paths clear, and it might be
okay. I still want to finish other core water mechanics first before I
write this into the new code (might need a lot of fiddling, a couple of
new blocks, etc).

as far as i remember, it was muffled a lot, but still did some damage. or maybe they changed that behaviour in 1.7.10.

also i see there seems to be a few timzones between keybounce, 4headtiger and me, so when i get up late and write a reply, i most times have to wait 6 hours for keybounce to reply so you're from somewhere in america? and 4headtiger from australia has the exact same thing with me responding late to his replies. this planet is quite amusing sometimes.

the tnt only does nothing when submerged in water.

otherwise it works just like in vanilla.

currently with only "-Xms512m -Xmx1024m" i had your alpha3 and even shadersmod running alongside with 20-30fps. and no huge lags at all.

i'll try the new values.

also with the min and max values, i saw the same problem occur here, although i remember setting "-Xms1024m -Xmx1024m" worked... but that changed one day.

edit: thanks "-Xms512m -Xmx1024m -XX:NewSize=400m -XX:MaxNewSize=400m -XX:MaxPermSize=250m -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses -XX:MaxHeapFreeRatio=25 -XX:MinHeapFreeRatio=22 -XX:CMSInitiatingOccupancyFraction=80 -XX:-CMSPrecleaningEnabled -XX:SurvivorRatio=3 -XX:TargetSurvivorRatio=80 -XX:SoftRefLRUPolicyMSPerMB=1 -XX:MaxTenuringThreshold=5"

works perfect for me. even on 1.8.8 with newest optifineHD with shaders.

Quote from Keybounce»

For a 3 GB system, I'd suggest starting with this:

-Xms1080m -Xmx2400m -XX:MaxPermSize=250m -XX:+UseConcMarkSweepGC
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
-XX:MaxHeapFreeRatio=25 -XX:MinHeapFreeRatio=22
-XX:CMSInitiatingOccupancyFraction=80 -XX:-CMSPrecleaningEnabled
-XX:NewSize=800m -XX:MaxNewSize=800m -XX:SurvivorRatio=3
-XX:TargetSurvivorRatio=80 -XX:SoftRefLRUPolicyMSPerMB=1
-XX:MaxTenuringThreshold=4 -XX:+PrintTenuringDistribution
-XX:+PrintCommandLineFlags -XX:+PrintHeapAtGC -XX:+PrintGCDetails
-Xloggc:GC.log -XX:+PrintGCDateStamps

Note that this puts all the logging stuff at the end.

with those settings, it can't create the VM.
note that it says 2,93 GB in my system properties using winXPhome.
the OS with some additional services uses about 1GB, so there's ~2GB left for use of MC

the last time it worked i used "-Xms512m -Xmx1024m" and nothing else as parameter.

on a sidenote: was it intentional to disable explosives? TNT can no longer destroy any blocks.

i just had an idea on adding to the world evaporated water counter=iRainCounter:

the counter is raised every amount of water that

-evaporates from a puddle

-evaporates due to heat (fire/lava)

-is consumed by plants or trees

the counter is lowered by every amount of water that

-forms as a rainpuddle

(-is added by a streams-source-block or would that break the streams?)

the chance for the weather to change to rain should be directly proportional to the amount of water on that counter

(i don't know how you divided the wateramounts per block)

put iChanceFactor into the config for finetuning

iRainCounter/iChanceFactor/100== fChanceRain

(i have no idea how often the game checks if the weather should change...)

if(fChanceRain>=0.9) {weathertype==thunderstorm}

as you wanted to make use of the temperature and humidity levels, you could only start the rain there if((1-fChanceRain)>=humidity)

so it only rains in the desert when it will also come to be a thunderstorm. this makes rain rarer in the desert, but also more dangerous.

if a puddle is placed and iRainCounter is set to 0, it should stop raining immediately and no more water blocks should be placed.

implement that into the weather change of the game and have a semirealistic water cycle.

Quote from Keybounce»

Let me guess: You use the default garbage collector. The throughput collector wants to spend the least total time in garbage collection, and is willing to stop the program in order to make this happen.

It is designed for non response-time-critical applications; it works great for web servers.

But every assumption that it makes about memory usage is broken by minecraft.

This is why I recommend the CMS collector.

Rainfall and evaporation are next on my list.

Hmm...

Cold doesn't create water. I'm planning on using humidity and temp to affect evaporation, as well as the humidity to determine how much water is placed during rain.

as a "pro" argument for helping to get this work on my machine:

if we get this to work fluently on my old lady (yes, my machine is a girl named Katyusha ), it works even better on every newer machine.

i'm honestly not a big fan of changing anything about world generation process as it makes old savegames possibly incompatible with chunks created by the mod.

there's no "after generation" as there is constant generation of new chunks and even the engine can't predict where the body of water will end.

(just like i spawned on what first looked to be an island and i was all jolly about having sucha nice little island with hills, trees, mountains and then i found it was just a small arm of the mainland.)

rewriting the generation process to generate all neighbouring chunks of a chunk with water at that chunkborcer would cause a most likely infinite process of chunk generation.

i think it's absolutely sane the way it currently is.

have your rainwater refill/repair the ocean and everything's fine.

where can i get that version with the pressure system in a compiled jar? is it already on the github?

( the √ was meant to represent a "check" mark and i wanted to point out that i appreciate that this feature already is in there. )

well, this was just all that i had to mention.

in general it worked without being wonky.

after long sessions, the game has almost always completely used the 972MB allocated memory and when reaching 99% got swept back to 70% which also causes a short moment ( 0.5 - 1.5 second ) of 0 - 1 FPS. that happened about every 10 seconds by then.

as i ( even with your explanations ) only understand half of those parameters and half of your explanations, i'll go with changing only a few of them.

So just to annoy *sarcasm*, here's my feature wishlist ( take your time developing, i am very patient, but hurry )

i definitely have to fiddle with the config until it fits what my hardware can handle.

i was unlucky in the way that my coastline had so many ravines and created many wonky situations.

water still can flow diagonally, which creates strange situations.

water can seep through dirt/sand/gravel, but only does so after receiving an update, so a small body of still water will not seep/flow until it receives its first update.

some lighting looked odd and caused flickering between lit and unlit areas.

as i only tested in SSP, i can neither confirm nor deny that a server can calculate the unseen chunks faster in the background and then send only the seen chunk updates to the user, but it sounds logical.

as soon as you guys got a testversion for 1.8.x, i'll try it on our family server.

(our world won't be downgraded to 1.7.10 and we don't want to start a completely new world, as we did that way too often already.)

keybounce, can we do a SMP test on your server? i mean, can i join your server and see how well it runs?

okay, didn't know that was part of that biome, as i never happened to see that biome before.

heavy lag occured because the ocean went into a cave, which ended in a ravine, which intersected with 5 cavesystems.

also for no apparant reason, my game only got 512MB allocated memory by default. git to change that to at least 1024 and see how that goes.

tested your jar, keybounce:

-the ocean went into a cave where the ocean ground was broken, but it did not slow down the overall game.

that was like 5 chunks from the spawn and the game did slow down at all.

-runs mostly smooth, except for when flying around and creating new chunks, but that's also a problem in vanilla.

after flying around in an area about 50x50 chunks, when flying over the open ocean, it couldn't keep up with creating the chunks in front of me.

-ATG "mossy rocks" and the podzol were created, although i have nothing besides forge and your jar in my current installation of minecraft.

so you must have accidently added some parts of ATG into your jar that change world generation.

it's not a big deal (yet ) i'll see how farming and other base features of the game work with your jar.

edit: so, it couldn't keep up creating the new chunks for me. and when i wanted to exit it, it kept staying in "shutting down internal server". i eventually had to force cancel the javaw.exe process.

@keybounce: don't hold back a sneeze, it can cause brain arteries to break and is very dangerous. great video, that's exactly how i test such mods.

also i see the rivers now look very natural with the two mods. (streams and ATG)

is there a compiled version available for testing?

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.

as for destroying worlds:

as long as a mod doesnt need a new world created, i just make a copy of any current world and ruin that copy.

If it needs a new world, well then "Fear me, as I am Armok, Destroyer of Worlds!" http://dwarffortresswiki.org/index.php/Armok

Just imagine how that genuine, potentially almost infinte world with people, animals and monsters living in it just vanishes to never being created again, just so you go ahead and create yet another world, which will most likely share the same fate in a few day-night-cycles.

features that need to be tested:

- rainwater -> flooding everything over time or is it balanced

- do farms work with this and is it arbitrary or a PITA

- does diagonally flowing water flow through a corner of a wall?

- can water be pushed upwards by piston?

- what can be used to keep certain areas from flooding? what can be used as a sewergrate to my sewer channels?

Quote from 4HeadTiger»

@Pvt Private: The hardest part of this mod isn't making an efficient fluid algorithm, but making one that works with Minecraft's engine, which is simply not designed for a mod like this. Notwithstanding that DF's engine is completely different; the game is closed source, so I couldn't copy it even if I wanted to (well, everything can be reverse engineered, there's just no way I'm digging through that much machine code).

Also, pressure is only about vertical flow, at least in this mod. Other implementations might handle it differently. More to the point; I can make it work, I've just been trying too hard to make it as efficient as possible