Cube at wrong position in Chamber 13

[Deconimus]

Version of the game

Master Branch, commit d99af47

Original Hardware or Emulator?

Project64 3.0.1

What is the bug?

The cube in the second room of Chamber 13 is not initially at the original location as in the original game. It should be on the inactive moving platform instead of on the ground.

Steps to reproduce the behavior:

1. In test chamber 13
2. Look through the glass.
3. See the cube in the second room being at the wrong position.

Screenshots

Additional context

The first screenshot shows the cube being at the wrong position as mentioned. The second was taken as I was trying out whether the current game physics are capable of handling a cube on a moving platform (which seems to work).

[mwpenny]

Thanks.

Here is how the cube is positioned in the level's .blend file (proper position):

If I enter the level from the "new game" menu or from the previous chamber, it is placed correctly:

However, if I load a save, I can reproduce what you are seeing:

I have debug contact solver drawing on, and can see the cube starting in its proper place before getting thrown across the room.

Likely, it is spawning inside of the platform and getting ejected. In fact, when I edit the level and move the cube slightly inside of the platform, I see the same thing. So it looks to be an issue with scene deserialization (affecting more than just cubes). This will be lower priority for now until I make more general progress, but does need to be fixed. Any others like it that you find are useful to track here too.

[Deconimus]

You're right, I forgot to mention I was loading the level instead of starting a new game. Starting a new game at this chamber yields the cube being placed correctly as you've shown for me too.

[FoxbitDreamtail]

wouldn't spawning the cube slightly above the platform upon chamber load and then letting physics take the wheel fix this issue? it kind of looks to me like it is being flung off the platform on load, either that or their is a weird offset of some kind....

[mwpenny]

That would solve the problem in this one instance, but special casing things like this can get quite messy code-wise and also doesn't address the issue with different objects/platforms in other parts of the game. So a general solution is best.

This looks like an interaction between save file (de)serialization and rigid body sleep flags.