Bugs with update to 2.05 - strange physics

[Moonsneaker]

.

Edited February 20, 2019 by Moonsneaker

[AluminumHaste]

What's your com_fixedTic set to?

[duzenko]

Could you upload a save game demonstrating this bug?

[HMart]

Moonsneaker don't know if this is the case, but i most tell you the idtech 4 (the TDM engine) rigid body physics don't behave the same has PhysX or Havok for example, is a simpler system so objects behave in a simpler way by design, but again don't know if this is what you are seeing.

Edited March 11, 2017 by HMart

[New Horizon]

Moonsneaker don't know if this is the case, but i most tell you the idtech 4 (the TDM engine) rigid body physics don't behave the same has PhysX or Havok for example, is a simpler system so objects behave in a somewhat unrealistic way by design, but again don't know if this is what you are seeing.

 

I don't think it's anything like that since they're reporting a change in behavior after the update.

[AluminumHaste]

 

I don't think it's anything like that since they're reporting a change in behavior after the update.

 

Hence my asking about com_fixedTic, as higher FPS has changed how physics behaves.

[Moonsneaker]

 

Edited February 20, 2019 by Moonsneaker

[grayman]

Hence my asking about com_fixedTic, as higher FPS has changed how physics behaves.

Eh? I wasn't aware of this.

 

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

[Moonsneaker]

.

Edited February 20, 2019 by Moonsneaker

[AluminumHaste]

Eh? I wasn't aware of this.

 

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

I'll start a PM about it,

[HMart]

 

I don't think it's anything like that since they're reporting a change in behavior after the update.

 

Facepalm You are right seams that fact totally passed by me. Sorry.

[duzenko]

I remember having a similar problem in Illusionist's Tower.

I would still ask for a save uploaded to a 3rd party server like dropbox or google drive.

The reason is I can't frob anything in the safe if I simply noclip into it.

[fortuni]

I'm having the same problem with the purse in Balcon's safe with 2.05 install.

 

Here are a couple of save...didn't know whether you prefer hard save or quicksave, so here's one of each, I also zipped up the files, is that the correct thing to do with TDM saves? this is only my second post in TDM forums so do not know the correct procedure but we'll learn quickly we hope.

 

ps. it's the right hand purse that is unfrobbable.

 

pps. I didn't have a problem with the purse or the button in the landlord's safe, but if i'm correct TDM can be a bit funny if you accidentally double frob buttons etc....well that's my experience.

Edited March 12, 2017 by fortuni

[stumpy]

isn't this likely to be the frob bug, where items become unfrobable if the froblock doesn't work as it should.

 

items inside a froblock must be frobable true

nocliping into a safe or a chest wont work because the froblock is active and has made all frobable items frobable false

 

some items in the update have lost there default frobability and it has to be added in editor, this seems to be mainly on enitiy movable loot. if you go into the item in the editor the default frobability is greyed out and set to false, so you have to add the frobable true spawnarg setting to get it too work as intended. Once frobable is true on item then froblock works as it should and doesn't bug out.

[athalle]

For me, there's got 2 problems with this fm since 2.05, the purse in Balcon's safe that doesn't highlight and the button in the chest (to activate the elevator). For this one, I had to use noclip to push it...

[Moonsneaker]

.

Edited February 20, 2019 by Moonsneaker

[grayman]

isn't this likely to be the frob bug, where items become unfrobable if the froblock doesn't work as it should.

Is there a bugtracker issue for this, noting an example where it happens?

 

some items in the update have lost there default frobability and it has to be added in editor, this seems to be mainly on enitiy movable loot. if you go into the item in the editor the default frobability is greyed out and set to false, so you have to add the frobable true spawnarg setting to get it too work as intended. Once frobable is true on item then froblock works as it should and doesn't bug out.

Please give an example of an item (and map?) where this occurs.

 

I just checked every piece of moveable loot and the 'frobable' spawnarg is set to true for all of them.

[grayman]

The update to 2.05 changed some of the characteristics of some items.

Are there instances other than the purse and the button?

[Springheel]

some items in the update have lost there default frobability

 

 

There was no indication of this during beta-testing...where did you get this information?

[grayman]

Here's what's actually happening ...

1 - There are two frob control boxes at the safe: one surrounding the items, and one surrounding the safe's lock.
2 - At spawn time, the second one is finding the bad purse and turning off its frobability. This is because the bad purse appears twice on the list of entities near the safe's lock. One of these instances has a good clipmodel size that doesn't touch the lock's frob box, and one has a much larger bad clipmodel size which does. The only other item inside the safe that appears twice is the other purse, but its bad clipmodel doesn't touch the safe's lock, so its frobability is left as is.
3 - At spawn time, when the safe's frob box activates (after the lock's frob box), it finds that the bad purse has had its frobability turned off, so it doesn't include it in the list of items that are affected by the frob box being activated. It turns off frobability of everything else in the safe, and puts those items on its list.

4 - When the safe is opened, the safe's frob box inspects its list and turns frobability on for all items it had turned off at spawn time. Since the bad purse isn't on the list, the bad purse remains unfrobable.

 

We saw this problem in A New Job, wrt the upper switch for the elevator and the frob box for the safe, which are on opposite sides of the same wall. We fixed that problem by making the switch unaffected by frob box changes, and I filed a bugtracker issue to figure out why the switch had an immense clipmodel at spawn time that was caught by the safe's frob box.

 

So the root cause appears to be that each spilled purse appears twice on the list of entities that get checked. One has a good clipmodel and other has a bad (large) clipmodel. One of the spilled purses gets caught by the lock frob box, and the other doesn't.

 

Since this problem involves a particular item (the spilled purse) and two frob boxes near each other, it is most probably not a widespread problem. Accountant 2 simply got bit by it.

 

I will look into this for 2.06. Prior to that, I can't think of any workaround. It might be that the spilled purse is not the only item that appears twice at spawn time.

 

The 'button inside a safe' not working is probably the same problem.

[duzenko]

So the root cause appears to be that each spilled purse appears twice on the list of entities that get checked. One has a good clipmodel and other has a bad (large) clipmodel. One of the spilled purses gets caught by the lock frob box, and the other doesn't.

So why did it work in 2.04 and not in 2.05?

[nbohr1more]

This is making me more worried about:

 

http://bugs.thedarkmod.com/view.php?id=4150

 

When the frob behavior of a default asset is not right, mappers will manually correct it. When we "fix" the problem,

the mappers corrections will still be in the map therefore the attempts to fix collide...

[grayman]

So why did it work in 2.04 and not in 2.05?

 

I'll post that here when I find out what changed in 2.05.

[grayman]

This is making me more worried about:

 

http://bugs.thedarkmod.com/view.php?id=4150

 

When the frob behavior of a default asset is not right, mappers will manually correct it. When we "fix" the problem,

the mappers corrections will still be in the map therefore the attempts to fix collide...

 

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

 

I'll start with that.

[stumpy]

i may have been wrong about the frobability thing, sorry.