The making of the mod thus far...

Since I'm having absolutely no luck with resolving the issue of infinitely spawning objects, and it's even affecting boxes too now, I have no new section designs to show today. This problem is not one I can solve easily and will probably have to wait for my brother to return from his university so we can both knock our heads together to come up with a solution; that will occur approximately one week from now, so it's not too far away.

In the meantime, I've taken some screenshots of the program that I am currently writing to mod Crash 2, and this program is how I have built all my sections thus far. I recommend clicking on the images so you can actually see what all the text is about.


Crash 2's levels are broken down into 64KB chunks, and these are broken down further in a small file tree structure. Entries within have a type identifier. The one I mod are ones of type 7, which contain the objects among other things.

This interface is what you see upon selecting an object.

Every single object within Crash 2, and the same goes for Crash 3, has a standard, very readable, English name, left behind by the developers. They usually go along the lines of "obj_(type)_(variant)_(number)". You can tell which objects I have named, as they do not follow this convention. Each object can be uniquely identified by its name, however there is no need for the names to be different at all; the PlayStation doesn't use these names to reference objects, they're just for the developers, as far as I'm aware.

Position data speaks for itself; this is where the object sits in the level. X is left-right, Y is up-down, and Z is depth, though interestingly the higher Z is, the closer to the screen the object appears. Values in here are relative to the section in which the object resides. If an object has more than one position, it's usually a wandering enemy, and the positions indicate where it'll walk to.

Object ID is a unique identifier of the object, and is used for rendering purposes and for the game to have a reliable method of tracking whether an object has been collected/destroyed or not.

Object Type dictates what the object is, and if there are lots of types of said object (e.g. a box), variant determines which one.

The General Settings contain numbers for specific tasks; e.g. when it comes to boxes, setting the first number to be 97 makes the box always produce a life. Setting the second number to 4 with left bitshift turned off makes the box give you its fruit/contents automatically upon breaking so you don't have to pick it up. You can also use these to dictate if a box is wireframe or not, and which box solidifies next in the sequence when the ! box is hit, if it is. These settings are also used in enemies to dictate their movement speed, or other various properties.

The "Destroys x objects" list usually applies to the Nitro detonation crate. Any ID listed here will be destroyed when the detonator is hit. Yes, it can destroy almost anything, including things that aren't Nitros, or even boxes. TNTs also have this value set sometimes and it's used if you go off-screen before the TNT blows up to ensure it destroys the objects it is supposed to.

The other settings you see do random things, some of which I don't know yet. The configuration for the "obj_checkpoint_emergency" I have shown above is for a ? box that turns into a Checkpoint if you die too many times. The "5" in the 0x288 box identifies which previous Checkpoint it is linked to (the related Checkpoint will also have a 5 in this field). The 3072 seems to dictate what kind of box it is before it turns into a Checkpoint.

This interface is what you see upon selecting the files that
seem to handle the information that renders objects.

This following section is currently incomplete and contains the infamous draw lists that I like to complain about. Draw List 1 indicates when objects should stop drawing, and Draw List 2 indicates when they should start. If you examine the hex, they indicate at what camera position the object will be going off/coming back onto the screen, so they can be used to make rendering VERY efficient by rendering EXACTLY what needs to be rendered only at any given time. The "positions" field shown is actually the route that the camera follows through the level and is directly related to the draw lists.


If space becomes an issue in the tiny 64KB sections, the program can reorder things to generate more room with the "Move this..." button at the top. Adding totally new objects is done on the button right next to it, and the program does its best to seek out the draw lists and add the object to them, though it is not always totally successful; sometimes the object spawned is not totally off-screen before vanishing and whatnot, and at that point the hex editor needs to come out to fix the issue. I've even had one draw list freeze the game for reasons unknown.

All of Crash 2's NSF files have a checksum on them, and changing any data means the checksum needs recalculating. Chadderz, my younger brother, was the one who cracked the checksum; the program updates it upon saving. The "Rehash a file" button has the same functionality, only you don't have to load the file into the editor if you use that button. It's useful if you've been messing with things in a hex editor and want to quickly get things tested.


And that is how I am doing my work! If it becomes stable, I may release it at some point. Currently it's buggy and a little sluggish, but I'll keep on working on it.

It's nicknamed the "NSF Modifier - Ripoff Edition". Why? ...Because my brother made a program called the "SZS Modifier" for Mario Kart Wii. And this program in some ways looks verrrrry similar to his work :P

Well then, have a great evening everyone.