The coins still preserved their Scritter-like movements upon saving and loading the game after the CMD4 was executed. This meant that within the saved data, the coin object's movement behavior was stored. After I released The End 9, I isolated the "Scritter coin" and the associated command 4 and ran some experiments (primarily involving saving the game and looking at the saved data in a Hex editor). Fortunately, object data in save files is, for all intents and purposes, arranged exactly the same as wop data. This made it a bit easier to figure out what was allowing the coins to move like Scritters.
After much testing (and a lot of excitement on my end upon achieving various results), I had figured out the key to making any object in the game move.
The primary parameter involved is the one that PowerWop labels as unknown parameter number 46 (???46). Because of its huge involvement in making any object move, I have decided to dub it "TrueMovement" (and also because it sounds cool, duh).
TrueMovement is a set of flags that determine what kinds of tiles the object is allowed to move over (floors, water, walls, lava, ice, bridges, etc). By default, a wop file has this set as 00 00 00 00 (all flags disabled), so TrueMovement will not take effect. However, when TrueMovement has its flags properly set (TrueMovement will be nonzero), the object will move while following the rules defined by TrueMovement.
When TrueMovement is enabled, the MovementType and MovementSpeed set in the wop file will (in almost all cases) override the object's default movement behavior. This is especially evident in TrueMovement-modified Chompers, which follow their TrueMovement-set rules rather than hunt down the player.
One critical partner of TrueMovement is unknown parameter 47 (???47), which I have dubbed "PhasePower". Like TrueMovement, PhasePower is a flag set and is also 00 00 00 00 by default. While it does not need to be nonzero for TrueMovement to function, it plays an important role in deciding how objects behave in certain hardcoded situations (in especial regard to what objects they can "phase" through, hence the name I gave to PhasePower). For example, when the second flag of the second byte of PhasePower is set (e.g. 00 02 00 00), this allows the TrueMovement-modified object to pass through barrels rather than treat them as solid objects (this is actually the behavior that Spikeyballs use that allows them to enter tiles containing barrels, cuboids, etc). Of course, there's also a setting that allows objects to move onto the tile containing the player (which, again, objects like Spikeyballs use); this setting is determined by the second flag of the first byte of PhasePower (e.g. 02 00 00 00).
Of course, ButtonReact (formerly unknown parameter 29 (???29)) plays an important role in object behavior when objects become mobile. ButtonReact is a flag. When it is enabled, objects are able to press buttons, be sprung, etc. When it is disabled, the object is unable to do those things.
ButtonReact, MovementType, MovementSpeed, TrueMovement, and PhasePower all come together to create a unique mobile object. Some of the potential results can't be graced with words. I think my demonstration adventure regarding TrueMovement says a lot more than I could in this post. I recommend playing the adventure for yourself if you haven't yet, especially if you're an adventure designer. It goes without saying that the kinds of capabilities that TrueMovement demonstrates have very profound implications for contemporary puzzle design.
TrueMovement wop files have a large number of advantages over creating equivalent objects via CMD4. The biggest advantage is the fact that you don't need to jump through any CMD4 hoops to get a TrueMovement entity in the game. That additionally means no extra General Commands that take up space in adventures. The biggest concern of simulating TrueMovement through CMD4 is the existence of "ghost entities" that are left behind when most varieties of entities are logic-swapped. Ghost entities is a whole subject I'm not even going to get into, along with a whole bunch of other annoying minutiae associated with CMD4 logic-swaps. The only annoying thing about TrueMovement wops is that you'll need to make a new wop for every new MovementType or MovementSpeed you desire, but I'd say the results more than make up for it.
Below are the actual values for the TrueMovement and PhasePower flags, along with some labels that are used on the wop files I created.
-=- TrueMovement -=-
MovementSpeed, MovementType, and PhasePower override logic's "default" movement.
XX XX 00 00
XX XX is a set of flags...
01 00: Move on floors. (F: Floor)
02 00: Move on walls. (W: Wall)
04 00: Move on water. (A: Aquatic)
08 00: ??? (U: Unknown)
10 00: Move on bridges. (C: Collapsible)
20 00: Move on lava. (L: Lava)
00 08: Move on straight ice. (iS: ice Straight)
00 10: Move on curved ice. (iC: ice Curved)
00 20: Move on ice walls. (iW: ice Wall)
00 40: Move on ice floats. (iF: ice Float)
-=- PhasePower -=-
Like TrueMovement, PhasePower is a flag system.
XX XX 00 00.
02 00: Phase through player. (P: Player)
10 00: Phase through items. (I: Item)
40 00: Phase through sunken turtles. (T: Turtle)
00 02: Phase through barrels and cuboids. (W: Wood)
Attached below are all of the TrueMovement wops I've made as of the writing of this post (58 wops total, including some of the ones that didn't really function as anticipated, but I'm sure you weirdos can still find uses for them). The file names probably don't make any sense to people who aren't me, but don't worry; if you're uncertain about something, feel free to ask. Testing the wops for yourself should be very insightful too.
TMXX-YY = TrueMovement: MovementType XX, MovementSpeed YY (both in base 10).
At some point I might program a module that automatically converts a wop to a TrueMovement wop of any desired MovementSpeed and MovementType. I might append the module to PowerWop, should I ever get around to rewriting it. For now, though, I suppose I'll be fulfilling TrueMovement wop requests on a whenever-I-feel-like-it basis. Try and keep the requests reasonable, please; the Wonderland Adventures engine has still yet to be bent entirely to our will.
