2) If you are referring to docking clearance, then there is already in the code the handler playerRequestedDockingClearance which takes as parameter the resulting clearance status from the station.
Thanks for the changes. I think it will make carrier and station handling better scriptable.
On 2 I must look into the code if playerRequestedDockingClearance can be used but the name player suggest it is only send to the player. When I now trace a station AI I get the AI message DOCKING_REQUESTED. I can relay this to the script with a scriptMessage, but I don't know what ship did the request. A problem I noticed with the pirate_cove I worked on is that it was in defence_mode and received a stream of defence_ships that returned in a dockingAI. With a handler I could filter out the returning defence ships and give them a new assignment. But probably this can also be achieved by adding a GROUP_ATTACK message in the default dockingAI as since 1.72 these messages are send to the defence ships when issued by the station. I am testing this currently on my computer.
Not necessarily, but since we already have the shipLaunchedFromStation handler that can go in scipt.js for the player launch detection, I did not consider it a particular requirement to distinguish between player and NPCs.
Yes, it should work. In any case, the place in the code where the NPCShipLaunchedFromStation gets sent from is that part that checks and updates the ship queue for launch. Because of that, it applies only to NPCs. Making it also report player launch, will need some more work.
Doesn't shipLaunchedFromStation work for NPCs in their ship-scripts as well?
I've used it in Cataclysm, and I think it worked.
No it does not. shipLaunchedFromStation is only sent to the ship that launches. But this should be sent to the station that has a launch. Like the handler a station receives when a ship docks.
When working with custom ships you can put the stuff also in the shipscript but when you want the station to launch something like police or trader, you want that the station-script is alerted about this. E.g. to change an AI for the launching ship.
Yes, it should work. In any case, the place in the code where the NPCShipLaunchedFromStation gets sent from is that part that checks and updates the ship queue for launch.
May I humbly suggest that the two places where shipLaunchedFromStation are currently sent (one for PlayerEntity, one for ShipEntity) would be a good alternative?
A minor side issue is an appropriate name, given that shipLaunchedFromStation is already taken. For consistency, it should start with station, e.g. stationLaunchedShip.
May I humbly suggest that the two places where shipLaunchedFromStation are currently sent (one for PlayerEntity, one for ShipEntity) would be a good alternative?
A minor side issue is an appropriate name, given that shipLaunchedFromStation is already taken. For consistency, it should start with station, e.g. stationLaunchedShip.
Doesn't adding the handler in these places require that we do extra calculations to find which station we were launched from? At least for the player, dockedStation is already set to nil by that time and for the ship I am not very sure which would be the best way to get the station it launched from without scanning all entities in range.
I will try to have a better look at first chance, but right now it seems to me a much easier and well working idea to leave the ship related handler where it is now and add the player related handler at the bottom of -leaveDock: What do you think?
For the name, 100% agree. Don't know why I didn't see the conflict earlier.
Doesn't adding the handler in these places require that we do extra calculations to find which station we were launched from? At least for the player, dockedStation is already set to nil by that time and for the ship I am not very sure which would be the best way to get the station it launched from without scanning all entities in range.
Good point. From another perspective, then, is there any reason not to put it with shipWillLaunchFromStation – or, to put it differently, would a stationLaunchedShip be needed if there was a stationWillLaunchShip?
Like a system-property that contains all systems in jumprange, depending on the player's current fuel, perhaps in an array. So if(system.systemsInRange.length == 0), we know that the player is stuck. (Of course it would have to work in interstellar space as well.) The engine already does the calculation when 'H' is pressed, or when an NPC performs performHyperSpaceExit, I only don't know how difficult it is to make it available to JS.
Which brings me to another suggestion: More information about interstellar space in JS. It would be good to be able to determine where in interstellar space the player currently is. Something like system.ID, only that it contains the numbers of the two systems the player is in-between (like in the 'interstellar: galaxyNumber planetNumber planetNumber' syntax in planetinfo).
Alternatively, and perhaps even more useful, you could make the galactic co-ordinates (from 'System 7, Lave (20,173)') available as a property. If it would be read/write, and misjumps become scriptable, we could even script exactly where in interstellar space the player would end up. And a situation like in Status Quo, where Rafe Zetter's Anaconda is located at one tenth the distance between two systems IIRC, would become scriptable.
Example: before the script spawns a ship with a certain role, I want to be able to check whether any ship with that role actually exists. This way I could prevent the
SCRIPT ERROR in <anonymous actions> ***** CANNOT 'addShipsWithinRadius: my_custom_role 1 abs -32650.703125 45844.160156 423609.406250 10000.000000' (should be 'addShipsWithinRadius: role number coordinate_system x y z r')
This would enable me to spawn ships from OXPs, without creating an error if the OXP in question isn't installed. I could use this for the upcoming bigtrader.oxp, which adds the role bigtrader (instead of trader), and contains an algorithm to add ships with this role, but does not contain ships itself. It is an offer for ship designers, to use the role bigtrader for ships too big to dock. So, as long as no ships match the new role, it would produce the error message in each system.
I would find it better if pirate ships that are called as pirates by the system populator would actually get the bounty defined in shipdata.plist and not the random populator one.
I am reworking my oxp and having a look that there are no errors in that department ship by ship, and this feature really would make sense. A pirate carrier i.e. just shouldn't bring 50 measly Creds bounty.
I would find it better if pirate ships that are called as pirates by the system populator would actually get the bounty defined in shipdata.plist and not the random populator one.
I am reworking my oxp and having a look that there are no errors in that department ship by ship, and this feature really would make sense. A pirate carrier i.e. just shouldn't bring 50 measly Creds bounty.
Why not? Bounty depends on what evils he has done, not how big he is.
I asked a few people if this was possible before posting, so if it is, I'm sorry...
A way to re-define price ranges for single line items within a system / main station. So, if I wanted a poor agricultural world that (for whatever storyline reason) was paying 8cr for Food, or a Rich Industrial that was selling computers at top-dollar amounts. (Just two extreme possibilities.) I know we can do this for stations we create, but not for the system/main station.
Something that would accept what cargo it was, a mean price, a variant range, availability likelihood, mean quantity for sale (if any), variant range for quantity (if any).
