For full N64 lybrary compatibility without desynchronization use AQZ input Netplay plugin for a suitable emulator.

Tutorial

Update: Counter Factor has been set to 1 for Super Smash Bros (U). The smash community has made this the new standard.

To set it yourself Emulate the rom then go to Options > Settings > Rom Settings > set Counter Factor to 1

To Save game progress online and play more games insync over netplay download: Mupen64++

Jabo Direct3D8 1.6.1 default Graphics plugin, use Glide64 finale version for more accuracy(at the expense of fps if low end PC). Else if you have an actual computer (not a toaster) you can use the new GLideN64 plugin

For WINE compatibility with Mac OS and certain linux distros try using "Aristotle's Mudlord and Rice Video" Plugins and Azimer's Audio Plugins also Mupen64++(Latest Mupen64k) may be more ideal for WINE as it's already been documented and tested.

Questions / Problems

Short understandable version

+Why does my game speed drop online?

Because of your Network connection or Computer preformance. When you have multiple things using the same network it causes lag. These things can include other hosts connecting to your network such as other computers or phones, or programs running that use network connections such as Webbrowsers, Steam, Skype, Updates, Anti-virus Real Time Protection services, and whatever else. However there could be a number of other reasons you, the best option to solve these issues besides manually turning them off is to run a program like Game Booster which can be found on google. The newer versions require login however the older versions do not. For most people game booster can help solve some of the problems but if you are Wireless there isn't much that can be done. Wireless connections will drop even more packets than are already dropped through Kaillera (UDP). You may beable to play at regular speed sometimes however it will be varied, the closer to your router/modem you are the better your connection will be.
If the problem is your actual computer preformance then lowering resolution with Jabo Direct3D plugins will be better. If you use Glide64 or any other plugin you may lag, as for Audio it is recommended you use HLE Audio (Azimer's Audio v0.30). Going in task manager and setting the priority of PJ64k to above normal may also result in preformance increase.
Also if nothing seems to help, going to another server might or P2Ping. Else you can try Mupen64++ with Rice plugin (which is faster but less accurate than Jabos) since it uses less network usage.

+ Can't Start Netplay / Kaillera

You may not have the requirements for Ownaclient (or even Open Kaillera P2P client), if this is the case run windows update and install all updates. Else you can try http://kaillera.com/download.php and use the original Kaillera 0.9 client. Just rename it to Netplay.dll and replace the one in the config folder of pj64k.

Lengthy technical version

+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.

The Latest Emulinker X (2.0.2 requires opening all .sh files in text editor to remove the NewLine after the java code to prevent issues with linux)Emulinker X 2.0.x

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."

1:3
[HOSTING]
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.

1:7
[FRAMEDELAY LAG]
- 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)

1:8
[SAVE FILES]
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.

1:9
[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.

2:1
[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.