My feeling on the matter is that the salesman script should just message you, "No energy!" and wait for more energy to be delivered instead of dying.
Hmm, I thought about that, but I would probably end up signaling once a minute, that would not be popular.
How about an option to let the salesman purchase energy when the TL or base is running low?
Logic would be: If there is less than 500 energy at base, buy a full load of energy in either the target sector or home sector when making a delivery.
Maybe the option should just be what price to purchase the energy at; you could specify 8 or less for no purchasing.
The issue with energy gets worse when you add in my Advanced Arms Dealer (I have a beta version going now). That script will jump all over the universe hunting equipment docks and factories.
Something that's a little odd, the salesman ship doesn't return the energy it started to load onto its ship if it aborts. I'm not sure your script checks to see how much is on the ship before it starts, but I can envision a problem where your sales fleet slowly picks up mountains of energy from aborted delivery runs, leaving the player scratching their head as to why they're selling so slowly.
Ups, yes it should drop the energy of an aborted run. (done in V1.1)
But when you restart the script it starts by unloading any energy on board, so there should be no long term negative effects.
My sales team completely ignored the pile of >1,800 units of Sun Flowers, because (I think) both Silicon and Ore came first on the list. Or another thought, is it because the "factory lot" of Sun Flowers is some really high number, so the script says
The script checks that the store on the TL should be large enough to fill up either the target station or the trading ship. If not, move on to next ware. So your flowers should be moved unless your trading ship (a Vulture perhaps) can hold more than 1800 flowers. Unless there is no buyers willing to pay more than average price.
An odd way to make the Vulture lift off is to load it with 200 units worth of any other good, the script will detect that the cargobay would now be filled by 1800 flowers.
So a Manta will make deal where a Dolphin would wait for more cargo.
I have a low tech version, which just sells whatever cargo is on board the trading vessel for getting rid of smaller amounts of cargo. I used that before I could afford a TL. Maybe I should release that too.
Minor grammatical errors:
Will fix those in next release. (Done in V1.1)
Which is inconvenient if you actually want to have a pile of silicon or ore in your hold
Hmm, that should be easy enough, maybe a blacklist of cargo, where you could specify up to 3 wares, someone might want to hold on to their crystals.
(Done in V1.1)
V1.1 is just uploaded at xscripting.com
Going back to OreCollect, is there any way for ships to start at different places in the "cargo list" for lack of a better word. I've been using two gatherers, and after watching them carefully for some time, it appears that they often target the same ore at the same time
I have given that a lot of thought, I have the same problem. The problem gets even worse when you use 4 auto miners at a time.
The "cargo list" is made each time a collection has been made, and will always select nearest object.
I tried selecting a starting point like the auto miner, but then you would have to restart the script in every new sector.
I also tried selecting an Auto Miner as the base of operation, but then the Ore Collector might return to base with the Auto Miner and leave uncollected ore because it is now outside its scanrange.
Maybe just selecting a random fragment among the 2 nearest, that would make the script less efficient for 1 collector but better for large scale operations. The selection between 2 fragments should make a large number of Collectors fan out in different directions.
But there would be a 50% possibility of leaving the last fragment of an asteroid and head for the next field. The fragment would be collected later but time would be wasted.
Maybe a check for other Ore Collectors nearby and going to efficient operation if none exists.
Maybe a completely random fragment if starting from the base.
Maybe ..... well ideas welcome
)
