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

Shimrod · Post by **Shimrod** » Tue, 21. May 13, 23:03

Repairs and equipping (shields, tunings, jumpdrive) are certainly something I'd consider in future though it's not an immediate priority.

Note that in 1.1.0 the trader will detect incoming hostiles within its max scan range and move to homebase, so assuming it has a jumpdrive, energy and not already in home sector, it should jump away before taking any damage.

So far in my game I've not had any casualties, and the warning subtitle message displays the sector name so I know which sector to blacklist or clean out if it recurs.

johntarmac · Post by **johntarmac** » Sat, 25. May 13, 12:02

Just started using this to free up my CAGs for CLS duties and it's working very well.

Cheers

Shimrod · Post by **Shimrod** » Sun, 2. Jun 13, 14:37

I've uploaded a new version. The main feature is they can now operate as free traders. The free trader balance of profit or loss since the command was started is displayed in the menu. Note that when it buys its first wares/energy it will start out in the red.

There is no micromanagement involved. To make a free trader, start the command on a ship without a homebase. To make a station trader, assign a homebase then start the command.

1.2.0
- OK Trade can now be enabled on ships without homebases. They act as free traders and roam the galaxy in search of profit.
- When a ship is already running the command, the trade menu will display the ships's current settings or profit/loss so far in the case of a free trader.

Edit: Thought I'd found a problem...
Update: It turned out the homebase just had no money

, everything is ok!

joelR · Post by **joelR** » Sun, 2. Jun 13, 16:29

Thanks shimrod. Great addition.

What happens if I homebase a free trader after issuing the command?

Mythrantar · Post by **Mythrantar** » Sun, 2. Jun 13, 16:38

Thanks for the great mod! Maybe a silly question but here it is anyway: what makes an non-homebased OK Trader a better choice than a classic sector trader or a universe trader?

Shimrod · Post by **Shimrod** » Sun, 2. Jun 13, 16:41

The script's sanity check should terminate the command if a homebase is assigned to a free trader, or a homebase is cleared on a homebased trader. If the ship is performing a blocking action though it might not immediately realize this.

Thanks for the great mod! Maybe a silly question but here it is anyway: what makes an non-homebased OK Trader a better choice than a classic sector trader or a universe trader?

The goal with OK Traders is for it to work without any micromanagement, levelling, training, and perform at their best right out of the box. I don't use UT and CAG for these reasons.

There is no common code between OK Traders and CAG/UT, so they'll also react differently to threats and changing trading conditions. I haven't made a side by side feature comparison, no doubt CAG/UT have more options.

vukica · Post by **vukica** » Sun, 2. Jun 13, 17:17

Shimrod wrote:The script's sanity check should terminate the command if a homebase is assigned to a free trader, or a homebase is cleared on a homebased trader. If the ship is performing a blocking action though it might not immediately realize this.

On AP I'm finding the 'buy x units of y' command isn't working for homebased traders when they buy ore, for no apparent reason. I'm experimenting with using the 'buy x units of y to a max. price of z cr' cmd as an alternative, as this is used in !trade.getware. Hopefully will cure it... Nope, didn't cure it.

Edit: I was just being an eejot. The homebase had no money!

Thanks for the great mod! Maybe a silly question but here it is anyway: what makes an non-homebased OK Trader a better choice than a classic sector trader or a universe trader?
so it is working now?

The goal with OK Traders is for it to work without any micromanagement, levelling, training, and perform at their best right out of the box. I don't use UT and CAG for these reasons.

There is no common code between OK Traders and CAG/UT, so they'll also react differently to threats and changing trading conditions. I haven't made a side by side feature comparison, no doubt CAG/UT have more options.

Shimrod · Post by **Shimrod** » Sun, 2. Jun 13, 17:19

Yes, it's fine, I just forgot to add money to the homebase station when I spawned the test environment. There's no known problem with 1.2, though if any problems manifest be sure to let me know and I'll fix.

vukica · Post by **vukica** » Sun, 2. Jun 13, 19:06

Shimrod wrote:Yes, it's fine, I just forgot to add money to the homebase station when I spawned the test environment. There's no known problem with 1.2, though if any problems manifest be sure to let me know and I'll fix.

ok, thanks!

DrBullwinkle · Post by **DrBullwinkle** » Sun, 2. Jun 13, 23:28

Shimrod wrote:- When a ship is already running the command, the trade menu will display the ships's current settings or profit/loss so far in the case of a free trader.

Nice. Thank you.

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".

Shimrod · Post by **Shimrod** » Mon, 3. Jun 13, 00:08

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 · Post by **Marvin Martian** » Mon, 3. Jun 13, 18:51

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 · Post by **Shimrod** » Mon, 3. Jun 13, 19:07

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 · Post by **Shimrod** » Mon, 3. Jun 13, 21:43

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 · Post by **Shimrod** » Tue, 4. Jun 13, 01:14

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 · Post by **reiks** » Wed, 5. Jun 13, 15:54

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 · Post by **Shimrod** » Wed, 5. Jun 13, 16:14

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 · Post by **Shimrod** » Wed, 5. Jun 13, 22:14

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 · Post by **vukica** » Wed, 5. Jun 13, 23:22

Shimrod wrote: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 · Post by **Shimrod** » Thu, 6. Jun 13, 00:25

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.

egosoft.com

egosoft.com

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