Thanks for the detailed explanation on the sysreq keys & when & how to use them for unlocking a frozen system :D. Also for the systemctl bit because i wasnt even sure what to do if i had gotten to a console lol.

It’s fixed in 6.8.10 and 6.9 if you have the ability to upgrade to those.

Honestly idk how id even begin to do that lol, and id also maybe rather not start my first week of linux use by immediately trying to change the kernel version on my own XD (either down or up). I did hear about an issue with rdr2 and kernel 6.8.9 from a reddit post which i found through someone writing about problems with the game on its protondb page. But i thought i was fine as my game worked normally until i encountered the crash & because the reddit and protondb post say its solved by enabling rebar which (iirc) i already have.

However idk if that reddit posts issue is the same/related to the one you linked. Since the rest of the game and my system seem to be mostly fine i think ill either just not play the game or specifically avoid the cutscene when i do (its in an optional quest luckily). And then ill maybe return to it after the updated kernel arrives on fedora to see if it solves the crash or not.

Thanks for the link! I managed to set up sysrq with it, which might have saved me from reinstalling steam when the crash occurred the second time (see the update in my post).

I’m still curious as to whether there’s an easier way to do this than simply updating the global position, by script, to match the pose’s.

I’m not sure if this is what you want but maybe you could use the BoneAttachment3D Node?

Ok so it seems like they don’t commute? I asked the question in part because i wanted to do something like:

const base_transform : Transform3D = <some transform>

func get_base_transform(node : Node3D) -> Transform3D:
    return node.transform * base_transform

func set_base_transform(node : Node3D, transform : Transform3D) -> void:
    node.transform = base_transform.affine_inverse() * node.transform

and i wanted to be sure that if i do set_base_transform(some_node, some_transform) i’d be guaranteed to get that get_base_transform(some_node) == some_transform afterwards. But when i tried it the above code did not work out, at least i didnt get the result i expected. But when i flipped it so that set_base_transform did node.transform = node.transform * base_transform.affine_inverse() instead it did work out. Its still not hard proof though, maybe something else was messed up the first time, or it only looks like it works now and i’ll discover the transform still isn’t what i wanted it to be. Or they do commute but only under some constriction like no scale on any axis or something and i just happened to fulfill it with all the ones i used in my test.

So it would still be good to know for sure whether/when Transform3D’s commute.

EDIT: I accidentally wrote the first line wrong, it said that they do commute. When actually the experience i had with it working only after both functions did their multiplications in a compatible order should indicate that they don’t commute.