PC Alpha 19 Dev Diary

Status
Not open for further replies.
I actually enjoy optimizing code. One of my favorite things to do, because sometimes you do find that big win and multiple small gains together do lead to moderate gains.

You often don't know how it will turn out until you do it. That is life.
I see you.

In my profession there are also things that awaken my "investigative curiosity" why some things broke apart, or why it held together for quite some time despite being installed in a "not-so-inspired" way, while other things that were concerted perfectly and should have lasted forever, have worn out pretty fast without no obvious reason. 

Most of the time it amounts to some boring/stupid reasons.

But sometimes you discover the hidden real reason that has the potential to break down a seemingly perfect machinery, and revealing that (and so being able to prevent future failures) is such a satifying thing, hard to find words for!

So no offense meant in my previous post, your work is appeciated much!

I am happy you see it as a satisfying challenge, and not  - as i have assumed/represented - hard work for little benefit

Good hunting! 

10 hours ago, beerfly said:

Nope, we watch these from here 

Oh YEAH really BIG THX to TFP this is exactly the thing I was hoping for!!!

*dancing/jumping naked on the couch while eating a pizza*

 
Last edited by a moderator:
Hi again @faatal .First of all Thx for reading and interacting on this subject. Your help is very welcome. I'm decided to keep on the feedback while I try to painfully test and, after going through the screenshots I noticed something that might help. The time between DECO writes seems to be a minute. If you bring it down to 10 or 15 seconds it should have a bigger overall overhead but WAAAY more stable framerate as there's  four to six times less to write. As the problem is worse when the load is higher (when there are chunks with buildings) the way to go might be to  just increase the writing frequency in smaller batches.

In theory, what I'm suggesting should work and reduce almost any writing-related bumps except the theoretical high time of the worse case scenario (606ms worth of stuff in real time when paused).

In my later test I encountered several 189ms bumbs, so I could say that the 606ms one is a 1% case (it did happen, is just that I paused after, more of that below) I also defragmented as you suggested and it did not do much, but yes, a little bit better, I would say a 5ms improvement on average tops (It's only been 2 weeks since my last one).

As you can see, the 606ms saving one was a big bumb, and it really makes reference to all the DECO handling and stuff happening before the fact,  but because I paused it after due to that pesky Zombie in order to take the screenshot then the feedback might be contaminated. I have more screenshots, no threats and in real time. Each chunk saving is from pausing I guess, but there's a relation between the size, the bumps and the DECO handling.



As you can see in the 3rd screenshot, there's no chunk writing because I didn't pause, but the Warnings hint at the problem and in every screenshot I did get a bumb.

The lightest one being 120ms (last screenshot)  but anything over 70ms after the paused fact is a direct tell of an incremental bump of proportional intensity just before  (lots of DECO being handled at once).

CONCLUSION: Plz, it sounds counterintuitive, but increase the DECO writing (saving?) frequency while spreading the load/unload. There's got to be a point in which if the frequency is too high the performance takes too big of a hit, but if you save DECO, say, each 10-15 seconds, the average fps could get just a small drop in exchange for a smoother experience. That,  plus your recent 19.2 fixes, should do it for a19 performance and beyond.

If it works, the huge 606ms rare drop "tip paused result" should still give away the  big freeze moment, but at 10 seconds DECO handling there would be 6 times less stuff to write so the DECO impact could theoretically be reduced. From there, you can try 5 second DECO saving/ writing and see what happens. 5-second writing could be taxing OR sustainably bearable. I would take the last one any day.

Again, thx and I hope this helps. Edit: Gamesparks and EAC is off in all the tests. The issue happens in ALL game modes.

Edit: I suspect that the DECO handling is heavily microhandled and I do still tend to mistake console notifications for the real thing. The core is right though. You need to micromanage it so it loads/unloads more often and in THE LEAST cuantities possible, resulting in a a more stable experience with not so big of a fps average hit.
I thought the deco writes were 0 as the log says, so it was confusing what was going on, but it turns out the list is cleared before the log happens, so it is writing out, in a 8k world, about 71000 entries, totally over 1 MB. Tried on my HD, but still not horribly slow, then on a flash drive, which gave a 7 second write time! The save timer is every minute, but there is a dirty check, so it does not always do the save.

The deco save code was changed a few months ago by another programmer to fix a problem with old saves, so it might have been only doing partial saves before, but since it does the whole thing now in any event, and on the main thread, it does lead to a large frame spike.

The simple solution was to write it into a memory stream, which is faster than a file stream anyway, then another thread does the actual file save, so minimal frame spike. This probably won't make 19.2, but hopefully 19.3.

Thanks

 
I thought the deco writes were 0 as the log says, so it was confusing what was going on, but it turns out the list is cleared before the log happens, so it is writing out, in a 8k world, about 71000 entries, totally over 1 MB. Tried on my HD, but still not horribly slow, then on a flash drive, which gave a 7 second write time! The save timer is every minute, but there is a dirty check, so it does not always do the save.

The deco save code was changed a few months ago by another programmer to fix a problem with old saves, so it might have been only doing partial saves before, but since it does the whole thing now in any event, and on the main thread, it does lead to a large frame spike.

The simple solution was to write it into a memory stream, which is faster than a file stream anyway, then another thread does the actual file save, so minimal frame spike. This probably won't make 19.2, but hopefully 19.3.

Thanks
Yeah, DECO was saying 0 but I could "feel" otherwise. Output log is quite revealing too because it registers the actual writen entries.

Despite my crazy explanation and boring journalistic feedback, you managed to find a lead, so I'm glad that I could help in the end. I will be testing 19.2 and 19.3 in detail too, hopefully posting feedback with less words this time around. 

 
Will hatches be given the same treatment as doors will in the future? New physics, one stage instead of multiple stages, etc.

Also, will vault hatches and/or fully upgraded iron hatches be nerfed at some point? Using them as a retractable wall has become the new pole wall into terms of a meta defense.

One option could be increasing the amount of damage that zombies deal against hatches by 6x. Just spitballing here, in fact this entire point I brought up is nothing more than a giant spitball.

 
faatal said:
Do you know that this is a team with many different skill sets, like pretty much every game team? Most people on the team can't fix FPS issues, so they do spent their time working on their "stupid" stuff.

FPS issues don't have an "I Win" button you can press to make it all better. It takes lots of time to analyze performance and find bottlenecks, which then often have no easy fix, but to rewrite and retest something, which often results in minimal gains. Features have maximum limits at which they can be optimized to run.

I've actually been spending half my time the last few weeks doing that and cleaning up the project of old/unused files. For example, I found an old unneeded water depth camera, that was rendering nothing each frame. After time spend researching it, removing and testing, I saw a 3% FPS gain. Not much. Path grid updates have also been optimized, which is not something increasing overall FPS, but reduces frame spikes. Terrain shader has been updated for good gains. Tree batching/instancing is being analyzed and tweaked. To get large gains, you have to do that over and over on many systems. Today I started moving many of those improvements to 19.2 for testing, so the next exp will have them.
Thank you very much Faatal, now that you're working optimizing terrain shader please take a look at this thread, there is a massive 40% fps drop from low to med terrain quality setting:




 
Last edited by a moderator:
faatal said:
Do you know that this is a team with many different skill sets, like pretty much every game team? Most people on the team can't fix FPS issues, so they do spent their time working on their "stupid" stuff.

FPS issues don't have an "I Win" button you can press to make it all better. It takes lots of time to analyze performance and find bottlenecks, which then often have no easy fix, but to rewrite and retest something, which often results in minimal gains. Features have maximum limits at which they can be optimized to run.

I've actually been spending half my time the last few weeks doing that and cleaning up the project of old/unused files. For example, I found an old unneeded water depth camera, that was rendering nothing each frame. After time spend researching it, removing and testing, I saw a 3% FPS gain. Not much. Path grid updates have also been optimized, which is not something increasing overall FPS, but reduces frame spikes. Terrain shader has been updated for good gains. Tree batching/instancing is being analyzed and tweaked. To get large gains, you have to do that over and over on many systems. Today I started moving many of those improvements to 19.2 for testing, so the next exp will have them.
@faatal

Thank You for telling us all this. I think it really calms some people (including me :) ) more than just generalized promises.

This is how i always imagined real communication with game developers.

 
Last edited by a moderator:
It would be logical to have this block shape in the current set (corner of block):

EQgGPbf.jpg


 
Last edited by a moderator:
Hello again @faatal . Another a19.1 b8 performance test :

This time around I detected a problem with the AIDirector . AIDirector aka the "wandering horde troll" knows that spawning entities all at once results in a freeze of 5-15 seconds to an already taxed cpu (that hurt). 

The freeze was the hardest I've ever seen. 4 entities at the same second. My 2.7ghz 4C/8T said nope for quite a while there.

Here's the screenshot, check that 19:52:26 timestamp :

20200925195241_1.jpg


I don't know if it's an easy fix. The solution would be to force the AIDirector to spawn each entity every 2 seconds. Ideally each one on readjusted coordinates from each other (to account for entities moving) provided that they still aren't noticed by the player. But the main problem is not the conga line, but the performance hit of simultaneous spawning.

Happens with different POI simultaneous sleeper volumes too. That one you already know  and I'll be testing it further in 19.2 // 19.3

 
Last edited by a moderator:
You should post that in the bug forum. This is the Dev Diary.
Normally I would agree and once the A20 dev diary starts obviously there will be zero tolerance for anyone posting A19 bug reports in the A20 thread. But this A19 thread is a somewhat lame duck thread and Blake and @faatal seem to have a dialogue going that faatal hasn't seen fit to discourage. Obviously we can't have everyone start flooding this thread with bug reports but so far it hasn't really happened and if it does then we will have to enforce that rule. Personally, I have enjoyed reading faatal's solutions to the issues Blake has brought up so until it becomes a problem I am inclined to let it continue until the A19 thread closes or until faatal wants it to stop.

I hope everyone is noticing the pattern of post removal. What stays is predominately direct questions to the developers and direct comments and reactions to what the developers say. As soon as you start commenting on other people's comments then that is a discussion that is tangential to the direct interactions with the developers. So those are what I am shifting over to discussions.

I am not giving infractions for it because it is natural to comment and react to what others post. I am just informing everyone that those posts will get moved out so they do not clog and overwhelm the direct questions that people are hoping the developers will answer. I mean, I am sure people are on the edge of their seat to find out what YOU think about their question but they probably also want to hear from the developer they were asking and sometimes their questions get lost in all the debate and discussion that ensues.

 
@madmole One of my several critiques with the crafting of steroids, and I feel this one is the most important, is that you need to have Intellect at 8/10 and Physician at 3/4 in order to craft them. Once you get a bicycle, steroids are obsolete, so any player wouldn't have any trouble acquiring some mode of transportation long before they reach this point in the Intellect tree, and even if not so, they could use those points to unlock the bicycle and the workbench and still have points left over. Considering that testosterone extract is a key crafting ingredient already - a rare and dangerous resource to collect from its host - and that steroids are, to my knowledge, only useful for so long, perhaps removing any crafting gate would be beneficial. The road is a long and situational one already - I don't see locking them behind a metaphorical steel cage serves any meaningful purpose, if people would craft them anyway. Just my thoughts.

 
Last edited by a moderator:
@madmole i was curious about possible corner blocks rounded like what im using on the top of my horde base, and @MechanicalLensis curious about rounded bars, im interested in those as well, for corners to kinda look better, what do u think?  I have looked but can only find the point ones and they don't look good at all on it.

20200926215416_1.jpg

 
Because I'm an idiot and posted in wrong thread.  This a suggestion of mine.

Not sure if this has been suggested or not, but I think it would be a good idea to add a separate 'blood moon range' option that let's blood moons occur 1-3 days before OR after the 7th day instead of only 1-4 days after. 

This way, you are still keeping the '7 days to die' concept intact while also giving players the option to add more randomness to the game, if they so choose.

Give the player a choice of setting it to 1, 2, or 3 days. (No more than that because then weeks would overlap.)

So for example; 

  1. Setting it to 1 day means a blood moon can happen at any time between day 6 - day 8. The next BM, day 13-15 and so on....
  2. Setting it to 2 days means a blood moon can happen at any time between day 5 - day 9. The next BM, day 12-16.
  3. Setting it to 3 days means a blood moon can happen at any time between day 4 - day 10. The next BM, day 11-17.
3 days also means there's a chance you could have 2 blood moons in a row at any given time. 

This would be a great option to include. 




 
@madmole i was curious about possible corner blocks rounded like what im using on the top of my horde base, and @MechanicalLensis curious about rounded bars, im interested in those as well, for corners to kinda look better, what do u think?  I have looked but can only find the point ones and they don't look good at all on it.
@madmole Phoenixshade35 slightly twisted my words which is fine, I was asking for corner wooden and iron bars, not rounded. :)  It's been something I've been wanting since A17, but hey, if they're not added, it's not something I'll lose my sleep over.

Edit: I'm too exhausted to provide the image at the time of me posting this, however we already have corner railings in the game. Now translate that shape over to bars. :)

 
Last edited by a moderator:
would it be possible to get static books as a block? like at the hospital prefab, find patients notes that we could read.not in a container, but actually lying around. we could then have police reports at the station, military notes about the outbreak, newspapers to help with the narrative? similar to the signs that we can edit, but a smaller block that when clicked on gave a screen the size of a quest accept that we can scroll through or turn the pages on?

 
Since today's theme is added blocks...

I wouldn't mind the ability to craft the noise making trash piles / broken glass we find in POI's as a poor man's 'alarm' for early game.

 
@faatal / @madmole

Hi! Just wanted to ask you devs if you've started working on the bandits' AI or anything related.

There's still confusion in the 7D2D community as to what the current A19 zombie AI is:

1) A prototype for the bandits AI that after bandits are implemented will be dialed back to "dumb" zombies

-OR-

2) The intended AI for zombies and the bandits AI will have its own way of doing things.

Thanks!

 
There is a current exploit that's been around since A18 (possibly earlier) where if you put a mod into a piece of gear like armor, a tool, or a weapon, it increases the sell price of said piece of gear for more than the original sell price of the piece of gear and the mod combined, and by a pretty hefty amount at that. Will this be patched out in A19 or A20+?

 
Status
Not open for further replies.
Back
Top