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

DrBullwinkle · Post by **DrBullwinkle** » Wed, 12. Jun 13, 03:03

Shimrod wrote:I can't think of any relevant example of a slow energy producer outside of docks in my recent experience.

Neither can I.

Shimrod · Post by **Shimrod** » Wed, 12. Jun 13, 10:35

I recall from build SPP station missions that they retain their crystal resource when handed over to NPCs. Traders will also buy at player stations that require resources. I'm worried that a trader could stall in a non-producing SPP as it's the nearest, while it never produces any energy.

One approach might be to to require a minimum stock level when searching for an energy provider along the orignal lines, providing amount input on the find APIs works as anticipated.

Another would be to exclude a minimum stock level in the search, but apply a filter to the results that a) factory is not a dock, d) producer has no resource ware entries. If true then assume ecells will appear (so it's ok to stay parked there until energy hits desired level), otherwise require that the station/dock has some minimum amount.

There are perhaps still edge cases for the last like factory production tasks being disabled, that might result in waiting on fuel from a non-producer indefinitely, but unless a real world example manifests I'm inclined to go with your suggestion of leaving stock level aside in the sxearch, while including the producer test in the search result filtering as a sanity check and falling back to requiring some amount.

Shimrod · Post by **Shimrod** » Thu, 13. Jun 13, 20:37

consider an insta-emergency jump.

I find there are cases when the trader picks up agro immediately at a jumpgate, or when it flies near some roaming pirates before getting targetted, so that it starts taking OOS damage quickly before the jump countdown completes. Insta-jumping would certainly help but I'm keen on keeping the simulation legit or at least introduce an acceptable tradeoff.

It's often the case in movies that ships perform blind emergency jumps with risk attached. I think it'd be acceptable for a ship to have percentage chance of mis-jump. Side-effects might include:
- Ship materializes in a random sector
- Ship disappears never to return
- Jumpdrive is destroyed
- All fuel consumed

It's something I'll consider for the future, particularly if more demand for it manifests.

DrBullwinkle · Post by **DrBullwinkle** » Thu, 13. Jun 13, 20:42

Shimrod wrote:- Ship disappears never to return

*Chuckle*... oooh, that would be nasty. Just before the jump, better send an emergency mess... <no further communication from OK Trader 122>

Traders are pretty defenseless on their own. If they do suffer emergency jump damage, then perhaps they should fly to the nearest friendly station and radio the player for help?

Vayde · Post by **Vayde** » Thu, 13. Jun 13, 21:06

Think I've found a bug/feature.

During a trade run one of my traders was targeted before she could deliver the wares, she jumped clear. Instead of continuing with the run she started looking for another buy option.

She is now running around the universe with 274 Terran MRE on board. I can stop her and sell via best buy/sell software but would like to have them do this on their own.

Shimrod · Post by **Shimrod** » Thu, 13. Jun 13, 21:19

Is it a homebased trader? At the moment anything they didn't sell should get offloaded next time they go to homebase.

Free traders always try and sell their cargo before buying new.

vukica · Post by **vukica** » Thu, 13. Jun 13, 21:26

why is it called "OK" trader?

Shimrod · Post by **Shimrod** » Thu, 13. Jun 13, 21:38

With the name I wanted to avoid anything lengthy that would get shortened via some acronym (like CAG), so that people have a better idea what's being discussed.

The word 'Smart' is perfect for every kind of automation but I needed something unique. I settled on OK intending to convey the impression that the script isn't pretending to be the best out there, merely an alternative.

I did some thesaurus browsing around clever, shrewd etc, but nothing quite seemed to fit. I guess if I spent more time thinking about it I could have come up with something cooler

vukica · Post by **vukica** » Thu, 13. Jun 13, 21:51

it's OK

Vayde · Post by **Vayde** » Thu, 13. Jun 13, 22:00

The trader was a free trader.

Shimrod · Post by **Shimrod** » Thu, 13. Jun 13, 22:24

I'll keep an eye out for that problem. You can get insight into what a trader is doing via the debugging settings:
1. Set that ship as the logging target
2. Set logging verbosity as desired. 5=standard, 10=verbose.

Logfile written to:

Code: Select all

%USERPROFILE%\Documents\Egosoft\X3AP\log09055.txt

Be careful with higher verbosity though as it can cause significant slowdown, particularly if logging target is <all> rather than a single ship.

Interesting tracing will occur when the trader transitions between actions, typically after it finishes moving to a station. At this point it decides on a new mission.

You'll probably need verbose tracing to see the decision making coming from $Lib.Get.Best.Ware.To.Sell, and why MRE isn't being picked. Searching for MRE should identify relevant pieces of tracing.

Shimrod · Post by **Shimrod** » Fri, 14. Jun 13, 00:35

I discovered an apparent bug in vanilla AP while trying to repro the MRE issue, but I don't see it being the root cause of that problem.

I reposted my analysis in the tech support problem, cut out the detail here and linked it:
http://forum.egosoft.com/viewtopic.php? ... 69#4075869.

This concerns me because OK Traders relies on autojump and stock move commands. I can't assume there'll be a quick fix, or even a fix at all depending on the reason the stay call was added, so it might require:
a. Implementing a custom move to station script to avoid the problem.
b. Disable autojump and jump manually before invoking the move-to-station script command.

Vayde - I've had no success reproducing the Terran MRE issue in AP. Are you using TC or AP vanilla, XRM or XTC? On AP or Traders happily sell it at any number of terran stations and docks, as long as I've revealed enough of the universe. I'd suggest for test purposes demonstrating the ware could be sold manually to a station. Also confirm the sectors buying the ware aren't blacklisted.

Vayde · Post by **Vayde** » Fri, 14. Jun 13, 19:38

I'll try and get it to repeat itself this evening and let you know what I find.

With regards to auto jump, do you mean that, when a ship picks a station to dock at which does not have a jump gate or beacon, and auto jump is enabled. It simply refuses to move?

Shimrod · Post by **Shimrod** » Fri, 14. Jun 13, 20:04

Yes that's the case. My testing suggests it occurs when adjacent sectors have no jump access. Ship just sits there and command displays as None.

According to the tech support response it's by design. This obviously makes autojump a liability for automated traders, I'll have to implement my own version of moving to station.

It should be possible to implement a custom jump-move command that works more like people would expect. There's a 'get next sector on route from sector x to sector y' command that can be used to walk from destination back to [SECTOR] and determine the nearest sector in fuel range that has a jumpgate/beacon. If this is closer to the destination than the current sector then jump, otherwise move to next sector manually.

DrBullwinkle · Post by **DrBullwinkle** » Fri, 14. Jun 13, 23:51

TC's !move.jump is like your second listing, so the code changed in AP somewhen.

Like you, I find it a head-scratcher. It does not seem to make sense, and I cannot guess why it would be intended behavior in your use case (if, in fact, it is).

You should really post in the L3+ beta test forum. A dev might notice your post there, and it would have a chance of being fixed in a future patch.

Shimrod · Post by **Shimrod** » Sat, 15. Jun 13, 01:08

On the flipside, rolling my own jump logic presents an opportunity to integrate with p2p jumpdrive solutions.

I've seen this in action after enabling beacon jump on a UT before, it can be a great force for profit and imbalance. OOS it's almost like watching a disk defrag as wares almost instantly move from one place to another. Also it's nice eye candy seeing jump signatures manifest when IS.

DrBullwinkle · Post by **DrBullwinkle** » Sat, 15. Jun 13, 01:18

Nice.

(But shouldn't you report it anyway?)

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

I might have nailed that free traders occasionally not selling wares issue. When the trader got lower on energy it was reverting to a 'best chance' search when selling wares instead of 'best price', the intent being to bias the search toward more nearby stations perhaps at the tradeoff of a few credits.

However I get the impression that 'best chance' searches may be leaving out stations that are far away, even if those stations meet price and jump range critiera. So the trader could see a good trade initially and buy a ware, and as it's fuel lowers and searching switches to 'best price', it can't see that destination anymore.

To address that I've changed the free trader find method it in the next version so they always use 'best price'. Except when equipping (nearest), and when they have no jumpdrive (best chance).

This and a host of other fixes and enhancements coming soon in 1.3.0. Still testing and tweaking at the moment though.

Shimrod · Post by **Shimrod** » Sun, 16. Jun 13, 21:15

I've uploaded 1.3.0.

1.3.0
- Homebased traders now buy jumpdrives in addition to free traders.
- Traders repair hull damage at shipyard
- When docked opportunistically buy and equip a quantity of missiles, drones, tunings (not cargo), scanner, jumpdrive, shields
- Reserve against sale a quantity of supported missile types, compatible lasers (ex. TB, MDS), installed shields, drones, and a jump beacon.
- Launch missiles and drones when under attack
- Increase intelligence around refuelling and fleeing.
- Add blacklist options to add pirate, non-jumpable, and war sectors.
- Increase the attacked warning subtitle message duration from 3 to 6 seconds.
- Rapidly restart the command script on version upgrade, rather than waiting on action completion. May not take effect until +1 releases ahead.
- Display collective free trader balance underneath the current traders balance in the free trader's menu. Note this only includes profits from currently existing player ships.
- Disable selling wares to player owned stations.
- Fix: traders could erroneously believe they had sufficient jump energy to jump when they didn't (since 1.0.0)
- Fix: attempting to top up jump energy exceeding available cargo space (since 1.1.0)
- Fix: take into account infinite buyers when free traders assess trade run profits (since 1.2.0)
- Fix: monitor task could exit on version upgrade and not start again until the ship's move action completes, leaving traders vulnerable (since 1.1.0). May not take effect until subsequent upgrades.
- Fix: race condition where 2 free traders could perform the same trade (since 1.2.0)

alt3rn1ty · Post by **alt3rn1ty** » Sun, 16. Jun 13, 23:30

Man this is fast becoming the trade script of choice .. If it isn't already.

I'm just about to update this ( I have previously had the last couple of versions installed )

I also have Gnasirators MK3 Improvement installed, and looking at your latest feature list the distinction between the two is getting a bit grey

I have just started setting up what will be my long term AP setup, so this has come at a good time .. Going to set 4 Mistrals as MK3 Improved STs and then to UTs once they have levelled up, and also set 4 Mistrals as Free Traders with OK

I will also be running 8 home based traders with OK ( two per station )

Then watch. I reckon now they both have sector blacklists surviveability will be comparable, I think the only difference will be in overall profit efficiency

Thank you for the update and work put into this Shimrod, I used to love CAG and EST .. But since Lucike has a bit of catching up to do ( if he is still intending to idk ) I decided to give yours and Gnasirators scripts a run for their money, so far very impressed.