[SCR] OK Traders v1.7.1 (04-12-14)

[Shimrod]

Minor note: When I updated my v1.1 OK Traders to v1.2, their previous "No Trade" orders changed to "Sell". However, after I reset them, their orders seem to "stick".

From 1.1 the cmd script saves the 'Ware.Entries' originally passed from the menu when the command was started into a local variable. When opening the menu again while the command is running, it can only display the original settings if this was v1.1 data. Otherwise the menu acts as before and offers up the default values, and restarts the command script rather than just poking in the updated settings into the existing entries.

Since the 'Ware.Entries' values are never modified outside of the menu, this suggests in highest probability that the trader was running version 1.0 and the script hadn't restarted itself to 1.1. Note that a restart only occurs after an action completes.

There's also of course an equally high probability that my code has a bug in it, so I'll keep an eye out

[Marvin Martian]

i use this Traders on an small complex that produces only energy cells, since the upgrade to 1.2.0 the (sell) traders stop there work with a amount of always 750 cell in the cargo bay

on other homebases it works fine, but there they don't sells energy cells

[Shimrod]

The 750 in cargo bay is probably reserve jumpdrive energy. Also note that since 1.1 there's a configurable 10% stock threshold before ships will sell.

I'll investigate this as soon as I get time, hopefully this evening. I'm already testing a 1.2.1 patch release; 1.2 included some major changes.

Update

I have a fix for a bug where if homebased traders aren't in their homebase when they decide to perform a trade mission, they wouldn't return home to load the ware but just stay put wherever they are.

This was introduced in 1.2 where the sell ware operation was decomposed into separate 'move to station' and 'sell ware' steps, in order to be able to track profits, which isn't exposed from the vanilla sell.ware script. I neglected to include a step to return to homebase and load the ware first.

With the fix in place the trader returned to the SPP, loaded the energy cells, and went off to sell them.

I'll get the 1.2.1 patch release uploaded with this and other fixes I've been working on with my AP based testing. However its not entirely clear to me if this matches the symptoms you have, so do let me know if there's some other issue.

[Shimrod]

I've uploaded a bugfix release 1.2.1, cleaning up known issues with 1.2.0. Apologies for the bumpy ride there, adding in the free trading changed a lot of code, and my XTC based test scenario didn't uncover this.

On a positive note I've started an AP vanilla game pottering around in a disco with OK Trade running on the mercury. It works great and it's making good money: 4h 30m game time traded up from 10k to 520k + jumpdrive, though I did accidentally pimp it out to the max 4k cargo space at the start, overzealous equipping in the custom start stage. I haven't had to touch it, except restarting the command to patch in fixes I was working on.

Based on this experience I decided to add a little functionality to make the free trader go buy itself a jumpdrive once the player can afford it. This way I could top up on more TS when my rep is up, though still manually outfitting with tunings on purchase, and not have to handhold the ship into terracorp HQ or otas HQ to get jumpdrives.

1.2.1
- Free traders will buy a jumpdrive if they don't have one already.
- Preserve free trader's profit tracking balance between command restarts. This primarily avoids resetting to 0 on upgrade.
- Fix attempting to buy a ware if there are insufficient funds to buy 1 unit.
- Fix docks not being taken into account when searching for a station to buy a ware at
- Fix a bug in infinite ware buying detection (introduced 1.2.0)
- Fix selling of wares to infinite buyers not awarding reputation
- Fix a bug where homebase traders would not return to homebase in order to load the ware for a sale mission (introduced 1.2.0)

Note that when I talk about infinite buyers, this is in the context of XTC docks which hold at 50% stock indefinitely. It's been so long since I played vanilla AP or XRM that I don't recall if such functionality exists in the vanilla game, or if perhaps vanilla docks lazily update periodically. Certainly the EQ dock in three worlds wasn't buying infinite mosquitoes when I tested it.

Finally, be aware that the script will only restart to upgrade itself when the current action is complete, as it blocks while the move operations are underway and can't check for version upgrades. I'm planning to add local state upgrade logic so the command script can be more immediately restarted by the monitor task without disrupting the active mission, but that's a bigger change and can wait a bit.

[Shimrod]

I uncovered another 1.2.0 regression that might also have been a contributing factor to Marvin's problem. Manifested 5h30m into my current AP game, again my apologies for the turbulence. I'll have words with my test department, though I fear it'll be a very one sided conversation.

1.2.2
- Fix if the cargo bay is completely full a trader won't sell the ware (introduced 1.2.0)

[reiks]

One thing I would love as a feature is that to have the ability to save a sector blacklist list. Every game start I need to re enter all the sectors i want blacklisted like for example in AP I always tend to blacklist all the terran sectors or the war sectors and sectors adjoining xenon sectors from the list.

[Shimrod]

I can sympathize with that but the ideal export/import approach might require manual intervention as the script can't readily interact with the filesystem:
1. Pushing Export could write a logfile into My Documents\Egosoft\X3AP with delimited blacklist items.
2. User must manually copy and paste that into a line within 9055-L044.xml
3. The setup script reads the textfile ID, parses the delimited sector names out, resolves them and builds up a default list.

Another approach might be to add buttons into the blacklist menu to ban all sectors for a race, ban AP war sectors, which I think are detectable using AP specific script commands.

I'd probably go for the latter as it's less arcane and will be more generally useful. Though it won't be an immediate priority as I'm trying to restrain feature creep right now and drive stability with patches.

[Shimrod]

I've uploaded 1.2.3. The key change in this mission is the middle part about revising search criteria.

Most significantly free traders weren't ever using a search mode other than 'find nearest' when looking for a place to sell a ware. This had 2 key issues:
- Reduced profit. Selling a ware was looking for the nearest place to offload rather than based on price, although it was still buying at the best price so the problem was mitigated and harder to detect. I didn't notice until the following occurred...
- When buying from a dock it would then sell the ware back to the same dock as it was also the nearest place to sell at. Repeat until some other ware makes a better trade.

I've revised this logic and set a new floor for amount of jumpdrive energy available before performing a 'best price' search for buyer/seller stations. That is 2x max jumps worth for homebased traders, and 1.5x max jumps worth for free traders. Where max jumps for free trader is approximated as universe width plus height. Note that traders will load up on 2.5x max jumps energy when refuelling, though this is capped at 40% of cargo bay size.

If they don't have that much energy, or have no jumpdrive at all, they'll fall back to a 'best chance' search. This is identical to the search type used in 'buy ware for best price', and still produces excellent results. It just appears to prefer stations within jumprange to those further away.

'Find nearest' isn't used at all except when looking for equipment (jumpdrive), as for some reason the 'best chance' method doesn't find them.

It may still be possible for a free trader to buy and sell at the same dock, though I haven't observed it. This is harder to tackle because a sale is carried out independently from a purchase. Free traders simply sell everything on board that isn't nailed down before buying something. So they don't know where they bought it or what price it was bought for. The idea is it sells what it has at the best price anywhere, as it's better to make a loss in rare cases than to clog up the cargobay and reduce efficiency.

1.2.3
- Switch display command to COMMAND_REFUEL when moving to an SPP.
- Revised criteria for searching stations by best-price vs best-chance vs nearest.
- When rerouting a buying mission check the ship can jump to the new destination, otherwise reevaluate.

[vukica]

It may still be possible for a free trader to buy and sell at the same dock, though I haven't observed it. This is harder to tackle because a sale is carried out independently from a purchase. Free traders simply sell everything on board that isn't nailed down before buying something. So they don't know where they bought it or what price it was bought for. The idea is it sells what it has at the best price anywhere, as it's better to make a loss in rare cases than to clog up the cargobay and reduce efficiency.

why not just have it buy at price less or equal to average, and sell for anything higher than average?

buy_price <= average
sell_price > average

[Shimrod]

Unless I'm mistaken docks buy an sell at fixed average price, so if traders only sell at avg+1, they'll never be able to sell lasers, missiles or shields as docks are the consumers.

If it was done the other way round, only buy if price < average, traders wouldn't then buy anything from a dock either. Typically I hope they'll find more profitable trades, but it'll at least prevent them finding a jumpdrive.

I think it might require some annoying hack like recording last purchased ware, location and price, and if [DOCKEDAT] sells that ware for that price then put it in the exclude array when searching.

However the 'find nearest' fix both reduces the likelyhood of it and the impact. At worst it might buy and sell 1 lot, if market conditions (or jumpdrive energy) changes so it's not worth selling it elsewhere. That might not actually be a bad thing.

As soon as the next mission is planned it won't generate the same mission net profit of buying and selling at the same place will be zero, and if it does pick a 2nd leg station that's not the one it's docked at, then this will also be the place it sells at since both use the same search logic.

So it's reduced to an imo harmless, rare and academically interesting condition that warrants an elegant fix, but isn't worth doing anything kludgy to try and address.

[reiks]

I can sympathize with that but the ideal export/import approach might require manual intervention as the script can't readily interact with the filesystem:
1. Pushing Export could write a logfile into My Documents\Egosoft\X3AP with delimited blacklist items.
2. User must manually copy and paste that into a line within 9055-L044.xml
3. The setup script reads the textfile ID, parses the delimited sector names out, resolves them and builds up a default list.

Another approach might be to add buttons into the blacklist menu to ban all sectors for a race, ban AP war sectors, which I think are detectable using AP specific script commands.

I'd probably go for the latter as it's less arcane and will be more generally useful. Though it won't be an immediate priority as I'm trying to restrain feature creep right now and drive stability with patches.

Thank you for the reply and yes I think what you suggested would also work!

[Shimrod]

I'm going to call 1.2.3 is stable as far as free traders go. I have 30 free trader mercury haulers now at 16 game hours and the profits steadily clock up. I've only had one ding where a neutral pirate base was surrounded by red lasertowers, and even with only a 1MW shield he managed to jump with 2% hull remaining so I could send him for repair.

After finishing exploring and as rep permits I'm going to set up some factories and watch out for any homebase trader issues. If it's all pretty solid then that'd be the time to review enhancements that have been proposed (inc. repairs, blacklist enhancements add-by-race/war). Though I fancy playing through the AP missions in earnest to see what's new so maybe will back burner that.

Major avenues of future development might include trading from ship homebases (miner support, sell wares that a mothership roams around collecting, resupply), huge ships acting as traders via transporter/trade drones. At some point I want to call it done though.

Playtesting notes:
- Couple of free traders killed when en route for fuel. One was heading through Xenon Sector 472.
- Getting attacked by terrans in war sectors despite neutral relations.
- Most pirate sectors end up needing blacklisted. A few other race sectors due to wandering pirates, Grand exchange agro from Xenon. Yaki sectors no trouble at all.
- Just 1 trade mission for teladi and my rep jumped up from not able to buy m3+, to being able to buy osprey and albatross. Way higher boost than what my army of traders are bringing in on their own.
- Manually equipping jumpdrive on homebased traders was annoying, need an auto equip option for them. Consider as part of an overall equipping config model.
- Starting off with no fuel from terracorp hq, homebased traders went to buy wares rather getting energy first. Had to manually send them to SPP to fuel up. Should make them refuel first.

[johntarmac]

If there is another revision the only niggle I have is the warning message when a trader is is trouble is a little short. Another 5 seconds or so on the duration of the pop-up would be great.

Cheers

[Shimrod]

These are the 1.3.0 changes I'm currently testing. No ETA eta on release though.

Code: Select all

- Traders now repair hull damage at a shipyard
- Homebased traders now buy jumpdrives like free traders already do
- Ships will refuel when below 15% of reserve energy.
- Increase the attacked warning subtitle message duration from 3 to 6 seconds.
- The monitor task now rapidly restarts the cmd script on version upgrade. This resumes the ships current action where possible.
- Fix a bug where traders might think they had sufficient energy to jump when they didn't (since 1.0.0)
- Fix: prevent selling wares at player owned stations. Bringing available funds into the equation adds complexity and supporting selling to self may not always be desirable. (since 1.0.0)
- Fix attempting to top up jump energy amount exceeding available cargo space (since 1.1.0)

If any of this presents a problem for anyone's edge cases let me know (particularly JD for homebase traders, no selling to player stations).

The last part I'm looking at is the blacklist enhancements. I'm considering adding the following 3 options, as they're the only blanket bans I'd need based on my current AP game experience.

1. Add pirate sectors
2. Add non-jumpable sectors
3. Add war sectors

As traders exclude stations they have no docking rights for, there's no need to include Xenon, Khaak or whatever race is at war. There might be edge cases of hacked stations in border sectors but these could be individually blacklisted. I might add that these won't dynamically update the blacklist over time, it's just a one-off search and mass addition of sectors.


Finally an observation. I found my free trading kestrel had stopped trading. Turns out he'd been buying lasers and fighter drones in his travels, and because OK's 'get amount of ware on board for sale' calculation excludes the amount of lasers that could be equipped by the mainguns and all turrets, as well as a quantity of fighter drones, he finally filled up his cargobay when topping up on jump energy and just parked up in a station. So be wary of ships with miniature cargobays

[DrBullwinkle]

Some other possible refinements for your long-term list (not priority):

- Do not attempt to travel without sufficient jump fuel to reach the destination (this might be something you are already doing -- I could not tell for sure).

- Obey ATF restrictions to inner Terran sectors. In TC, never enter Earth sector.

- Be careful about jumping to outer Terran sectors in AP. AI likes to jump to the North gate in Asteroid Belt. They often survive through the gate, only to wind up having to cross Jupiter (war sector). It is a large and lonely place for a trader. (Most current blacklists do not take this issue into account; they may not choose Jupiter as a destination, but they attempt to travel through Jupiter.)

- There are situations in which a trader may find itself inside targeting range of an enemy capable of a one-shot kill (3km OOS and 7-ish IS). This may be a certain-death situation when OOS because it can take two turns to jump while only one turn to die. To make matters worse, the faster ship gets the first turn; and that is often a Xenon Q. In those cases, consider an insta-emergency jump. It is a feature that should be in the vanilla game, so this is your opportunity to "fix" that.

- Speaking of blacklists, consider a ware blacklist as well. It can be annoying to try to find a rare weapon or missile when the free traders have sold them all for profitsss!

[Shimrod]

Thanks, some handy ideas. I haven't done any Terran sector trading so far, have yet to encounter those problems. I've only ever used tethered sector traders with a jumprange in terran sectors before, and only with a purpose of boosting reputation rather than seeking profits. Never seemed like a worthwhile excercise for profit, given size of sectors, lack of jump access, and trade scripts tripping over special access conditions for the inner planets.

I've significantly revised jump energy calculations in 1.3 and hope to have minimized cases where traders run out of jump energy. The action selection logic now goes:
1. Buy a jumpdrive if don't have one
2. Refuel if below 15% of reserve energy
3. Go to SY for repair if below 100% hull
4. Select trade mission
5. If cannot jump from here to destination then on to an energy source, then refuel.

When refuelling it performs a 'find nearest' search using max 75% of ware price. This should promote shorter hops to refuel.

The logic surrounding trade mission selection is now common to both homebased and free traders, whereas it was previously a little quirky. Free traders would always sell wares before refuelling for example, and homebased traders wouldn't refuel anywhere other than their homebase.

There may be edge cases to discover and weed out with mission redirection and fleeing, but in the main I'm happy with that logic, it brings more intelligence to the party than 1.2.3.

[DrBullwinkle]

It sounds all good, Shimrod.

Why limit the price for buying fuel? The trader cannot safely move without it, and energy cells can be far away in some sectors. If the trader needs it, then he needs it, regardless of the price.

[Shimrod]

I guess the 75% price was really an easy way of wanting at least 25% stock in the station, to help ensure a decent refill even from a small SPP.

Using the price point fits the code without having to significantly change Find.Station, since it doesn't currently factor stock level into the station finding APIs.

Though having thought about it military outposts will always sell for average price even with hardly having any stock, so and amount-based minimum equivalent to something arbitrary like 5 jumps minimum may be more sensible.

[DrBullwinkle]

A thousand energy cells would be a lot for most traders, and almost nothing at all for a Solar Power Plant. Also, SPP's produce quickly. So do you really need to check for how much they have on hand?

If the trader lands at an SPP that does not have enough ecells, then it could safely wait until there are enough. It will not take long.

[Shimrod]

Need to be careful of military outposts and odd docks that cell ecells though, they don't produce ecells fast and the majority of them are usually empty.

If we can be confident using the factory vs dock finding APIs as exposed by X-Studio (which differ from the real script APIs) can reliably be used to differentiate searching guaranteed quick producers, then no limits could be supplied when using 'find factory', while some arbitrary multiple of unit jump energy could be supplied as a minimum when searching docks.

I do recall in ages past deploying crystal free SPPs and finding they produced rather slowly, though I can't think of any relevant example of a slow energy producer outside of docks in my recent experience.