* update falcon and raven races to not get names
To conform with other monster units
* units: remove a redundant line of code
from races falcon and raven definitions
At the suggestion of @stevecotton, I propose a special 'replacement_type' and 'alternative_type' attribute capable of modifying the type of attack used when the conditions are met.
Also make Holy water combine arcane damage with native type of weapon
Like holy water imbued ordinary weapon, it's seem logic what arcane damage dominant what if more efficient what original type(water can't altered pierce or blading of spear or sword)
using overwrite_specials alone means that we have only two possibilities, either one_side is chosen and in this case if the ability used as a weapon carrying the attribute is applied to the unit (apply_to=self), the other abilities are the same type applied also to 'self' not carrying the attribute will be overwritten, but those of the opponent with apply_to=opponent will be kept in the list; or else both_sides is chosen and all abilities of the same type that do not carry the attribute will be overwritten. To be able to use the attribute in abilities like [damage] for example, it is necessary to be able to be even more selective as for a 'charge' type leadership with multiply=2.5 but which must not be combined with the classic charge and without overwriting the aute [damage] as backstab, [overwrite_filter] to only match damage with apply_to=both and active_on=offense is then interesting.
adding priority allows you to select that it ability can use its overwrite_specials attribute while the others can be overwritten in the same way as an ability without the attribute. Finally, this system makes it unnecessary to limit the use of the attribute to abilities used as weapons but also to special weapons.
give abilities support of halo or overlay so that the unit benefits from a second halo or overlay when conditions are matched
One of the things that bothers me is the permanent character of the halos of the Mage of Light and other units with the "illuminates" ability, which forces them to program only a permanent illumination applied only to the possessor of the ability.
Adding the halo attribute to ability does not change anything about the behavior of the unit, but can be used in several cases:
1 allowing the use of ""illuminates" whose activity would be variable, in this case encoding the halo in [illuminates] ability and not in the unit_type allows to modulate the appearance of the halo under the same conditions
2. Applying illumination to adjacent units, I know it's pretty cheesy but a set developer might consider it easier if the hlo display follows the same logic.
3 The halo used to illustrate the possession in the unit of a special weapon used as leadership, the halo would be used to raise the possessor of the ability.
for overlay, same logic for illustrate possession of a special weapon used as leadership, or influence on student
with the "halo_image" attribute, it is now possible to give Sun Sylph units an illumination ability with an activity depending on the incarnate sun attack instead of giving the ability and the halo via obect and therefore allowing the player to have access to the description of the ability even when it is inactive.
* EI: revise entire campaign
* Fix indentation
* More indentation fix
* Remove unused projectiles
* Revert "More indentation fix"
This reverts commit b7794ee73d1672b65665015ef50e96d90457f312.
* Rename wesnoth lua pack to items
* Another round of fixes
* wowwee another round of edits
* Address some CI errors
* CI fix attempt no 2
* here comes more
* CI slowly getting fixed
* Fix terrain codes
* So many things to do
* small patch
* more more
* oops
* Split keys onto separate lines
* MORE MORE MORE
* Resolve licensing
* I like to write
* Add blood gore warning
* licensing licensing licensing
* asdkfjasliefjal
* draw draw draw draw pixels pixels
* Update data/campaigns/Eastern_Invasion/scenarios/04b_Ill_Humours.cfg
Co-authored-by: Luis Miguel Iglesias Sánchez <Luis_koopa@hotmail.com>
* Resolve some more licensing issues
* license
---------
Co-authored-by: Luis Miguel Iglesias Sánchez <Luis_koopa@hotmail.com>
* Duplicated text
* Favour generic term 'file manager' over Microsoft terminology.
* Clarify language code use.
* Replace inconsistent spelling of 'add-on'.
The basis for this rework is lowering the extremes in acrance resistances between units and factions. That allows for more free usage of arcane damage and helps with balance of games in which high levels are way more frequent than in standard default 1v1 or 2v2.
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.
