Skip to content

Remove technical reason for desync from desync window#836

Open
mibac138 wants to merge 1 commit intorwmt:devfrom
mibac138:hide-technical-desync-details
Open

Remove technical reason for desync from desync window#836
mibac138 wants to merge 1 commit intorwmt:devfrom
mibac138:hide-technical-desync-details

Conversation

@mibac138
Copy link
Contributor

@mibac138 mibac138 commented Mar 17, 2026

This can be confusing and doesn't provide much value on it's own (e.g. when someone joins the Discord and just says they have Wrong random state on map). It can also lead users to mistakenly thinking a different issue is the same as their own because the headline is the same.

The text is still present in the log file.

@Zetrith @notfood @SokyranTheDragon thoughts?

This can be confusing and doesn't provide much value on it's own (e.g.
when someone joins the Discord and just says they have Wrong random
state on map). It can also lead users to mistakenly thinking a different
issue is the same as their own because the headline is the same.

The text is still present in the log file
@notfood notfood added the enhancement New feature or request. label Mar 17, 2026
@notfood notfood moved this to In review in 1.6 and Odyssey Mar 17, 2026
@notfood
Copy link
Member

notfood commented Mar 17, 2026

For user reports it's not very useful. Maybe just keep it enabled for dev if we need it. I don't mind either way.

@rautamiekka
Copy link

rautamiekka commented Mar 17, 2026

No.

Removing it will do more harm than good, it's at least a starting point, even if you won't report it or try to debug it in any way; removing will make the mod look like it has no, or less, clue what happened, especially when you ain't new like me & my friend are.

At the very least the reason suddenly changing between desyncs will indicate something has gone worse.

I don't have a better way, though.

@mibac138
Copy link
Contributor Author

This PR is not a hill I'm going to die on, but I'd like to understand why do you think it's a bad change.

Removing it will do more harm than good, it's at least a starting point, even if you won't report it or try to debug it in any way

If you aren't going to do anything about the desyncs, then what does it even matter? It's a starting point for what?

removing will make the mod look like it has no, or less, clue what happened

The mod doesn't really know why a desync has happened, it only knows that it did happen and what were the last actions (simplified) before the desync (available in the desync file which also has a lot more info).

especially when you ain't new like me & my friend are.

At the very least the reason suddenly changing between desyncs will indicate something has gone worse.

If you are curious you can just enable dev mode in the game options and you'll still see the reason, and if you're willing to debug the issue, the text is probably not going to be super useful and you'll almost certainly use the desync file (which still contains the reason) anyway.

@SokyranTheDragon
Copy link
Member

I feel it's a good change - but I'd slightly expand on it. Perhaps by adding some extra text like: "detailed technical information is included in the desync file". Or something similar.

As for why I think it's a good change - I honestly don't even bother with the desync reason. I feel it doesn't provide any useful info. Sure, desync may have happened when ticking map 0, but what is to say that it wasn't caused by something that desynced in the world or on a different map that the map 0 was currently basing its logic on? In most desyncs that I myself have observed, that message doesn't provide any meaningful information and could just make you believe that you've fixed a particular desync and encountered a different one because the message has changed.

Although that's generally the issue with desyncs in this mod. We're tracking the most obvious sources of desyncs (like by tracking when Verse RNG is used), and vast majority of desyncs are caused by something else. So the desync tracing will just tell you the first time it noticed a desync, rather than when it actually occurred.

Somewhat unrelated to the actual PR, but there's actually a tool that's very useful in looking for desyncs that Zetrith made - MutationTracing. By using prepatcher, it basically logs all the fields that are accessed in simulation code, interface/non-simulation code, and both. It requires a lot more technical knowledge, but it can allow you to find stuff that's used in simulation that may also be modified out of simulation, which is a very easy desync source. Sadly, analyzing it takes a bit more time, and I believe that it's a tad bit slower than your usual desync logging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request.

Projects

Status: In review

Development

Successfully merging this pull request may close these issues.

4 participants