This causes the viewport to be scrolled during MUFs even when
[lock_view] is in effect or Follow Unit Actions is disabled in Advanced
Preferences.
Rationale for the default value:
* Follow Unit Actions is already ignored by [scroll]/[scroll_to] and
unit [message]s, even in 1.10.x.
* [move_unit_fake] may be used in cutscenes in conjunction with
[lock_view]. It is desired to have the viewport scroll to show
unit movement, and this isn't possible at the moment without
overriding the implementation of [move_unit_fake] using Lua to
disable the viewport lock for the duration of the action.
* Since the above is a rather common scenartio, it is better to
let the engine handle it correctly without additional code in
the WML/Lua side. For situations where the [move_unit_fake]
scrolling is not desired, the user can pass the optional attribute
themselves.
* Follow Unit Actions's usefulness outside of unscripted battle
maps is rather questionable.
This allows forcing the viewport to scroll when moving units even when
[lock_view] is in effect or Follow Unit Actions is disabled in Advanced
Preferences by passing an optional parameter to move_unit() and the
unit_mover class constructor.
This does not mean that all the MAIs do anything with this yet, only
that it is passed to all MAIs for which it is set. It needs to be
implemented on a one-by-one basis. Only the Goto MAI uses this option
so far.
This is necessary because there is now no distinction between
parameters passed as keys or tags in the [micro_ai] tag setup functions
for all MAIs. No change in functionality.
It turns out this is actually very useful according to a certain add-on
author who is definitely not me.
For example: have Campaign Foo and Music Pack Foo. Music Pack Foo can
depend upon Campaign Foo so a player attempting to download it is
suggested to download Campaign Foo as well since it's entirely useless
otherwise. Meanwhile, Campaign Foo depends upon Music Pack Foo in order
to be able to use some custom music in the campaign proper.
This requires passing additional information about available add-ons (on
the server) and installed add-ons to the dialog's constructor. The
dependency list is a completely flat label displaying a comma-separated
list, with color-keyed installation statuses like the Status field and
the main add-ons list display.
The goal is to merge three code paths so they are easier to update.
When GUI2 is ready, it might make sense to merge choose_unit_2()
into menu_handler::create_unit().
