Stuck on Ladder in Delta Reactor Room

[jyudoki]

Just encountered a game stopping bug in Delta Reactor Room (the one with lost souls). At first I had trouble walking up the initial set of stairs without jumping, with my character getting stuck. Next, when I try to go up the ladder to the next level, I get stuck and cannot proceed no matter what.

I've looked this up and found that it's a random bug that happens with both vanilla and BFG edition. Here's a video of it from someone else:

https://www.youtube.com/watch?v=zrsW5taL88c

Could this be isolated and fixed perhaps? Attached my affected quicksave:

QuickSave.zip

Edit: It appears perhaps on level load all the ladders and stairs are loaded wrong so that it makes traversal difficult/impossible until the level is reloaded.

[HarrievG]

I encountered this same bug too., Not sure it is an engine bug since you show that it even happens on the console port and original released bins. That being said, the loading part about the ladders is interesting. Did you debug this yourself? if you can point to what is in your opinion the offending code, i can take a look. Or if you deduced this from logging, sharing those would also be appreciated.

Edit: Actually, after seeing the whole vid you linked, I am not so sure if this is NOT an engine problem. the load thing is starting to sound very plausible.

@DanielGibson I will chase this and update here.

[HarrievG]

tests to perform:

• [x] Load from supplied save game. so far unable to reproduce from save game in 32bit win debug and release

• [ ] normal load from start of map

• [ ] DevLoad from start of map,

[HarrievG]

ladder_load_relase32.txt Attaching an save game load which is made from the quicksave above, and saved infront of the first ladder encountered

Lots of warnings. Not sure if there are really bad ones.

Made with "+set fs_basepath \"E:\\SteamLibrary\\steamapps\\common\\Doom 3\"", "+set fs_devpath ", "+set r_fullscreen 0", "+set com_allowConsole 1", "+set developer 1"

[HarrievG]

I have done some searching, and it appears that the ladder bug is common, but only in this level. It also seems to be persistent from saves, but i cannot reproduce it with the supplied one.

Would love to get my hands on a save game that persistently reproduces this. For now, i dont think this should hold back the next release.

[DanielGibson]

Did you also test with release binaries? Maybe the bug doesn't happen with (unoptimized) debug binaries.. If it indeed only happens in release mode, you could try CMake's RelWithDebInfo release type

[HarrievG]

Yes , I tried 32 bit release and debug. Could you give a try at reproducing it? Then at least we can be sure the save game is unfortunately not the golden egg we are looking for..

[HarrievG]

Is it also maybe possible for us to try to reproduce it on his exact same build? Can we extract that that info from save game?

[DanielGibson]

I don't think that this is stored in the savegame. But maybe @jyudoki can tell us which build was used, and if the bug is reproducable when loading the savegame, or only happened when originally playing the map and saving.

I'll try to remember to reproduce it, I think I've tried before unsuccessfully, but I don't even remember if I only tried on Linux or also on Windows. (My vacation is over so I don't have as much time for dhewm3 this week)

[jyudoki]

I was using the latest public build. When loading the save game it will always be bugged. However when loading the level from scratch it will be fine. That’s why I suspect the issue is due to the level loading improperly at the very start. Also this seems like a long standing bug on multiple platforms including Xbox and BFG so I’m pretty sure it’s not linked to any specific build.

Thanks for taking the time to look into it.

Cheers

Justin

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Daniel Gibson notifications@github.com Sent: Wednesday, January 20, 2021 11:52:02 AM To: dhewm/dhewm3 dhewm3@noreply.github.com Cc: jyudoki justin.yu84@outlook.com; Mention mention@noreply.github.com Subject: Re: [dhewm/dhewm3] Stuck on Ladder in Delta Reactor Room (#328)

I don't think that this is stored in the savegame. But maybe @jyudokihttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjyudoki&data=04%7C01%7C%7C292ded87f1814157c31408d8bcdd99e7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637467007239968569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WT%2FAQVHJWOy0FJuJfL9sbObc%2F6uDWCP3MWmLgM0SL7I%3D&reserved=0 can tell us which build was used, and if the bug is reproducable when loading the savegame, or only happened when originally playing the map and saving.

I'll try to remember to reproduce it, I think I've tried before unsuccessfully, but I don't even remember if I only tried on Linux or also on Windows. (My vacation is over so I don't have as much time for dhewm3 this week)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdhewm%2Fdhewm3%2Fissues%2F328%23issuecomment-763248034&data=04%7C01%7C%7C292ded87f1814157c31408d8bcdd99e7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637467007239978523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=j30h%2FqG9lBPsRUa%2F9qM1xC3%2BFGBrkGQoToAae0yBgAg%3D&reserved=0, or unsubscribehttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FARW6FSVCPKV5QJYYLFS27DLS2YSLFANCNFSM4TV4QYTQ&data=04%7C01%7C%7C292ded87f1814157c31408d8bcdd99e7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637467007239978523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=q%2F5hxIdYXEwU5VtNTlaKkfs3hcHYl2qeYmbhlqOO0Vk%3D&reserved=0.

[DanielGibson]

I was using the latest public build.

In November the latest public build was 1.5.1 RC2, unless Justin meant the latest proper release (not pre-release) which was 1.5.0 (or used some semi-public build I linked somewhere in a bugreport to test specific fixes).

[HarrievG]

Ok, I will try again with the released builds!

I hope I am able repro it. @jyudoki if you are still encountering it, could you also attach one of your logs here while you have "com_developer 1" set?

-H.

[turol]

I have never actually played Doom3 that far but it appears that the save is very far from any ladders. This makes reproducing and testing under Valgrind hard. Can you make another save which is directly in front of a ladder?

[HarrievG]

Yes, its a bit far, you have to progress the level a bit. 1) You follow the path to the reactor room where you interact with the monitor 2) you backtrack, and a hole in the ground opens up. Enter that hole and exit on the other side of the floor 3) follow the path and you will see a dead guy sitting/leaning on a crate/battery (or something) pick that up. 4) backtrack again to the reactor room and walk to same spot you interacted with monitor, the object will be taken from your inventory and the reactor will start 5) backtrack once more, and this time a monsters appear from that same hole. ( turn on god mode, so you don't die and can just walk past it/kill easily ) 6) enter hole and exit on other side again, a new path is opened here. 7) after taking this new path and doing some fights, a ladder will present it self shortly.

Its pretty linear, and you cant really stray from the designed path. I also haven't finished doom3, but played only the demo content before picking up DHEWM3 for my hobby project.. and now play specific levels just to see/feel how the original developers pulled off different things. I have to say, that this is a very, very nice part to play. if you haven't played it, it worth doing so anyway ;)

I have not tried no-clipping immediately to an ladder, although I think it should be a feasible test run, it is always dangerous to use this type of cheat since you can easily miss trigger volumes that trigger need logic for progression

so yes these are a lot of steps.... and if you (@jyudoki) could make the save game again in front of the first ladder, that would be great. !

Oh, and the output with com_developer 1 might be helpful even if we cant reproduce with your savegame,

[turol]

That's no good... I suspect this is caused by uninitialized memory. Valgrind can easily find these but the problem is that it slows down the game by about 10-50 times. Those steps are completely infeasible under Valgrind.

[DanielGibson]

Ok, something is really broken here - with the "official" 1.5.1 RC2 win32 binaries I can load the linked savegame just fine, and I just gotta walk up some stairs (which already doesn't work as it should and requires jumping), through a corridor, up some other stairs and then I already see the ladder, and when going up that ladder I get stuck.

When I try to load the savegame with newer binaries, I get spawned at the beginning of the level - and then when playing until I actually get to that spot I don't get stuck.

git bisect revealed that the savegame not loading correctly (and sending you back to the beginning of the level instead) is caused by c4c72363523fc65e635c7ad7ae86247b4f082340 - haven't found out why yet. I'm not sure if the getting-stuck-on-the-ladder bug needs to be fixed before the next release (as it apparently has always existed), but the savegame-doesn't-load-correctly bug definitely needs to be fixed - I hope that there's a better solution than reverting the offending commit. UPDATE: On Linux the savegame always sends me back to the beginning of the level, even in 1.5.1_RC2

[HarrievG]

Ok wow.

So. You have been able repro it in 1.5.1 rc2 32b release. That's great news.

But, does this mean, that this is not the same bug as the famous "can't get off ladder bug" ? I would not expect this bug to be caused by an submit in 2020. Or are you saying that that submit, exposes it as returning to start of level?

-Harrie.

On Sun, 24 Jan 2021, 05:34 Daniel Gibson, notifications@github.com wrote:

Ok, something is really broken here - with the "official" 1.5.1 RC2 win32 binaries I can load the linked savegame just fine, and I just gotta walk up some stairs (which already doesn't work as it should and requires jumping), through a corridor, up some other stairs and then I already see the ladder, and when going up that ladder I get stuck.

When I try to load the savegame with newer binaries, I get spawned at the beginning of the level - and then when playing until I actually get to that spot I don't get stuck.

git bisect revealed that the savegame not loading correctly (and sending you back to the beginning of the level instead) is caused by c4c7236 https://github.com/dhewm/dhewm3/commit/c4c72363523fc65e635c7ad7ae86247b4f082340

• haven't found out why yet. I'm not sure if the getting-stuck-on-the-ladder bug needs to be fixed before the next release (as it apparently has always existed), but the savegame-doesn't-load-correctly bug definitely needs to be fixed - I hope that there's a better solution than reverting the offending commit.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dhewm/dhewm3/issues/328#issuecomment-766289970, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIUHNS7EZKSH5LGCT2QHJDS3OPOXANCNFSM4TV4QYTQ .

[HarrievG]

I will see if I can find the offending content.(script) It seems that it is at least linked to that cl. That is not a big change, I will see if I have time today to instrument it some more and check where it kicks in. The hope on a content authoring error is getting bigger again.

-edit- I have looked at map_delta1.script. but it at first glance, the map script does not seem to have functions with arguments, so i cant say that it lies in the map script itself.(called scripts excluded)

[HarrievG]

And, does this not mean, that that commit actually fixes this. (I don't see being put back at start of level to be worse then an PTS :) )

[turol]

For me both master and the commit before https://github.com/dhewm/dhewm3/commit/c4c72363523fc65e635c7ad7ae86247b4f082340 start me in the same place, presumably the beginning of the level. Using default release build. Valgrind gives some warnings about uninitialized variables in the renderer but nothing in the gameplay code. Loading up the level takes 5 minutes and the game runs about 1 frame every 5 seconds. With UBSAN enabled the game fails to build (no typeinfo for class idGameEdit) so can't check for UB.

[HarrievG]

I have manually reverted https://github.com/dhewm/dhewm3/commit/c4c72363523fc65e635c7ad7ae86247b4f082340 on my dwasm/upstream branch and i can confirm that loading the save game in 32b debug on windows gives a 100% repro!

Edit: DONT RUN! the stairs only seem to hold you back, if you dont run.

@DanielGibson I have not hit any of the mentioned asserts (when loading the savegame) in // DG: make sure parmSize gets calculated when parsing prototype (not just when parsing // implementation) so calling this function/method before implementation has been parsed // works without getting Assertions in IdInterpreter::Execute() and ::LeaveFunction() // ("st->c->value.argSize == func->parmTotal", "localstackUsed == localstackBase", see #303)

[HarrievG]

Well, i guess we have hit that golden egg.

But it looks to be prevented by https://github.com/dhewm/dhewm3/commit/c4c72363523fc65e635c7ad7ae86247b4f082340. but not for all releases? or at least not for @turol?

If we can now figure out, why you actually start at the beginning of the level, instead of at the exact save point, when the code is 'patched' ...

[DanielGibson]

As I said, on (64bit?) Linux the savegame always sends me to the beginning of the level (even before c4c7236), but on Win32 I get to the correct place before that commit and to the beginning of the level with/after that commit.

On first sight, this seems like a separate issue - a change that (in some cases) breaks savegame compatibility. Unless that commit indeed fixes the bug (probably accidentally, as you said the Assertions in the script interpreter code it is supposed to fix don't happen in that level) but also breaks savegame compat in some cases because maybe the saved stack of the script interpreter has a different size now or whatever (TBH I'm not sure how/if the script interpreter state is saved).

I think figuring out why we start of the beginning of the level with the patched code (and also on Linux, at least Linux amd64 as that's all I tested) is a very good idea - I guess either we identify a new bug, or we learn more about the original bug.

[HarrievG]

Im going to see if i can get the script debugger tools back in. it sounds like they are needed here?

[DanielGibson]

I never used them so I don't know, but sounds like they might help

[DanielGibson]

Ok, one interesting fact: On 32bit (x86) Linux builds of 1.5.1_RC2 the savegame loads at the correct place and I get stuck on the ladder. For reference, this is what it should look like after loading the savegame: You should go up these stairs and then just follow the path etc and will soon reach the buggy ladder (though at least I also got stuck on the stairs if I didn't jump or at least run):

And this is what it should not look like:

[DanielGibson]

I (mostly) know why the savegame isn't loaded properly: In idProgram::Restore() the calculated checksum doesn't match the one from the savegame, so it returns false, so idGameLocal::InitFromSaveGame() also returns false and idSessionLocal::ExecuteMapChange() handles that by calling game->InitFromNewMap(...) which starts the level from the beginning. I'm really surprised that not a single warning about this gets printed.

I haven't gotten around to debug idProgram::CalculateChecksum() very deeply, but it seems like statements[271].a->num is 577 instead of 581: broken: 271: op: 104 a: 577 b: -1 c: -1 line: 62 file: 3 works: 271: op: 104 a: 581 b: -1 c: -1 line: 62 file: 3 op 104 is OP_PUSH_OBJENT, file 3 is pak006.pk4/script/weapon_base.script and statements[i].a->initialized is 3 (stackVariable) in both cases. (This is just the first difference between the statements when loading with/without c4c7236, I guess the others either have the same cause or are consequences of earlier differences.) I'm not sure why this happens, but maybe the order the stackvariables are created in (and thus get their number) changes because now the function parameters are allocated earlier?

Neither ASan nor valgrind detected any memory corruption; I couldn't get -fsanitize=undefined to work either, I think for that to work we'd have to build the game DLL (base.so) into the dhewm3 executable (maybe d3wasm already has that working?).

(And now the weekend is over which means not much time for this until maybe next weekend)

[HarrievG]

AFAIK when trying to debug the def allocation: Weapon_base is the very first prototyped scriptclass encountered. All of the functions have (invisible/default) 1prop/argument : self / object which I guess must be exactly 4 bytes.

Dumping some idea to check: When loading the save game, it loads an IDTHREAD, which holds an IDPROGRAM which is an script. So , when saving or loading the game, one of the two already parsed function prototypes, the other not.

Ps , yes I believe dwasm should compile the lib in staticly! But I haven't compiled it in a long long time. I don't thing we have to look for mem corruption or uninit vars. I think the problem here is very clear. And then we have yet to figure out the invisible collider , which I think we will figure out at the point we can identify the savegames data exactly.

On Mon, 25 Jan 2021, 06:36 Daniel Gibson, notifications@github.com wrote:

I (mostly) know why the savegame isn't loaded properly: In idProgram::Restore() the calculated checksum doesn't match the one from the savegame, so it returns false, so idGameLocal::InitFromSaveGame() also returns false and idSessionLocal::ExecuteMapChange() handles that by calling game->InitFromNewMap(...) which starts the level from the beginning. I'm really surprised that not a single warning about this gets printed.

I haven't gotten around to debug idProgram::CalculateChecksum() very deeply, but it seems like statements[271].a is 577 instead of 581: broken: 271: op: 104 a: 577 b: -1 c: -1 line: 62 file: 3 works: 271: op: 104 a: 581 b: -1 c: -1 line: 62 file: 3 op 104 is OP_PUSH_OBJENT, file 3 is pak006.pk4/script/weapon_base.script and statements[i].a->initialized is 3 (stackVariable) in both cases. (This is just the first difference between the statements when loading with/without c4c7236 https://github.com/dhewm/dhewm3/commit/c4c72363523fc65e635c7ad7ae86247b4f082340, I guess the others either have the same cause or are consequences of earlier differences.) I'm not sure why this happens, but maybe the order the stackvariables are created in (and thus get their number) changes because now the function parameters are allocated earlier?

Neither ASan nor valgrind detected any memory corruption; I couldn't get -fsanitize=undefined to work either, I think for that to work we'd have to build the game DLL (base.so) into the dhewm3 executable (maybe d3wasm already has that working?).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dhewm/dhewm3/issues/328#issuecomment-766554412, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIUHNSC2NR32D4JFVLMAZDS3T7OHANCNFSM4TV4QYTQ .

[DanielGibson]

I don't thing we have to look for mem corruption or uninit vars. I think the problem here is very clear.

Well it's still possible that the original issue (getting stuck on the ladder) is caused by some kind of memory corruption.

[HarrievG]

I don't thing we have to look for mem corruption or uninit vars. I think the problem here is very clear.

Well it's still possible that the original issue (getting stuck on the ladder) is caused by some kind of memory corruption.

Yes indeed.. to spread our chances, i will continue integrating the script debugger. I actually would really like to have it functional anyway, and see a way to do it without depending on a gamelib too.

[HarrievG]

Almost there..

[turol]

Tried this on Raspberry Pi which is 32-bit. Current master goes to beginning of level and the old commit is somewhere else, which is the correct place I think. I also had trouble walking up the stairs. I'm not sure if Valgrind runs on the Pi and even if it does it's going to be even slower.

[turol]

There are some uses of uninitialized memory in the rendering subsystem when loading the save on 32-bit. Fixing them doesn't fix the stairs problem.

It's possible to make the game compile with UBSan by refactoring idGameEdit class but then it fails to load. Several idDecl* classes are referenced from the game code but their vtables are not included in the .so which is apparently required for UBSan. Is there an existing way to hard-link the game code into the main executable? If not, what changes are required for it?

[DanielGibson]

@HarrievG Nice job on the Script debugger!

@turol I don't think there's a point in trying to run valgrind on RPi, shouldn't make any difference vs PC. I haven't tried it yet, but maybe hard-linking the game code into the executable isn't that hard, see https://github.com/gabrielcuvillier/d3wasm/commit/d9458983f12c287c100229ab0c73611ddae6c388

I created a separate issue for the savegame problems: #344

Haven't gotten further with the getting stuck in ladder problem yet. Does anyone know how one can reproduce it "from scratch", i.e. without a known-broken savegame, by loading the map, playing, maybe creating (and loading) a new savegame? Maybe if there was any memory corruption it happened before creating the savegame so it contains a broken state, but doesn't trigger any real bugs (that could be detected with valgrind or whatever) on/after loading. If I'm not mistaken that bug doesn't always happen when playing that level (even when saving/loading fresh savegames), at least I think I tried that.

[HarrievG]

ladder_bug_headref.zip

1. Loaded original save game with fix NOT in place

2. Moved right in front of an offending collider

3. Saved again.

4. Loaded save game with fix IN place and skipped checksum

5. Saved again.

Result uploaded. All states same to be correct, no assertations, original bug still present.

[HarrievG]

About not being able to walk up the stairs:

The physics engine detects that you walk on an near vertical surface, and determines it is to steep for you to walk on , and ignores movement.

https://github.com/dhewm/dhewm3/blob/2139a122c58bfe2a449320ff669532add53c943b/neo/game/physics/Physics_Player.cpp#L1015

The offensive collider is the world itself. there does not seem to be a dead entity or something blocking you. To be precise, nothing IS blocking you, the surface is to steep.

[DanielGibson]

but don't these stairs work just fine when not coming from a "broken" savegame?

[HarrievG]

Yes they do. ( edit : I have tested the lader AND the stairs when playing from start, and they both do not generate the "steep" warning )

But i am not sure yet if the fail reason applies to the ladder.

[HarrievG]

I have just been able to confirm. That whenever you are stuck on the ladder the same bug as with the stairs also occurs here. [edit] this actually makes sense when you climb a ladder, not when you walk on stairs.!

The game will shout "steep" at you when enabeling g_debugMove 1

But, the ladder case has an different Move function. So the "steep" case is a symptom. I guess the root cause lies in the physics system/collision model

[DanielGibson]

I didn't really find out why this happens, but the more specific symptoms are: In idPhysics_Player::CheckGround() (neo/game/physics/Physics_Player.cpp around line 970), EvaluateContacts() is called and re-calculates this->contacts (an idList<contactInfo_t>, i.e. dynamic array). In the working case, all of the entries of contacts have a normal of (0, 0, 1), i.e. pointing up from the ground In the broken case, some contacts have values like x = -0, y = 0.999801815, z = 0.0199078973. With

        groundTrace.c = contacts[0];
        for ( i = 1; i < contacts.Num(); i++ ) {
            groundTrace.c.normal += contacts[i].normal;
        }
        groundTrace.c.normal.Normalize();

these normals are then added up and re-normalized in groundTrace.c.normal, so it also gets a weird value that's very much not (0, 0, 1). if ( ( groundTrace.c.normal * -gravityNormal ) < MIN_WALK_NORMAL ) { then considers this too "steep" and logs the message you mentioned if g_debugMove is enabled.

I haven't found out (yet?) where these incorrect normals are coming from. It could be walls, but at the steps the walls should be perpendicular, i.e. their normals should have z = 0, and if they're axis-aligned either x or y should be exactly 1.

[DanielGibson]

Progress: The problem is that for some reason the player's (idPhysics_Player) clipModel->axis is wrong. It's a idMat3 transform matrix for some kind of rotation - not even sure what kind of rotation to be honest, rotating the player by looking around does not change it. In savegames that work (or when freshly starting a level) it's the identity matrix ({ {1, 0, 0}, {0, 1, 0} {0, 0, 1} }), in the broken savegame it's { {0.999980 0.002787 -0.005702}, {-0.002673 0.999798 0.019923}, {0.005757 -0.019908 0.999785} }, which is not that different, but apparently different enough for the player bounding box (?? more specifically, the idTraceModel you get from gameLocal.clip.TraceModelForClipModel( clipModel ) which happens to be a box and is identical in the broken and working savegames) to clip into the level geometry when it shouldn't after applying that axis rotation matrix to it.

If at the beginning of idPhysics_Player::CheckGround() I replace clipModel->SetPosition( current.origin, clipModel->GetAxis() ); with clipModel->SetPosition( current.origin, mat3_identity );, which resets the player's clipmodel->axis to the identity matrix, both going up the stairs and climbing up the ladder works without any issues even in the "broken" savegame. This doesn't feel like a proper fix though, I wonder what causes the clipmodel's axis to be wrong in the first place. I think that it gets loaded from the savegame like that (haven't verified this yet), but if that's the case the question still is why it's corrupted(?) in the savegame, or how it became "corrupted" before saving.

[DanielGibson]

More progress: It seems like that crashing lift right before the savegame modifies the clipModel's axis (with some kind of rumbling effect I guess). The backtrace is:

idClipModel::Link() at neo/game/physics/Clip.cpp:597 0xc965b513 
idPhysics_Player::Rotate() at neo/game/physics/Physics_Player.cpp:1,968 0xc9762f2a  
idPush::TryRotatePushEntity() at neo/game/physics/Push.cpp:810 0xc97943e2   
idPush::ClipRotationalPush() at neo/game/physics/Push.cpp:1,313 0xc9799a77  
idPush::ClipPush() at neo/game/physics/Push.cpp:1,437 0xc979b163    
idPhysics_Parametric::Evaluate() at neo/game/physics/Physics_Parametric.cpp:629 0xc972ff1e  
idEntity::RunPhysics() at neo/game/Entity.cpp:2,579 0xc90be112  
idEntity::Think() at neo/game/Entity.cpp:838 0xc90bd54c 
idGameLocal::RunFrame() at neo/game/Game_local.cpp:2,330 0xc91536b3
...

idClipModel::Link() changes axis from the identity matrix to { {1.000000, 0.000338, -0.000338}, {-0.000337, 0.999999, 0.001623}, {0.000339, -0.001622, 0.999999} } in the first call. Then it gets reset to the identity matrix by:

idClipModel::Link() at neo/game/physics/Clip.cpp:597 0xc965b513 
idPhysics_Player::SetAxis() at neo/game/physics/Physics_Player.cpp:1,934 0xc97627c6 
idPush::RotateEntityToAxial() at neo/game/physics/Push.cpp:137 0xc9792bcb   
idPush::TryRotatePushEntity() at neo/game/physics/Push.cpp:827 0xc979452f   
idPush::ClipRotationalPush() at neo/game/physics/Push.cpp:1,313 0xc9799a77  
idPush::ClipPush() at neo/game/physics/Push.cpp:1,437 0xc979b163    
idPhysics_Parametric::Evaluate() at neo/game/physics/Physics_Parametric.cpp:629 0xc972ff1e  
idEntity::RunPhysics() at neo/game/Entity.cpp:2,579 0xc90be112  
idEntity::Think() at neo/game/Entity.cpp:838 0xc90bd54c 
idGameLocal::RunFrame() at neo/game/Game_local.cpp:2,330 0xc91536b3
...

These steps are repeated 43 times (43 calls with a matrix that's slightly off and 43 calls with the identity matrix, alternating, last call resets it to the identity matrix).

I can imagine that this breaks if you save during the shaking, during a frame with the "wrong" (non-identity) matrix and then load again - probably shaking doesn't resume after loading but the wrong axis matrix is saved (and then loaded again). I guess saving on that lift when noticing that hell breaks loose is a normal reflex of many players :feelsgood:

@jyudoki Do you remember if before you created the savegame you uploaded here you did another quicksave while on the lift?

But maybe there's other ways to stick in the wrong state, maybe if you jump off the lift at the "wrong" time or something? UPDATE: I was able to jump off and reduce the amount of changes to the axis (from 2x43 to 2x9), but I couldn't manage to get in a "bad state" that way, the axis was always changed to the identity matrix in the last call. Maybe it's still possible and I just had bad(?) luck, maybe it indeed isn't possible with jumping off and can only corrupt by saving during rumbling.

BTW, one easy way to check what values the player's clipmodel's axis matrix is changed (and giving a good place to set a breakpoint for the debugger) to is to modify idClipModel::Link() like this:

Click me to show Code

```c++ void idClipModel::Link( idClip &clp, idEntity *ent, int newId, const idVec3 &newOrigin, const idMat3 &newAxis, int renderModelHandle ) { this->entity = ent; this->id = newId; this->origin = newOrigin; if(strcmp(ent->GetType()->classname, "idPlayer") == 0 && ent->GetPhysics() && ent->GetPhysics()->GetClipModel(0) == this) { if(newAxis != axis) { const idMat3& ax = this->axis; printf("changing axis from { {%f, %f, %f}, {%f, %f, %f}, {%f, %f, %f} } to ", ax[0].x, ax[0].y, ax[0].z, ax[1].x, ax[1].y, ax[1].z, ax[2].x, ax[2].y, ax[2].z); this->axis = newAxis; printf("{ {%f, %f, %f}, {%f, %f, %f}, {%f, %f, %f} }\n", ax[0].x, ax[0].y, ax[0].z, ax[1].x, ax[1].y, ax[1].z, ax[2].x, ax[2].y, ax[2].z); } } else { this->axis = newAxis; } if ( renderModelHandle != -1 ) { this->renderModelHandle = renderModelHandle; const renderEntity_t *renderEntity = gameRenderWorld->GetRenderEntity( renderModelHandle ); if ( renderEntity ) { this->bounds = renderEntity->bounds; } } this->Link( clp ); } ```

[DanielGibson]

I have a fix (I reset that axis matrix to the identity matrix when loading a savegame), I hope it doesn't break anything.

I should create a proper 1.5.1 RC3 for everyone to test, but not right now as it's very late. I hope I get around to it in the next days, if not I will next weekend.

[Nable80]

Does it make sense to include this matrix into save files at all?

[DanielGibson]

Does it make sense to include this matrix into save files at all?

For the player (or idPhysics_Player): Not really. But it would be really hard not to save it, as it's saved as part of the clipModel which is also used by other physics-using types (and the clipModel itself isn't saved by idPhysics_Player itself but some base-class of it), and for them it (presumably) must be saved.