DKC Atlas Forum

So, I recently created a couple of init script editors for DKC 2 and 3. Here, you just enter in the sprite code used in the editor. DKC 3 is a bit incomplete. Both use the 1.0 U version. Only pairs are editable, commands are not. This allows you to change key value pairs and save. Alternatively, the ROM address is given to you as well. This is actually a very powerful tool. You may be wondering, "What about DKC1?" I have already created a more featured one for DKC1, but that is integrated into my editor, which will be released shortly.

DKC2:
http://www.mediafire.com/view/9eqql2vx6 ... cripts.exe
DKC3:
http://www.mediafire.com/view/88unr53ka ... cripts.exe

Sounds interesting. What does it do? Screenshots please.

I am working ion my own editor too. Thanks to everyone though for the help.

Cyclone wrote:Sounds interesting. What does it do? Screenshots please.

This just takes a sprite pointer and loads it for you. Each line is a new index. Each index can either be a key-value, or a command. For key-values, the key just represents which byte of the sprite is looked at, and the value is what to assign there.

Notice in the top right a ROM address is given, so if yoou prefer, you can do all your edits in a hex editor.

ok so it loads a sprite pointer. What can you do with it?

Cyclone wrote:What can you do with it?

Change stuff. Kingizor? I'm bad at explaining myself.

The tools are capable of modifying parameters relating to different objects, in other words how objects behave.

The idea is that when an object is loaded it copies this list of data into RAM and runs different actions using that data each frame or so.

"pointer" refers to the ID of each object. The SDK2 and SDK3 editors both have a near full list of these (sprites.ini) which might make things a bit easier. It might be helpful if rainbow felt like integrating that data into the editor?


In the screenshot rainbow posted, he has loaded the object with ID 0x670, which is one kind of Bazza, typically seen in Bazza's Blockade. I believe you'd load that by typing 0670 in the box at the top-right and clicking "Search".

The first line probably refers to the ROM address where this data was loaded, in this case $FF92CA = 0x3F92CA. Following that is a list of commands for this particular object.

The first one is command F9, which says to load more behaviours from the address $92AA in the same bank. This section is marked as a subroutine, which implies that multiple objects may use this command. Specifically, this subroutine is probably common to all the different Bazza objects, so each one will load it with the same F9::92AA command.

The first key in the subroutine is FF with a value of 01F8. Just a guess, but this might be related to graphics or audio loading as they only need to be done once per object. Someone will probably correct me if that's not the case.

The bracketed keys ([5C], [5E], [60], etc) are behaviours that have an associated value. Each one will change how the object behaves, and this is the primary purpose of the editor.

As for what each one does, well we don't know that so some experimenting is required.

Code: Select all

[5C] - how many Bazzas are spawned at once
[5E] - the distance between spawns
[60] - how long it takes for a new spawn
[62] - ?
[38] - ?

Again, those behaviours are part of the 92AA subroutine, so they'll apply to all objects that use that subroutine.

Below that we have two more entries that aren't part of a subroutine, so we can deduce that they only apply to the 0670 object. Different Bazza objects might have different values for these.

Code: Select all

[64] - spawn position X
[66] - distance to travel before disappearing? (might be positive or negative depending on direction?)

If you're very lucky you can sometimes guess what one of these commands might do based on the value. Other times you can find out by changing it and observing what effect it has in-game. Sometimes different values have no obvious observable effect so they might require deeper code analysis.

Also be aware that values might not be interpreted as a number, but as a number of different bits that represent flags. e.g. if this bit is set do this, otherwise do this... etc. These are probably a bit less common but they might still come up. The 0670 Bazza object goes from right-to-left, whereas the ones that go from left-to-right have an additional [60] parameter might be flag-based.

—

I believe the main object commands have been covered in-depth before by someone, somewhere. The Fx commands in particular seem familiar, but I can't find anything about it right now.

If what I am reading is correct, this is the way to modify a script in DKC, as merely moving the scripts from their original position through RE would cause them to break. Until the script issues were resolved, we could only replace the script as a new object in the meantime.

Has that bug ever been discovered, by the way?

Thank you, Kingizor! I can springboard off your comments!

Kingizor wrote:"pointer" refers to the ID of each object. The SDK2 and SDK3 editors both have a near full list of these (sprites.ini) which might make things a bit easier. It might be helpful if rainbow felt like integrating that data into the editor?

Heard.

Kingizor wrote:
The first key in the subroutine is FF with a value of 01F8. Just a guess, but this might be related to graphics or audio loading as they only need to be done once per object. Someone will probably correct me if that's not the case.

Command FF actually has nothing to do with gfx. There is a separate command just for animation. What FF does, is sets bytes [00]-[05] of the object. 00, and 01 are id (01f8) and bytes 02-05 represent the address of the object that is executed each frame (b6b744).

Kingizor wrote:The bracketed keys ([5C], [5E], [60], etc) are behaviours that have an associated value. Each one will change how the object behaves, and this is the primary purpose of the editor.

As for what each one does, well we don't know that so some experimenting is required.

Code: Select all

[5C] - how many Bazzas are spawned at once
[5E] - the distance between spawns
[60] - how long it takes for a new spawn
[62] - ?
[38] - ?


Again, those behaviors are part of the 92AA subroutine, so they'll apply to all objects that use that subroutine.

Below that we have two more entries that aren't part of a subroutine, so we can deduce that they only apply to the 0670 object. Different Bazza objects might have different values for these.

Code: Select all

[64] - spawn position X
[66] - distance to travel before disappearing? (might be positive or negative depending on direction?)


[38] is used for all sprites and represents the status/mode of the object. This value can fluctuate at runtime.
In this case, I'd like to correct a couple.
[64] is not spawn position, but it is related to despawn position.
[66] is the spawning speed of x of the bazza.
I think you just mixed up [64] and [66]!

VideoViking wrote:If what I am reading is correct, this is the way to modify a script in DKC, as merely moving the scripts from their original position through RE would cause them to break. Until the script issues were resolved, we could only replace the script as a new object in the meantime.

Has that bug ever been discovered, by the way?

I'm not sure what the bug you reference is...
It's no wonder scripts broke if you moved them in dkc1! Scripts are pointed to by the object code in bank b5. So the first Gnawty in 1-1 is b413. This points to b5b413. If the right code isn't there, bad things happen, as you've seen.

In dkc2 (and 3 by extension) a similar thing happens. For dkc2, there is an array of 16-bit pointers at fbe800. Each pointer points to a script. Think of it like the command Kingizor mentioned: f9. Call. By using this array, multiple codes can point to the same script.