HostedRedmine.com has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...
Bug #858204
open
Qt/Gtk clients don't always keep ruleset selection combo box in sync with server ruleset
0%
Description
I loaded a savegame that I knew was created with the sandbox ruleset. In the load game preview, attached, it incorrectly displays default. But it is sandbox rules, as help Current Ruleset shows (also attached).
Files
| qt-ruleset-wrong.png (26.4 KB) qt-ruleset-wrong.png | |||
| help-current-ruleset.png (7.98 KB) help-current-ruleset.png | |||
| 26-ruleset-combo-sync-FAIL.patch (19.3 KB) 26-ruleset-combo-sync-FAIL.patch | Incomplete and doomed 2.6 patch |
Related issues
Updated by Jacob Nevins over 3 years ago
Gtk gets round this by not showing the control at all (since you can't change it).
Updated by Jacob Nevins over 3 years ago
There's a comment acknowledging that the Qt client isn't looking at the name of the currently selected ruleset and hardcodes "default":
void pregame_options::set_rulesets(int num_rulesets, char **rulesets)
{
/* ... */
for (i = 0; i < num_rulesets; i++){
cruleset->addItem(rulesets[i], i);
if (!strcmp("default", rulesets[i])) {
def_idx = i;
}
}
/* HACK: server should tell us the current ruleset. */
cruleset->setCurrentIndex(def_idx);
/* ... */
}
(But client can know the ruleset name.)
This also means that typing a server command like /read or /rulesetdir in the pregame chatline (when not loading a savegame) isn't reflected in the ruleset selection box. (Gtk client suffers this too.)
Updated by Jacob Nevins over 3 years ago
- File 26-ruleset-combo-sync-FAIL.patch 26-ruleset-combo-sync-FAIL.patch added
- Subject changed from Qt client shows wrong ruleset in Load Game preview (2.6.1+) to Qt/Gtk clients don't always keep ruleset selection combo box in sync with server ruleset
- Category set to Client
- Status changed from New to Blocked
- Sprint/Milestone set to 3.1.0
(But client can know the ruleset name.)
No. No, it can't.
As I knew really, ruleset names in the client mean .serv scripts you can /read. But the ruleset name in a savegame is a value for /rulesetdir. They are conventionally the same, but it's not guaranteed. Many .serv script could in principle give the same rulesetdir. So, there's no way to know what to put in the combo box (that is, what
Similarly, the client can't know what .serv file could have led to the currently loaded ruleset. (Except if it told the server to load the .serv file because someone fiddled with the combox box.
(In fact, the client doesn't currently know the rulesetdir either. But it could with a protocol change.)
I don't think this can be sorted out until the messy ruleset name semantics are sorted out.
The obvious thing to do would be make everything be aboutrulesetdir. However, looking at modpacks that exist, I don't think we can quite do that:
- 'variant2.serv' uses the commands
cheatingandcreate "" threadedto control AI defaults. Because AI options are funny special commands rather than regular settings, they can't move to the ruleset. (See #858206 for a long-term plan to do something about that, but not before 3.1.) - (I had a bit set that the 'ancients' modpack didn't follow the convention; but that was cleaned up in 2.5 -- previously it did '/rulesetdir ancients/data' -- and in 2.6, the settings that were in the .serv file moved into the ruleset, so ancients.serv is now the conventional trivial /rulesetdir.)
Attached is a patch for S2_6 that I wrote before I remembered any of that (sigh). It compiles, but does the wrong thing. If the name semantics are ever sorted out, and rulesetdir sent over the network, some GUI stuff can probably be rescued from this patch.
Updated by Jacob Nevins over 3 years ago
- Related to Feature #858206: Turn AI defaults into regular server settings added
.
