and "Foo/Bar/baz" exists, allow the case passed to be returned (foo/bar/baz).
ResolvePath is fairly expensive, and should only be used by file drivers
that actually need it.
fallback was checked with the main theme, then each class fallback was checked
with the base theme, and so on.
Reverse this: check the class name with each theme, then check the class
fallback with each theme, and so on.
This is faster, since we only look up each class Fallback at most once, not
once per fallback theme, and groups together theme lookups (which may allow
further optimizations). More importantly, this matches the metric lookup
scheme.
This also makes more sense--if "ScreenWithMenuElements header" is overridden by
"ScreenMenu header" in the base theme, overriding "ScreenWithMenuElements header"
in a derived theme should change the same in the base theme (changing the
default) but not change the specialized "ScreenMenu header".
example, if a base theme had:
[Derived]
Fallback=Base1
[Base1]
A=1
and a derived theme had:
[Derived]
Fallback=Base2
[Base2]
then the lookup "Derived", "A" would find 1. This is confusing and inconsistent:
it means that the value of Derived::Fallback has two values, both Base1 and Base2,
and Base1 is only accessible by the internal metric lookup. Every metric should
have only one value; "Fallback=Base1" should be completely overridden here.
(This also reduces the difference between theme lookups and path lookups; path
lookups did not have this anomaly, as they did not have access to the extra Fallback
value.)
- RunAtExpressionS. Using @ to generate command lists is no longer allowed; it's
too expensive and clumsy, and is no longer needed.
- "::" for newlines. This isn't needed, since the string is a Lua expression;
use "\n".
- FontCharAliases::ReplaceMarkers. This only makes sense for settext calls.
(The latter two will still be supported by settext directly.)
This is so "settext,'Foo &START; bar';x,10" will be parsed as two commands,
not three. This hasn't been needed so far, since places that load actor
commands have been calling ReplaceMarkers first, so the entity is replaced
before this; that's going away, so handle it here.
Chris Danford