Some updates

Here are the changes I have made to the thousand parsec client this week.

Movement orders possible by selecting a fleet and right-clicking the destination. Finding out how to send orders in thousand parsec was an important milestone for me.


Movement paths are indicated by a line. However, this does not remain when the turn updates. In addition, changing the destination will leave the old line behind. :( I will be getting to that shortly...


Able to delete messages. I would like the "Goto" button to center the map on the source of the event. For instance, a battle report message would go to the combat location. However I could not find any information in the message object passed by the server that might help. Currently, the message object has id, slot, type, subject, body, turn number and references as it's attributes, and clearly "references" would be a good place to look, but I found it empty no matter what the message. So, "goto" is still in progress. Also, I think a message count in the window title would be useful.

Able to exit to the login screen and re-enter the same game. This was done by clearing all the resources and loading them upon re-entry. However, tpserver logs do not report a client disconnect, so I have find out how to do that before entering another game.

Some bugs I have encountered:

The mouse cursor is hovering over what is called a "CEGUI listbox" object. Since I am using it to show available orders for the selected object, it required removing the list and repopulating it whenever a new object was selected. However I found that it would segfault immediately upon removal of an object. Finally saw a method called "setAutoDeleted(boolean)" for listbox items in the api, which deletes the item automatically when it is removed from a list. After setting it to False I could then remove items without crashing. Hope that this helps other python-ogre cegui users out there, since the setting is on by default. My unqualified guess is that python's gc does not like objects deleting themselves automatically.

What's next
I have been giving some thought to improving the look of the client. I think it should be pretty clear that the current 3d models are all placeholder objects. I've found Vega Strike to be a rich source of 3d models, although I have only played the game a couple of times. Ideally, I would like to have different models for each ship class, but this might become ruleset-specific. So right now I would assign a ship model type to each player, so "Player 1" would always get a certain model and so on.

Planet models should have a texture to them as well, but I'm wondering how to distinguish planets from one another. For instance, some planets could be "Terran" type, "Arid" type, "Acid" type and so on. In rulesets which don't supply such information, I would apply a generic planet type to prevent confusion.

For stars, they ought to have a glow in addition to their texture. Actually mithro, who created the client, has already put in "glow" billboards, but they are not visible as I think I forgot to resize them.

Currently it's not clear which ships and planets belong to each player, so they have to be differentiated somehow. I guess I could change the material settings for each fleet to colour them, but colouring planets would be weird. Perhaps I could change the colour of their text label, but I've already found some colours to be barely visible against the background. A better way would be to surround the planet with a coloured halo, because at least the player won't have to read it.

The skybox currently being used for the background has to go as well. I will try a particle system of white dots with billboarded nebulae. Hope it looks better than it sounds. :)

A status report

Yesterday marked the official start for coding. Following my schedule, these are my features for this week:

- Starmap will represent objects with different models
* Stars, fleets and planets can be distinguished from one another

This is where the coding I've done beforehand comes in handy. Stars, fleets and planets can be distinguished already, using some extremely primitive models.

If you squint, you can still see the blueprint lines on those ships :). Those are my three fleets orbiting around the home star system. It is a bit close to the other star for my liking, but I'm not sure what to do about that. I guess I will add some colour tinting to distinguish friendly assets from the enemies (which is everyone else).

- Client will show a message window
* Able to scroll, flip through messages and delete them.
* A Goto button will center the map on the object related to the message.

So far, I have implemented some of the windows already, based on how the existing tpwx client works. Since the messages window can flip through messages using "Next" and "Prev", I will be adding a goto button and delete button as well. I guess I'll have to resize those existing ones.

A bit of silliness

I spent a lot of time reading through the tpclient-pywx code and tp's client libraries to figure out how a client sends code. This line under StateTracker's ChangeOrder method threw me off for a while:

evt = self.application.cache.apply("orders", "change", self.oid, node, order)

I guess the function of the cache object is rather self-explanatory. It is found in the tp client library, and stores all of the universe objects which has been very handy for getting object properties so far. Thinking I could use the cache.apply method to send orders (my reasoning was that when cache is changed it will notify the server automatically) I tried adding this to my code. However, nothing happened and I couldn't figure out an alternative approach and instead kept combing through the same code over and over to look for any mistakes.

When I tried downloading all the alternative clients I found the answer in the text-based python client. The code is spread over two files only, and immediately reveals that the Connection object should be used instead. It contains all the methods (such as insert_order) necessary to make things happen.

I guess the lesson learned here is to look for simple alternatives before going deeper down a chosen path. Since the tpwx client and tp client libraries have a very large code base, I should have made sure there were no other choices first before delving in.

Taking a little break

Right now, I'm on a rather impromptu vacation in Sydney. I'll be back on Sunday.

Thinking I could make commits on the go, I copied my ssh keys over to the laptop which I lugged all the way here. Unfortunately, it seems that the tp server rejects any commits not from the original machine? I'm not too familiar with ssh I'm afraid.

Currently, I'm trying to send orders to move the fleets around, but how to do that is still not obvious to me. I've read the tp03 protocol and skimmed through the tpwx client code already, but the real problem is that the weather is really great for sightseeing, even at night (which starts at 5+ p.m.). Internet access around here is a little hard to come by as well. What I wouldn't give for some of Singapore's island-wide wifi right now :)

On the GSOC front, it seems that Google has now sent out the mystery book via Fedex to all the students. I haven't read any blog posts since then for fear of spoiling myself.

On one hand, I can't wait to get back to Singapore and code, on the other, it really is rather nice here...

Rendering of stars and fleets

One design issue I've run into is how to display planets and fleets in relation to star systems. Thousand Parsec uses incredibly large distances when positioning the stars in order to give a sense of scale to the game. In order to fit everything reasonably close together for the player, I've scaled down these distances. It works decently for star systems, but when it comes down to individual planets, they appear right on top of their parent systems due to scaling.

There are a few approaches I could try to solve this problem

1. The tpclient-wx approach

The flagship client of Thousand Parsec draws both fleets and planets as dots in a circle around their star systems. This would involve ignoring their individual locations and drawing them in an arbitrary position around the star.

2. The GalCiv 2 approachGalactic Civilisations 2 draws planets and fleets in a semi-realistic manner. What I mean is, planets are out of proportion and now that I think of it, it appears that all the planets have an equal distance from the sun. So this is not really a different approach from the above, the only difference is that fleets can move around the system (not supported in TP).

Image credit: GalCiv 2 site

3. The MOO2 approach
Master of Orion 2 draws star systems and fleets on the map - no planets. To view planets, one has to click on the system which brings up a window showing the individual planets. Very elegant in my opinion.

Here is another shot of how systems are drawn in relation to fleets.

Image credit: Mobygames

4. Another method would be some kind of dynamic map which changes in detail as you zoom in and out (Homeworld style).

I guess this post has really been a thinly veiled excuse to post some nice screenshots from other games. :) Now back to work!

TPServer update

There was an update of tpserver to 0.5, which is a big update and includes the Reach For the Stars ruleset. RFTS offers a more substantial ruleset for thousand parsec and is based on the actual game. Sadly, I missed out on playing this game before, but no more! I wonder if there will be a MOO or Spaceward Ho! ruleset too. :)

I was trying to compile the server on my system, when I started to get errors all over the place. Then I went back to try compiling 0.4.1 and failed too, so I knew I had probably had some issues with my system configuration.

Later while chatting with the devs, I found that the cause was due to me running gcc 4.3 while the devs were using 4.2.3. With the handy porting guide, I compiled the server successfully but found that all I needed to do was to add some #include statements. If only all my problems would be this easy.

SleekSpace

Over the weekend, I found a nice CEGUI skin for the client. When I first downloaded it, it was strangely missing a lot of property tags needed to work correctly, such as text colours and one of the frame borders not showing up. Not sure if I managed to get the same look as the original, but at least I learned a little about the Falagard skinning system in the process. I'm guessing there are still missing property tags since I haven't tried all the widgets.

I thought I would try some simple layouts to see how the main gui might look, then I ran into some problems with the star system labels.

Looks like the GUI blocks out the star objects correctly but not the text overlays. I'll have to look into how OGRE's overlays work. Once the rendering order is sorted out, I'll start to look into how I can retrieve information(messages, system information, etc) using the tpclient library.

edit: Looks like I just had to change one parameter from False to True when creating the CEGUI renderer.