Improved overriding of MultiplayerDialogSettings in custom game modes

Hell yes. I'm making lots of game modes which really require pre-set multiplayer settings. Supported.

Oh, I wouldn't hold my breath for this one... it would require reading the mpmode ini as soon as you select it and go back to the match setup menu. If you go back and select another mode, we'd have to flush the parsed rules + mpmode down the drain and reload rules from scratch, then read the mpmode. It takes some noticeable time to read the rules.

This would also require a loose interpretation of the "default" values specified in RA2md.ini...

In my opinion, it is worth waiting a few seconds in this spot. Another nice addition would be the removal of countries from the drop down list if they are tagged Multiplay=no.

On what grounds do you decide that what the player chose to make his game is wrong?

I am not sure if I understood your question. Decision should be based upon the mpmode.ini, which might contain some changes to the ruledmd.ini, which affect the skirmish/multiplayer UI. But like DCoder foreshadowed, the mpmode.ini currently isn't parsed until the game starts. It's probably being read after the loading screen appears, because changes affecting the loading screen (Country->LoadScreenText.SpecialName e.g.) are ignored, too.

@Renegade:

Game mode in which there are only units available - ShortGame should be off because when player loses the unit specified in BaseUnit he will lose immediately and that's not what I want to happen no-bases mode.

Game mode in which player should be using equipment and buildings provided via map coding (for example something a la C&CRenegade mode or a cooperative) and not the default MCV and Starting Units.

Game mode in which the only unit I want player to have is the base unit. I can't disable starting units and I can't disable starting INFANTRY because the game will crash without such.

Etc.

There's plenty of new modes I'm trying to implement in MO and those changeable multiplayer settings really get in the way sometimes. Control of ShortGame and Starting Units settings is something that would really be useful for custom modes which change more than tech locks etc.

Game mode in which there are only units available - ShortGame should be off because when player loses the unit specified in BaseUnit he will lose immediately and that's not what I want to happen no-bases mode.
On what grounds do you decide that what the player chose to make his game is wrong?

Game mode in which player should be using equipment and buildings provided via map coding (for example something a la C&CRenegade mode or a cooperative) and not the default MCV and Starting Units.
If each map has to be individually generated to provide said equipment anyway, what's preventing you from placing the starting points in "definite kill" zones?

Game mode in which the only unit I want player to have is the base unit. I can't disable starting units and I can't disable starting INFANTRY because the game will crash without such.
What's preventing you from making the only starting units useless junk with map-wide suicide weapons?

Either way, while some of these are superficially reasonable examples, the question to answer is "is it worth the effort"?
And, to be frank, I don't think it is.
Take cases like the "no short game" thing - yes, it's sucky if the player starts the game with short game in such a case, but, for one, he should have read the manual, and, for two, it's called "short game" for a reason - he'll notice soon enough, and will probably remember for the future.

Is a little inelegance in such cases really worth completely recoding the when and where of INI-loading and adding constant reloads?

And if bugs happen in this kind of feature, they'll be really annoying...you'll have inconsistent rules states, game modes blurring into each other and debugging will be a pain because you're thinking you chose mode X and there's a bug, when, in reality, the game loaded "mode" A+B.

It's not impossible you can come up with an example that completely requires this "feature" and would be totally awesome.
I'm just not convinced it will be a general enough case to warrant recoding such an integral system and risking the bugs and breakage to come with it.

"On what grounds do you decide that what the player chose to make his game is wrong?"

I think I got what you mean. A player should get the freedom to chose whatever he wants, right? Ok, maybe he is willing to play a game mode with units only as short game... or "crate war" without crates. But these inconsistent settings are mostly done accidently.

I understand the reasons why you don't like this "feature". Right, it's nothing new. This feature isn't essential. You just help players which are are too lazy to use their brains or read the manual. But you could look at it as a bugfix. If game mode X says [YuriCountry]->Multiplay=no, why can I still play with Yuri? Of course, the modder can replace Yuris starting unit with Tanya waving a big flag, which shows "You donkey selected an invalid country." Would be funny... :-) Or let Yuris MCV deploy into a silver screen with the same message. But that's a lot of work, too. And the missetting could have been detected earlier. But I know, I am just repeating my arguments. :-) If you were not convinced before, you won't be convinced now.

I am not concerned about bugs regarding to this issue. They can be detected very early in a game. I would love to find and report them. Bugs, which require specific game situation, look more complicated to me, because it always takes a reasonable amount of time to reprocude them.

Personally, I don't think the time investment needed to make this work and the slowdown it would cause in the UI are worth it.

Frankly the only valid usage cases relate to Unit Count and Credits. The other stuff is wanting to have excessive control over the interface.

I have a deathmatch mode in Star Strike, and being stuck to 15 units makes for a pretty short (but often very interesting) deathmatch. In RA1, selecting no bases increased the unit limit to 50 or something like that.

Rather than have this all defined in the .ini files that control the mode rules that get loaded when you pick one, why not expand the file that list what modes there actually are to allow locking/disabling certain UI controls for those mode. That way the game already knows what you are allowed to vary and what you are not to for each mode.

I agree with DCoder, having the UI read settings from game mdoes is not the way to go. Most of the problems described can be overcome (you don't want Yuri - then make him into a clone of Russia or something in that mode).

Rather, game modes should be made obsolete by the introduction of a whole page of new controls. Primarily I'm thinking checkboxes to include the different game mode INIs in layers, and a config INI so the author can control what checkboxes are displayed, layout, what INIs they include and some basic prerequisite logic on the boxes (A prohibits B, B requires C, etc.)

For things this doesn't solve, like "MaxMoney", it would be easier to just have the game mode cap the starting money once you got into the game, rather than messing with the UI.

Agreeing with Blade to set them up in mpmodesmd.ini

Me too. I didn't take mpmodesmd.ini in account yet. But it's the easier solution.

Marsh: #bug:1438 / #bugnote:8541

Well, personally I think that FreeForAll/Megawealth/Assault/etc make no sense as game modes. These should be toggleable options. Otherwise you have to have FreeForAll, Megawealth, Assault, FreeForAllMegawealth, FreeForAllAssault, FreeForAllMegawealthAssault, MegawealthAssault - just to provide the possible combinations of 3 game modes. Very restrictive IMO. Game modes should be wholly different styles of play, not just the toggling of a couple of units.

If it's a pig to code then fair enough, but I think it solves a lot of issues people have with game modes. I'm not gonna push the issue though if no-one agrees.