If we need to assign a new nation while a nation set restriction is in force,
and there are none left within the set (even conflicting ones), permanently
remove the restrictions.

Second part of gna patch #3449.

(Browse SVN revision 21665)

> Does it work similar to available nations limit in that civil
> war just never happen when all nations are already in use?

No; for 2.4, with file #16237 applied, then the sixth civil war will cause the restriction to be limited and a non-core nation will appear.

For the proposed long-term solution for 2.5+ (patch #3448), it would behave as you say.

Attached patch on top of what's already committed causes pick_a_nation() to disable restrictions and retry, if out of nations and a restriction is in place.

This is a temporary approach for S2_4. For the proper implementation in 2.5 (patch #3448), the size of the chosen nation set should determine an equivalent of playable_nations, such that attempts to create nations beyond the limit imposed by the set (via aifill, network connections etc) are rejected, so the issue doesn't arise.

(If anyone's worried what else might come out of the woodwork with this late change: if it turn out to be unusable, we can always stop using it in 2.4 with no harm done, and take the time to get it right in 2.5. So I plan to press on.)

(file #16237)

Add an optional concept of "nation set" to the ruleset.
If only nations within a set are picked by players in pregame, no others
will be automatically assigned during the game.
Designed to support a "core" group of nations for translators to focus on.

See gna patch #3449.

(Browse SVN revision 21642)

> (At least in the SDL client.)

I meant Gtk. Nation groups aren't currently used in the SDL client.

The design in patch #3448 requires network protocol changes and a chunk of work. Here's a cut-down proposal to sneak into 2.4.x.

Not tried actually coding this up yet, so details may change.

Proposal:

Include the "nation set" definition syntax for nations.ruleset [nset_XXX] from patch #3448.
However, unlike 2.5, it won't be mandatory to have any nation sets.
(This is an optional ruleset format extension. If we're going to do this, it must thus go in for 2.4.0-beta1.)

Nation sets will behave the same as groups in 2.4.x -- they'll be displayed alongside nation groups, there's no new UI, the client is unchanged.
(For expediency the order of groups vs sets will be fixed: sets then groups. This is not as flexible as it could be, but allows us to make the "Core" group the default group.)

The only difference is that, at game start time, we'll go through the explicitly-picked player nations and calculate the union of nation sets they belong to; belonging to no nation set counts as belonging to a notional "all" set.
Then we'll take all nations not in that union set out of consideration, before assigning random nations, and remember that criterion for in-game nation assignment too (e.g. civil war).
(For expediency, this might just add internal "conflicts_with" relationships, which doesn't give an absolute guarantee that the nation will never be used, but is probably good enough.)

If there are no explicitly-picked nations, we'll use the first defined nation set for restrictions, or no restrictions if no sets defined.

This should allow us to usefully define a "core" set in the supplied rulesets, while not impacting any other rulesets that don't use our nation set.

Effects:

• Players see the "Core" set by default in the "pick nation" UI; if none of them choose another group tab, only nations from that set will be used in the game.
  • (At least in the SDL client.)
• Games where no players pick nations will again use nations only from the "Core" set.
• Unfortunately there's no way to tell the server that you want a completely random nation selection from the "extended" set. So no more games where the world spontaneously consists entirely of Dryads, Hackers, Martians, Ozites, and Vampires -- someone will have to pick a nation. (The 2.5 design won't suffer from this.)