Register - Login
Views: 87369496
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - JCS - Stats - Latest Posts - Color Chart - Smilies
11-20-17 08:34:48 AM

Jul - SM64 Hacking - Behaviour Scripts New poll - New thread - New reply
Pages: 1 2 3 4 5Next newer thread | Next older thread
messiaen
Catgirl
Level: 64


Posts: 42/1085
EXP: 2160013
For next: 54084

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 04-21-08 07:26:17 PM Link | Quote
Did you take a close look at CellarDweller's earlier post? That information was surely gold, now that I'm beggining to somewhat understand it. The first byte is the kind of operation, so it determines what/how much is written.

Your test confirms the formula he gave for the second byte offset index (index*4 + 0x88). For example, the 0x2726:

hex 26 = dec 38 x 4 (32-bit) = 152 (dec) = 98 (hex) + 88 (hex) = offset 0x120

But how come 11 00 doesn't write at 0x88 or 0x8C ?

yoshiman
Member
Level: 22


Posts: 51/95
EXP: 55722
For next: 2628

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

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 04-22-08 07:57:24 PM Link | Quote
I must of missed that, maybe I can find out by looking at the ASM. Speaking of the coding, I can now change what an item box gives out, I found the item table in the RAM so it acts as a master control for all item boxes. Because of looking at the behaviour coding for the item box that lead me to the list of values that decide what the item looks like, and what it does.

I won't post any actual values here until I do a video on YouTube but this discovery means two very exciting things:

(1) Have items that you couldn't.
(2) If it's possible to expand the table, add more different types of items that you can get from an item box.

James S.
messiaen
Catgirl
Level: 64


Posts: 44/1085
EXP: 2160013
For next: 54084

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 04-22-08 10:00:43 PM (last edited by messiaen at 04-23-08 07:08 PM) Link | Quote
Have you searched for some RAM values that determine the path of Koopa the Quick in Bob-omb Battlefield ? Maybe there is some set of X,Y,Z coordinates that serve as checkpoints.

I was wondering if you found those values (or pointers) if they could be changed using only behavior commands which write in the RAM.

--

Also from CwellarDweller post:

0x45 -- Disappear distance (float) (found by matching my notes with HyperHacker's old ones)

He means index 0x45, which translates to "RAM object" offset 0x19C

This is used a lot in platforms or 0x24 geometry which needs to be viewed from a certain distance:

0E 45 07 D0 (max values if 07FF, check out the Flatworld thread)

This is the same as the 0x20 Geometry Layout command! But the geometry layout sets global properties for a model, while the behavior probably OVERRIDE that for a specific object. Interesting, no?

Index 0x43 (RAM Offset 0x194) probably does something related:

0E 43 07 D0

I tried inserting these two behavior commands (0E 45 07 D0 and 0E 43 07 D0) at my platform behavior and now it can be viewed from very far!!! That's great!!
yoshiman
Member
Level: 22


Posts: 52/95
EXP: 55722
For next: 2628

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

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 04-23-08 08:30:48 PM Link | Quote
I've been studying the coding a lot which has helped me to understand how the object variables are used since an offset is used to reference them. I did have a brief look at Koopa the quick and it seems there's a ponter (different offset to the Tox boxes) in its object structure that indicates some values but I can't yet work them out. As you race Koopa the pointer value changes and the 16-bit value it points to is copied to Koopa's object structure at a nearby offset. Changing them seems to have no affect so maybe the ASM will reveal something.

James S.
messiaen
Catgirl
Level: 64


Posts: 48/1085
EXP: 2160013
For next: 54084

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 04-25-08 09:19:07 AM Link | Quote
Nice that you have a good grasp of N64 ASM. A while ago I stumbled unpo this code for Zelda:

"This is a near-complete implementation of the GameShark pro's code system in MIPS R4300i assembly."

http://outlawer.net/library/1/

I was wondering if loading custom ASM wouldn't be easier in N64 because of the 0x0C behavior script commands and the 0x16 load to RAM.

From "SM64MainLevelScripts.txt"

16 10 00 00 80 16 F0 00 00 21 F4 C0 00 26 9E A0 --Loads ASM code into RAM at 8016F000

The whole 21F4C0-269EA0 offset region could be moved to an extended part of ROM and then getting a few more bytes in RAM would be just a matter of repointing these adresses.

Does this sounds feasible or is just wrong ?
yoshiman
Member
Level: 22


Posts: 53/95
EXP: 55722
For next: 2628

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

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 04-27-08 06:54:39 PM Link | Quote
So far I have only edited the ASM in the RAM but of course doing that with codes has big limitations. I also inserted my own short routines into a unused area of RAM to do simple things such as increase Mario's lives when pressing D-Pad up. Let's not forget that Gameshark codes are converted to ASM routines but it's better to work in harmony with the game's coding.

Yes, I do think it's possible, but what exactly would be best? We could adjust the existing behaviour coding or possible add new behaviours. Speaking of that, either I've made a serious error or I've missed something obvious. I've been looking at the ASM called by the 0x0C behaviour instruction and the signposts and Bullet bill blaster both make the same call. I know that being able to read a signpost is due to a variable in the object and not the 0x0C call but I don't see the connection with a blaster. And similar, why do the trees need a 0x0C call when you can climb a tree because of a set variable in its structure like with the signposts?

James S.
messiaen
Catgirl
Level: 64


Posts: 53/1085
EXP: 2160013
For next: 54084

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 04-27-08 09:37:01 PM (last edited by messiaen at 04-27-08 09:53 PM) Link | Quote
I think it is best to create new behaviors. I don't know if you have checked my experiments with creating new objects with moveable collision. They use new behaviors with 0x2A collision pointers. Loading a few more behaviors into RAM is easy, thanks to VL-Tone's ROM extender which gives you a uncompresses version of the ROM.
(Let's not forget to give the credit to GuyPerfect, who cracked the compression format)

Regarding your 0x0C question, I can only share with you what I have discovered so far by experimenting. Just setting variables is not enough for some objects. For instance, you *need* a 0x0C call to make an object solid, that is, for the 0x2A command to work. The call to address "80 38 39 CC" is used in most solid behaviors, such as platforms. If I use the 0x0C call to "80 2C 63 E8", which is the one used by tree, my collision won't work. Also, the 0x0C tree call could be needed because of the special 2D model.

However, not always the "80 38 39 CC" call is require for solid objects. For instance:

Description: TH Island Top Trap Behavior
219F74/000174 00 09 00 00
219F78/000178 11 01 00 01
219F7C/00017C 2A 00 00 00 07 00 E2 28
219F84/000184 08 00 00 00
219F88/000188 0C 00 00 00 80 2A 6C F4
219F90/000190 09 00 00 00

I don't know how this object is used in the game, but among other things, the 0x0C call makes this object compatible with the 0x2A command.

Since I got a good "solid" with 0x2A collision behavior, I haven't experimented a lot with behavior scripts.

Also, Why don't your start a ASM thread? Post some of your codes, so we can try to load it from the ROM. If we get that, then creating new permanent behaviors will be possible, without affecting other behaviors or codes loaded in the RAM.
yoshiman
Member
Level: 22


Posts: 54/95
EXP: 55722
For next: 2628

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

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 04-28-08 07:55:23 PM Link | Quote
Very helpful information but it amazes me how overly complex this game is. For e.g., the red coin and 1-up 0x0c call do exactly as you would expect them, i.e. to increase Mario's red coin total/lives, play sound, etc. But that is not so with other objects that rely more on behaviour type variables in the object structure.

I have done mainly RAM hacking, so could you please direct me to a place in the ROM where it would be suitable to place new ASM. And would that be an area protected by checksum, though that can be fixed with a program.

Creating behaviours generally isn't too difficult, but typically we would also want to use existing functions that do common things. It seems that there are two important pointers available for behaviours, a pointer to Mario's object structure and what appears to be a pointer to the object structure who the behaviour belongs to (e.g., a coin). Using these pointers we can get at any of the variables that belong to the object so there are great possibilities.

So, can you please confirm that this is correct: the game uses a command to load ASM from the ROM into the RAM. Since the coding stays at the same place in the RAM regardless of the level, when are these commands to load the ASM executed?

If we did create new behaviours and have the game load them there might not be free space in the RAM (though ASM takes up very little space compared to graphics, sound, etc). How does the game link behaviour coding to the 0x0c command in the script-is it segment/offset?

I wanted to do an ASM thread ages a go and I asked VL-TONE but he said not to since not many people know ASM so perhaps it could be kept to this thread. If you would like I could put samples of behaviour coding used by objects such as coins so you can get an idea of what goes on.

James S.
messiaen
Catgirl
Level: 64


Posts: 58/1085
EXP: 2160013
For next: 54084

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 04-28-08 08:43:27 PM (last edited by messiaen at 04-29-08 02:37 PM) Link | Quote
Well, I guess you could try this:

This is the command that loads most ASM stuff in RAM:

16 10 00 00 80 16 F0 00 00 21 F4 C0 00 26 9E A0 --Loads ASM code into RAM at 8016F000

This is executed in the first menu screen, at the same time the behavior and other shared 'banks' are loaded, such as Mario geometry. I don't know if you tried RAM editing the first menu, but the buttons themselves are created by a 0x0C behavior script call.

The extended ROM has lot of free spaces, but I would recommend for you to use offsets above 0x1300000, to avoid future compatibility problems with Flatworld. So, copy the whole 21F4C0-269EA0 segment to 0x1300000 and paste your new code at the end of. Then change all the "16 10 00 00 80 16 F0 00 00 21 F4 C0 00 26 9E" (there about 5 or 6 of them) in the ROM to reflect your new offsets:

16 10 00 00 80 16 F0 00 01 30 00 00 01 3X XX XX

Try that and see if it works. This is how I extended the behaviour bank. I haven't run into any checksum problems. All the offset pointers at the behaviour bank (such as 0x04 jumps in behavior data) are relative offsets, not absolute ones. Moving data around in the ROM is very easy.

Concerning ASM, I know nothing about MIPS or any ASM whatsoever, but I think the idea is to create a database of information here. Maybe some people will be inspired by your findings and try to learn it. I'll surely try to understand what your code does. In the worst scenario, nobody will answer your messages, but at least the information will be there.

This site looks great for N64 ASM info EnHacklopedia.

---

A visual demonstration of the 0x32 scaling command + simple behavior editing, producing a solid pipe with 400% scaling:

yoshiman
Member
Level: 22


Posts: 55/95
EXP: 55722
For next: 2628

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

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 04-29-08 10:44:31 PM Link | Quote
That's a very good website you provided, thanks.

I need to become more familiar with the NTSC game before I make any big changes to the ROM since I know the PAL game more, and there might not be enough RAM to hold new code. Oh, and I'll be on holiday soon as well, so if I don't reply in a while that's why.

Having had a look at the file select menu as you suggested objects are used, for e.g., the first object is the background. You can move it, rotate it and change what it looks like exactly as you would with in-game objects. The behaviour for the background basically fixes its size using a very common function that takes one size and applies it to all 3 object size modifiers.

I checked each of the pointers to graphic structures and found that there are 2 for Mario new file icon and 2 for Mario icon of a file that has already been started. It may be nothing but the extras could have been used for Luigi if he were to be playable as well as Mario.

As well as the file select menu behaviours the in-game behaviour coding is there but not the scripts. I did a test and applied the Koopa shell 0x0c call to the background and it span around, but no change in music.

James S.
messiaen
Catgirl
Level: 64


Posts: 61/1085
EXP: 2160013
For next: 54084

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 04-30-08 09:51:49 PM (last edited by messiaen at 04-30-08 09:52 PM) Link | Quote
My suggestion about the first menu came from the SM64MainLevelScripts.txt, which is VL-Tone's commented version of the main level interface level script.

According to that document, there are 3 objects in the menu screen:

24 18 1F 00 00 00 00 00 B5 C8 00 00 00 00 00 00 04 00 00 00 13 00 30 08 --Places Menu Buttons on screen.
24 18 1F 06 00 00 00 00 B5 C8 00 00 00 00 00 00 04 00 00 00 13 00 2F C0 --Places Yellow Wood Texture Menu BG on screen.
24 18 1F 00 00 00 FF 9C 00 00 00 00 00 00 00 00 04 00 00 00 13 00 30 48 --Places some object on screen.

The 0x24 is the level script command which creates objects. The last four bytes are the behaviors (13 00 is the bank and the last two bytes the relative offset).

What is unusual about this is the fourth byte of the first and third commands. This is the "model" byte ID, as defined by the 0x22 or 0x21 Geo Layout/Polygon pointers. In this case, the ID is 00, so no model is used, which I think means that the sole purpose of these commands is to point to the behavior which executes a 0x0C call.

Another striking thing is the relative unusual command "11 01" comand in the 0x3008 behavior: "11 01 08 21". This is only shared by the "Controlable Platform"' behavior, so maybe one of the 0x3008 behavior 0x0C calls is related to the mouse.
I tried setting "11 01 08 21" to a goomba, and indeed he seems to follow you, but very slowly. Perhaps you could try this for your videos .

Also, this may be of help to you. I remember reading in a very old thread about the function of the "08 00 00 00" command, it seems that his sets some kind of loop in the 0x0C call. You have a programming background, so that may make sense to you. If you look at the behaviors, usually the 0x0C calls are made after one of these 0x08 commands, but there are cases in which there is one 0xC call before the 0x08 "loop".
yoshiman
Member
Level: 22


Posts: 56/95
EXP: 55722
For next: 2628

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

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 05-01-08 10:13:32 PM Link | Quote
I haven't found the mouse yet used for the file select screen and as I'll be on holiday tomorrow I'll have to continue investigating when I get back.

The 0x1101 command appears to determine how much an object reacts to Mario but it's exact use seems to vary depending on the behaviour. As for the 0x08 command it appears to affect the animation of the object; if you copy the value for Chain-chomp to a Goomba they move their heads like a chomping action. This is confusing since there's a pointer dedicated to animation.

From what I've seen, every object has a pointer to the behaviour script for initialization and then two more (often the same values) that pointe to a position in the behaviour script to be called often, usually a 0x0c call as to update the object.

There is something that's really bugging me I'd like someone to explain. Codes I create that modify the coding only work if activated before the file select screen if using an emulator but on my actual N64 I can edit the RAM any time and the effects are instant. Anything else you can change and you see immediately the changes but not with coding, as if the emulator makes a back up copy-but how would it know?

James S.
Mega Mario XD
80
Level: 21


Posts: 72/81
EXP: 44212
For next: 5731

Since: 10-26-07
From: Australia

Since last post: 9.0 years
Last activity: 9.0 years

Posted on 05-02-08 02:59:59 AM (last edited by Mega Mario XD at 05-02-08 03:01 AM) Link | Quote
Originally posted by yoshiman
I haven't found the mouse yet used for the file select screen and as I'll be on holiday tomorrow I'll have to continue investigating when I get back.


James, I haven't done much RAM editing, but I know the texture for that is in the ROM. If I could get a program that linked into SM64 in PJ64, I could see if I could change it.

As for the emulators, when you apply codes, it temporary backs up the info of the RAM a temp file. When you disable the codes, it replaces the modded RAM addresses with the values of the old addresses. However, that would have a problem with the level address for example.

Say the level number is 06 for the battlefield course. In the RAM, it would say at address XXXXXXX 00000006 or something. Like if your in Cold, cold mountain, which could be 0000001A, I dunno if I'm correct 100%, but if the emulator reset that RAM address using the previous code that it 'backed up' (the 06 one), the game could have a spaz attack and crash.

I think emulators look at the changed addresses in the RAM only and back them up, say if you had a Moonjump code, it would modify the jump value for mario to 255 for example, but you disable it, and it would replace it with the old value (60 for example).

I should be somewhat correct. If I'm not, please correct me.
messiaen
Catgirl
Level: 64


Posts: 64/1085
EXP: 2160013
For next: 54084

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 05-02-08 03:34:38 AM (last edited by messiaen at 05-10-08 02:10 PM) Link | Quote
I guess the "mouse pointer" could be easily found by investigating the 0x22 geo layout commands which define models pointers in each level, if you want to change that. But what I was indeed searching is the 0x0C call that commands and sets the mouse on screen.

Also, I don't have if you have experimented with the "collect star" 0X0C calls, but if you use all of them on an object, the model of that object will be replaced by the star. That is interesting, because so far this is the only case of an 0x0C I found that actually changes the model.

As for the 0x08 command, I don't think we are talking about the same thing. I'm talking about the 0x08 command before 0x0C calls you found in the behavior scripts (check VL-Tone's reference file), while you are probably talking about the 0x08 inside the 11 01 right?

From what I gather, the 0x0C calls inside a 0x08 "loop" constantly update the objects information, and you can do interesting things with this (I'll talk about some experiments I've been doing in a later post).

>yoshiman: From what I've seen, every object has a pointer to the behaviour script for initialization and then two more (often the same values) that point to a position in the behaviour script to be called often, usually a 0x0c call as to update the object.

The first pointer to script initialization is probably set by the 0x24 level command, like the ones I posted in my other post. It is the relative offset position of the behavior start in the behavior bank (0x13). Regarding the other pointers, I'm not sure. Could you post some examples? There are behaviors who use 'jumps' in the data, as this saves space for minor behavior changes, but these are very few and probably not what you mean.

---

I found the "parameters" indexes!

Whomp King Behavior is the same as regular whomp's, except for this:

10 2F 00 01 <--- 2F = sets parameter 1 -> 1
10 3F 00 03 <--- 3F = sets paramater 2 -> 3

This has the same function as the parameters bytes of the 0x24 command. I guess this just shows again how patchy SM64 is!

King Bom-omb uses this "internal" set parameter command:

10 3F 00 03 <--- parameter byte 2

I tried changing this to other values, but didn't noticed any different effect.

---

Here is why the "TH Island Top Trap Behavior" 0x0C call also produces the "solid" behavior:

void func802A6CF4()
{
[...] goto pc803839CC; [...]
}


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


Posts: 201/621
EXP: 949999
For next: 63939

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

Since last post: 83 days
Last activity: 52 days

Posted on 05-11-08 12:46:36 AM Link | Quote
Hi,

Just wanted to tell you that you're doing an amazing work on understanding behavior scripts. I'll try to eventually integrate some behavior script editor in TT64 when I get more time (somewhere in June), though it'll be hard to make it easy to use for mere mortals.
messiaen
Catgirl
Level: 64


Posts: 74/1085
EXP: 2160013
For next: 54084

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 05-11-08 10:34:56 AM Link | Quote
Hi VL-Tone, thanks for your kind words on some threads. From what I have done so far, I have the felling that an integrated behavior would be such a nightmare to design! Is it worth the trouble? I am even thinking about the possibility of using the Bank 0x07 to store level-specific behaviors for my custom level, because I may ran into problems when extending Bank 0x13 too much.

I have been experimenting with Nemu's disassembler and reading a few ASM tutorials, and I think that with some simple modifications we can get interesting effects. For instance, supressing a few traits of a specific behavior. Also, by comparing the codes we can find some shared functions (JAL calls triggered by conditionals), which could be used for "frankenstein" behaviors.
Fuzzyfreak
User
Level: 12


Posts: 3/22
EXP: 6087
For next: 1834

Since: 05-11-08
From: Overberg, Netherlands

Since last post: 6.0 years
Last activity: 6.0 years

Posted on 05-11-08 11:08:36 AM (last edited by Fuzzyfreak at 05-11-08 11:31 AM) Link | Quote
Originally posted by messiaen
I have been experimenting with Nemu's disassembler and reading a few ASM tutorials, and I think that with some simple modifications we can get interesting effects. For instance, supressing a few traits of a specific behavior. Also, by comparing the codes we can find some shared functions (JAL calls triggered by conditionals), which could be used for "frankenstein" behaviors.


Most definitely. Maybe it might be possible to design custom objects, even. I don't know how exactly the objects are formatted, but it SHOULD be possible to point the object list to an unused place in the ROM map, to make custom objects... I wonder if the last -almost- 6 MB in the extended ROM (24 MB) are even used... all I see is a huge block of '01's. They don't seem to be used at all, so maybe one would point the objects to that place.

Of course, it would be a lot of a hassle to implement that correctly...
yoshiman
Member
Level: 22


Posts: 57/95
EXP: 55722
For next: 2628

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

Since last post: 8.0 years
Last activity: 8.0 years

Posted on 05-12-08 07:26:25 PM Link | Quote
I've been on holiday so I haven't done any more hacking yet but I was just reading over the threads. I remember that one of the box behaviours forces the object to use the box graphics, which of the 2 textures is used is selected by a variable in the object structure. Does anyone know what command sets that variable?

Modifing or adding new behaviours could only be done by those who know ASM so that would not be a good idea to integrate into TT64. Certainly choosing which 0x0c calls are used would allow for the custom behaviours using the existing coding.

The best thing we could do with SM64 is put in object behaviours from past Mario games although the Blarrg & Yoshi egg behaviours might be there. Nemu is great for studying the behaviour coding since you can set up watches on certain addresses, do something significant in the game and Nemu will pause showing the instruction that read/wrote to the watch address. This came in handy when, for example, someone requested that I do a code so that the Bob-ombs ignored Mario.

James S.
messiaen
Catgirl
Level: 64


Posts: 81/1085
EXP: 2160013
For next: 54084

Since: 11-20-07


Since last post: 3.0 years
Last activity: 2.0 years

Posted on 05-12-08 08:24:01 PM (last edited by messiaen at 05-12-08 08:27 PM) Link | Quote
Too bad I can't seem to open the extended ROM on Nemu. Is this happening with other people also?

It would be a good idea to update the Behavior document, because a lot of the behaviors called "unused" are actually used by sub-objects. For instance, the behavior at 0x0254 is used by a sub-object created by Bob-Omb.

The same happens with the Waving Koopa Flag. No mater what model you place with the Flag behavior, the Waving Flag itself will be created by this command:

29 00 00 00 00 00 00 6A 13 00 45 F8

6A is the Waving Flag Model, as defined by the 0x22 Geo Layout pointer and 45F8 the behavior pointer.

Now the star behavior is another case, because the fixed model is actually hard coded in the ASM. By the way, here is the JAL call inside the star behavior which stops the camera: 8029000C.

I was also looking for other very common JALs which are shared by a lot of objects (inside the ASM, not in the behaviour code) and these are some adresses I found:

803839CC
80383BB0
80383CB4
80383D1C

Now the 803839CC we already know as the "solid" one and it works along with the 0x2A collision data pointer. What could be others? These could be very general effects which could be directly linked to the behavior 0x0C command, creating more possibilites without modyfing the coding itself.

Also, to throw yet another variable in the behavior maze: the first 4 bytes of each behavior define some kind of general attributes. Used values are 04, 05, 06, 08, 09, 0A, OB and 0C.

The behaviors which start with the "00 0C 00 00" usually consist of a few "set RAM variables" followed by a 0x0C call. If you set, for instance, the first bytes of the "Koopa Behavior" to this, he won't be able to interact with you, nor his collision sphere will work.
Fuzzyfreak
User
Level: 12


Posts: 5/22
EXP: 6087
For next: 1834

Since: 05-11-08
From: Overberg, Netherlands

Since last post: 6.0 years
Last activity: 6.0 years

Posted on 05-13-08 11:42:20 AM Link | Quote
Originally posted by yoshiman
Modifing or adding new behaviours could only be done by those who know ASM so that would not be a good idea to integrate into TT64. Certainly choosing which 0x0c calls are used would allow for the custom behaviours using the existing coding.

Well I was thinking about some simpler things like adding new contents for the ! box. But yeah, why not learn ASM? I understand it's harder than SMW ASM, but it's definitely possible. And none of us are complete morons, are we?
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.

29 database queries, 15 query cache hits.
Query execution time: 0.198466 seconds
Script execution time: 0.021911 seconds
Total render time: 0.220377 seconds