These are the rules:
- If the active PC gets an empty shop, iterate from the first to last PC until finding someone who can see a shop item
- If none can shop, show the 'no item' response
- When the active PC buys something, if this clears out the shop, iterate from the first to last PC until finding someone who can see a shop item
- if none can see an item, stay on the empty shop of the PC that was active when the last item was bought.
- When shopping ends, if the shop interface was the last thing to change the player's active PC, it puts it back how it was.
Fix#669
In effect, this is a combination of two of the previous pickers:
the location picker, and the editable string picker.
This required quite a significant rework of how the tilemap places its children.
Currently it's only used in special node editing.
I plan to add its use in many other places too though.
All controls now store a reference to their direct parent,
whether it be the dialog itself or a container control.
Every dialog control now has a guaranteed parent, which abstracts away
the three possible types of parents (dialog, container, and plain window).
The control name is now stored in the control from the moment it is parsed from the XML.
This means that it's set before the parseContent function, though after parseAttribute.
These are all cases where similar items stack but these ones for some reason didn't.
Gemstones/Ores: Ruby, Crystal, Rough Diamond
Powders: Dust of Hiding and Choking
Missiles: Poison Darts; Arrows of Life and Light; Burning and Exploding Arrows
Reagents: Asp Fangs
It's used not only in special node editing (for Event Happens and If Event Happened?)
but also in the Townperson Advanced, Talk Node, and Quest editors.
This just implements the guts of the dialog, without using it for anything yet.
It also fixes a bug that caused a blank page to appear in the string picker if the total number of strings was an exact multiple of 40.
Closes#563