After updating to version 1.3.2 today, I encountered an issue I've never seen before: invincibility time is locked to 1s

As the title suggests, in my project, enemies would launch an attack upon colliding with the player. The player’s invincibility time is only 0.2 seconds, allowing for quick judgment of the next attack.

However, after updating to version 1.3.2, I noticed that even though I haven’t made any modifications, the duration of each enemy attack has significantly increased, by at least 1 second. Within 1 second of the player colliding with the enemy, no health loss occurs and no next action is triggered.

After an attack, there seems to be a mandatory wait of over 1 second before any response is possible.

Even after changing the invincibility time to 0.1 seconds, it still forces a stiffening time of about 1 second? What is going on?

I want to revert to the previous version 1.3.1 to test and see if this issue disappears, but it seems the official 1.3 versions are no longer available on Steam?


I hope the official team can at least keep a 1.3x version available for users to test.

Update: I have conducted numerous tests and essentially confirmed that the invincibility time is locked at 1 second. No matter what value I change, it remains unchanged. Even when I set the invincibility time to 10 seconds for testing, it is still treated as 1 second.

===========The official forum has lost its AI translation function===========

I’m experiencing the same issue. Modifying the settings in basesettings does not affect the settings in invincibleSsttings.

@S.C @SLHgameproducer
I’ve been trying to replicate this and I cannot seem to.

If I put 5 seconds in the BasicSettings, it will last 5 seconds:

This makes me wonder, do you have InvincibleSettings node that might be overriding the BaseSettings? Because it has it’s own timer that should override the BasicSettings:

The template has an InvincibleSettings node. Previously, modifying BasicSettings would also update InvincibleSettings. Now, if the InvincibleSettings node exists, the values in BasicSettings are ignored, and the runtime uses the InvincibleSettings node as the standard. In the node list, InvincibleSettings appears below BasicSettings, which may cause its values to be overwritten. After deleting the InvincibleSettings node, the BasicSettings values take effect. This is my current situation.

2 Likes

The InvincibleSettings node is designed as a feature to be introduced when customized invincibility states require capabilities beyond those described in BasicSettings. Therefore, the precedence of InvincibleSettings over BasicSettings aligns with the AGM design intent. Based solely on this description, there is no substantive bug here.


The previous-version branch is the branch where the previous version resides after each update. You can use it for comparison.

@Baz @Justus

The cause has been found. It’s an issue with the InvincibleSetting node. Since I started using AGM, I’ve never operated or used the InvincibleSetting node; I’ve always relied on the “Invincibility Duration After Taking Damage” setting in basesettings for judgment.

Everything was working fine until the update to version 1.3.2, after which the InvincibleSetting node took precedence over basesettings.

This means that no matter how I modified the basesettings, it had no effect on the character. I had to go into InvincibleSetting to make changes. Before this, I didn’t even know the InvincibleSetting node existed :crying_cat:

P.S.: Last night, I wanted to revert to the previous version for testing, but the previous-version folder showed a date of May 26, which wasn’t even version 1.30. It wasn’t until today that a version dated June 30 was updated. I guess the admin forgot to upload the backup…

1 Like

Sorry for the confusion.

The specification that InvincibleSettings takes priority when the InvincibleSettings node exists has not changed.

However, in order to prevent bugs, we recently changed the behavior so that data is forcibly generated when InvincibleSettings does not contain any data. This is the cause of the issue.

InvincibleSettings was configured to be generated when creating a player object from the template, but it was generated without any InvincibleData. Because InvincibleData is now forcibly generated, it suddenly started overriding the BaseSettings behavior, which caused this issue.

I plan to remove InvincibleSettings from the template generation. I will also consider whether there is anything else we can do.