Lara is getting teleported on collision

[vvs-]

The new collision system is rough at present, but that isn't a point. For some strange reason the coordinates fluctuate wildly. Try this test at the console setgamef(4,3) setEntityPos(player,42787,39352,-6131,177,0,0) then return to game play and tap down once. I've got Lara on top of a crate, on top of it at the back wall, inside the crate, out of the level geometry and even at the opposite front wall of the room at one point!

[Gh0stBlade]

Collision is being updated by TeslaRus thus there are currently numerous bugs which have occurred. I'm sure he's aware of this and will fix it as time goes by.

[Lwmte]

I've also noticed these very strange teleporting issues and asked TeslaRus about that; he tells that the reason may be some screwed up overrides in anim state control module, and he needs to revise that.

[vvs-]

Yes, seems like in OpenTomb informal coroutines have been implemented with shared data, but without proper synchronization abstraction.

EDIT: This particular bug is now fixed, but there still remain many cases of geometry penetration. Overall it's much better now.

[Lwmte]

I just got informed that TeslaRus used completely different algorithm to check for penetrations (although it's slower), which fixed about all penetration cases. However, face wall is broken again, let's wait for more fixes.

[vvs-]

There is a workaround: you can use jump and then action to grab a ledge, except in water.

BTW, do you guys use GitHub notifications? I have a feeling that some information get missed. Recently I updated #17 and nobody responded :worried:

[Lwmte]

Sorry! Currently I have little time, so replies might get delayed. Consider current collision algorithm still-work-in-progress! :)

[vvs-]

The most problematic is animation code. It is not synchronized with other parts of the engine and can cause geometry penetration anywhere. Try for example to pull a lever under water or to push a block somewhere. Also, correct climbing collision heavily depends on current animation behavior, which is very fragile and change often. Some more clear abstraction would be helpful which won't depend on random factors and which would make changing entity position by different code impossible.

[vvs-]

Here's a nice recent example: in High Security Compound at 30529,44245,-2560,264,0,0 press action.

[Lwmte]

I tried it, Lara just grabs a block, and nothing abnormal is happening.

[vvs-]

Well, but there is no block at that position. She was teleported to it first.

[vvs-]

It's not fixed, but just changed the side of the cube. Now it's at 29509,43105,-2560,180,0,0 and press action+up. It also happens in Palace Midas but is more difficult to reproduce.

P.S. The old side of the cube works too. Just the coordinates are slightly different: 30605,44210,-2560,289,0,0 because the angle to grab a block now is very narrow.

[vvs-]

In TR1 Lara's Home map, pressing action while running forward to a crate makes Lara to teleport on top of it instead of climb up. Actually happens with any one-click climb.

[TeslaRus]

aha... thanks, I saw same bug, but can't reproduce... run + action (no fix all + direction + speed linear deal buggy thigs)

[vvs-]

Now it doesn't even required to actually hold the action to be teleported. I'm not sure if this is recent regression.

[TeslaRus]

tr1 map home (99) run to the fence... it is collision resolving logic...

[TeslaRus]

not reproducing more...

[vvs-]

Those related to teleporting up are gone. But those which teleport near movable block are still there. That High Security Compound example is still valid.

[ghost]

Is for TR3 but fixed in TR1 ?

[vvs-]

No, this is not related to game version at all. This is caused by a forced position change on certain events, e.g. grabbing a movable block. That's how it's implemented to prevent collision related mesh penetration due to vast differences in physics simulation in Bullet vs. Core floor data approach.