Crushers are even more messed up than Trapdoors!

So on the surface, crushers and dropping spikes in CV3 share the same myopic code structure. The y-coordinates are based on one of the additional arguments, not the y-coordinate of the spawner. But it gets worse.

The same variable is also used to dictate if the instance is a crusher or dropping spike. Why?! The spawner already dictated that. Terrain element spawner #06 is used for dropping spikes and #07 is used for crushers. The only difference between the two, however, is just which object is assigned to the instance. Crushers and dropping spikes are the exact same object.

The highest position, lowest position, and sprite are all dictated by the same argument. The object assigned to the instance determines where the player can stand. Changing a dropping spike (#6E) to a crusher (#74) will make the top of the spikes safe to stand on. If you want it to actually be a crusher, though, you would need to modify the data tied to $0607-$0618. The object only determines collision handling, not sprites, movement, and tile editing.

I don't know what the person that coded these terrain elements was thinking. In this case, why not just use one spawner, use the spawner's y-coordinate as the highest position, set the object in argument 1, and either the lowest position or index to an array of them in argument 2? That would use less memory and make the code more flexible to boot.

Argument 0 is reserved for the width. Typically the argument is left at #01. If you change it to #00, it's treated as #100. Rather than giving the crusher an actual variable width, though, it just duplicates the crusher 32 pixels to the right. This means it will occupy additional instance slots. Anything greater than #02 is going to cause bad sprite flicker as well, which is probably why they limited it to #01.