If you want to contribute to the culture and create your own dedicated Kaillera Server see here
Known games to sync over Kaillera(Emulinker X)
|Super Smash Bros 64(No Random Stage)
||Super Smash Bros 64(Gameshark.dll implemented to unlock all)
|Mario Kart 64(3-4Player Speed Glitch)
||Mario Kart 64
|Star Fox 64 / Lylat Wars
||Star Fox 64 / Lylat Wars
|SM64 Multiplayer Rom Hack by Skelux
||SM64 Multiplayer Rom Hack by Skelux
||Diddy Kong Racing
||Snowboard Kids 2
+Why is my game so laggy when I play? What is lag? What is desync? What does "Ping" mean?
When you play games over the internet, you can be playing against someone that is across the world . When speed is concerned, you start to run into concept of the speed of light.
Say I'm in New York, and I want to play a server in Tokyo. That's about 6760 miles. The speed of light is approximately 186,000 miles per second. In ideal conditions, your signal has to go from your computer to the server, and back. Assume that this electronic communication happens at the speed of light. (Which it does not. There are other problems due to overhead, A/D conversions, etc. Not to mention that electricity travels a bit slower than the speed of light.)
So, we have to go 6760 miles there, and 6760 miles back. That's 13520 miles. At the speed of light, it would take about 72.688 ms ([13520mi / 186000 mi/sec] * 1000ms/sec). So, at best you can have a 72 ms ping. (Not taking into account time lost by routing hops, A/D conversion, network overhead, latency, etc.)
You really can't defeat the speed of light.
Lag: AKA network latency and ping time. If you say you are "lagging", network-savvy people are going to think that when you press a key, your actions are delayed. Lag is NOT shown when you are playing but the game appears to have locked and none of the keys work. That is called...
Packet Loss: Over the TCP/IP and UDP protocols and the others, data is sent out in little packets of data. I believe it is approximately a few hundred bytes, (someone who knows, please let me know). The receiving computer reassembles these packets, according to stamps on them, into what it was supposed to be. In UDP, which Kaillera uses, these can be received out of order and there's a timestamp on them so that they can expire. Ex.: If you're playing a fighter and you press a punch, you don't want it to be received after the kick you pressed first; fighting would be downright hilarious. You may never get a UDP packet since it is just sent once and that's it. Once it's expired, if your computer ever DOES get it, the packet is checked against the computer's clock and just ignores it.
In TCP/IP, packet loss does not happen as often, and the participating computers' connection seems to last longer, usually until both computers feel the connection has just been lost. (This is why IRC, laggy as all hell, still works). TCP/IP replies with what we call an "ACK" (acknowledgement) when a packet has been received. Until that, the other computer keeps sending the little packet out until it gets the "ACK". I don't know the frequency of resending. (Again, someone who knows, please send the information in. I would imagine it's more than 300 or so milliseconds.) The problem is, this takes up bandwidth on a connection, thus for things like Kaillera, UDP is much more preferred so lag can be reduced.
Frame loss: You will see choppiness in the game if there is some lag happening. The resulting effect from packet loss in UDP is that you may have some packets that are not received. This would not only cause lag, since the timing would be held back, but you may also miss a transmitted move or button press. One of the benefits of UDP is that all of the bandwidth of both computers is used to full and not wasted resending packets. The problem is if a packet is not received the computer that was supposed to get it has nothing to do. With the way Kaillera is set up, (which it has to be, or desyncs would occur whenever a packet is lost) the program is set to stick until it receives a packet so the other player(s) can move. Work some brain cells for a second and you can see this was the only sensible thing to do. This prevents Kaillera from desyncing. Those of you who frequently get perfect games feel rested: you are getting relatively low packet loss: less than 5%. 0 is quite uncommon just because there's so much traffic everywhere. High speed connections usually have much lower rates of packet loss than dialup. This entire process works so fast however that even though you think you're playing a smooth game, packets are still getting dropped and despite the fact that this is happening, you can't tell Kaillera has stopped working for 2 milliseconds.
In addition, Kaillera implements modern technology which make UDP packet transmission much more reliable. But even with that, if your connection is bad, there's no magical way around it.
If your games keep getting choppy, check out what's going on with your internet connection. For instance, if you're in the middle of any file transfer while playing with Kaillera or are using other bandwith-eating applications.
+DS aka Desynction
Desync is a thorn in the side of playing emulators over a network. If you want to know why this also happens in PC games, keep reading this paragraph, otherwise skip down a bit. This also comes up in real time strategy games. For example Starcraft, those of you that play(ed) it, you know each player can have around 100 or more units, not to mention buildings, at once. Maybe each on screen "entity" takes about 200 bytes. That's 200 entities for each player, 4 kilobytes for those entities. If there are 8 players, that's 32k. Your 56k modem can not send 32 kilobytes per second reliably. In the game Black and White, you can have unlimited amounts of villagers. The more villagers, the more houses, food, wood, and prayer power you get. That's a ton of data that needs to be sent to EVERY player. Peer-to-Peer games do not usually send every single piece of data to each computer. Obviously, that would be too much data to send consistently, and quite a waste of time. So instead, they do something like what Kaillera does, send tiny updates.
In essence, Kaillera just sends keystrokes. The server you connect to is the host. NOT whoever makes the room for the game. Every key you press while playing is sent to the server you connect to and it then routes it back to you and to everyone else. Again, it does not matter who hosts a game, the playing experience on a single server will be the pretty much the same unless one player reconnects to their ISP.
When you press a key while in Kaillera, as stated above, it is sent to the server and sent to everyone else:
- Player 1
Server - Player 2
- Player 3
If player 1 presses punch, it goes to the server, and then it follows the lines back to each player. If one player is experiencing heavy packet loss, all players stick because as mentioned in the above topic:
Kaillera waits for keystrokes. As you can imagine this is very unreliable. It's like telling a person to remember a sentence for you and you can tell them to go back and forward, delete words and add words. If one of you screws up going forward, back, add or remove and then you both write the sentence out, you get modified sentences. The result is one of you could still have the correct new sentence but since the other person screwed up, you are "desynced." This is exactly what happens with a desync. One of the players' Kaillera will "think" about something differently. It could also be caused by packet corruption that was somehow received, (though the likelihood of that is low, it does happen.) Since nothing but keys are sent, there is no way currently feasible to synchronize. One possibility that is being explored is to copy byte for byte the game's "state" from one computer to all the others. Technically you could "teleport," if you were playing a game like Dungeons and Dragons, to each other and you would be synched but usually it's not that easy. You could have different scores and stuff. This tiny update stuff is the blind leading the blind. Each client blindly assumes the other clients have exactly what it has. Usually this works. When there's a desync, it doesn't.
With the keystroke method the best way to check for a desync is compare scores. Tell each player your score and have them tell you what they see your score as. If it's different, you're desynced. You can also check to see if players are hitting air (note: they could just be drunk) or dancing ballroom style.
Packet corruption would seem the most likely culprit for desync. This is when somehow, over the network, the packet gets a bit or more changed in it. TCP/IP has a quick check I think and discards corrupted packets and doesn't send the ACK. UDP doesn't care, and just drops it. Corrupted packets are supposed to be dropped but it can be possible to receive a corrupted packet and try to use it. I don't think this happens often, however, it has been known that on early firmware versions, the LinkSys routers can corrupt packets. Usually corruption is faulty hardware. I don't know if this is the case, but if these corrupted packets are sent off as being correct, received and used, this causes HORRIBLY unwanted results.
+Ping / FrameDelay
Ping is How Fast you're internet connection connected to the servers host. This is what determines the frame delay of emulating any game online. N64 games typically run at 30 or 25 fps(frames per second), so it's not as bad but a single frame delay to an experienced player will be noticable.
*This is calculated connetion's Ping/FrameDelay for Emulinker Servers (Kaillera)
Lan Connection Ping (Max 18 minute synchronization time)
0 to 16 ms 1 (1 frame delay)
17 to 33 ms 2 (2 frame delay)
34 to 49 ms 3 (3 frame delay)
50 to 66 ms 4 (4 frame delay)
Excellent Connection Ping (Max 32 minute synchronization time)
0 to 33 ms 1 (3 frame delay)
34 to 66 ms 2 (5 frame delay)
67 to 99 ms 3 (7 frame delay)
100 to 133 ms 4 (9 frame delay)
Good Connection Ping (Max 50 minute synchronization time)
0 to 49 ms 1 (5 frame delay)
50 to 99 ms 2 (8 frame delay)
100 to 150 ms 3 (11 frame delay)
151 to 199 ms 4 (14 frame delay)
+Creating a Kaillera Server
Using AQZ input
AQZ is a netplay client designed for PJ64 1.7 and ultilizes the Input of N64 emulation, in PJ64 2.x versions it must be in the 1.6 Plugins folder. It works like the Kaillera P2P
client but allows multiple players to connect to the host and does not desync. AQZ requires all players to have the SAME save data, this will prevent any possibility of DS and of course using the SAME emulator. For all practical reasons a clean version of the PJ64 1.7 beta that AQZ designed the netplay client for is distributed. However it is recommended you use 2.x for games like Donkey Kong 64 and Banjo.
"I forgot to mention this, but the netplay plugin does not support raw data or the use of any packs (memory, rumble, etc.) This was to prevent desyncs."
official download/tutorial page
Older AQZ Version for Troubleshooting
Note: PJ64 NRAGE (v2.2) will not work with AQZ.
PJ64 2.x in general may have issues with AQZ.
1:1 Setting up Emulator for AQZ
1:2 Console Commands
1:3 Setting up a Server Host for AQZ
1:4 Starting AQZ
1:5 Hosting a on AQZ
1:6 Connecting to a Server/Host
1:7 Framedelay / Lag
1:8 Game Memory Save Files
1:9 Using Gameshark codes (cheats)
2:1 How Golf Mode Works
1. launch project 64 1.7
Optional: click File, Choose Rom Directory... and direct to your folder full of N64 roms
2. click Options, Settings
3. UNcheck "Pause emulation when window is not active"
4. click on the Plugin tab
5. change Input (controller) plugin to AQZ Netplay
6. Click [OK]
7. click Options, Configure controller plugin
8. Select your input plugin
9. Click [Configure] and set up your controls.
10. Start Emulation (AQZ Window should pop up)
* /name Nick -- sets your username
* /server Port -- hosts a server for others to connect to
* /connect host:port -- connects to a server
* /start -- starts the game
* /lag # -- sets the frame delay (response delay) for the game
* /golf -- turns golf mode on or off
To host a game, you must have a port opened for listening. If you cant open a port for some reason, then Hamachi is a good backup solution.
Q: What is hamachi?
A: Hamachi is intended as a zero-configuration virtual private network (VPN) application that is capable of establishing direct links between computers that are behind NAT firewalls without requiring reconfiguration (when the users PC can be accessed directly without relays from the Internet/WAN side); in other words, it establishes a connection over the Internet that emulates the connection that would exist if the computers were connected over a local area network.
Note: Hamachi is limited, once your account limit has been reached you will no longer beable to connect to hamachi. You have to completely remove hamachi from your computer and reinstall it (older version) and create a new account once old account limit is reached.
*Hamachi will require all players to have installed hamachi. You simply create a server and give the people you want to connect the Server Name and Password so they will be on your hamachi server. then you simply use the Hamachi IP with any port.
In some cases, you might need to change the Traffic setting to Block Untrusted to Allow All to accept incoming connections between peers. Like this:
1. right-click on your friend in Hamachi window, click the Details tab..
2. Next to traffic, change from Block untrusted to Allow All.
- Load a rom like you would normally, AQZ window should pop up. (If it doesnt troubleshoot plugins)
- To set your name, type /name (yournamehere)
[WHEN HOSTING A SERVER]
- To host a server, type /server (your listen port # here)
(Pretend your port is 7777, you would type, /server 7777)
[WHEN CONNECTING TO A SERVER]
- To connect, type /connect (hosts IP address here) (hosts listen port # here)
(pretend the hosts IP address is xx.xx.xx.xx and port is 7777, you would type, /connect xx.xx.xx.xx 7777)
- To set the Lag or more commonly known as Frame Delay you type /lag # (You want 5 or less, aiming for 1 at best however if FPS (frames per second) drop then you might need to raise it to 2 or higher.)
(The further away you are from the host, the higher the Lag needs to be raised inorder to maintain full FPS)
In order to keep emulation in sync you both need to be on the exact same Save File.
A save file is created everytime you emulate a rom, you can delete save data in game or you can manually delete the Save File in the Save Folder.
[USING GAMESHARK CODES]
In order to use gameshark codes ALL PLAYERS must ENABLE the SAME gameshark codes.
With Project64 2.x you can Right Click your rom then Edit Cheats and preset your codes before starting AQZ.
[USING GOLF MODE]
To use golf mode, wait until it is your turn to play. Before you play, press the Z button.
What this will do is set your own lag(Frame delay) to 0, but set everyone elses lag to what the pre-set lag was previously set to.
Now you are free to do your turn without any lag. When it is someone elses turn, they press Z and it switches their lag to 0.