The key word of course being "start". This PR changes the editor by default to work at the add-on level instead of in its own separate scenarios and maps directories. The goal is to make the editor more useful generally, but also specifically to make it much easier for players to distribute content they create using the editor:
* When they click the Editor button on the main menu, they will first be prompted to choose an add-on (or mainline), or to create a new add-on.
* When saved, if the scenario cfg is in the format previously generated by the editor, it will be converted to the new format and to use the [multiplayer] tag, the map_file attribute, and have the map data saved to a separate .map file.
* Relatedly, the editor now knows how to handle scenarios with the map_file attribute at all (which yes, does mean that currently wesnoth's editor doesn't know how to load its own mainline scenarios from their cfg).
* When opening the file chooser dialog, it now defaults to their selected add-on's directory.
If they choose to create a new add-on, then the editor creates for them:
* a basic but functional _main.cfg.
* an empty achievements.cfg (at this point mostly just so they might see it at some point and realize achievements exist, but ideally an achievements editor dialog could be created eventually).
* an empty _server.pbl file.
* a proper add-on directory structure containing the standard set of folders (maps/, scenarios/, units/, utils/, images/, etc).
Additionally, as an initial proof of concept for actually using this new add-on level functionality, a new Add-ons dropdown has been added to the editor's top bar, with a pbl editor option. This allows populating the blank _server.pbl file as well as editing an existing _server.pbl. There is also an option to change the add-on's ID, which will update the add-on's folder name and _main.cfg.
Misc other changes:
* The ability to add a recruit list to a side has been added back as a text box on the edit side dialog. While admittedly this doesn't allow players to select units from within the editor itself, it does set the actual side's recruit list (rather than a specific unit's extra_recruits), will show the user what the current recruit list for the side is (which the previously removed implementation didn't show anywhere), and correctly sets the faction as Custom so that the recruit list is used.
* When saving an old-style editor scenario, everything that can be triggered via [event] is either moved to a start event with a specific id attribute. Exceptions to this are [time], [side], and [side][village]. This is done so that the editor can know (for the most part) what things are actually its own to safely replace. As such, aside from the three previously mentioned tags plus the start event, any other WML added to a scenario by a UMC author is preserved rather than being overwritten - the editor no longer replaces the entire contents of the scenario file.
* The editor no longer writes out cfg files missing the top level scenario tag. If it doesn't find one or this is the first save of a new scenario it defaults to [multiplayer], but otherwise it will properly handle finding [test] or [scenario] as well.
* Requires that map files have the .map extension and scenario files have the .cfg extension. Also it assumes that .map files do actually only have map data in them and the .cfg files do actually have valid WML in them. I understand that this is not a limitation it had previously, but I don't think this is an unreasonable thing to require.
* Addresses part of #7667 by just not using regex for figuring out the map_data attribute value.
Additionally, it is not possible to change the currently selected add-on without going back to the main menu, clicking the editor button, and choosing a different add-on. This is intentional - I don't want to deal with having multiple add-ons open at the same time. If someone feels really strongly otherwise, then they can implement that themselves later.
Previously the config class had an operator bool and
it was a common pattern to use if(const config& = cfg.child(..)).
While this pattern was nice to use. It has severe drawbacks, in
particular it was unclear whether a function that took a config&
parameter allowed "invalid" configs, while most functions
did not, there were some that did. Furtheremore it lead to a few
buggy codes that were unconvered by this change (Not fixed though!),
in particular codes that tested local config objects that were
not references to being invalid, which could never be the case.
This commits replaces those with just `true` in order to not
change behaviour.
Some obvious cases were also removed including for example
things like `assert(config());` There is ony case in the ai code
that i'm not 100% sure of where one implementation of a virtual
function checked for an invalid config and another one that didn't.
With this, all code that check for a config child to be
present now uses config::optional_child which returns an object
that behaves similar to optional<(const) config&>, so it throws
on invalid dereferencing. But it also has operator[string] for
convinience, in particular to make is similary
easy to use the the previous `if (config& = .. child())`.
Also it has a tool DEBUG_CONFIG which tests whether all
optional_config values are checked before they are derefereneced.
Another method manditory_child was
added that throws when the key is not found, which replaces all
occurances of child() that did not check whether the result was
valid. This was neccecary (this= adding a new method instead of
renaming .child) to keep track of converted changes, and be sure
no occurances of child() were accidentally changed to the
throwing version.
We might want to rename one of mandatory_child or optional_child
to just child later. Not sure which one yet. I think it's better
to keep it in the current state (no config::child() ) for a while
though, so that people that currently used child() in their open
prs or other work get an error and not wrongly rely on the previous
behviour of config::child.
The interface of vconfig was not changed in this commit.
CONTROLLER is now defined in a single small header that can be easily read without needing to look through a bunch of Boost macros to figure out how it all works. Using the string values of the enum is now also much simpler since they're just constants of the side_controller class.
This additionally:
* Makes all copyright notices identical aside from the starting year for Wesnoth-specific source files. Files not included: mariadbpp, lua, spirit po, xbrz, and bcrypt (crypt_blowfish).
* Removes all attribution from the files, since the vast majority of them are outdated or seemingly just outright incorrect. For example, I would guess that Dave is no longer the sole author of the majority of Wesnoth's current code.
- place_shroud and remove_shroud no longer accept a shroud data string or the special string "all"
- new functions are added to convert between lists of locations and shroud data strings
- place_fog, remove_fog, is_fogged, and is_shrouded aren't changed, only moved
* Removed more unnecessary includes
* Used std::swap instead of boost::swap in fake_unit_ptr. This is since unit_ptr (the type of `unit_` here)
is now just a shared_ptr instead of a boost::intrusive_ptr.
* Used std::gcd instead of boost::integer::gcd
Hopefully this will fix issues in Game Stats where the teamname was displayed as "teamname^South",
for example. I think the reason it appears that way has to do with translatable strings not being
transmitted properly...
This is the same method used in connect_engine.
There's no AI manager in the editor (a game state is required), nor a need for one, so I simply
disabled the AI initialization if we're not in the editor.
Fixes#2372.
It turned out that the AI kept dangling references to the old Lua state,
and crashed while destroying AI contexts for destroyed sides.
The best way to avoid it is to ensure that game_state, which already owns
the Lua state, also owns the AI. That way, the AI will be destroyed before
the Lua state and a dangling reference can't stay.
Also contains a minor fixup of db8891fa3c03 (sign type mismatch warning fix).
For some reason, the use of the side-1 fallback in the to_unsigned() calls was making every
side get assigned the color red... Sadly, this means an saved games created in the past 12
hours or so have broken color data. Oh well.
These changes cover areas from PR #2101, excluding the removal of the numeric ID color ranges.
That can't be done yet (it breaks things).
This also excludes any changes to the connect_engine color handling. That needs to be refactored
separately. Despite the fact that it's done very similar to the new get_side_color_id function,
I need to deal with the fact that every side_engine member in the connect engine keeps a copy of
the default color options.
* Added a general-purpose function to extract color data from a config.
* Refactored the team class's general get-side's-color-data function so it always returns a color
ID instead of falling back on a number.
* Deployed this change for the leader image coloring in the save_index; said coloring is now always
done by ID.
* Save color data by ID in team_info instead of using the side number if no color was provided.
* Renamed get_side_color_index to get_side_color_id to better reflect its purpose.
this adds a new tag [cancel_action], it currently only has an effect in
move actions. It can be used in enter_hex/exit_hex events to abort the
current movement. It can also be used in moveto events where is
cancels possible following attacks (if the user issued a move+attack
action).
This also changes the behaviour of moveto and enter/exit_hex event so
that they now no longer cancel the movement automatically, also
[allow_undo] no longer has an effect on whether the move is cancelled,
it now only allows undoing of the move.
