Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. Hello Guest!
    Welcome to the Bug Report forum, please make sure you search for your problem before posting here. If you post a duplicate (that you post the same issue while other people have already done that before) you will be given a warning point which can eventually lead into account limitations !

    Here you can find a guide on how to post a good bug report thread.
    Space Engineers version --- Medieval Engineers version
  2. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

[1.186.101] Run out of memory

Discussion in 'Bug Reports' started by silenceko, Feb 11, 2018.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. silenceko Trainee Engineer

    Messages:
    5
    Hi guys,

    I wanted to report, that I run out of memory for the first time. DX Diag reports a problem with Space Engineers. But I don't know how to solve this - if this problem is on my side.

     
  2. silenceko Trainee Engineer

    Messages:
    5
    I was able to reproduce this failure.

    1. started new game, easy start earth, creative
    2. placed 3 rocket- und 2 chaingunturrets to defend against the incoming drones
    3. at the silicon deposit, I build up a drillset of 9 large drills, connected to an advanced roter and piston, so they can dig into the earth.

    Time : Action : RAM
    16:35 : Eay Start, setup mining drills, placed 3 rocket and 2 chaingunturrets against the piratedrones : 5200 MB
    16:45 : activating drills : 5280 MB
    16:56 : game running in background : 7100 MB
    17:03 : game running in background : 7500 MB
    17:19 : game running in background : 8000 MB
    17:25 : quit game, closing Space Engineers, reload Space Engineers and load map : 5100 MB

    So, without any interaction, just running the game in background, the RAM gets more and more full. And, the reload of the game points out, that 3 GB of RAM are not used correctly, after nearly one hour of vanilla gameplay.
    Could it be, that the RAM for debris (from mining or drones / dogs) is not released again?
     
  3. Nova_Hawk Trainee Engineer

    Messages:
    9
    I have a similar issue relating to what others have coined as a "Memory leak".

    I use a large page file on my SSD to accommodate for the lack of RAM which seems to help but, there is always a limitation.

    It seems the issue you have and my issues, which turn into a "Filename too long" error seem to be stemmed from Voxel editing. Any altered terrain requires a hefty update to the world and game files which puts increased load on the system.

    I assume you run with mods, if so, would you mind listing them out?
     
  4. silenceko Trainee Engineer

    Messages:
    5
    I run my test without mods.
    I took the terrain deformation into account and it seems you were right. Without terrain deformation the RAM usage was not rising.

    But where is the difference in loading a map with already deformed terrain and deforming the terrain while playing? I assume, the deformation itself is saved in the RAM as a kind of change value. After reloading the map this value is not existing and will be recreated with new deformations. If this is the case, a transformation of the cange value into the "loaded one" is the key. But how should this be done while playing?

    I have 32GB of RAM, enough to play (and change the terrain) a while. But systems with lower RAM have a certain problem.
     
  5. Nova_Hawk Trainee Engineer

    Messages:
    9
    Exactly, the changes result in current runnings of the game. A test would be to push the game to it's high ram or stutter point (for me it's 12gb of RAM) then close the game, not the world/session, but the game. I have found (at least in prior versions) the game itself records and saves the deformation data even after exiting the world (confirmed via Process hacker and TaskMan). Upon loading a new world will add onto your RAM usage, at least, used to.

    Close out of the game entirely and, like you said, the RAM usage reverts to normal standards, however . . . If you refer to your %appdata% folder and go to your space engineers location, saves and then open the folder which houses whichever game you mined/deformed the voxel, you'll see the filename go from a filename closely resembling "EarthLike-1779144428d120000.vx2" to "EarthLike-1779144428d120000-3868533696819502467-3868533696819502467-3868533696819502467-3868533696819502467-3868533696819502467-3868533696819502467.vx2" (replace Earthlike with whatever planet you are currently mining on)

    This, in turn, will cause an error that resembles a "Memory issue" as what is portrayed via error message on your screen, however, when you check your log files, you may see near the bottom a "FileNameTooBig" which is a result of SE renaming the planet file to account for voxel dimension changes.

    >Why data isn't placed into the file ITSELF and not the name is beyond me. Rant over.<

    So far, renaming said file and altering the SANDBOX_0_0_0_0_ file to adjust to the new filename results in a planet being deleted. Which, for me, left my gigantic underground base floating in the void of emptiness.

    So, to bring a Tl;Dr to the post, don't alter your map TOO much or you may end up with no planet at all. I have adjusted my Win10 registry to accommodate for filenames larger than windows normally allows but since haven't altered my terrain, instead altering the base so I won't have to dig as much.

    My Steam profile is listed in my Keen profile, feel free to add me if you want to troubleshoot more personally.
     
  6. silenceko Trainee Engineer

    Messages:
    5
    Underground Base, this is the key! ^^ At the moment, it is more a giant hole covered with armor ^^

    But, if the deformation is changed in the filename, it should be easy to pass this information into the savefile. And it should be possible to save this change in order to free up memory. For example, one could define chunks of terrain, which will be saved only. This should reduce long loading times while playing, so that the "new loading of terrain" could be done after playerdeath or something like that. Maybe this could work on DS too, where this saving is done seperately for each player. Desyncs should not happen, because the terraininformations are still the same, just stored at different places, like it actual is.

    In my game, I am playing with the "modular encounters collection". This is the reason why I dig in. And what is the sense of deformationable planetsurfaces if you can not dig in, but make a small hole to get ressources out :?
    So, I feel that a solution by Keen is needed. I can not imagine, we both are the only ones who dig in ^^ ;)
     
  7. Nova_Hawk Trainee Engineer

    Messages:
    9
    Well, I haven't had much time to test if the filename limit has been worked around through the Win registry, if it does, I will let you know.

    Until then, I have a somewhat workaround. Download the VCZ Multifloor elevator http://steamcommunity.com/sharedfiles/filedetails/?id=1154898843

    As per instructions; Place bottom, then speed module (I recommend 3ms unless you have a really deep base), filler and then top it.

    Where the elevator TOP is, make that your base entrance and make it above ground. Do not edit any voxels. Take elevator from top to bottom, you'll clip right through the ground without issue. This will allow you to make an entire base underground, seal/wall it off and not have to edit a single voxel.

    I suggest walling off the elevator to avoid the obvious "you can see through the planet" phenomenon. Otherwise, works like a charm aside from one thing, rotors.

    Rotors do not (so far I can see) work when placed completely underground. Not sure if this is the rotor base or rotor head causing issues. I suspect the head and in which, some crafty work with a merge block could solve this issue.

    I can also upload my world to a private workshop if you want to use my base as a reference for design ideas. Let me know and will do it first thing in the AM when I'm off work.

    If yes, you should know; you'll need a few mods to get you the basic idea. Not including the decorative mods ( you can adjust and add/remove pipes and cables through various other authors mods). These will ensure there isn't holes in the sides of the pathways.

    Pistons Mod Pack: http://steamcommunity.com/sharedfiles/filedetails/?id=566142426
    UOH | Catwalk: http://steamcommunity.com/sharedfiles/filedetails/?id=1247723388
    Azimuth Complete Mega Mod Pack: http://steamcommunity.com/sharedfiles/filedetails/?id=472832143
    Larger Airtight Hangar Door(s): http://steamcommunity.com/sharedfiles/filedetails/?id=418515207
    Stairwell: http://steamcommunity.com/sharedfiles/filedetails/?id=649590538
    Conveyor Air Vent: http://steamcommunity.com/sharedfiles/filedetails/?id=410678202
    Passage Intersections: http://steamcommunity.com/sharedfiles/filedetails/?id=946724937
    Interior Wall Corners: http://steamcommunity.com/sharedfiles/filedetails/?id=402836950
    And the VCZ Elevator linked above

    My entire collection: http://steamcommunity.com/sharedfiles/filedetails/?id=367344570

    Cheers
     
    Last edited: Feb 14, 2018
Thread Status:
This last post in this thread was made more than 31 days old.