GSOC Day 6 – Can that object move?
I began today’s work by making a small change to icon drawing for the starmap, just adding lines between each coordinate of an object with multiple coordinates.
Then, I began to work on a problem that seemed relatively simple at first: the client needs to either enable or disable the “waypoints” button depending on whether the selected object can move or not. As it turned out, this was not as easy as it seemed.
The problem is that there’s no direct way to tell if an object can move – you have to look at its orders and find one that represents movement. Orders, however, don’t have information about how they’re interpreted, only what parameters they need. So the parameters for a movement order are just a position in space, and that could mean a number of things.
For example, an object could have the ability to “throw” something at a location in space. The object itself isn’t moving, and the thrown projectile has no propulsion of its own, so waypoints make no sense. The order, however, has a coordinate in space as a parameter, so it looks to the client like a movement order. Voila, waypoint button activated, even though it has no purpose.
This is the problem with real dynamic construction – if you want concrete detection of functionality, it makes that almost impossible, depending on what the dynamic construction looks like. In this case, the user will need to sort out whether the waypoint mode makes sense. We’ll try to make that easier in the future, but in itself, that may prove difficult.
I have the feeling a lot of these underspecified cases will appear in the coming months, and it may leave the client unable to deal with certain special situations in the best possible manner. I’ll have to work hard to come up with creative solutions that will minimize these problems.
I also started thinking today about how the starmap can deal with any type of object, and I’m convinced that it needs to allow objects to specify their own images to draw. This can be done with the media functionality that is currently in place, but it will take some code to get working. Also, the images to draw will need to be very small – almost unrecognizable – if they are to fit with the current icons. I think it’s the only way to allow objects to draw themselves and avoid the same type of ambiguity and auto-detection that I had to deal with for today’s patch, though. It’ll take some work to get it right, so I’ll start on it soon.
Tomorrow, I might warm up for that change on the Pictures panel, which needs to be able to get self-specified pictures in a similar fashion. The difference is that it already has the infrastructure in place, for the most part.
The other option would be to start getting orders working. I’ll decide tomorrow which one to prioritize.