SynaGl0w

Members
  • Content count

    24
  • Joined

  • Last visited

Posts posted by SynaGl0w


  1. 4 hours ago, JimBearUSA said:

    The REALLY need to hire someone who understand proper communication.

    For a great example of how to do communication really well, look no further than the Factorio devs. They always post detailed patch notes, take feedback seriously, respond to bug reports quickly, and keep the community in the loop on what's going on. I especially like that when they post patch notes they often link the forum post where the bug or issue was reported and discussed.


  2. Heh... Seen that in a number of games, especially funny when it happens in skyrim. Usually it's related to a mess-up with a mesh's skeleton (often related to physics) where one of the bones gets stuck or pulled really far away for some reason.

    Still not as bad as a failing graphics card I had back in 2007:

    graphics_corruption_crysis_01.thumb.jpg.dc558fc4fab01868bcf67f54307092ba.jpg

    Needless to say, corrupted vertex buffers are very noticeable. Problem was fixed on replacing the card.


  3. This is why I back up save files often and manually of course (%USERPROFILE%\AppData\Local\Astro\Saved\SaveGames). This game's save system is really annoying, as you cannot manually save to a different file and can only rename it in place.

    In most other games that I can, I save between multiple files incrementally, so if something happens like a bug, crash, or save corruption, I can easily restore. But either way manual save backup is good to do. The other option they don't offer is to to quit without saving. Now the fact it saves when you enter a seat on a vehicle has been helpful, since you can reload to back when you entered the vehicle. This has help me many times recover from those types of bugs.


  4. That's odd, the ones I knocked free were gone when I reloaded the game. Maybe it depends on how (re)embedded or spazzy they are when the save occurs. Still beyond annoying. I spent as little time as possible on the surface of this planet. Activated all the gateways as quick as possible then left.


  5. Like this?

    I have reached the point in my current save where it generally performs like garbage, which is why I had process properties open. CPU never goes above 20% use max, RAM use never went above 6.4GB, IO (hdd, etc.) was almost nothing since I am still playing with the sound system disabled... GPU use was less than 20% and so low that it sits around idle temps. For those curious, my system is a hexa-core running at 4.1GHz, 64GB of RAM, and 2x GTX 1080 Tis. None of which is being very well utilized in this case...

    So what must be causing all this waiting? Waiting... too much threadlock/synchronization? Thats a lot of threads dedicated to a "TetherNetworkSingleton" "Update" method... I have actually removed most of my tethers from large networks and isolated as much as possible with their own oxygenators.

    Still it seems late in the game performance is far worse, and like you mentioned it seems to vary per planet. My worse experience so far has been Novus and Glacio. Glacio was okay very early game, but now... I don't want to go back. I remember way back in early access, by the time I would get to my third planet, performance would get bad enough that I had to stop. Thankfully my saves perform better for much longer now.

     

    So about the vehicles sinking with the drill running... does it happen more often when the ground seems sticky? Like when you run around on foot and the ground seems to lock you in place like this?

     


  6. So I did a test on a new game. A new game does perform better than the same new game loading from a save. Remember this is only monitoring that one sound bank. I have noticed the stutter not related that one sound bank, but obviously others (again, -nosound, completely removes any of this stutter for me, so other stutter must still be from sound system IO).

    A single stutter event involving this specific external sound bank, Popper.bnk, includes 1,964 system calls. Many of those calls are buffered reads in 65535 byte blocks. For each block of 1,964 calls there is a single call to QueryOpen, this is how I can easily count the number of stutters and how many times the bank is reloaded. The average time those 1,964 calls takes is usually about 20ms on my system, but occasionally goes as high as 90ms.

    Here is the basic setup:
    1. A fresh new game from the main menu.
    2. No terrain deformation at all, other than what the habitat and landing pad do for a flat spot.
    3. I run one specific direction away from the spawn until I suffocate and respawn at the habitat.
    4. I save and exit out of the game then relaunch the game, load, do #3 again, repeat...

    A new game:
    - 6 stutters/reloads (11,784 calls)
    First load of save:
    - 11 stutters/reloads (21,604 calls)
    Second load of save:
    - 12 stutters/reloads (23,568 calls)
    Third load of save:
    - 20 stutters/reloads (39,280 calls)
    Fourth load of save:
    - 23 stutters/reloads (45,172 calls)
    Fifth load of save:
    - 18 stutters/reloads (35,352 calls)
    After this point it would average around 15 to 25 stutters each time...

    Another thing to note is that it becomes easy to find boundaries that trigger this reload of sound banks. There appeared to be two axes right near the habitat in this test game. If I ran in a tight circle over one of these boundaries, a stutter/reload would happen each time I crossed that boundary in one direction.

    Constantly reloading the same soundbank over and over is a waste, load it once and be done. Also 65535 byte buffered reads... seems like a small buffer for something that should be completely loaded into memory one time and in one go, unless it's purpose is streaming, like you do for music. So yeah all my stuttering is caused by sound system IO.

    I can only imagine how many of these sound banks are being reloaded internally, not just this one...


  7. Never said it would help you. Just commenting on the fact that so many are taking flight due to what appears buggy terrain collision, while at the same time it's sad that this game lacks an actual jetpack.

    Just yesterday I watched someone streaming where they got launched through many layers of terrain then died. I died 4 times in my own base in just a short span, getting launched to about cloud level for one of 'em. I am also sick of picking up items off my own corpse. Wish there was a "take all" recovery option, or in your case "recover last corpse" option on the trade platform.


  8. I noticed this as well, but it's not consistent for me and seems to only be that platform type you have selected. Basically if I select that platform type and let the ghost of it sit there, it flickers to the same angle in your screenshot continuously. If I hit print at the exact moment it is at that angle it prints at that angle. It seems to happen to all off my medium printers with that platform type selected.


  9. Solved! sort of... Launch the game with the -nosound argument (disables sound system in UE4 executables). Wow it runs great now. No more continuous stuttering. Butter smooth now, sometimes there might be a one-off hiccup when first loading stuff, but otherwise excellent. Might be nice to get sound back, but I would rather play with no sound than constant stuttering.

    I have plenty of other games and projects that use Wwise audio system, but none have this kind of problem that I know of (all games generally run great except GTAV which also stutters continuously while moving, but ran flawlessly before some big update back in 2015, never looked into it though).

    I should also mention that there are occasionally other requests for other Wwise .bnk files at that same non-existent path, but they seem to occur only once or vary rarely, unlike the constant spam for Popper.bnk.

    No idea what is at fault, Wwise or something being done to it via UE4.


  10. So I got more curious... I decided to give it the file it was looking for. So I pulled a Popper.bnk out of Astro-WindowsNoEditor.pak. It is in Content/WwiseAudio/Windows/ dir (no English(US) directory) and placed it at Content/WwiseAudio/Windows/English(US)/.

    Started up the game and no change, still the same stutter. However something seems to like that file... a lot. This is from a single stutter while moving:

    single_stutter_event.thumb.png.4d7aceee86a37595765f39ec94516616.png

    WTF!? Why bumrape that specific file so much? Look at all those calls!

    The time required for all those calls adds up...

    Here is a CSV of a single stutter: astro_stutter.csv 

    Those timestamps. Despite that one missing file the stutter must be going on somewhere. I wonder if it's doing all those same/similar calls to the same file inside Astro-WindowsNoEditor.pak


  11. For quite a while now I have been experiencing a constant stuttering whenever moving around in the world. Noticed HDD activity light was in sync with the stutter. So I wanted to see what was going on.

    Not sure if these events are the direct cause or just part of the same:

    stutter_events_c.thumb.png.3b746b753e25d09fa88ed26f416f0a88.png
    Every time there is a stutter those two events pop up in a pair. CreateFile and QueryOpen. Both calls trying for the file “Popper.bnk” that does not exist (obviously). Ignore the different drive letters on each event, the path is the same (one is a symbolic link).

    Events:

    High Resolution Date & Time:	2/21/2019 1:51:15.7524011 PM
    Event Class:	File System
    Operation:	CreateFile
    Result:	REPARSE
    Path:	C:\Programs\Steam\steamapps\common\ASTRONEER Early Access\Astro\Content\WwiseAudio\Windows\English(US)\Popper.bnk
    TID:	8748
    Duration:	0.0000146
    Desired Access:	Read Attributes
    Disposition:	Open
    Options:	Open Reparse Point
    Attributes:	n/a
    ShareMode:	Read, Write, Delete
    AllocationSize:	n/a
    OpenResult:	<unknown>
    
    
    High Resolution Date & Time:	2/21/2019 1:51:15.7524402 PM
    Event Class:	File System
    Operation:	QueryOpen
    Result:	PATH NOT FOUND
    Path:	I:\Steam Games\COMMON\ASTRONEER EARLY ACCESS\ASTRO\CONTENT\WWISEAUDIO\WINDOWS\ENGLISH(US)\POPPER.BNK
    TID:	8748
    Duration:	0.0000047

     

    stutter_events.webp