SlyCooperReloadCoded

Personal scratchpad - the results of my experiments and findings can be found here. inb4 some of this leads to massive discoveries.

Multi-game stuff:

Some triggers that don't have to do with damage or death can be found by searching for the start of the struct of the character that just touched it. For example, Sly's struct in island_map in the September build is 0xCACA40, so search for a value of "CACA40". These triggers store this info near the top of their struct. It's a value of 00000000 when no character has touched it. If you find it and scroll up a bit, you'll see a visibility value that begins with 1 instead of 0. Go -0x2C from there and you'll end up at the start. If there's something other than 00000000 at the start of a trigger's struct, freezing that to 00000000 and doing a full reload should disable that trigger's functionality. If it doesn't, setting its visibility works too. Usage examples include disabling the tilt_hall trigger that crashes the game in freeroam, or disabling the cracking of the thin ice that surrounds Canada 1. Note that triggers such as job start beacons or the barrier preventing you from flying too far in ACES don't use this system.

Potential Murray Slam/Throw Hardcoded Theory:

The damage types for Murray slamming and throwing guards is hardcoded in both Sly 2 and Sly 3, just like Sly 3's death barriers. Code controls the damage and its type, rather than it being stored in an entity struct. Diablo Fire Slam, the gadget that makes Murray slam a held guard into flames, is a duplicate of the ability, but isn't hardcoded, and stores its damage type and amount in an entity struct.

While not a theory that attempts to give a precise reason what about slamming and throwing requires hardcoding, it is important to note that many damage type values changed a lot over the course of both Sly 2's and Sly 3's development, yet the damage type values for Murray slamming and throwing guards never changed at any point. From Sly 2 July to Sly 3 retail, they've always been the same.

Sly 2 stuff:

NTSC-U Episode 5 hub - at address 0x4D8364 is a list that bears a resemblance to the fk$x list, but includes not only entities, but also objects, triggers, invisible things, path points, etc. Each (nameless) entry contains the address that marks the start of its struct, as well as some other info. Unable to find this in any other episode, but it most likely isn't specific to this map. Some things I've been able to find with it include entities like the bats flying around, but also an anchor point for a boat, a bounce-away trigger of some kind, some deactivated triggers, both parts of Sly's cane, and the patrol boat. Everything in the fk$x list probably has entries here.

"Collision" address on the addresses sheet isn't quite collision, the term "binding" fits it better. Instead of setting it to 0, set certain characters in the value to 0 - sometimes nothing will happen, sometimes the object will lose collision, and sometimes the object will lose its "rigid" behavior and can be pushed around by touching it - the entirety of Arpeggio's blimp can be tossed around, for example. This also removes the object's need for a map reload to change coordinates - it'll update live - then setting that value back to its default will lock it in place again. If you do this to the entire map's struct, large parts of the map model will gain physics, letting you throw mountains around, but most of the time everything but entities will disappear due to being mass-proxied away due to all the entities touching it. If you want to move something but changing its coordinates either doesn't work or leaves its collision behind, freeze its "binding" value to FFFFFFFF and reload.

Map objects that:

- Have their transform component updating automatically (i.e. tilting building on a tree in Ep3 hub, Ep5 hub patrol boat, Ep7 water wheels, etc)

- Have scripting with multiple states (i.e. the invisible blockers on Episode 2's side islands that allow Sly through but push Bentley and Murray away)

have an "is being touched" float like entities do - unmoving ones don't, the only exception being the map model itself. Visibility will be nearby, and -0x2C from that is the start of the struct. Alternatively, you can find the start of the struct of anything with collision by using address 0x3E0988 with an offset of 0x1A0, which points to the struct of the object Bentley's first placed bomb attaches to. There seems to be no way to do this for map objects that lack collision, or for specific map objects (i.e. changing the color of the hidden ice wall in Ep7). Most map objects do generally work with entity offsets like +0xD4 for Render Priority or +0x12C for Opacity. Doing an entity swap with an object in the fk$x list and an object not in the fk$x list will always crash, whether it was done with the ID method or the pointer method.

Inside structs for map objects that can move is a set of addresses with the values 00000006 and 00010005 right next to each other. Above the 00010005 is a pointer to an animation speed region, but this is already known. The new discovery is that to the left of the 00000006 is a value of 0 when it's not in motion, and acts as a pointer whenever it is. Additionally, the 00010005 is 0 when it's not in motion. Putting them back to how they were before, freezing them, and reloading the map can sometimes reanimate them, usually at the wrong speed. Sometimes the 00010005 can be other values, such as 00050007.

Job beacons have their own visibility value. If frozen to 010F0200 and game is reloaded, they appear with their correct waypoints as well. Touching them as the correct character just makes them disappear, but touching them as the wrong character makes the "Only XXX can complete this job!" text box appear.

0x3E11AC seems to point to an address, changing this to 00000000 activates fake floor, and setting it back to its original value deactivates fake floor. This is a way to deactivate fake floor after getting it naturally through the glitch method. On rare occasions, setting it back causes weird oddities, like Sly acting like he's on the edge of something everywhere, or one or two more guards falling through the ground before it stops, but this rarely happens.

Sound volumes exist, just like damage volumes. You can find them by deactivating them through visibility. If you search for its visibility, which should be the same value as the laser itself, and set it to 00000000, it will stop emitting sound. -0x2C from there is the start of its struct. There could be a "Sound Volumes" struct with an offset, but it's too undocumented to say for certain.

The Contessa's blimp can't be completely found through the "Last Collision Touched" pointer or its fk$x list entry, that only points to its "hull" which is only the balloon/platform part. Moving that will result in the spotlights and climbable pole left in their original positions. For NTSC Episode 4, the correct entity struct is at 0x85E1FC and for NTSC Episode 5 it's at 0x125F6F0. It can be identified on other releases by changing its default visibility value (100FFF00 is default when spawned by the game) to 00000000, where the entire blimp will instantly despawn, no map reload needed. It's possible that other cases like this exist.

Sly 3 stuff:

September build is post-release and therefore uses most of the same offsets as retail. August and July are very different.

The pointer for the object touched by Bentley's first bomb exists here: 0x4789FC with an offset of 180. Works the same way. The "last damage plane touched" also exists and is functionally identical. Can be used to find the struct of death planes as well, setting their visibility to 00000000 disables them completely.

Unlike Sly 2, most map objects appear to have an "is being touched" float. For example, if you want to find the struct for a door, even if that door never opens under any circumstance, odds are it has this float.

Also unlike Sly 2, not all of Sly 3's lasers can be disabled by disabling their visibility and doing a full map reload. The "multiple moving lasers coming out of an emitter" type will remove all collision from the level when they're loaded if even a single laser in the group has its visibility disabled. Some lasers don't remove collision but also don't disable their damage plane, such as the lasers surrounding the Dr. M boss fight arena. Find and move their coordinates instead, which should require modifying several Z coordinate floats for each laser.