Online code reform.

Online code reform.
I haven't updated the CS part of GCARS-CS in quite a while, but I think it's time. Here's my checklist for the next release: 1. Server mode 2. Server app 3. Synchronization mode (frames don't advance until all data is synchronized, like MK:DD) 4. Dependent code lists (players all use the same code list, eliminating cheating) 5. SD support in memory card manager 6. Unlocking cards in memory card manager 7. Disc ripper (already finished :P) If anyone has idea they'd like to add, post here. You don't even need to register.

Ah, those are good ideas. I don't know how I'd implement them in the GUI, but I'll figure it out somehow. Unlocking will support official Nintendo cards and card swapping; and there are a few minor fixes to the memcard libraries that I could do that should make them more compatible.

Get A Xlink Kai mode.....so we can setup games easily :) no hassle with ips :) I think thats what the server app and server mode will be for.

Please make sure it works with max drive pro. Thanks :)

Well how about a auto-boot from memcard(like anaconda). text chat voice chat... User controlled computer operated slots(6 player on SSBM) Ip ban,hardware ban for cheaters and script kiddies (better idea ban the combonation of OS+IP+ISP and have GCARS anticheat software scan for ALL these or deny access.)have random variable check from the server that check for stat boosts and freeze.(ie if you go faster than you should go you get booted from the server.)encrypt the connection to the server with SSL. As you can see I hate what hackers do to good games. -Optimizing- lower the keystrokes(If you played MAME32k DO IT! its fun especially with Metal Slug 4 and MVC) to help latentcy. can you split the connection to the server into serveral smaller streams and have them rejoined PC side(kind of like bittorrents). easy set up.(does this even work?) Ctr-cs(will netcat work as well?)--->GCARS--->memcard2--->AR to boot .dol Ctr-cs-->send anaconda(auto-boots)-->to memcard2---> send GCARS-->boot with anaconda Ctr-cs--->send GCoS--->boot with AR Text chat and voice chat can already be done through IM clients for PC. Text chat in GCARS-CS itself would probably not be possible, because where would the keyboard be displayed? Also, voice chat would not be possible, for multiple reasons, including the fact that the microphone for the GameCube has no homebrew libraries available for it, and the fact that compressing the voice data would slow down the game a lot. I think a better solution is to get it working with Kai, which already has support for text and voice chat built-in. User-controlled computer slots would be great; I asked Fuzziqer about this back on Team-GX, and he said that it was in tentative plans for the GCARS-CS Server. And if you think 6-player SSBM would be good . . . think about 30-player F-Zero GX with everyone having their own screen . . . that'd be so damn sweet, even if it used up a ton of bandwidth. And of course, a Mario Kart script would be nice, as would some hint of why my Super Monkey Ball 2 script doesn't work. Kind of sad that I started that in June, and I still haven't had any time since then to do some serious debugging. :oops:

Although I don't have SSBM, I think a nice addition to the SSBM script would be velocity codes. That way, lag is less annoying (no more rubber-banding).

I think it would be nice for the scripts for all the games to be built into GCARS, for all of the games, or just for SSBM. Because I still don't quite understand why you NEED them to even play online. They're just codes right? I don't understand why we need to enter them for online playing to work? Without scripts, the games will desync due to randomness and lag. I think the scripts are built into GCARS-CS. The scripts that are built-in aren't updated as often as the ones posted online, though. That is something that Fuzziqer should probably be more careful with. :)

Although I don't have SSBM, I think a nice addition to the SSBM script would be velocity codes. That way, lag is less annoying (no more rubber-banding). Hey bio, that was originally my idea for the velocity codes. :D :-P Wow, I thought this project was bascially dead after the team-gx server went down. Apparently its still going thanks to good ole' Fuzz though. Congratulations on buying the domain name Fuzz and improving gcars, we really do need that server mode. -Ice

Although I don't have SSBM, I think a nice addition to the SSBM script would be velocity codes. That way, lag is less annoying (no more rubber-banding). Hey bio, that was originally my idea for the velocity codes. :D :-P Wow, I thought this project was bascially dead after the team-gx server went down. Apparently its still going thanks to good ole' Fuzz though. Congratulations on buying the domain name Fuzz and improving gcars, we really do need that server mode. -Ice Haha, yes, all credit for wanting velocity codes goes to you. :) And yes, thank you Fuzz for continuing to work on GCARS-CS; I usually lose interest in my programming projects after a couple weeks/months. :lol:

I usually do too.... but this project nd my PSO server haven't bored me yet :P The problem is that I never have time to work on them anymore.....

how about script updates. I would second that . . . specifically, some help with my SMB2 script would be great. As would an MK:DD script, and velocity codes for SSBM.

I'm not sure if this would be possible, but it would definitely help for the ssbm script. Would there be a way to have Player 1's data (mainly the character position and state (ie. tumbling/standing/attacking/stunned)) override Player 2's data as soon as they became desynched? While playing, it seems the largest problem comes from when player 2 sees something hit player 1, but in reality player 1 wasn't hit, but was just shielding. This also happens when player 2 tries to powershield, they see themselves shield it, but notice their % went up and they kind of slide around. Both of these things usually end up in player 2 trying to do something and somehow desynching the positions pretty far. The biggest thing is that you'd need to make the characters warp to player 1's states, so that there's no chance of you grabbing the edge when youre really falling below the level (very disheartening when you realize it just before you die). And on levels like Hyrule or ones with platforms, it can be harder to synch up, since there are often objects in the way. I think this would also take care of the problem where you see the character just falling into the round, even though on Player 1's screen that person has landed. Sorry about my poor coherence in this post, tell me if I shoud re type it with clearer ideas. Btw, The things I mentioned above all came up as issues with DJ Veeman's GCARS-CS-CONFIG.sav that was on Xlink. I think that could be a permanent solution if you could find a way to implement the stuff above. Anyway, hope to hear back from you, and I'm always up for -*test*-('")s if you need someone. :D Also wanted to address something about the velocity codes. With DJ Veeman's fix, there really is no more rubber banding (not even for player 2 really), the only thing is that when it is trying to synch, often it isn't fast enough. So now that there's no trouble of rubber banding, allowing the characters to warp immediately (and hopefully be able to go trhough the stage to get where they are supposed to be) is the best fix for it at the moment.

I'm not sure if this would be possible, but it would definitely help for the ssbm script. Would there be a way to have Player 1's data (mainly the character position and state (ie. tumbling/standing/attacking/stunned)) override Player 2's data as soon as they became desynched? While playing, it seems the largest problem comes from when player 2 sees something hit player 1, but in reality player 1 wasn't hit, but was just shielding. This also happens when player 2 tries to powershield, they see themselves shield it, but notice their % went up and they kind of slide around. Both of these things usually end up in player 2 trying to do something and somehow desynching the positions pretty far. The biggest thing is that you'd need to make the characters warp to player 1's states, so that there's no chance of you grabbing the edge when youre really falling below the level (very disheartening when you realize it just before you die). And on levels like Hyrule or ones with platforms, it can be harder to synch up, since there are often objects in the way. I think this would also take care of the problem where you see the character just falling into the round, even though on Player 1's screen that person has landed. Sorry about my poor coherence in this post, tell me if I shoud re type it with clearer ideas. Btw, The things I mentioned above all came up as issues with DJ Veeman's GCARS-CS-CONFIG.sav that was on Xlink. I think that could be a permanent solution if you could find a way to implement the stuff above. Anyway, hope to hear back from you, and I'm always up for -*test*-('")s if you need someone. :D Also wanted to address something about the velocity codes. With DJ Veeman's fix, there really is no more rubber banding (not even for player 2 really), the only thing is that when it is trying to synch, often it isn't fast enough. So now that there's no trouble of rubber banding, allowing the characters to warp immediately (and hopefully be able to go trhough the stage to get where they are supposed to be) is the best fix for it at the moment. Okay, just thought I should say something. DJ Veeman's modifications (which, by the way, are really mine; I told him to try that over IM), while I am told that they work well for some people, have the problem that all players other than P1 (even locally) will lag. This causes all the problems that you mention. I personally think that it would be worth adding velocity codes, just for the purpose of finding out whether they would make the original script (each player has a script) work as well or better than DJ's and my modification. I'm not saying that velocity codes are guaranteed to make the original scripts work better, but I think it's worth a try.

From what I can tell, the only lag it gives is Ping. So like he said, only geographical distance and internet service can lessen it. And yes, I realize that these problems are limited to player 2 (i think i said that somewhere). The person I was playing with probably had a ping of around 100 ms, so that is .1 seconds, or 6 frames or so. From what I could tell, this was the only source of desynching, and then the fact that since the two characters would then be in different animations, player 2 would either see Player 1 move when he wasn't, or move on their screen when they are in stun or tumble animation on Player 1's. However, I don't think I exactly know what you mean by velocity codes. From what I gathered in the first mention of them, it would simply limit the character to moving their maximum speed, either horizontal or vertical. If that's what it is, then I might have a different problem that I'd bring up.

From what I can tell, the only lag it gives is Ping. So like he said, only geographical distance and internet service can lessen it. And yes, I realize that these problems are limited to player 2 (i think i said that somewhere). The person I was playing with probably had a ping of around 100 ms, so that is .1 seconds, or 6 frames or so. From what I could tell, this was the only source of desynching, and then the fact that since the two characters would then be in different animations, player 2 would either see Player 1 move when he wasn't, or move on their screen when they are in stun or tumble animation on Player 1's. However, I don't think I exactly know what you mean by velocity codes. From what I gathered in the first mention of them, it would simply limit the character to moving their maximum speed, either horizontal or vertical. If that's what it is, then I might have a different problem that I'd bring up. Adding velocity codes to the script makes GCARS-CS sync the players' XYZ velocities in addition to their XYZ coordinates. This means that, instead of rubber-banding (which occurs because the game thinks the character is moving quickly, when they should be standing still), lag would result in an attack just not working. At least, that's a simple explanation.

View Full Version: Online code reform.