For this last week, I worked on flattening out the bugs from the tpweb program. Most of them were a lot simplier than last week, so I was able to address more of them. I won't attempt to list them all but for this session I tried more adamantly to stick to the philosophy of updating to Github after every little change, instead of dumping all the changes after a weeks time, so the full list of changes are here: (http://github.com/StupidIncarnate/tpclient-pyweb/commits/master). I will say that the philosophy of it does change things slightly in terms of work progress, in that it allows for a better reward system and thus more motivation to progress, but I still feel weird about uploading tiny changes to the svn, because inevitably I'll have to patch them, instead of uploading when a specific portion of the code is more solid.
The main changes I made, however, were dealing again with click functionality, path display, and basic order operations. I also managed to download the newly patched python libs, and though that broke things for a time, it was less of a hassle to patch than when I first took up the project.
I did manage, as well, to implement several improvements I've been intending to address. Namely, putting a load icon at several points in the program when a player submits an order, updates an order, or removes one. That way the player knows that the order was addressed, and does not have to sit there questioning while the server updates itself. I also added a color coding system that distinguishes owned objects, ie green for ally objects and red for enemy ones. It seems to clear up some confusion while playing as to what objects are under a player's control.
Since this is the last post, I suppose I should address my progress overall throughout the program. In terms of my proposal, I did manage to cover all the main points that I had planned to address, those being support of the tp04 standard and several gui improvements. I also managed to implement several other changes that were not proposed, such as the redesign of the gui look and several other minor tweaks to make playing more efficient. The only thing that I regret is not having time to address the design panel for mtsec and cache support that was reimplemented during this last week. So I'll have to deal with those after the program. But other than that, I suppose I accomplished much, though I feel relieved that the program is over rather than any sort of accomplishment toward my achievements. But that's just how I am. It was the same for college.
Tuesday, August 17, 2010
Tuesday, August 10, 2010
Week Eleven Report
I worked a lot on the clicking functionality for the gui this week, trying to balance out the program so that one change would not instantly break it. That basically involved simplifying the code so that there was less to obstruct the flow of logic.
I first fixed the right-click menu when a player clicks an object on the system planet panel. Before, the code was sending the specific div name of where to place the order's menu. However, since there's three places the menu can appear, the code had to be changed so that the parent element of the clicked object would be where the order menu is created in.
There was an issue with the drawing of the object path where once a ship left the system, it would no longer draw the path. So that was fixed.
I simplified the rollover functionality for a map object. Before, it had a variable switch that was enacted when the mouse entered the children panel of that object. However, a bit of the rollover code changed a bit so this was no longer necessary to have and merely complicated things further.
There was also an issue with the rollover functionality when an order was submitted. This was because the code was redrawing the objects on the map (in case paths or what not changed), but it wasn't reimplementing the css event handlers for the map objects, leading to the failure of rollover functionality. So this event handler code had to be put in its own function so it could be called from multiple places.
A small change was also made to the info panel close button. I think it's a bit faster now.
After all this, a new bug showed up that launched the info panel whenever an object was right-clicked. For some reason, Jquery's left/right clicking events seem to jumble and confuse themselves when fired. I ultimately had to change most of the live events that can be defined before an object is created, to more standard binding where the object has to be in the DOM structure for the event handler to apply. It seemed to clear up some of the bugginess with the clicking, but it still didn't clear up this issue. In order to do that, I had to have the code disable clicking for an object that gets right-clicked until the order menu is closed.
Looks like this is the last week, so I'll be playing matches to find any more bugs hidden in the functionality.
I first fixed the right-click menu when a player clicks an object on the system planet panel. Before, the code was sending the specific div name of where to place the order's menu. However, since there's three places the menu can appear, the code had to be changed so that the parent element of the clicked object would be where the order menu is created in.
There was an issue with the drawing of the object path where once a ship left the system, it would no longer draw the path. So that was fixed.
I simplified the rollover functionality for a map object. Before, it had a variable switch that was enacted when the mouse entered the children panel of that object. However, a bit of the rollover code changed a bit so this was no longer necessary to have and merely complicated things further.
There was also an issue with the rollover functionality when an order was submitted. This was because the code was redrawing the objects on the map (in case paths or what not changed), but it wasn't reimplementing the css event handlers for the map objects, leading to the failure of rollover functionality. So this event handler code had to be put in its own function so it could be called from multiple places.
A small change was also made to the info panel close button. I think it's a bit faster now.
After all this, a new bug showed up that launched the info panel whenever an object was right-clicked. For some reason, Jquery's left/right clicking events seem to jumble and confuse themselves when fired. I ultimately had to change most of the live events that can be defined before an object is created, to more standard binding where the object has to be in the DOM structure for the event handler to apply. It seemed to clear up some of the bugginess with the clicking, but it still didn't clear up this issue. In order to do that, I had to have the code disable clicking for an object that gets right-clicked until the order menu is closed.
Looks like this is the last week, so I'll be playing matches to find any more bugs hidden in the functionality.
Tuesday, August 3, 2010
Week Ten Report
I finally found an elegant solution to the coordinate to pixel conversion and vice-verse. When the program gets the list of objects, it takes the coordinate point that's the biggest, whether it be x or y, negative or positive, and determines how many digits it has using the browser height as the constraint modifier. That makes an easy variable to multiply/divide by to transition between space and pixel coordinate.
With that fixed, I worked on getting the trajectory of moving objects to display. Apparently Javascript doesn't have inherent drawing capabilities, so I had to go through several packages till I found one easy enough to manipulate, since the drawing is basic line geometry. If I do get time, it will also allow me to put some animation on the clicking so that it's more satisfying when a player specifies a destination for an object. There was a bit of confuddling with more of the pixel/space coordinate relationship, and whether the player clicks the map or a map object, but I think it's pretty much sorted.
In doing this, I found that I never actually positioned the objects over their coordinate, so that the images were ending up shifted down and to the right. This also led to the discovery that the width modifiers for map objects were doing funky things and that was adding to the buggyness of the rollover functionality. Ultimately I had to have the program change the widths whenever a rollover/rollout is initiated.
The click-tracking functionality is still a bit buggy, so I put a close button on the information panel. It's a bit of a hassle compared to being able to click anywhere to get rid of said panel, but until all the bugs are out that's the best solution.
I started applying the right-click functionality to the objects on the planetary system panel and the ships on the map that aren't children of anything, but there still seems to be problems with that.
So this next week is more bug testing. I think there's also some sort of bug that destroys the positions of all objects when I ship arrives at its destination, but haven't had time to address it yet.
With that fixed, I worked on getting the trajectory of moving objects to display. Apparently Javascript doesn't have inherent drawing capabilities, so I had to go through several packages till I found one easy enough to manipulate, since the drawing is basic line geometry. If I do get time, it will also allow me to put some animation on the clicking so that it's more satisfying when a player specifies a destination for an object. There was a bit of confuddling with more of the pixel/space coordinate relationship, and whether the player clicks the map or a map object, but I think it's pretty much sorted.
In doing this, I found that I never actually positioned the objects over their coordinate, so that the images were ending up shifted down and to the right. This also led to the discovery that the width modifiers for map objects were doing funky things and that was adding to the buggyness of the rollover functionality. Ultimately I had to have the program change the widths whenever a rollover/rollout is initiated.
The click-tracking functionality is still a bit buggy, so I put a close button on the information panel. It's a bit of a hassle compared to being able to click anywhere to get rid of said panel, but until all the bugs are out that's the best solution.
I started applying the right-click functionality to the objects on the planetary system panel and the ships on the map that aren't children of anything, but there still seems to be problems with that.
So this next week is more bug testing. I think there's also some sort of bug that destroys the positions of all objects when I ship arrives at its destination, but haven't had time to address it yet.
Tuesday, July 27, 2010
Week Nine Report
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.
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 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.
Sunday, June 13, 2010
Week Two + Some Extra Report
Bah, so plans never go as planned. This is not the "milestone overcome" sort of post it's supposed to be, but it does tie in with what I'm supposed to do next. And it was getting absurdly overdue.
This last week plus a couple days, I've been focused on fixing the final issues with tpweb so that it could support the tp04 standard. This last "issue", which immenesified the further I attempted to eradicate it, was the order manipulation functionality. As one issue was solved, so another took its place, and the amount of code rewriting that I've done is abundant. However, here are some of the issues that have since impeded me.
Figuring out how the order structure changed was very difficult as I don't know anywhere that listed specifically the new structures, such as submitting a position change order. The nesting seems to have changed, and I'm not sure what the reasoning behind it was. For example, a move order looks like this: [[[0,0,0]]]. Another weird thing is that the code submits dummy orders and then updates those orders once the player has decided on the specifics. The apparent problem with this is if they submit a dummy order and their turn ends before specifying those details, the order is a waste. Another change to the data structure, which took a lot of time and figuring to get correct was the build order, which changed the inner most container to a tuple. It looks like this:
[0, 10, -1, 2, 0, [], [[(1, u'Scout', 100), (2, u'Frigate', 100), (3, u'Battleship', 100)], [[1, 1]]], [0,"A Fleet"]] Null_000 was very helpful in helping me out, and now that I have internet at home, maybe my time can be spent on actual programming and not research.
The cache has been giving me problems again as well since it was converted to a variable that remains in memory as opposed to storing it in a pickled file. There's some sort of issue that's arising between calls to the python backend.
Since the orders have been separated from the objects in cache, it uses a separate id to point to an object's order queue. Both the javascript and python sides had to be thus changed in order to handle this, and it took some effort to harmonize the two coding sets.
In terms of progress, the basic functionality for dealing with orders has been fixed. Again, I'm still having an issue with the cache (something to do with the incompatibility between threads), but it appears that orders can now be sent, updated, and removed. In order to continue working on this cache issue, as well as make some progress on my milestone goals, I'm going to change the schedule a bit. I was slotted to work on implementing the dynamic media capabilities (have the objects retrieve their icons from a repository rather than having their locations hard-coded into the javascript) but I think I'll work on modifying the code to handle multiple order queues that the tp04 standard supports. Since I've been working with queue manipulation for the past week, it should make it somewhat easier to accomplish this within a small time frame. I shall make another blog post in a few days to reflect the progress I've made and get back on schedule, now that I can hole myself in my room for however long I need.
This last week plus a couple days, I've been focused on fixing the final issues with tpweb so that it could support the tp04 standard. This last "issue", which immenesified the further I attempted to eradicate it, was the order manipulation functionality. As one issue was solved, so another took its place, and the amount of code rewriting that I've done is abundant. However, here are some of the issues that have since impeded me.
Figuring out how the order structure changed was very difficult as I don't know anywhere that listed specifically the new structures, such as submitting a position change order. The nesting seems to have changed, and I'm not sure what the reasoning behind it was. For example, a move order looks like this: [[[0,0,0]]]. Another weird thing is that the code submits dummy orders and then updates those orders once the player has decided on the specifics. The apparent problem with this is if they submit a dummy order and their turn ends before specifying those details, the order is a waste. Another change to the data structure, which took a lot of time and figuring to get correct was the build order, which changed the inner most container to a tuple. It looks like this:
[0, 10, -1, 2, 0, [], [[(1, u'Scout', 100), (2, u'Frigate', 100), (3, u'Battleship', 100)], [[1, 1]]], [0,"A Fleet"]] Null_000 was very helpful in helping me out, and now that I have internet at home, maybe my time can be spent on actual programming and not research.
The cache has been giving me problems again as well since it was converted to a variable that remains in memory as opposed to storing it in a pickled file. There's some sort of issue that's arising between calls to the python backend.
Since the orders have been separated from the objects in cache, it uses a separate id to point to an object's order queue. Both the javascript and python sides had to be thus changed in order to handle this, and it took some effort to harmonize the two coding sets.
In terms of progress, the basic functionality for dealing with orders has been fixed. Again, I'm still having an issue with the cache (something to do with the incompatibility between threads), but it appears that orders can now be sent, updated, and removed. In order to continue working on this cache issue, as well as make some progress on my milestone goals, I'm going to change the schedule a bit. I was slotted to work on implementing the dynamic media capabilities (have the objects retrieve their icons from a repository rather than having their locations hard-coded into the javascript) but I think I'll work on modifying the code to handle multiple order queues that the tp04 standard supports. Since I've been working with queue manipulation for the past week, it should make it somewhat easier to accomplish this within a small time frame. I shall make another blog post in a few days to reflect the progress I've made and get back on schedule, now that I can hole myself in my room for however long I need.
Tuesday, June 1, 2010
Week One Report
Since the week has been a flurry of being pulled hither and thither by coding and school, I haven't really kept a detailed list of bugs I ran into, since there were a lot of issues which were mostly due to my misunderstanding of the structure of the Thousand Parsec code. What has arisen from my coding binges over the past week is that Tpweb launches under tp04 libraries without any impedance and displays most of the information it must. The object panel, which displays object information when selected, does need to parse several pieces of data differently because the array of data it receives has changed, however, this can be dealt with later since I'll be moving that information to another dialog.
The issue that still impedes tpweb from running fully under the tp04 standard is the orders functionality. As of this moment, I've hit a wall that I need to talk to mithro about, as it appears to me that one of the functions involved in sending orders to the server might be outdated. Otherwise, I'm simply misunderstanding the code yet again.
Mentionable Issues:
The first major issue I faced in getting tpweb running under the tp04 standard was the issue with the cache. Apparently the cache used to be pickled, but with the inclusion of dynamic objects in the tp04 standard, this makes pickling throw errors. It took a lot of time to actually track down that issue, and five minutes talking with Mithro to confirm it, but it enabled me more understanding of the code and how the cache is created. From there, I simply had the backend python code store the cache in a global variable which will suffice for now. In doing this, there are two new functions added to the backend middleman method that deal with this local version of the cache.
Another issue with fixing up tpweb was understanding and taking command of the modified structures of an object's properties. A lot of information has been moved into nests of general parent headers, such as position and velocity within a parent header of Positional. Initially, I thought I could just use Greywhind's getPositionList function in the objectutils file, however, that would be ill-equipped to parse the rest of the nested data. After several rewrites, I managed to produce a recursive function (posted at end of this post) which converts all the properties of an object into a nested dictionary so that the javascript portion of tpweb can handle the data. I also ended up creating a recursive search function for it as well, since the order's functionality requires the queueid nestled within the objects property.
In dealing with these troublesome data structures, I discovered where the turn counter was stored. In tp03, it was apparently stored in a shallow dictionary within object[0] (the universe), however it is now stored in the
Another sub issue I had was dealing with positional data of the objects, since that is necessary element in an object's visual quality. The structure of the Position property is:
A bit elaborate for my tastes, and it required some condensing for easier insertion into the javascript framework. I spent some time on the best way to condense it, but this was still while I was thinking I could use the getPositionList function. It became obvious that I would need a more robust function and so my attention and time was directed at that.
An aside: I found an error in the getPositionList when it deals with relative positioning of objects. When it would get to this section of the code, it would call get_position_list, which was the old name for this function, and thus cause it to fail. I submitted the corrected file to github, but since I fail utterly with git, it may not be up there or may have been deleted.
I believe I had some issue with the Universe size as well, but this may have been what finally forced me to write the recursive function to parse an object's property data.
Before the client would even display, the get orders function would also have to be addressed as well. When I would output what was stored in the cache, it showed a collection of only four order queues which I thought was strange considering the collection of objects had a total of ten or so queues in their properties. Thus, I went on a maddening chase to insure that the function which constructs an object's order's queue was not somehow malfunctioning.
It was not however, which led to the next maddening quandary as to why the order's queueid's listed 0, 11, 12, 13, 14 when my planet and ships were ids 20, 21, 22, 23. Id 11 was an uninhabited planet, so there was no way it could or should have an order's queue. Upon looking at the massive data log I had in front of me for an hour or two and trying many different things to figure out the cause of this mismatch, I realized that the queueid was actually distinct from the object's id and that the object had stored in it a reference to its queue id. With that settled, the client magically displayed.
I had up to this point commented out the types of orders that would get sent to the browser, since the constraints it initially relied on had been changed into another confounding data structure in parameters. Once tpweb did finally display in the browser, reimplementing these were not as difficult since Greywhind had listed on his blog how to deal with them. In theory, by fixing that, the client should now be able to display orders, but since I have yet to get the submit orders functionality working, that theory is likely only half-baked.
Submit orders, remove orders, and update orders still need to be addressed before tpweb can return to normal functionality. So those are the things I'll be focusing on this week, because they need to be finished by next weekend if I am to stay on schedule. But, I am also done with school next Monday, so I can do more coding binges if it becomes trickier than I'm thinking it will be. Just have to figure out why the orders are not sending to the server.
As an aside: queue is most evil a word.
The issue that still impedes tpweb from running fully under the tp04 standard is the orders functionality. As of this moment, I've hit a wall that I need to talk to mithro about, as it appears to me that one of the functions involved in sending orders to the server might be outdated. Otherwise, I'm simply misunderstanding the code yet again.
Mentionable Issues:
The first major issue I faced in getting tpweb running under the tp04 standard was the issue with the cache. Apparently the cache used to be pickled, but with the inclusion of dynamic objects in the tp04 standard, this makes pickling throw errors. It took a lot of time to actually track down that issue, and five minutes talking with Mithro to confirm it, but it enabled me more understanding of the code and how the cache is created. From there, I simply had the backend python code store the cache in a global variable which will suffice for now. In doing this, there are two new functions added to the backend middleman method that deal with this local version of the cache.
Another issue with fixing up tpweb was understanding and taking command of the modified structures of an object's properties. A lot of information has been moved into nests of general parent headers, such as position and velocity within a parent header of Positional. Initially, I thought I could just use Greywhind's getPositionList function in the objectutils file, however, that would be ill-equipped to parse the rest of the nested data. After several rewrites, I managed to produce a recursive function (posted at end of this post) which converts all the properties of an object into a nested dictionary so that the javascript portion of tpweb can handle the data. I also ended up creating a recursive search function for it as well, since the order's functionality requires the queueid nestled within the objects property.
In dealing with these troublesome data structures, I discovered where the turn counter was stored. In tp03, it was apparently stored in a shallow dictionary within object[0] (the universe), however it is now stored in the
object[0].__Informational.Year.value position of the universe object.Another sub issue I had was dealing with positional data of the objects, since that is necessary element in an object's visual quality. The structure of the Position property is:
'__Positional': [Position: [vector: [x(q): 0, y(q): 0, z(q): 0], relative(I): 0]A bit elaborate for my tastes, and it required some condensing for easier insertion into the javascript framework. I spent some time on the best way to condense it, but this was still while I was thinking I could use the getPositionList function. It became obvious that I would need a more robust function and so my attention and time was directed at that.
An aside: I found an error in the getPositionList when it deals with relative positioning of objects. When it would get to this section of the code, it would call get_position_list, which was the old name for this function, and thus cause it to fail. I submitted the corrected file to github, but since I fail utterly with git, it may not be up there or may have been deleted.
I believe I had some issue with the Universe size as well, but this may have been what finally forced me to write the recursive function to parse an object's property data.
Before the client would even display, the get orders function would also have to be addressed as well. When I would output what was stored in the cache, it showed a collection of only four order queues which I thought was strange considering the collection of objects had a total of ten or so queues in their properties. Thus, I went on a maddening chase to insure that the function which constructs an object's order's queue was not somehow malfunctioning.
It was not however, which led to the next maddening quandary as to why the order's queueid's listed 0, 11, 12, 13, 14 when my planet and ships were ids 20, 21, 22, 23. Id 11 was an uninhabited planet, so there was no way it could or should have an order's queue. Upon looking at the massive data log I had in front of me for an hour or two and trying many different things to figure out the cause of this mismatch, I realized that the queueid was actually distinct from the object's id and that the object had stored in it a reference to its queue id. With that settled, the client magically displayed.
I had up to this point commented out the types of orders that would get sent to the browser, since the constraints it initially relied on had been changed into another confounding data structure in parameters. Once tpweb did finally display in the browser, reimplementing these were not as difficult since Greywhind had listed on his blog how to deal with them. In theory, by fixing that, the client should now be able to display orders, but since I have yet to get the submit orders functionality working, that theory is likely only half-baked.
Submit orders, remove orders, and update orders still need to be addressed before tpweb can return to normal functionality. So those are the things I'll be focusing on this week, because they need to be finished by next weekend if I am to stay on schedule. But, I am also done with school next Monday, so I can do more coding binges if it becomes trickier than I'm thinking it will be. Just have to figure out why the orders are not sending to the server.
As an aside: queue is most evil a word.
def getPropertyList(obj):
"""
Examines an objects properties structure and outputs a nested dict of the entire thing for use
by the javascript portion of tpweb
Referenced from Greywhind's getPositionList function in objectutils
"""
propertieslist = {}
variable_list = {}
for propertygroup in obj.properties:
if type(propertygroup) != Structures.GroupStructure:
continue
for property in propertygroup.structures: #Position
property_list = getattr(obj, propertygroup.name) #Gets Positional List
def propertyparselist(property, property_list):
"""Todo: Relative Position/Vector needs to be accounted for"""
vardict = {}
subvardict = {}
if property.__dict__.has_key('structures'): #Is group sturcture
subproperty_list = getattr(property_list, property.name) #Gets Position list
for subproperty in property.structures:
subvardict.update(propertyparselist(subproperty, subproperty_list))
if(len(subvardict) > 0):
vardict[safestr(property.name)] = subvardict
else:
if type(property_list) == Structures.ListStructure.ListProxy:
for key, value in enumerate(property_list):
vardict[key] = value
elif type(property_list) == Structures.GroupStructure.GroupProxy:
vardict[safestr(property.name)] = safestr(getattr(property_list, property.name))
else:
print property
print type(property)
print property_list
print type(property_list)
print "===================="
return vardict
propertieslist.update(propertyparselist(property, property_list))
return propertieslist
def searchPropertyList(propertylist, attribute, found=False):
# print "Find this attribute: ", attribute
# print "Propertylist incoming: ", propertylist
# print type(propertylist)
if type(propertylist) == type(dict()) and len(propertylist) > 0:
for keys in propertylist.keys():
if keys == attribute:
return propertylist[keys], True
else:
propertyl, found = searchPropertyList(propertylist[keys], attribute)
if found:
return propertyl, True
return None, False
Tuesday, May 25, 2010
GSOC Commences
This post covers two things, the project outline which deals with what the GSOC period will be spent trying to accomplish, and the current state of tpweb(the tpclient-pyweb browser client for the Thousand Parsec game).
Primary Objective - TP04 Support
Functionality Upgrade to TP04 Standard
This involves modifying the current tpweb code so that the basic code functionality can work with the new tp04 standard.
Dynamic Object Types
This involves removing all instances of hard-coded object types so that dynamic object types can be used.
Multiple Order Queues
This will involve expanding the Order issue functionality to support the ability to submit several orders at once.
Messages to battle log style
This will change the current inbox style messages in the game to a more condensed form for easier digestion.
Object information panel to rollover item
This will change the object panel to a rollover menu when the mouse rolls over objects on the game board, such as planets and ships and whatnot.
Trajectory display of moving objects
This will draw the trajectory of traveling objects onto the game board.
Condensed menu items
This will move some of the menu items such as logout and download map, into a dropdown menu.
Order’s panel to intuitive right-clickable menu
This will implement a new style of issuing commands that differs from the standard order's dialog.
Orders: Displaying, Sending, Removing, Updating
Objects: Positioning, Velocity, Damage, Ships
Turn: Retrieve Current Turn
The days leading up to next Monday will be spent fixing these remaining issues and by that time, the client should be in basic working order so that new features can be added, such as media downloading.
Project Abstract
The focus of this project is to improve upon the tpclient-pyweb version of the Thousand Parsec game. In order to accomplish this goal, there will be two main objectives to complete. Under each objective, there are several “todo” items that must be completed in order to accomplish each objective.Primary Objective - TP04 Support
- Functionality Upgrade to TP04 Standard
- Dynamic Object Types
- Multiple Order Queue
- Messages to battle log style
- Object information panel to rollover item
- Trajectory display of moving objects
- Condensed menu items
- Order’s panel to intuitive right-clickable menu
Functionality Upgrade to TP04 Standard
This involves modifying the current tpweb code so that the basic code functionality can work with the new tp04 standard.
Dynamic Object Types
This involves removing all instances of hard-coded object types so that dynamic object types can be used.
Multiple Order Queues
This will involve expanding the Order issue functionality to support the ability to submit several orders at once.
Messages to battle log style
This will change the current inbox style messages in the game to a more condensed form for easier digestion.
Object information panel to rollover item
This will change the object panel to a rollover menu when the mouse rolls over objects on the game board, such as planets and ships and whatnot.
Trajectory display of moving objects
This will draw the trajectory of traveling objects onto the game board.
Condensed menu items
This will move some of the menu items such as logout and download map, into a dropdown menu.
Order’s panel to intuitive right-clickable menu
This will implement a new style of issuing commands that differs from the standard order's dialog.
Timeline
May - Primary Objective
- May 31: The client will be capable of basic functionality using the TP04 libs.
June
- June 7: The ObjectComponentClass will call the proper css object icon without relying on hard-coded object types within the javascript.
- June 14: The client will use generated css code to call a specific icon for an object.
- June 21: The client will be capable of displaying multiple orders.
- June 28: The client will be capable of submitting multiple orders.
July - Secondary Objective
- July 5: Messages will be displayed in a battle log format.
- July 12: The object information panel will display next to the object as a rollover panel.
Mid-Term: The First Objective will be met by the time of the mid-term period.
- July 19: The client will be capable of displaying the trajectory of each object that is directed at a target.
- July 26: Orders will be displayed in the rollover information panel. The orders will also be deleteable and their order position will be changeable.
August
- August 2: Orders that require a target will be issuable from the right-click order’s menu.
- August 9: Orders that require build information will be issuable from the right-click order’s menu.
- August 16: This week will be left for bug-hunting and optimization of the search function.
Current State of Tpweb
Currently, most of the functionality for the backend of tpweb has been modified to the TP04 standard, so that it can retrieve all the data it needs and display the game board. The following still needs some functionality changes to adhere to the modified format/locations of data before tpweb can return to normal functionality under the TP04 standard.Orders: Displaying, Sending, Removing, Updating
Objects: Positioning, Velocity, Damage, Ships
Turn: Retrieve Current Turn
The days leading up to next Monday will be spent fixing these remaining issues and by that time, the client should be in basic working order so that new features can be added, such as media downloading.
Monday, May 24, 2010
Precursor Part 2 through GSOC official program commencemnent date (Ie working well into the start of May 24th with coffee buff about to wear off)
On the quest for barebones tp04 support, as of 5 am, the multiple cache issues are basically sorted, as is the get_objects function. This refers to only the fact that errors no longer arise when the backend is trying to download these. There are, however, a couple attributes in the objects construction part of the backend that have to be dealt with differently for tp04, such as Ships, Velocity, Damage. It looks like Position and Resources are properly applied though. It does look like the web browser is at least able to parse through the data for objects and load them to the right hand panel.
More bashing on and confuddling with the tpweb code this week to make it support tp04 (in conjunction with final project for school) but hopefully by the end of Sunday night, tpweb will be able to at least show all the objects/orders in the browser using the tp04 versions of the libs. Right now, it's chocking on the orders and won't display the gameboard.
More bashing on and confuddling with the tpweb code this week to make it support tp04 (in conjunction with final project for school) but hopefully by the end of Sunday night, tpweb will be able to at least show all the objects/orders in the browser using the tp04 versions of the libs. Right now, it's chocking on the orders and won't display the gameboard.
Monday, May 10, 2010
Precursor Part 1ish
I began looking over the code for both libtpproto-py and libtpclient to get an idea of how it's going to apply to the changes I'm making to Tpweb (tpclient-pyweb). It's somewhat explanatory for the most part, though it appears that I need the version that supports tp04. Oh the breakage that will surely happen when tpweb tries to use the libs that run with version 4 of the protocol. Still some questions for Mithro.
While most of the weekend was spent digging through the lib codes, there were several changes I made to Tpweb's code:
Included functionality that now draws any stray object in the universe onto the map that isn't a child of any planetary system.
Added object names to the icons on the map so finding stuff's a bit easier.
Finished the popup panel that displays all the objects within that system. Necessary if that annoying right panel is going to be axed.
Still need to figure out how to streamline the javascript css stuff and how I'm gonna retool the look.
While most of the weekend was spent digging through the lib codes, there were several changes I made to Tpweb's code:
Included functionality that now draws any stray object in the universe onto the map that isn't a child of any planetary system.
Added object names to the icons on the map so finding stuff's a bit easier.
Finished the popup panel that displays all the objects within that system. Necessary if that annoying right panel is going to be axed.
Still need to figure out how to streamline the javascript css stuff and how I'm gonna retool the look.
Subscribe to:
Posts (Atom)