I pledge $100 to whoever can fix the P64k disconnect bugs

[EpicDonk]

Not sure if this is a client fix or server fix, but my god this sucks -- there must be something we can do.

To claim the prize, fix would need to address:

• Random ds's that require drop/restart of game constantly
• Time limit ds on LAN/EXC that freezes entire client

*** Fix and client/server code must be released with open-source license on Github or similar service ***

time issue is easy
the messages contain a 16-bit int for the message number in order to make sure the inputs are correct
60 frames a second (LAN connection) => 3600 messages a minute.
16 bit ints have a max value of 65535
65535 / 3600 = 18.2 minutes till lagout

change the protocol to use a 24 or 32 bit int

- Herbert Von Karajan

If you are interesting in supporting the cause please reply with name, amount, and how you will send (i.e. paypal). I will update this thread with pledges names and amounts. Maybe if this gets big enough somebody will fix it.

Thank you.


Total Pledged: $100.00




Name Date Pledged Type Amount

EpicDonk 10/8/2014 Paypal $100.00

 

[Madao]

• Random ds's that require drop/restart of game constantly
• Time limit ds on LAN/EXC that freezes entire client

• The random DS is usually the emulator's fault. Using an emulator not made in 2001 would help ;/ . Dunno about the time limit issue as I don't play on server (p2p ftw). People prioritize gameshark codes over desynching, so that's the problem.

 

[Herbert Von Karajan]

time issue is easy
the messages contain a 16-bit int for the message number in order to make sure the inputs are correct
60 frames a second (LAN connection) => 3600 messages a minute.
16 bit ints have a max value of 65535
65535 / 3600 = 18.2 minutes till lagout

change the protocol to use a 24 or 32 bit int
EZ

 

[MrMarbles]

if it's so easy i feel like it would have been fixed already

 

[Kahnu]

lol is this seriously your first ****ing post on smashboards
and you're pledging one hundred ****ing dollars for something
NOBODY will ever fix



-walks out room-

 

[bloodpeach]

fixing random ds's would require fixing all bugs in project 64. also all bugs in the kaillera client and server.
but the kaillera netcode doesn't actually include any form of recovery from connection instability DS.
so really you would need a new netcode protocol, which would require a new client and server as well.

in summary:
- new emulator
- new netcode
- new server
- new client

i'd consider attempting it for $500 000.
I think a team of five seasoned programmers working full time could get it done in a year or so.


the reasonable thing would be to offer the reward only for fixing the timeout ds.
that would only require successfully decomipling/reverse engineering the kaillera server.
as karajan pointed out, once you have the source it's easy.
that might only take a month or two as a full time job, so maybe $5000 would be a suitable bounty.

 

[rjgbadger]

i pledge my undying love, gratitude, and the mercy of TR3G on you and your family, and your family's families

 

[SuPeRbOoM]

old kaillera never had this 18.2 minute ds problem. When emulinker came in, it brought along this dum limit.

Does FEDEX(dropping packets) issue exist on FU still?

 

[firo]

I had a time limit fix about a year ago - I tested a game that worked about an hour on LAN before I stopped. I made it so that the server expects packet number 0 after reaching 65535 instead of changing the whole protocol (which is a much bigger change).

The problem is this was on the open source emulinker 1.0.2, and not the current version of emulinker. Whoever worked on that didn't save the source. I spent many, many hours trying to get a working compiling version of a decompiled jar of the current server code, trying with different decompilers, etc. but no good solutions presented themselves. Starting from emulinker 1.0.2 is a better option, but there are a lot of features that aren't implemented (no lagstat, everyone has the same delay, etc) that would require a lot of time to code.

The real solution, as bloodpeach stated, is a rewrite. I've explained what I believe needs to be done before but I'll put it down here:

- Migration to mupen64plus/bizhawk, which is cross platform (mac, windows, linux), open source, and is still being supported (bizhawk is written in C# and is might be easier for this purpose, but just uses mupen64plus at its core).

A basic version of p2p netplay in bizhawk for n64 would probably only take a week or so of dedicated work. It would be a great project for someone who knows C# and wants to contribute to an open source project (and get a job - work on kaillera was on my resume when I left school). Although I'm coding most of the day at work I may look into this just to see how netplay would perform on a different emulator.

- Lightweight server to coordinate matches (like what melee/pm online uses - could just be as simple as a browser chatroom, http://www.smashladder.com/ would work fine)

- p2p connections with NAT traversal (disabling the need to forward ports)

Users would find a match, enter their opponents IP (or some other identifier), and the emulator will connect and begin gameplay. Doing this with 3+ players is harder but can be done a few different ways and is definitely doable.

Once this is done, we'd likely experience fewer desyncs, and whoever is doing this can then work on detecting desyncs, sharing emulator states, and so on.

 

[Madao]

There's already 2 open source kailera emulators that desync way less than pj64k. No need to migrate to Mupen64plus which has no good plugins. Both are already good enough to where most, if not all desync comes from unstable internet. Now if you guys are just ambitious and want to make an emulator that surpasses the current one, then great, but otherwise it's best to use what's available.

If you guys really insist on using Mupen64Plus as a base and implement your own kaillera code, please add back zilmar spec. The plugins available for Mupen64Plus are laughable.

As for the server code, I could take a look at that jar, if someone links me it. I'd be willing to give it a shot. I guess I'll need the source to 1.0.2 as well.

 

[firo]

Mupen64plus has rice, for openGL, and glide. The new plugin being developed (https://www.indiegogo.com/projects/gliden64-graphics-plugin) will also support it. I don't think plugins is a big problem.

The other emulators may desynch less than pj64k, but who uses them? The idea is to not have to have people download some unused emulator just to play online, it should also be the one the use to play offline. Dolphin does this well. Plus, none of those emulators are maintained. Mupen64plus is the future of n64 emulation unless something new comes around, and in a few years from now, who knows what will happen to the unsupported emulutators. Getting pj64k to work on windows vista was a hassle.

Getting online to work itself isn't much code. The majority of kaillera/emulinker was the other stuff - chatting, joining games, access rights, GUIs, etc. All of that is not necessary now. If netplay was integrated into mupen64plus or bizhawk, that would make playing online much more accessible, and possible on different platforms.

Here's the link to the most recent emulinker files I have. I wish anyone the best of luck if they want to try and get a working compiling version. The only thing in here that's changed from the emulinker 1.0.2 release (which you can find on a search engine) is the emulinker.jar.
https://www.dropbox.com/s/dvx0d3h35oqn3vd/emulinker.zip

Chrome gives me a malicious warning when downloading but I promise it isn't. I'm really not sure why it's labeled that way.

 

[Madao]

Well if portability is important, then ya Mupen64Plus is the best option. I personally don't like bizhawk though (had too many problems with it). I forgot about glideN64, but if I understand correctly, it requires OpenGL 4.2 which i don't have unfortunately ;/. Anyway, I'll worry about the plugins when this actually happens . As for the other emulators, people still use them because different emulators excel in different things. If you want to play Goldeneye OCed, you use Ultrafast V3, if you want to play WDC/Stunt Racer, you use PJ64 2.1, etc. I think it would be great to combine features of different emulators.

You're right that getting online to work isn't much code. Especially when you can copy paste code from other emulators xD.

Now about this emulinker issue. It's been a while since I've reverse engineered java (not really a java person), so I can't promise that I will succeed, but if it's as simple as changing a few lines of code, it should be doable. I've already looked at the jar with a decompiler and can see most, if not all of the source code. So can someone explain to me a bit more about what to change, to fix the time limit issue?

Right now, I'm looking at this piece of code in 1.0.2's source.

protected V086Message(int number) throws MessageFormatException
    {
        if (number < 0 || number > 0xFFFF)
            throw new MessageFormatException("Invalid " + getDescription() + " format: Invalid message number: " + number);

        if (messageType < 0 || messageType > 0x17)
            throw new MessageFormatException("Invalid " + getDescription() + " format: Invalid message type: " + messageType);

        this.number = number;
    }

Is this the part that needs to be changed? Also how would I test the code xD? I'm not familiar with this server stuff ;/ .

 

[firo]

I looked through some old chats and found this, I think this is all that needs to be done (at least in emulinker 1.0.2):

in v086Controller, adding the if:

if(messages[i].getNumber() == 0)
     lastMessageNumber = -1;

at the beginning of the for loop to get the number of messages around line 528.

And in the v086Bundle changing the if check to break from the loop around line 134 to:
if (messageNumber <= lastMessageID && lastMessageID != 65535)

For testing, since there aren't any automated tests, you can just start a game and wait, maybe put a breakpoint on those lines if it helps. Testing locally (running the server on your own machine, then connecting with localhost:27888) should work with kaillera emulators.

Reverse engineering is not that simple unfortunately. Changing this in emulinker 1.0.2 is not hard, but injecting these changes into the emulinker.jar requires decompiling it, and no decompiler that I have tried allows me to compile the whole source without errors. And even when I got a version to compile it didn't function properly. If you just decompile these two classes though you might be able to just extract the rest of the jar and rebuild it, which could work. I had used that method to make very small changes to emulinker X a few years ago.

 

[Madao]

Wow I must have the wrong source or something ;/ . In 1.0.2, V086Message.java is only 186 lines. I guess I'll try finding the correct source code.

Ik reverse engineering isn't simple. Dealing with decompilers is a hassle and often times, it doesn't fully decompile the jar.

Edit: Kinda even more confused now. Looking through the jar in the package you linked, I saw this piece of code already,

public synchronized int getNextMessageNumber()
    {
      if (this.messageNumberCounter > 65535) {
        this.messageNumberCounter = 0;
      }
      return this.messageNumberCounter++;
    }

 

[firo]

Not v086Message - the fist class is v086Controller, and the second is v086Bundle. V086Message is 186 lines in my version of 1.0.2.

Also, in what file is that code you referenced? It's possible I added that myself but I'm not sure.

 

[Madao]

LOL idk how i missed that! Sometimes I do silly things ;/ .

The code i referenced was in V086Controller.class . I looked at V086Controller.java and it also had that code in it. Oh boy I must have been out of it today. Well now I found what you're talking about. I'll see what I can do.

 

[Agent 21 iXi]

I looked through some old chats and found this, I think this is all that needs to be done (at least in emulinker 1.0.2):

in v086Controller, adding the if:

if(messages[i].getNumber() == 0)
     lastMessageNumber = -1;

at the beginning of the for loop to get the number of messages around line 528.

And in the v086Bundle changing the if check to break from the loop around line 134 to:
if (messageNumber <= lastMessageID && lastMessageID != 65535)

For testing, since there aren't any automated tests, you can just start a game and wait, maybe put a breakpoint on those lines if it helps. Testing locally (running the server on your own machine, then connecting with localhost:27888) should work with kaillera emulators.

Reverse engineering is not that simple unfortunately. Changing this in emulinker 1.0.2 is not hard, but injecting these changes into the emulinker.jar requires decompiling it, and no decompiler that I have tried allows me to compile the whole source without errors. And even when I got a version to compile it didn't function properly. If you just decompile these two classes though you might be able to just extract the rest of the jar and rebuild it, which could work. I had used that method to make very small changes to emulinker X a few years ago.

I now have a working, compilable source of the lastest version of EmuLinker X and will be posting it soon

 

[Capos]

People prioritize gameshark codes over desynching, so that's the problem.

But you need them right? Or is there a way to have characters/item switch unlocked online without them?

 

[Madao]

I now have a working, compilable source of the lastest version of EmuLinker X and will be posting it soon

How did you manage to accomplish that?

But you need them right? Or is there a way to have characters/item switch unlocked online without them?

Save files automatically get synced in Mupen64++. I'm pretty sure KVE synced saves too ;/ .

 

[Agent 21 iXi]

How did you manage to accomplish that?
Save files automatically get synced in Mupen64++. I'm pretty sure KVE synced saves too ;/ .

I used a combination of about 5 different compilers varying in quality, analyzed the bytecode of the contents of the EmuLinker X v1.2 .jar file so that I could see how each class worked. Then I checked each .java file with compile errors against the original emulinker 1.0.2 source and all of the results of the different compiler's interpretations and fixed the remaining errors.

 

[Madao]

I used a combination of about 5 different compilers varying in quality, analyzed the bytecode of the contents of the EmuLinker X v1.2 .jar file so that I could see how each class worked. Then I checked each .java file with compile errors against the original emulinker 1.0.2 source and all of the results of the different compiler's interpretations and fixed the remaining errors.

Cool, so I had the right idea of how to do it. I just lacked the motivation . Thanks for your hard work! I'm sure a lot of people will appreciate what you did.

 

[Capos]

How did you manage to accomplish that?
Save files automatically get synced in Mupen64++. I'm pretty sure KVE synced saves too ;/ .

Using KVE, I've never hosted and had stuff unlocked without having cheats enabled. But I did have a save with stuff unlocked when I played offline. If there's a way to fix that I'd do it.

 

[Madao]

Using KVE, I've never hosted and had stuff unlocked without having cheats enabled. But I did have a save with stuff unlocked when I played offline. If there's a way to fix that I'd do it.

Ya I just did some testing ;/ . With PJ64KVE, it doesn't sync saves. I even tried setting the Kaillera save file as read-only and that didn't work. So all the emulator does is overwrite save data. How pointless ;/ .

The amount of hassle I had to go through, just to set up plugins, makes me wonder why people love PJ64k/KVE. As for why you had stuff unlocked without cheats, it's probably because the host had cheats on.

Mupen64++ and 1964 both sync saves.

 

[MrMarbles]

I now have a working, compilable source of the lastest version of EmuLinker X and will be posting it soon

so what exactly would this mean for online play?