Add "CustomMissionID" for saved games

[chaserli]

Implemented the updated requirements of issue #18

[SadPencil]

Sorry, but I'm a bit confused. Are there any unclear passages in issue #18?

[chaserli]

Sorry, but I'm a bit confused. Are there any unclear passages in issue #18?

I just noticed the additional message on the issue page, sorry.
So far I introduced 4 consecutive int32, indicating the CampaignID, total House count present, total Techno count present, total Anim count present, just for testing.

I'm not sure if the ScenarioNumber is eventually unused when the spawner is present, and since we can actually append more extra info on the file, why not recording more.

So far if you can manage the previous 4 bytes (int32) of the member Spawner MetaInfo, then you can set [Settings]CampaignID in spawn.ini to modify it.

[SadPencil]

@chaserli
When loading a saved game and saving the game again, the CampaignID is set to -1 instead of previous value in the .sav file if it is not specified in spawn.ini. Could you make the spawner read this value from .sav file first? (although the client is able to specify this value again, I think it is better to handle this in the spawner; for example users might load another mission inside the game, where the client is unable to interrupt)

Also, could be better if this value is an uint64. I use hash algorithm to generate such an ID so using an 8-byte unsigned integer is better than a signed number.

---

Besides, all the 4 values you introduced for testing work as intended. For the sake of ABI compatibility, could you just save the campaign ID (uint64) in an separate OLE key "Campaign ID"?

[chaserli]

yeah I'm aware of such issue. There's another problem: when finishing the current mission and proceeding to the next one, such ID should change according to your requirement, but I have no idea how to make that happen yet. I'll try to investigate when I have time later

[SadPencil]

@chaserli You are right. pINI->ReadInteger does not support reading uint64 so I guess I have to use int32

[chaserli]

@chaserli You are right. pINI->ReadInteger does not support reading uint64 so I guess I have to use int32

Alright, I reverted that to int. Now Campaign ID appears in sav file only when its value is not 0

[github-actions]

Nightly build for this pull request:

• spawner-c00ad31c4ff0e01422d9c352fc186c1392baffcb.zip
• spawner-CnCNetYR-c00ad31c4ff0e01422d9c352fc186c1392baffcb.zip
  These artifacts will expire in 90 days and will not be available for download after that time.

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

[Starkku]

Took a liberty of making sure it is up-to-date with main and addressing some issues with the parsing of mission info from spawn.ini (including decoupling it from custom missions, which has been adjusted in the associated client PR as well).

[SadPencil]

Can this PR be merged or are there any review comments? @Belonit @chaserli

[Starkku]

There's still an issue caused by game seemingly reading some CSF labels/strings on spot instead of using the labels/strings from originally reading the scenario which causes issues with save/load, I will try to look for proper solution to this during the upcoming week.

[Starkku]

There's still an issue caused by game seemingly reading some CSF labels/strings on spot instead of using the labels/strings from originally reading the scenario which causes issues with save/load, I will try to look for proper solution to this during the upcoming week.

Investigated further, this is not worth fixing on game's side due to complexities involved. The current solution of always providing the mission configs in spawn.ini for custom missions is sufficient.

[SadPencil]

Why is this PR marked as a draft? There should be no remaining work to be done and are ready for review

[Metadorius]

care to explain why did you dump the no save mode into an unrelated PR? I was going to say "screw it, merge as is" since multiple authors worked on this one incl. Starkku, but not with hardcore mode (which has some ??? code)

[chaserli]

care to explain why did you dump the no save mode into an unrelated PR? I was going to say "screw it, merge as is" since multiple authors worked on this one incl. Starkku, but not with hardcore mode (which has some ??? code)

It's unfinished, just making a dll for testing then rework this one. I'll handle the commit history issue later.

Are you going to merge the custom mission part this year or next year? I didn't expect such swift reaction. I suggest reviewing #20 first. Then I'll split things

The no-save part is not unrelated. If I draft another PR it will build on top of this one, it will be harder to manage

[Metadorius]

make a branch on top of this one then rebase

I figured since Starkku took over there's no reason to leave it gathering dust, so screw it, merge it is

[chaserli]

I figured since Starkku took over there's no reason to leave it gathering dust, so screw it, merge it is

@Belonit Is there any issue at this point?
@Starkku Anything else you want to add or check?

[CnCRAZER]

What's the use case for this proposed pr?

[SadPencil]

What's the use case for this proposed pr?

See #18 and CnCNet/xna-cncnet-client#518

[Starkku]

Don't think there's anything that needs to be addressed or changed at this time. It works in conjunction with the client changes. If issues crop up further down the line they can be dealt with separately then.