fix: regenerate seed randomization for singleplayer skirmish when restarting match

[ViTeXFTW]

Description

This PR changes when new seeds are generated for the randomization of events in maps. Specifically focused around singleplayer.

Before this change when using random triggers in maps, the seed would be reused if the user restarted the mission using the quit menu. For maps that use random triggers this ruins the emergence and time invested by the mapper for a dynamic feel in the map.

Old Behavior

Showcase_Original.mp4

New Behavior

Showcase_Fixed.mp4

Map used for testing:
ShellMapMD.zip

Todo

• Replicate In Generals

[greptile-apps]

Greptile Summary

Changed random seed initialization to generate fresh seeds for singleplayer mission restarts and shell map initialization, preventing predictable random event sequences.

Key Changes:

• QuitMenu.cpp: Added conditional logic to generate new random seed using GameLogicRandomValue() when restarting singleplayer missions, while preserving deterministic seed for multiplayer
• Shell.cpp: Changed shell map initialization from fixed seed (0) to random seed using GameClientRandomValue()

Minor Issues:

• Typo in comment (duplicate "a new")
• Commented-out code remains present

Confidence Score: 4/5

• This PR is safe to merge with only a minor typo needing correction
• The logic changes correctly address the stated issue of predictable random events in singleplayer mission restarts. The implementation properly uses conditional logic to preserve multiplayer determinism while adding randomness to singleplayer. Only a trivial typo and pre-existing commented-out code prevent a perfect score.
• No files require special attention; the typo in QuitMenu.cpp line 247 is trivial to fix

Important Files Changed

Filename	Overview
GeneralsMD/Code/GameEngine/Source/GameClient/GUI/GUICallbacks/Menus/QuitMenu.cpp	Added conditional random seed generation for singleplayer mission restarts; minor typo in comment and commented-out code remain
GeneralsMD/Code/GameEngine/Source/GameClient/GUI/Shell/Shell.cpp	Changed shell map initialization to use random seed instead of fixed 0; clean implementation

_{Last reviewed commit: 3034789}

[greptile-apps]

_{3 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

GeneralsMD/Code/GameEngine/Source/GameClient/GUI/GUICallbacks/Menus/QuitMenu.cpp, line 206
Comment is now incorrect - code generates new random seed instead of reusing previous seed. The seed variable is also unused.

[stephanmeesters]

Can you explain how this relates to #2270 ?

Do the changes made here impact replays which require a correct restored seed?

Randomization in the shell map seems fun

[ViTeXFTW]

I will make this a draft as I hadn't updated my local fork which introduced the changes mentioned in the PR above.

[ViTeXFTW]

@greptileai

[greptile-apps]

Additional Comments (1)

GeneralsMD/Code/GameEngine/Source/GameClient/GUI/GUICallbacks/Menus/QuitMenu.cpp, line 247
Typo: duplicate "a new" in comment

		// TheSuperHackers @bugfix ViTeXFTW 26/02/26 Generate a new seed value if we are in a singleplayer match

[ViTeXFTW]

Can you explain how this relates to #2270 ?

Do the changes made here impact replays which require a correct restored seed?

This change tries to do a bit of the oppisite of what that PR did as when you are playing mission maps you would potentially want your seed to be regenerated when restarting maps to make random events "random".

I have updated the code now to only regenerate a new seed if the game was a singleplayer game. This will keep the seed for replays and also not touch multiplayer seeds as they should be consistent.

[Caball009]

The change in restartMissionMenu also affects campaign and challenge modes, and those should not use a random seed because they should always behave the same way.

As for the showShellMap change, I suppose that should work, but in practice that's virtually always the same value for a few restarts. Perhaps that's because the initial time seed is almost the same for restarts. You could increase randomness by seeding more than once, if your random value happens so early in the game like with this map.

[ViTeXFTW]

As for the showShellMap change, I suppose that should work, but in practice that's virtually always the same value for a few restarts. Perhaps that's because the initial time seed is almost the same for restarts.

Could we add a new random function behind the retail compatible flag which is "more" random and doesn't use this weird bit shift, multiplication, division, old setup.

[ViTeXFTW]

This is a very hands-on handling of the Generals challenge issue but should work as they all have prefixes. The same can be done for mission maps. But that can interferre with custom maps if they decide to name their map something similar.

Suggested change

	if (gameMode == GAME_SINGLE_PLAYER) {
	if (gameMode == GAME_SINGLE_PLAYER && !mapName.startsWith("GC_")) {

[Caball009]

Looks brittle and doesn't work for campaign maps.

[ViTeXFTW]

Campaign maps can be filtered with !mapName.startsWith("MD_");, but i agree this is a brittle solution

[Caball009]

I think it's worth asking if single player maps should have scripted run-to-run variance at all. The code doesn't support that currently, though we could change that probably, but I don't know if it's even desirable.

[ViTeXFTW]

I think it's worth asking if single player maps should have scripted run-to-run variance at all. The code doesn't support that currently, though we could change that probably, but I don't know if it's even desirable.

I would only assume that it is intended to have it as WorldBuilder has scripts which set timers and counters between 2 values. But I agree that it is mostly (if not only) for single player / mission maps. But for above average mission maps it is a powerfull feature to have.

In theory the code already supports it as when you load a map from fresh it will update the seed (just not that quickly) but expecting players to quit and then re-launch the map instead of using the restart button is just not feasable.