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.
Subscribe to:
Posts (Atom)