#2963 closed enhancement (fixed)
[PATCH] Preserve game settings after launching/canceling a game
Reported by: | Alex | Owned by: | leper |
---|---|---|---|
Priority: | Should Have | Milestone: | Alpha 18 |
Component: | Multiplayer lobby | Keywords: | gamesettings |
Cc: | Patch: |
Description
Just had this annoying experience where I wanted to play the same map again and therefore had to set up all the game settings a second time.
Time to get this patched away.
Note: In the patch I've appended, player settings are preserved as well, so I don't exactly know how this will interfere with multiplayer games. Gonna test it out soon.
I hope it's acceptable to store all settings in a JSONized string in the user config - if any part of the settings naming 'API' should be changed in the future, it's rather no problem then.
Attachments (3)
Change History (28)
comment:2 by , 9 years ago
I have a questions This one need custom build to work? I wanna test as user .
Pd give the tag "review" for Dev can give a review for it. Thank you
comment:3 by , 9 years ago
No, you don't have to build the entire game on your own. Instead:
- Just search for a 'public.zip' in your game folders,
- open it using any zip tool,
- head to binaries/data/mods/public/gui/gamesetup/gamesetup.js
- extract it to have a backup of it
- duplicate the gamesetup.js backup, this is the one that gets modified now
- replace the lines with those given by the patch
- put the modified gamesetup.js back into the zip
- Start 0ad
Please do keep in mind that this is a first version that should cause misbehaviour when switching between single/multiplayer lobbies. Still, just try it out, you still have the backed-up gamesetup.js :)
comment:4 by , 9 years ago
Keywords: | review added |
---|
comment:5 by , 9 years ago
So, I pretty much got it working now.
1) Also, things like the AISeed shouldn't be persisted. Done. Also, the MatchId is regenerated as well.
2) Perhaps it would be the best to manually remove these fields from the object. Then, the object had to be cloned though. Not necessary because they will become overwritten anyway.
3) I don't know whether cancelSetup() in gamesetup.js gets called for multiplayer lobbies, too. Works properly. gamesetup_mp.js is an entirely different thing (where I originally assumed it somehow inherited code from gamesetup.js).
4) Would it make even more sense to split up into single/multiplayer-settings? Yes, thinking of campaign or multiplayer/singleplayer-only maps.
5) Just checked the behaviour of scenarios where civs are fixed, then after reloading, this setting confuses the UI logic etc. - perhaps omitting the entire player settings part from the settings might help there a lot - or just persist AI difficulties. This part has been solved as well now, at least entirely for singleplayer. It's still required to check the behaviour when there are other real players logged in.
Furthermore, how to protect the settings against corruption? Try to hide this JSONized part from the config? Enforce proper semantics checks? Build up a custom settings data object that stores only 'visible' information, so e.g. no map meta info or AI-internal things?
comment:6 by , 9 years ago
Okay, just tested said multiplayer case. All slots that are filled with real players will be 'unassigned' after hosting an other game. I think that this is somewhat acceptable - I probably could fill these slots with AIs again though.
comment:7 by , 9 years ago
Component: | UI & Simulation → Multiplayer lobby |
---|
by , 9 years ago
Attachment: | preserveGameAttributes.patch added |
---|
Map reselection works now. It's still needed to test multiplayer behaviour.
comment:8 by , 9 years ago
I'm not sure saving the *.json file in the public.zip is a good idea. Maybe save it in the user.cfg instead ? Or create a preference file in that folder ?
comment:9 by , 9 years ago
Because WriteJSONFile uses pyrogenesis' vfs-infrastructure to write files, the relative path 'config/matchsettings.json' means it gets written into the user.cfg-directory, not somewhere in the 0ad binaries :)
comment:10 by , 9 years ago
There was discussion in the irc whether the settings shall be saved only during runtime, so not after the game was shut down and restarted.
Why I think that this is a bad idea:
- When you play in multiplayer (mp), you won't always host, but when you host, all your settings you entered sometime earlier will likely be gone.
- From my experience, I only do one, two games per 0ad runtime, so it's then as awful as before to have to set up everything again.
- All Age of Empires episodes save settings, too.
- In the rare case that a default map (or other values) changes, gamers who've been playing 0ad will change the map to their needs anyway.
- Invalid values will be ignored because they won't get found by indexOf().
- I'd put in my custom mod that persists these settings inter-runtime anyway, so screw others' decisions :P
- It's way faster for map devs to check and test their maps as they don't have to reselect it each game start.
comment:11 by , 9 years ago
Dev's usually use quickstart for that purpose. (CommandLine Option) that's why they probably don't see the utility. I don't really think it matters to save the multiplayer stuff though. Because most of the guys don't play everyday with each other. (However saving the current data might be a good idea, ie : player joining 3 player game making the host change map and therefore lose all the settings.
BTW, since you are at saving stuff could you have a look at #1580 ? This is a feature I'd really like to have, and that will need to be saved if it gets in the game.
Stan.
comment:12 by , 9 years ago
In my relative long RTS experience, saving those details (even if it's only about fixed teams and revealed map by default) is essential to me. Still, you'd definitely want to preserve all settings between matches, otherwise it's bothering me enormously.
Having colors added later on will unlikely interfere with this feature, as the entire gameattribute object is getting dumped into the json.
Right now I'm adding a reset button so you can reset all the settings to the given default - although I don't know why some people are frightened of not having defaults in their settings.
follow-up: 14 comment:13 by , 9 years ago
What about adding a gameplay tab to options menu with these settings, rather than automatically save the last used as a default?
comment:14 by , 9 years ago
comment:15 by , 9 years ago
No, not gonna do this. I'm happy with just let it silently work for me.
I'm furthermore not sure whether this reset button is really needed. I mean, what's so bad about having settings from the lastly hosted game in multiplayer?
comment:16 by , 9 years ago
(Following from some discussion/opinion gathering on irc yesterday)
Persisiting it across restarts is fine, but I'd like to see a way to clear that (somewhere in the settings dialog probably).
comment:17 by , 9 years ago
Alright, added an extra option where you can disable saving those settings. Disabling the option also deletes the matchsettings.json file (despite the actual removal happens when leaving a gamelobby)
by , 9 years ago
Attachment: | preserveGameAttributes.2.patch added |
---|
Implemented a WriteJSONFile method to let it dump the settings directly into .json files
by , 9 years ago
Attachment: | saveStuff.patch added |
---|
Fixed not having random civs anymore after launching a game with previously saved settings
comment:20 by , 9 years ago
Keywords: | review added |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
comment:23 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:24 by , 8 years ago
Keywords: | review removed |
---|
Also, things like the AISeed shouldn't be persisted. Perhaps it would be the best to manually remove these fields from the object. Then, the object had to be cloned though.