Tuesday, August 17, 2010

Final Report Wrapup

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 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.

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.