Week Three Report - On Track + Some Extra

This blog post signifies that I am back on track with the schedule I created at the onset of working on tpweb. What I've been working on is both fixing the cache issue that was delaying my progress by days, as well as implementing multiple queue support for the program.

The way the cache is supposed to work is that its data is pickled between load and save commands, and this allows for data perpetuity. However, tp04 broke this functionality, and since it was not going to be worked on for a while, the cache had to be dealt with differently. One thing I tried was to store the cache into a global variable, but for some reason, it created thread instability when an order was submitted. The error looks like this:


File "libtpclient-py/tp/client/threadcheck.py", line 6, in thread_check_callable
    assert self._thread is threading.currentThread(), "%s can only be called by %s not %s" % (func, self._thread, threading.currentThread())

AssertionError:  can only be called by <_DummyThread(Dummy-3, started daemon -1250780304)> not <_DummyThread(Dummy-2, started daemon -1242387600)>

I tried asking people in the irc channel, but mithro's been busy and the others haven't run into this problem. The ultimate solution I arrived at, much to my disdain, was to have the cache update before each order is submitted, so that the right thread is chosen. The problem with this is, while it works over a localhost, it will create lag issues when the client is transmitting to a remote server. I'll have to go back and remedy this once I find out how to deal with this threading issue.

While I was working on this, I figured it would be best to work on the multiple queue order functionality as well. Before my acquisition of the project, tpweb only allowed one order to be maintained by an object, but the tp04 standard opened up this capability.

I attempted to have the backend submit the order id in an order queue to the frontend javascript, so that modification to both frontend and backend code sets would be minimal. However, apparently, every time the cache is updated, the order ids are changed, so that by the time a send_order command would finish, the get_orders command would already have a new order id set associated with the current orders for an object. This meant that order ids could not be passed between backend and frontend, because they would become antiquated too rapidly.

What this meant was to have both ends of code communicate these order ids based on their position in the order queue. So that if there is a Move command, followed by a Wait command, their ids would be id 0 and id 1 subsequently.

The backend accepted this structural change without much hassle, but the javascript side was less willing to accept change. For some reason, when the data gets passed between python and javascript through the json bridge, the queue order does not necessarily stay in its order. And if the javascript has a different order for the order queues, then it can't communicate with the python end. And this broke the code for a time. However, eventually I got the javascript to adhere to the order by sorting the array of orders before use, and everything become good.

The surprising thing by the end of all this was, though I should have been just caught up, according to the schedule, I'm now a week ahead. I suppose I might have overestimated the difficulty of dealing with multiple queues, but that grace was paid for by the toil of the past three weeks in dealing with just one order in queue. Since I went a bit out of order from the schedule, here's a updated terse version.

May 31th: Upgrade to TP04 Standard

June 7th: Upgrade to TP04 Standard
June 14th: Implement Multiple Queues
June 21st: Dynamic Object Type Support
June 28th: Dynamic Media Support

July 5th: Messages to BattleLog
July 12th: Rollover Object Information Panel
July 19th: Display Trajectory of Objects
July 26th: Move Orders to Info Panel. Subsequent menus implement

August 2nd: Right-click Menu for Orders
August 9th : Build Commands Issuable through Right-Click
August 16th : Bug Hunting

So yeah, on to dealing with dynamic object support and media display for objects. Essentially, I will be stripping any code that makes indication to any specific object types (such as Ship, Galaxy) and have the code construct its types based on what is sent from the server. I'll probably have to deal with the media support issues as well, so the next two weeks will be again switching between both issues.