This approach has several advantages. It's more flexible; full conditionals
can be used. It mixes with things like the "bGoingToPlayTheSameMusic"
logic in ScreenAttract much better; it gets the real real next screen, not
the branch. It also mixes with screen preloading, such as used by ScreenStage.
(I don't know if grouping functions that are used like branches makes sense;
I'm not sure how Lua will be used in general, so this stuff might get reorganized
later.)
This is appropriate for global scripts which are loaded only once, and
used multiple times: the scripts can safely affect global state (eg. override
functions), and stay in memory. There's no way to unload them short
of resetting the Lua state. It's not appropriate for one-shot scripts, such
as those that might be associated with BGAnimations. (needs more work)
all of the information we need is in one place, with proper links so we
don't have to do weird hacks to connect data together
we don't have to touch /proc/bus/usb/devices; doing so generates USB
messages to all devices, which can cause problems
works for all removable devices; usb-storage or ub should both work with
no changes, as long as mountpoints exist in /etc/fstab
doesn't need to fork lsusb
Old support is removed; unless serious, unfixable problems are found with
this method, the old code is too big and confusing to keep around. This
code needs more testing.
Background. This should be more consistent (we were creating BGAnimations
as non-generic in some places where it probably should have been generic).
This means all themes need to explicitly set the position of all BGAnimation
graphics, which is good practice anyway.
SM_BeginFadingOut. We can't do this in the ctor (since it's sent during
Update now); we can't do it in Update(), because if the message is posted
with a delay of 0 (ScreenRanking), the message will be added by
ScreenAttract::Update and immediately processed by Actor::Update
before the derived Update can remove it.
Glenn Maynard