Detecting NPC launches via Javascript not possible?

[Thargoid]

Not sure if this should be a bug report or a request for a new feature. But at the moment there doesn't seem to be any way to catch an NPC launch before the ship in question is out of the dock and in flight.

For the player we have this.shipWillLaunchFromStation, but this doesn't get called in the code for NPCs (Eric kindly checked for me). this.shipLaunchedFromStation does get called, but only once the launch sequence is completed and the ship is out of the dock area (ie status goes from STATUS_LAUNCHING to STATUS_IN_FLIGHT), closely followed by this.shipSpawned. So whilst I could catch it if I could monitor this.ship.status, there is no event available to put that into I think to be active when the status is STATUS_LAUNCHING?

I'm trying to use this function for a couple of the Aquatics ships (ManOWar and Hawksbill) which are large ships but have trader roles (for the populator). This has the unfortunate effect that sometimes the station launches then, which looks very weird and usually results in the nav buoy getting trashed. Plus I know from talking to him that Eric has hit this issue before too with Dredgers.

At the moment I'm catching it with LaunchedFromStation, but it does mean for a short while the ships do appear for a few seconds before the code kicks in, which isn't the ideal solution.

[Eric Walch]

I think it should be solved different. Not by adding a trader and than removing it again by script when the selected ship is a certain big ship. I see some alternatives.

A) let the launch procedure do a dimensional check. And than don't launch the ship when the L x W of the ship is larger than the docks L x W. This would be the best on the long run. It stops any ship-launch of to big defined ships.

B) Don't give ships to big to dock a trader (or police or interceptor) role. In my opinion the trader role must be exclusively for ships that fit in a standard dock.


For B you than need an home made populating script. For one or two oxp's that is not a problem, but the ships add to the ones by the populator. When you have a lot of those oxp's installed, it can get busy in the spacelane and around the station.

Maybe we must add a special bigTrader.oxp that does nothing more than populate ships with role "bigTrader". It can even contain a bigTraderAI.plist. It contains no ships of its own. Every oxp that contain such bigTraders can include this oxp in their package. By using a single role far all bigTraders it won't get more busy when you install a lot of such ships.
Population conditions could become: system.mainPlanet.radius > xx and/or system.productivity > yy. (Both conditions that need more transportation quantities)

You can also make it dependent on an existing oxp that populates like Transports.oxp. This oxp already adds ships with role: coachwhip, liner and fuelship to the universe. Those roles are already defined as pirateVictimes so pirates act on them in the same way as normal traders.

One could include bigTrader polulating to transports.oxp when there is a good reason to populate such ships on different conditions as the current included roles. (like radius and productivity)

[Thargoid]

In Aquatics I can easily do this (it already contains a populator script to add the HammerHead). I was thinking more generically, especially for ship OXP creators who aren't so proficient in scripting that they can write a populator script.

I do like the concept of an "umbrella OXP" for adding big ships, but for me that would be better built into the trunk rather than having to keep it separately maintained. As you say, perhaps a bigTrader trunk role which works the same as trader but without the launch potential.

The idea of dimension checking I'm not keen on, as don't forget it's not actually mandatory for a station that can launch a ship to have a dock defined like that. Your method would effectively stop Lave Academy and the upcoming Aquarian HQ from launching anything, as they do docking by dock-radius rather than using a sub-ent dock.

I'll pull together a rough bigTrader OXP over the weekend, as I have all the components for it already to hand. We can then perhaps work around this, although I personally would prefer the available events were more consistent as to me that's the better route here.