PC Developer Discussions: Alpha 17

Developer Discussions: Alpha 17

  • Newly Updated

    Votes: 1 100.0%
  • Check out the newest reveals by Madmole

    Votes: 0 0.0%
  • Over 100 new perk books with set collecting and bonuses

    Votes: 0 0.0%

  • Total voters
    1
Status
Not open for further replies.
It also ruined The Walking Dead for me. It got ridiculous that neither Rick nor Negan wouldn't just KOS each other. Instead...endless blabbing and lots of missing when they did finally decide to shoot. There has to be a limit to calling each other out....lol
Com on man. That's what those shows are all about. Drawing out the drama and milking that for all its worth. So people keep watching it and paying for it. :)

- - - Updated - - -

I get irritated by how rare brass is, there is never enough shell casings so I never have enough, I got gun powder and lead coming out of my ears though.
Man. You got to get your ears checked out. ;)

But really, why not a shotgun? Hm?

 
I think everyone already agrees with that 110% :playful:
Not me. Hate the idea.

- - - Updated - - -

The devs need to make the zombies smart in the sense of choosing targets so that they can make destructive progress and put pressure on defending players but not make them appear like intelligent zombies that are scrutinizing where to place their next best punch. Knowing the prioritized list of targets that a zombie will go through is really information we as players should be oblivious to unless we notice the pattern in game by observing the zombies and not because we looked at the code or read the forums. If the devs are good they will make the zombie behavior appear to have no recognizable pattern and that the zombies seem stupid even though under the hood the zombies "know" exactly which linchpin blocks will undo all your defenses. As good players we shouldn't be trying to learn the coded patterns so we can exploit them in the game.
faatal has to be like a good DM that lies when it suits the gameplay and so must keep ALL die rolls hidden behind the screen and we have to be like good players not trying to peek and second guess each and every DM decision.

Part of me somewhat envies the soul that picks up this game in 2019 or 2020 without ever having read a single forum post or update changelog and just plays it experiencing the game with no clue of how the AI is coded or how the heatmap works, or how SI is governed and just plays by trial and error...
Now that's interesting.

- - - Updated - - -

Sounds like fun!!!!

Are We There Yet? :)
No....

 
Oh, incase you guys didn't know. I'm baaaak. :)

Been helping out with other games. Lots of new stuff dropping on Steam. Both new games and Alpha builds.

Been busy.

 
Last edited by a moderator:
Take your time for AI guys. Make us post "So, who survived first red Moon?" when we get to testing or stable. Excellent job so far. ;)
As we don't know all the tricks and surprises TFP have up there sleeves that sounds like fun!

Make a thread and everyone do a short story on there final moments. Maybe add a kill count with days lived, as I will be going slow and safely my first time.

But once I become the: "Maximum Melee Mincing Machine" then kill count will go up... a bit. :)

 
Can we have so that battery bank be connected with multiple input. i.e. we Generator and Solar Bank both. this way we can use one battery bank to power our lines and use generator at night if battery goes too down ..Also sometime we get poor quality solar cell, hence I need 2-3 solar banks to power on battery to get wiring straight.

 
Question

Not yet. We've talked about growling, circling, sidestepping and such, which might get into A17/18.

Hi, what about the physics of water. will it be possible to run the water over a number of blocks or some other means.

For example to create streams, waterfalls, divert a river .....

 
Hi, what about the physics of water. will it be possible to run the water over a number of blocks or some other means.For example to create streams, waterfalls, divert a river .....
As awesome as that sounds, moving water is a FPS killer. The current computer technology is nearly maxed out, so something new or a simple cheat (the water doesn't move, you have just a few looks to the water block and change the look every so often).

 
As awesome as that sounds, moving water is a FPS killer. The current computer technology is nearly maxed out, so something new or a simple cheat (the water doesn't move, you have just a few looks to the water block and change the look every so often).
Well, this was 2D game and single developer is turning it into 3D it is been a while he is doing this, but he has good water flow in 3D :https://www.youtube.com/watch?v=i_cBjh5FdN0&t=1306s his game is nearly launch. However I agree that it does get resource heavy with water physics, and with other things FP doing it is not possible to have water in next one year. But all Hardware are so good that if done right we can have water in this game.

 
We can't say if that video is doing what is required for 7D2D to work. I mean, is the water in that video just an ever growing mass (like it seems) or is it one giant, limited body of water that covers the landscape and fills stuff?

It's hard to describe, but let me try: The problem is not calculating small amounts of water filling rooms / gaps - a few hundred voxels of water can easily be calculated. It gets problematic when giant bodies of water, with tens of thousands of voxels, get moving. So, lets say you have a huge lake of roughly 200*200*20 tiles - that's still a rather small lake (only 200 times 200 meters and 20 meters deep), but it already has 800.000 voxels. So if you dig a tunnel under that lake and break through to the lake, all those 800.000 voxels need to be calculated for every single tile of water that moves to fill the tunnel. Workarounds, like people argued that natural bodies of water could be unlimited and thus wouldn't need to be calculated, don't really work - because if that lake was unlimited and the tunnel underneath leads to a huge gorge / cave on a lower elevation, you suddenly create a gigantic water body there that has to be calculated.

Sow, think about the size of seas we have in random generated maps at the moment... some of them are like 5000x3000x50 tiles (rough estimation, i think they are even bigger...), so with that size, it would mean that 750 million voxels would need to be calculated every single time one water tile in the bottom of that lake moves... and that's just impossible to do, really...

 
I'd prefer they wait until the c# job system is incorporated into the released version of unity, it's currently only available in the beta build. You can stick the water system away in its own little thread and it should barely impact the frame rate at all. Maybe A18 or A19 is my prediction, assuming they don't head to beta before then.

I'm not usually a fan of using the beta release of anything if I'm doing anything of my own on top of it. I produce enough bugs without having to worry whether the bug in question is mine or theirs. I made an exception in the case of the c# job system, I could either use the job system or try to balance co-routines. Despite an early version of the 2018 beta borking my UI _every_ time I ran the project and the new shader system borking _every_ single shader I had built I'm glad I did. The job system is easier and far better than the old co-routine system, even with the idiosyncrasies and weirdness of its implementation.

 
It's hard to describe, but let me try: The problem is not calculating small amounts of water filling rooms / gaps - a few hundred voxels of water can easily be calculated. It gets problematic when giant bodies of water, with tens of thousands of voxels, get moving. So, lets say you have a huge lake of roughly 200*200*20 tiles - that's still a rather small lake (only 200 times 200 meters and 20 meters deep), but it already has 800.000 voxels. So if you dig a tunnel under that lake and break through to the lake, all those 800.000 voxels need to be calculated for every single tile of water that moves to fill the tunnel. Workarounds, like people argued that natural bodies of water could be unlimited and thus wouldn't need to be calculated, don't really work - because if that lake was unlimited and the tunnel underneath leads to a huge gorge / cave on a lower elevation, you suddenly create a gigantic water body there that has to be calculated.
Not necessarily. Look at the changes that are actually happening. Essentially the top is being drained while the water is flowing out of the bottom, everything in between remains largely unchanged. We only need to know about the blocks that are changing from water to air and vice-versa. If a water block is surrounded by water blocks it's going to remain a water block, we don't need to know which particular water block is moving around inside the body of water so they can essentially remain static, you can treat large sections as a single object. You can save a lot of unnecessary calculation that way.

Storage and retrieval of the data can be done as an octree to save on disk space.

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

 
Last edited by a moderator:
So how do you combine the time investment of 7days and the fear element of PvP? Dead is dead.
...you die and lose your map, your skills, your claim, and your items? You're going to be a lot more cautious about engaging in battle.

If you're ridiculously over powered and can one shot anyone? Well, that will either promote team effort against you, or push for a game design where a bullet will kill you, no matter the gun quality.
True, but its another game from there...

 
Not necessarily. Look at the changes that are actually happening. Essentially the top is being drained while the water is flowing out of the bottom, everything in between remains largely unchanged. We only need to know about the blocks that are changing from water to air and vice-versa. If a water block is surrounded by water blocks it's going to remain a water block, we don't need to know which particular water block is moving around inside the body of water so they can essentially remain static, you can treat large sections as a single object. You can save a lot of unnecessary calculation that way.
Storage and retrieval of the data can be done as an octree to save on disk space.

https://en.wikipedia.org/wiki/Octree
You beat me to it. Just to add to this, you can also assume that all surface blocks are going to change at the same rate and update their appearance only as quantum levels of emptying occur. This emptying calculation would only need to be done whenever a hole is added or removed.

-A

 
i wonder what the criteria is for the bar to move Hmm
Well, it WAS every Sunday. Until people started min/maxing and calculating the bar every. single. time! Oh, wait, that was me.. :D

The good news is TFP and/or Roland are trying to make it as accurate as possible with a pinch of fudge factor. So what you see, is as close an approximation as anyone is prepared to give.

It has slowed down so MY guess of July looks to be fading and the "real" deadline of August is the target date.

 
Can we have so that battery bank be connected with multiple input. i.e. we Generator and Solar Bank both. this way we can use one battery bank to power our lines and use generator at night if battery goes too down ..Also sometime we get poor quality solar cell, hence I need 2-3 solar banks to power on battery to get wiring straight.
This +1

 
Status
Not open for further replies.
Back
Top