Register - Login
Views: 87822067
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - JCS - Stats - Latest Posts - Color Chart - Smilies
12-14-17 08:20:31 AM

Jul - SM64 Hacking - Behaviour Scripts New poll - New thread - New reply
Pages: 1 2 3 4 5Next newer thread | Next older thread
yoshiman
Member
Level: 22


Posts: 43/95
EXP: 55907
For next: 2443

Since: 12-21-07
From: London, England

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 03-20-08 09:01:09 PM (last edited by yoshiman at 03-21-08 07:44 PM) Link | Quote
I finally had time to look at what VL-Tone calls in his doc 'behaviour scripts' but they are nothing more than short assembly language routines so I can tell you exactly what is happening. From his doc he writes:

The 0x0C command calls ASM functions found in RAM.

[0C] [00 00 00] [80 2A CC 3C]

[0]= 0C is the command byte.
[1,2,3]= Always zero, unused?
[4,5,6,7]= Offset in RAM of the ASM function.

I can tell you that 0x0C is the ASM JAL (Jump And Link, a procedure call) and the three bytes [1,2,3] are always zero so that translates to JAL 0x80000000. Because of the delay slot the next instruction is also executed which VL-Tone calls the offset in RAM of the ASM function and that's where I'm confused.

It does look like a pointer to ASM and indeed of the ones I've checked there is coding there but it's actually an instruction that supposedly is the offset in RAM, the instruction loads a byte into a register; the offset is half the address. I'll stop there and not go into any more detail unless you want me to as to be kind to those who are unfamiliar with MIPS ASM.

In a RAM object there seems to be 3 behaviour pointers which is somewhat supported by VL-Tone's doc. Change these values and the object behaves differently but if you swap the behaviour values in the scripts it has a global effect so that, for e.g., all Bob-ombs act like Goombas! I guess you could do the same with a ROM hack which essentially is what Toad's Tool does.

What my finding means is that I can look at any object in the RAM and identify what the behaviour is but that of course means there has to be an object that uses that type of behaviour.

But I now have doubts if it is pure ASM because it doesn't make sense even converted from C. What it seems to do, apart from the call to the behaviour coding, is set the state of certain variables in each RAM object that uses that type of behaviour.

Taken from VL-TONE's doc for the Toad message behaviour:

21CCFC/002EFC 11 01 40 49

The 4049 is copied to the variable in the Toad object that determines how it reacts to Mario.

I hope this is of help and I'd be happy to add more if you want me to.

James S.
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 189/621
EXP: 953018
For next: 60920

Since: 07-27-07
From: Montreal, Canada

Since last post: 107 days
Last activity: 76 days

Posted on 03-24-08 12:36:14 AM Link | Quote
Very interesting stuff James, we're closer and closer to crack open the behavior system.

I knew that command 0x11 was used to load values into registers (and command 0x10 also), but I never investigated much into what was loaded. I thought that the 0x0C command was the only thing that determined the actual behavior, but it seems that the 0x11 command is also a key to this process.

I'd like to know more about that 0x0C offset/instruction thing, even though I'm not proficient in MIPS assembly code.

yoshiman
Member
Level: 22


Posts: 44/95
EXP: 55907
For next: 2443

Since: 12-21-07
From: London, England

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 03-24-08 07:46:02 PM Link | Quote
Thanks VL-TONE for your doc as I was changing behaviours with codes but when I looked at your doc and investigated something clicked. I will try to work out what more of the scripts do. Maybe Nintendo thought they'd use the same code value for a call to ASM that's used in the script but added the zero padding. In ASM the 0x0Cxxxxxx is jal which doesn't use an actual address like in the script but instead divides it by four (the length of an instruction).

James S.
Rena

Star Mario
Fennel
Level: 127


Posts: 2479/5239
EXP: 23369310
For next: 357256

Since: 07-22-07
From: RSP Segment 6

Since last post: 117 days
Last activity: 75 days

Posted on 03-25-08 03:37:14 AM Link | Quote
I find it unlikely that the 0x0C000000 is actually interpreted as an instruction. You say that one for example would jump to 0x802ACC3C? If that were the case I don't see why they would store the instruction and address separately like that.

What it could be doing is reading the 0x0C0000000 and ORing it with some other value to produce a JAL instruction. In this case it makes more sense. Rather than explicitly loading 0x0C000000 into a register, the game saves a cycle by making the command byte 0x0C and having 3 bytes after it that are always zero, so there is already a register (the one holding the command byte) with the required value. Mario Kart does this often. Why, I don't know, as it trades a fair chunk of ROM space for an extremely tiny performance gain, but eh... dumb optimizing compiler I guess.

If you mean 0x802ACC3C has a pointer to code, then that may well be what it's doing. If not, then it's possible they had some reason to store the raw RAM address and combine it into an instruction at runtime instead of just storing the result. Possibly another routine reads it and needs the RAM address. What happens if you set those zero bytes to other values? Try setting the last one to 0x01 and see if it jumps to 0x802ACC40 instead, or crashes.
yoshiman
Member
Level: 22


Posts: 45/95
EXP: 55907
For next: 2443

Since: 12-21-07
From: London, England

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 03-25-08 07:23:13 PM Link | Quote
Your reasoning is valid and now I see it not as instructions but it's strange they used the same value for the jal (0x0C) as they did for a jump to ASM in the script. I assumed that the behaviour pointers in a RAM object were to ASM but instead they are to different parts of a behaviour script. So the calls are to ASM in the behaviour scripts but had it been an ASM instruction the address would have been stored differently.

James S.
messiaen
Catgirl
Level: 64


Posts: 16/1085
EXP: 2167095
For next: 47002

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 04-03-08 11:46:47 AM (last edited by messiaen at 04-08-08 01:15 PM) Link | Quote
Hi, I think I've discovered the function of another behaviour command.

Quoting VL-Tone from Editing the RAM objects thread:

"While some object indeed have polygonal collision maps (levels, platforms, boxes etc.), many enemies and Mario himself don't use polygons for collision detection. Because of the complexity of the body, and the fact that it's animated, a spherical collision bubble is instead used. There's no polygon involved, it's only a matter of detecting a collision if the distance between objects is less than X. This is how most 3d games worked until more recently when more powerful and precise physics engines were implemented in games"

That is what the 0x23 command seems to do (sets a collision sphere).

The format is [23] [00 00 00] [??] [?? ?? ??]

[0] = 23 is the command byte.
[1,2,3] = Always zero, unused?
[4] = 00 or 01 (?)
[5,6,7]= Some kind of coordinates?

On a somewhat related note, both the Tree and Pole Grabbing behaviour share the same 0x0C, which is what happens when you step on the area defined by the 0x23 command:

ROM Addr: 00219F44 Hex Behav: 13000144
Description: Pole Grabbing
219F68/000168 0C 00 00 00 80 2C 63 E8

ROM Addr: 0021C8A4 Hex Behav: 13002AA4
Description: Tree Behavior
21C8C4/002AC4 0C 00 00 00 80 2C 63 E8

This could shed some light about:

ROM Addr: 0021E3F8 Hex Behav: 130045F8
>>>>>>>>>>Unused Behavior?

Which also has the same "0C 00 00 00 80 2C 63 E8". This behaviour also has a 0x27 animation command. So, what else in the game has animation and at the same time can be "grabbed"?

---

Edit: Hi, another small discovery! In many behaviours which contain the 0x23 command, there is of course some action associated. I thought that action was determined only by the 0xC command, like the supposed "pole grabbing/tree grabbing" shared 0x0C command. However, 0x10 also plays a big role!

I first thought 10 2A 00 [XX] would determine what Mario state (while in the collision sphere area determined by 0x23) would trigger the related 0x0C action. For instance, in the Tree behaviour (see below), we have 10 2A 00 40 [Hmm, 2A, doesn't that sound somewhat familiar?], and the 40 byte means jumping state. If you change it to 02, action will only occur when you "PUNCH" the collision sphere. And if you change the last byte to "04", action will occur when you WALK on the collision sphere.

The amazing thing is that when you change 10 2A 00 40 to 10 2A 00 04 in the Tree behaviour, Mario won't climb the tree when you walk into it, but instead it will open it like a door and go to the other side. If you change the last byte to 02, you will be able to GRAB the tree with you! I thought a specific 0x0C call was needed to change the action!

ROM Addr: 0021C8A4 Hex Behav: 13002AA4
Description: Tree Behavior
21C8A4/002AA4 00 0A 00 00
21C8A8/002AA8 21 00 00 00
21C8AC/002AAC 11 01 00 01
21C8B0/002AB0 10 2A 00 40
21C8B4/002AB4 23 00 00 00 00 50 01 F4
21C8BC/002ABC 10 05 00 00
21C8C0/002AC0 08 00 00 00
21C8C4/002AC4 0C 00 00 00 80 2C 63 E8
21C8CC/002ACC 09 00 00 00

Also, if you change the 10 2A 00 02 command in the King Bob-omb behaviour to 10 2A 00 40, you won't be able to punch him from the back and grab him. However, if you JUMP on him from the back, you will CLIMB him, like the pole grabbing behaviour! So, the 0x10 is worth studying, for now one could mess just with the "10 2A" command, in objects which have collision spheres.

I hope that was useful!
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 196/621
EXP: 953018
For next: 60920

Since: 07-27-07
From: Montreal, Canada

Since last post: 107 days
Last activity: 76 days

Posted on 04-03-08 09:46:59 PM Link | Quote
Wow, these are very interesting discoveries.

I actually knew about the 0x23 command, I just didn't document it. Mario's got a 0x23 command too! It doesn't affect it's actual collision with platforms and the terrain, but it affects the range of his interactions with enemies and such.

But what you found about the use of the 0x10 in combination with the 0x23 command is something I didn't know about. I wish I had time to experiment with it. Maybe this week-end if I'm not too tired from my work week.

I begin to suspect that the 0x10 (and 0x11) commands are used to write values to "RAM objects", you know, the objects that yoshiman knows a lot about. I guess that the second byte of the 0x10 command determines the offset of the write in the RAM object (it may be multiplied by two because they are 16-bits values). So depending of this offset you may modify different object properties. I think it's the case because RAM objects include properties such as the ones you seemed to modify in your experiments.
CellarDweller
Random nobody
Level: 6


Posts: 4/5
EXP: 686
For next: 221

Since: 08-15-07
From: Arkansas

Since last post: 9.0 years
Last activity: 8.0 years

Posted on 04-04-08 04:11:26 AM (last edited by CellarDweller at 04-04-08 09:01 PM) Link | Quote
Originally posted by VL-Tone
I begin to suspect that the 0x10 (and 0x11) commands are used to write values to "RAM objects", you know, the objects that yoshiman knows a lot about. I guess that the second byte of the 0x10 command determines the offset of the write in the RAM object (it may be multiplied by two because they are 16-bits values). So depending of this offset you may modify different object properties. I think it's the case because RAM objects include properties such as the ones you seemed to modify in your experiments.


Funny you should bring that up. I have been disassembling some of the functions that process behavior scripts. There are at least four (there are almost certainly more) that take an index into the the object's RAM structure in the second byte. These commands work on 32 bit fields of the structure. (offset = index*4 + 0x88)

0x0e -- converts a signed 16 bit integer to a 32 bit float and saves it at the specified index
0x10 -- converts a signed 16 bit integer to a 32 bit integer and saves it at the specified index
0x11 -- ORs the specified 16 bits with the lower 16 bits at the specified index
0x27 -- copies a 32 bit value to the specified index

A few known index values:
0x06, 0x07,0x08 -- position (float)
0x12, 0x13, 0x14 -- rotation (int)
0x26 -- Animation pointer (segmented address) (from SM64Behaviors.txt)
0x45 -- Disappear distance (float) (found by matching my notes with HyperHacker's old ones)

EDIT: another such command
0x0f -- adds a signed 16 bit integer to the 32 bit integer at the specified index
VL-Tone
Member
Super Mario 64 forum moderator
Level: 51


Posts: 199/621
EXP: 953018
For next: 60920

Since: 07-27-07
From: Montreal, Canada

Since last post: 107 days
Last activity: 76 days

Posted on 04-05-08 01:11:14 PM Link | Quote
Wow Cellar, thanks for this info... There's a lot of interesting stuff that may come out of this.

It means that we can now apply some of yoshiman's (yoshielectron) gameshark hacks in a permanent way in the ROM.

Maybe someday I'll make a behavior script editor that works a little like my StarFox level editor. Actually, I'm very proud of that StarFox script editor interface, even though it made the editor too hard to use because it was the only way to edit things. (I don't know of anybody that created a new level with it).
+c0

Level: 10


Posts: 9/17
EXP: 4311
For next: 103

Since: 08-05-07
From: Nowhere.

Since last post: 6.0 years
Last activity: 6.0 years

Posted on 04-06-08 12:01:29 PM Link | Quote
*cough*

I think this would be the right area, As i did hack the Pole Grabbing behavior to do this..

http://www.youtube.com/watch?v=SECw6fB3vQY

Hoot the Owl in Bob-omb Battlefield.

Rena

Star Mario
Fennel
Level: 127


Posts: 2556/5239
EXP: 23369310
For next: 357256

Since: 07-22-07
From: RSP Segment 6

Since last post: 117 days
Last activity: 75 days

Posted on 04-06-08 03:28:51 PM Link | Quote
Jeez, how do you stand such a lousy frame rate?

Also did you change some parameters or something? I seem to remember him not descending as fast and not getting tired so quick.
+c0

Level: 10


Posts: 10/17
EXP: 4311
For next: 103

Since: 08-05-07
From: Nowhere.

Since last post: 6.0 years
Last activity: 6.0 years

Posted on 04-06-08 03:52:15 PM (last edited by +c0 at 04-06-08 05:03 PM) Link | Quote
Originally posted by HyperHacker
Jeez, how do you stand such a lousy frame rate?

Also did you change some parameters or something? I seem to remember him not descending as fast and not getting tired so quick.


It runs a lot faster when i don't have a Screen Recorder active..
Usually about 70-75..

I noticed that too, I didn't really notice any bits to change it.. Maybe i did something wrong?
I'll have to look for what i edited and post it

I probably either left something out or Some other command in the Pole Grabbing bit i didn't change did something with it..

edit:

Hm, Just noticed.. It also doesn't make a flapping noise..



New Pole Grabbing Script
00 0A 00 00
11 01 00 09
10 2A 00 01 -- 01 is would appear to be Holding onto Hoot.
23 00 00 00 00 50 05 DC
0C 00 00 00 80 2E 97 64
10 05 00 00
08 00 00 00
0C 00 00 00 80 2E A5 88
09 00 00 00



And something else



The following will should work with 10 2A 00 [XX]

00 = Something Solid. Can't grab. Mario walks around, Can jump over.
01 = Crashed when jumping at it, Used by Hoot.
02 = Grabbing
04 = Going through door
08 = Knocks mario back and dissappears. No damage.
10 = Something Solid, Can't grab, Mario walks around, Can't jump over, Seems somewhat thin..
40 = Climbing

10 2A 40 seems to only be in the Cannons script
10 2A 20 seems to be used with Warps
10 2A 08 seems to be Door Warps?


Also i think the other 10 2A 00 40 labeled as Unknown is the Giant Pole in Whomp's Fortress..
Could be wrong but when i altered it it did seem to affect the Giant Pole..
messiaen
Catgirl
Level: 64


Posts: 18/1085
EXP: 2167095
For next: 47002

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 04-06-08 07:30:15 PM (last edited by messiaen at 04-15-08 01:55 PM) Link | Quote
Hi +c0, it's very nice that you found some interesting use for the 0x10 2A behavior command! Unfortunately I didn't have time this weekend to mess with it.

You could change the background of Bob-Omb Battlefield to make it a "night" level (has anyone tried this yet?) and then invert the colors of that model (black->white) you used to replace the owl. You would get "Mario rides the moon" .

I really liked the way you mixed the two behaviours (Owl + Pole grabbing), perhaps if we categorized some of the 0x0C command addresses we could make interesting things, like a Toad that gives Mario one extra life, or some other mixed behaviors.
---

I did something cool with the Mario behavior which will probably be useful for a ROM hack (I'm all for creating a new level with custom geometry/models and hacked behaviors. Maybe a team effort?). Back to Mario, with this code you can change Mario's speed in a certain area of a level, for instance.

If you place a 0x24 object and set it to Mario Behavior (2EC0, not acessible in TT64?) in a level, you will get double speed mario. If you put another one, you will get 3x or 4x speed mario!

That's interesting, however you can do the same by hacking Mario's behavior:

ROM Addr: 0021CCC0 Hex Behav: 13002EC0
Description: Double Speed Mario behavior!
21CCC0/002EC0 00 00 00 00
21CCC4/002EC4 10 05 00 00
21CCC8/002EC8 11 01 01 00
21CCCC/002ECC 11 03 00 01
21CCD0/002ED0 23 00 00 00 00 25 00 A0
21CCD8/002ED8 08 00 00 00
21CCDC/002EDC 0C 00 00 00 80 2C B1 C0
21CCE4/002EE4 0C 00 00 00 80 29 CA 58
21CCEC/002EEC 0C 00 00 00 80 2C B2 64

and now just copy these 0x0C commands again
0C 00 00 00 80 2C B1 C0
0C 00 00 00 80 29 CA 58
0C 00 00 00 80 2C B2 64

09 00 00 00 --> end of behavior

Getting this code inside a certain level or area is just a matter of changing Mario's 0x25 pointer:

(25 0C 00 01 00 00 00 01 13 00 2E C0 <------ Mario's Pointer from FlatWorld)


--

How about a Flying Tree Behavior?

How to do it? Well, just copy the two 0x0C butterfly commands and add them to the tree behavior. Simple as that! Other nearby trees will be affected, but that will be solved by extending the behavior bank and creating a new script. Imagine a forest with many trees, but when you find the right one, you will take a tour to the magical island!!



Mario takes a ride!

What about some EVIL butterfiles that damage you? That will probably be possible just by combining 0x0C commands!

yoshiman
Member
Level: 22


Posts: 46/95
EXP: 55907
For next: 2443

Since: 12-21-07
From: London, England

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 04-09-08 12:26:19 PM Link | Quote
Very interesting. If you have a look on my site or the thread about RAM objects that will tell you what some of the other params do (though I have an updated version to upload).

I've found when creating my codes that change behaviours that they often work not as expected. For e.g., with my codes that allow you to pick up an object that was a signpost it flys further than normal, perhaps because other params haven't been set.

James S.
messiaen
Catgirl
Level: 64


Posts: 25/1085
EXP: 2167095
For next: 47002

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 04-10-08 02:46:27 PM (last edited by messiaen at 04-18-08 04:59 PM) Link | Quote
I'm pretty sure VL-Tone knows this one (it's fairly obvious), but since this isn't documented in the official Behavior document, I'll report it.

Command 0x04 is used to jump in behavior data.

[04] [00 00 00] [13] [00 06 44]

[0] = command byte
[1,2,3] = Always 0
[4] = Bank
[5,6,7] = Offset

After the jump, there is no return to the original data, it will continue in the jump offset until a 0x09 command that marks the end of it.

--- Edit ---

Now I think these are major discoveries!

Command 0x32 not only scale objects X,Y,Z but also the collision data!
The usage is very simple:

[32] [00] [00 32]

[0] = command byte
[1] = Probably always 0
[2,3] = Scaling Factor (%), in this case 32 = 50% of the original size.

Also, it seems that command 0x1E has the effect of keeping objects on ground.

[1E] [00 00 00]

[0] = command byte
[1,2,3] = Probably always 0, but one could try and see if there are some tweaks for it. (Like keeping from a certain ground distance)
yoshiman
Member
Level: 22


Posts: 48/95
EXP: 55907
For next: 2443

Since: 12-21-07
From: London, England

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 04-19-08 08:29:27 PM Link | Quote
I've found two behaviour script instructions that basically do the same as the ASM equivalent. There's 0x0C000000 which is a jump to ASM and 0x00000000 which functions the same as NOP (do nothing) and has the same opcode.

More interesting is this behaviour script instruction:
0x27260000 xxxxxxxx
The value xxxxxxxx is placed at offset 0x120 in each object structure that uses the behaviour script. I don't know exactly what the variable at offset 0x120 does but it seems to be only used with animated objects. If you copy Chain-chomp's value to a Goomba it moves its head up and down like a chomping movement.

The behaviour pointers in an object structure often point to a position not at the start of the behaviour script, where it points to seems to be for values that need to be continually updated in the object structure, including jumps to ASM. As for values that are written once to each object when the level is initialized there is no pointer in the object to those script instructions.

While looking at the behaviour pointers for the Tox boxes in Shifting Sand Land I noticed a pointer at offset 0x1AC that's different for each box and points to data that determines their paths. This data in the RAM isn't overwritten even if you re-enter Shifting Sand Land which is strange. I don't know exactly what each value does but by studying the Tox box movement I've seen a pattern.

(PAL)

802FCA68 0401040104010401
802FCA70 0401020501050105
802FCA78 0105010501070102
802FCA80 0601060105010204
802FCA88 010701FF

Each movement appears to be grouped into two, though there seems to be an index variable in the object structure that inceases by one each time. You see that there are 5 0x0401 theses are the south movements where the first Tox box ends up at the start of the pathway.

James S.
messiaen
Catgirl
Level: 64


Posts: 38/1085
EXP: 2167095
For next: 47002

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 04-20-08 03:58:03 PM (last edited by messiaen at 04-20-08 03:59 PM) Link | Quote
That is interesting. If you open up TT64 and search for the Tox Box objects in Shifting Sand Land, you'll see that the "Second Parameter" from the 0x24 determines is labeled by VL-Tone as "Path ID".

With the values you've found, it is now possible to alter not just the preset paths determined by the second 0x24 parameter, but probably the paths themselves. I searched for them in the ROM, and these values are found at offset 0x0EB8A8.

The 0x27 is a animation pointer, and was already documented by rstewart in another thread.
yoshiman
Member
Level: 22


Posts: 49/95
EXP: 55907
For next: 2443

Since: 12-21-07
From: London, England

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 04-20-08 07:13:09 PM Link | Quote
It seems in every object structure there are at least three pointers to postions in a behaviour script, the first two are often the same and the last usually points to the start of the behaviour script. This explains why changing the third pointer appears to have no affect since it possibly initializes whereas the other pointers indicate values that are constantly written to the object including calls to ASM.

I did think that the behaviour script instructions did not explicitily state the offset into the object where the variable is located to be written to but I now wonder if that is not so.

Have a look at these behaviour script instructions I have worked out that copy the 16-bit value to a variable in the object structure:

0x1101xxxx xxxx is put at offset 0x8E in object structure
0x1103xxxx xxxx is put at offset 0x96

But what about this instruction:

0x27260000 xxxxxxxx xxxxxxxx is placed at offset 0x120. How does it know that 32-bits is to be witten or is it so that only certain offsets can be used?

Do you see a connection? I'll have to test but this might mean that using the behaviour scripts you can write to any variable in an object structure. This would give us great power but you'd have to be careful as to not change variables that shouldn't be altered that might crash the game.

James S.
messiaen
Catgirl
Level: 64


Posts: 39/1085
EXP: 2167095
For next: 47002

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 04-20-08 11:56:43 PM Link | Quote
I was looking through the behavior list, and besides 0x102A there some other 0x10 commands with different second bytes, such as 0x1005, 0x101A. Could you test these and see what offsets are affected? This is where your RAM Map for the objects will be very helpful.

Also, what about trying to change the second byte to an arbitrary value, such as 0x102B or 0x1006 ?
yoshiman
Member
Level: 22


Posts: 50/95
EXP: 55907
For next: 2443

Since: 12-21-07
From: London, England

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 04-21-08 06:53:37 PM Link | Quote
I have made some sense of the behaviour script instructions we've been discussing. I used the Goomba behaviour script as a test and changed the instruction values and noted the effects.

1100xxxx places the value xxxx at offset 0x8A in the object structure.

Now look at the pattern:

1100=offset 0x8A
1101=offset 0x8E
1102=offset 0x92
1103=offset 0x96

Obviously the offset increases by 4 which is weird considering that only 16-bits (i.e 2 bytes) can be written to the variable which would mean you couldn't write to any variable in the object structrure.

As for the instructions that write 32-bits:

2725=offset 0x11C
2726=offset 0x120

Again, a 4 byte difference which is logical with those instructions. If you change the four zeros after the 2725 or 2726 it appears to be ignored by the game. So it knows how many bytes are to be copied to the variable but how?

James S.
Pages: 1 2 3 4 5Next newer thread | Next older thread
Jul - SM64 Hacking - Behaviour Scripts New poll - New thread - New reply




Rusted Logic

Acmlmboard - commit 2f1bc75 [2017-08-27]
©2000-2017 Acmlm, Xkeeper, Inuyasha, et al.

31 database queries, 14 query cache hits.
Query execution time: 0.149081 seconds
Script execution time: 0.018873 seconds
Total render time: 0.167954 seconds