Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

door: fix checking for Lara position #1422

Merged
merged 3 commits into from
Jul 25, 2024
Merged

door: fix checking for Lara position #1422

merged 3 commits into from
Jul 25, 2024

Conversation

rr-
Copy link
Collaborator

@rr- rr- commented Jul 24, 2024

Checklist

  • I have read the coding conventions
  • I have added a changelog entry about what my pull request accomplishes, or it is an internal change

Description

Resolves #1419.

Removes the proximity test and instead checks if Lara is on the same tile where the ghost block will spawn.

@rr- rr- added this to the 4.3 milestone Jul 24, 2024
@rr- rr- requested review from a team, eikehein, lahm86 and walkawayy and removed request for a team July 24, 2024 21:48
Resolves #1419.

Removes the proximity test and instead checks if Lara is on the same
tile where the ghost block will spawn.
@rr- rr- force-pushed the b1419-closing-door-glitch branch from c448e10 to 07a34f0 Compare July 24, 2024 21:58
Copy link
Collaborator

@walkawayy walkawayy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This LGTM from what I tested, but I'm certainly no expert tester.

Copy link
Collaborator

@lahm86 lahm86 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. There is another issue though (and it's present in the current release too). If you save and load behind a door (in this non-portal scenario), Lara will void. The problem I believe is that Door_Initialise is called on level load and so Lara's position at that point is at the start of the level. The savegame logic will move her to the door's block, but then there are no further checks for door status. Should we tackle this separately?

@rr-
Copy link
Collaborator Author

rr- commented Jul 25, 2024

I have resolved the savegame issue mentioned above.
However, I've also observed that the camera still shakes when swimming up against the current in the Midas pool when the gate isn't fully closed. It's because we don't place the invisible block during the door animation that prevents Lara from reaching the trigger. It works as expected after the gate fully shuts, though, which is what this PR corrects (along with the save/load issue). I think this is consistent with the OG; can someone verify this?

@lahm86
Copy link
Collaborator

lahm86 commented Jul 25, 2024

Yes, just tried TombATI and you get the same behaviour in that scenario.

@rr- rr- merged commit e7dd5ac into develop Jul 25, 2024
2 checks passed
@rr- rr- deleted the b1419-closing-door-glitch branch July 25, 2024 14:02
@rr- rr- added the TR1 label Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TR1X bug: Lara can reach trigger through closed UW gate
3 participants