Fix offset token substitution in MS packet

In an IC message, x and y offsets are separated by an ampersand, which
is unfortunately a conventional separator within packet fields. So, it
looks like `25&10` for x = 25 and y = 10. A consequence of that is you
have to substitute '&' if you actually want to send it. AO does it by
substituting it to `<and>` and back.

The MS handler instead expected it to never be decoded, and instead
assumed `25<and>10`. By the time the MS packet reaches the handler, the
token has already been decoded into '&', however, thus breaking offsets.

0 files changed, 0 insertions, 0 deletions