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.
This commit ports the text I found as the introductions to wiki
pages like this http://wiki.wesnoth.org/Drakes into the in-game
help, preserving the links to race descriptions and eras.
This moves the after the fall schedule into core to grant that the
debian package wesnoth-editor does not depend on wesnoth-utbs.
Also, the images now life in their own subdirectories.
Wmllint has been updated to take care about the changed paths.
