Bug #69

PlayerModifiers shared state issue in v1.5.0h

Status:	Resolved
Priority:	High
Added by:	dsaf on May 4, '26
Assigned to:	Unassigned
Due date:
Reported for:	SFD 1.5.0h Auto
Fixed In Release:	SFD 1.5.0i

Steps to Reproduce

No steps to reproduce

Explanation

Using GetModifiers() and SetModifiers() with PlayerModifiers now appears to operate on shared mutable state instead of independent snapshots.

The following sample was tested in v1.4.2 and v1.5.0h:

PlayerModifiers mod;
IPlayer player;

public void AfterStartup() {
    player = Game.GetPlayers()[0];
    mod = player.GetModifiers();
}

public void ChangeModifiers(TriggerArgs _) {
    var strong = new PlayerModifiers() {
        SizeModifier = 2f
    };

    player.SetModifiers(strong);
}

public void RestartModifiers(TriggerArgs _) {
    player.SetModifiers(mod);
}

In v1.4.2, this works as expected: mod stores the original modifiers, ChangeModifiers() applies temporary modifiers, and RestartModifiers() restores the original modifiers.

In v1.5.0h, RestartModifiers() no longer restores the original state.

Inspecting values shows that mod also changes after calling SetModifiers(). For example, mod.SizeModifier becomes 1.25, even though mod was captured earlier and is expected to remain unchanged.

This indicates that PlayerModifiers is no longer being handled as a value snapshot, and is instead being shared and mutated.

This breaks an existing and common scripting pattern where modifiers are captured, temporarily replaced, and later restored.

The API is also not explicit about whether GetModifiers() returns a snapshot or a live reference, or whether SetModifiers() stores a copy or mutates / shares the provided instance.

Either the previous behavior should be restored so PlayerModifiers is handled as a copied value in this flow, or the reference semantics should be made explicit and a supported way to clone modifiers should be provided (for example PlayerModifiers.Copy()).

Watchers

Watch