I'm going to leave the frobbox_size in place (and thus the second bounding box it creates). I don't want to tinker with frobability for items that define their frobboxes.

It's cleaner to verify that an item's physical clipmodel is touching the setFrobable target brush when that brush is building its list of 'contained items'.

This ignores the false positive that was telling the safe's lock that the spilled purse was inside its setFrobable target brush, which allows the purse to be frobbed when the safe is opened. (I also need to check that this is what was affecting the button inside the other safe.)

The solution should also fix the problem we had with the elevator switch in A New Job, but I need to verify that assumption. Adding this solution will not affect A New Job.

As a try, I updated today again to 2.05. Strange . Now it works. All updates completed without fails (as it seems). ´Don´t know what changed, but the button in the safe worked correctly . Are there changes in the 2.05 update during it´s appearance till now? Anyway. I hope it will remain stable. However, I would be glad to the next update ... 2.06 - or even higher.

With Dunia [2] engine - over 60FPS render will cause physics and scripting bugs. Have to choke it on modern hardware to stop many bugs and strange behaviours.
Maybe NASA could run Farcry2 on max settings back then, but no-one else could... Even still - who had a monitor with more than 60hz / 58hz no vsync against tearing?

The same is true for the Source engine which is based on the Quake engine, so it might be relevant for the Doom3 engine too. If your FPS are higher that 90 you will regularily get stuck in opening doors and if you go even higher you can't push some physical items anymore...

Source Engine uses havok physics so unfortunately is not relevant for idtech 4, this last one uses a custom made physics engine, this is also pretty much the standard way in the industry to conciliate physics time with the rest of the game time and prevent inconsistencies, unfortunately the faster the game runs the less reliable the physics calculations become, one way that i think could help is to make the physics always run to max 60fps, even if the game runs at more, this will have their own problems tho, like objects moving slower than expected compared to the rest of the game, afaik is not a easy problem to solve.

btw one of the most prevalent problems of most old games in modern systems, is not because of windows compatibility problems, or because we have modern GPU's with modern API's, many are almost CPU based anyway, the fact for most of them is, they run faster then they should, one recent example i add was Soul Reaver 2, on my new windows 10 PC was only able to play the game after, one forcing it to run on one CPU core, two finding a way to make it run at less than 60fps, used reshade to force post process effects and make it run slower (and prettier ;P ), before this, some controls didn't work, i couldn't change worlds, would become stuck in one place, etc, pretty much unplayable.