Closed Eroc closed 2 years ago
I think I know what caused this. I forgot to push the update that corrected updated the "whole package" instead of just the hunger module.
I'll correct this tonight when I'm back at my home PC.
Unfortunately, this didn't resolve our desyncs, but they are related to the CVAR, and I've finally worked out a reliable reproduction. Start a game where one player has UaS_HungerGrumbles set to 1 and the other set to 0, wait until the grumbles start, then eat food as either player while the other continues to starve. It'll desync pretty quickly after that for the other player, usually before you've even finished eating the ration.
So you don't have to spend 15+ realtime minutes waiting to get hungry, I've attached a save file with two players already hungry enough to trigger it. Files to load are just latest HD and UAS. hungersetup.zip
It's definitely an int in the base file, and menudef should also be the same for while now. If there's a mismatch then somehow someone is loading an old version.
After looking over the code, it seems the desync is possibly this line: https://github.com/caligari87/Ugly-as-Sin/blob/5b2400fe666b13d4a5973c1ad777900f23254606/hunger/module/hunger_tracker.zsc#L111 It's checking the consoleplayer's cvar instead of the owner's, which means the hunger RNG is likely getting out of sync when one player trips the condition but the other doesn't. I don't know why I did it this way.
I've pushed a fix attempt in 11fe71d2b1486d111dfc8f32441858e09e3b3e37 but can't test it right now. If you get a chance before I do, let me know if it works.
Seems to have worked. It's not desyncing anymore either in the original save file I had or with the minimalist repro setup. Thanks!
Awesome! I'll close this in a few days if nothing else crops up.
The CVARINFO for the Hunger module changed UaS_HungerGrumbles to an int and added the -1 option, but the CVARINFO in the base package contains the same cvar, still defined as a bool and that seems to take precedence. I'm not completely positive but I think this was causing desyncs (the best we could narrow it down was that eating food was involved, and this stood out to me as a potential problem which we couldn't recreate after correcting the base CVARINFO). The MENUDEF entry also still only supports 0 or 1.