Now that we're going this route, here's a suggestion that's based on mossfoot's idea. One might assume that a working system with multiple dockables would have all sorts of traffic between those dockables. And some patrolling too. This oxp could mimic that with it's probability calculations. There could be imaginary routes from WP to all stations that have beacons. And there could be imaginary routes from the main station to all stations with a beacon. There could be more routes of course, but I think that these would suffice for this purpose. Then traders and vipers would only be spawned when close to those routes to mimic normal trade traffic and patrolling. Pirates and occasional hunters would be spawned everywhere.
I'd still rather see this as a separate OXP.. give players the choice of being able to have without the other, if they prefer.
So a DeepSpacePirates OXP as it is (updated for 1.80)
and
a "DeepSpaceTraders" OXP based on Spara's Idea (to be created)?
I like that . I prefer several small OXP that compliment each other over a single large portmanteaux one.
So a DeepSpacePirates OXP as it is (updated for 1.80)
and
a "DeepSpaceTraders" OXP based on Spara's Idea (to be created)?
I like that . I prefer several small OXP that compliment each other over a single large portmanteaux one.
I also like this idea of separate oxps. I would just add some rare Hunters (heavy ones?) to DeepSpacePirates. DeepSpaceTraders would add some secondary space lane calculations with Traders and Vipers.
I also think adding station traffic should be a separate oxp.
Currently I calculate two routes (Wichpoint-Planet and Sun-Planet) and start adding ships on the border of these lanes. The further the player is from these lanes, the lower the chance of adding something.
A new oxp could use similar addition code, but calculate different lanes.
Problem is than the removal of ships to prevent a build up of ships when flying for a long time. When you pass a ship on the route, you would expect the ship still be there when flying back on the same route. In deep space you wouldn't expect to find the ship back in the first place.
Problem is than the removal of ships to prevent a build up of ships when flying for a long time. When you pass a ship on the route, you would expect the ship still be there when flying back on the same route. In deep space you wouldn't expect to find the ship back in the first place.
Heavily limit the number of simultaneous traders added by the oxp, while not removing them. Max limit could for example be "one ship/convoy per lane" or "TL+1 number of ships/convoys per system".
For a station-to-station adding oxp, you need traders with custom AI script that contain the destination station. Then you can add a shipDocked-handler which adds a new trader in the docking-que with a custom script to go to the station on the other side of the lane. I now realise that you do not need to remove those ships as they remove themselves by docking.
For a station-to-station adding oxp, you need traders with custom AI script that contain the destination station. Then you can add a shipDocked-handler which adds a new trader in the docking-que with a custom script to go to the station on the other side of the lane. I now realise that you do not need to remove those ships as they remove themselves by docking.
I like the sound of this. If I wasn't so busy at the moment, I would be doing this. Anyway, it could work like this:
* Make two lists of stations with beacons. One for mainstation to secondary station traffic and one for WP to secondary station traffic.
* Make a timer that periodically with some probability randomly selects a station from either of these lists and adds a ship to the station queue or makes a WS entry. Make sure that there is max one ship in one lane.
* Timer interval or spawn probability depends on the system gov making safe systems more populated.
For a station-to-station adding oxp, you need traders with custom AI script that contain the destination station.
The standard trader or shuttle AI should be sufficient - just set the destination station parameter on launch, rather than waiting for it to pick randomly.
spara wrote:
Anyway, it could work like this:
Also make sure that on initial system population an appropriate number of ships are placed mid-journey for the rate they're later added.
Also make sure that on initial system population an appropriate number of ships are placed mid-journey for the rate they're later added.
Hmm. The trouble is that the extra stations are spawned in the populator step too and I'm not really sure I can detect them when setting up the populator. Have to test a bit.
The trouble is that the extra stations are spawned in the populator step too and I'm not really sure I can detect them when setting up the populator.
If the same script does both, it's relatively straightforward - add the extra stations, then at a later priority number, add the ships between them.
If it's a different script, system.stations will give you quick access to all stations in the system. Your callback function is probably going to ignore the positions given to it, for the most part, in favour of picking a suitable station pair - since none of the predefined zones deal with extra planets anyway. So long as it has a later priority than anything which might add a station, it should be okay.
For a station-to-station adding oxp, you need traders with custom AI script that contain the destination station.
The standard trader or shuttle AI should be sufficient - just set the destination station parameter on launch, rather than waiting for it to pick randomly.
Had a quick look at this. Haven't looked at the new priority ai earlier so this is new to me. Do you mean that the existing oolite-traderAI.js can be copied and tweaked for this purpose or do you mean that I can somehow set the parameters of the ship ai on flight?
Either. Doing priorityai.setParameter("oolite_selectedStation",station) on a shuttle or trader will change its destination.
You might want to copy and modify the shuttle AI instead, though - the stock trader AI you'll have to mess with a bit to stop it leaving the system; the stock shuttle AI you'll have to mess with a bit - but not very much - to get it to consider fighting if attacked.
Either. Doing priorityai.setParameter("oolite_selectedStation",station) on a shuttle or trader will change its destination.
You might want to copy and modify the shuttle AI instead, though - the stock trader AI you'll have to mess with a bit to stop it leaving the system; the stock shuttle AI you'll have to mess with a bit - but not very much - to get it to consider fighting if attacked.
One last question and then I'll go to bed. Is it possible to set ship's ai parameters from a worldscript? I assume that the code above is to be used inside an ai script.
Sorry Eric for the thread derailment, I'll be on my way, when I get started with this one.
No problem. I was away for coding anyway. Now I have implemented the changes I intended. First test show things work as planned. Pirates are as responsive as before. Only one pirate in a group receives my old custom AI for welcoming the player and starting the attack. That seems enough.
Occasional traders etc are now also added and correctly removed again when out of view-distance of the player. I still want to do some more testing before release.
. I prefer several small OXP that compliment each other over a single large portmanteaux one.
![[EliteWiki]](/images/elitewikismall.png){kind=small}
New Cargoes