PC Developer Discussions: Alpha 17

[Daggett Beaver]

@Tin:

The main problem is not players transferring water in Buckets, the main problem is players manipulating the landscape around water bodies.

How should the game react when a player digs a tunnel from a 50 tile body of water to a 8x8 tiles hole? Should the game generate 14 additional water tiles so the water can fill that hole? Should the water just disappear because it isn't enough to fill that hole? Should there be 14 tiles of water just missing, forming strange gradients?

One solution would be to make it a bit more like Terraria, where fluids can fill a block partially (like 25%, 50%, 75% and 100% filled), this way the gradients wouldn't look as strange... but i can imagine that this needs a lot of resources in a voxel game.

 

[The Gronk]

So having two different functioning water types wont work?Example:

All terrain generated water sources (lakes/rivers/oceans etc,.) cant be depleted but all prefab and player made water sources can deplete (prefab water sources, player made water holding structures).

If a player "harvest" water from a terrain generated water source to a bucket, it doesn't deplete from that water source (infinite).

If the player wants to transfer that water into a bucket and add to a structure they made to hold it, it gets applied as the depleting type of water source. So, If the player removes water from a prefab/player made source, it depletes.

Just trying to think outside the box type of [sUG].

Somebody, somewhere, for reasons known only to themselves will try to remodel the entire landscape like a post-apocalyptic Capability Brown and complain that the sky-lake is ruining the sight-lines to their gazebo.

https://en.wikipedia.org/wiki/Capability_Brown

 

[Guppycur]

@Kinyajuu: That's welcome news, can't wait for more tidbits.

@faatal: I'm patient. =)

@Roland: um, nothing. Just "hi."

 

[Crater Creator]

On RWG in a17:Random worlds in a17 onward will be fully "pregenerated". This means that the world generator will output the same data structure as navezgane but in a save folder. This means that any rwg world will load just as fast as navezgane going forward.

After fixing the vehicles and adding new ones it was determined that RWG's runtime code was just waaaay too slow. So now it instead gets all the data set up and exports it in a common format which allows for quicker chunk loading.

With the change to pregeneration and using the socket(tile) system over the entire world there will be some other changes as well. For the better. Over the next couple of days I will give a bit more detail on what else these changes to RWG mean for the average player, modders, and server owners. I think most will be very happy.

More to come...

Just thinking through the pros and cons here... Will it take longer when first starting a new RWG world? When people pregenerate the whole map now with visitmap, they report it takes around 30 hours. Obviously it won’t be that bad or you wouldn’t do it. But it’d take a thousand-fold optimization to stay as fast as in A16 where you’re not pregenerating.

 

[Dagzambie]

@Kinyajuu: That's welcome news, can't wait for more tidbits.
@faatal: I'm patient. =)

@Roland: um, nothing. Just "hi".

This is getting awkward...

 

[Guppycur]

Just thinking through the pros and cons here... Will it take longer when first starting a new RWG world? When people pregenerate the whole map now with visitmap, they report it takes around 30 hours. Obviously it won’t be that bad or you wouldn’t do it. But it’d take a thousand-fold optimization to stay as fast as in A16 where you’re not pregenerating.

Yeh I'm a little confused too, since rwg already loads the first time and loads faster subsequent times. The nav bit has me confused too, because it also uses pre-generated .rg files. I'm assuming that the "changes to rwg" tidbits will yield more info.

- - - Updated - - -

This is getting awkward...

Well, instead of looking in from the window, come join us then. Geesh.

 

[The Gronk]

Running the maths as fast as processor can handle it, in other words hyper-optimized, I can see it being far quicker but I'm curious if it can be done in less than 15 minutes. That's a hell of a lot of calculations no matter which way you slice it.

 

[wolfbain5]

@Kinyajuu: That's welcome news, can't wait for more tidbits. sounds appreciative
@faatal: I'm patient. =) <warning> translation, I can wait til you're single

@Roland: um, nothing. Just "hi". that awkward meeting your ex moment

Well, instead of looking in from the window, come join us then. Geesh.

Eep! *Runs to safe place! And GuppyLech has struck again. not even faithful to fataal yet

humor compiled from previous pages

 

[Crater Creator]

We're getting sticky arrows, and I'm really looking forward to them- can this feature work for showing bullet and knife wounds as well?

Not the same feature, I don’t think. Sticky arrows means attaching the arrow model to an arbitrary position on the actor’s surface. Bullet and knife wounds would mean changing the texture (or in severe cases the model) on part of the actor itself. The most you could do with sticky arrow tech is see the knife or bullet lodged in the actor’s body.

 

[Dagzambie]

...


Well, instead of looking in from the window, come join us then. Geesh.

Eep! *Runs to safe place!

 

[Bubo]

We're getting sticky arrows, and I'm really looking forward to them- can this feature work for showing bullet and knife wounds as well?

=)

 

[petruherro]

@kinyajuu or faatal
has the cause of the lag in the buildings in the large cities such as the pharmacutical or the admin buildings been found or fixed yet?

i'm also curious about this

 

[Tin]

@Tin:
The main problem is not players transferring water in Buckets, the main problem is players manipulating the landscape around water bodies.

How should the game react when a player digs a tunnel from a 50 tile body of water to a 8x8 tiles hole? Should the game generate 14 additional water tiles so the water can fill that hole? Should the water just disappear because it isn't enough to fill that hole? Should there be 14 tiles of water just missing, forming strange gradients?

One solution would be to make it a bit more like Terraria, where fluids can fill a block partially (like 25%, 50%, 75% and 100% filled), this way the gradients wouldn't look as strange... but i can imagine that this needs a lot of resources in a voxel game.

Well the bucket of water transfer was an issue in the beginning. When you applied the bucket of water to a block it was a "infinite water source" at that time earlier in development, that players could use to make a water wall to stop zeds from destroying structures. They also used it to destroy other player bases. Which, if I'm not mistaken, was one of the reasons for the water changes to begin with.

Also if a player wants to spend all that time to dig out and landscape from lake/river/ocean then more power to them, now the water will flow into those spaces, again like it was before.

With your solution: That is basically what they are doing now with water, so a water block can empty, which works decent for small water sources.

Since it's not working all that well from large water bodies, causing the "empty water" spaces from not filling back up when the water is taken from it. It just stand to reason to try something else. Maybe a 1 size fits all solution isn't always the correct answer.

 

[Crater Creator]

Yeh I'm a little confused too, since rwg already loads the first time and loads faster subsequent times. The nav bit has me confused too, because it also uses pre-generated .rg files. I'm assuming that the "changes to rwg" tidbits will yield more info.

My understanding (of A16) is the first time you load RWG, it has to generate all the chunks around you. It generates more chunks bit by bit as you move to new areas, and so whenever you log off, you’re in the middle of a bunch of already-generated chunks. So the next time you load, it doesn’t have to generate any new chunks. This is why the teleport command can take so long, if you’re landing in an area that hasn’t been generated before.

Navezgane is (almost) 100% predetermined, so nothing needs generation, and neither would RWG if the seed was pregenerated ahead of time. The unknown part is how long that initial pregeneration step takes. Sorry if I’m explaining the obvious here, but I don’t think I’m confused as much as I am curious.

 

[rdunham3]

Well the bucket of water transfer was an issue in the beginning. When you applied the bucket of water to a block it was a "infinite water source" at that time earlier in development, that players could use to make a water wall to stop zeds from destroying structures. They also used it to destroy other player bases. Which, if I'm not mistaken, was one of the reasons for the water changes to begin with.

Also if a player wants to spend all that time to dig out and landscape from lake/river/ocean then more power to them, now the water will flow into those spaces, again like it was before.

With your solution: That is basically what they are doing now with water, so a water block can empty, which works decent for small water sources.

Since it's not working all that well from large water bodies, causing the "empty water" spaces from not filling back up when the water is taken from it. It just stand to reason to try something else. Maybe a 1 size fits all solution isn't always the correct answer.

A grossly simplistic fix for the zombie-corpse whirlpools would be for the corpse block, on despawn, to see if the four horizontally adjacent blocks are all water and if so replace itself with water instead of air. Since it's a corpse block doing the navel-gazing, and not water blocks looking at each other for some kind of gamey water physics existentialism, it shouldn't cause too much CPU use. Practically none.

 

[The Gronk]

has the cause of the lag in the buildings in the large cities such as the pharmacutical or the admin buildings been found or fixed yet?

The cause is surface area. When generating terrain you essentially only have to deal with a single layer of blocks, no use creating blocks that the player can neither see or interact with yet. Building always have a larger surface area and a larger array of blocks the player can interact with, the larger the building the more system resources it takes to show it. Please bear in mind this has nothing to do with the gfx card, it's pretty much always the processor-ram combo which is struggling.

- - - Updated - - -

We are NOT generating all the chunks.

That makes more sense

 

[dhlmaster]

On RWG in a17:Random worlds in a17 onward will be fully "pregenerated". This means that the world generator will output the same data structure as navezgane but in a save folder. This means that any rwg world will load just as fast as navezgane going forward.

After fixing the vehicles and adding new ones it was determined that RWG's runtime code was just waaaay too slow. So now it instead gets all the data set up and exports it in a common format which allows for quicker chunk loading.

With the change to pregeneration and using the socket(tile) system over the entire world there will be some other changes as well. For the better. Over the next couple of days I will give a bit more detail on what else these changes to RWG mean for the average player, modders, and server owners. I think most will be very happy.

More to come...

This is excellent news! On my server, if I set it to Navezgane, I can run around on a Max quality bike. On random gen, nothing over 300 quality. So if random gen worlds will now be optimized like Navezgane, I will be very happy

 

[Tin]

RWG was pregenned before yes. but in less compacted data causing run time distance calculations for say, road asphault.
Now this is being precalculated and added to an image map that contains the roads. The height part of them is stored in the world height map.

The way the old RWG generated vs the new way is a bit too large of a topic to cover in passive discussion. I put pregenerated in quotes because it's simply outputting the same biome map, terrain map, etc. like navezgane has. Generation takes about as long as it did before but once it's done all will be output to maps for quicker loading. Since so much was done with the data loader for the navezgane format and much more is being done for distant trees and terrain it only made sense to match it up to that.

We are NOT generating all the chunks. That's just not going to be doable for reasons others have already stated, takes too long. But outputting it in the same dtm, biome map, prefabs.xml etc. only stands to gain speed and also gets all the features without me having to do special coding specifically for RWG.

Feel free to think over pros and cons but I'm 100% certain of what I'm doing. Just sit back and relax.

Joking tone-> Pft! But you're just a Kinyajuu, how could you possibly know? It's not like you made it or anything :gossip: layful:

Joking aside. Sweet! can't wait to get my hands on it

 

[art336]

You the man Gazz!
- - - Updated - - -

Yep.

On the road again. Just can't wait to get back on the road again. lol

Shut up dunkey!

 

[Ouch Quit It]

We're getting sticky arrows, and I'm really looking forward to them- can this feature work for showing bullet and knife wounds as well?

Sticky arrows...........lead to SPEARS!!!

Even if we cant pick them back up...a spear in game would be AWESOME..especially since that would be the first thing I would look to build if I didn't have a gun or ammo. To keep the Zeds far away!!!

MTFGA