This fixes the default implementations of widget's copy constructor and copy
assignment, which was root cause of the regression in 4139b43cc900 (#4215).
This reverts commit f46ed66f2c9a8acf8d88338d8433fc35689d4c39.
This requires three more tables to be added to any database with the forum user handler enabled, the structures of which are defined in the wesnothd man page:
* `db_game_info_table` - stores information about each game.
* `db_game_player_info_table` - stores information about each player in the game.
* `db_game_modification_info_table` - stores information about any modifications that are enabled for the game.
This fixes the buttons in the editor's terrain palette being unselectable. Since the gui::widget class
had a virtual base class, the class was not trivially copy-constructable. We need to explicitly define
the copy constructor so we can initialize the sdl_handler base class.
Possible fix for #4058, with the following logic:
* If non-empty, [unit]overlay= is handled by adding modifications
* unit::write will always output an empty overlay=
* The Lua API's get_units() will still provide the list of overlays
* [effect]apply_to=overlay can now remove as well as add overlays
* [remove_unit_overlay] is implemented with [effect]apply_to=overlay
Using [object]s with durations hasn't been tested, but expected effects:
* An expired add= followed by a non-expired remove= will simply cause the remove=
to have no effect when std::remove(overlays_ ...) is called.
* A remove= followed by [remove_unit_overlay] cause the [remove_unit_overlay] to be a no-op,
and the overlay will reappear when the first remove= expires. This edge case is already
documented as unsupported on the wiki.
Decided it's better to just tie this to the draw rate. There were problems with the timing on the accelerated_rendering
branch, so I had disabled it there, but I think it's better without the timing so I'll just leave this.
Changelog provided by @ghype below. Additional credits at the end.
=================================================================================================
*Art*
Most of units were reworked - some more some less - but our goal was to make them fit for mainline all together.
If any changes are needed to any unit, then we gladly execute those. There have been months worth of progress
documented in the according art thread for this project.
Base Units: https://forums.wesnoth.org/viewtopic.php?f=9&t=49075
Extra Units: https://forums.wesnoth.org/viewtopic.php?f=9&t=49625
*Balance*
The main reason why this project started in the first place. Here as well we have all the progress for balancing
Dunefolk documented and all developers and users interested in this project and seemed to agree on the current
state of balance. Thats the reason why we will not enlist all the changes here. If there are any problems with
the balance, then we too are willing to provide alternatives that can be discussed either here or on forum.
Balance Thread: https://forums.wesnoth.org/viewtopic.php?f=15&t=49627
*Alignment*
The balance of this faction was based on the newly proposed liminal alignment which works as +0/+0/+25/+0/+0/+25
instead of the old -25/-25/+0/-25/-25/+0
*Weapon Portraits*
As Dunefolk features entirely new units, we found some weapon portraits that fits the attacks of certain units.
The portrait - called „blade-curved“ is a franken but a convincing one. As the current blow pipe for UtbS is a
franken as well, this new weapon portrait should good enough to be mainlined as well. If this request get’s denied,
then we are free to provide alternatives as well. It just fits very well the theme of exotic Naga weapon
craftsmanship without relying on the orcish theme. It used for the following two units:
Lv2 Naga Bladewhirler
Lv3 Naga Dervish
*Descriptions*
New unit concepts require changes and new units require entirely new descriptions. We enlisted all problems and
inconsistencies that resulted with the rework and provided either solutions for them or new descriptions. Yumi
already started doing them but for those who want to see the initial conflicts, here you can find all the problems
displayed:
Unit Descriptions: https://forums.wesnoth.org/viewtopic.php?f=32&t=49867#p642698
*Female Dunefolk Names*
With the introduction of female units to this faction, we would require female names as well. Apparently this was
already coded in mainline, but simple not used.
*Future Plans - Animations*
There are some recourses from past works that allow us to - more or less - easily animate most of Dunefolk units.
The animations range from idle to attack-only, while other units will be fully animated. Some of the units that
are harder to animate will first receive single attack/defend frames until animation concepts were agreed upon.
Our goal is to make Dunefolk as alive as possible.
*Future Plans - Theme, Sound FX*
Rather unimportant to most people but I am interested to add some new sound fx that can start with different hit/death
sounds or new weapon sounds for scimitars. Those are just example and I do not know what I will end up with. But I know
that I will compose a Dunefolk Theme at some point. Using your feedback, I am sure I can manage to create something that
fits the faction the best.
*Future Plans - Wyvern Rider*
This is the only unit is the only one that did not get touched or reworked. The wyvern on it self looks amazing an does
not need any rework but the rider does not really fit thematically anymore, not to mention the weapon is too oversized
and not the usual Wesnoth style. But I won’t touch this sprite until it actually will be needed, most likely - IF -
there is ever going to be a mainline Dunefolk campaign.
*Credits*
I don’t know how detailed you need this to be but here all contributors.
ghype, Hejnewar, Krogen, The_Gnat, Lordlewis, EarthCake, Tom_Of_Wesnoth
It is however important to mention that the amount of contributions of each varies a lot in different categories. I will
organise it a bit and you make use of this info how ever you want. The names are in order of the amount of work put in.
Art: ghype, The_Gnat, Lordlewis
Balance: Hejnewar, Krogen, ghype, The_Gnat
Descriptions: Tom_Of_Wesnoth, Hejnewar
Earthcake joined us in the end and helped us finishing this project by cleaning/finishing the codes and doing all the git
stuff together with The_Gnat. Although none of his work can be categorised in one of the three categories, he still deserves
to be credit in one way or another.
Thanks for your time and efforts.
The old copy-assignment code would have appended the topics and sections
without clearing those lists, while the new code does clear them. However, the
copy-assignment is only called after calling clear(), so this doesn't affect
the behavior.
An exception was getting thrown during the handshake process that wasn't properly being thrown.
Since poll() only ran during the handshake, I've moved the handling in that case to wait_for_handshake().
This makes things a bit less confusing by making the worker thread handle the handshake. It also
removes the need for manually spinning the main thread to wait for the handshake.
