Updated scripts for SSBM v1.0 *Update 2*
After 2 days of searching and -*test*-('")ing, me and psychotic worm have been able to find the "real" damage scripts in super smash brothers Melee, v1.0. The current scripts in fuzziqer's scripts only deal with damage that is displayed. While useful, it doesn't fix desyncing issues. In reality, the damages inside the games are desynced and your opponent may go flying at 30 percent in really bad cases (of course, they'll stay in place because of the position scripts). These scripts fix that. All damage is now synced up. Please note, DO NOT removed fuzz's old damage scripts. Those are important as well. Also, please note that player 3 and 4's scripts have not been -*test*-('")ed over the internet. However, they -*test*-('")ed through on GCNrd GUI so it should work fine. Player 1 Script additions: 42451170 0C480000 42451170 0C490000 Player 2 Script additions: 42452000 0C480000 42452000 0C490000 Player 3 Script additions: 42452E90 0C480000 42452E90 0C490000 Player 4 Script additions: 42453D20 0C480000 42453D20 0C490000 Update 1: Sorry, psychotic, I couldn't wait ><. I went ahead and -*test*-('")ed it out with perfekter. And for the large part, these new scripts work very well at greatly reducing desyncing. These are the "previous position" variables I've been talking about. They keep the previous position of the player so if this is kept track of, desyncing problems should go down, like me and perfekter confirmed. If the player is in the air, the syncing should be instantaneous. However, on the ground, one other variable is needed and I have located it and have made scripts for it (they have not been -*test*-('")ed yet). However, I'm reluctant to -*test*-('") it yet due to the lag problems I've been faced with. There are just too many scripts now that lag is becoming a problem. I can't play a game currently without putting update speed to 4 because of the backlog of information that needs to be sent if I put it any lower. So I'll hold off on the "ground syncing variable" now until we have bandwidth to spare. Right now, I'll just give this out because it's crucial for syncing: Prev Position scripts: Player 1: 42451170 03AA0000 // x prev coord high 42451170 03AB0000 // x prev coord low 42451170 03AC0000 // y prev coord high 42451170 03AD0000 // y prev coord low Player 2: 42452000 03AA0000 // x prev coord high 42452000 03AB0000 // x prev coord low 42452000 03AC0000 // y prev coord high 42452000 03AD0000 // y prev coord low Player 3: 42452E90 03AA0000 // x prev coord high 42452E90 03AB0000 // x prev coord low 42452E90 03AC0000 // y prev coord high 42452E90 03AD0000 // y prev coord low Player 4: 42453D20 03AA0000 // x prev coord high 42453D20 03AB0000 // x prev coord low 42453D20 03AC0000 // y prev coord high 42453D20 03AD0000 // y prev coord low The next variable I'm going to be looking for is the variable that says if the character is in the air or not. There may be more than one and I've tried once and failed at finding it so I'm giving it another shot. If I can find this next variable, the game should keep track of if the player is on the ground or not. Due to the way the game works, this is actually sort of important because movement works differently on the air and ground. Update 2: It seems while in the air or while doing a move that doesn't require direction input (like neutral air, neutral a/b on the ground, or grabbing), the direction a character faces can become desynced. So, there are two variables that need to be synced up, immediate facing direction (which changes the direction the character faces during a move but immediately reverts afterwards) and the character facing direction (when poked, it changes directions after the current animation is finished or a new one is started). To save bandwidth, I guess all you really need is the immediate facing direction but that's not tied to the "regular" pointer variable that most other variables are for in game things and is has always been 200 (in hex) units BEFORE the value in said pointer variable so that's not found yet. For now, we'll have to deal with the other one, which should help with facing desyncs: Player 1: 40451170 00008C00 Player 2: 40452000 00008C00 Player 3: 40452E90 00008C00 Player 4: 40453D20 00008C00 Suggested scripts to use: To conserve bandwidth and reduce backlog, it is suggested to add all the codes found here but also remove: From script 1: the cpu information in global number of coins chip data From scripts 2 to 4: number of coins hand data chip data As long as only player 1 does all the menu navigating.

you are the most awesome person in the universe.

Thanks psychoticworm! :) Oh and fuzziquer, if you're reading this, we're after another thing as well, the position variable. How did you find the position variables you put in your script? Maybe I could get some inspiration off of that. Thanks for making this awesome program, btw fuzz.

Finding XYZ (or, in SSBM's case, XY) coordinates is easy. Here's how I do it: 1. Move your character to the right of the center of the stage. 2. Search Unknown Value. 3. Move right a bit more. 4. Search Greater Than. 5. Move left, but do not move past the center of the stage. 6. Search Less Than. 7. Repeat steps 3-6, throw in a few Equal To searches, etc. Basically, the farther right you are, the greater the value is, as long as you don't go past the center. 8. When you have just a few addresses, start poking them with 00000000. If you find one that causes your player to jump towards the center of the stage when poked, that's the one you're looking for. Basically, it's what Biolizard said.

well I think we are both looking for character positions. Ones that are relative to other characters. Like character 1's X distance from character 2, and character 1's Y distance from character 2. I'm pretty sure you could use the same way of finding those variables, but what do you think?

I'd be surprised if they even kept track of a variable for that. You usually never need to keep a separate variable for relative position between characters since it's usually very dynamic and you only use it once in a calculation before it changes again. You usually just want to build that into the calculation; it would be inefficient to first put that info into another variable before using it in collision detection algorithms. Thanks for the help by the way, fuzziquer and biolizard. However... I found out that fuzziquer's coordinate scripts seem to be relative to the map, not to the camera, so my previous fears were unfounded. However, something odd I found was that moving 70 decimal units right of center on a map seemed to change even while I was still playing on the same map. For example, on jungle japes, 70 units from center would always take me far enough to grab onto the left ledge of the rightmost platform. However, later on, I would actually land ON the platform, with my units right of center STILL being 70. (Edit: And it would not simply because of the fact that I was running INTO the ledge. In fact, during the times I did it, I would above the platform.) If this is true, that would explain why we would explain some of the odd desyncing issues. It would also explain why sometimes one person would immediatly go into sudden death mode; the players almost always start left or right of center so their position variables are never 0. Let's say player 1 starts the game right of the center of the level. Let's also say his position variable is equal to 40. It could be that in player 2's gamecube, 40 is (at that moment) to the extreme right of the level, far enough to kill someone. On player 1's gamecube, it's about where it's supposed to be. So on player 2's gamecube, player 1 dies 4 times in a 4 stock match, thus making him "lose" on that screen. However, player 1's "lives" variable (see fuzziquer's SSBM scripts) is telling gamecube 2 that he still has 4 stock left. Thus, player 2's gamecube goes into sudden death while player 1 starts the match as normal. Another thing I noticed is that the position variables don't let you go through walls or past ledges. I think I have an idea why too. In every game I've programmed since 9th grade, I've not only kept a variable holding the "current" position of your character but also the "previous" position of your character; this allows for you to know from where you came from before. So, let's say if Mario hits a goomba from the side, he dies. However, if he comes from above, he lives. If you have the "previous" position of both your character and the enemy, you can easily calculate if he came from the top or side. I'm guessing that's how smash is programmed as well, which is why character's can't go through walls and why if they're facing the edge of the level and you "poke" a value to take them farther than the edge, they get stuck at the edge in a "whoa I'm going to fall" animation. Which is another reason why desync is happening. With the "real damage" now constant between gamecubes, desync should improve a bit because the gamecubes' momentum procedures aren't competing between each other. However, there is still this leftover issue with position. I don't know if I'm exactly right on what I said but it seems to be the issue. Right now, I'm sort of tired from trying to find the damage scripts so I'm going to take a little break as of now. Some of it, I'm sure, is just due to lag but you'd think that at the very least when all the player's scripts are put into script 1 (to make them all global), the positions would at the very least match up perfectly. However, when psychotic and I tried that before, our characters would be desynced and for some reason stay desynced, even when there is obviously not a wall or a ledge to prevent it from resyncing. Oh well, I'm tired. Anybody have any ideas?

well the updates to the current damage scripts are working wonderfully, but there is still a problem with anumations being out of sync. For example, when player 2 is like on the ground doing a down smash on his screen, on my screen he might be twirling in place, because I did a smash attack upward on his character. His game randomly doesn't register the smash attack I did, so on my screen he would be twirling around in circles, when on his screen the animation sequence might be him finishing the smash attack he executed. Its like some buttons being pressed, arent updating fast enough, so we would need to come up with some kind of 'animation sequence' script. Like say if he is jumping over me and pressing A in mid air, i press up-A to cancel it out, and on his screen it cancelled out successfully, but on my screen, My up-A 'sends him flying' because the cancelling out didn't register on time in my game. his character will still be following the same exact path, up and over me(because of the position/coordinates scripts) but he might be in a "flying away" animation on my screen, instead of just fall to the ground like normal. On my screen it would have looked like I hit him, but he recieves no damage BECAUSE on his screen he had cancelled out the move. I was really thinking hard about how we could resolve most of this issue, dealing with animation frames. I realize it will be extremely difficult to create the scripts for something like that, because theortically you would have to make scripts for every character, and every single animation of each character. but it would definitely increase the accuracy/syncing between the people fighting. The thing is, I don't know what size variables I should search for, 8,16 or 32, or even if frame-by-frame animations are stored as variables. With that we evedn run into more problems. Animation sequences can be interrupted, but since the script would be constantly updating each animation to more accurately show what the other player is actually doing, it would still be better in sync. ANY IDEAS??

You shouldn't need to make scripts to find every character's animation and frame sequences. I would suggest just finding the one or few variables that hold animation data. The way this is handled is different from game to game. For instance, in MUGEN, a fighting game engine/maker that I was into a few years ago, each player had a variable that held the "animation ID", which is just identifies the animation of the character (like kick, jump, haydoken, superduperspecialattack, etc) and another variable for the "frame number" (which is just the frame within the animation that the character was currently in). I adopted this strategy in my own fighting game that I started making (and never finished). I'm pretty sure that at the very least, the game keeps track of frames within an animation. When people talk about Super Wave Dashing with Samus, they always talk about the 41st or 42nd frame of the "bomb laying" animation. IASA frames for certain moves, like when you are allowed to jump cancel Fox's deflector, seem to indicate that this is the case for Smash. Also, Smash is also a 2-d fighter, much like mugen (and other 2-d fighting games that work similarly). Maybe try to find out the variable that holds Animation ID and frame number for each player? It's worth a shot. And thanks, biolizard, for bringing to my attention the "pause" function in GCNrd. I had no idea that's what that button did. Friggin A. So THAT's how you do individual pokes :lol: . Well, I'll try that out. Thanks for the tip.

^^ok well i would have no idea how to -*test*-('") something like that, except pure guess and check. I mean its not like I could do a greater than/less than search. The best way would be a "different by.." search which is still very vegue. How could I search for a variable like that?? I have absolutely no idea. And would they be character based? like would I need scripts that cover each individual character, or something that relates to button presses(each button press triggers the proper animation) I imagine the variables could look something like this: Pikachu Fwd Smash --> Character.....Animation......Frame ...1A................01AA.............01 Pikachu Dwn Smash V Character.....Animation......Frame ...1A................01A3.............01 Fox Over B --> Character.....Animation......Frame ...B3................14F8.............01 I'm not coming up with anything...

There's all sorts of things you can try. The first thing that comes to mind is to try a slow move, like Falcon Punch and just pause it and do a greater than search. Assuming you can pause at the right moments. Frame numbers go up in a move. As far as those moves are concerned, none of those moves are 1 frame long, if they run on frames. Pika's forward smash is definitly not 1 frame long. It is a really long move. Same with his downsmash. And it takes more than 1 frame (1/60 of a second) to do Fox's fantasmal. I'm not even sure if there is a move in the game that is only 1 frame long. And anyway, you can always go into slo mo melee anyway.

Well I figured out a way to do it, and I'm getting very consistant variables. I first tried greater than searches, moving frame by frame, but that didnt go anywhere. I tried a few more ideas, and eventually I tried something else. I got a 16-bit search, I started searching different by 00000001, and a few equal too's and bravely threw in a greater than, somewhere near the end of the animation. It didn't work. So the next try I did the same search, but thrw in a greater than variable at the beginning of the animation....its working... So I guess the way the variables are set up is they run off a time limit, the variables seem to be counting down the further into the animation you are, and at the end of it, the value to the variable is 0000. I'll have to do some more extensive -*test*-('")ing, but I think I got an idea of how the vars are working. Another thing that makes sense is that, well, you can't possibly do 2 different animations at the same exact time with the same characxter, so that alone may help in determining what to look for in the variables. So far its making sense.

Effing A!
I really hope this is not just specific to Peach's castle but I narrowed down my search to 13 varaibles. A multipoke to all of them and I go right through the middle wall of Peach's castle and fall through the castle instead of stopping at a wall. If I actually found positional x-varaibles that are truely syncing (ignores walls and obstacles for true syncing), I think I may have the next step to making online smash that much more playable. Since I multipoked, it may be either a separate varaiable that ignores walls and such I've found the "previous position" variable among the 13. Thanks for all of your helps. Good luck with those animation scripts psychotic worm. By the sounds of it, looks like you're making progress. If you get the animation scripts and I get these position syncing scripts up, we might finally have a game of smash that feels very much like playing with another person (ignoring the latancy issues of course. Can't get rid of lag, no matter what scripts you put in). LOL! Psychotic, I wasn't even looking for it but I found P1's frame variable on Peach's Castle. I'm guessing this is a pointer variable so you'll have to find it on every level but basically, if you poke this variable while doing ANY action, the character will immediatly go into that numbered frame in their animation, which sounds exactly like the variable you found. And it DOES seem to count down. When I poke it at 0, it just stops the animation that it was doing. And when I poked it with FF (255 in decimal) the game froze so I'm assuming this is what it means. Since it's probably a pointer variable, I'll go ahead and give you the code, remember Peach's castle with no items and only p1 and p2 on: 80C7185C. Wow, I is confused. When in the air, this "previous" value works just like I'd think it would. However, when the player is on the ground, suddenly, the game starts paying attention to the regular rules again.... wait, maybe it has something to do with the "previous y" value? Makes sense, right? Since it only bugs up when a player is on the ground... yeah. Time to try it out. Well, specifically, find the "y" value. Okay I am currently not as confused but still have questions. I have found the "previous position" variables for both x and y for player 1 on Peach's castle (with some help from fuzziquer's current position scripts; shortcuts are fun). However, they only work like they should when one is not on the ground. Sure, when you're in the air, it works like it should; if you set the previous var to the left side of the wall but your current position is on the right side, you should immediatly teleport to the very leftmost part of the wall. However, when on the ground, the previous y var does nothing and the previous x variable seems to act like the current x variable... some of the time. Huh, that was a lot easier than I thought it would be. The previous variable does indeed work like it should but the way it is used is a little different on the ground, which explains a few things. Nevertheless, I think that since the player that gives the values should have proper prev and curr values to give, it won't do the wierd things it did on my screen, because I was just putting in values that the game probably doesn't understand. Anyway, I've found the previous position codes. Thank you bio and fuzz for all the help (and thanks fuzz for already making the "current position" scripts; made it a lot easier to find the previous positions). I'll have the codes updated as soon as I -*test*-('") to make sure they work as intended.

uuh...something about that code is making my game freeze. Its also not working. Also, What characters were you, and was it a timed match, stock match, and were you P1 or P2?? Also, GCNrd keeps corrupting my memory card, and its a nintendo brand card... REALLY ANNOYING. This seems to be a rather difficult code to hack, it seems to just keep changing no matter how many times I play the same battle, the variable appears in a different part of the ram.