Crazy Hand v1.31 - Character editing program

[Tater]

I recently installed Windows so that must be it, I guess I'll go download Java. After I do that, what file do I open specifically? Thanks.

Extract the .zip folder somewhere, and then run Crazy Hand v1.10.jar

Happy modding!

 

[Tater]

Oh, by the way @ Ampers I put your changes to FSM into my build, and it crashed on startup. It crashed due to an IllegalArgumentException thrown by FSMNode because it tried to set the actionbox selected index to 3408(What BitWork.setBits(20,31,b) returned). I tried loading a clean melee ISO and got the same error. Did everything run alright on your side when you committed the changes?

 

[schmooblidon]

Anyone know how exactly the control stick x-value affects dash acceleration?

 

[Ampers]

Oh, by the way @ Ampers I put your changes to FSM into my build, and it crashed on startup. It crashed due to an IllegalArgumentException thrown by FSMNode because it tried to set the actionbox selected index to 3408(What BitWork.setBits(20,31,b) returned). I tried loading a clean melee ISO and got the same error. Did everything run alright on your side when you committed the changes?

No, I didn't get any kind of error like that. However I did notice a couple bugs after I uploaded that code that I haven't fixed yet. They may be causing this unexpected crash. Once I fix them up we can try to merge again.

 

[Gentlefox]

It would be extremely useful to have Hitbox ID and Hitbox Interaction visible. Not sure why those two were left out?

Also, I've been trying to identify some of the unknown subaction commands, and I found two really easy ones that haven't been ID'd for some reason.

70 AA BB CC seems to be for setting body state on a specific hurtbox.

Fox has 70 A4 00 02 for upsmash

Doc has 70 5C 00 02 for upsmash

I assume AA is the hurtbox identifier. Probably bitshifted or something though. I tried to match it up with Fox's head ID in the hitbox spreadsheet, and found no correlation.

No idea what BB does. Probably just blank space to fit the 4 byte pattern.

CC is the body state to be set. I believe 00 is normal, 01 is invulnerable, 02 is intangible.

Fox and Doc also both have 6C 00 00 00 on the frame they lose invulnerability, so I tested that, and it basically does what the 70 XX XX XX command does, but for the entire body.

I switched Doc's to 6C 00 00 02 and it set his entire body intangible for the duration of the move.

 

[Tater]

It would be extremely useful to have Hitbox ID and Hitbox Interaction visible. Not sure why those two were left out?

Also, I've been trying to identify some of the unknown subaction commands, and I found two really easy ones that haven't been ID'd for some reason.

70 AA BB CC seems to be for setting body state on a specific hurtbox.

Fox has 70 A4 00 02 for upsmash

Doc has 70 5C 00 02 for upsmash

I assume AA is the hurtbox identifier. Probably bitshifted or something though. I tried to match it up with Fox's head ID in the hitbox spreadsheet, and found no correlation.

No idea what BB does. Probably just blank space to fit the 4 byte pattern.

CC is the body state to be set. I believe 00 is normal, 01 is invulnerable, 02 is intangible.

Fox and Doc also both have 6C 00 00 00 on the frame they lose invulnerability, so I tested that, and it basically does what the 70 XX XX XX command does, but for the entire body.

I switched Doc's to 6C 00 00 02 and it set his entire body intangible for the duration of the move.

Hitbox ID and hitbox interactions have been added. I'm not entirely sure why they weren't present from the start either. Good find on the body state scripts as well. I'll plug the full-body one(And the hurtbox-specific one if I can figure out where/if the bitshifting occurs) into the next release

 

[Achilles1515]

It would be extremely useful to have Hitbox ID and Hitbox Interaction visible. Not sure why those two were left out?

Also, I've been trying to identify some of the unknown subaction commands, and I found two really easy ones that haven't been ID'd for some reason.

70 AA BB CC seems to be for setting body state on a specific hurtbox.

Fox has 70 A4 00 02 for upsmash

Doc has 70 5C 00 02 for upsmash

I assume AA is the hurtbox identifier. Probably bitshifted or something though. I tried to match it up with Fox's head ID in the hitbox spreadsheet, and found no correlation.

No idea what BB does. Probably just blank space to fit the 4 byte pattern.

CC is the body state to be set. I believe 00 is normal, 01 is invulnerable, 02 is intangible.

Fox and Doc also both have 6C 00 00 00 on the frame they lose invulnerability, so I tested that, and it basically does what the 70 XX XX XX command does, but for the entire body.

I switched Doc's to 6C 00 00 02 and it set his entire body intangible for the duration of the move.

Good find with the 70!
Here is how the game handles this command:

70A40002

= Command ID and Bone
= Body state to apply

Function:
80071a9c   SubactionEvent_ChangeHurtbubbleBodyState
------------

- r5 holds memory address of the command -
80071ab4   lhz r4,0(r5)    # Load first halfword of command. For Fox Usmash, r4 = 0x000070a4
80071ab8   lwz r5,0(r5)    # Load entire command. For Fox Usmash, r5 = 0x70a40002
80071abc   rlwinm r4,r4,30,24,31    # Get bone ID. For Fox Usmash, r4 = 0x00000029 (decimal 41)
80071ac0   rlwinm r5,r5,0,14,31     # Get body state to apply. For Fox Usmash, r5 = 0x00000002
80071ac4   - branch link into function to make the hurtboxes attached to the specific bone change state -

Magus already documented the body state command? What is different between 68 and 6C?

 

[Gentlefox]

Hitbox ID and hitbox interactions have been added. I'm not entirely sure why they weren't present from the start either. Good find on the body state scripts as well. I'll plug the full-body one(And the hurtbox-specific one if I can figure out where/if the bitshifting occurs) into the next release

Thanks! I've been asking a lot of questions and taking a lot from this board without contributing anything, so I'm trying to finally put some effort into getting this game mapped out.

Also, little bug report:

If you go into Subactions (Attacks Only) and pick a subaction, then switch tabs to Subactions (All) or Other, or whatever, when you come back it will still show the subaction you picked in the menu, but the data being displayed is the one at the top of the list (Jab 1).

So for example, if I go to Doc, then Subactions (Attacks only), then Up-Smash, then Other, when I come back to Subactions (Attacks only) it will show that I'm on Up-Smash in the drop-down box, but the data being displayed is Jab 1.

I would recommend not changing this to how it is supposed to work (switching to the top menu item), but instead switching back to whatever you had open. It's annoying when I'm looking at Doc's Usmash, I go to "Other" to show raw data, and then come back to jab. I think of tabs like an internet browser, I want my data to stay how it was.

Good find with the 70!
Here is how the game handles this command:

70A40002

= Command ID and Bone
= Body state to apply

Function:
80071a9c   SubactionEvent_ChangeHurtbubbleBodyState
------------

- r5 holds memory address of the command -
80071ab4   lhz r4,0(r5)    # Load first halfword of command. For Fox Usmash, r4 = 0x000070a4
80071ab8   lwz r5,0(r5)    # Load entire command. For Fox Usmash, r5 = 0x70a40002
80071abc   rlwinm r4,r4,30,24,31    # Get bone ID. For Fox Usmash, r4 = 0x00000029 (decimal 41)
80071ac0   rlwinm r5,r5,0,14,31     # Get body state to apply. For Fox Usmash, r5 = 0x00000002
80071ac4   - branch link into function to make the hurtboxes attached to the specific bone change state -

Magus already documented the body state command? What is different between 68 and 6C?

Good job mapping it! I still don't fully understand how that correlates to Fox's head though. Where did you get 29 from A4? Also, how do you find the code section given the event code? Did you just set a read breakpoint in someone's character file, or is there a better way? Speaking of which, how do you find where the code starts for special moves?

The difference between 6C and 68 is 4 =P Just kidding. The difference seems to be that 68 can not undo what 70 does. If you change the 6C 00 00 00 in Doc's Usmash to 68 00 00 00, it will not cancel his head's invulnerability until the move ends. I assume 6C is also called after every subaction then, instead of 68, as moves do indeed clear up after the subaction.

 

[Achilles1515]

Also, how do you find the code section given the event code? Did you just set a read breakpoint in someone's character file, or is there a better way?

Take 0x000070A4 (value in register 4), rotate the bits left 30 times (bit 0 would get rotated around to bit 31), then turn all 32 bits into 0’s except leave any current 1’s between bit 24 and bit 31.

(Bit 0 is all the way to the left. When bit 0 is 1, you get 0x80000000)


Basically, just take the first halfword of the command, subtract 0x7000, then divide by 4.

Also, how do you find the code section given the event code? Did you just set a read breakpoint in someone's character file, or is there a better way?

That is indeed how I initially found out how subaction events are read and handled. I did a memory read breakpoint on hitbox data and then returned from that subaction_hitbox function to see how the game was branching to it. Basically, there’s just a table of pointers in the RAM/DOL that list the subaction control functions in order of their IDs. I still need to do some research on it, but I’ll be hoping to post more soon.

Speaking of which, how do you find where the code starts for special moves?

What do you mean? Code that controls what exactly?

The difference between 6C and 68 is 4 =P Just kidding. The difference seems to be that 68 can not undo what 70 does. If you change the 6C 00 00 00 in Doc's Usmash to 68 00 00 00, it will not cancel his head's invulnerability until the move ends. I assume 6C is also called after every subaction then, instead of 68, as moves do indeed clear up after the subaction.

So there is a specific “hurtbubble/bone body state”, and then a “full body state”, and they are controlled totally separately. Makes sense.

 

[Citricide]

So I'm trying to make moves be interruptible/cancelable into anything. I've tried editing the Asynchronous timers/ISAS frames but nothing has worked. I'm trying to get it similar to turbo mode in Project M. What is the proper way to do this?

 

[Tater]

If you go into Subactions (Attacks Only) and pick a subaction, then switch tabs to Subactions (All) or Other, or whatever, when you come back it will still show the subaction you picked in the menu, but the data being displayed is the one at the top of the list (Jab 1).

So for example, if I go to Doc, then Subactions (Attacks only), then Up-Smash, then Other, when I come back to Subactions (Attacks only) it will show that I'm on Up-Smash in the drop-down box, but the data being displayed is Jab 1.

I would recommend not changing this to how it is supposed to work (switching to the top menu item), but instead switching back to whatever you had open. It's annoying when I'm looking at Doc's Usmash, I go to "Other" to show raw data, and then come back to jab. I think of tabs like an internet browser, I want my data to stay how it was.

Funny you should mention "tabs".

Spoiler

NOTE: This is still a work-in-progress feature that I can't promise will come with the next update, so don't make direct eye contact with the ugly GUI.

That menu bug has bothered me for a little while as well.
It has been fixed and will be included in the next update.

So I'm trying to make moves be interruptible/cancelable into anything. I've tried editing the Asynchronous timers/ISAS frames but nothing has worked. I'm trying to get it similar to turbo mode in Project M. What is the proper way to do this?

Put 5C 00 00 00 (Allow Interrupt/IASA) where you want the subaction to be cancelable, such as after hitboxes are cleared/come out, etc. As far as making it function like Project M(Attacks are cancelable only on hit) I'm not sure if/how you would accomplish that purely by subaction editing. You might have to dive into DOL editing for that. I've actually been meaning to look into a similar subject, so I'll let you know if I find anything relevant to your interests.

 

[Gentlefox]

What do you mean? Code that controls what exactly?

I mean for special moves. For example, looking at the data for Fox's shine, there is no code that corresponds to the reflect hitbox being created. Every special move seems to have its own function that is pure ASM, but I don't know where that is located.

 

[Ampers]

@ Tater , I've fixed up some bugs in the FSM code and submitted to github. can you try to merge your code with it? Or just give me your code and I can try to combine it.

 

[Tater]

@ Tater , I've fixed up some bugs in the FSM code and submitted to github. can you try to merge your code with it? Or just give me your code and I can try to combine it.

I merged your code with mine, and got the same error while trying to load FSM's that I had gotten before the merge. To be safe, I used a completely untouched melee(v 1.02) iso for each try and got the same error.

At this point I figured I must have broken your code with some of my own changes/additions so I copied the fully functional build off of github and tried loading an ISO with that. Unfortunately, I got the same error as I was getting with my own build :/

Console log

Spoiler

PlKp.dat
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
false
Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: setSelectedIndex: 1056 out of bounds
at javax.swing.JComboBox.setSelectedIndex(Unknown Source)
at com.FSMNode.<init>(FSMNode.java:83)
at com.FSMPanel.refresh(FSMPanel.java:155)
at com.FSMPanel.<init>(FSMPanel.java:115)
at com.MeleeEdit.<init>(MeleeEdit.java:144)
at com.MeleeEdit$1.run(MeleeEdit.java:786)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$500(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

Not all bad news though; I think I might know why it's working fine on your end. When I was fiddling with the FSM classes the first time I got errors, I found that changing the lines of

actionBox.setSelectedIndex(BitWork.setBits(20,31,b)); to actionBox.setSelectedIndex(0);
(within FSMNode)

Would allow CrazyHand to load without errors since an IllegalArgumentException wouldn't be thrown. Unfortunately, doing this obviously caused FSM editing to be virtually non-functional. HOWEVER, it did write some data to the ISO regarding FSM's. So when I put the FSM classes back to normal and tried loading the same ISO that had some FSM data written to it, it did still crash on startup but I got a much different console output.

Spoiler

PlKp.dat
0
update!
0
update!
0
update!
0
update!
false
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
0
update!
false
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
0
update!
false
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
0
update!
false
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
0
update!
false
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
0
update!
false
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
0
update!
false
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
0
update!
false
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
0
update!
false
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
0
update!
false
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: setSelectedIndex: 3408 out of bounds
at javax.swing.JComboBox.setSelectedIndex(Unknown Source)
at com.FSMNode.<init>(FSMNode.java:83)
at com.FSMPanel.refresh(FSMPanel.java:155)
at com.FSMPanel.<init>(FSMPanel.java:115)
at com.MeleeEdit.<init>(MeleeEdit.java:139)
at com.MeleeEdit$1.run(MeleeEdit.java:769)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$500(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

My thought is that things may be working properly on your end since I assume you used the same ISO for the entire process of making the FSM panel. If you were figuring out how to make FSM's work through trial and error then little bits of data may have been written to the proper places within the ISO to make FSM's functional.

To be 100% sure, I'm going to clean up my code(Which is already merged with your own) and commit it to a separate branch. If you could try loading a clean melee ISO and the ISO you most commonly use for Crazy Hand and see if there's a difference in functionality, it would be a good way to tell where the disconnect is on my end.

 

[Ampers]

Well shoot, I was really hoping the issue was fixed. I am going to test from my end using a clean copy of melee. I will need to download a new iso though because the only place I keep a clean copy is on my external hard drive which I don't have with me. Might take a little while.

 

[Ampers]

@ Tater ,

I've discovered the problem. As it turns out, my code for FSM's currently will only work on a 20xx iso. I've never noticed this before because I have used pretty much exclusively 20xx iso's since I started melee modding, just for convenience.

The issue is that a vanilla Melee v1.02 iso actually contains data in the location that FSM's are intended to go into. For the 20xx hack, @ Achilles1515 must have relocated/removed this data. If you try to load a v1.02 iso, it will try to interpret what is already there but this most certainly result in a crash.

I'm not entirely sure what the best way to work around this is to be honest. Maybe there is a location that the FSM code can be put that would not interfere with 20xx or vanilla 1.02? For the time being this feature may just have to be 20xx only.

 

[Tater]

@ Tater ,

I've discovered the problem. As it turns out, my code for FSM's currently will only work on a 20xx iso. I've never noticed this before because I have used pretty much exclusively 20xx iso's since I started melee modding, just for convenience.

The issue is that a vanilla Melee v1.02 iso actually contains data in the location that FSM's are intended to go into. For the 20xx hack, @ Achilles1515 must have relocated/removed this data. If you try to load a v1.02 iso, it will try to interpret what is already there but this most certainly result in a crash.

I'm not entirely sure what the best way to work around this is to be honest. Maybe there is a location that the FSM code can be put that would not interfere with 20xx or vanilla 1.02? For the time being this feature may just have to be 20xx only.

Ah, that makes sense then. I wish I could be of more help with a solution for vanilla Melee but at the moment I'm not familiar enough with dol editing to do much.


Since FSM editing(for 20xx) is functional, and the features I've added are mostly complete* do we want to consider an official release soon?

The only things missing that I could quickly add are some script classes for what @ Gentlefox mentioned (Although I'm not sure if I could get a script for 70 AA BB CC working quickly; Bit shifting confuses me a little lol)

That, and I have an idea for character specific attributes that would make them more streamlined/easy to update with new information without having to push a new release of Crazy Hand. I could jam that in the program in an hour.



*:

Spoiler

I'm still not sure if script switching is 100% airtight yet, but everything I've tried so far works fine.
The issues are minor:

1. Due to how Crazy Hand is currently set up to predict accidental subaction endings, meaning if 00 00 00 00 is part of an unrecognized script, Crazy Hand will replace that 00 00 00 00 with CC 00 00 00 because it thinks the zeroes are leftover garbage data from changing scripts. That is a possible occurrence, but I haven't observed it through my own personal use yet.
2. When replacing a smaller script with a larger one (I.E replacing synchronous timer(4 bytes) with throw(12 bytes) sometimes leftover data from the scripts below the one being replaced will still be present. Imagine this scenario:

Synchronous Timer(4 bytes, 04 00 00 05)
Hitbox(20 bytes, 2C 81 10 05 03 E8 00 00 00 00 00 00 29 99 02 93 00 0C 00 8F)

If we replace the Timer with a Throw, we need to borrow 8 bytes from the data below. In this case, that is the first 8 bytes from the hitbox(2C 81 10 05 03 E8 00 00). This leaves us with leftover garbage data that is the rest of the hitbox(00 00 00 00 29 99 02 93 00 0C 00 8F). Crazy Hand will immediately look through all the subaction data to check if there's any occurances of 00 00 00 00 after a script switch. It changes any it finds to CC 00 00 00 to prevent it from thinking the subaction ends early. After that's done, we have this data in the subaction:
88 00 00 00 00 00 00 00 00 00 00 00(The new throw script we just created)
CC 00 00 00(A self-damage script set to do 0 damage, previously 00 00 00 00 in the hitbox)
29 99 02 93(Garbage data from the hitbox)
00 0C 00 8F(Garbage data from the hitbox)

Crazy Hand won't crash or behave strangely with the garbage data, but right now the user does have to fix it manually. Depending on when we want to release a new build, I could make Crazy Hand check the scripts it is replacing and handle garbage data by turning each 4 bytes of it into CC 00 00 00.

 

[Gentlefox]

The only things missing that I could quickly add are some script classes for what @ Gentlefox mentioned (Although I'm not sure if I could get a script for 70 AA BB CC working quickly; Bit shifting confuses me a little lol)

Achilles explained above, but it's pretty simple.

If we call it [70 AA BB CC] the AA part is simply divided by 4 to get the bone ID (in hex)

BB CC is what holds the body state. The CC part is all that currently matters because there are only 3 body states, but for the sake of completeness you should consider BBCC the value. I doubt anyone will ever hack in another 252 body states, but it's your call.

 

[Ampers]

@ Tater ,

Looks like we definitely should be ready for the next release soon. I think for the time being we should focus entirely on polishing up what we have and not adding new features. This way we can be sure that all of the bugs are hammered out before moving on to anything else. My thought was that we could first release v1.20, and then for small editions and/or bug fixes we could do a v1.21. How's that sound?

And whenever you get a chance could you put your code up on github? I'm planning to do a fairly thorough search for bugs/glitches before the next release, so I'd like to have both of our code combined before I begin looking.

 

[Achilles1515]

You need to have the user be able to specify the start of the FSM list, because it can be anywhere they want it to be. I would also put a note in there that it actually requires external code to be added, because it sounds like you guys aren't adding the actual FSM engine code into the DOL file.

Achilles explained above, but it's pretty simple.

If we call it [70 AA BB CC] the AA part is simply divided by 4 to get the bone ID (in hex)

BB CC is what holds the body state. The CC part is all that currently matters because there are only 3 body states, but for the sake of completeness you should consider BBCC the value. I doubt anyone will ever hack in another 252 body states, but it's your call.

You need to take the first halfword, subtract 0x7000, and then divide by four. If you just use the second byte, then you will not be able to reference any bones greater than 0xFF/4=0x3f=decimal 63. Which there are some greater.

 

[Gentlefox]

You need to have the user be able to specify the start of the FSM list, because it can be anywhere they want it to be. I would also put a note in there that it actually requires external code to be added, because it sounds like you guys aren't adding the actual FSM engine code into the DOL file.


You need to take the first halfword, subtract 0x7000, and then divide by four. If you just use the second byte, then you will not be able to reference any bones greater than 0xFF/4=0x3f=decimal 63. Which there are some greater.

Oh. MyB. Thought you just included the subtract 0x7000 part because it's easier to deal with half words or something. How does it know it's the 70 command if that can overflow into it though?

 

[Achilles1515]

Oh. MyB. Thought you just included the subtract 0x7000 part because it's easier to deal with half words or something. How does it know it's the 70 command if that can overflow into it though?

So it ignores the two rightmost bits of the command byte. This is why commands start at 04 and not 01 or 02.

 

[Ampers]

I would also put a note in there that it actually requires external code to be added, because it sounds like you guys aren't adding the actual FSM engine code into the DOL file.

Actually Crazy Hand will inject the fsm engine code into the DOL for you.



Also Crazy Hand currently has it's own bit shifting algorithm written that should be able to handle what you guys are talking about fine.

 

[Achilles1515]

Actually Crazy Hand will inject the fsm engine code into the DOL for you.

Anywhere you want it to (both the code and the FSM list)? What if you already have code at a place it is trying to write it to?

 

[Ampers]

Anywhere you want it to (both the code and the FSM list)? What if you already have code at a place it is trying to write it to?

It won't put it wherever you want, it will always do a fixed location (0x4088B0 for the code, 0x4098B0 for the modifiers).
If there is code already present there, it will overwrite it when you press the save button. I plan to add a fail safe that prevents this in the future.

 

[Ampers]

Hey everyone, It's been a very long time since the last official release of Crazy Hand, but Tater and I are finally ready to show you v1.20.

There are a whole host of new features to play with in this build, but of them the three major additions are script swapping, special move floating point support, and FSM support. Here are brief descriptions of what they do:

Script Swapping (credits to Tater): You are now able to quickly and easily swap out the individual events of a subaction with new ones. The name of each event is now a drop-down menu where you can then select a new one to replace the old one with. In addition to this, each event also has the ability to shift it up or down with buttons on the right hand side.

Article Floating Point Support (credits to Tater): Edit the unique values that each character has associated with their special moves. Each known value displays the move, as well as a brief description of what each particular value does. (Major credit also goes to this article for documentation on this).

FSM Support (credits to Ampers): Crazy Hand now has support for the "Frame Speed Modifier" code written by the wonderful @Magus420. You can now quickly and easily add in modifiers that affect how quickly an action occurs, and on what frames it affects. Crazy Hand will also automatically put the modifiers in the correct order that the FSM code requires (All modifiers of the same character grouped together, and starting frames listed in reverse order for each specific subaction). Pressing save will also inject all of the necessary code for the FSM engine to work properly.
Please note: Due to a pretty big oversight when designing this, only 20xx iso's are currently supported for the FSM GUI. The reason being that a vanilla melee v1.02 iso already contains data in the location that Crazy Hand tries to put the FSM data. Achilles' 20xx hack on the other hand has this location completely free and usable making it the only currently supported iso.


Here's the list of all the other additions that have been made since the last version of Crazy Hand:

--Characters are now displayed with icons, not just names.
--Support for the "Graphic event". Now displays fields for the Graphic ID, x, y, and z positions, and x, y, and z spread.
--Support for the "Sound event". Now displays a field for the sound ID.
--Edit special move subactions from the "Attacks only" menu for subactions.
--"loops" in subactions are now displayed in a different color.
--There is now a file menu at the top of the window. It has a number of new features in it:
Open a new iso without closing the program.
Save a single character file from your iso.
Load a single character file into your iso.
Run dolphin directly from the program.
--Hitboxes now display the hitbox ID and hitbox interactions.
--Character randomization can now be seeded.
--Various bug fixes.


That's all of the major changes that I can think of. As always, if anybody has any questions/comments/bug reports, we're always happy to hear them. Thanks!



Now I have one last thing to say:
This version of Crazy Hand will be the last major version that I will be working on. I have added pretty much every feature that I wanted to the program and I am quite content with it. I've talked with Tater about this and he said that he plans to continue working on some aspects of the program still, but he did say he will likely be slowing down quite a bit.
This has certainly been an incredibly fun project and also a great learning experience for me. It's great to see how many people have found a use for the program. I've very much enjoyed working with everyone who has contributed to this project, in any way shape or form.
I definitely don't plan to completely vanish from the Smash scene though. I'll still be around, checking Smashboards, helping out if needed, etc... I also have some other smash related projects in mind that I plan to work on in the future. I will of course also do my best to fix bugs in the latest release, should any be discovered.



Anyways, here is the download link: Crazy Hand v1.20
Happy modding!

 

[NintenNess]

@ Ampers Holy Mary Mother of Jospeh, this is incredible!

 

[Ampers]

@ Ampers Holy Mary Mother of Jospeh, this is incredible!

Glad to hear that you like it, although most of your praise should be directed at Tater, not myself. He was the one who made most of the contributions for this update.

 

[Tater]

Hey all, hope you're enjoying the update

I know one feature that got some attention before release was modifying what projectile is spawned from certain moves(Like Falco shooting Zapdos from his blaster. Good times.) Some characters have these entries in their character specific attributes list such as Falco, Fox, Peach, Young Link, etc.

But, there isn't a proper list of ID's for said projectiles/items in Crazy Hand, or on the internet(from what I've found) that Crazy Hand will accept. That's because Crazy Hand needs an integer value for a projectile, and the lists I've found are in hexadecimal.

It's a simple enough process to convert a hexadecimal value into an integer value, but I went ahead and made a list of projectile ID's that you can use for Crazy Hand without any extra work.

(Note: The source of this list is from http://arcentral.net/ssbm/desc/objectmod.html)

Spoiler

1 Box
2 Barrel (Taru)
3 Egg
4 Partyball (Kusudama)
5 Cannon (TaruCann)
6 Bombomb (BombHei)
7 Mr. saturn (Dosei)
8 Heart
9 Tomato
10 Star
11 Bat
12 Sword
13 Umbrella (Parasol)
14 Green shell (G Shell)
15 Red shell (R Shell)
16 Laser Gun (L Gun)
17 Freezie (Freeze)
18 Foods
19 Motion Sensor Bomb (MSBomb)
20 Flipper
21 Super scope (S Scope)
22 StarRod
23 LipStick
24 Fan (Harisen)
25 Fire flower (F Flower)
26 Big mushroom (Kinoko)
27 Small mushroom (DKinoko)
28 Hammer
29 Warp star (WStar)
30 Screw attack (ScBall)
31 Rabbit hood (RabbitC)
32 Metal Box (MetalB)
33 Cloak (SpyCloak)
34 Pokeball (M Ball)
35 green triangular prisim
36 Star Rod Star
37 Lips Stick Dust
38 Super Scope Beam
39 (Not specified)
40 Hammer Head
41 Flower
42 Yoshi's egg
43 Goomba (DKuriboh)
44 Redead (Leadead)
45 Octarok (Octarock)
46 Ottosea
47 Stone
48 Mario's fire
49 Dr.Mario's Capsule
50 Kirby's Cutter beam
51 Kirby's Hammer
52 Raygun beam
53 (Not specified)
54 Fox's laser
55 ? Falco's Laser ?
56 Fox's shadow
57 Falco's shadow
58 Link's bomb
59 Young Link's bomb
60 Link's boomerang
61 Young Link's boomerang
62 Link's Hookshot
63 Young Link's Hookshot
64 Arrow
65 Fire Arrow
66 PK Fire
67 PK Flash
68 PK Flash
69 PK Thunder
70 PK Thunder
71 PK Thunder
72 PK Thunder
73 PK Thunder
74 Fox's Blaster
75 Falco's Blaster
76 ? Link's Arrow ?
77 Young Link's arrow
78 PK Flash (explosion)
79 Needle(thrown)
80 Needle
81 Pikachu's Thunder
82 Pichu's Thunder
83 Mario's cape
84 Dr.Mario's cape
85 Smoke (Sheik)
86 Yoshi's egg(thrown)
87 (Not specified)
88 Yoshi's Star
89 Pikachu's thunder
90 Pikachu's thunder
91 Pichu's thunder
92 Pichu's thunder
93 Samus's bomb
94 Samus's chargeshot
95 Missile
96 Grapple beam
97 Sheik's chain
98 (Not specified)
99 Turnup
100 Bowser's flame
101 Ness's bat
102 Yoyo
103 Peach's parasol
104 Toad
105 Luigi's fire
106 Ice(Iceclimbers)
107 Blizzard
108 Zelda's fire
109 Zelda's fire (explosion)
110 (Not specified)
111 Toad's spore
112 Mewtwo's Shadowball
113 Iceclimbers' Up-B
114 Pesticide
115 Manhole
116 Fire(G&W)
117 Parashute
118 Turtle
119 Sperky
120 Judge
121 (Not specified)
122 Sausage
123 Milk (Young Link)
124 Firefighter(G&W)
125 Masterhand's laser
126 Masterhand's bullet
127 (Not specified)
128 (Not specified)
129 Crazyhand's Bomb
130 (Not specified)
131 (Not specified)
132 (Not specified)
133 (Not specified)
134 (Not specified)
135 (Not specified)
136 (Not specified)
137 (Not specified)
138 (Not specified)
139 (Not specified)
140 (Not specified)
141 (Not specified)
142 (Not specified)
143 (Not specified)
144 (Not specified)
145 (Not specified)
146 (Not specified)
147 (Not specified)
148 (Not specified)
149 (Not specified)
150 (Not specified)
151 (crashes with peach pulls out)
152 (Not specified)
153 (Not specified)
154 (Not specified)
155 (Not specified)
156 (Not specified)
157 (Not specified)
158 Coin
159 (Not specified)
160 Null pokemon entry?
161 Goldeen (Tosakinto)
162 Chicorita
163 Snorlax
164 Blastoise
165 Weezing (Matadogas)
166 Charizard (Lizardon)
167 Moltres
168 Zapdos
169 Articuno
170 Wobbuffet
171 Scizor
172 Unown
173 Entei
174 Raikou
175 Suicune
176 Bellossom (Kireihana)
177 Electrode (Marumine)
178 Lugia
179 Ho-oh
180 Metamon
181 Clefairy
182 Togepi
183 Mew
184 Celebi
185 Staryu (Hitodeman)
186 Chansey
187 Porygon2
188 Cyndaquil (Hinoarashi)
189 Marill
190 Venusaur (Fushigibana)
191 Chikorita's Leaf
192 Blastoise's Water
193 Weezing's Gas
194 Weezing's Gas
195 Burn ??? Fire something
196 Burn ??? Fire something
197 Charizard's Breath
198 Charizard's Breath
199 Unowns
200 Lugia's Aeroblast
201 Lugia's Aeroblast
202 Lugia's Aeroblast
203 Ho-oh's Flame
204 Staryu's Star
205 Healing Egg
206 Cyndaquil's Fire
207 ??? invisible
208 (Not specified)
209 Target
210 Shyguy (Heiho)
211 Koopa(Green) (Nokonoko)
212 Koopa(Red) (PataPata)
213 Likelile
214 (old-lead)
215 (old-octa)
216 (old-otto)
217 White Bear (whitebea)
218 klap
219 Paratroopa (Green) (zgshell)
220 Paratroopa (Red) (zrshell)
221 (Not specified)
222 (Not specified)
223 (Not specified)
224 (crashes with peach pulls out)
225 Apple
226 (Not specified)
227 (Not specified)
228 (Not specified)
229 (Not specified)
230 Tool
231 (Not specified)
232 (Not specified)
234 Arwing Laser
235 Wolfen Laser
236 (Not specified)
237 (Not specified)
238 (Not specified)
239 (Not specified)
240 (Not specified)
241 (Not specified)
242 (Not specified)
243 (Not specified)
244 (Not specified)
245 (Not specified)
246 (Not specified)
247 (Not specified)
248 (Not specified)
249 (crashes with peach pulls out)
250 (Not specified)
251 (Not specified)
252 (Not specified)
253 (Not specified)
254 (Not specified)
255 (Not specified)

Hope this helps

One last side note about projectile ID swapping:
Melee is very finicky about how a new object such as an item or projectile is spawned. This can create very odd effects and sometimes leads to crashes when you do things such as:

Replacing Falco's laser spawn ID with odd entries such as Crazy Hand's bomb, or Yoshi's egg. The game treats the lasers as items, but... Not properly. If you want to know exactly what I mean try it out for yourself.

Making Peach pull pokemon instead of Turnips.

Making Link shoot pokemon from his bow.

Making a character spawn a projectile that is "not theirs" (I.E trying to make Peach pull a PK thunder instead of a turnip, Young Link trying to throw a G&W parachute instead of a boomerang, etc)

 

[flieskiller]

Can Link/Young Link spawn a Pokéball with their down-b instead of a bomb without problem?

 

[MagicScrumpy]

Yes.

10char

 

[SwiftNinjaBlackMan]

hmm the projectile ID swap isn't working for me =( i can't make falco shoot Ho-oh's Sacred fire

 

[Tater]

Can Link/Young Link spawn a Pokéball with their down-b instead of a bomb without problem?

hmm the projectile ID swap isn't working for me =( i can't make falco shoot Ho-oh's Sacred fire

General rule I've found with projectile ID modification is it will work 100% of the time if the object replaced has the same properties as what it is being replaced with.
For instance, replacing an item with another item will always work fine. Replacing an item with an object that is not normally holdable will confuse melee, resulting in odd errors and issues with letting go of non-holdable objects. Z-dropping will always work in this case.

Replacing a projectile with another projectile is inconsistent. In some cases it works 100% fine, in other cases (Such as replacing falco's laser with Ho-oh's fire) it will either A) crash the game B) not do anything at all C) work as intended.

I think what works with what has something to do with how the subaction is programmed, and the subaction properties(Might be the wrong name, it's something to do with subactions in main.dol. I remember reading a post about them and how to change Yoshi's shield so he can jump out of it but for the life of me I can't find that post again.) The game needs the right data put in the right places for it to properly spawn an item/projectile/any object really. Without that data, issues will occur. I don't have enough knowledge of how it all works to be of any more help at the moment, unfortunately.

 

[Ampers]

does anybody know the name of the subaction for taunt? I've never been able to find it.

 

[Doq]

Afaik it's Appeal (or AppealL and AppealR for chars with two taunts)

 

[Tcll]

Afaik it's Appeal (or AppealL and AppealR for chars with two taunts)

hmm, wonder if we could staticly add AppealU and AppealD :3

 

[standardtoaster]

I don't see why it wouldn't be able to be done. You'd just need to be able to add additional subactions properly and then have a code to check if dpad up/down do respective subaction.

 

[SwiftNinjaBlackMan]

is ganon's Up tilt uneditable?

 

[Ampers]

is ganon's Up tilt uneditable?

I've wondered that myself for a while. I'm sure it must be editable in some way, just not via Crazy Hand. I don't know why but the code for that move must be stored elsewhere.

 

[Achilles1515]

I've wondered that myself for a while. I'm sure it must be editable in some way, just not via Crazy Hand. I don't know why but the code for that move must be stored elsewhere.

What can you not edit? Hitbox data?