* Updated unit descriptions for the Orcish Grunt line
* Updated unit descriptions for the Merman Fighter line
* Updated unit descriptions for the Sergeant, Lieutenant and General
* Updated unit description for the Peasant
* Updated unit description for the Royal Warrior
* Updated unit description for Ancient Lich
* Updated unit description for Dwarvish Steelclad
This isn't a perfect solution, since it still results in bridges drawing "over" caslte walls (except Stone Bridges),
which have special bridge <-> castle transitions). That was one of the reasons for 81659462eb33, but this at least
prevents transitions from bring cut off. All bridges still draw under non-dwarven castles. In order to properly
get this effect with dwarven castles, the dwarven castle <-> chasm transition images would need to be split into
Castle and Chasm components (currently they're all one image).
Removes the cave Duelist surprise and Li'sar's sudden reinforcements, makes Fencers and Duelists try to assassinate Konrad (or Delfador if they get the chance), and enlarged the map to give the assassins more room to manouver. Probably needs further balance tweaking based on feedback.
This causes a window scrollbar to appear on 600h (or > min tree height + height of rest of widget) resolutions.
I'll need to deal with some minimum size-setting on a dialog basis.
This allows almost all castles<->walls combinations to work together visually. The basic idea is to draw cavewalls onto castles, but not draw castle walls onto cavewalls except for specific castle tiles at castle<->wall<->other intersections to fill in the resulting gaps.
Otherwise it is too easy to exploit this by baiting the AI leader to
run into a trap, and it is too difficult for what it's worth to make
sure the attack location is safe. If only the side leader is left to do
such an attack, it's more often than not not a good idea to do so
anyway.
The syntax is mostly the same as the old cave generator - a [scenario]
tag for general scenario data, and an [items] subtag of [chamber] for
chamber-specific data. However, the generator assumes that map locations
(from [item_location]) will be used and thus does not support
same_location_as_previous=yes in moveto events within [items].
