If you try to move straight into the water, the explorer should stop at the
lake edge and comment about where they're going. Trivial change, mainly because
I was using a fast unit for debugging and wondered why I hadn't triggered the
lake monsters.
This is motivated by reorganising the help pages to split the Quenoth from the
"pointy ears, pale skin" help text in data/core/units.cfg. It also means that
there's no reason to [hide_help] for the default era elvish units. The new help
text is just a short placeholder for now.
The new race has [race]help_taxonomy=elf.
If the player loads a mid-campaign save then their recalls and heroes will have
race=elf while new recruits have race=quenoth. For that reason, I've changed
the scenarios' event triggers to recognise both races.
When levelling up, units with race=elf may change to race=quenoth.
Opening the help for a unit will show the help as if the unit has race=quenoth,
even when right-clicking on a race=elf unit. This is good.
For a few of these, I think another race might be better - they're converted to
Quenoth here, as they were Elves before. The Corrupted Elf is should probably be
considered undead, and the Divine Avatar should possibly be something else, more
like an elemental than a living creature. That those two are currently included
in the elves does have the side-effect of hiding a plot spoiler about the Dark
Assassin who is also included in the elves (the spoiler being that this one is
correct, he really is an elf).
The code comments talk about both Dunefolk and Quenoth Elves - of these two, only the
Dunefolk's data is changed in this commit. All Quenoth unit are race=elf at the moment,
I intend to add [race]id=quenoth in a separate PR.
Draft documentation for the Wiki:
* '''help_taxonomy''': {{DevFeature1.15|?}} in the help browser, show this
race as a group of units from another race; the value of this attribute should
be the other race's '''id''' attribute. This only affects the help browser, for
all other purposes (such as WML filters) the two races are completely separate.
How this is visualised in the help browser is a GUI design decision, this attribute
merely tells the engine that the relationship exists.
These 5 scenarios were never completed, so the option to play this branch was
always commented out. However the existence of them has caused extra work for
the translators, and would cause further extra work in tasks roadmapped
for 1.15.x (removal of the ^Uf mushrooms, removal of {MODIFY_UNIT}).
If it comes back then it will likely start as UMC.
* Attempt to resolve spelling errors and other phrases which didn't make complete sense.
* Replace apostrophes in user-visible strings with typographical equivalent.
* Revised WoCopedia Help based on clarification from @gfgtdf.
* Unify use of 'OK' in dialogues and remove use of 'okay' in prose.
* Remove some 'modern' language usage such as 'guys'.
[ci skip]
this refactors the lua gui2 callback c++ implementation
Now the callback infrastructure also supports different
types of callbacks for a single widget. Furthermore
it also supports multiple open gui2 dialogs at the same time.
This now also makes the widget parameter of widget.find
manditory.
lua now has a widget userdata that can be used
to set/get widgets properties as one would
expect, a lot of the set/get_dialog_xy function
were converted into modifiable properties of
the widget userdata. This in particular allows
us to get rid of the strange 'path to widget'
type of arguments of gui2 functions.
It currently generates lot of compiler wanrings,
I will fix this in a later commit.
One of the main advantage is that it makes it
much easier to add new api, previously a lot
of functions where overused, probably because
that was just easier than creatign a new
function. For example set_dialog_value returned
multiple value of listbox objects. (the
compatibility path doesn't support this
particular feature yet but i don't think it is
important, it probably wasn't even used at all,
since it also wasn't documented).
This also adds some new features, like an 'add_item'
function to add an item to a listbox, a 'type'
property of widgets to query the type of a
widget and a 'item_count' property to count the
number of children in an item.
Im still not 100% sure about the
property /function names, in particular:
1) i might rename 'items' to 'elements' or
'children' in some functions. Not sure yet
2) I might rename the 'value' property to
'value_compat' to make clear that its only
supposed to be used by the
backwards_compat.lua code.
A next step in improving this api might be
to introduce a (reusable!) 'window' userdata
so that the implementaion of wesnoth.show_dialog
would become:
```
function wesnoth.show_dialog(wml, preshow, postshow)
local dialog = gui.create_dialog(wml)
preshow(dialog)
local res = dialog:show()
postshow(dialog)
return res
end
```
However this is currently not really possble
since the pure existance of a gui2::window
object blocks the gui1 code (the main game view)
from receiving events. So we clearly cannot luas
gc take ownership of gui2::window objects.
This scenario is not guaranteed to take place.
If the player wouldn't play it, he wouldn't lose 60% of his gold.
The enemies give up to 248 XP, but the players units mightt also
have already reached Level 3. (There's no keep, only preselected loyals)
[ci skip]
They were supposed to be unlocked by a die event,
but it never happened because [store_unit]kill=yes
removed the unit in it's last breath event.
Refactor the handling of that.
[ci skip]
In some cases, players can see the obectives already earlier
by pressing CTRL + J. E.g. when the game scrolls to a unit
for a [message]. If the objectives aren't set at that time,
then the default objectives are displayed (kill all enemy leaders).
Because the code uses boolean_equals instead of equals it's not
anymore dependent of other variables being set beforehand.
[ci skip]
closes#1149
The difficulty slider is in fact the gold setting.
bob_the_mighty suggest setting it to 75, though for new players 100 might be better.
I think the best we can get from this situation is to have it by default on 100,
but to tell players about changing the gold setting if the scenario becomes too easy for them.
[ci skip]
For side 3: additional upkeep costs are
1 / 2 / 4
Try to compensate by increasing upkeep by
0 / 0 / 1
For side 2: additional upkeep costs are
2 / 5 / 6
Try to compensate by increasing upkeep by
0 / 2 / 2
[ci skip]
