---

- Added support for GP podium texts editing
- Added the ability to import and export all tracks (by mcintyre321)
- Added an alternative way to set the starting position second row offset
- Added a hack to work around Mono crashes, especially on Mac
- Fixed a ROM text loading edge case bug
- Improved the speed and compression rate of the Codec compressor
- Fixed error message handling when using the Codec
and trying to decompress from an invalid address

---

Posted by Googie

---

Here's P's new message...

---

Posted by Googie

---

I should give this SMK editor a try, I played this game to death in the 1990's.

---

Posted by Googie

---

I should give it a try and hack this game, the editor looks really easy to use.

---

Posted by gridatttack

---

I wonder, is it possible to change the assigned palette for the battle balloon object?

---

---

I thought this may as well be the time to figure out Ghost Valley pillars and I see how it works now. For the other courses I suppose you don't have to relocate the object positions since every course, even Ghost Valley, has 64 bytes of reserved space whether or not they use the objects. The object *zones* for all courses however I will relocate.

Ghost Valley pillars are more flexible and it works in a completely different way from the others. Instead of having ranges of checkpoints where one of four object zones are applied, it has a table with an entry for every checkpoint on the course. Each checkpoint is assigned a starting index where pillars will be loaded. It will then load the 4 pillars starting from that point. The starting index is into a variable length array of 2byte positions similar to what normal courses use.

for sake of documentation or if you want to mess around with it:
4DB83: 16bit pointers for each GV in order they appear (bank byte is $84)

Each pointer points to:
2 bytes: 2 byte pointer to checkpoint assigned table I just mentioned. The checkpoint # is used as the index.
2 bytes * n: the pillar positions, assume it's the same 7bit positioning other objects use. The checkpoint assignment *2 is used as an index into this data. Load 4 pillars starting from the given index.

Easiest way to make this more flexible is to assign some fixed number of bytes for all 20 tracks that could potentially be used for ghost valley pillars in the expanded ROM. 2 bytes are required to position a pillar, so say 256 bytes per course is enough for 128 pillars in a single course. There is no fixed number of pillars in GV, for every checkpoint you can potentially loaded up to 4 unique pillars. 128 checkpoints max means 512 possible pillars but that's really excessive. There is also the checkpoint assignment table that has to be stored.

---