Status Report

This one is a little late, but anyway here is a recap of what I did last week.

Fixed the goto button for the messages window thanks to lots of help from mithro and greywhind in irc. Now clicking on it will cycle through all the objects specified in the message. Still not too ideal though. There was also a suggestion to make the message window into a two-pane reader similar to e-mail clients like Thunderbird. I really like the idea and it's definitely on my list of goals.

Fixed the move order in TP's Reach for the Stars (RFTS) ruleset. The problem was that move orders are implemented differently in Minisec and RFTS, one uses absolute coordinates while the other uses object ids. Order parameters are something I will be talking more about later.

Display a radial menu using CEGUI widgets. The circular background is a static image, while the buttons are created in code and arranged in a circular pattern around the center. The menu is currently toggled with the spacebar, and I shall have to find a way to activate it via the mouse. Also, it does not follow the object when the screen is moved around, which is something I actually intended but looks a little weird in practice.

Handling order parameters when sending new orders was pretty much the focus of the latter part of my week. Thousand Parsec has quite a few order parameter types, and rulesets can mix and match them up however they like, so parameters have to be handled in as generic a way as possible. Thus far, I have handled the following order parameters:

• Time
• Object
• List
• Absolute coordinates
• String

I haven't done the rest because I've not been able to find orders which use those parameters yet. Anyway, to implement these parameters, I had to create a new widget for each new parameter I found. I first drew up the widget layout to act as a template and hid the widget upon runtime. Then, I made a copy of the widget as needed and placed them inside a ScrollablePane, a useful CEGUI widget which allows it's content to be scrolled.

Finally, handling list parameters is a little different from the other parameters. This is because while other parameters can take in a generic set of values, lists only take in values from a limited set of options which are defined by the type of object selected. This requires creating the order first using some default parameters and sending it to the server. After that, the server will return the order populated with the options, which I can then use to show the user. After selection, the order with the user's selections is sent to the server to "overwrite" the initial order. This has the habit of creating "phantom" orders filled with default options when the client updates while the user is still filling in the order.

Now it's time for the strange problems section. :)


Some messages use html tags which are not supported at the moment. There's also a unwelcome gradient in the horizontal scrollbar now that I look at it.

RFTS is still not playable yet. The problem is mainly with the lack of ship design support, which RFTS requires to build even your first fleet, but there are also some usability issues such as not showing which turn it is as RFTS allows different kinds of orders depending on the current turn.

Still no nice way to colour the fleets and indicate which planets are your own. I might go with some kind of overlay over the objects containing the player's name.

Code structure. Under the hood, the code contains a lot of method calls which violate the Law of Demeter, in other words many classes have intimate knowledge of the structure of other classes and "reach through" them to get the things they need. I'm not sure if this is actually something particularly bad, but it is an eyesore. Also, there is a small amount of duplicated code which I have to remove as well.