stgatilov

The crash inside idDict access might be race condition. idDict use global string pool without mutex, so two threads cannot access it simultaneously. But the culprit is on the main thread then: frontend thread runs gameplay code which can legally access idDict-s. I will download the dump and see myself what's going on. Maybe we should add assert for threadID inside idDict/idStrPool? Maybe even leave the check enabled in release, so that if such a problem happens, it leads to Error/crash in 100% cases...

It's probably nothing more that goes wrong, and reading wrong memory by itself does not crash often (it is usually valid memory page, and depending on the build its contents can be quite deterministic). It is not the first time where such issues cause crashes on Linux while Windows build seems to work fine. Also, we might have different compile settings: Linux build settings are pretty standard, while Windows ones have e.g. security buffer checks disabled. Even calling conventions are very different between Windows and Linux. Most of C++ worshippers don't look any further than "we get undefined behavior here"

My guess would be: the door generates visual stims that AI can notice the stim has "AIUse" spawnarg which specifies its type, which is 7 = "AIUSE_DOOR" the AI code casts the stim source entity to CFrobDoor, which it is not -> crash Here is the place with non-checking cast: else if (aiUseType == EAIuse_Door) { // grayman #2866 - in the interest of reducing stim processing for closed doors, // add a check here to see if the door is closed. Otherwise, a closed door will // ping every AI w/in its radius (500) but the AI won't shut it down until it // can see the door. A guard not patrolling will receive endless pings unless // we shut it down here. CFrobDoor* door = static_cast<CFrobDoor*>(stimSource); if ( !door->IsOpen() ) { door->DisableStim(ST_VISUAL); // it shouldn't be pinging anyone until it's opened return; } Supposedly, you changed the entity C++ class from door to static entity, but did not remove the "AIUse" spawnarg. Maybe we should add IsType check here and do Error if it is incorrect.

@nbohr1more can provide you debug symbols from the assets SVN repo (for 2.11 release only, not for dev builds). They are zipped inside devel/release directory. I don't have my main PC available right now, can't do it. Then you can run "gdb ./thedarkmod.x64", within gdb execute "add-symbol-file ./thedarkmod.x64.debug", and run the program to reproduce your issue.

1.5 seconds after start is probably the time when script functions are called. Or some other post-spawn activity. Someone can also share LInux debug symbols for 2.11 release (they should be in assets repo somewhere inside devel). This way we can probably see stacktrace. Also keep in mind that the threadname message might be not the error itself, but some issue happening when game tries to throw exception or stop something after the issue has already happened.

This problem most likely happens in all the missions with custom briefing released before 2.10. I don't want to waste so much time and nerves on such a minor issue.

dev16801-10370 is available.

And the same problem applies to every button in the mission start sequence which is more specific than "back": "Objectives" button on default briefing "Start mission" / "Buy Equipment" button on difficulty selection screen "Difficulty" button on shop screen Instead of trying to reproduce the state-switching logic of C++ code, better rename these buttons to something generic like "Next".

That's because this mission overrides mainmenu_briefing.gui and it does exactly that: /*************************************************************************** * * The "Back" Button * **************************************************************************/ windowDef BriefingNewGameButton { rect POS_BRIEFING_MAIN_MENU_BUTTON matcolor 1, 1, 1, 1 background "guis/assets/mainmenu/buttons_start/back" visible 1 } windowDef BriefingNewGameButtonH onAction { set "cmd" "play sound/meta/menu/mnu_select;"; // Switch to the mod menu set "gui::targetmode" MM_STATE_MOD_SELECT; resetTime "MainMenuModeSelect" 0; } } This file was written before The Great Main Menu Refactoring, so it uses explicit state names. The correct modern approach would be to set "gui::targetmode" MM_STATE_BACKWARD, which would cause engine to look what is considered previous in builtin tables, and hopefully move to main menu. Also, this file was written before the change related to start mission / install mission. At that moment, current mission was started from mission selection screen, so this custom gui redirects to that screen instead of just main menu.

I guess footstep sounds are played from within source code. So their volume can only be changed there without information loss. There are already many cvars about that, but a brief glance shows that perhaps they are ignored...

Yeah, it should be renamed so something generic like "Next", because internally all these buttons point "forward" now.

I don't understand what you are talking about. From the point of engine, there is one long sound, and many messages in SRT subtitle. The engine cannot distinguish between messages inside a single sound file. SRT file fully controls how long its subtitles are displayed for. The tdm_subtitles_durationExtensionLimit is merely a sanity limit, to make sure subtitles don't go wild and behave independently. No. I suppose all overlapping messages are displayed at once. Duration is computed from the maximum endtime of all messages.

No... nobody requested it yet. Do you want to make a discussion in Editor's Guild forum?...

The duration for SRT is min(LastMessageEndTime, SoundDuration + tdm_subtitles_durationExtensionLimit)

The subtitle cvars are not for user configuration, they are internal. They would change only if if TDM developer decides that... if player changes that, it would be his problem. Just like very many cvars which are totally not for the user to change. I just committed it in svn rev 10358, so expect it to arrive... I guess I'll publish dev build this weekend. I decided that options always start with minus, while commands always start with letter. That's how parsing can work in well-defined way, regardless of linebreaks. The final syntax is: -durationExtend 0.5 -dx 0.4 Also, for now it only work on inline comments (warning and subtitle removal when applied to SRT).

I still don't like the idea of -x parameter. That would make subtitle decl files linebreak-dependent, i.e. its meaning would change from adding or removing a linebreak. Can you recall any other decl file type that behaves like this?... UPDATE: Although it we forbid commands starting with minus, it can be parsed unambiguously regardless of linebreaks. It's not that -x style is widespread in decl files, but perhaps we can live with it...

The extend parameter for inline subtitles is not implemented yet. Verbosity does not matter. Inline subtitles will be displayed for min(max(c + x, 1), c + 5). Here x = 0.2 by default, or whatever value is set in the extend parameter. Of course all these constants are controlled by cvars, I used their default values for simplicity.

I think it is better to decide on case by case basis.

Made it default.

As far as I see, it uses the bytecode + file indices and line numbers.

These are attempts to show direction to the source of sound. I would be glad if you propose a more understandable but still well implementable different way I set "noevents 1" in tdm_subtitles_common.gui.

You can go to idProgram::Restore, delete "saved_checksum != checksum" check, build the code and try again. But it is quite dangerous. The savefile does not store your scripts, it only stores their hash.

A hotfix release "release211a" is available in tdm_installer. Right now you need to select this version manually. As usual, the savegames are compatible both ways between 2.11 and 2.11a. In fact, the hotfix uses the same executable files, so there is almost no risk of breaking anything. We only fixed a bug with wrong map icons in one def file. Please update your 2.11 installation to this version. It is very unlikely you can meet any issues, but if you do, report them here

Revert scripts to their original state. Script mismatch immediately make savegames incompatible.