Planet SoC

This Week:

This week’s big accomplishment was completing the wizard. From initially getting it to work to a fully functional wizard only took two (long) days of hacking, thanks to good preparation everywhere else.

I also improved the control scripts and XML definitions. The server and ruleset stuff implemented so far works well.

Big sigh of relief. Looks like I covered everything I set out to. While there are undoubtedly some rough edges, given how the slow progress of early August pushed me almost right up to the deadline, there are no major gaps.

From Here On Out:

Well, I managed an eleventh-hour completion of the single-player wizard, the last major component of my Google Summer of Code project. From here on out, it’s wrapping up little loose ends, spit and polish, documentation, and instructions for some sort of proof-of-concept demo.

This Week:

I wrote the Single Player wiki page early this week, and expanded on it several times since. There is a flowchart showing the conceptual steps to starting a single player game in a wizard context, and an accompanying Python script which actually interfaces with the libtpclient-py backend. There are also sample XML and control script files for tpserver-cpp, the Risk ruleset (as if it were a separately installed module), and the two GSoC AI clients (daneel-ai and GenCon).

The Thousand Parsec Single Player wiki page, which I started this week, provides information about implementing single player mode in clients (for now, only those using libtpclient-py) as well as adding support in servers, rulesets, and AI clients. The implementation section provides a text-based Python script that emulates the functionality of a wizard.

This Week:

Two of three major components of single-player mode have been tackled as planned this week.

The first was specifying the XML and control script formats each server, ruleset module, and AI client should use. I will document it in detail on the wiki soon, but for now, take a look at the most current mock-up I’ve been using for testing and demonstration.

The second was developing the SinglePlayer module of libtpclient-py (in the singleplayer branch). This builds server, ruleset, and AI client information lists from the aforementioned XML files, presents some useful higher-level functions (more to come, as I develop the GUI part), and starts and stops the external programs using the control scripts with some intelligence.

Yesterday’s thoughts on implementing the single-player wizard in libtpclient-py.

I’m planning to use Python’s xml.sax module to parse multiple server/ruleset XML descriptions into a big list-and-dictionary structure. The structure for, say, tpserver-cpp-0.5.1.xml would look something like this (though the final product would, in general, consist of the data from multiple such files):

I’ve started mocking up what the XML descriptions and control scripts for Thousand Parsec single-player mode would look like in a /usr/share/tp context. The idea is for the servers, rulesets, and AI clients to provide their own descriptions of what they are and what they need, as well as a common interface that clients can start them with. This way, none of the components are bound to each other’s specifics. The design is admittedly very UNIX-centric currently. Feedback, as always, is appreciated.

This Week:

I completed the libtpproto-py administration components. This turned out to be less ambitious than I anticipated, involving mainly creating an admin connection object, the various command frame objects, and a log message frame object. Everything seems to work so far.

This Week:

I spent some time attempting to fit a couple other students’ midterm reports to the layout I designed. I never intended to reuse it, so it consists of a bunch of manually placed text boxes and images. Along with OpenOffice Draw apparently being the black sheep of the family in terms of bugginess, my spirit is beaten, and I give up. I’m going to try to redo the reports in a less masochistic way.

On the bright side, there is now a config branch of libtpproto-py. I have begun adding administration frame functionality to it locally, but I haven’t made much progress yet.

This Week:

I added some small but important bits of functionality to tpadmin-cpp. Notably, libtpproto-cpp now handles log message frames properly, and tpadmin-cpp detects server-end disconnection and cleans up the command list accordingly.

The rest of the week was spent adding comments to the code wherever they seemed particularly important, and working on the midterm report.

Next Week:

This Week:

First, with llnz’s help, I fixed the connection issue in tpadmin-cpp, which had to do with the way libtprl was being used in the EventLoop context.

I think the first half of my GSoC project, comprising the administration protocol, the modifications to tpserver-cpp and libtpproto-cpp to support it, and the standalone tpadmin-cpp administration client, is ready for prime time, or at least a half-hour spot at 3:00 AM on the public access channel.

I’ll still be hammering it for bugs over the next day or two, but fingers crossed, it looks good right now. There are still a few gaps in functionality that will probably be added at some point; notably, the local command set is only updated at login currently, but eventually the client may want to watch for changes in the server-side list and update.

Well, tpadmin-cpp almost works properly now.

The connection problem was due to the console input loop monopolizing the single-threaded event loop, so that the sockets never got checked for data. On Lee’s suggestion, this was fixed by making the console a TPSocket that would be scheduled by the event loop.

This Week:

Early in the week, I added an AdminLayer interface to libtpproto-cpp, and a series of other commits completed the functionality over a two-day period. Notably, I created a CommandDescCache for command descriptions. More recently, I added an AdminStatusListener class, so that clients can act when the AdminLayer status changes.

This Week:

Early in the week I finished adding the various administration frames to libtpproto-cpp in the new config branch. This provides the basic frame packing and unpacking functionality. I have deferred implementation of the CommandUpdate frame since I’m not entirely sure it’s necessary.

Next, I started the tpadmin-cpp utility. The basic console functionality is there, but currently it doesn’t connect to the server. When I got to this point, I realized that clients using libtpproto-cpp would connect through a high-level interface in that library called GameLayer, rather than implementing their own code for this based on lower-level stuff. So, tpadmin-cpp is now waiting for a similar interface tailored to admin clients.

On the libtpproto-cpp front, I think I may just be finished, in the programmer’s sense of the word (seems finished, but will most likely need plenty more work once I actually try to use it). I added CommandTypesList, Command, and CommandResult frames. Conspicuously missing is the CommandUpdate frame, which I am not really sure I need. No big deal to go back and implement there and in tpserver-cpp if I do.

Since Friday, I’ve managed to get a decent amount done on libtpproto-cpp. I added a config branch — a bit of a misnomer since I’ve been calling everything “admin”, but consistent with my tpserver-cpp branch. So far I have the LogMessage, GetCommandDescription, and CommandDescription frames, and functionality for command parameters.

This Week:

Unfortunately, my internet connectivity was extremely limited while I was away this week for a conference in Boston, so I wasn’t able to accomplish much actual coding work (in fact, I managed to total two commits all week).

However, I did get a chance to review the libtprl and console code reasonably thoroughly, and the currently available libtpproto-cpp briefly. My familiarity should give me something of a head start in implementing the client, and indeed, it looks as if it should be relatively straightforward.

This Week:

There is now a fully functional CommandManager in tpserver-cpp. It implements a basic command set similar to what was once in the console, and allows modular addition of new commands (from rulesets or plugins, for example). It also implements the command description portions of the protocol extension, in a fashion similar to order descriptions in TP04. Together, the CommandManager and Command classes already implement just about everything necessary for commands on the server side.

This Week:

The administration protocol extension is now specified in the XML format using the protocol DTD. It uses some of the existing basic frames and most of the new frames are closely related to the Order family from the main protocol. This may not be the “final” specification, but at this point I think the only likely changes are additions.