Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
0 
Report this post
My experience with crashes has been due to my older GTX660 card, where puzzles work mostly, but picking up high quality textured items for inspection leads to crashing (like the comic in the same room by the window); though, some thought below that may help or may help devs or others that may respond. - In the early Demo version under Proton (on and old-ish Fedora system) I had some oddness with the doors not unlocking after completing puzzles until interacted with twice, but I don't think a crash at those moments.
Quick thoughts:
If there is a setting/behavior that helps/works then that may help narrow down the type of issue. Interesting that it is the Puzzles (or just interaction with the anchor).
Questions that may help later:
(note: this path is different from the ~/.local/steam/... directory that has all the game data and screenshots etc)
That may be a bunch of questions as a start, so sorry if it's a bit daunting. I feel that if previous puzzles did play out and work and were not very choppy or crashing or having issues that it could be some odd bug. I'm not sure what would distinguish that "Anchor" (set of puzzles) as different than the others other than being the first formal puzzle set. So some of the questions may not fully apply (except in the cases like when I could pickup and inspect some items but not others, or after running around a bit that GPU memory space became an issue and next item would cause a crash; all due to my older card that is below the recommended specifications).
Could try waiting until the audio/subtitles are finished before accessing it (I think that one requires you to do that if you don't access it really quickly (which is probably not intended) but it's been a bit since I played that one. Most "Anchors"/puzzles once entered still continue to play any dialogue started prior to entering them (so may not matter).
If you have any questions or need a clarification due to my wording/question being odd then don't hesitate to ask.
I tried a few of your suggestions. I lowered the graphics switched to Full screen etc. but it seems the bug persists.
7. I then had a look at the Crash folder and found that all my crashes are logged there. I attached the bug report below.
To answer the other questions: I use standard XFCE and my graphics card is a GeForce GTX 950. I am playing the full version. There was no demo version available for Linux.
Yeah, the Comic is one of the tougher ones. For my under-spec card I either run windowed at actual 1024x768 if I want to pickup items, and or without Gnome3 (it eats up a ton of video memory on it's own with the compositor etc) and instead with very minimal mwm from openmotif; fluxbox did not like fullscreen on plain Xorg but I did not play with it much.
Thank you for the clarifications :) I think they may help with tracking this.
As for this crash - It is similar to my past ones on picking up items when VRAM of the card was very low. It ended up as a segfault (SIGSEGV) with the same address, though I think this is an exception that Unreal or the libraries generated. The top bits of the stacks all had similar addresses for my crashes. I'll try to recheck yours against mine. I may paste a few snippets of my notes from a few weeks ago just for comparison.
One other quick question, I think there is another line in another Report file which also pairs with the SIGSEGV and hints at possible memory issues, let me pull up that example....
**1.** Do you have anything like this in your 'CrashContext.runtime-xml' ?
A snippet from my larger scratch notes at pastebin below
Mostly, this is a group of 41 crashes with stacks merged together as an overview. Note: a couple were from when playing the demo on linux with Proton, so there are a few odd-ball ones that had a lower number of occurrences (throwing off the summary a bit).
Not as important unless trying to grok the technical thoughts/output, though it's mostly vague and guesswork without symbols or trying to disassemble and further poking. (The first numbers are counts of the number of times across all 41 that that exact line was seen. The numbers like 13: or 14- 15- are just line numbers (so they are kinda offset frame numbers; 14 would be #0 15#1 and so on); This bit is a bit more technical but wanted to toss in clarifi
cation about what I was looking at at the time.)
The important part is the question above about the xml named file, and the fact that you can use nvidia-smi or nvidia-settings to try and get a very generalized view of the memory usage on the GPU side. It may or may not be correlated with this crash. Though I suspect it might be. Your observations from commands like these on memory usage when playing might be useful to know if it's bordering the edge (though that could also be ok...).[/b] I've n
ot seen anyone else report what I've seen and what you are likely also seeing (VRAM related or otherwise).
This was back in April so I need to dig around and find the past data as it may have rotated; or just to recreate a new crash and provide that for comparison, but your stack also has the top 6 matching the majority of my stacks (if not always for the same crash, I had a few different ones back then during Demo and early Full release) based on my past summary view. As noted below, the first couple are likely just signal/exception handling so might b
e expected to be similar, but a bit further down is likely where things went wrong and also may vary. Maybe the failure to allocate was not handled by the engine/game (or not really possible to handle gracefully regardless).
_____________________________
These are some of the full scratch notes from the end of April
https://pastebin.com/raw/jUm05FZw
They meander a bit and I did not finish poking around and cleaning them up. I had started to accept that this older card/system was not quite enough, so I focused instead on having fun playing the puzzles and reporting other bugs that were more likely to affect all platforms. Though it looks as though this may still be worth a discussion. :)
Thoughts at the moment:
It could also be good to enable the Steam overlay's FPS feature so you can see if you are dropping under 60 or 30 fps at times or on average; just a general idea of card performance, though it is likely similar to mine. (Steam Settings -> In-Game -> In-game fps counter). Though this is less related to the crash/memory issue but may help judge how well the game is doing at various times of odd behavior.
One big thing is that I've not fully updated Fedora 31. It's the latest non-beta but 32 is near. (It was mostly but not fully updated back in April.) When I started testing and seeing the issues I tried not to change anything in case I later was to report and investigate. I'm not sure that the updates to nvidia driver version or other OS side libraries could be in play (the stack does not help too much, though maybe I can enable some verbose output from libraries similar to opengl; bleh. nvidia proprietary).
I'll see if I can come up with anything and may list the driver version details etc. Need to free some space on the OS disk to do updates and time to poke around a bit more.
Hopefully a dev may chime in, but we can try to get attention later if not. (I did not at first as I figured it was just me with my old-gen card; which may still be similar but at least it's multiple instances.)
A snippet from the top of my pastebin so that it's here and more read-able, albeit at the bottom of the comment (adapted slightly; though still rambling since it was just a past uncleaned draft)
Oh right, playing the Demo via Proton (wine/dxvk layers) of Steam Play, the Comic/Magazine at the first window did NOT cause a crash. I was able to read the cipher on that one at the time :) Now I rage against this aging GPU
@toho: Oh - while this may not be all that encouraging, it may be helpful. If you'd like to try and do some of the hidden puzzles that are not environment but are items that you must pick up, there are some Steam Guides that were put together which are Just screenshots of the items (not the solutions). It is worth picking up the Archive cards for achievements and to enter for plot related e-mails (the cards that have peoples name and a password on them that show at the computers). Any of the Wayfar cards are mostly supplemental and add to the Corrupted puzzles, but they usually show ok when viewed at the terminal, sometimes they may crash if you are really low on VRAM (assuming again that that is the correlation). - Just beware that the Guide with screenshots also at the same time exposes/spoils the action/challenge of -finding- the environment puzzles yourself (realizing they are there) but really they are extra things, and the games main puzzles are a lot of fun, and plot details come in the audio and then in password entry of Archive cards which lets you read emails between the characters (not that big of a spoiler just unsure if you've found those or not).
Lastly, if you play with video settings and desktops and find one that the game fails to open on after setting some resolution/setting. Config files are located here as you may have seen when looking for the crash details "~/.config/Epic/Filament/Saved/Config/LinuxNoEditor/"
From my CrashContext.runtime-xml:
There may be some settings for Unreal to allow it to keep more crash report details. The minidump related files I had looked at in the past were all very small but I was not sure if they had been deleted/cleaned up since it was only a while after the crashes that I started looking at them.
I'll give it a bit to see if the devs follow up here with any thoughts. Though they like to use Discord, and the initial rush of players on steam has slowed down with the first batch finishing off most/all puzzles. I don't actually use discord unless I really have to, but that may be the next steps later. Just in case we determine if it's something simple to fix even if due to limited hardware resources. If I do updates and find anything changes in the future I'll be sure to reply back here as well.
something that would be helpful to know; do the crashes also occur if you interact with a terminal? we use a similar trick there to let us do interesting effects on the screen which ideally we don't want to have to rework, but if that also crashes I'll make sure that the same performance changes are added as an option to the terminal
I have no problems with the computer terminal. It never crashed even on high settings.
And I can confirm that the workaround of lowering the graphics settings helps, like Spider reported. But yeah it looks meh then. So it's really awesome that you are working on this. Thanks.
To confirm here, it's the same for me - hadn't happened at the terminals. I can't remember any crash at the Terminal; I'm pretty sure it never did for me. Picking-up/rotating an Archive card can lead to the crash (sometimes ok), but they've always been ok at the Terminal, motivating the recommendation to Toho to still grab them for later. - I've never monitored GPU resources at the Terminal for comparison, actually. Though the old Demo via Proton was sluggish when entering passwords at the Terminal (that was also before I started setting quality settings lower).
That was also my past concern, that two separate scenes and high quality textures may be related; though I figured the Terminal might be done that way too (only slight contradiction in relation, given no crashes). It's possible it's less strain or something else unique to the implementation of non-terminal view. Like the whole level background vs a more narrow view with less/less-varying content when at the terminal walls or smaller rooms. (Though if it's just an item alone, maybe that's not much beyond it's own quality and then scene overhead.) Mostly my random guessing to guide what I might look at/try/observe.
Items/scenarios of crash/non-crash
The below may just be tipping points, and may not help much to describe which items/scenes, but I figured it may give some extra perspective in case it helps.
- The Crow VHS tape can often be picked up without a crash (or just after a crash, before wandering a bunch),
- and books are sometimes ok (I really like their old journal style and textured covers :),
- but the Comic/Zine at the window in the beginning is one that almost always is an issue for me (I'm not sure if it's ever worked since the Demo under Proton for me). I think it's similar for the crypto message in the cryochamber, though I managed to squeeze that one out to screenshot.
- (The Comic did take a bit to load on same hardware when on Proton in the demo, though I'm not sure it crashed for that action; I did have it crash a few time in the Demo for other things like resolution size/mode change etc, which I took as separate.
- I can't remember if it happened for Canary's card in the Demo(Proton); the Wayfarer card was ok at the time, I think.
The fact that I don't remember Proton crashing for these scenarios (just delay in loading them) had me wondering several different things regarding relation to that fact. I'd need to re-confirm before relying on any meaning from that, as it's been a month, though I definitely was able to rotate the Comic and check it out and read the message(s).Otherwise, at the Terminal -
I don't believe we can rotate (only "zoom") with the mouse while at the terminal, which may not make much of a difference given that most of the time the non-terminal crashes are before the item can make it onto the screen; though, sometimes it can load and be rotated a bit before a crash. (rotation is possible at non-terminal view times that don't lead to a crash on load/interaction.) I mention this just in case I had overlooked a way to rotate the items while at the Terminal, as I've not tried that if that is an option (only used the zoom perspective); and mention it in case that implementation difference could be related. Flipping through Archive cards at the terminal is no issue, though occasionally input stutter/lost on a key press that I may be pressing to flip the card too soon in an animation (while trying to quickly rotate through them). During the Demo in Proton the terminal was one other place it was a bit sluggish to respond to my input of passwords (this was before I was setting resolution and settings to low etc), as might be expected.
General thoughts / testing
While it sounds as though it may be non-windows specific, if it would be useful for perspective, I'm not sure it's needed but I may be able to:
- Test again with Proton+Demo - I believe I still have an old copy of the Demo files, or can trick it and run Full Windows binaries via Proton if testing any of that would be useful. (Mostly to confirm if Comic and other items cause crashes.
- Later test on Windows (Full game) and the same gpu but newer cpu for comparison;
As for my testing with a newer GPU, that may be a bit messier.- Other cards I have laying around are mostly Quadros or misc older amd/nvidia ones. (I don't think anyone wants to try to see a Matrox card attempt this as it would not get very far. haha
- A close friend that could run Filament has a much newer gpu, but mostly runs all games in a Windows VM with passthrough, unsure if testing outside that confinement (or the time to do so) is an option. I'd be calling for a favor; and hassle of any time to gather data.
Mostly it's likely about the borderline scenario and not so much the higher end cards (even if they would see the same resource use and just not be impacted), I'd guess; unless it's always directly tied to bordering the 2gb vram limitations. (Maybe too many variables changing except for a test with the same card on Windows etc.) I only think of testing different scenarios just from my outside perspective to help with narrowing things down any, and since I can likely do some technical footwork/profiling.If any other questions come up or if testing with the same GPU on a Windows system or if it's thought that testing any other scenario (or on Windows as I may be able to make that happen), then feel free to let me know. I'm not sure how soon some scenarios can be done but I can make that effort. The 'day' job and some family things have slowed me down a bit, though if I find anything else of use in the mean time then I'll update again.
I have a bunch of vktrace layer data and some vram pool resource usage statistics (and various frame/stack-frame dumps with addresses that likely no longer match the latest version) from a fully updated Fedora (but not very latest upstream nvidia binaries) two weeks ago or more before I went MIA, that I can use in comparison.
Unfortunately we had a serious family emergency which we're still coping with, but the urgency is mostly past at this point
Typically I would trigger the VK_ERROR_OUT_OF_{POOL,DEVICE}_MEMORY part way through some activity during a vkAllocate{DescriptorSets,Memory}(), where most pools were full and not too fragmented; and indeed the device was out of memory; usually needing a new pool around that same time. With device_local memory pool type's 7 holding the majority, and is what we were seeing in the past for the crash report. -- In my cases I'd trigger it by picking up the Comic in the first room/anchor window area, wandering the map/floor, accessing one Terminal, then returning to pick-up the Comic; where at times an alt-tab was needed to trigger the results when the 'pause' menu would come up while still holding the Comic. All done with a very minimal mwm xinit session and some remote gdb and a few other tracing tools (remote at times). Though as noted in the past it could be triggered just picking up items etc.
As non-important side comments
I'll be sure to follow up (at least some time in the future) with if it helps with my original hardware configuration, and if i find anything noteworthy when comparing the latest version details to the older one; just for the sake of documenting it for later reference. Thank you again.