Historically, MC packet ended up in a ridiculous spot. It had this
single structure:
MC#something#cid#%
It used to change music track to `something`, and the character ID `cid`
was used in clientside muting (blindly trusted, by the way). Then,
this packet was expanded to mean area change as well, so the same
generic structure carried two completely different meanings.
How does one differentiate the two? Whether the client tried to move to
an area `something`, or played a music track called `something`?
The solution was to assume that having ".extension" at the end magically
implied that it was a name of a music file, check the string `something`
within the MC packet, and pray that you guessed correctly. So,
understanding the protocol message required penetrating into one of its
data fields and ambiguously inferring what the whole message even meant.
Modern AO gives us a more logical solution. Not as good as having two
separate packets for two unrelated actions, but we can at least discern
the area and music change directly from the framing.
Area change uses the same two-field structure: MC#area#cid#%
Music change, however, has acquired two additional fields:
MC#music#cid#showname#flags#%
We consider four-field MC to be music change, and two-field MC to be
area change, resolving the ambiguity and eliminating odd constraints
on area and music names.
WebAO still uses the old logic and sends two-field MC packets for both
cases. CSDWASASH server, as a result, thinks that web users try to
change areas when they play music. This commit fixes this behavior and
adds special sendAreaChange instead of using sendMusicChange for both.
The flags are hardcoded to 0 because WebAO can't set fade-in, fade-out,
or position sync, and it ignores the server flags.