Alpha 18 Dev Diary!!

[beerfly]

Nonsense, beer is nasty

 

*tapping with fingers on the desk*

[n2n1]

We were using perlin worms and generating cave data at runtime. Some of the caves were extensive and we were rendering huge cave networks MOST players didn't even see. (why is my game slow, I'm staring at a flat open desert?) Then to make them interesting, we had to spawn animals or zombies down there, slowing it further and taking away from potentially obvious zombies on the surface. In short, imagine rendering 1.5 x as much stuff as you need to, and use a costly algorithm when generating it for the first time when a player goes into the area. It was making it challenging to keep up with a minibike movement. If we could pregenerate it and cull it 100% and not spawn guys in there until a player was inside, (all easily doable in a static world game, but challenging in a fully destroyable voxel game) then we could probably add them in.

Well, it is clear that this may take time to generate on the fly.

But i can't understand - why the pre-generation, which is now available, has not solved this problem?

In the end, can generate caves as POI and then place them in the world...

[n2n1]

He'll probably get some custom AI and properties so he bull dozes traps and explodes at the right time.

This will allow me to make a mod with stupid zombies instead of those "smart" who are now?

Sounds like a solution to the problem for us...

[Gazz]

You don't need to send the entire mesh as such, just enough data that the client can rebuild it on the other side. That could still be a lot of data but far less than a full mesh.

And for that you have to load enough chunks to cover the area that the POI could potentially cover.

Not doing that is the principle behind all that distant-anything.

[faatal]

Is there any chance of a 17.4 soon? I wanna start a new game but I'm scared of it becoming obsolete immediately.

 

17.4 if released will probably just be bug fixes and misc changes. Currently it should not break your 17.3 game.

 

So far 17.4 has:

 

Fixed SDTD-10072 It is very difficult to harvest pigs.

Added automove console command.

Changed gfx command default permission, so all clients can use.

Fixed SDTD-10122 Virtual memory leak causing client game crashes.

Changed TraderArea command now displays the status of all trader areas.

 

I played a new RWG game on 17.4 for about 3 hours last night. It ran well and memory use seemed stable.

 

There might be a few more graphics settings tweaks. I also have a bug with zombies sometimes not able to hit clients that I hope to have fixed on Monday.

[Damocles]

Especially SSR should be "off-turnable"

 

and dont forget SDTD-6873 : implement zip lines

[madmole]

Well, it is clear that this may take time to generate on the fly.

But i can't understand - why the pre-generation, which is now available, has not solved this problem?

In the end, can generate caves as POI and then place them in the world...

 

As I said, 7 Days has zero occlusion. NONE. Frustrum occlusion is all it has. So you render every polygon and every entity and having caves just adds to the list of problems we already have. We don't have 16k worlds yet, generating them is too slow. So should we put a feature in 2% of the players want and block a feature 50% of the players want? Then there is stability concerns.

 

Anyhow it might come in a future build, but its not in the cards for 18. Until then, Get off your ass and carve your own cave with a pickaxe

[madmole]

This will allow me to make a mod with stupid zombies instead of those "smart" who are now?

Sounds like a solution to the problem for us...

 

God forbid zombies path as well as dogs.

[Damocles]

Generating 16k maps takes me also almost 30 minutes.

Its quite large, and only really needed for large servers.

 

12k is big enough, and more managable.

[Colin248]

17.4 if released will probably just be bug fixes and misc changes. Currently it should not break your 17.3 game.

 

So far 17.4 has:

 

Fixed SDTD-10072 It is very difficult to harvest pigs.

Added automove console command.

Changed gfx command default permission, so all clients can use.

Fixed SDTD-10122 Virtual memory leak causing client game crashes.

Changed TraderArea command now displays the status of all trader areas.

 

I played a new RWG game on 17.4 for about 3 hours last night. It ran well and memory use seemed stable.

 

There might be a few more graphics settings tweaks. I also have a bug with zombies sometimes not able to hit clients that I hope to have fixed on Monday.

 

fingers crossed that 17.4 bring about the healing others fix! i dont mean to rail on this but gawd darn. X3

[The Gronk]

And for that you have to load enough chunks to cover the area that the POI could potentially cover.

Not doing that is the principle behind all that distant-anything.

 

Why have a difference between terrain and a building? None exists conceptually, it's all just a collection of blocks.

 

The server is expected to run slightly better specs than any of the clients. Have the server send a data packet containing the bare essentials required for the client to build the distant mesh, both terrain and buildings at the same time, as the same chunk.

 

This needs to be solved at some point. I've collapsed a building next to my base to make space for the entrance. To say that the sudden disappearance of the original prefab as I'm heading home is immersion breaking is an understatement, it's physically jarring.

[Damocles]

Why have a difference between terrain and a building? None exists conceptually, it's all just a collection of blocks.

 

The server is expected to run slightly better specs than any of the clients. Have the server send a data packet containing the bare essentials required for the client to build the distant mesh, both terrain and buildings at the same time, as the same chunk.

 

This needs to be solved at some point. I've collapsed a building next to my base to make space for the entrance. To say that the sudden disappearance of the original prefab as I'm heading home is immersion breaking is an understatement, it's physically jarring.

 

Its cheaper and easier to generate the distant terrain based on the original hightmap (wich is a simple 2d hightmap at start), than on the actual voxels in the world.

Thats why we dont have natural overhangs generated in 7DtD, as there are in Minecraft.

 

The overhangs are only there when made by a player, or defined by a POI.

[The Gronk]

Its cheaper and easier to generate the distant terrain based on the original hightmap (wich is a simple 2d hightmap at start), than on the actual voxels in the world.

Thats why we dont have natural overhangs generated in 7DtD, as there are in Minecraft.

 

The overhangs are only there when made by a player, or defined by a POI.

 

That's the crux of the problem.

 

Unless you update from the same data as the other systems it's damn near impossible to keep things consistent.

 

This may be a case where ease and speed must be sacrificed to achieve the goal.

[Guest Rassilon]

Nonsense, beer is nasty

 

you, Sir, just made the whole of Germany and Belgium and Czech your enemy!

 

- - - Updated - - -

 

As I said, 7 Days has zero occlusion. NONE. Frustrum occlusion is all it has. So you render every polygon and every entity and having caves just adds to the list of problems we already have. We don't have 16k worlds yet, generating them is too slow. So should we put a feature in 2% of the players want and block a feature 50% of the players want? Then there is stability concerns.

 

Anyhow it might come in a future build, but its not in the cards for 18. Until then, Get off your ass and carve your own cave with a pickaxe

 

very glad to hear that 16k maps are still kinda on the List and i keep fingers crossed for some kind of occlusion system in the future

[Star69]

@Fatal.....nice on the current bug fixes. Can you tell me if the campfires/forges no longer giving heat buff bug is going to be fixed or was that purposely removed?

[n2n1]

As I said, 7 Days has zero occlusion. NONE. Frustrum occlusion is all it has. So you render every polygon and every entity and having caves just adds to the list of problems we already have. We don't have 16k worlds yet, generating them is too slow. So should we put a feature in 2% of the players want and block a feature 50% of the players want? Then there is stability concerns.

 

Anyhow it might come in a future build, but its not in the cards for 18. Until then, Get off your ass and carve your own cave with a pickaxe

OMG!.... that is.... all the distant blocks are first drawn in the frame buffer, and then just closed by nearest? ....no work z-buffer?

ie the entire array of blocks that are in front of the player - drawn on the screen?...

ie, nearest blocks that obstruct the subsequent do not exclude rendering those who follow them?

 

this.... is a enormous loss of performance........

[Mechanimal]

What are the chances you will attempt to implement a better water block for A18? A19? Are any modders, can any modders, try making such a block?(not overhauling world water, just a new block to play with.)

 

I was just randomly thinking about it, then remembered how it worked in Minecraft, forever ago, and that is a voxel world, so...

 

I've heard it is complicated, but does it really have to be? Like what would it take to implement pretty much the same behavior for water as there was in Minecraft years ago? It worked ok enough there, better than in 7DTD, why? I think with most other blocks the resource jump is obvious, having much higher poly counts and textures, but a "block of water" should be simpler geometrically(to start anyway), and the texture generic by comparison too. Maybe try to just get a solid blue square to behave the same as MC water as a test, then tweak it from there.

 

Not just still water either, also rivers with running water, with same/similar behavior as in MC. Maybe look into their code/method for inspiration. Seems like it would be worth another try, just don't attempt an extreme overhaul or anything daunting or risky to start, I can def understand why you'd avoid that. So just leave existing water as-is, make a new block and play with it on it's own until it works, then deal with implementing it into world once the block is ready, that seems like a whole other phase/task anyway, so break it up into more digestible phases. It's just the more I think about it the more I am wondering why not, just keep the mesh/behavior really simple at first, ease into it.

[beHypE]

As I said, 7 Days has zero occlusion. NONE. Frustrum occlusion is all it has. So you render every polygon and every entity and having caves just adds to the list of problems we already have. We don't have 16k worlds yet, generating them is too slow. So should we put a feature in 2% of the players want and block a feature 50% of the players want? Then there is stability concerns.

 

Anyhow it might come in a future build, but its not in the cards for 18. Until then, Get off your ass and carve your own cave with a pickaxe

 

I hope this will make the list. The old caves where you had to do some scaffolding to get to those tunnels or vein ores were amazing times. And with modding possibilities i'm sure the underworld would add endless possibilities.

[Guest Rassilon]

What are the chances you will attempt to implement a better water block for A18? A19? Are any modders, can any modders, try making such a block?(not overhauling world water, just a new block to play with.)

 

I was just randomly thinking about it, then remembered how it worked in Minecraft, forever ago, and that is a voxel world, so...

 

I've heard it is complicated, but does it really have to be? Like what would it take to implement pretty much the same behavior for water as there was in Minecraft years ago? It worked ok enough there, better than in 7DTD, why? I think with most other blocks the resource jump is obvious, having much higher poly counts and textures, but a "block of water" should be simpler geometrically(to start anyway), and the texture generic by comparison too. Maybe try to just get a solid blue square to behave the same as MC water as a test, then tweak it from there.

 

Not just still water either, also rivers with running water, with same/similar behavior as in MC. Maybe look into their code/method for inspiration. Seems like it would be worth another try, just don't attempt an extreme overhaul or anything daunting or risky to start, I can def understand why you'd avoid that. So just leave existing water as-is, make a new block and play with it on it's own until it works, then deal with implementing it into world once the block is ready, that seems like a whole other phase/task anyway, so break it up into more digestible phases. It's just the more I think about it the more I am wondering why not, just keep the mesh/behavior really simple at first, ease into it.

 

Either Gazz or Madmole explained it fairly well a few weeks ago.

Current water is pretty close to minecraft water, exept for the flow part.

This seems to be fairly difficult to code, as calculations of Waterflow to different hights in surrounding Blocks eat a sh*tton of Ressources

 

Water is on their list, but when they will get to it is unknown.

There seem to be several ideas on how to approach this, but each with a lot of drawbacks.

[Mechanimal]

oh... of course I bring up functional water blocks amidst talk of caves... haha, sorry, tis a rather volatile mix, albeit uncomfortably appropriate to consider the two interacting sooner than later. TAKE THAT CPU !!!! mwuahaha.

[Weazelsun]

 

Fixed SDTD-10122 Virtual memory leak causing client game crashes.

 

 

There might be a few more graphics settings tweaks. I also have a bug with zombies sometimes not able to hit clients that I hope to have fixed on Monday.

 

Huh? So, I guess that' why sometimes my game would crash. Though, sometimes would simply crash to main menu. Guess that's fixed, now.

[Mechanimal]

Either Gazz or Madmole explained it fairly well a few weeks ago.

Current water is pretty close to minecraft water, exept for the flow part.

This seems to be fairly difficult to code, as calculations of Waterflow to different hights in surrounding Blocks eat a sh*tton of Ressources

 

Water is on their list, but when they will get to it is unknown.

There seem to be several ideas on how to approach this, but each with a lot of drawbacks.

 

Ah, thanks, figured it popped up before, and have been reading forums, musta just missed that.

[Weazelsun]

There are a lot of npcs coming to 7 days, just not ones you can recruit to do your bidding unless we can make it look convincing and afford the performance setback.

 

Aw... of course. So speaking of bandits and I know this a longs way off. How will they be implemented? Like if I were a new a player that simply skimmed over the description of the game and bought this solely for zombies. How would the bandits be shown as a possible threat? Simply only during quests or will there be a chance of encountering some sort of bandit scout. Since I know for me personally, if I were to be attacked by a bandit that could use melee and do the same the actions as me, I would definitely be caught off-guard.

[Damocles]

Aw... of course. So speaking of bandits and I know this a longs way off. How will they be implemented? Like if I were a new a player that simply skimmed over the description of the game and bought this solely for zombies. How would the bandits be shown as a possible threat? Simply only during quests or will there be a chance of encountering some sort of bandit scout. Since I know for me personally, if I were to be attacked by a bandit that could use melee and do the same the actions as me, I would definitely be caught off-guard.

 

They should be more than just mindless maniacs, that attack out of nowhere.

Somehow warning the player to enter an area "thats our town, our loot".

 

So only attack if the player does not comply, trespasses or attacks them first.

 

Kind of like "roadblocks" to a high yield area, such as city-centers.

 

In the Walking Dead, "Bandits" usually first try to extort people for resources, before actually attacking.

 

My idea would be that they place a kind of dropchest, that the player has to insert a certain amount o resources regularily. If the player does not comply, they start an attack.

[Cernwn]

If we limited stack size to 3 food items per slot, then people wouldn't be taking 50 cornbread and being good to go on a quest. They might actualy make more advanced foods because of limited carry space.

 

If you introduced spoilage where fresh food/meat/eggs spoils (gains food poisoning percentage) at the rate of the stack size it is in, it would entirely solve this issue. That way, if people want their carried food to spoil slower, they will carry smaller stacks and store it in a functional cooler(on a vehicle) or fridge(at their base) when not on them. The larger the stack, the faster it spoils.

 

This actually happens IRL based on gasses released by decaying matter causing decay to spread, and is where the idiom "one bad apple spoils the whole batch" originates. TBH though, for balance sake would also need to add dehydrating, salting/curing/smoking and canning as viable means to preserve foods for longer journeys. Definitely a few new workbenches out of that, and would make salt+sugar valuable resources. However, this would be a major time+resource sink. Some people enjoy immersion, while others do not.