Red herrings

I got a little distracted by some issues yesterday.

The first was the sphere mesh I was using for planets and star objects. No matter what texture I applied to it nothing would display on the surface except for the general colour of the texture. For some reason I decided it would be cool to generate a sphere in code using the "create a sphere" code snippet. It cost a bit of time to adapt the code and finally I got stuck at the part using pointers anyway. What I did in the end was to create a new sphere mesh in blender with the texture coordinates applied.


Here's the stars and planets with a texture (from vega strike again!) applied. It is very faint, but the "glow" of the star has an issue as well: it runs into the image border and looks cropped. Once again, I spent time fooling around with different image formats and Ogre's scene blending options to try and fix the problem. I also tried creating flares with a transparent background but Ogre doesn't like that, it requires a black background instead. The cause and solution was found in this forum thread, which is to adjust the levels and make the outer glow invisible.

So anyway, I was trying to create a selection boundary around the selected object, and came across this cool thread detailing the use of stencil buffers and render queue listeners. After a while, I had adapted the code over to python but found what seems to be a bug in python-ogre: RenderQueueListener methods require a return value which is a pointer to a c++ bool object. Even with a listener stripped of all code it would still have the error, and I'm not sure how to create a c++ type. This might have been fixed in the latest Python-Ogre, but compiling that is quite a chore.


What I went with in the end was a simple billboard pasted over the selected object, which is still better than using the bounding box. I'm currently wondering if this sun, with the glow exposed, is more 'sunny' than the previous one.


After adding a few different types of planets and stars.

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.