Script Effiency (Question for Fuzziqer)
Hey fuzziqer, I need to know something about Gcars. I think I know how it uses scripts. Since it has an AR simulator, I'm guessing the Gamecube sends it's scripts (determined by script 1, 2, 3, or 4) to the other gamecubes with the values filled in. The other gamecubes recieve this and runs this through the AR simulator (sticking the values into the proper place in RAM). Does this sound about right? My question is, is it possible to only send certain scripts at certain points? For example, the chip and hand scripts are really only needed at the character selection screen. Keeping track of number of coins need only happen in a coin battle. Same with stock. Etc. The reason why I ask this is because I fear that all of that data being sent is causing a "backlog" to happen on the Gamecube. With my most recent script updates (the position ones), the desyncing has gone down considerably. However, another problem has come to surface: the backlog issue. When my last scripts were -*test*-('")ed, we noticed that as the battle went on, we began to become more and more "slow", meaning our reaction times were getting worse. I actually took the opportunity to -*test*-('") it and indeed, when I left where I was before to hide at a ledge, my opponent kept on fighting in the same place fighting nothing for several seconds before moving on to the ledge to try and hit me. I rolled away right before he got there but instead of following me back on stage, he downsmashed the ledge at least 4 times before realizing I wasn't there. When we later set the update speed to 4, no such issues were in place. However, as you know, update speed 4 is excruciatingly choppy. It was playable, no doubt, especially with the new scripts in place, but we wanted to play a game where our opponent wasn't playing at 15 fps. Before, when there weren't as many scripts, the we would notice little to no backlog issues. True, it could have been disguised in the rubber banding. However, if it was, it didn't happen nearly as much. Every single time we played at update speeds lower than 4, the backlog issue would return in full force. Before my new scripts were added, we could play at update speed 0 with 3 people and we would be able to resync ourselves by simply positioning ourselves. If there was a backlog issue, we wouldn't have even be able to resync. Like that. When we noticed the backlog issue after we but the scripts in, we tried stopping the game for a while, to see if it would finish sending whatever packets, hoping since we weren't doing anything that we would return to the same time zones again. It didn't happen, we still had the backlog. I'm not sure it's a sending/recieving issue either because we both have broadband and we're sending a combined total of 2 kilobytes of data to each other. I think it has more to do with the fact that there are too many instructions being given to the AR simulator at smaller update speeds and the gamecube slows down as a result). Also, psychoticworm set up his webcam. Even with the added bandwidth pressure of the webcam, my gamecube and his gamecube never strayed furthur from each other timewise (this was before I added the new scripts). It could still be a sending recieving thing but it could also be this. Either way, I was hoping that maybe if certain scripts were only triggered at certain times (like in some senarios described in the 2nd paragraph) we would greatly be able to reduce the "backlog" effect in actual gameplay because we would be sending less stuff to do, but we would still be able to keep or even improve the syncing in the menus and character select screen (the game has been known to freeze or desync at certain menus). I mean, we could just talk before hand and figure out what type of game we're going to play and modify the scripts that way. But that can become troublesome. And you can forget about items if this is the case. This will also make syncing up levels just about impossible. And what about the hand/chip data? It's never used in gameplay but it takes up 8 scripts. I really appreciate the work you've put into this, fuzziqer, and thanks for all of your previous help. Thanks for making such a great (and cool, and neat, and awesome) program. Please get back to me on this; I would very much appreciate it.

Thanks for your appreciation :P The backlog problem could be caused by one of two things. First, it could be the fact that the BBA is an EXI device - meaning that it can't send and receive data very quickly, and it may drop data sometimes. It could also be caused by sending packets larger than 0x580 bytes, which will fragment as they're sent and likely cause major problems. The solution to both of these problems is conditional codes. What you'll need is a code that tells if you're in-game or not, and use it to activate the hand/chip codes and position codes. Deactivated codes aren't removed from the packet, but I'll fix this in the next version. In v1.0 (when it comes out), if a deactivated code is present, it'll be removed. You're right about a script being just like an AR code; that's why all the values are zero. The hook function reads the script, fills in the values based on the GameCube's memory, and sends it off - and the remote GameCube runs it just like a long AR code.

Yes, your assumption about how GCARS-CS handles scripts is correct; it fills in the values, sends them, and runs it through the AR simulator on the other Cube. I asked Fuzziqer about this in a PM recently. Cool, that's nice to hear. On the subject of script hacking, I have a question. I'm planning to go through my Super Monkey Ball 2 script line-by-line and figure out which line or lines are crashing the game on boot. But once I figure out what lines are causing it, how would I fix the problem? My impression is that I should do a read breakpoint on the address when in-game (where it doesn't crash it), note the value of the 32-bit location containing the instruction that accessed it, and make that into an if code that controls the original script code. Is that at all close to what I should do? Or is there some other way to deal with it that I don't know about due to my n00bishness? For SMB2, your method sounds good - but as of now, conditional codes don't work too well in the Control Simulator. I'll have the conditional code handling all fixed up in the next version, however. My question was about codes crashing the game when they are synced at times they shouldn't be, but the same fix should apply to this situation. In case you didn't understand the question I asked him, there are "if" code types, which you can find in GCN Code Type Helper. Do a read breakpoint in GCNrd on the variable (not the pointer, although it might work as well) when you're in the part of the game that you want it to be synced in. The breakpoint should trigger immediately, and GCNrd will give you some disassembled code. Most of this you can ignore (you don't have to know any ASM to do this). Just note the address at which the breakpoint occurred, and the value that it has. Make that into an if equal code, with the address and value that the breakpoint gave you. Then put all the codes that you want to be associated with that part of the game inside that if block (how you do this depends on what type of if code you used; there are different ones, e.g. next code, next 2 codes, all following lines until z2 code). If you did this correctly, the codes will only be synced when the if code evaluates to true, and the other Cubes won't have to worry about them. Unfortunately, there's Fuzziqer's comment at the end: conditional codes don't work well in the current version; they will be fixed in the next release. So you won't be able to use this method until the next GCARS-CS release. Oh, and I really hope that the ASM that the breakpoint finds isn't on a pointer. I have no clue how to deal with that (Fuzziqer probably does, though). EDIT: Looks like Fuzziqer beat me to responding. Oh well.

ASM on a pointer is not easy to deal with; luckily, not many games use relocatable modules (the DLLs of the GameCube, if you will).

That's awesome! Thanks for both of your replies! All I needed to hear was "conditional code" and I almost had a seziure from the sheer excitement of hearing that. This way, I can just find the codes relating to if a battle is actually happening or not and just put it in the if-else cases (assuming there is an else. I looked through the GCN Codetype helper and it looks like you need a separate conditional code for in battle scripts and out of battle scripts). This also means that I can work on syncing individual levels! Once v1.0 is released, that is :). And fuzziqer, I think the idea that "sending packets bigger than x amount" will cause it probably is a huge factor. I only added 4 lines of code and before I added those four lines, there was no real backlog issue. Combined with the other issue, right now the game only seems to work with update speed 4. Thanks for all the help! I look forward to the next version! For now, I guess I'll just have to get rid of certain codes, like chip and hand values. They're not that important since whenever I play, we're always on AIM and the characters resync when you go into the "game options" menu anyway. Hopefully, we'll be able to make the menus synced and remove those annoying menu freeze issues.