Views: 7,617,746 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
10-23-17 04:39 PM

0 users reading CLPS Exposed! | 1 bot

Main - General SM64DS hacking - CLPS Exposed! New reply

Posted on 01-18-17 08:46 PM (rev. 6 of 05-02-17 07:21 AM) Link | #80977
The CLPS is not an array of 8 bytes. It is a giant bitfield that just happens to be 64 bits long. A proper backronym for CLPS would be CoLlision Parameter Structure.
Here are the bits in order from bit 63 to bit 0.


(The numbers below will be in decimal)
T = Texture.
  • 00: Normal
  • 01: Path
  • 02: Grass
  • 03: ???
  • 04: Rock/Stone
  • 05: Wood
  • 06: Snow
  • 07: Ice
  • 08: Sand
  • 09: Flowers
  • 10: ???
  • 11: ???
  • 12: Grate

A = Water
This is a boolean indicating whether the surface defines a water plane.

V = View ID
This indexes the view that the surface should have. If the View ID is 63, it does not have a view attached to it.

F = Traction
  • 0: Normal
  • 1: Unslippable
  • 2: Unslippable
  • 3: Slippery Slope
  • 4: Slippery
  • 5: Slippery, no wall jumping

C = Camera Behavior
  • 00: Normal
  • 01: Go behind player
  • 02: Zoom way out and go behind player
  • 03: Go behind player
  • 04: Go behind player
  • 05: ???
  • 06: Normal
  • 07: Go behind player
  • 08: Go behind player
  • 09: 8 directions only
  • 10: No rotating except with arrow buttons
  • 11: Close up and personal

B = Behavior
  • 00: Normal
  • 01: Lava
  • 02: ???
  • 03: Ceiling hanging mesh
  • 04: Death plane
  • 05: Death plane
  • 06: Low jumps
  • 07: Slow quicksand
  • 08: Slow quicksand
  • 09: Instant quicksand
  • 10: ???
  • 11: ???
  • 12: ???
  • 13: ???
  • 14: ???
  • 15: Start line
  • 16: Finish line
  • 17: Lets Vanish Luigi through
  • 18: Pushes the player off it in 1 frame
  • 19: Gust plane

Z = Transparent to Camera
Whether the camera can go through it.

X = Toxic
Like the Water parameter, but this one defines a toxic barrier.

U = Camera Wall
Whether actors other than the camera can pass through it.

P = Padding

W = Wind Path ID
Links the surface to a 2-point path defining a vector which says which direction the wind blows. Parameter 4 for the path is either 0, 1, 2, or 3. This could define a breeze, a water current, or a quicksand pulling direction.

Q = Padding

And here is a picture of a CLPS editor for Whomp's Fortress and that shows the proper way to break up the CLPS:

Answer to Hiccup's question:
 Whoops, I meant to press "edit", and I can't post again until an hour passes.
You'd have to unfortunately write out all the bits, convert to hexadecimal, and write the bytes in the CLPS editor in order from least to most significant.

Where it says "zoom", I meant "transparent to camera".

Current hack: Excerpt from Super Mario 256

Any map on a flat torus can be colored with at most 7 colors.

Posted on 01-18-17 09:00 PM Link | #80978
Pretty cool findings!

Minor nitpick tho: you should use an imgs tag for your image rather than a spoiler.

NSMBHD - Kafuka - Jul


Posted on 04-15-17 07:52 AM Link | #82503
How would one use this info with the current CLPS dialog box?

(post deleted) #82507

Posted on 04-15-17 09:44 AM Link | #82510
This is very useful. Do you have this integrated already with SM64DSe? If so you could open a pull request to the SM64DSe github repo, otherwise I will implement myself it in the next few weeks.

(post deleted) #82512

Posted on 04-15-17 06:24 PM Link | #82524
I have it integrated. I'd have to extract it from the million changes I've made to my version of SM64DSe, though.

Current hack: Excerpt from Super Mario 256

Any map on a flat torus can be colored with at most 7 colors.

Posted on 04-16-17 04:01 AM Link | #82533
Are they changes that could be useful to others? If so it would be nice to have them.

Posted on 04-16-17 01:07 PM Link | #82548
Some yes, some no.

Here's the list of changes I've made:
  • CLPS form updated to reflect the one true CLPS breakup
  • Optional grid for precise placement of objects
  • Restriction plane (RP) to snap placed objects to, for example, y = 0.0
  • In the absence of a RP, placed objects snap to the collision triangle the mouse is touching if there is one.
  • Code compiler that takes an ASMPatchTemplate folder and an offset to compile code for
  • Dynamic overlay support in said code compiler (requires a patch in the ROM to work)
  • Overlay compiler for levels
  • Support for adding, removing, and renaming files and directories in the ROM except for archives (a little imperfect, though, and removing requires a patch in the ROM to work)
  • Updated object renderer paths to reflect filenames for objects in Excerpt from Super Mario 256 (breaks compatibility with a regular SM64DS ROM) (plan to use overlay 0 file IDs instead because those remain constant)
  • Imported normals are multiplied by 511/512 to prevent overflow
  • A template for adding a new platform to the game
  • Update object database function removed and changed to Reload object database (prevents the Excerpt-from-Super-Mario-256-specific changes I made from getting accidentally reverted, but I have a backup anyway)
  • Alt+{Up | Down | Left | Right | F | B} for top, bottom, left, right, front, and back views
  • The level editor loads the entire overlay on initialization and rewrites the entire thing on save to prevent glitches with adding new areas.
  • PaletteFitâ„¢ compresses palettes for compressed textures by overlapping them nearly as much as possible
  • QuickGraph imported to support the PaletteFitâ„¢ algorithm
  • Increased quality of compressed textures. Combined with PaletteFitâ„¢, the size of a texture may increase or decrease.
  • BCA importer now creates smaller BCAs by using the constant-track, same-track, and interpolation optimizations. (by a factor of about 6)
  • .NET framework upgraded to 4.5

Current hack: Excerpt from Super Mario 256

Any map on a flat torus can be colored with at most 7 colors.

Posted on 04-16-17 02:11 PM Link | #82549
Dear, that'd be quite the pull request. I'm amazed by your competences!


Posted on 04-16-17 03:18 PM Link | #82554
Could you please provide more detail about the following:
- "Code compiler that takes an ASMPatchTemplate ...", "Dynamic overlay support ..." - What does this do and how does it work?
- "A template for adding a new platform to the game" - Is this code to modify an existing object or something else?
- "Overlay compiler for levels" - What is this?

Out of the remaining items I would only exclude:
- "Updated object renderer paths ..."
- "Support for adding, removing and renaming files and directories" (until fully working)

Posted on 04-16-17 04:24 PM Link | #82556
I got tired of NSMBe's heap-sucking patch template, so I transferred the code to SM64DSe and made a function that creates overlays for levels so the heap doesn't get used when it doesn't need to be used. For example, Blocky Block Land (displayed in "Launch Stars (and Totally Not Breaking the Game's Code)") doesn't use any objects from Bob-Omb Battlefield, but it has its own objects, and the overlay compiler for levels compiles the code for that.

A dynamic overlay is a type of file that I invented for Excerpt from Super Mario 256. For each level, a list of overlay 0 file IDs for each dynamic overlay is stored. When the level loads, they are loaded, and the pointers are fixed. This way, an object can be put in any level regardless of the bank settings.

The new platform template does just that: add a new platform to the game. More specifically, you give it a name, show where the model and collision files are in the ROM, give it a description for documentation, say what object and actor ID it gets (and some more behavior-related stuff) and it generates ASMPatchTemplate/source//.h and ASMPatchTemplate/source//.cpp. Editing the makefile source path to direct to ASMPatchTemplate/source/, compiling the code (as a dynamic overlay), and storing that in the ROM results in the platform being added to the game.

Current hack: Excerpt from Super Mario 256

Any map on a flat torus can be colored with at most 7 colors.

Posted on 04-16-17 05:14 PM Link | #82559
Sounds like it could be very useful, I have a few questions:
1. Is it possible to use a custom object in multiple levels and if so how is this done? Is it a manual step or is based on something defined in the code eg. the way hook addresses come from function names?
2. Is it still possible to patch arm9 code?
3. What if I want to patch a non-level overlay eg. character control in overlay 2?
4. Would the existing ASM hacking template work without modification?

Posted on 04-16-17 05:25 PM Link | #82560
1. Compile it as a dynamic overlay, put it into the ROM, look at the Ov0ID (displayed at the bottom on my version of SM64DSe) of the file, and hex edit the level overlays to add it to the list of dynamic overlays for the levels.
2. That would require NSMBe, and I haven't tested that yet.
3. The function that makes level overlays completely overrides the level overlays, so probably not, unless you want to decompile the entire overlay (it's big).
4. No. Each object (or level) should have its files in its own folder in the source folder, and the makefile source needs to be edited accordingly. Also, the function list and SM64DSe.h file are wildly different.

Current hack: Excerpt from Super Mario 256

Any map on a flat torus can be colored with at most 7 colors.

Posted on 04-17-17 12:08 PM Link | #82579
OK, thanks. It would be a good feature to have, would you mind opening a pull request for this and the other features?

Posted on 04-17-17 03:34 PM Link | #82582
After finishing the level I'm making.

Current hack: Excerpt from Super Mario 256

Any map on a flat torus can be colored with at most 7 colors.

Main - General SM64DS hacking - CLPS Exposed! New reply

Page rendered in 0.059 seconds. (2048KB of memory used)
MySQL - queries: 29, rows: 226/226, time: 0.035 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2015-10-07)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.