Ah, sorry biolizard, I already found them. (see last edit in last post). But thanks for the tips anyway. But I did figure out that they were close to each other and they were all using the same pointer var. In fact, I can use the same scripts fuzz made except just change the offsets. As far as the velocity type thing is concerned, that's probably going on to a certain degree with me. However, I haven't found separate variables, which leads me to beleive that there are no other variables; it's just that the variables are used differently on the ground and in the air. Even the CURRENT variables that fuzz uses are used differently in the air and on the ground. I'm going to -*test*-('") to see if I can teleport myself from one stationary ground position to another stationary ground position by messing with these variables. I'll edit my results in. If it IS the case, I'll also have to find the variable that keeps track of if you are on the ground or in the air. But that should be relatively easy to find (boolean variables are 8 bit searches, right?). Oh, and psychotic, don't use any hexidecimal variables that are too high. It'll mess things up. Also, it might matter that I did a 32 bit search. Now that I think of it, it's probably not going to need to be that high. If that's what ends up being the problem, sorry about that. I'm so close to cracking this nut! Edit: Biolizard, you may end up being correct on that actually (about there being separate prev vars for ground and not ground. Although, I don't know if they are prev variables, more as they are "platform" variables. Like which platform you are on and where on the platform you are (and stuff like that). That would sort of make sense considering that I can't warp from one platform to another and that the "current Y" variable is completely obsolete when on the ground. And it would also explain why most of the position glitches happen when a player is moving around on the ground. I'm sure some of it has to do with "prev" position in the air but most of it is seemingly focused on the ground. I take back what I said about being close to cracking this nut. Stupid ground. Adding another layer of difficulty into things. Now I gotta figure out more stuff. Oh well, the prev position vars should at least help a little (after all, to resync, all you would theoretically would need to do is jump, which people do a lot of anyway). Edit2: I've finished up what I believe to be the previous var scripts. I'll upload them into the first post after I've -*test*-('")ed it.

Sorry to double-post, but something you might be interested in hacking once you finish up with this would be a "held item" code. The way I hacked this for Super Monkey Ball 2 was to get an item, search Greater Than, lose the item, and then search Less Than. Repeat, throw in a few Equal To searches, and you should find a code for what item a player is holding. This would make items somewhat usable online. The only weird thing that would happen is that the items lying on the ground wouldn't be synced, so you may see your opponent pick up an item that didn't exist on your Cube until he picked it up. Conversely, any item you can see is probably invisible to your opponent as well. I still think that would greatly improve online play, since currently items can't be used at all. Sound like something you might want to try hacking?

Be careful about that, though. One of the most useful abilities in hacking a game is the ability to think like the programmer. Since I've both hacked games and written them, and I've written one like SSBM, I have a few ideas as to the methods the programmers may have used. In my game, the player's ground/platform identifier is a pointer - ST_PLATFORM_INFO* - within the player's struct. I'm just saying that while an 8-bit identifier is more likely in SSBM, don't rule out a 32-bit identifier, or even a pointer. Side note: plug in two memory cards, but pull out the one in slot A while GCNrd is loading. It should save to slot B correctly; then all you have to do is have that card in either slot when you load GCNrd later.

LMAO! There IS a platform ID variable for each character! That's quite a shock! I was coming in thinking there was no way but there is. Funny that. AND the best part is, it looks like every player has some sort of user defined variable as the structure. What do I mean by that? Well, if you've ever programmed in Java or C++, you know about objects. It's the same sort of thing: each player has it's own object. Therefore, I can use the same pointer variable address and just add the offsets compared to where they are on another variable, such as the position variables. If you notice, all of P1's in game variables are tied to the same script 42451170, which translated to the pointer variable address 80451170. I just need to change the offset and that's easy to find (just find the address of the variable you want to find and then find the difference between that addresses and the address for X coordinate on that level (just look in Memory Viewer), add or subtract that from the offset for the X-coordinate script and you have your code). This process is a little different than for my other endevours for converting to script format because it's and 8-bit offset pointer variable instead of a 32-bit offset pointer variable like the other variables I have been looking for in the past. However, I think all I need to do is change 32-bit to 8 bit and just fill in all the right variables (since 8-bit allows for an offset). And since the bits match up, I don't need 2 scripts but 1. Does that sound right? One of the most useful abilities in hacking a game is the ability to think like the programmer.I didn't know how much this really mattered until I started to hack. You're right, this is a lot easier if you've already been in the trenches of game creation. That being said, I'm going to -*test*-('") out the platform ID and prev position scripts now. Hopefully, everything goes peachy keen.

New scripts are up and they greatly reduce desyncing. Unfortunatly, they also increase lag. I'll make another thread addressing that.

Hey, Fuzz, while we're on the subject of scripts, do you still have the velocity codes that you hacked (the ones that only worked when in the air)? If so, it'd be cool if you posted them (even if they only work in the air, I assume they would improve the game in some cases).

I might still have them; I'll take a look after I get my new computer room all set up :P

Stupid ground variable
This ground variable thing is taking way to much thought. Maybe there are other ways to sync the game other than trying to find this variable.

I am having absolutely no LUCK with the animation codes...I have tried alot of different things. I want to find the variable responsible for triggering and holds the frame number for character animations, per player. What I want to do is be able to find a variable, for Mario to start out with, as player 1, that holds animation data. ITS FREAKING IMPOSSIBLE TO FIND. I'VE POKED THOUSANDS OF VALUES IN THE LAST 3 DAYS, NOTHING HAS BEEN WORKING. Hell, I haven't found any of the ones I've poked to do anything noticible on screen. Basically what I want to be able to do is find the variables that hold animation data(what your character does when you press a button/do any action) for each character, for each player, and use it in the script to keep updating the gameplay so as to keep it that much more in sync. Theoreticly what SHOULD happen when I poke the right variable, My character should either instantly be in the middle of the animation specified by the variable(depending on what frame# I choose for the value) -OR- Either that, or I would have to trigger the animation myself, then poke the variable, and skip a frame and see my character instantly skip to the frame # that was poked. The thing is....NO LUCK I would also like to make some AR codes that keep your character in the same exact frame of animation consistantly throughout the course of a started game. HELP HELP HELP!!! I've tried EVERYTHING!! I'm going NUTZ!! X_X

I'd love to help, but my whole computer system is un-set-up right now, because I'm finally cleaning out the computer room (you wouldn't believe some of the crap I found in there). Try asking on gscentral.org or arcentral.net; many people there have hacked SSBM quite a bit.

Huh, I didn't even think about asking there. Thanks fuzziqer.

The things I have done so far are pretty easy stuff. "Real" damage, previous values, platform ID, and facing direction are all pretty easy to find. However, the values that control whether you are on the ground, in a certain animation, or a certain frame of the animation has proved to be more difficult. For example, frame number of animation is not stored as an 8-bit value, like you'd expect. It's actually stored as a 32-bit hex float (about 67 different memory locations actually hold this information). Which is wierd because they don't even use decimal places... at all. I'd think you wouldn't need more than 16 bits... unless of course, there are higher up calculations that need these frame numbers to be type casted up higher to floats, instead of the lower data types that make more sense to have from an outsider's standpoint. In this case, frame numbers (of animations) are calculated, not stored and incremented. This means that even if you poke the values into these frame data (like I've tried), it won't actually change what happens since the values are simply calculated and used right away, in the same unit of gametime. So even if you pause the game and poke the values at each frame of an animation (using "pause" and "next" in GCNrd), it won't effect anything because once the values are calculated, they're immediatly used and won't be used again until the values are calculated, effectively overriding your poke. That's what it seems like to me anyway. So the obvious way to find what I need is to trace the calculation backwards from the calculated values I've found to see what values I CAN poke to get the results I want (go back to an earlier part of the animation, like the start up part of a smash attack). I've looked at an old GCNrd tutorial and it looks like I'm going to be using ASM at some point. It links to a quick reference for ASM. I'm sure if I spent enough time at it, I would get an understanding of how to use it but I'd rather not spend time reinventing the wheel. Is there a good beginner's guide to ASM somewhere? (Never mind, I found it. Also, does anyone have any other ideas on tracing backwards from the values I've found to find the values I SHOULD be poking? Currently finished and -*test*-('")ed: Damage sync scripts Previous position scripts Direction Facing scripts Finished but not -*test*-('")ed: Which platform your character is on Still need to find the pointer varaible: Immediate Direction Facing scripts Still need to locate (all of which seem to require tracing backwards ): Animation Data Frame number of Animation Data Data on whether or not the character is on the ground or not Anything else that comes up after these scripts are found

I made a quick save file of all the la-*test*-('") updates, so if people know how to use ctr-gcs, they can get the config save for gcars without dozens of minutes of typing. http://files.filefront.com/GCARS_CS_CONFIGsav/;5361745;;/fileinfo.html Depending on how confused most people are by ctr-gcs, which can be found here: http://www.btinternet.com/~s_f_collier/web/n-scene/n-scene/download.htm I could make a guide walking through the steps and maybe recommending some of the GUIs. After a bit of trial and error though, it's pretty easy and really cool. Also, i didn't know of any place better than filefront to upload, so if anyone knows of a good free site that's easy, let me know or make another upload.