I guess the Terminator warned us this time would be coming. Today I committed some of the new features in Parsek to KDE server. You can find a link to the repo here. Give it a try and let me know if you have any problems. Quickly after starting, you will realize this is still very much a work in progress. I guess I underestimated the complexities of building a game client and have failed to deliver all the originally planned features. I see the work done for GSOC as big step in the evolution of Parsek and it will allow me to continue developing Parsek into a premier Thousand Parsec client. Once the coming soon features described below are ready, I will be uploading the GSOC changes to the Thousand Parsec git repositories as well.

Current Features
Users can now connect to game servers, select games, join, and later disconnect cleanly.
A status manager responds to events from the protocol library.
A corresponding status widget displays connection status, server information, and game information.
A clock displays the time until end of turn (EOT) events.
A logger widget provides debugging and error messages. The logger is a implemented with a filterable model.
Users can view the game universe with the object viewer. The object viewer, tied to an object model, provides basic information about selected objects.

Bugs and Quirks
There remains several unresolved bugs that still need work.
1) The object viewer does not display the last modified time in proper format.
2) The object viewer does not correctly read the object type.
3) The EOT clock could be formatted in hh:mm:ss instead of just seconds.

Undelivered Feature Status
Starmap: The starmap is still a work in progress. The starmap will be tied to the object model. Basic drawing is functioning but still need to implement game object coordinate readings.
Messages: The basic backbone for the message system will be similar to the logger. This will be added later this week. The protocol functionality for messages is not yet implemented, but Parsek will be ready for message support.
Orders: As mentioned during the midterm report, this feature was removed from the project scope. I will start working on this after the object system is fully functioning.

Coming Soon
There are somethings not included in the current build. I will be adding these features over the next few days after a little more testing and proper integration. This includes a more robust object model with support for object parameters including resources. The object viewer interface will also be further improved to provide a better user experience. The object model behind the object viewer will be expanded with abstract type implementation and also work with orders, players, designs, and resources. In addition, a player viewer will added shortly. This will provide a display of the game’s player and later allow the user to send a message or read information about selected players. The chat system will be integrated with the logger and both will allow for filtering and sorting.

The next major feature coming soon is an overhauled main interface. The default dock widget system is ugly and the advantages it provides are minimal. This is a game, not an IDE, so I see little need to provide a fully modifiable window. The new main interface will display the game widgets in an organized and effective manner while working with low resolution displays. The target is to have Parsek function well on 800×600 displays. There will also be a splash window at the start which will allow user to connect to games. The connection manager will also include an account manager. A simple custom button interface will replace the traditional application menu.

Future Visions
Future plans include completion of the message system and the order system. I also plan on configuring Parsek to watch for changes in real time and display updates asynchronously instead of downloading all objects at each EOT. I will spend time working on the protocol library to complete support of some the important features still missing. I will try to complete my failed efforts to get the protocol library functioning on Windows by providing supporting network implementation. After the interface overhaul, I hope to extend Parsek to provide support for 3D graphics.

Screenshots

Parsek’s object tree is now functioning. There is still a lot of work to do to clean it up, make it look nice etc but the overall functionality is now there and works. I’ll be adding a seperate widget that popups when a selection is made in the tree and displays the object’s full information, instead of trying to embed it all in the tree’s columns.

Have a look at the screenshot! The tree hierachy matches tpclient-pywx with the exception that lone objects who’s parent are the galaxy (after they have left a system) are all listed at the bottom, instead of underneath their old parent system.

Yay! So I’ll be adding more features to this as well as hopefully getting the starmap in place (now that I know the information from the data model is loaded correctly) in the next few days. Once all the bugs are fixed in the object tree, I’ll add it to the KDE svn branch.

There’s been some progress over the last couple of days. I fixed a small issue with exception handling in Parsek. Turns out Qt disables exceptions by default and Parsek was crashing even though it was trying to catch exceptions from the protocol library. Parsek’s event handler now catches DisconnectedExceptions when reading or writing to the server, though it does not do anything with them yet. More importantly, downloading the universe’s objects is coming closer to functionality. The program correctly receives the objects from the universe, I was able to read and verify (using tpclient-pywx) the information in the object frames in the debugger. However, the Qt model is still broken and needs some work. The model view design in Qt is a little bit confusing but the QAbstractModel class is pretty sweet. When properly configured, you can just use any of the pre-created viewer widgets (QTreeView, QTableView, etc) to instantly display the data. Right now I’m having trouble getting the view to refresh as the information is loaded in from the server. The Boost + Qt integration here is getting a little hard to keep track of. I hope to have this resolved in the next couple of days and be able to post some screenshots of the object viewer. Thankfully there some good Qt examples out there for this type of thing…

Wow. The last week just fly blew. I can’t believe it has been a week since my last blog update. Let’s just say all things didn’t go as planned over the past week. Tuesday the 28th was actually my birthday so I took the day off to go to the amusement park to ride some roller coasters! The fun didn’t last very long past Tuesday however. For whatever reason, I started having problems with GDB and QtCreator. Whenever I would set a breakpoint, GDB would just crash. It got frustrating trying to continue without a functioning debugger. I’m the type of person who just writes code sloppily and then tries to compile+debug and clean up afterwards. Reinstalling QtCreator and the GDB packages didn’t stop the crashing. I got fed up and decided to try doing a clean install with Kubuntu instead of openSuse. Things just got worse from there. I mistakenly burned a copy of the x64 ISO which I then proceeded to install. After finally managing to get all the required packages installed, compiling would fail with Boost throwing up about 1500 lines of errors. For whatever reason, I just couldn’t get it to work. After realizing I had switched to x64, I figured it was perhaps a problem or incompatibility related to that. So again, I reinstalled Kubuntu, x86 this time. It managed to go a lot speedier the second time around. The whole situation with Boost is frustrating as well as the only supported packages available for Ubuntu are versions 1.35, which is horribly out of date. I could have built the needed Boost libraries from source, but unfortunately CMake wouldn’t properly find them and would instead only locate the /usr/include/ version that was forcibly installed with KDE! Updating KDE removed the Boost dependency and allowed me to install a new version of Boost. I managed to find more up to date packages on launchpad but it took a few tries and different versions to get it to work. In the end, I wasted about two days with this non-sense but it did end up compiling. The good news is however, I have a fresh install with the latest version of QtCreator (which resolves many debugger problems anyway) and my damn GDB doesn’t crash anymore. I think the lesson here is NOT to go damn messing with your development enviroment in the middle of crunch time. This has proven to be one of the more frustrating lessons in Linux. Installing software and packages can be extremely frustrating because of versioning and dependencies. Hopefully this new Ubuntu proposal makes it into the new versions and helps resolve some of these dilemmas. I really think this is one of the things holding Linux back from mainstream. … /end rant

Over the weekend I spent time cleaning up some code and doing a little refactoring. I’m also making some progress on object display but it is going slow. I’ll have more to report on this soon. There’s roughly 2 weeks left until the final deadline. I’m committed to having what was proposed at the midterm ready and in a functioning state. The revised proposal suggested the message system would be completed by the end of this week and the object system by the end of next week. I’ve suggested leaving the message system until next week as there still needs to be some code and functionality added to the protocol library before it will work. So the focus for this week is the starmap and object system as they are really partners in backend functionality (they retrieve their information from the server in the same way).

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.