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