Skip to content

[Bug]: Tux immunity after door #3186

Closed
@Alasdairbugs

Description

@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 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.

Activity

Brockengespenst

Brockengespenst commented on Jan 21, 2025

@Brockengespenst
Contributor

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

Alasdairbugs

Alasdairbugs commented on Jan 21, 2025

@Alasdairbugs
ContributorAuthor

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

Brockengespenst commented on Jan 21, 2025

@Brockengespenst
Contributor

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

mstoeckl

mstoeckl commented on Jan 22, 2025

@mstoeckl
Contributor

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

Brockengespenst commented on Jan 22, 2025

@Brockengespenst
Contributor

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.

added a commit that references this issue on Jan 22, 2025
49d73db
Brockengespenst

Brockengespenst commented on Jan 22, 2025

@Brockengespenst
Contributor

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.

added a commit that references this issue on Jan 25, 2025
b45af28
added a commit that references this issue on Feb 3, 2025
af3b9d4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      [Bug]: Tux immunity after door · Issue #3186 · SuperTux/supertux