Cores are now validated, invalid ones are discarded.
The failsave mechanism now tries to load without add-ons in case of a
fail before it falls back to the default core.
Core definitions are now read from a cores.cfg in every add-ons'
toplevel.
This will be used to switch addons off during runtime.
Used for fallback if loading fails.
Can later be used to give gui controll over loading the addons.
Tested to work with this test scenario, and the mainline defaults:
[label]
x = {X}
y = {Y}
text = {STRING}
[/label]
[multiplayer]
id=lua_map_gen
name= _ "Lua Map Gen Test Scenario"
description= _ "test test test of lua map gen"
map_generation="lua"
[generator]
id="test"
config_name="Test Lua Map Generator"
create_map = << local rng = Rng:create()
print(rng:draw())
print(rng:draw())
print(rng:draw())
local w = 50
local h = 40
map=""
for y=1,h do
local r = rng:draw() % 2
for x=1,w do
if x == 10 and y == 10 then
map = map .. " 1 "
end
if x == (w-10) and y == (h-10) then
map = map .. " 2 "
end
if ((x + y) % 2) == r then
map = map .. "Gg"
else
map = map .. "Md"
end
if x ~= w then
map = map .. ","
end
end
map = map .. "\n"
end
return map
>>
[/generator]
id = foo
random_start_time=yes
{DEFAULT_SCHEDULE}
[event]
name=prestart
{LABEL 25 20 ("Lua map generator")}
[/event]
[side]
[ai]
villages_per_scout=8
[/ai]
id=RBY_Side1
side=1
save_id=RBY_Side1
persistent=yes
color=red
team_name=Red
user_team_name= _ "teamname^Red"
controller=human
canrecruit=yes
shroud=no
fog=no
gold=1000000
[/side]
[side]
[ai]
villages_per_scout=8
[/ai]
id=RBY_Side2
side=2
save_id=RBY_Side2
persistent=yes
color=blue
team_name=Blue
user_team_name= _ "teamname^Blue"
controller=human
canrecruit=yes
shroud=no
fog=no
gold=1000000
[/side]
[/multiplayer]
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.
A similar assertion failure also exists in mp_create I believe.
It's a bit ugly to have to put this in src/game_initialization/
multiplayer.cpp, but probably the best thing if these classes
aren't going to be robust against corner cases like this.
This fixes several bugs in the Lua interpreter:
* http://www.lua.org/bugs.html#5.2.1
* http://www.lua.org/bugs.html#5.2.2
* http://www.lua.org/bugs.html#5.2.3
Released on December 2013, this is the latest stable version as of the
writing of this patch.
This commit consists of a merge of the full diff between versions 5.2.0
and 5.2.3, with paths fixed (.c vs. .cpp). I only had to manually
reconcile the following two commits:
* f5e673e6443220c57e40cea31d430870b4f73925
Replace all kinds of the constant pi representations.
* 299a29f99a84767731dbadd540712d1a37e5e10d
Fix an off-by-one past-the-end buffer read in lua
This partially reverts an earlier commit
28fe7e44
instead of changing the exception type to game::game_error,
(which I assume is meant for in-game errors?), we go back to
game::error which is now handled properly in playcampaign.cpp
and game_launcher.cpp
Tested that this does not reintroduce bug 22611.
I also add one for mapgen_exception, but this doesn't make so much
difference. It seems to be a big problem that we don't catch
game::error anywhere, I observed a similar bug being caused by
game::error being thrown directly by a button when it couldn't
find its image. The report was that it caused the game to crash
to desktop immediately (I think it was caught only in void main.)
