EverestAPI / EverestAPI/CelesteTAS-EverestInterop
RumbleTrigger Desync
- Dominant language
- C#
- Stars
- 85
- Forks
- 30
- PR merge metrics
- No merged PRs in 30d
Description
`RumbleTrigger`, which breaks `CrumbleWallOnRumble` blocks
```
...
foreach (CrumbleWallOnRumble crumble in crumbles){
crumble.Break();
yield return 0.05f;
}
```
determines the order of these crumbles when `RumbleTrigger.Awake` is called. And `RumbleTrigger.Awake` contains this line of code
`crumbles.Sort((CrumbleWallOnRumble a, CrumbleWallOnRumble b) => (!Calc.Random.Chance(0.5f)) ? 1 : (-1));`
We know when `Level.LoadLevel` is called, `new Random(Session.LevelData.LoadSeed)` is pushed onto the random stack, then all entities/triggers added to the scene, their `Awake` methods called, then this random is poped
So in most cases, this `RumbleTrigger` RNG is actually fixed
However, if there's a mod which hooks `Level.LoadLevel` to add a mod entity,
```
private static void On_Level_LoadLevel(On.Celeste.Level.orig_LoadLevel orig, Level level, Player.IntroTypes playerIntro, bool isFromLoader){
level.Add(new ModEntity());
orig(level, playerIntro, isFromLoader);
}
```
and the ModEntity calls `Calc.Random` in its `Awake` method, then the RNG of `RumbleTrigger` is affected
And there is such example, e.g. in Gallery Collab HeartSide, if you ever passed flag19, then a MaxHelpingHand.CustomizableGlassBlockController is added to each upcoming level, and this entity, calls Calc.Random. So in this case, if a team cooperate on this tas, each team member responsible for several flags, and no one knows there is such an issue. When they've done their work and try to put their tases together, a desync appears unexpectedly.
---
Now the issue is, should we fix this "desync"?
We can easily prevent this kind of desync by enclosing RumbleTrigger.Awake with a Push/PopRandom pair. However, this may cause most tases which rely on the order of crumble-blocks-breaking to desync. Or we manually search for all such kind of bad mod entities and patch them?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading RumbleTrigger.Awake and Level.LoadLevel, focusing on the Calc.Random usage and the CrumbleWallOnRumble ordering. Reproduce the interaction with a ModEntity whose Awake calls Calc.Random, using the described MaxHelpingHand.CustomizableGlassBlockController example. Done requires an agreed approach that resolves the desync without unintentionally breaking existing crumble ordering.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- game-dev
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100