@gfgtdf pointed out that the WML parser can deal with such tags after all.
I had missed that when I implemented the check that the game state is
valid WML before saving it (commit 3bc36efa5898a95ce793195e24b4dee1b546c222).
Such tags are still disallowed in the Lua API because allowing them would
be an API change.
Now content that is loaded via [load_resource] is placed to the position
where the [load_resource] was. This fixes a problem where previously one could
not use lua variables/functions created by the [resource][lua] because the
engine would put the [lua] tags from the [resource] after the [resource] from the
scenario.
This time it uses size_t indicies instad of vector iterators to prevent
possible bugs arisong from invalidating iterators when the size of the
vector changes.
This reverts commit b3e1680f886ec27c29150912bb27949d7cdd7f6e.
In the long run i think it might actually be better to allow [event] and
[lua] to have a order/priority attribute similar to lua on_event events.
Then this commit would probably not be needed anymore.
This reverts commit 706740220957a9313909f5cc358ba5aba3bf4118.
The commit used the `pos` iterator after invalidating
it (passing an iterator to `config::add_child_at()`
invalidates it), resulting in undefined behavior.
Now content that is loaded via [load_resource] is placed to the position
where the [load_resource] was. This fixes a problem where previously one could
not use lua variables/functions created by the [resource][lua] because the
engine would put the [lua] tags from the [resource] after the [resource] from the
scenario.
(cherry-picked from commit 1ac635ec63e775dcd1aa90d04b9adf3f061ef476)
This also covers handling of legacy DescriptionWML for [set_menu_item],
and tweaks its handling in the other cases (mainly [multiplayer_side]).
I added the next_dev_version constant intending to use it, but then
decided not to do so; however I left it in in case someone finds it useful.
This should mean a performance boost when the game config manager processes [units] tags.
Since they're all merged into one, it's very likely whole addon's worth of unit type configs
were being copied (twice)! Worth noting that a lot of addons use the tag amendment syntax
([+units]), but it's unlikely that meant no copying was done at all.
* moved the new function next to valid_id()
* renamed to valid_tag(), and renamed valid_id() to valid_attribute()
* removed unnecessary parentheses I forgot in
* changed the name of valid_id()'s parameter from "id" to "name"
* changed WML parser to use valid_tag() when it validates tag names
Thanks to @CelticMinstrel who told me about config::valid_id().
It turned out that it works fine as long as it's called with a char
rather than unsigned char. (But to add to the confusion, the other
variant of the function in <cctype> *requires* that cast.)
The function seems to just throw std::bad_cast() in libstdc++ and libc++.
Fortunately it's very easy to write our own implementation instead.
Thanks to @Pentarctagon for the stack trace.
The regular append_children function makes a copy of the applicable child tags. This moves them
from the source to the destination configs. Do note it leaves the source tags empty.
[ci skip]
I ran the command used in 9b7b1751fdda, excluding results in lua/ and spirit_po/.
Also, once again, for some reason actions/vision.hpp gets registered as massively changed
(similar to f11fa0652af0) despite nothing really having changed at all.
this has 2 advantages:
1) we can now forwaed declare the class config_attribute_value without
including config.hpp
2) the config.?pp files are a little easier to read.
