Jump to content


Bugs with update to 2.05 - strange physics

  • Please log in to reply
34 replies to this topic

#26 Springheel


    Creative Director (retired)

  • Admin
  • 37612 posts

Posted 12 March 2017 - 03:54 PM


... aaaaaand that may very well be the bug that was introduced.


I'll start with that.


That should have only affected belt-purses, not the spilled purse entity.

TDM Missions:   A Score to Settle   *   A Reputation to Uphold   *   A New Job   *    A Matter of Hours
Video Series:   Springheel's Modules   *   Speedbuild Challenge   *   New Mappers Workshop  *   Building Traps

#27 grayman


    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12808 posts

Posted 12 March 2017 - 06:54 PM

All the purses received a new frobbox_size of 10. If I remove that addition, the split purse in the safe is frobable.


I'm trying to understand why the addition of a frobbox_size should make the object appear twice, once with a reasonable bounding box and once with a large bounding box.

#28 grayman


    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12808 posts

Posted 13 March 2017 - 10:10 AM

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.

  • nbohr1more likes this

#29 grayman


    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12808 posts

Posted 13 March 2017 - 12:52 PM

The button in the floor safe worked fine for me with and without the fix. I would need more failure reports before I look at the button again.


The fix solved the problem with the elevator switch in A New Job. I removed the "immune_to_set_frobable" flag on the switch and it still worked fine.


I'm going to submit the fix for 2.06.

#30 fortuni



  • Member
  • Pip
  • 8 posts

Posted 19 June 2017 - 06:24 AM

The Creeps


I've found another unfrobbable purse that has not been reported in the forum before and it's easily frobbed in Fen's video of this mission.


It's the purse in the hidden compartment of the bureau in the room you get to by mantling up onto a couple of crates on top of the bales in the courtyard next to where you start the mission.


Hopefully this quicksave works though.


#31 Moonsneaker



  • Member
  • Pip
  • 6 posts

Posted 27 November 2017 - 07:40 PM

As a try, I updated today again to 2.05. Strange :huh: . Now it works. All updates completed without fails (as it seems). ´Don´t know what changed, but the button in the safe worked correctly :rolleyes:.  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. :D :laugh: :D


Greetings to all Thievies. :ph34r:


To all TDM-creators - Keep up the good Work!!!

Edited by Moonsneaker, 27 November 2017 - 07:42 PM.

#32 Moonsneaker



  • Member
  • Pip
  • 6 posts

Posted 27 November 2017 - 08:17 PM

I don´t get it  ...   ... 


A few minutes later, I ´ve tried the same. I restarted the game and the level Accountant 2 New in Town. Now the purse and the button in the safe could not get grapped. :blink:  :blink:  :blink: 

I closed the safe and opened it once again, and than Bingo :rolleyes: -  Button and purse were frobable. Can anyone tell me, what´s going on?


I guess the Bug is still there. But it is a moody one ^_^.

#33 teh_saccade


    Advanced Member

  • Member
  • PipPipPip
  • 696 posts

Posted 30 November 2017 - 04:57 AM

Eh? I wasn't aware of this.

I hope you're going to tell me that physics behaves better.

Several months late, but:

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?

http://www.moddb.com/engines/dunia <--- old crytek cryengine, 2008.

It's why new Farcry games are 60 FPS render capped, I believe.

Engine 1 or 2 can't cope.
2 is mostly DX11 and graphics updates. Core remains.

TDM is rehashed 2004 iDtech..?

Farcry sucked after 2/3 anyway... 2 remains the best.

Id5 is capped at 60...
Maybe try this: https://community.pc...49-id5-tweaker/


(but check out "known issues" re: physics and scripting)

Edited by teh_saccade, 30 November 2017 - 05:05 AM.

#34 wesp5


    Advanced Member

  • Member
  • PipPipPip
  • 643 posts

Posted 30 November 2017 - 07:18 AM

With Dunia [2] engine - over 60FPS render will cause physics and scripting bugs.

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...

#35 HMart


    Advanced Member

  • Member
  • PipPipPip
  • 764 posts

Posted 30 November 2017 - 05:17 PM

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.      

Edited by HMart, 06 December 2017 - 03:22 PM.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users