Suggestion for gcars
Hey Fuzziqer. I'd like to start off by saying you've made a mighty fine program here. And that this is only a suggestion and you are under no obligation to take it. However, as I've been doing more and more hacking into SSBM, I've noticed a problem: there are a lot of variables that need to be passed in order to ensure that the game is really in sync. Now, conditional codes (like the ones you're working on) will surely do the trick to certain extent but there are still a LOT of scripts even only during battle that need to be passed. (I'm on the cusp of reaching that limit and that's not even talking about the potential for number of scripts that I haven't even gotten close to finding). I've stripped it down to the very basics for gcars .95 play (of the existing scripts I have found) to make the game as smooth as possible: ° Character type, flags, costume (1 byte each) ° Number of kills/Lives/Number of coins (depending on your mode, pick 1 only!) ° Displayed Damage (somewhat optional yet highly recommended) ° Internal Damage high ° Internal Damage low ° Shield Size ° X coord high ° X coord Low ° Y coord high ° Y coord low ° X prev coord high ° X prev coord low ° Y prev coord high ° Y prev coord low ° character selection data ° Facing Direction ° Ground Variable High ° Ground Variable Low ° Falling State Variable High ° Falling State Variable Low And that doesn't even include Animation (high and low), frame data (high and low), the global variables, velocity variables, or any other variables that may be deemed necessary in the future. Conditional codes can cut down on globals and a few of the existing variables but not by enough, I don't think, before backlog kicks in. Part of it due to the fact that 32 bit variables take up a whole lot of space. Also, certain variables that are right next to each other (like xcoordinates and ycoordinates) take 4 lines of 64 bit code. This is just a suggestion and I don't know how easy it would be to implement (since I haven't seen any of your code for gcars) but I have a suggestion to help get more scripts with less bandwidth: Require that everybody have the same scripts (meaning player 1's "script 1" is identical to player 2's "script 1", and their "script 2"s are equal and etc). So everything is in the same order as well. Separate the scripts into 8 bit, 16 bit and 32 bit codes (depending on what the code affects in GCN Codetype helper); this can be done by adding another option in the "script editor" in Gcars or something. When a player sends their own data (let's say player 2 sends his data), his whole file he sends over the net starts with the player number (so 2 in this case), then all of the 8 bit data, then all the 16 bit data, then the 32 bit data (just the data, not the whole code). You shouldn't have to make separater codes or ending codes to mark where the 16 bit codes start or 32 bit codes start or when the file actually ends because the other 1 to 3 players have identical "script 2"s. So, all they need to know to start with is that the file they're recieving is from player 2 and then they start at the beginning of the file, removing an 8-bit data and putting it in the first script in "script 2", until all the 8-bit scripts in "script 2" are used up, at which point 16-bits are removed from the beginning of the file and so on until there are no more scripts to fill in data for in "script 2". Then, all those filled in scripts are run through the AR simulator. However, I don't know how gcars makes/distributes/stores the scripts. If storing all 4 scripts is too much data to store, I guess it might not work (although GCNrd is a huge file and it seems to work, although I may be oversimplifiying things). However, this is a huge bandwidth saver, I think. Addresses don't need to be sent since everyone has the addresses allready. Offsets don't need to be sent. This means for all 8-bit offsetted codes, instead of sending 64 bits over the line, only 8 bits are, an 800% jump in efficiency. 16 bits are similarly effected with a 400% jump in efficiency. Non-offsetted 32 bits are effected by a 200% jump. However, offsetted 32 bit variables are hugely beneffitted; instead of sending 128 bits of data for 2 lines of scripts, they only send 32 bits, a 400% jump in efficiency. Overall, there should be about a 400% jump in effiency (assuming 32 and 8 bit variables pretty much cancel each other out in the efficiency equation), which means you can make roughly 4 times as many scripts without worrying about backlog. This could make conditional codes a little tricky though. From what I've seen though, there are two uses for conditional codes: one, to reduce the bandwidth needed. This is for such things as "level syncing", where specific values need to be set to sync up the levels (like bullet bill in Peach's castle), or for such things as menu syncing, something that eats up bandwidth when not in the menu. However, I've recently found another use for conditional values: preventing freezes and crashes. One of the codes I found will sync up ground/air state. However, the "battle" doesn't always start right at the same time (the gamecubes' announcer says "GO" at different times). The ground/air state variables also (apparently) keep track of the state of characters when they start up. So if the game is already supposed to be started on one screen but the other person has barely started and the games are supposed to sync up, the person who's already started freezes. The way I see of fixing this is with a conditional code that says, "if your game hasn't started yet, don't send this piece of data". However, there could be data later on that is found that could deal with the issue, "If I'm not in the same place the other guy is, don't take his data, which is similar but the problem is in the other direction. Since there are conditional codes for next line, next two lines, and until z2 code, here's the first thing that comes to my mind: When the gamecube is making data to send to others, the script could contain a preceding code before the conditional code that says "Does it matter what my condition is or does it matter what their condition is?" and then it adds a bit to the data that is being sent, 0 for the former and 1 for the latter. This preceeding code can be a variety of things, one way could be to use the two "Subtype 3" codes, under codetype 0 in GCN Codetype Helper: (size 0) indicating the sender matters and (size 1) indicating the reciever matters, which should be okay since they are unused codes anyway. After that, it then evaluates the condition. It then adds another bit to the data, 0 for failing and 1 for passing; this'll be read by the reciever later. If passing, it then adds all the data from the codes that the conditional code is "conditioning". If failing, none of that data is sent. So, after all of that, when the reciever gets the data, it says it's from player 2, so it goes over to "script 2". If the first script is an 8-bit script, it then reads 8 bits from the beginning of the file (not including the data that said it was from player 2) and puts it in. Etc. Then it gets to the "Does it matter if it's a sender or receiver code" preceeding the conditional. Then it goes into conditional mode. It reads the first bit afterwards to see if the sender matters of reciever matters. If sender matters, it reads the next bit to see if the conditional passed or didn't. If it passed, it runs the next lines in the script as normal (all the way up to the z2 code if applicable). If failed, it ignores the next line or next two lines or up to the z2 code depending on what the conditional was. This matches up with what the sender did. In the other case that the reciever matters, it should still read the next bit to see if it passed or failed on the sender's game. If failed, it ignores the next line, next two lines, or lines until the z2 code. If passed, the reciever goes and checks its OWN status. If he passed, the data is filled in and the codes are read. If he failed, the data is read but the codes are ignored. The reading part is important so the reciever go through the recieved data until it gets to the part right after the conditional, at which point normal work is resumed. Again, this is only a suggestion and I don't know how you've programmed gcars and I only know enough of how it works as far as seen it in different situations. If you don't want to do it, that's fine, since it is your program. Also, it's up to you on how much work you want to put into this. The conditional code implementation I put up could get a bit complicated (I'm already imagining). But if you decide to implement bandwidth saving algorithms, I'd really like that :D. Anyway, good luck on making v1.0! I'm looking forward to it :)! PS: Do you still have those velocity scripts? :mrgreen:
Hey Fuzziqer. I'd like to start off by saying you've made a mighty fine program here. And that this is only a suggestion and you are under no obligation to take it. However, as I've been doing more and more hacking into SSBM, I've noticed a problem: there are a lot of variables that need to be passed in order to ensure that the game is really in sync. Now, conditional codes (like the ones you're working on) will surely do the trick to certain extent but there are still a LOT of scripts even only during battle that need to be passed. (I'm on the cusp of reaching that limit and that's not even talking about the potential for number of scripts that I haven't even gotten close to finding). I've stripped it down to the very basics for gcars .95 play (of the existing scripts I have found) to make the game as smooth as possible: ° Character type, flags, costume (1 byte each) ° Number of kills/Lives/Number of coins (depending on your mode, pick 1 only!) ° Displayed Damage (somewhat optional yet highly recommended) ° Internal Damage high ° Internal Damage low ° Shield Size ° X coord high ° X coord Low ° Y coord high ° Y coord low ° X prev coord high ° X prev coord low ° Y prev coord high ° Y prev coord low ° character selection data ° Facing Direction ° Ground Variable High ° Ground Variable Low ° Falling State Variable High ° Falling State Variable Low And that doesn't even include Animation (high and low), frame data (high and low), the global variables, velocity variables, or any other variables that may be deemed necessary in the future. Conditional codes can cut down on globals and a few of the existing variables but not by enough, I don't think, before backlog kicks in. Part of it due to the fact that 32 bit variables take up a whole lot of space. Also, certain variables that are right next to each other (like xcoordinates and ycoordinates) take 4 lines of 64 bit code. This is just a suggestion and I don't know how easy it would be to implement (since I haven't seen any of your code for gcars) but I have a suggestion to help get more scripts with less bandwidth: Require that everybody have the same scripts (meaning player 1's "script 1" is identical to player 2's "script 1", and their "script 2"s are equal and etc). So everything is in the same order as well. Separate the scripts into 8 bit, 16 bit and 32 bit codes (depending on what the code affects in GCN Codetype helper); this can be done by adding another option in the "script editor" in Gcars or something. When a player sends their own data (let's say player 2 sends his data), his whole file he sends over the net starts with the player number (so 2 in this case), then all of the 8 bit data, then all the 16 bit data, then the 32 bit data (just the data, not the whole code). You shouldn't have to make separater codes or ending codes to mark where the 16 bit codes start or 32 bit codes start or when the file actually ends because the other 1 to 3 players have identical "script 2"s. So, all they need to know to start with is that the file they're recieving is from player 2 and then they start at the beginning of the file, removing an 8-bit data and putting it in the first script in "script 2", until all the 8-bit scripts in "script 2" are used up, at which point 16-bits are removed from the beginning of the file and so on until there are no more scripts to fill in data for in "script 2". Then, all those filled in scripts are run through the AR simulator. However, I don't know how gcars makes/distributes/stores the scripts. If storing all 4 scripts is too much data to store, I guess it might not work (although GCNrd is a huge file and it seems to work, although I may be oversimplifiying things). However, this is a huge bandwidth saver, I think. Addresses don't need to be sent since everyone has the addresses allready. Offsets don't need to be sent. This means for all 8-bit offsetted codes, instead of sending 64 bits over the line, only 8 bits are, an 800% jump in efficiency. 16 bits are similarly effected with a 400% jump in efficiency. Non-offsetted 32 bits are effected by a 200% jump. However, offsetted 32 bit variables are hugely beneffitted; instead of sending 128 bits of data for 2 lines of scripts, they only send 32 bits, a 400% jump in efficiency. Overall, there should be about a 400% jump in effiency (assuming 32 and 8 bit variables pretty much cancel each other out in the efficiency equation), which means you can make roughly 4 times as many scripts without worrying about backlog. This could make conditional codes a little tricky though. From what I've seen though, there are two uses for conditional codes: one, to reduce the bandwidth needed. This is for such things as "level syncing", where specific values need to be set to sync up the levels (like bullet bill in Peach's castle), or for such things as menu syncing, something that eats up bandwidth when not in the menu. However, I've recently found another use for conditional values: preventing freezes and crashes. One of the codes I found will sync up ground/air state. However, the "battle" doesn't always start right at the same time (the gamecubes' announcer says "GO" at different times). The ground/air state variables also (apparently) keep track of the state of characters when they start up. So if the game is already supposed to be started on one screen but the other person has barely started and the games are supposed to sync up, the person who's already started freezes. The way I see of fixing this is with a conditional code that says, "if your game hasn't started yet, don't send this piece of data". However, there could be data later on that is found that could deal with the issue, "If I'm not in the same place the other guy is, don't take his data, which is similar but the problem is in the other direction. Since there are conditional codes for next line, next two lines, and until z2 code, here's the first thing that comes to my mind: When the gamecube is making data to send to others, the script could contain a preceding code before the conditional code that says "Does it matter what my condition is or does it matter what their condition is?" and then it adds a bit to the data that is being sent, 0 for the former and 1 for the latter. This preceeding code can be a variety of things, one way could be to use the two "Subtype 3" codes, under codetype 0 in GCN Codetype Helper: (size 0) indicating the sender matters and (size 1) indicating the reciever matters, which should be okay since they are unused codes anyway. After that, it then evaluates the condition. It then adds another bit to the data, 0 for failing and 1 for passing; this'll be read by the reciever later. If passing, it then adds all the data from the codes that the conditional code is "conditioning". If failing, none of that data is sent. So, after all of that, when the reciever gets the data, it says it's from player 2, so it goes over to "script 2". If the first script is an 8-bit script, it then reads 8 bits from the beginning of the file (not including the data that said it was from player 2) and puts it in. Etc. Then it gets to the "Does it matter if it's a sender or receiver code" preceeding the conditional. Then it goes into conditional mode. It reads the first bit afterwards to see if the sender matters of reciever matters. If sender matters, it reads the next bit to see if the conditional passed or didn't. If it passed, it runs the next lines in the script as normal (all the way up to the z2 code if applicable). If failed, it ignores the next line or next two lines or up to the z2 code depending on what the conditional was. This matches up with what the sender did. In the other case that the reciever matters, it should still read the next bit to see if it passed or failed on the sender's game. If failed, it ignores the next line, next two lines, or lines until the z2 code. If passed, the reciever goes and checks its OWN status. If he passed, the data is filled in and the codes are read. If he failed, the data is read but the codes are ignored. The reading part is important so the reciever go through the recieved data until it gets to the part right after the conditional, at which point normal work is resumed. Again, this is only a suggestion and I don't know how you've programmed gcars and I only know enough of how it works as far as seen it in different situations. If you don't want to do it, that's fine, since it is your program. Also, it's up to you on how much work you want to put into this. The conditional code implementation I put up could get a bit complicated (I'm already imagining). But if you decide to implement bandwidth saving algorithms, I'd really like that :D. Anyway, good luck on making v1.0! I'm looking forward to it :)! PS: Do you still have those velocity scripts? :mrgreen: