This map generator is used in HttT 17 and SoF 4. which needed to be updated aswell.
With this we finally have a lua generator that is used in mainline and that
can be used an an example by wml authors who want to write other map generators.
Unfortunateley there are still umc add ons in 1.12 that use
scenario_generation=cave so i didn't remove the cpp implementation yet.
According to the Wiki, since 1.13.2 message= is an alias for label=.
Using message= provokes a warning about it being deprecated.
This replaces message= with label= in the entire mainline (where it had not already been changed).
instead of storing the poolypesin savefiles we now have them as 'const'
lua array and store only the indexes to this array in the savefiles.
this has some advantages:
1) It makes the savefiles smaller
2) It simplyfies the lua code becasue we don't have to convert the wml
tables to lua tables anymore.
This also changes the scenario so that the spawned unit types are now
calculated at the beginning (they will be the same when reloading from a
savefile.)
unfortunateley the 'description' (the tooltip of the widget in the mp
configure dialog) doesn't show in current master. This is likeley to be
a bug related to gui internals.
This has multiple advantages:
1) It makes the code easier to understand because we now can use local
variables and return values.
2) It makes the code easier to debug because we don't have to reload the
wml cache anymore for changes to have an effect
3) It makes loading the multiplayer wml faster, specially dark forecasts
wml codes is now so short that we don't need to guard it inside its own
preprocessor marco anymore.
4) It decreases the save file size.
This commit also does other improvements to the code, for example:
1) We don't create temporary units anymore just to query the costs of
a unittype.
2) We now load the weather maps dynamically at runtime with
wesnoth.read_file, this decreased the prorocessor paring time and savefile
size further.
3) When creating the new spawns we use temporary objects to decrease
the units movement, instead of changing and resetting the unit stats
manually.
This also has a disadvantage:
1) It now requires all players to have this scenario installed, since it
it a mainline scenario i see no problems with that.
this adds borders to the 2p dark forecast survival map, it also removes
the big empty space in the upper third of the map.
This also renames the mask files to map files, becasue they are actually
just normal maps, and the [terrain_mask] just replaces the current map
with these.
Previous it couldhappens that create_engines and depcheck::manager s lis
of mods could get out of sync which caused wrong modification to be
active.
Also we add a type= key to [era]s chiech defaults to mp so that only the
default era is avaiable in sp by default (for technical reasons there
must be at least one era avaiable in sp.
Previously faction_from_recruit would search for default_recruit= in
[multiplayer_side]. This commit fixes it so that it seached for
'recruit' ('default recruit' is no attribute of [multiplayer_side]).
This fixed behaviour breaks 'A new land' mp scenario becasue the faction
now gets locked to the mp faction that matches the recruits best
(loyalists), but in ANL we wants custon recruitlist and not Loyalists
recruitlist. To Fix this i removed faction_from_recruit= from 'A new
land's sides.
making 4mp leader automaticly quick is unexpected for a campaigns
designer. And the intention is make it easier to port sp campaigns to
mp.
To do this i ported the quick4 mp leader code to lua.
I also moved the lua code from eras.cfg to a new file eras.lua, this
makes is easier for an editor to detect lua syntax highlichting
automaticly.
For campaigns (sp and mp) which are usually coop campaigns you usually
don't want the turns over advantage message. So we disable it by default
for campaigns. It is still possible to (de-)activate is manually by
setting the wml variable show_turns_over_advantage to yes/no
This only seems to happen when Use Map Settings is enabled. Using
faction_lock in that case forces the "Custom" faction selection, which
offers all possible leaders from all factions and doesn't override the
recruit lists.
faction_from_recruit would limit the faction selection to Loyalists in
1.10, thus ensuring all leaders are Loyalists with Use Map Settings on,
but that doesn't seem to work right now either. It shouldn't matter for
this scenario anyway as long as the recruit lists are the ones defined
here rather than the faction's.
As described in bug report, mp create had a bizarre implementation
for random map vs scenario generation. Scenario generation was called
map generation, and map generation was impossible. We fix it and make
it work like it works in the rest of the game.
At time of writing the wiki describes map generation wml as follows:
```
To use the default [generator] your [scenario] tag must contain one of
the following keys:
scenario_generation=default
map_generation=default
If ‘scenario_generation’ is used, the engine will expect for your entire
[scenario] sub tags to be inside a [scenario] tag inside [generator].
Tags outside of this will be ignored. There may be value in this, but at
this writing, it’s not clear. ‘map_generation=default’ is simpler and
more commonly used. It is also necessary to use this key so that you can
regenerate a map in MP game creation. In its use only generator data is
in the [generator] tag, all other [scenario] data is placed outside of it.
The exception is if you are making an initial MP scenario available in MP
game creation, for this a [scenario] tag must appear inside of
[generator], containing the [scenario] subtags you want to use.
See “data/multiplayer/scenarios/Random_Scenario.cfg” for an example.
```
This commit essentially removes the "exception" pointed out above.
After this, the mp create dialog treats map and scenario generation
both in the "random maps" classification, and it handles them normally,
scenario generation replacing the entire scenario, and map generation
replacing only the map data of the scenario.
