Parsek’s clock is now functional, cleaned up, and integrated with the program’s status bar. There’s still an odd bug I’m trying to resolve that occurs when I spawn a dialog box which somehow resets the clock when it (the dialog) is dismissed. Strange problem but otherwise, the clock is working fine. It is also accurate when compared to tpclient-wx. The status widget is also now functioning thanks to Lee and some fixes in the protocol library. Parsek can reads the server and game information and displays it in a simple widget. Below is a screenshot of the status and clock functionality. There’s still some issues that need to be fixed.

I’m also configuring the “game” selection widget which will spawn after connecting to a server. This will provide the user with a list of all available games on the server and allow the user to select which one to join. While most servers currently only run a single game “tp”, this will be an important feature for the future when servers are running multiple game instances. I have some ideas beyond the basic pulldown/list menu selection for the game chooser which I will try to elaborate on. The idea is to have an overview of each available game displayed and allow the user to scroll through them in a nice manner, similar to Cover Flow on iTunes/iPhone. For the time being however, it will be a simple dropdown menu! Keep it simple until it works! The account creation features of Parsek are also non-existent at the moment as well. I’ll be adding this shortly. In the mean time, I’m also working on the object display features, as I discussed in my last post. Still more to come there as I’m hoping to have that online ASAP as well.

An updated build has been posted to KDE SVN here. Please try it out. Right now many features are disable and it simply acts as a test of the log, the status widget, and the clock. Try building it and connecting to demo1.thousandparsec.net with guest/guest. Note that you have to actually click the Connect button in the connection dialog – the enter key hasn’t been configured yet!

Just a quick update before I go to bed. The EOT clock is now functioning and is properly synchronized with the server. I verified this by comparing the values received in the Parsek clock with those in tpclient-pywx. Stays consistent with tpclient-pywx, off maybe by one second. The rest of the GameStatusListener functions are mapped and the Parsek client receives eotStarted() and eotEnded() events as well as new clock updates as they are pushed at the EOT. The EOT clock is now integrated into the Parsek’s status bar in a similar fashion to tpclient-pywx. I will also configure it to mimic the same flashing behavior as the EOT counts down to zero.

I’ve also created a simple connection status widget. This basically shows if the game is connected, logged in, and if the account creation succeeded. I will expand this tomorrow to display the server address, logged in username, and account details. Thanks to Lee, the GameInfo frames have now been implemented as well. I will be integrating these changes to Parsek tomorrow. The status widget will then include the server name, game name, ruleset type, and other game information retrieved from the GameInfo frame.

All of this will be wrapped up by the end of the weekend. For this upcoming week, I’ve started experimenting with object display using some of JLP’s old code. The first step will be to redevelop the model used in Qt to store the object information. Once this is done I will develop the tree-based widget and starmap for display. I’m trying to find the best way to the handle the starmap drawing. I also want to make sure the object model is kept expandable and will allow for easy integration with a simple 2D starmap or 3D based version that could be included later on down the road. That’s all for now, check in soon.

Slow day today. I had to catch up on some chores and other stuff around the house before jujutsu practice but I managed to find some time to get some work in. I spent some time designing the clock/status widget and conceptualizing the implementation of some of the features. Most of the time was spent working on CMakeLists.txt files trying to figure out how to build the library along with Parsek so I can debug both at the same time. I managed to get it working but it was poorly organized and had all the source files in the same directory. It took me a while to get the library and Parsek organized in separate folders and able to find each other. As surprisingly easy CMake is once you figure out the syntax, it is pretty difficult to find good tutorials or examples online. That’s all for now, more to come later.

A small bug in the protocol library was preventing Parsek from connecting to the server. This issue has been resolved and patched. Parsek can now fully connect and logon to servers. ParsekEventLoop seems to be processing the protocol libraries callbacks properly but there is still some more testing to do. At the moment, it seems correctly able to do socket reads but socket writes might present other problems. There also might need to be some fixes to get the class to properly clean up on termination.

Next step I’m going to work is on providing real-time clock updates from the server. This will provide a foundation to build more real-time updating functionality in Parsek like the message system. I’m a bit behind the desired July 20th deadline for the clock system completion but with the other problems now out of the way, I’ll be able to have it complete by the end of the week.

I spent the weekend working on some bugs and problems with the connection routine. I updated my build of the protocol library and noticed a small bug preventing Parsek from connecting. I made Lee aware of the small problem and he promptly fixed. It took a while to realize that the bug was a result of the protocol library and the whole time I thought it was the client doing something wrong. After resolving that, I pushed on further by throwing in some logger messages in the protocol library to see where Parsek was get stuck. Right now it is narrowed down to a particular problem. During connect, the protocol library sends the Connect frame to the server. This part is being properly executed. The GameLayer::connect function, line 354, is executed and returns true after the frame is sent. The problem is afterwards, the GameLayer::ConnectCallback is not executed and the client hangs in a gsConnecting state. This problem points to the eventloop not properly executing the callback functions. I tried to debug the eventloop and peak into what was going on. My listenForSocketRead(TPSocket *socket) is the only function getting called and the file descriptor monitors, handled by the QSocketNotifier class, are not getting triggered. I peaked into what information was being read from the TPSocket and it seems the file descriptor is being read as 0. After asking Lee, it turns out this is not normal and could be the reason why the QSocketNotifier is not triggering (monitoring fd = 0) and therefore the callbacks are not being executed.

In order to help make this problem easier to test and debug, I created a stripped down client simply for connecting. The main components in action here are the parsekeventloop class and the core of the program is in the mainwindow.cpp file. Have a look and see if there is something you might think is wrong in the eventloop or in the connection routine in mainwindow.

Download TAR Package
Visit Code Postings

No major update for the last couple of days. Still working on some problems with the event loop. Going to have something more after the weekend.

I got sidetracked a little over the past couple of days dealing with my overheating laptop. It is a pretty new machine but unfortunately came equipped with one of those defective Nvidia 8000 series GPUs. The damn thing heats up like a toaster. I already got Asus to replace the motherboard and GPU in November but now it seems the CPU is overheating. I guess it is a combination of poorly designed chips and bad cooling. Luckily for me, my warranty expired last month. My laptop is out of commission until I can find a good cooling solution so I’ve have to reset my Linux install on my desktop.

Today I spent some time configuring my Qt Creator based development environment to build both Parsek and the protocol library. While the protocol library is a standalone library, by doing this I will have more power to simultaneously debug both ends of the program. I also need to do this to resolve an issue of the client getting stuck during the login procedure. In addition, I am in the process of setting up a tp-server to run. Up until now I have been using the demo servers for testing. Creating my own server will now allow me to monitor the client’s activity from the server side. It is taking some time to get all this organized but it is all sorted out by tomorrow.

Another thing I am looking at is getting the protocol library to build in Windows along with Parsek. I believe maintaining both Windows and Linux compatible builds is important. There are a few problems in the socket and network code in the protocol library that are holding it back from properly compiling in Windows. I’ve already sorted out issues regarding the lack of <stdint.h> in Windows. I spoke with llnz about rewriting some of the socket code to make it compatible with Windows. It mostly involves changing header files and changing some of the function calls. If it ends up being feasible I will try to get this done quickly so future developers can use the protocol library on Windows.

This post is going to be an overview of the current status of Parsek. Let’s have a look at the objectives of this project.

Full Integration with Protocol Library
Current Status: Testing still required
Expected Completion: July 20th
Deliverable: Synchronized Clock

Integrating the KDE/Qt application with the new protocol library has proven to be difficult. The key part of this task involved integrating the Qt application’s event loop with the protocol library’s EventLoop class. The intended design of Parsek is to provide a fully asynchronous client to users. The combination of Boost libraries, network programming, and the Qt tookit has provided a series of challenges. There are still some problems in Parsek’s EventLoop that need to be fixed. I’m planning on building the protocol library in my application for debugging purposes to see where my application is getting stuck. Parsek’s EventLoop may be failing to handle some callbacks from the protocol. I expect it to still take another week before all these problems preventing proper client/server communication are fixed. The deliverable will be what I call the full function clock. The client’s clock will be synchronized with the server and update in real time. It will also receive EOT events. Parsek will also be able to display general game information from the server.

Starmap
Current Status: Only basic widget in place
Expected Completion: July 31st
Deliverable: Basic display of system

I believe once the issues with the server communication are fixed, the starmap will not take long to complete. Right now, as I cannot properly receive information from the server, it is impossible to test the starmap. I’m thinking of temporary testing the starmap by manually creating objects on the client side. That will be the alternative approach to testing the starmap if I cannot get the client to download the data. Qt will provide a lot of the functionality that will make this task easier to complete.

Message System
Current Status: Model in place, basic widget complete, testing required
Expected Completion: August 7th
Deliverable: Full display of game messages

The message system again needs some more time for testing. I believe it will functional quickly. I am still trying to design the message system to update in real time as messages are received. The plan is have a dynamic message display that can be easily sorted by the user.

Object System
Current Status: Not started
Expected Completion: August 14th
Deliverable: Display of system’s objects through starmap and separate tree-based display and information widget

This will by far be the most complicated task of the project. In fact, I can’t say I’m optimistic about having it complete by the end of the GSOC deadline. However, I am certain significant progress will be made in the Parsek client towards having a full featured object display system. The client will be able to the display the system’s object through the starmap and a separate searchable and filterable tree-based widget. In addition, a seperate widget will display information about selected objects. The widget will be configured for media support and displaying the object’s parameters. Another feature I am hoping to implement is the ability for the user to spawn additional object information widgets which would allow them to compare multiple objects simultaneously. Think of it like tabbed object browsing.

Order System
Current Status: Not started
Expected Completion: After GSOC

I don’t expect this part of the project to be completed before the final deadlines. I still plan on working on Parsek after GSOC is over so I hope to still add the order system. At this point I want to focus on the other tasks as I believe they are more important to Parsek.

General Overview
According to the initial plan, a lot of these tasks should already be complete. Clearly the project is behind the original schedule. Creating the eventloop class was difficult and provied interesting challenges. A lot of time was wasted I predict there are still more issues to work out. Despite the slow pace, I believe there is value in the work being done. Even if I fail to complete other tasks, integrating the Qt application with the protocol library’s eventloop and provide asynchronous real-time updating of game information will prove be valuable for future developers. It will serve as a demonstrable example of integrating the protocol library with a GUI toolkit. I plan to provide significant documentation to help future developers trying to complete similar tasks. I’m still confident that once issues with the client connectivity are resolved, many of the other tasks will be able to be accomplished quickly. Despite a significant setback of not including a working order system by the end of GSOC, the Parsek client should at least provide users the ability to watch games as a spectator. In addition, I believe working on simultaneous Linux+gcc and Windows+MSVC builds will prove to be valuable. This will ensure the code for Parsek and the protocol library is fully portable across both systems and allow future developers on either side of the fence to help out with project. Each system has its advantages when testing as well.

My work on Parsek has been challenging. The most important time spent on the project thus far has been overcoming various learning curves to understanding a complex client/server program. I have spent a lot of time getting familiar with the system so I plan to continue on working on Parsek and Thousand Parsec after GSOC is over. I have ideas for improving Parsek and providing great features like integration with a battleviewer or similar 3D system while remaining quick, responsive, and portable.

Read that little status bar! Finally connected!

Just fixed that bug. Yes, as you can read from the status bar, it is finally connected. (Yes I know there’s nothing else in the app, the widgets haven’t been loaded.)

Today I was able to finally get to the eventloop to properly compile. Thanks to caduel on the Qt Centre forums I was able to resolve some of the problems with the build. The QHash containers now correctly store the callback timers and their corresponding signals. There still might be some issues regarding the cleanup at the destructor but I think that the removal of the callback signal after it is called should take care of any problems here. There was also an issue with Boost complaining about exceptions in the case the callback signal is called when empty. This case shouldn’t occur either way but I was able to resolve this problem by adding #define BOOST_NO_EXCEPTIONS and an empty void boost::throw_exception(std::exception const & e) {} function. In the case (I can’t think of any need for it) that the exceptions would need to be handled, it can now be implemented.

So while the class was able to compile with all the new changes, the client still gets stuck when connecting on the call eventloop->listenForSocketRead(sock) in the protocol’s gamelayer class. I hope to try to resolve this issue tomorrow. I think it might just be the result of a silly bug that I’m trying to track down. Thankfully the debugger in Qt Creator is very helpful so I’m hoping this will be a quickly squashed problem. With the end of the midterm evaluation period coming up, I plan to have a report online detailed the next steps of the project and so forth online as soon as these last couple of issues with the eventloop are resolved.

Please see my thread on Qt Centre here. Also thanks again to caduel on the forums there – I would still be stuck where I was a week ago without him. There’s also some good info there about getting CMake, Qt, and Boost to all play ball together.