User:B squo

Discord → B_squo#5127

Twitter

YouTube Channel

Details on my old_mario_gc_hayasi restoration attempt

Download

Models

old_mario_gc_hayasi has two models:

course_model.brres

The course's model.

MDL0

Its MDL0 (model format) is in version 8 (the final game only supports version 11), so attempting to load this model will crash the game.

For this restoration, I used BrawlBox v0.71 to convert the model to version 11, and so far, the resultant model looks identical to the original Double Dash!! version of the model (which also happens with old_mario_gc_b, and the rest of the unused versions of GCN Mario Circuit). You can tell by looking to the little bumps where the Goombas are, which look identical to how they did in Double Dash!! (in MKWii, the bumps have been raised up a little).

TEX0

The textures, while identical looking to the ones in the final, are stored in TEX0 version 1 format (the final game is meant to used TEX0 version 3 format). However, because v1 and v3 formats both have the same structure, the final game can actually load them just fine! So in this case, I didn't need to do any conversion/editing at all to make it work.

STR0

The texture animation is stored in the format SRT0 v4 (the final game only supports v5). For this I actually imported the SRT0 file from the old_mario_gc_b version instead of changing the version using BrawlBox v0.71. This is because I originally did change the format with BrawlBox v0.71, but I then compared the resultant SRT0 with the one from old_mario_gc_b and I realised the were ALMOST identical, except for a few bytes that, following the SRT0 format page, I did not think they affected the actual texture animation data itself. In both cases, the water animation works, but does not loop properly.

SCN0

Much like old_mario_gc_b, this version also features a SCN0 (scene settings) file in version 4 (the final game only supports version 5). This file controls things like ambient light, fog settings, etc.

As far as I'm aware, SCN0 files are used for showing live rendered videos and are not found in any used course at all (again, as far as I know), in fact, things like the lights or the fog settings are actually controlled by other type of files unrelated to SCN0 files, so it's not that important. Nonetheless, I still added it to the restoration as well (in this case I also imported the one from old_mario_gc_b given the similarities).

According to BrawlBox v0.71, the SCN0 file contains the following

• One light whose starting position is XYZ = (4, 4, 4), with a Specular Shine of 16 (every other entry = 0). Both light and specular colors are equal to RGBA = (255, 255, 255, 255) (completely white).
• An ambient light whose color is equal to RGBA = (255, 255, 255, 0) (completely white).
• A camera with position XYZ = (0, 10, 20), Fov Y = 30, Aspect = 1,777777, Near Z = 1 and Far Z = 1000000 (every other entry = 0).

vrconr_model.brres

The skybox model.

MDL0

This MDL0 (model format) is also in version 8, so it was converted to version 11 using BrawlBox v0.71.

TEX0

Much like with the course model, its only texture is also stored in TEX0 version 1 format. And again, I left it as it was from the original unused course file, since the final game can load it just fine.

map_model.brres

While the unused version does not feature a minimap model, I had to add one to the restoration, since the game crashes if it's not present. I just added an empty model and moved its positional bones far away (-99999, 0, -99999), so that the character icons don't appear in the screen.

Collision (course.kcl)

The collision from the unused file can be loaded in the final game just fine, so I just added it to the restoration as is.

The collision itself is very similar to the one found in old_mario_gc_b at first glance (main type of road assigned to every single road texture, main type of wall assigned to all of the wall texture kinds, no shadowing when passing under shadows, tricks cannot be done, etc). However, there is actually something that is unique to this and one of the other unused GCN Mario Circuit versions: there are two tree trunks standing in the area with the wide curve in the grass shortcut! This is not in the final game nor in old_mario_gc_b, as the trees (and their collision) are added as separate objects.

Parameters (course.kmp)

The course.kmp is in an older version of the format (0x0640) in which some sections have a different layout, meaning it won't work in the final game. I studied this file, assuming the final version's KMP format to figure out what was still in the file and also what's wrong with it. This has a summary of the technical differences between this and the final version of the format.

KTPT (Starting point)

As you saw in the video, the starting point is placed a bit forward than in the final game.

When it comes to the section in the KMP, the section header that is common to all sections of the file (which tells things like the number of entries the section is using) only consisted of the magic. The section data starts right after it, but otherwise it seems to follow the same structure as the final version.

ENPT (CPU points)

- Number of CPU points = 34 (0x22)

These are the invisible points the CPU follow in order to navigate around the course. In comparison to the final, old_mario_gc_hayasi has less points, but nonetheless follows the course correctly.

The section data in this version only contains position data (3 single-precision floats), and lacks the additional float, uint16 and two bytes that dictates the width in which the CPU can navigate and a few settings such as when should the CPUs use a mushroom, do a wheeliee, etc.

Because these missing bytes are not present in the unused version, I decided to make them 0 (like a default case). This explains why, for example, the CPUs seem to be in a strict line the whole time instead of moving left/right sometimes.

ENPH (CPU points group info)

This section is missing from the unused file. Because of this, the CPUs shouldn't even actually move at all.

However, I've decided to add an entry to the restoration to create a group containing all the CPU points and linking itself as the "previous" and "next" group so that you can see the CPUs following the already-predefined CPU points. Again, remember that this is technically custom, and CPUs should not actually move. If you want to truly make the restoration's KMP accurate, you can always "remove" this section by opening the course.kmp file and then changing the byte at offset 0x325 from 01 to 00, which will make the game think this section is empty.

CKPT (checkpoints)

This section seems to be in the same format as the final one, so I just copy/pasted the data from the unused version as is.

CKPH (checkpoint groups)

This section seems to be in the same format as the final one, so I just copy/pasted the data from the unused version as is. There is only one checkpoint group that contains all of the checkpoints.

GOBJ (objects)

This section is empty.

POTI (object/camera routes)

This section is empty.

AREA

- Number of AREAs = 7

From what I know, this is the only unused GCN Mario Circuit version with AREAs defined, all of which act as camera activators. They're all located from the beginning of the first curve until around the curve before the tunnel.

The section layout is almost the same as the final version, except that it is 4 bytes shorter. In the restoration, these missing bytes were added as 0.

CAME (cameras)

- Number of cameras = 8 (7 FixSearch + 1 Goal)

Much like with the AREAs, this is the only unused GCN Mario Circuit version with cameras defined. The cameras are placed in more or less the same places as with the AREAs.

The Goal camera is closer to the character than in the final version, and it does not zoom in slightly when it is activated.

While the unused file defines the intro camera to be the first one, that one is not the type of camera that is meant to be used in that sequence (with the type being OP_FixMoveAt and/or OP_PathMoveAt). Not only that but because this camera can only be activated by passing through its associated AREA, it does not actually show up in the intro. Instead, the camera just focuses on your character, similarly to what happens when there're no cameras defined (however in this case, the camera actually stays in place, probably because the camera does exist). To sum up, no, the developers did not actually add opening cameras to the file.

The section layout is almost the same as the final version, except that it is 4 bytes shorter. In the restoration, these missing bytes were added as 0.

Other sections

Every other section is missing from the unused file. In the restoration, they've been added, but are empty.

The only exception (aside of the ENPH section from before) is the STGI section, since the game crashes if it's not present in the file. For this case, I made all the section data bytes 0 EXCEPT for the number of laps (3). This is because, if I make this byte 0, Lakitu won't appear when driving backwards.

Be careful because if you fall out of bounds (or if a CPU gets stuck for a while) the game will crash because of the lack of respawn points.

Details on my old_mario_gc_yabuki restoration attempt

Download

Models (MDL0)

Much like old_mario_gc_hayasi, this version also has two models: the course's model (course_model.brres) and the skybox's model (vrcorn_model.brres), both of them are in the same older formats as with old_mario_gc_hayasi. Because of this, I followed the same process to convert these resources as with old_mario_gc_hayasi.

As far as the differences goes, they are both identical looking, the only exception is that none of the old_mario_gc_yabuki models (MDL0) have normals. This does not seem to change its appearence, however.

TEX0

The textures, while identical looking to the ones in the final, are stored in TEX0 version 1 format (the final game is meant to used TEX0 version 3 format). However, because v1 and v3 formats both have the same structure, the final game can actually load them just fine! So in this case, I didn't need to do any conversion/editing at all to make it work.

STR0

The texture animation is stored in the format SRT0 v4 (the final game only supports v5). For this I actually imported the SRT0 file from the old_mario_gc_b version instead of changing the version using BrawlBox v0.71. This is because I originally did change the format with BrawlBox v0.71, but I then compared the resultant SRT0 with the one from old_mario_gc_b and I realised the were ALMOST identical, except for a few bytes that, following the SRT0 format page, I did not think they affected the actual texture animation data itself. In both cases, the water animation works, but does not loop properly.

SCN0

Much like old_mario_gc_b, this version also features a SCN0 (scene settings) file in version 4 (the final game only supports version 5). This file controls things like ambient light, fog settings, etc.

As far as I'm aware, SCN0 files are used for showing live rendered videos and are not found in any used course at all (again, as far as I know), in fact, things like the lights or the fog settings are actually controlled by other type of files unrelated to SCN0 files, so it's not that important. Nonetheless, I still added it to the restoration as well (in this case I also imported the one from old_mario_gc_b given the similarities).

According to BrawlBox v0.71, the SCN0 file contains the following

• One light whose starting position is XYZ = (4, 4, 4), with a Specular Shine of 16 (every other entry = 0). Both light and specular colors are equal to RGBA = (255, 255, 255, 255) (completely white).
• An ambient light whose color is equal to RGBA = (255, 255, 255, 0) (completely white).
• A camera with position XYZ = (0, 10, 20), Fov Y = 30, Aspect = 1,777777, Near Z = 1 and Far Z = 1000000 (every other entry = 0).

map_model.brres

While the unused version does not feature a minimap model, I had to add one to the restoration, since the game crashes if it's not present. I just added an empty model and moved its positional bones far away (-99999, 0, -99999), so that the character icons don't appear in the screen.

Collision (course.kcl)

The collision from the unused file can be loaded in the final game just fine, so I just added it to the restoration as is.

The collision itself seems identical to the one used in old_mario_gc_hayasi (although both files are technically different, i.e. not byte-to-byte identical).

Parameters (course.kmp)

The course.kmp is in an older version of the format (0x0640) (much like with old_mario_gc_hayasi) in which some sections have a different layout, meaning it won't work in the final game. I studied this file, assuming the final version's KMP format to figure out what was still in the file and also what's wrong with it. This has a summary of the technical differences between this and the final version of the format.

KTPT (Starting point)

The point has the exact same coordinates as with old_mario_gc_hayasi, except that it is rotated backwards 180 units (Y Rotation = 0x43340000).

Something curious about this is that, if you play in a kart, you will bounce when starting the race (this does not happen when playing in a bike). No idea why this happens.

ENPT (CPU points)

- Number of CPU points = 55 (0x37)

These are the invisible points the CPU follow in order to navigate around the course. In comparison to the final version, old_mario_gc_yabuki has around the same number of points, following the course correctly... except backwards.

The section data in this version only contains position data (3 single-precision floats), and lacks the additional float, uint16 and two bytes that dictates the width in which the CPU can navigate and a few settings such as when should the CPUs use a mushroom, do a wheeliee, etc.

Because these missing bytes are not present in the unused version, I decided to make them 0 (like a default case). This explains why, for example, the CPUs seem to be in a strict line the whole time instead of moving left/right sometimes.

ENPH (CPU points group info)

This section is missing from the unused file. Because of this, the CPUs shouldn't even actually move at all.

However, I've decided to add an entry to the restoration to create a group containing all the CPU points and linking itself as the "previous" and "next" group so that you can see the CPUs following the already-predefined CPU points. Again, remember that this is technically custom, and CPUs should not actually move. If you want to truly make the restoration's KMP accurate, you can always "remove" this section by opening the course.kmp file and then changing the byte at offset 0x4C9 from 01 to 00, which will make the game think this section is empty.

CKPT (checkpoints)

This section seems to be in the same format as the final one, so I just copy/pasted the data from the unused version as is. Much like with the CPU points, the checkpoints are indexed following the course backwards.

CKPH (checkpoint groups)

This section seems to be in the same format as the final one, so I just copy/pasted the data from the unused version as is. There is only one checkpoint group that contains all of the checkpoints.

GOBJ (objects)

This section is empty.

POTI (object/camera routes)

This section is empty.

AREA

This section is empty.

CAME (cameras)

This section is empty.

Other sections

Every other section is missing from the unused file. In the restoration, they've been added, but are empty.

The only exception (aside of the ENPH section from before) is the STGI section, since the game crashes if it's not present in the file. For this case, I made all the section data bytes 0 EXCEPT for the number of laps (3). This is because, if I make this byte 0, Lakitu won't appear when driving backwards.

Be careful because if you fall out of bounds (or if a CPU gets stuck for a while) the game will crash because of the lack of respawn points.

So... why do you drive backwards in this version???

As you have seen, the quirk about this version is that, for some reason, it is driven backwards! Not only the CPU points and checkpoints are indexed following the course backwards, but the starting point is rotated backwards as well. So... what's going on?

Now beforehand: yes, the data IS correct. This is not an inaccuracy of the restoration or something like that. I've checked the KMP file throughly and this is indeed how the data is stored in the file. For those who don't know, the way the game determines the indexes of the CPU points and checkpoints quadrilaterals (assuming they belong to the same group, and in this case, checkpoints are grouped in a single group) is simply by checking the order in which each entry is defined. For example, in the case of the CPU points (assuming they belong to the same group), the first point defined in the file (after the section header) is the point with index 0, the one that comes after it, index 1, the next one, index 2, and so on. In the case of old_mario_gc_yabuki, the 2nd point defined is positioned before the start line, the 3rd one, right before it (in the jump), and so on, following the course in reverse.

So now that we have discarded any issues with the KMP itself, these are my theories on why this happens:

• The course was originally rotated backwards: When comparing the early versions of GCN Mario Circuit with the final version, they are rotated 180 degrees. Which might explain the reason why the starting point is backwards for example. However, this is unlikely in my opinion, because if you rotate the whole course, sure, the rotation will match, but the position will be completely different. Not only that, but both the CPU points and checkpoints follow the course as it is stored in the file, and not rotated (which would misposition all of those entries out of bounds).

• The code for parsing KMP files worked differently at the time. The point entries were indexed in reverse: It is true that the code of the game might have been different at the time, and so the order of the points might have been determined from the last to the first entry. Now all we can do really is speculate on this one, since we have don't have any evidence on this. One argument to go against it is how old_mario_gc_yabuki 's KMP version is the exact same one as the one from old_mario_gc_hayasi (0x0640). If both KMP files have the same version, that could mean that the code that parsed both files had to be the same. If that was the case, then this would be pretty much debunked considering that old_mario_gc_hayasi has the points following the course in the correct order.

• It was a developer oversight: Discarding any issue with the KMP or how the code worked when this version was made, all there is left to speculate is that this was an oversight from the developer. Maybe they weren't told about the correct orientation of the course?

• • Sadly, this is very speculative, but I do have something interesting to say here. Remember how I said that the point coordinates were the exact same as the ones from old_mario_gc_hayasi? Maybe old_mario_gc_hayasi originally took old_mario_gc_yabuki as a base, and then (among other things) corrected the starting point orientation.

• • Another thing is how the lap counter checkpoint is placed before the finish line. Because of this, the lap can only count if the course is driven backwards. In order to be able to drive forwards and make the lap count, this lap counter checkpoint has to be put in front of the line.

Details on my old_mario_gc_narita restoration attempt

Download

BRRES (models, textures, texture animation and scene settings)

Both *.brres files are byte-to-byte identical to the ones from old_mario_gc_yabuki, so I just copied those files from that restoration into this one.

map_model.brres

While the unused version does not feature a minimap model, I had to add one to the restoration, since the game crashes if it's not present. I just added an empty model and moved its positional bones far away (-99999, 0, -99999), so that the character icons don't appear in the screen.

Collision (course.kcl)

The collision from the unused file can be loaded in the final game just fine, so I just added it to the restoration as is.

The collision file itself is identical to the one from old_mario_gc_hayasi.

Parameters (course.kmp)

The course.kmp is in an older version of the format, in which some sections have a different layout, meaning it won't work in the final game. However, unlike with old_mario_gc_hayasi and old_mario_gc_yabuki, the exact version number is unknown, as that field is missing from the file. Though it is possible that the version in this file is earlier than the ones from the aforementioned courses, given how it only has 6 sections defined, instead of 8.

I studied this file, assuming the final version's KMP format to figure out what was still in the file and also what's wrong with it. This has a summary of the technical differences between this and the final version of the format.

KTPT (Starting point)

The position is almost the same one as in the final version, except it is rotated backwards 180 units (Y Rotation = 0x43340000).

ENPT (CPU points)

- Number of CPU points = 32 (0x20)

These are the invisible points the CPU follow in order to navigate around the course. In comparison to the final version, old_mario_gc_narita has less points, following the course correctly... except backwards.

The section data in this version only contains position data (3 single-precision floats), and lacks the additional float, uint16 and two bytes that dictates the width in which the CPU can navigate and a few settings such as when should the CPUs use a mushroom, do a wheeliee, etc.

Because these missing bytes are not present in the unused version, I decided to make them 0 (like a default case). This explains why, for example, the CPUs seem to be in a strict line the whole time instead of moving left/right sometimes.

ENPH (CPU points group info)

This section is missing from the unused file. Because of this, the CPUs shouldn't even actually move at all.

However, I've decided to add an entry to the restoration to create a group containing all the CPU points and linking itself as the "previous" and "next" group so that you can see the CPUs following the already-predefined CPU points. Again, remember that this is technically custom, and CPUs should not actually move. If you want to truly make the restoration's KMP accurate, you can always "remove" this section by opening the course.kmp file and then changing the byte at offset 0x2FD from 01 to 00, which will make the game think this section is empty.

CKPT (checkpoints)

This section seems to be in the same format as the final one, so I just copy/pasted the data from the unused version as is. Much like with the CPU points, the checkpoints are indexed following the course backwards.

CKPH (checkpoint groups)

This section seems to be in the same format as the final one, so I just copy/pasted the data from the unused version as is. There is only one checkpoint group that contains all of the checkpoints.

GOBJ (objects)

This section is empty.

POTI (object/camera routes)

This section is empty.

AREA

This section is empty.

CAME (cameras)

This section is empty.

Other sections

Every other section is missing from the unused file. In the restoration, they've been added, but are empty.

The only exception (aside of the ENPH section from before) is the STGI section, since the game crashes if it's not present in the file. For this case, I made all the section data bytes 0 EXCEPT for the number of laps (3). This is because, if I make this byte 0, Lakitu won't appear when driving backwards.

Be careful because if you fall out of bounds (or if a CPU gets stuck for a while) the game will crash because of the lack of respawn points.

So... why do you drive backwards in this version???

As you have seen, the quirk about this version is that, for some reason, it is driven backwards! Not only the CPU points and checkpoints are indexed following the course backwards, but the starting point is rotated backwards as well. So... what's going on?

Now beforehand: yes, the data IS correct. This is not an inaccuracy of the restoration or something like that. I've checked the KMP file throughly and this is indeed how the data is stored in the file. For those who don't know, the way the game determines the indexes of the CPU points and checkpoints quadrilaterals (assuming they belong to the same group, and in this case, checkpoints are grouped in a single group) is simply by checking the order in which each entry is defined. For example, in the case of the CPU points (assuming they belong to the same group), the first point defined in the file (after the section header) is the point with index 0, the one that comes after it, index 1, the next one, index 2, and so on. In the case of old_mario_gc_narita, the first point defined is positioned before the start line, the second one, right before it (in the jump), and so on, following the course in reverse.

So now that we have discarded any issues with the KMP itself, these are my theories on why this happens:

• The course was originally rotated backwards: When comparing the early versions of GCN Mario Circuit with the final version, they are rotated 180 degrees. Which might explain the reason why the starting point is backwards for example. However, this is unlikely in my opinion, because if you rotate the whole course, sure, the rotation will match, but the position will be completely different. Not only that, but both the CPU points and checkpoints follow the course as it is stored in the file, and not rotated (which would misposition all of those entries out of bounds).

• The code for parsing KMP files worked differently at the time. The point entries were indexed in reverse: It is true that the code of the game might have been different at the time, and so the order of the points might have been determined from the last to the first entry. Now all we can do really is speculate on this one, since we don't have any evidence on this.

• It was a developer oversight: Discarding any issue with the KMP or how the code worked when this version was made, all there is left to speculate is that this was an oversight from the developer. Maybe they weren't told about the correct orientation of the course?

• • One fact to support this is how the lap counter checkpoint is placed before the finish line. Because of this, the lap can only count if the course is driven backwards. In order to be able to drive forwards and make the lap count, this lap counter checkpoint has to be put in front of the line.

Differences between old_mario_gc_hayasi and yabuki's (0x0640) and the final (0x09D8) KMP versions

KMP (Parameters) format

General

The older version only defines 8 sections: KTPT, ENPT, CKPT, CKPH, GOBJ, POTI, AREA and CAME. The final version in the other hand, has the following additional sections: ENPH, ITPT, ITPH, JGPT, CNPT, MSPT and STGI; adding up to a total of 15 sections.

KTPT (Starting point)

The section header that is common in all sections only consisted of the magic here. The section data starts inmediately after it. This likely indicates that at this point of time multiple starting positions (used in Battle mode for example) were not implemented.

ENPT (CPU points)

Each entry only has position data for the X, Y and Z coordinates (3 single-precision floats). A few extra parameters (such as the width in which the CPU can navigate and a few other settings like when should the CPUs use a Mushroom, do a wheelie, etc.) are missing.

AREA (activators) and CAME (cameras)

In the older format, both sections are 4 bytes shorter.

• In the case of the AREA section, the Route ID (RailID) (byte), Enemy point ID (EneLinkID) (byte), and the last two bytes fields are not implemented (section size = 0x2C)
• In the case of the CAME section, the field that indicates the time that a camera has been active (the last 4 bytes of each entry) is not present (section size = 0x44)

Differences between old_mario_gc_narita (unknown version) and the final (0x09D8) KMP versions

KMP (Parameters) format

General

• The older version only defines 6 sections: KTPT, ENPT, CKPT, CKPH, GOBJ and POTI. The final version in the other hand, has the following additional sections: ENPH, ITPT, ITPH, AREA, CAME, JGPT, CNPT, MSPT and STGI; adding up to a total of 15 sections.

• The older version lacks the "version number" field, so we can't tell which version this is exactly.
  It is possible that this version of the format is earlier than the ones from old_mario_gc_hayasi and yabuki though, given how its format is pretty similar, but defines less sections, and is lacking this "version number" field (unlike with all other versions of the format found in the game).

KTPT (Starting point)

Much like with old_mario_gc_hayasi and yabuki, the section header that is common in all sections only consisted of the magic here. The section data starts inmediately after it. This likely indicates that at this point of time multiple starting positions (used in Battle mode for example) were not implemented.

ENPT (CPU points)

Much like with old_mario_gc_hayasi and yabuki, each entry only has position data for the X, Y and Z coordinates (3 single-precision floats). A few extra parameters (such as the width in which the CPU can navigate and a few other settings like when should the CPUs use a Mushroom, do a wheelie, etc.) are missing.

About Mario Kart Wii's Special Ghosts

Special Ghosts (スペシャルゴースト in Japanese / 스페셜 고스트 in Korean) were a feature in Mario Kart Wii in which Nintendo would deliver ghosts themselves through the Internet. It is mentioned in some of the game's text, and the Mario Kart Channel also has some icon files stored for it (above). TCRF.net article.

For a long time, many of us believed it was an unused feature, since there is barely any mention at all of them (in English) on the Internet. However, as it turns out, they actually existed!

Kim Bum (김범) (Korea)

History

On April-May 2009 (a few days after the game came out in Korea) a ghost of South Korean actor and model Kim Bum (김범) was delivered to Korean Wiis, alongside a letter to the Wii Message Board. He appeared in several Mario Kart Wii Korean commercials, such as this one and this one (extended version).

This was promoted by Nintendo in Mario Kart Wii's official Korean website. At the bottom of that page, there's a little button with the Special Ghost icon on it. Clicking on there will take you to a Flash video of Kim Bum stablishing the record. While the website has long been taken down, the video in question can still be seen here (A mirror is available here and here)

The letter sent to the Wii Message Board can be seen here. Direct link to image 1 Direct link to image 2. (Mirrors are available here and here respectively).
The ghost metadata can be seen in that website too. Direct link to the image.

The ghost and Mii

Ghost

This ghost is preserved on Ninrankings.org! Download

IMPORTANT: Because Ninrankings.org changes the drift type of every ghost that is uploaded there to Manual and the ghost type to 0x27 (expert staff ghost), I had to manually change the drift type to Automatic and the ghost type to 0x05 in the ghost file, so that the playback is correct (and obviously to match the official video footage too, see above), that's why the filename includes "automatic_modded_and_type". This only requires changing a few bits though, and after that, recalculating the checksum (changing 4 bytes at the end of the file). No other data was modified at all.

If you still want to get the original ghost file from Ninrankings.org, here's the original download link.

The metadata of the ghost is as follows:

• Course: Luigi Circuit
• Character: Medium Mii, Male, Outfit A
• Vehicle: Standard Kart M
• Controller: Wii Wheel
• Drift Type: Automatic
• Country: (Disabled location sharing)
• Region: (Disabled location sharing)
• Date: saturday, April 4 2009 (26 days before the game came out in Korea)
• Ghost Type: 0x05
• Finishing Time: 01:27.489
• Lap 1: 00:30.069
• Lap 2: 00:28.192
• Lap 3: 00:29.228
• Mushrooms used per lap: 2-1-0
• Total number of frames: 5485
• Checksum (CRC-32): 0x71B393CD

Mii

The ghost file includes the full Mii data. This Mii also appeared in the letter that was sent to the Wii Message Board (see above). Download. Instructions on how to make the Mii from scratch can be found here

The metadata of the Mii is as follows:

• Name: 김범 (Can only be seen properly in the Korean version of the game. Otherwise two boxes with question marks will be displayed.)
• Creator name: (Not set)
• Birthday: (Not set)
• Gender: Male
• Favorite: No
• Favorite color: Dark green
• Mingle: Off
• Mii ID (in hexadecimal): 81-87-fc-82
• Date of creation(*): saturday, April 4 2009, 7:34:32 (AM)
• System ID (in hexadecimal): 03-98-7d-d9
• Special Mii: No
• Height: 104 (0x68)
• Weight: 31 (0x1F)
• CRC16-CCITT-XModem checksum (at 0x86 in the ghost file): 0xD096

(*) https://twitter.com/B_squo/status/1421790512718225410

Medaka Ikeno (池乃めだか) (Japan)

Frame of the video of Ikeno-san racing the ghost (from Wii.com's japanese Mario Kart Wii website)

History

On April 16th, 2008 (roughly a week after the game came out in Japan) a ghost of Japanese actor and comedian Medaka Ikeno (池乃めだか) was delivered to Japanese Wiis, alongside a letter to the Wii Message Board. He appeared in several Mario Kart Wii Japanese commercials, such as this one.

This was promoted by Nintendo in their official Wii website, together with a Flash video. While the website has long been taken down, the video in question can still be seen here (check the description for download links and mirrors)
According to the description in the video page, Ikeno-san was asked to record this ghost in the dressing room where they recorded the TV commercials.

The ghost

As mentioned by several websites from back in the day, the ghost metadata is the following:

• Course: Luigi Circuit (ルイージサーキット in Japanese)
• Time: 01:36.157
• Mii Name: ★めだか
• Country: Japan
• Character: Small Mii (Male Outfit A?, see the videos below)
• Vehicle: Quacker
• Controller: Wii Wheel
• Drift Type: Very likely Automatic (see the videos below)
• Ghost Type: 0x05 (this is the ghost type ID for special ghosts)

The Mii used in this ghost also appears in one of the Japanese commercials.

This article contains images of the letter sent to Wiis alongisde the ghost, as well as the Mii used and the record as seen in the Rankings menu. A few more images can be found here, which shows the Time Trial card for this ghost (direct link to the image). This website shows a little bit more of the ghost's letter (direct link to the image).

So far, I was able to find three videos showcasing the ghost: this one, this one and this one.

Other

• One of the official Korean trailers shows the special ghost icon and messages.
• Special Ghosts seem to have unique sound effects for the bubbles that appear for them in the Rankings menu (labeled SE_UI_RANK_ENTER_FAMOUS and SE_UI_RANK_BTN_IN_FAMOUS respectively). The "FAMOUS" string implies that special ghosts were indeed meant to be celebrities' ghosts, which is also proven by how the two ghosts mentioned above were played by celebrities.

Conclusions

While the ghosts mentioned above are the only ones known to exist, there is the possibility that more special ghosts (presumably from other actors that appeared in the Japanese/Korean commercials, such as the ones listed here and here) could have been delivered.

If you know anything more about Special Ghosts (or have received these, or even, another special ghost back in the day), feel free to message me on Discord! (at the top of the page)

loser_demo (Losing version of Mario Circuit) vs. castle_course (Final Mario Circuit)

To do: Investigate the multiplayer version.

Twitter thread

loser_demo.szs (the version of Mario Circuit that is loaded when losing a Grand Prix/VS Race/Battle) is very interesting because it represents an earlier version of the course! This is almost imperceptible in gameplay, but looking further at the course data reveals quite a few elements that were seen in the E3 2007/Fall 2007 Press Conference versions of the course that are missing or were changed in the final version. This section will discuss the differences found between loser_demo and the final (single player) version of Mario Circuit.

NOTE:

• Keep in mind that, while similar, loser_demo is not 100% identical to the E3 version, so we can't really call it the "E3 version" itself.
• Only the elements that are found in both versions of the course will be mentioned. For example, some things, such as checkpoints, and some objects like the Chain Chomp and item boxes, are not found in loser_demo, as they cannot be seen in its associated cutscene, and thus are not really needed.
  • In the same way, if there is a resource that is found between both versions but it's not mentioned, then it is assumed that it is byte-to-byte identical between both versions. For example, most textures are the same between both versions, so this article will only contain the textures that are different.

Models

course_model.brres (Course model)

Overview
loser_demo	Final
Wireframe
loser_demo	Final

Many small differences can be found in the geometry and texture mapping of some parts of the course model. A list of much of them can be found in this Twitter thread. Some examples are listed below:

• The crosswalk placement was changed between both versions. Curiously, the Goombas were originally supposed to walk across these, as seen in the E3 2007 version of the course. In fact, the placement of the second Goomba in the final version makes more sense when loaded over loser_demo's course model, as seen here.
• One additional bush is present in loser_demo, under the tree that can be found in the area with the Jump Boost Pad.
• The location of some of the static 3D flowers have different positions between loser_demo and the final version.

loser_demo	Final

• The texture mapping of the grass next to the road is different in some parts of the course. Some of the white walls also look less stretched in loser_demo, as seen above.
• Some polygons were missing, and the vertex shading was slightly different in a few selected places.

vrcorn_model.brres (Skybox model)

In the material settings, the FogIndex parameter (under the SCN0 References) is 0 in loser_demo, while -1 in the final version. This has seemingly no effect in-game, as none of the courses have a SCN0 file in the first place.

Textures

loser_demo	Final

The "M" in the flags found on top of the castle had a different design. In the final version, it was changed to the stylized "M" seen on Mario's cap.

loser_demo	Final

	loser_demo	Final
Filename	p_union_A17km.tex0	p_union_A33k.tex0

• Many of the billboards say MarioKart (stylized like the Nintendo logo) in loser_demo, all of which were changed to MARIO.
• The cloud texture is a little bit darker in the final version.
• The "?" on top of the item boxes were removed in the final version, and the colors of both boxes are very slightly less saturated as well.

loser_demo	Final

	loser_demo	Final
Filename	p_union_C45k.tex0	p_union_C51k.tex0

The colors of the finish line texture are a bit more saturated in the final version.

loser_demo	Final

	loser_demo	Final
Filename	p_unionE15.tex0	p_unionE17.tex0

The start line banner was made slightly darker in the final version. The Mario picture is also a bit different with Mario being slightly shorter in the final version.

In addition, the purple chimney hole was also made a bit more saturated in the final version.

loser_demo	Final

	loser_demo	Final
Filename	t_kabe_sita_047.tex0	t_kabe_sita_048.tex0

The semi-transparent dark outline is less scattered in the final version.

loser_demo	Final

	loser_demo	Final
Filename	t_road_i04f6k2.tex0	t_road_i04f6k3.tex0

loser_demo	Final

	loser_demo	Final
Filename	t_road_i21f6k2.tex0	t_road_i21f6k3.tex0

loser_demo	Final

	loser_demo	Final
Filename	t_road_i40f6k2.tex0	t_road_i40f6k3.tex0

The road textures were made very slightly less saturated in the final version (increase the brightness of your screen, and quickly toggle between both images to see it).

loser_demo	Final

• The shadows of a couple of the trees were made smaller and more circular in the final version.
• One of the flower's shadow in the northern part of the course was moved in the final version, since the object was also moved in comparison with loser_demo (see below).
• In addition to that, several other flower shadows that did not match the actual flower positions in loser_demo were moved (and a few of them were removed) in the final version to better match the final course layout. Interestingly, most of these are leftovers from the E3/Fall 2007 Press Conference footage, as flowers (such as the one seen in the left at the beginning of the course) can be seen in those spots from the loser_demo shadow map.

Lighting and Post-processing effects

loser_demo	Final

Outside, the bloom effect is noticeably more widespread in the final version than in loser_demo. When driving under shadows, the ambience lighting is brighter in loser_demo than in the final version. This cannot be seen in loser_demo however, as this version does not have shadowing effects. These can be seen in winningrun_demo (the version of Mario Circuit that is loadedwhen winning a Grand Prix), as that version has the same shadow parameters as loser_demo AND defines shadows.

loser_demo also lacks the blur effect seen in the areas farther away from the camera that appears in the final version, as it lacks a posteffect.bdof file.

The exact differences between the post-effects files are presented below:

• /./posteffect/posteffect.blight (Lighting)
  • The second ambiance light defined in loser_demo has an alpha value of 0xFF, while in the final version it was changed to 0x82. The third ambient light has the RGBA value of 0x3F4C5CFF in loser_demo, while in the final version, it was changed to 0x47586A3C (a bit lighter in comparison).
  • In the same way, the second and third lights objects defined in that file in loser_demo have an alpha value of 0xFF, while in the final version, the second light's alpha value was changed to 80, and the third one, to 64. In addition, each light object entry is in version 0x01 in loser_demo, while in the final version, it is 0x02. It is unknown what the exact difference between both versions is, however.

• /./posteffect/posteffect.bblm (bloom and glow)

To do: Write the meaning of these differences once the format is figured out.

Offset	loser_demo	Final
0x0C	806F5A34	00000000
0x9C	3F000000	3F333333
0xA0	3D880000	3D75C28F

• /./posteffect/posteffect.blmap (Environment mapping controller) (exclusive to loser_demo)

To do: Write the meaning of these differences once the format is figured out.

References the lm_0 texture (not present in the course file).

Collision (course.kcl)

loser_demo	Final

One wall was added in the final version near the end of the course at the left.

loser_demo	Final

Just like with the regular course model, in the off-road section in the right of the road near the final curve of the course, some polygons were added in the final version. In the wall in front of that, another polygon was added, and two polygons were flipped near the end of the course at the right.

In addition to these, the shadows do not give a shadowing effect in loser_demo, as they are not defined in the collision model, unlike in the final version (seen in some of the screenshots above). Even then, loser_demo's collision does indeed have the geometry for the shadows in place, as seen above.

Parameters (course.kmp)

loser_demo uses a slightly earlier version of the KMP format (0x09CE instead of 0x09D8). No apparent differences to the final version of the format can be seen, however, so the game still parses the parameters correctly.

Respawn Point (JGPT)

loser_demo	Final

The respawn point was moved a bit backwards and was better centered in the final version.

Objects (GOBJ)

DummyPole (Lamp post collision)

In loser_demo, the collision flag set for these objects is "regular wall" (first object setting is 0), while in the final version, it is set to "metallic wall" (first object setting is 2).

castletree1 (3D tree) and castletree2 (2D tree)

loser_demo	Final

In loser_demo, there is a 2D tree located in the center of the area with the houses in the northern part of the course. This object was seemingly replaced by a 3D tree in the final version, as the 2D tree was removed, and the 3D one is located in almost the exact same position (albeit with different rotation).

Additionally, all of the instances of both tree objects in loser_demo have their "presence value" set to 0x3F (always visible), while in the final version this value is set to 0x09 (meaning they will appear in single player modes only, so they'll be disabled in multiplayer).

castleflower1 (3D flower)

	loser_demo	Final
Fourth 3D flower's Y Position	3208.649	3208.65

The fourth 3D flower defined (the one found in the right of the starting line), has been very slightly positioned more upwards in the final version...

loser_demo	Final

...while the fourth 3D flower has a different position altogether (highlighted above in red).

Additionally, all of the instances of this object in loser_demo have their "presence value" set to 0x3F (always visible), while in the final version this value is set to 0x09 (meaning they will appear in single player modes only, so they'll be disabled in multiplayer).

Stage Info (STGI)

Unseen Starting Point Setting

Something that cannot be seen in loser_demo is that the racers in the starting line should be placed starting from the left instead of the right (as the byte that cintrols that is set to 00 instead of 01). This can't be seen because this version of the course already defines individual starting points where most players should appear.

Lens Colors

To do: Get comparison picture of this

	loser_demo	Final
Sun flare lighting color value (RGBA)	0xE6E6E64B	0xE6E6E632

The lighting color that covers the screen when looking at the sun is a bit more opaque in loser_demo. This can't be seen however, as loser_demo does not have the object for said effect defined.

Model and Texture Animations

vrcorn_model.brres/vrcorn.srt0 (Skybox's texture animation)

	loser_demo	Final
Skybox texture animation's frame count	1500	2249

The skybox texture rotates faster in loser_demo than in the final version, as its animation has less frames.

castleflower1.brres/castleflower1.chr0 (3D flower's animation)

Some of the keyframes have very slightly different rotation and positioning (for example, in loser_demo, frame 98 of the Hm_body45 bone (which rotates the stem) has the X rotation set to -4.434772, while in the final version, it is -4.544624). This change is pretty much unnoticeable to the naked eye, however.

castletree1.brres/castletree1.chr0 (3D tree's animation)

	loser_demo	Final
Frame 18's Z rotation	-2.734277	-2.753552

In the final version, the Z rotation of frame 18 was made very slightly more rotated towards the right. This change is pretty much unnoticeable to the naked eye, however.

castletree2.brres/castletree2.chr0 (2D tree's animation)

Some of the keyframes have very slightly different rotation and positioning (for example, in loser_demo, frame 18 has the Z rotation set to -2.734277, while in the final version, it is -2.753552). This change is pretty much unnoticeable to the naked eye, however.

Details on my Gctr_MarioCircuit_Divide restoration attempt

• Download (Citra Emulator only)

• Download (CTGP-7 compatible). This version of the restoration was prepared by PabloMK7. It allows you to use the restoration with CTGP-7's "Custom Cup" system to be able to play it on an actual console. Click on the link for more details on how to install it.

• TCRF Article

This is my attempt on restoring the contents of Gctr_MarioCircuit_Divide.szs, with the objective of making an (accurate) playable version of the course that can be played in the final version of the game, over the Mario Circuit slot.

NOTE: Only the files that had "Gctr_MarioCircuit_Divide" in their filename have been taken into account for this restoration. There are two extra files in the "Gctr_MarioCircuit_Divide.szs" archive, named Gctr_MarioCircuit.bclgt and Gctr_MarioCircuit.kcl. However, these seem to be from another iteration of Mario Circuit, so they haven't been taken into account for this restoration.

General

Luckily, most files from the Gctr_MarioCircuit_Divide.szs archive will work just fine in the final version of the game, so those have been added to the restoration as is, without being modified in any shape or form.

However, other files needed to be modified or added into the restoration, in order to make it work properly. These are listed below:

Filenames

The files that had "Gctr_MarioCircuit_Divide" in their filenames had to be changed to "Gctr_MarioCircuit". This is necessary for the restoration to work over the Mario Circuit slot (this wasn't done for the CTGP-7 compatible version, as it supports loading courses with different internal names).

Course model (Gctr_MarioCircuit.bcmdl)

The course model alone crashes the game. This is because its internal name (Gctr_MarioCircuit_Divide) doesn't match the internal name for the final Mario Circuit course (Gctr_MarioCircuit), so the game will crash at the instruction Field::FieldModel::attachCells(Field::QuadTree*) + A4 (located at RAM address 0x0033F450 (EUR Rev0 v1.1))

In order for the course model to work, not only the file itself had to be renamed from "Gctr_MarioCircuit_Divide.bcmdl" to "Gctr_MarioCircuit.bcmdl", but its internal model (CMDL) name (which starts at 0x10A74 in said file) also had to be changed as well from "Gctr_MarioCircuit_Divide" to "Gctr_MarioCircuit".

To do this, I removed the "_Divide" part of the string by replacing their bytes with 00, so that only the "Gctr_MarioCircuit" part is taken into account by the game.

However, sadly, even after doing this, the game still crashes in the same instruction that was mentioned above, so either I'm doing it wrong or this is not enough to fix it. This is the only thing that is preventing the restoration to work on real hardware. Everything else works just fine.

The CTGP-7 compatible restoration (see above) will work on an actual console with the CTGP-7 mod installed, as it supports loading courses with different internal names. Keep in mind that currently it will only work with CTGP-7. Other file replacing methods, such as Luma CFW's, will still make the game crash.

Course parameters (Gctr_MarioCircuit.kmp)

The course parameters (KMP) format is in an slightly earlier version, which makes the final game crash.

In this restoration, for each Object entry, these 4 bytes have been added at the end to prevent the crash: FFFF0000. I added these bytes specifically since, in the final version of the track, these values are what every object has at the end of each respective entry.

The other thing that is technically inaccurate is that I left the checkpoints from the final version of Mario Circuit in this restoration (sections TPKC and HPKC, the original file had these sections empty). I left these because the original file has replay cameras that can only be viewed when completing the course, so checkpoints must be placed in the track in order to complete the course and view them.
If you want to remove these to make it more accurate the original file, then open the Gctr_MarioCircuit.kmp, go to the addresses 0x83 and 0x9BC, and overwrite the value there with 00.

Other than what was mentioned above, the rest of the data in the KMP has been copied from the original file into the restoration, so it's 1:1 accurate to the original file. Be cautious not to fall on the water or out of bounds, since this track doesn't have respawn points.

Added files and folders

The following files and folders have been added to the restoration. All of these needed to be added, since they're needed for most objects defined in the course parameters to be displayed correctly in-game:

• CmnDokan1/CmnDokan1.bcmdl
• CmnKinoko1/CmnKinoko1.bcmdl
• CmnTree1/CmnTree1.bcmdl
• CmnVR1/CmnVR1.bcmdl
• kuribo/kuribo.bcmdl

Minimap (Gctr_MarioCircuit_map.bclim, Gctr_MarioCircuit_map2.bclim and UIMapPos.bin)

Gctr_MarioCircuit_Divide.szs handles minimaps differently to how they are handled in the final version.

In the early version, the minimap is stored as a 3D model (in the same way as Mario Kart Wii did), named Gctr_MarioCircuit_Divide_map.bcmdl.

In the final version, the minimap image are stored in two separate files, named Gctr_MarioCircuit_map.bclim (simplified) and Gctr_MarioCircuit_map2.bclim (full). The position of the minimap is stored in another file as well, named UIMapPos.bin

For this restoration, I created a custom image for both the simplified and full minimap images. These images consists of a custom 3D render that I made from the minimap model file left in the original archive. It properly shows its vertex shading, so you can see the shadowing in some places, such as in the curve inside Peach's Castle.
For the positioning, I was originally considering to copy the position values of the original minimap model (the position values of the bones posLD and posRU) into UIMapPos.bin for (technically) more accuracy. However, this turned out to make positioning the minimap images much more time consuming, so what I ended up doing was to manually position the minimap images themselves, while keeping the UIMapPos.bin file intact from the final version of Mario Circuit.

Differences between Gctr_MarioCircuit_Divide's (0x0BB8) and the final (0x0C1C) KMP versions

KMP File Format

Version number

The version number for the KMP file in Gctr_MarioCircuit_Divide is 3000 (0x0BB8), instead of 3100 (0x0C1C) like in every other KMP in the final game.

Objects (JBOG)

In the Object section, each entry doesn't have the last 4 bytes (2 uint16) fields in the early version, which makes the final game crash. This makes each entry have a size of 0x3C, instead of 0x40 like in the final version.