Uru CC: Falling-in-place problems.

[Ehren]

So weirdly, with my new computer my avatar will start doing the falling animation when just touching certain objects, this happened in some cases on my last computer too, but no where even close to THIS easily. The problem is that if this falling animation goes on for a little while an automatic panic link happens. Since I play a lot in first person, I could be standing touching something and not even know the avatar thinks it's falling.

I feel like at this point with Uru CC the falling timeout should just be gone entirely, either you hit a panic link region in which you WOULD still link out or you need to manually open the book and link yourself out when ACTUALLY falling out of an age. It's not the most elegant solution but it's better than the linking out happening when you are mistakenly falling in place (and might I add that in a lot of cases I can just turn or walk to get out of this falling animation, so it's not like I am stuck without hope of recovering from the falling in place animation in most cases.)

So, uh... does anyone know where the timeout for falling is even stored? Is it in the exe itself and if so is there any way to either get rid of the timed panic link or at least set it for a REALLY long time? I feel like I read about someone editing the base exe for Uru CC before to do something with camera behavior I think... but maybe I am wrong.

Even if I can't get rid of the stupid animation happening, I REALLY hope there is something I can do about the timed panic link.

[Sirius]

New PC ? Haha, that's your framerate going too high friend Old games like Uru start freaking out when the physics engine runs too fast, which causes it to fail detecting some collisions.

I did a quick test by running Uru windowed with a 800x600 resolution. I'm getting nearly 400fps, and the bug start appearing when walking on steep inclines like in Gira. Play fullscreen again with vsync forced on, the game is clamped at 144hz and the problem disappears.

Have a look at your framerate (Steam and Fraps both have an FPS counter). If it's over 400 then that's probably the problem. Playing fullscreen with vsync on clamps Uru's framerate to your monitor's refresh rate (at least it does on Windows 8, I dunno about Windows 10). Or else you can probably use an external frame rate limiter.

So, uh... does anyone know where the timeout for falling is even stored? Is it in the exe itself and if so is there any way to either get rid of the timed panic link or at least set it for a REALLY long time? I feel like I read about someone editing the base exe for Uru CC before to do something with camera behavior I think... but maybe I am wrong.

Yep, it's a variable in the exe (const float plAvBrainHuman::kAirTimePanicThreshold = 10, in seconds). I agree this limit is a bit silly.
And yeah, a while ago I hacked the exe to get the first person camera to render in widescreen, and to remove the up/down limit when looking around (both hacks are still available somewhere in Drizzle). I'm afraid I can't do something similar with that particular variable though. My knowledge of hacking is limited to opening the exe in HxD and search/replace very specific values, like 1.33333333 in the case of the widescreen hack. A value of 10 appears dozens of time in the exe, so figuring out which one to modify would take hours.

[Ehren]

I'm afraid I can't do something similar with that particular variable though. My knowledge of hacking is limited to opening the exe in HxD and search/replace very specific values, like 1.33333333 in the case of the widescreen hack. A value of 10 appears dozens of time in the exe, so figuring out which one to modify would take hours.

I found it! In the 1.1.4 beta version at least.

It's the 9th instance of 10 (as a float) from the bottom:

Show Spoiler

[attachment=0]AirTime.png[/attachment]

I ended up setting the fall time to 100000000376832 seconds, which is as high of a number as it allows. Apparently that's about 3,170,979 years, so I might have overdone it a bit...

[Sirius]

Wow nice work, hope it didn't take too long testing out ! 3 million years should do. The engine would run into many more problems before we reach that time

Ideally all those tweaks (fall time, view pitch, widescreen) should be loaded at runtime through a ModDLL without modifying the exe itself, but finding the runtime addresses is more complex since they are rarely fixed (I think ? Would be worth checking out I guess...).

In the 1.1.4 beta version at least.

Good to know, now that we have multiple versions of the executable floating around.
Hmmm... I wonder what happened to finally fixing the FoV bug in that version. Probably Cyan forgot about it Guess I'll continue using the old version.