[Bug]: Tux immunity after door

[Alasdairbugs]

SuperTux Version

v0.6.3-1566-ge43838b1d

System Information

win 11 64 bit

Expected Behavior

Tux is not immune to every damage type

Actual Behavior

After entering a door, possibly in addition to having Tux be set invincible and then not invincible (#3051 related(?)), tux is invincible to all damage types.

Steps To Reproduce Actual Behavior

go through a door, if thats not enough, possible try make tux invincible and then not invincible, then go through the door.

if that doesnt work, then start by making tux not invincible (he shouldn't be anyway, by default), invincible, then not invincible, then go through a door.

Additional Information

No response

Guidelines For Reporting Issues

• I have read https://github.com/SuperTux/supertux/blob/master/CONTRIBUTING.md#bug-reports.
• I have verified this isn't an issue that's already been reported.
• I have verified this isn't a discussion, or an issue about a crash or a feature request, but rather an actual bug ─ that is, the game did something not intended.
• I have verified this issue is not about wrong translations (use Transifex for those), or anything unsupported (e.g. third-party add-ons).
• In this report, I have only included details about one (1) bug.
• If I make a mistake while submitting this report, I agree to use the "Edit" feature to correct it, instead of closing this issue and opening a new one.

[Brockengespenst]

It‘s not a bug, it‘s a feature. Please see discussions in #2844 and related tickets.

[Alasdairbugs]

No, it is a bug. I have permanent immunity after entering a door, please see the latest nightly and related literally in your face bug.

[Brockengespenst]

Permanent immunity should indeed not be, Tux should only be invincible during the fade in effect.

[mstoeckl]

I can reproduce this, and think I understand the mechanism for this: #3051 repurposed the variable m_is_intentionally_safe to control invincibility, instead of creating a new one; before the PR the variable was only being read by Player::draw to control a "blinking" effect during the post-damage safe period, but had no effect on the game logic; the variable was set to true by Player::make_temporarily_safe, which may get called on spawn or teleport under certain conditions, and set to false in Player::kill.

[Brockengespenst]

I can reproduce this, and think I understand the mechanism for this: #3051 repurposed the variable m_is_intentionally_safe to control invincibility, instead of creating a new one; before the PR the variable was only being read by Player::draw to control a "blinking" effect during the post-damage safe period, but had no effect on the game logic; the variable was set to true by Player::make_temporarily_safe, which may get called on spawn or teleport under certain conditions, and set to false in Player::kill.

That is correct. I should have chosen a diffent name for the variable, it is obviously misleading.

[Brockengespenst]

I have split the flags according to their intention and renamed the flag that avoids the blinking effect to make it hopefully less misleading. I did some tests with the door and the scripting function and did not see any unintended behavior, but please give it a try and check for yourself.