they can both have parameters stashed in a table, and they both play
stuff out of the actor command list. Merge them; now the only
difference between playing and broadcasting a command is that playing
plays recursively on a tree and broadcasting sends to all subscribers.
The distinction between "messages" and "commands" is cosmetic now;
everything is a message. The only thing special about commands intended
to be received as a broadcast is the "Message" suffix, which subscribes it.
In edit mode, though, AdjustSync should only save to memory, giving the
user a chance to save later. This change adds a SongChanged message
to the MessageManager. Making the ScreenEdit class listen to this
message allows the AdjustSync class to mark a song as dirty rather than
saving it to disk when in edit mode.
R=steve chekoway
before the ThemeMetric templates that use them. That's broken
and unreasonable, so change this around a bit and make FromStack
(and Push) templates.
Push() takes a bit of a trick. Some Push overloads push the
actual value: scalars (int, float), RageColor (pushes a table).
Others--most of them--push a reference to a C++ object. We
want the scalars to have a reference parameter type, so we
don't make extra copies of things like RageColor when we push
them. We need to pass C++ objects by pointer (we need to
push the actual object's pointer, not a pointer to a copy).
Further, pushing a scalar is a const operation, but pushing
a reference to an object is not.
To do both with the same template, we handle objects with
this slightly odd template:
template<> void LuaHelpers::Push<T*>( lua_State *L, T *const &pObject );
The actual overload (T) is eg. "Actor*"; this fits within the
general prototype, "Push(lua_State *L, const T &object)", giving
us a const reference to a (non-const) pointer to Actor, and we're
conceptually pushing the pointer.
The net effect of this is that 1: what was before compile errors
now becomes link time errors, but 2: these specializations
don't have to be in the headers (except for new ones for
Preference and BroadcastOnChange).
(not a performance issue; we don't queue up tons of messages. only use
deque when you really need constant time access to the beginning, eg.
for large objects, since deque has both memory overhead and is much
slower than vector for access to the end of the list, since it can't reserve like
vector can)
Chris Danford