One small thought that could be a useful extension, if we can not only read missile slots as equipment, but perhaps if awarding equipment to specify which slot it gets awarded to (rather than just the first available).
Thought behind this is that we can then have "proper" pylon mounted re-usable equipment without it wandering all over the pylon mounts. For example on my Missile Rack OXP, as that is basically used and re-awarded with a lower amount of mini-missiles, if it's fired from (for example) pylon 3, when it's re-awarded again it goes back to an earlier pylon if one is available. Only cosmetic I know, but can get a little weird. If we could make a note of which pylon it was on originally (do-able by your code above, although a ship.activePylon (or ship.missileActive or somesuch if you want name consistency) listing which pylon is currently selected might also be useful there) would make it look much better.
Thought behind this is that we can then have "proper" pylon mounted re-usable equipment without it wandering all over the pylon mounts. For example on my Missile Rack OXP, as that is basically used and re-awarded with a lower amount of mini-missiles, if it's fired from (for example) pylon 3, when it's re-awarded again it goes back to an earlier pylon if one is available. Only cosmetic I know, but can get a little weird.
I agree strongly with this. I'd like to have a certain weapon always on a certain pylon.
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
Is there any reason why the pylon mounted weapons cannot stay where they are? Added weapons can then fill the empty spaces.
Currently the save file only lists the missile types of the player in the order he has them. If the player fires a missile, that slot is empty, thus after save/reload, the remaining missiles fill that slot and leave empty space at the end.
Looks like it would require some "SLOT_EMPTY" info as a placeholder in order to survive load/save.
I am wondering why missileCapacity is inconsistant across different ships, when missiles seems to be the more appropriate method to use for both player ships and NPC ships as well.
missileCapacity is provided as an extra way for OXPs to find out if they can actually award missile type equipment to the player. If an OXP maker wants more missiles on a particular NPC ship, they can simply create a like_ship with more missiles on board to begin with. But there are some 'features' associated to NPC missiles that might require some code tweaking. If we do that, missileCapacity might well start to be different to missiles.length on NPCs too. Quite a few of these properties are generic, to allow us to add to the game engine without having to change the api.
Pylon positioning: suggestions welcome (on the suggestions board please), will see what's practical/doable!
This is something that I wanted to do for a very long time. Finally, it's in trunk.
This is the Advanced Nav Array as we have known it up to now. It shows the least number of jumps route to destination when you press Shift+6 (^):
This is fine, but for contracts where delivery time matters it is maybe not enough. Well, as of the upcoming 1.74, we will be able to display the time-optimized route to destination on the Advanced Nav Array by pressing also Control at the same time as ^. In the example above, pressing control will switch to time-optimized route and display this:
This should complete the functionality of the Nav Array for now and enable truly efficient route planning, as advertised in the shipyard screen.
The colours for the hyperspace jump tunnel can now be changed using the new hyperspace_tunnel_color_1 and hyperspace_tunnel_color_2 keys inside planetinfo.plist
If neither key is present, the hyperspace tunnel will look identical to the docking one.
At the moment, trunk's hyperspace tunnel colours are off-white/blue, (as opposed to pink/blue) - to do that, only one colour redefinition is needed:
.
