stgatilov

Yes, I confirm. Looking at changelog, most likely I broke it in "Major refactoring of particle systems (5138)." UPDATE: Broken in svn rev 9011.

I was talking about the moment when you hit quicksave.

Issue: 5515

I can reproduce the issue perfectly from the savegame if I start TDM not from VC. However, I cannot reproduce it from fresh start. So I can try to fix it, but I won't be able to verify that the fix is working (raw object pointer and EntityPtr are represented differently in the save file).

You can download updated save from here. The easiest way to fix the problem is to open game console and execute "remove CBloodMarker_atdm:blood_marker_43". It would remove the blood entity from the game, so it won't be able to cause crash in future.

I think here is what happened: @JBERT hurt the guy named "Mozir" enough to generate a blood spill. (UPDATE: confirmed that this blood spill was Mozir's). When you go down the stairs, "spawnGuards2" script function is called, which removes "Mozir" entity. Something happens to the blood spill (e.g. it gets noticed by someone), and the game crashes on dangling pointer. @JBERT, did this issue blocked you from finishing the mission? Do you need workaround to let you proceed from this save?

@nbohr1more , why don't you downgrade to beta209-02 yourself? I'm uploading all PDB files to google drive. I have reproduced some sort of crash using the provided savegame. I loaded the quicksave before stairs, and went down. Nothing happened. I left the game and went to take shower when I returned, it has already crashed. No idea what happened and how long it took. It happened to me on Windows. Here is the stacktrace: > TheDarkModx64.exe!ai::State::OnVisualStimBlood(idEntity * stimSource, idAI * owner) Line 3575 C++ TheDarkModx64.exe!ai::State::DelayedVisualStim(idEntity * stimSource, idAI * owner) Line 1161 C++ TheDarkModx64.exe!idClass::ProcessEventArgPtr(const idEventDef * ev, __int64 * data) Line 1047 C++ TheDarkModx64.exe!idEvent::ServiceEvents() Line 598 C++ TheDarkModx64.exe!idGameLocal::RunFrame(const usercmd_t * clientCmds, int timestepMs) Line 3392 C++ TheDarkModx64.exe!idSessionLocal::RunGameTic(int timestepMs) Line 3070 C++ [Inline Frame] TheDarkModx64.exe!idSessionLocal::RunGameTics() Line 3112 C++ TheDarkModx64.exe!idSessionLocal::FrontendThreadFunction() Line 3158 C++ [Inline Frame] TheDarkModx64.exe!idSessionLocal::StartFrontendThread::__l2::<lambda_6b7828b12cf509cf76fb3406570c8cd1>::operator()(void *) Line 3252 C++ TheDarkModx64.exe!<lambda_6b7828b12cf509cf76fb3406570c8cd1>::<lambda_invoker_cdecl>(void * x) Line 3254 C++ owner is "watchGuard4" stimSource is "CBloodMarker_atdm:blood_marker_43" When I look at stimSource, its _spilledBy member is pointing to some location, which is apparently deleted. To be honest, I am quite surprise at the amount of game code which uses raw long-living entity pointers without any care that it can be deleted. EntityPtr should be used almost everywhere for this purpose. UPDATE: Yes, reproduced it from the first take. Waited in shadows immediately after the stairs for at most 30 seconds. Same stack trace.

Steps to reproduce (for anyone who have not played): I could not reproduce it in Linux VM. I have a feeling that this "cutscene" about standing guard is not a cinematic... I think one of the following could help (ehm... potentially) Crashdump. You can record it by starting TDM in gdb, and executing some special gdb command when it crashes. See e.g. this. Savegame. It would be helpful if you can also say whether you can reproduce the problem from it by starting fresh TDM and going down the sewers. Since TDM 2.08 was built with this stupid "omit frame pointers", I'm afraid only savegames and crashdumps recorded with 2.09 beta will be helpful.

I don't see anything suspicious in your config. I recall you once said you wanted to retain your config from older versions, which could bring all sorts of nasal monsters... but this file is pretty clean. I did not see anything like flashes while simply running around. Would be great if you post some locations where you experience it most. Sometimes I notice micro-stutters when moving through maps, probably when crossing visportals. We strive for maximum FPS, but often forget that occasional freezes are also very annoying... I'd prefer having -10 FPS but no such stutters.

@joebarnin, could you please post some easy-to-follow instructions how to get to the place where @JBERT has the crash? For the poor devs who don't want to play the whole mission Like the sequence of main locations with getviewpos coordinates...

In the Mother Rose FM it is not a white flash, but instead something like a screen shake. Obviously, for a brief moment screen contents are replaced with some garbage, which can be different. With bisecting, I tracked the problem down to revision 8981. Setting "r_tonemap 0" removes the issue. So it is some trash from FBOs. Aside from that, there is a slight change in the sky while doing quicksave, but I guess it is some old issue. Maybe the same as the one about jittered screenshots with sky.

@wesp5, I assume you use Windows. When you used tdm_update, did it self-update properly?

A weird issue that I noticed only with 32-bit Linux build of tdm_installer. When run from a shared NTFS directory, it thinks that it has only 3.84 GB of free space available. Which is obviously 2^32. I checked the code, and I don't see any 32-bit integers there. And I don't see any reports about filesystem::space not working properly on 32-bit Linux. When I run it from /home, it thinks it has only 2.62 GB of free space available. It can be either the issue with dynamic virtual disk, or something with the fact it is VM. I'm afraid I'll release 32-bit build without changing anything, and see if anyone has the same problem.

Sometimes tdm_installer does not work with spaces: This must be fixed, of course.

It is tracked as 5312 (since 2.07 version). And I'm sure I tried to reproduce it but failed. This is a minor graphical glitch in the overly messy GUIs. That nobody wants to waste time fixing I'm afraid. BTW, it is 4984. I would say our save/load screens have been ill since 2.06 at least with various weird flashes. I have scheduled 5314 about quickloading for 2.10. As for qucksaving... I think the first question is whether it disappears depending on various graphical cvars, like "r_useNewBackend 0".

Simple solution is to run tdm_installer, check "Custom version", then select the latest version you see in beta/2.09 folder, let it install, and then you will have the latest currently available beta version. If you want to know which version you have now, then I guess you are already trying to do something not simple...

Hardly possible. The name is only set in tdm_installer. Right now we bump some constant manually after every official release, so that the game could show 2.08 or 2.09 correctly. I don't see any solution for showing beta build, except for adding another constant for it... in which case I'll most likely occasionally forget to update it, so it won't be very reliable Right now you can open game console and see revision of source code SVN in its bottom-right corner. Then you can go to changelog and see which beta build it is. Or you can start tdm_installer, click "custom version", and go to version selection page. In most cases it should show the name of the version which you installed last in the top field. And there is nothing wrong in updating to the version you already have (except that you'll probably want to save your config).

beta209-04 is available. Changelog is provided in its usual place. Use tdm_installer to get the new version, and don't forget to check "Get custom version".

@MirceaKitsune, please check the referenced GitHub thread. @KCat asks for OpenAL log there...

You need debug symbols in order to see something in a stack trace. We store debug symbols for official releases, but I guess they are not published. If you have built TDM from source, then of course there you have debug symbols, but otherwise you don't. Also, there was a problem that TDM 2.08 was built with "omit frame pointers". As the result, stack trace could not be recorded. It was fixed for 2.09, so if you take 2.09 beta, this won't be a problem. Obviously, this one: 3724 Well, this bug is probably Linux-only (I wonder if it happens on Windows) and only happens if you have non-standard keymap. It needs attention from someone who knows something about Xlib and this "keymap" thing, and I'm not sure there is one.

I have posted comment in OpenAL issue which seems to be the most related to this problem. Sorry for not doing it back in November.

As a matter of fact, TDM still builds well on Elbrus 2000 architecture with svn rev 9083 (which is very close to 2.09 release). Here is how it can be done (requires conan 1.33 or later): ./ThirdParty/: python 1_export_custom.py ./ThirdParty/: conan install . --build -o platform_name=myelbrus ./ : cmake -B build/linux64 -DCMAKE_BUILD_TYPE=Release -DTHIRDPARTY_PLATFORM_OVERRIDE=myelbrus The first command puts the conan recipes which were customized by TDM team into the conan local cache. The second command builds all the conan recipes to get third-party libs artefacts. Notice the "platform_name" argument. The last command builds TDM. Aside from build directory and release configuration, notice the "THIRDPARTY_PLATFORM_OVERRIDE" macro matching "platform_name". The process of building third-party libs for a non-typical platform like e2k is described in /trunk/ThirdParty/readme.md in section "Unsupported platform".

I understand their reaction pretty well. Basically, someone releases TheMegaBrowser with a feature "save stuff in cloud", which saves user's data on Google servers. After some time the browser gets some user base, which use TheMegaBrowser and give that company profit for its ads, but their data is stored on Google servers and Google pays the costs. Judging from the article, Google only wants to block non-Chrome browsers from freely storing data on Google servers.

I could not pick it, and saw a console warning about it. But I could read it just like a typical non-pickable paper. What's the difference between pickable and non-pickable readables?...

I think I have just got into the same problem on Volta 1. The readable_percys_note 1) cannot be picked up, and 2) has some empty pages if I hit "next page" key while reading. And I think once I got the empty page which was stuck like reported here. But I cannot reproduce it from quickload Perhaps @kingsal can confirm whether the two points are intended.