I ran into problems with MTsec not working, and so while it is being sorted, I worked on implementing a click function when the player wants to give a move order to an object.
What the click functionality for the move order is supposed to do is enable a player to select either an object or sub object on the map(hence why it was necessary to have rollover system objects) or anywhere on the map and that would send the position to the server. This is much more efficient than having the player enter the coordinates by hand, which is tedious and wholly ineffective.
In order to do this, a click manager was necessary so that if a move order is enacted, any click would then be interpreted as the position desired by the player instead of normal functionality such as if a player were clicking on an object to get its information.
Getting the position of an clicked object was fairly hassle-free since the space position is already stored in memory. Unfortunately, it is not so easy to send any arbitrary position based on the map, and so the bulk of my time has been spent attempting to translate a pixel position into a viable space coordinate.
I will say this, I absolutely hate dealing with pixels. Especially in the browser.
The main problem I've had is figuring out how to translate an always positive position such as (200,500), with a range of (0,0) to (1920, 1020), into a grid value that the space coordinates are stored as. The map display has a psuedo sort of quadrant system, but it is one way only. What has added to the confoundation of it all is that the y axis in css is negative on top and positive on bottom, instead of the usual way.
Suffice to say, I'm still stuck on the problem. After I do come up with a solution, whenever that happens, I'll begin bug testing, since I don't think I'll have time to deal with the design panel and because I've been running into several annoying bugs that need to be dealt with, such as the home planet not accepting a build order.
Tuesday, July 27, 2010
Tuesday, July 20, 2010
Week Eight Report
It was becoming apparent that certain object panels would need to have focus within the viewport, so I wrote a simple window manager which allows the info panel to disappear if the order's panel is brought up or to close the right-click order's menu if the order's panel is up. However, this caused problems with the rollover objects on the map, and so I had to deal with that as well. It was a bit complicated how I set it up initially, and for the longest time I was having trouble with the z-index of things which is the stacking property in css. If two objects were close to each other, one of the objects would always interrupt the rollover subpanel for a map object. I believe the ultimate solution was to temporarily change the z-index of the current rolled-over object on the map. But there were several other issues with this that took a while to solve. It came down to one of those issues with css that end up taking hours to solve when it ultimately ends up being a single css property.
Initially when the player clicked an object on the map, the info panel would appear centered directly under the mouse pointer. However, when an object on the system panel was clicked, the info panel would appear centered in the browser, close to the top. Since it was a bit confusing to have the position of the info panel change so much, I had it position itself in one spot every time. This will allow the orders panel to appear in that same spot so that there's less confusion for the player.
In the info panel, there's always been a list of children objects that I've never found a use for, since there's already the system panel. I finally decided to take it out, meaning I can shrink the info panel a bit.
The other major change that happened this week was implementing functionality to the right-click orders menu and bringing back the order's panel. I ran into some code that was again using the object id to refer to a specific order set instead of the queueid, and this caused some confusion in the code for a time.
After orders could be submitted, I could the tweek the order's list on the info panel. It was mostly display issues that arose, and they weren't that time consuming to deal with. I added the links to allow a player to asc/desc/remove an order, but I think it'll look better and save some space if they're icons instead.
I still need to shrink the info panel and make the icons, as well as write some functionality for the orders, but it looks like I'll be able to start on the design panel this next week.
Initially when the player clicked an object on the map, the info panel would appear centered directly under the mouse pointer. However, when an object on the system panel was clicked, the info panel would appear centered in the browser, close to the top. Since it was a bit confusing to have the position of the info panel change so much, I had it position itself in one spot every time. This will allow the orders panel to appear in that same spot so that there's less confusion for the player.
In the info panel, there's always been a list of children objects that I've never found a use for, since there's already the system panel. I finally decided to take it out, meaning I can shrink the info panel a bit.
The other major change that happened this week was implementing functionality to the right-click orders menu and bringing back the order's panel. I ran into some code that was again using the object id to refer to a specific order set instead of the queueid, and this caused some confusion in the code for a time.
After orders could be submitted, I could the tweek the order's list on the info panel. It was mostly display issues that arose, and they weren't that time consuming to deal with. I added the links to allow a player to asc/desc/remove an order, but I think it'll look better and save some space if they're icons instead.
I still need to shrink the info panel and make the icons, as well as write some functionality for the orders, but it looks like I'll be able to start on the design panel this next week.
Tuesday, July 13, 2010
Week Seven Report
I started with adding the order's list to the info panel. I still need to add the functionality that allows the player to asc/desc/remove an order from that panel, so I'll take care of that probably next week after the right-click functionality is in place. You can't really sort/remove orders if you can't add them in the first place.
The square icons that represented a planetary system on the map was starting to look old, so I replaced them with a shrunken version of the media image that comes from the server.
Then I went to implementing the rollover panel that shows the children of a system, such as planets and ships. These too have their media image shrunken, and since the planets are animated, it gives it a nice effect. When a player rolls over a system, it also dims the names of the other surrounding systems to aid readability.
After that, if a player right-clicks one of the children objects, a pop-panel with the orders for that specific object will display. I have to match the style with rest of the ui, and the functionality still needs to be put into place. I also have to remember that $("map-canvas") does nothing, and it must be $("#map-canvas").
One thing I hate about css is you can sink 5 hours into getting something to display correctly (ie the rightclick menu) when the problem is a single attribute in the css. And then once you get the thing to finally display correctly, it will not work in terms of usability. And then it does in a different way. So maddening.
Next week, I'll be adding the functionality to the rightclick order's menu.
In terms of schedule, it looks like I'm definitely ahead of schedule. I seem to keep doing things out of order as they come up:
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 + Redesign
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
However, I'll be implementing the desgin panel that was not originally in my proposal. So here's the new tentative schedule.
July 19th: Orders issuable from the right-click order's menu / Order position changeable from the info panel.
July 26th: Display design information in design panel.
August 2nd: Issue Design changes from design panel.
August 9th: Fix browser compatibility issues
August 16th: Fix browser compatibility issues
The square icons that represented a planetary system on the map was starting to look old, so I replaced them with a shrunken version of the media image that comes from the server.
Then I went to implementing the rollover panel that shows the children of a system, such as planets and ships. These too have their media image shrunken, and since the planets are animated, it gives it a nice effect. When a player rolls over a system, it also dims the names of the other surrounding systems to aid readability.
After that, if a player right-clicks one of the children objects, a pop-panel with the orders for that specific object will display. I have to match the style with rest of the ui, and the functionality still needs to be put into place. I also have to remember that $("map-canvas") does nothing, and it must be $("#map-canvas").
One thing I hate about css is you can sink 5 hours into getting something to display correctly (ie the rightclick menu) when the problem is a single attribute in the css. And then once you get the thing to finally display correctly, it will not work in terms of usability. And then it does in a different way. So maddening.
Next week, I'll be adding the functionality to the rightclick order's menu.
In terms of schedule, it looks like I'm definitely ahead of schedule. I seem to keep doing things out of order as they come up:
June 14th: Implement Multiple Queues
June 21st: Dynamic Object Type Support
June 28th: Dynamic Media Support
July 19th: Display Trajectory of Objects
August 9th : Build Commands Issuable through Right-Click
August 16th : Bug Hunting
However, I'll be implementing the desgin panel that was not originally in my proposal. So here's the new tentative schedule.
July 19th: Orders issuable from the right-click order's menu / Order position changeable from the info panel.
July 26th: Display design information in design panel.
August 2nd: Issue Design changes from design panel.
August 9th: Fix browser compatibility issues
August 16th: Fix browser compatibility issues
Wednesday, July 7, 2010
Week Six Report
This week was sort of a transitory week, with other stuff getting in the way, so it was spent mostly planning for the coming weeks.
I did however manage several modifications. When switching from Minisec to MTsec, I discovered that the Universe size changes, which broke the planetary object map display. The positions of the objects in MTsec were also outside the constraints of the universe boundaries, which is illogical. But apparently there is no guideline in place to stop this. So in order to come up with a scaler variable that would work for both Minisec and MTsec, the program now has to determine the size of the actual universe. The javascript then takes those dimensions and converts the position of each object into a distance percentage from those bounds, and then translates that into pixel distance with the browser viewport height as a constraint so that everything is basically viewable within the browser. It took a while to come up with this solution and I don't particularly like it, but it works for now.
The other fix I had to implement was the custom scroll bar to the system panel, since apparently I forgot to apply it last week. However, the whole scroll thing seems to impede usability somewhat and I might have it switch to a scroll based on the mouse scroll wheel, which technically is more intuitive than the scroll bar in general. The only problem with this is for people that don't have a mouse wheel. I can't particularly imagine such a group to be the majority, but it's still bad practice to exclude them.
I had planned to do the design panel, and I did research a bit on how I'd implement this. However, there seems to be a bug with MTsec (the ruleset that supports the design dialog) in that the server isn't sending over the commands for a player's home planet. I'll have to wait till this is fixed before I handle constructing the design dialog, which will probably take me about two weeks to complete with the amount of python and javascript coding that will be required.
I had also planned to put the order's list onto the clickable system info panel, but after looking over the order's class again, it's looking like I'll have to deal with that when I do the right-click orders menu for an object. This also led to the realization that because the map only displays planetary systems, it will be difficult to get at something like a ship that's parked in one of those systems. I don't want to have to use the system pulldown dialog since I don't really like it in general.
So for this next week, I'm going to have to implement a rollover panel for the systems on the map that will display all the objects within a planetary system. Once that is done, I can also deal with the right-click order issuing and having the orders show up on the info panel. Optimistically, I want to say it will only take me a week, but given how big the order's class is, modifications to that will probably require two weeks. We'll see by next weeks progress report. After that, I should be able to deal with the design panel.
I did however manage several modifications. When switching from Minisec to MTsec, I discovered that the Universe size changes, which broke the planetary object map display. The positions of the objects in MTsec were also outside the constraints of the universe boundaries, which is illogical. But apparently there is no guideline in place to stop this. So in order to come up with a scaler variable that would work for both Minisec and MTsec, the program now has to determine the size of the actual universe. The javascript then takes those dimensions and converts the position of each object into a distance percentage from those bounds, and then translates that into pixel distance with the browser viewport height as a constraint so that everything is basically viewable within the browser. It took a while to come up with this solution and I don't particularly like it, but it works for now.
The other fix I had to implement was the custom scroll bar to the system panel, since apparently I forgot to apply it last week. However, the whole scroll thing seems to impede usability somewhat and I might have it switch to a scroll based on the mouse scroll wheel, which technically is more intuitive than the scroll bar in general. The only problem with this is for people that don't have a mouse wheel. I can't particularly imagine such a group to be the majority, but it's still bad practice to exclude them.
I had planned to do the design panel, and I did research a bit on how I'd implement this. However, there seems to be a bug with MTsec (the ruleset that supports the design dialog) in that the server isn't sending over the commands for a player's home planet. I'll have to wait till this is fixed before I handle constructing the design dialog, which will probably take me about two weeks to complete with the amount of python and javascript coding that will be required.
I had also planned to put the order's list onto the clickable system info panel, but after looking over the order's class again, it's looking like I'll have to deal with that when I do the right-click orders menu for an object. This also led to the realization that because the map only displays planetary systems, it will be difficult to get at something like a ship that's parked in one of those systems. I don't want to have to use the system pulldown dialog since I don't really like it in general.
So for this next week, I'm going to have to implement a rollover panel for the systems on the map that will display all the objects within a planetary system. Once that is done, I can also deal with the right-click order issuing and having the orders show up on the info panel. Optimistically, I want to say it will only take me a week, but given how big the order's class is, modifications to that will probably require two weeks. We'll see by next weeks progress report. After that, I should be able to deal with the design panel.
Tuesday, June 29, 2010
Week Five Report
I started this week by rewriting the function that checks if the media images exist on the server. Instead of having it open a connection to the server every time it needs to see if an image exists, the client now checks the text file stored on the server called media-new, which contains a list of all the images on there. So it was simple enough to have it create an array of the list and check against that array. It's now a lot faster than it was.
After that was done, I worked on reskinning the client based on the layout I had made. There's really not much to say in terms of bugs and whatnot, since the whole process is basically exporting bits and pieces of the layout composition and coding each piece with certain css properties. What consumes the most time is getting those css properties to work the way they're supposed to.
This is what it looks like:
I actually moved the menu and messages dialog to the left, to uniform the whole thing a bit. They're expandable when you click their names, which is a fun effect.
I ended up redoing the css properties for all the windows in the client, such as the info panel and system panel. In fact, I combined the orders panel with the info panel and made it pop up when an icon on the map or system panel is clicked.
While getting the css to conform the way it was supposed was time consuming, the most difficult part was probably implementing a custom scroll bar to the panels, since the regular one looks out of place. However, with the current JQuery lib being used, it turned out a bit difficult to implement a custom one, so I included a plugin scrollbar class to the javascript lib.
It appears that next week I'm supposed to do the rollover object information panel. I'm not sure I want to implement this now that there's the clickable information panel, so we'll see what happens. I have to think about it. I might work on the design window instead.
After that was done, I worked on reskinning the client based on the layout I had made. There's really not much to say in terms of bugs and whatnot, since the whole process is basically exporting bits and pieces of the layout composition and coding each piece with certain css properties. What consumes the most time is getting those css properties to work the way they're supposed to.
This is what it looks like:
I actually moved the menu and messages dialog to the left, to uniform the whole thing a bit. They're expandable when you click their names, which is a fun effect.
I ended up redoing the css properties for all the windows in the client, such as the info panel and system panel. In fact, I combined the orders panel with the info panel and made it pop up when an icon on the map or system panel is clicked.
While getting the css to conform the way it was supposed was time consuming, the most difficult part was probably implementing a custom scroll bar to the panels, since the regular one looks out of place. However, with the current JQuery lib being used, it turned out a bit difficult to implement a custom one, so I included a plugin scrollbar class to the javascript lib.
It appears that next week I'm supposed to do the rollover object information panel. I'm not sure I want to implement this now that there's the clickable information panel, so we'll see what happens. I have to think about it. I might work on the design window instead.
Tuesday, June 22, 2010
Week Four Report
The first main thing I worked on this week was, of course, modifying TP Web. It was a bit weird this time in that I've known what exactly I need to fix because the bugs would present themselves one by one. But since this week was the start of implementing changes rather than fixing bugs, it was a bit disconcerting as to where I should start.
However, that unease was shortly lived, and I fell back into things soon after. I started with turning the static object types mentioned in the code (Ship, Planet, Galaxy) into a more dynamic list presented by the server. This began with modifying the backend python code because the function that constructs the JSON object data had a reference to this static object type list. However, the static object types were not as deeply ingrained in the backend code as they were in the frontend javascript code, so it was actually a simple modification.
I began working on the frontend code, and I believe the process, while somewhat more intensive, wasn't all that more difficult either. It was mostly just switching from reliance on a static object type array to using the object type name that gets sent in the JSON stream. However, this led to the realization that I would have to work on the dynamic media goal concurrently. Something to do with the css code needing it but I don't remember the specific reason.
Thus, I also went into the code to enable it to take the urls sent in the json stream and use those for icons and media images. What was difficult about this was that the image urls do not come with a image type attached to them, like png or gif. If it had, I could have just had the code in the frontend post the links as if they were images. Since that is not the case, I had to have the python backend go through each image link and test if it's a png. If that fails, it then tests if the image is a gif. This slows the code down a lot, and will need to be fixed later to find a more elegant solution, because it's really annoying.
When I had implemented this, I discovered that some image links that come from the server are not actually there. Llnz knows about this apparently, and I'm supposed to tell Mithro what images are not up there. But I haven't been on linux for the past couple of days, so never had them with me. Basically it's the universe/galaxy icons that are missing.
I actually managed to get those two goals done fairly quickly, so I worked on a reskin of the game. As it currently is, it looks a bit bland, not to do discredit to Tote or anything. So I spent the long weekend finalizing the redesign I've been working on since the start of GSOC. Unfortunately, any design thing I undertake tends to devour all my time and attention. I didn't think to save any in-progress shots, but here's the comparison between the current look of TP Web and the new design I plan to implement. There are still several things to address, such as the icon and the clicking menu, but I think I like the overall look.
With that, two goals are checked off. I'm a bit more ahead of schedule, but that will allow me to implement my reskin. Next week I'll work on putting the messages into a battle style format and implementing the redesign.
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 + Redesign
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
However, that unease was shortly lived, and I fell back into things soon after. I started with turning the static object types mentioned in the code (Ship, Planet, Galaxy) into a more dynamic list presented by the server. This began with modifying the backend python code because the function that constructs the JSON object data had a reference to this static object type list. However, the static object types were not as deeply ingrained in the backend code as they were in the frontend javascript code, so it was actually a simple modification.
I began working on the frontend code, and I believe the process, while somewhat more intensive, wasn't all that more difficult either. It was mostly just switching from reliance on a static object type array to using the object type name that gets sent in the JSON stream. However, this led to the realization that I would have to work on the dynamic media goal concurrently. Something to do with the css code needing it but I don't remember the specific reason.
Thus, I also went into the code to enable it to take the urls sent in the json stream and use those for icons and media images. What was difficult about this was that the image urls do not come with a image type attached to them, like png or gif. If it had, I could have just had the code in the frontend post the links as if they were images. Since that is not the case, I had to have the python backend go through each image link and test if it's a png. If that fails, it then tests if the image is a gif. This slows the code down a lot, and will need to be fixed later to find a more elegant solution, because it's really annoying.
When I had implemented this, I discovered that some image links that come from the server are not actually there. Llnz knows about this apparently, and I'm supposed to tell Mithro what images are not up there. But I haven't been on linux for the past couple of days, so never had them with me. Basically it's the universe/galaxy icons that are missing.
I actually managed to get those two goals done fairly quickly, so I worked on a reskin of the game. As it currently is, it looks a bit bland, not to do discredit to Tote or anything. So I spent the long weekend finalizing the redesign I've been working on since the start of GSOC. Unfortunately, any design thing I undertake tends to devour all my time and attention. I didn't think to save any in-progress shots, but here's the comparison between the current look of TP Web and the new design I plan to implement. There are still several things to address, such as the icon and the clicking menu, but I think I like the overall look.
With that, two goals are checked off. I'm a bit more ahead of schedule, but that will allow me to implement my reskin. Next week I'll work on putting the messages into a battle style format and implementing the redesign.
June 14th: Implement Multiple Queues
June 21st: Dynamic Object Type Support
June 28th: Dynamic Media Support
July 5th: Messages to BattleLog + Redesign
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
Tuesday, June 15, 2010
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:
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.
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.
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.
Subscribe to:
Posts (Atom)