donkey.KONG
Smash Rookie
- Joined
- May 5, 2012
- Messages
- 19
Legend
- confirmed for release - stable
- unconfirmed for release - could be removed!
- development note entry
Original Post 5-12-2012
I am a software programmer, fluent in C/++/#, Java, VB6, and x86 assembly.
I used PJ64k somewhat in 2004, and was disappointed by the lack of features in Kaillera. I assumed after downloading the updated client in 2012 it would have been far upgraded by then, however only few features it seems have really been implemented since then and they are mainly in terms of stability.
I have considered writing a replacement Kaillera override client, that would allow the original stable Kaillera client to run in the background however invoke all of it's features - including playerlist, chat, games list, etc. I also think it should reflect some of the recent additions to the online playing community, including AQZ support. AQZ and Kaillera players would not be able to play together, but at least people running the AQZ plugin could use a central Kaillera server to find and play AQZ games (which, in my opinion, desync far less often).
I would like to ask this community what additional features (if possible) they would like added to this client override, and any other suggestions would be nice. Right now this project is not a reality, however I have had success with projects in the past and can make this a dedicated reality if the demand is there for it.
AQZ has been developed since around 2009, and it still has not gained the popularity it deserves primarily to the fact that there's 1) no central server and 2) it's not user-friendly.
The disadvantages of the AQZ netplay plugin are:
1) No central server / master list
2) Does not synchronize cheats or save states
The advantages of AQZ over Kaillera games are:
1) The frame delay is redundant and lag is minimal.
2) Less frequent desyncs if all players are using the same plugins. I've honestly played for almost 5 hours without a single ds.
Kaillera p2p games are good and don't desync often, however the stability of Kaillera is arguable. So please post your suggestions as far as AQZ implementation and if you haven't heard of it, here's the netplay plugin topic:
http://forum.pj64-emu.com/showthread.php?t=1973
The idea is to implement this into a kaillera-like client to where there are both AQZ and Kaillera games listed, and perhaps recode the p2p client to where the hoster can optionally broadcast their p2p game onto the main server list.
This will essentially localize all game servers, whether they are AQZ, P2P, or Kaillera, into a single network (i.e. Galaxy) and allow users to more easily connect. I fear the reason AQZ and P2P are not used as much is because of the fact the client was not coded in a user-friendly manner, however I have much experience with doing so and would like to know the demand from this excellent community.
Update 5-25-2012 - concept
It currently relies on a secondary master server to broadcast the primary kaillera server along with any additional aqz or p2p matches that are listed as public.
This is a concept gui and is not final and far from complete. For example it currently shows the host as a username for aqz/p2p matches and also does not update the Users amount for them yet.
However, double-clicking a p2p game will (optionally) close the current client and reload the client in p2p mode, which is now possible by adding executable arguments. These arguments are:
-p2p tells the client to automatically load in p2p mode.
-mode specifies whether to start as a client or host.
-ip specifies the IP/PORT to connect to
-framedelay to autoset a custom frame delay
-broadcast is a boolean (0/1) value that specifies whether the p2p match should be listed to the secondary master server. (currently not implemented)
So if a user currently double-clicked my p2p match listed in this screenshot, it would restart the client with these arguments:
Project64k.exe -p2p 1 -mode client -ip smashbros.servegame.com:27886
I still haven't developed server time-outs, and there are a few bugs that need fixing as well, but I thought I would keep you posted on the progress. Also, users that are not using my client will see a /me chat message when loading an AQZ or P2P game, and if broadcast is specified as true it will include the host IP/port. This is to maintain somewhat backwards compatibility, as updated clients will not see this chat message but will list the specified game instead.
Update 5-27-2012 - bugfixes
- fixed the kaillera chat window from constantly 'refreshing' on new updates. This means while scrolling the chat will update without auto-scrolling to the bottom, and selections are also saved so copying and pasting is a lot easier in busy areas (i.e. Galaxy).
- fixed some memory leaks (some repeated at least 8 times) and wrote functions to replace a lot of repeated code structures, which will reduce the size of the client and is more conventional and secure.
- *undecided* maintains backward compatibility with 0.13 01 Aug 2003 release. There is no "Warning: Emulator mismatch may cause desync" when playing with this emulator because the netcode, thus far, remains the same (excluding any additional broadcast netcode)
Update 5-28-2012 - GUI improvements
There's also a bug that if you click anywhere in the chat, the text cursor prevents the chat from auto-scrolling properly. This means if the chat has focus, the furthest it will scroll is the line of the text cursor. Without some buggy hacking, the use of RichEdit is not logical. Owna acknowledges this in his code.
A workaround would be to disable focus on the chat window, but that would prevent copy/pasting. The cursor is required to make selections. So maybe we should make the focus more apparent, i.e. gray out the chat textbox when it's not in focus, and disable the autoscroll while the main chat has focus. Then when the chat textbox regains focus, toggle autoscroll to true.
I've rewrote Owna's rigged re_append function which works with the richtext object directly rather than external API messages. I considered using QTextEdit, an alternative to RichEdit. It's lightweight, cross-compatible and has other features. But the library dependencies were over 1GB so I'm looking at an alternative GUI controlset, wxWidgets. The new function will append the data to this object, and I'm working on a bugless autoscroll now.
I am considering updating the source, but not sure how many servers will adopt the change. Nevertheless, an is_spoofing user variable would be useful. There is a commented portion of the client that used to append "IS_SPOOFING" to the username if they were spoofing, a client-side indication. This could still be used somehow, but perhaps with an asterisk symbol appended instead. I think server owners should have the right to know who is spoofing and who is not, and if they desire, ban spoofing on their server. Let me know your thoughts on this.
This in combination with some of the control issues we're having with RichText has convinced me to restart the GUI from scratch using the wxWidgets control library. wxWidgets even has a very nice socket layer, but I am very hesitant to change socket modules without causing any desync implications, so I will most likely just change the GUI controls to use wxWidgets and leave the socket layer untouched.
wxWidget controls have a lot of awesome features, such as animated emoticons in chat, background images in all controls - if we had a graphics designer, we could come up with a killer GUI using these updated controls. I'm ok with Photoshop, but I don't want to get too distracted with the GUI because there's simply too much code that needs updated. Perhaps we can introduce this concept later using skins.
This will not be a copy-paste job because the whole core is built around these crappy windows controls. The trivial part will be making sure the client stays in sync with 0.13 despite all the core improvements, so I'm still testing with a p2p 0.13 client after every little change I make to ensure nothing is broken, because I am far from a Kaillera expert. Speaking of which, is Project64k meant to be ran on Windows only? I hope so, because the wxWidgets library I'm using is the Windows version and I'm not sure what results would incur from running it on WINE. I also don't even know how many of you use PJ64k with WINE, or if it's ever been possible, so let me know if this is an issue.
Update 5-29-2012
- in the p2p host dialogue, there is now a list of servers that mimics the list in the main interface. The purpose of this is the optional broadcast. It will need to know a server to broadcast the game info to, but due to the way the Kaillera server is designed this will require an established UDP connection with the server. Hopefully this will not impact the benefits that p2p offers with more bandwith being used. Maybe we can add a server-side variable just for p2p broadcasters, to force the server not to send them redundant data (such as the userlist, gamelist, chat, etc). Either way this was necessary to establish a ping/pong between the p2p server and the kaillera server.
- with the new wxWidgets GUI, the bug 'You must close all Kaillera windows first!' when trying to close Project64 (despite all Kaillera windows being closed) has vanished. I myself have found this annoying on many occasions, forcing me to close PJ64 from task manager. Not anymore.
- with the adoption to wxString, a buffer overflow prevention string class that comes with wxWidgets, the majority of the buffer overflow exploits in the existing Owna client are no longer an issue. I saw a blogspot that referred to Kaillera hacking and many of the alleged hacks were buffer overflow exploits. I am pleased to inform you that these exploits are no longer a reality. Improved security ftw.
- implemented gamelist filters. Now you can optionally ignore all games you do not have installed in your ROM directory. You can also specifically filter out p2p matches, aqz matches, or kaillera matches. Chats are not affected by this filter yet.
- when redesigning the GUI for wxWidgets, I had an idea for a button specifically for connecting to The Galaxy. From my experience The Galaxy is the most popular N64 Kaillera server, but some may not agree with this. So maybe we should have an Options dialogue with a checkbox 'Autoconnect to Galaxy.' Please post any GUI or Options requests you have here. Now would be the time to implement them.
To-Do / etc
- since the author of the AQZ topic seems to be ignoring my request, I've been thinking about a method to approach the AQZ broadcast. This is my idea: to bind the AQZ plugin to an additional plugin I will write so that both libraries are loaded simultaneously. However, in order for this to work, people will need to update their AQZ plugin to my new binded one that will essentially be hacking in GUI elements. Alternatively, I could position the window slightly above/below the AQZ window and just add more options. Maybe we should make the client check for which AQZ version the user has, and if they don't have the updated one, load an unbinded secondary DLL; if they do have the binded one, just load the binded DLL. This is the best solution I can think of after a lot of brainstorming and I am still not satisfied, so hopefully before I get to this point we can work something out with the author.
- wxList is capable of listing images in it's listbox control, so maybe the gamelist can be improved with default images for select games. i.e if a user loads a Mario Kart game, there would be an image of the Mario Kart game displayed next to it's list item. The disadvantage of this would be the list items would have to be more spaced apart to give room for the image. Right now it's just an idea, and goes against my initial goal of reducing the client size, but I'm still up for any and all GUI improvements.
- confirmed for release - stable
- unconfirmed for release - could be removed!
- development note entry
Original Post 5-12-2012
I am a software programmer, fluent in C/++/#, Java, VB6, and x86 assembly.
I used PJ64k somewhat in 2004, and was disappointed by the lack of features in Kaillera. I assumed after downloading the updated client in 2012 it would have been far upgraded by then, however only few features it seems have really been implemented since then and they are mainly in terms of stability.
I have considered writing a replacement Kaillera override client, that would allow the original stable Kaillera client to run in the background however invoke all of it's features - including playerlist, chat, games list, etc. I also think it should reflect some of the recent additions to the online playing community, including AQZ support. AQZ and Kaillera players would not be able to play together, but at least people running the AQZ plugin could use a central Kaillera server to find and play AQZ games (which, in my opinion, desync far less often).
I would like to ask this community what additional features (if possible) they would like added to this client override, and any other suggestions would be nice. Right now this project is not a reality, however I have had success with projects in the past and can make this a dedicated reality if the demand is there for it.
AQZ has been developed since around 2009, and it still has not gained the popularity it deserves primarily to the fact that there's 1) no central server and 2) it's not user-friendly.
The disadvantages of the AQZ netplay plugin are:
1) No central server / master list
2) Does not synchronize cheats or save states
The advantages of AQZ over Kaillera games are:
1) The frame delay is redundant and lag is minimal.
2) Less frequent desyncs if all players are using the same plugins. I've honestly played for almost 5 hours without a single ds.
Kaillera p2p games are good and don't desync often, however the stability of Kaillera is arguable. So please post your suggestions as far as AQZ implementation and if you haven't heard of it, here's the netplay plugin topic:
http://forum.pj64-emu.com/showthread.php?t=1973
The idea is to implement this into a kaillera-like client to where there are both AQZ and Kaillera games listed, and perhaps recode the p2p client to where the hoster can optionally broadcast their p2p game onto the main server list.
This will essentially localize all game servers, whether they are AQZ, P2P, or Kaillera, into a single network (i.e. Galaxy) and allow users to more easily connect. I fear the reason AQZ and P2P are not used as much is because of the fact the client was not coded in a user-friendly manner, however I have much experience with doing so and would like to know the demand from this excellent community.
Update 5-25-2012 - concept
It currently relies on a secondary master server to broadcast the primary kaillera server along with any additional aqz or p2p matches that are listed as public.
This is a concept gui and is not final and far from complete. For example it currently shows the host as a username for aqz/p2p matches and also does not update the Users amount for them yet.
However, double-clicking a p2p game will (optionally) close the current client and reload the client in p2p mode, which is now possible by adding executable arguments. These arguments are:
-p2p tells the client to automatically load in p2p mode.
-mode specifies whether to start as a client or host.
-ip specifies the IP/PORT to connect to
-framedelay to autoset a custom frame delay
-broadcast is a boolean (0/1) value that specifies whether the p2p match should be listed to the secondary master server. (currently not implemented)
So if a user currently double-clicked my p2p match listed in this screenshot, it would restart the client with these arguments:
Project64k.exe -p2p 1 -mode client -ip smashbros.servegame.com:27886
I still haven't developed server time-outs, and there are a few bugs that need fixing as well, but I thought I would keep you posted on the progress. Also, users that are not using my client will see a /me chat message when loading an AQZ or P2P game, and if broadcast is specified as true it will include the host IP/port. This is to maintain somewhat backwards compatibility, as updated clients will not see this chat message but will list the specified game instead.
Update 5-27-2012 - bugfixes
- fixed the kaillera chat window from constantly 'refreshing' on new updates. This means while scrolling the chat will update without auto-scrolling to the bottom, and selections are also saved so copying and pasting is a lot easier in busy areas (i.e. Galaxy).
- fixed some memory leaks (some repeated at least 8 times) and wrote functions to replace a lot of repeated code structures, which will reduce the size of the client and is more conventional and secure.
- *undecided* maintains backward compatibility with 0.13 01 Aug 2003 release. There is no "Warning: Emulator mismatch may cause desync" when playing with this emulator because the netcode, thus far, remains the same (excluding any additional broadcast netcode)
Update 5-28-2012 - GUI improvements
There's also a bug that if you click anywhere in the chat, the text cursor prevents the chat from auto-scrolling properly. This means if the chat has focus, the furthest it will scroll is the line of the text cursor. Without some buggy hacking, the use of RichEdit is not logical. Owna acknowledges this in his code.
A workaround would be to disable focus on the chat window, but that would prevent copy/pasting. The cursor is required to make selections. So maybe we should make the focus more apparent, i.e. gray out the chat textbox when it's not in focus, and disable the autoscroll while the main chat has focus. Then when the chat textbox regains focus, toggle autoscroll to true.
I've rewrote Owna's rigged re_append function which works with the richtext object directly rather than external API messages. I considered using QTextEdit, an alternative to RichEdit. It's lightweight, cross-compatible and has other features. But the library dependencies were over 1GB so I'm looking at an alternative GUI controlset, wxWidgets. The new function will append the data to this object, and I'm working on a bugless autoscroll now.
I am considering updating the source, but not sure how many servers will adopt the change. Nevertheless, an is_spoofing user variable would be useful. There is a commented portion of the client that used to append "IS_SPOOFING" to the username if they were spoofing, a client-side indication. This could still be used somehow, but perhaps with an asterisk symbol appended instead. I think server owners should have the right to know who is spoofing and who is not, and if they desire, ban spoofing on their server. Let me know your thoughts on this.
This in combination with some of the control issues we're having with RichText has convinced me to restart the GUI from scratch using the wxWidgets control library. wxWidgets even has a very nice socket layer, but I am very hesitant to change socket modules without causing any desync implications, so I will most likely just change the GUI controls to use wxWidgets and leave the socket layer untouched.
wxWidget controls have a lot of awesome features, such as animated emoticons in chat, background images in all controls - if we had a graphics designer, we could come up with a killer GUI using these updated controls. I'm ok with Photoshop, but I don't want to get too distracted with the GUI because there's simply too much code that needs updated. Perhaps we can introduce this concept later using skins.
This will not be a copy-paste job because the whole core is built around these crappy windows controls. The trivial part will be making sure the client stays in sync with 0.13 despite all the core improvements, so I'm still testing with a p2p 0.13 client after every little change I make to ensure nothing is broken, because I am far from a Kaillera expert. Speaking of which, is Project64k meant to be ran on Windows only? I hope so, because the wxWidgets library I'm using is the Windows version and I'm not sure what results would incur from running it on WINE. I also don't even know how many of you use PJ64k with WINE, or if it's ever been possible, so let me know if this is an issue.
Update 5-29-2012
- in the p2p host dialogue, there is now a list of servers that mimics the list in the main interface. The purpose of this is the optional broadcast. It will need to know a server to broadcast the game info to, but due to the way the Kaillera server is designed this will require an established UDP connection with the server. Hopefully this will not impact the benefits that p2p offers with more bandwith being used. Maybe we can add a server-side variable just for p2p broadcasters, to force the server not to send them redundant data (such as the userlist, gamelist, chat, etc). Either way this was necessary to establish a ping/pong between the p2p server and the kaillera server.
- with the new wxWidgets GUI, the bug 'You must close all Kaillera windows first!' when trying to close Project64 (despite all Kaillera windows being closed) has vanished. I myself have found this annoying on many occasions, forcing me to close PJ64 from task manager. Not anymore.
- with the adoption to wxString, a buffer overflow prevention string class that comes with wxWidgets, the majority of the buffer overflow exploits in the existing Owna client are no longer an issue. I saw a blogspot that referred to Kaillera hacking and many of the alleged hacks were buffer overflow exploits. I am pleased to inform you that these exploits are no longer a reality. Improved security ftw.
- implemented gamelist filters. Now you can optionally ignore all games you do not have installed in your ROM directory. You can also specifically filter out p2p matches, aqz matches, or kaillera matches. Chats are not affected by this filter yet.
- when redesigning the GUI for wxWidgets, I had an idea for a button specifically for connecting to The Galaxy. From my experience The Galaxy is the most popular N64 Kaillera server, but some may not agree with this. So maybe we should have an Options dialogue with a checkbox 'Autoconnect to Galaxy.' Please post any GUI or Options requests you have here. Now would be the time to implement them.
To-Do / etc
- since the author of the AQZ topic seems to be ignoring my request, I've been thinking about a method to approach the AQZ broadcast. This is my idea: to bind the AQZ plugin to an additional plugin I will write so that both libraries are loaded simultaneously. However, in order for this to work, people will need to update their AQZ plugin to my new binded one that will essentially be hacking in GUI elements. Alternatively, I could position the window slightly above/below the AQZ window and just add more options. Maybe we should make the client check for which AQZ version the user has, and if they don't have the updated one, load an unbinded secondary DLL; if they do have the binded one, just load the binded DLL. This is the best solution I can think of after a lot of brainstorming and I am still not satisfied, so hopefully before I get to this point we can work something out with the author.
- wxList is capable of listing images in it's listbox control, so maybe the gamelist can be improved with default images for select games. i.e if a user loads a Mario Kart game, there would be an image of the Mario Kart game displayed next to it's list item. The disadvantage of this would be the list items would have to be more spaced apart to give room for the image. Right now it's just an idea, and goes against my initial goal of reducing the client size, but I'm still up for any and all GUI improvements.