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

[Fun-X]

I guess an easy fix would be to see if immediately after the sale the factory is 100% full, and if so, give up and return to home and start over.

Just a thought. There might be a cleaner way.

[Shimrod]

On further analysis the problem is more complex than first thought. OK isn't actually trying to sell to the station it's camping it, but rather it's stuck in the following loop:

- I currently have no mission and am outside the homebase.
- Since I have no mission I need to retain only enough energy to jump home (retain 100, cargo 200).
- Select a mission. I have 100 energy for sale in the cargobay that I don't need.
- I can sell this a few sectors away for a profit, start sale mission...
- Since I'm on a sale mission I need to retain enough energy to jump there and then jump home plus contingency (retain 250, cargo 200)
- Sanity check: I don't actually have any energy for sale as I need to retain all of it as jump energy, abort mission!

Prior to the homebased trader energy optimizations this wasn't an issue as it always retained a constant amount of around homebased max jumps * 2. But now that the state machine determines fuel requirements based on trader's transient states, this introduces a new category of problems.

Opportunistic trading - Trader has completed its sale mission and can buy or sell another ware without returning to homebase. However homebased trader with mission <none> docked outside homebase will currently sell all its energy besides enough to get home with. This practically eliminates any scope for opportunistic trading outside of the trader's current sector.

Opportunistic trading of energy cells - Amount of for sale needs to take into account the planned mission rather than current one and increase amount to retain accordingly.

I'm considering the following changes to address these:

1. When embarking on a homebased trader mission, persist the initial energy retention amount in the trader's state. Don't reduce this floor amount until the trader returns to its homebase. May need to let floor amount expand to allow for opportunistic trades when trader can buy energy cells where it's docked to extend its range.

Intent: more scope for opportunistic trades.

2. Factor in the prospective destination of an opportunistic trade into energy retention calculations for determining if the trader really has any energy for sale.

Intent: fix the station camping bug loop

I've discounted simply making the trader return home as I want to allow for opportunistic trades.

Eta for a fix may be in the order of days or weeks, probably no free time this weekend in which this gets priority.

[panacea]

First off, this script is brilliant. I've replaced most of my UTs with free traders and it's remarkable how much more profitable they are.

My question is about using them to replace my CAGs. Most of my complexes are set up where there's a bit extra on some of the resources produced - ie crystal complex with ~20 silicon extra per hour. If I set a homebased trader there and tell him to sell the silicon, I'm concerned he'll throw the crystal production out of whack by selling off too much silicon. The only setting I can see to adjust this is the 10% minimum stock level global setting. Does that mean he'll leave 10% stock or that he'll only sell when the stock gets to 10% ? Am I missing an easy way to use them to manage the stock levels for a complex ?

[Quinch]

To my knowledge, it means "only sell if there's at least 10% stock in the coffers". At least that's how it's been working out for me.

[Shimrod]

I've uploaded 1.7.0.

1.7.0
- Add Stock Limits settings accessible from homebased trader menus to support intermediate ware trading. Traders avoid selling below the minimum stock limit and avoid buying above the maximum stock limit. The limits apply to all traders at that homebase.
- Fix a bug with trading energy cells that could cause homebased traders to sit around in a station (1.6.2 regression)

This has some nontrivial changes. I've put in a couple of days testing and fixing, but can't dedicate any more time to it so please be vigilant for bugs.

I updated the info post:

Stock Limits

The homebased trader menu contains a Stock Limits section. This allows a minimum and maximum threshold to be set for each of the homebase wares. These settings apply to the homebase rather than per-trader so only need to be set once.

Min Stock % is used to set a floor amount traders won't sell into This is useful for trading intermediate wares. The default of 0% means traders will sell everything.

Max Stock % is used to set a ceiling where traders won't buy stock above that level. This works in the same way as a dockware manager limit except it is percentage based. The default of 100% means traders will buy the ware to full stock level.

The menu also shows any dockware manager limits in a read only fashion. If a dockware limit is set the minimum absolute stock level between the OK setting and dockware setting will apply.

The global settings page also contains a Min Stock Level Trade % setting. This is used to create a buffer which must be exceeded before a homebased trader will trade a ware. The purpose of the setting is to avoid traders performing small trades, such as immediately re-buying the jumpdrive energy they refuelled with. This setting only applies to triggering a trade run; the trader will still use the full range of the stock level, or as limited by Min and Max Stock Level % settings described earlier.

[panacea]

This sounds like exactly what I was looking for, thank you!!

[g_BonE]

Hi... so i dont know if this is a bugreport or how i best describe the issue- bear with me:

I'm running the OK Trader 1.7.0 version in my Litcube Universe. In the beginning i had five OKT running without any performance issues whatsoever, but now being 2 days into the game the traders cause unbearable lag - i even had a lockup when trying to use the OK traders to resupply my dock (dockware manager). Especially when on time acceleration one can see when one of the trader calculates and starts a new run theres a lag spike.

Does anybody else have this happen to them ? Might it be caused by having satellites in all sectors non-threat sectors?

[Shimrod]

Check if OK's debug mode is enabled in its menu, the logging causes massive lag.

Good to hear it works (for a while) with LU, I haven't tried it yet.

[dizzy]

I'm playing XTC 2.2b and looking at your script as a way to support my stations as I'm getting to a point in my game where I'll start building some complexes.

I have about 50 (most of them fully upgraded to level 25) UTs going about their business. As opposed to what many are saying, the vanilla UTs seem to work just fine to me for universal trading purposes, they run when attacked, they buy and drop fighter drones, they make good profit and almost never get stuck (one in 10 traders may get stuck in the first few trade runs/levels but it depends on the sector anyway). Maybe XTC has improved their algorithm and I haven't had fresh experience with real vanilla UT :)

In any case, I expect that once I have my first complex I'll be at the mercy of my UTs to have its products sold and have it stocked with resources. I assume that even if I assign a homebase to the complex for the UTs, their logic won't change and the only way to get my stations supplied would be to buy and start more UTs.

That's where your and other people's scripts come into play. CAG is incompatible with XTC (requires some patching), Improved MK3s is also incompatible (although listed as compatible on the XTC 2.0 compatibility list thread). Your script seems to have been developed and tested with XTC so it seems like the ideal candidate for station trading support needs.

Do I need to do something special to get it working properly on an existing game? Will it "just work" if I start enabling it for existing UTs (most of them fully upgraded like I said)? Will the OK trader profitability work with the XTC statistics center where it displays each trader's profit?

Thanks!

[Shimrod]

I don't anticipate a problem, but to be on the safe side you could try a limited rollout before converting the whole UT fleet.

To operate as free traders / UT you'll need to clear the homebase setting before enabling the OK trade command. With a homebase set the ship will trade a configurable set of wares for its homebase, prioritizing the ware to trade by stock levels, whereas the free traders prioritize by profit. Free traders also have an economy boost (eco mode) toggle where the free trader will prioritize trading with non-producing factories.

I haven't coded explicit support for the XTC statistics center so wouldn't expect that to work. Though there's a chance if it's implemented generically by hooking a buy/sell event that the center may recognize their trades.

OK traders in free trader mode track their profit and report this in the OK trade menu. There's one global counter that shows a balance for all traders, and one local counter for the trader itself. Both can be reset to zero.

Do be aware that if the trader needs to initially buy any equipment the trader's balance may go in the red before it earns enough to go back into profit.

I haven't played X for many months, please let me know if anything is broken.

[dizzy]

Thanks for your detailed reply. I'm still putting off starting to build stations/complexes because I'm afraid I won't do it in the right place and then I'll lose all the money I spent on them :(

So now I'm spending all the money my UTs are making on building an army instead. Ships at least are mobile :)

I'll let you know how it works when I decide to bite the bullet.

[chronicon]

Check if OK's debug mode is enabled in its menu, the logging causes massive lag.

Good to hear it works (for a while) with LU, I haven't tried it yet.

also setting things like m1 and m2 to ok traders causes massive lag i dont think the script knows how to use them properly . stick to haulers lol

[dizzy]

I started using the script last night. Main motivation was to get a personal equipment dock supplied properly with military shields (xtended 2.2a). I've tried using vanilla supply commands but each ship can trade only one ware and in the case of military shields this is terribly wasteful and takes all docking ports of the equipment dock because I have to end up with one ship per type of military shield that are mostly idle because military shields are produced so slowly by the NPC factories.

So now I have a single Caiman homebased OK Trader doing all the supplying for the equipment dock, it works beautifully (although it doesn't seem to know to do multiple buys per trade run, it only buys one type of goods in a trade run which again is very inefficient with military shields because you normally get only one or two of those and still have lots of room left in the cargo hold).

Seeing how that worked pretty well I started converting my 11 Caiman dedicated traders of a personal tech producing complex hub. In this case, the vanilla supply commands worked OK (compared to the equipment dock) because I only had a few goods to sell and distributing the goods to sell among the 11 homebased Caimans works reasonably well. But I now converted them to OK traders and it seems they are doing a much better job, making more profit than before.

Finally, I started converting some of my 75 fully upgraded UTs to free OK Traders (non-economy support mode). They also seem to be making some profit although it seemed rather slow (about 3 mil credits for 20 OK Traders in about 30 minutes of gaming, I think the UTs made more). It's likely that the free roaming OK traders aren't as efficient because they compete along with the remaining UT traders to make profit since there is no "communication" between the 2 scripts and they don't avoid repeating trade runs.

Anyway, overall it seems like a VERY well written script, really impressed, high quality work.

Now the bad part:
- OK traders do not register at all in the Xtended statistics pages
- they are not listed on the "list all traders" page
- they don't have a category on the "list traders of certain type" page
- they don't show profit stats in the "configuration" page of xtended (additional commands section of the ship)

I'll try to look into this problems. Especially the "list all traders" and "list traders by type" would be very useful for me. Fixing the profit tracking would be nice too. I know OK traders have their own profit tracking but it's much better to get a listing of all traders and the profit value for each like Xtended does, rather than going through all of the 70+ traders and checking each one's profit in the OK trader menu.

Let me know if you are interested in those fixes :)

[dizzy]

I looked at bit at the scripts trying to find what to modify. I found at least one place where it tries to find and display the trader profit and it seems that it just displays whatever variable that specific script has to report profit (it has support for specific scripts like the game autotrader plus CAG, CLS, EST, etc). I then tried to find in which variable is your OK Traders storing the per trader profit so that I can report that but I can't load "glen.trade.ok.menu" in Exscriptor, I get some error:

Code: Select all

Loading C:\Program Files (x86)\EGOSOFT\X3 Terran Conflict\scripts\glen.trade.ok.menu.xml...
Load failed! Error while loading file: C:\Program Files (x86)\EGOSOFT\X3 Terran Conflict\scripts\glen.trade.ok.menu.xml: Error on line 701 - Unknown command ID '1579'
Load failed

So now I'm a bit stuck there.

EDIT: I used the game SE to load that script and take a look at it. I now know that the balance of each OK trader is saved in the state array (a local variable named 'glen.ok.trader') at index position 7. I also see that it can either be an array (for large value support) or a simple integer. I've started changing the Xtended code to support OK traders. Made some progress so far on the ship detail page.

[Shimrod]

Thanks for looking into this. I developed the script using X-Studio. Exscriptor may not be AP-aware; the scripts contain conditional logic which executes AP commands if the game version is AP, e.g. Lib.Generic.Get.Minimum executes 'get minimum' if on AP. You may also need access to AP level game data to recompile the scripts with the AP references.

The trader's local balance is in a local variable:

Code: Select all

053    $State.Balance = 7 
470   | $State = array alloc : size = 30 
471   | [THIS] -> set local variable : name = 'glen.trade.ok' value = $State 
480   | $State [ $State.Balance ] = 0 

(glen.trade.ok.state)

The global balance is in a global:

Code: Select all

035    $Config.Global.Balance = 18
106   | $Config = array alloc : size = 100 
107   | set global variable : name = 'glen.trade.ok' value = $Config 
124   | $tmp = create new array , arguments = 0 , 0 , null , null , null 
125   | $Config [ $Config.Global.Balance ] = $tmp 

(setup.glen.trade.ok)

Beware that this value is an array containing a pair of signed integers. The first element idx[0] counts billions (1,000,000,000), and idx[1] is the remainder. Ref:

BigInt.Add: - Add or subtract from a bigint (i.e the array[2])
BigInt.Format: - Format the bigint as a string, comma separated
(glen.trade.ok.lib)

Format.Balance - Format the value in green or red depending on positive/negative.
(glen.trade.ok.menu)

Originally the value was just a single integer, which is why you may see some compatibility logic that tests whether it's an int or an array here and there.

[dizzy]

Oh, now I have to buy AP over Steam? I hate hate hate hate (and more hate) Steam. I want them dead, buried and then killed again. Egosoft should just use GOG damn it!
</... rant>

Actually, since I don't need to modify your code (I only needed to read it to understand where the profit was recorded, etc) I won't need to recompile your scripts and so probably won't need AP. I also can't use X-Studio v1 because it asks for admin password (what's up with that?) and X-Studio v2 has some bug where it can't load Twares.pck (already known to the author, waiting for a fix).

Thanks for the heads up that it's always an array and the conditional code was for backward compatibility, this might explain why when trying to use the profit value (array) as it is in the Xtended detail ship display the game hangs. Since Xtended doesn't have BigInt support for per-trader profit (and I think it wants an integer not a string) I may just get the second value of the array and if it wraps... well, bad luck :) Anyway, this is per-trader profit so much less likely to overflow.

[Shimrod]

I got AP for free since I had the superbox, so I can't complain too much. I just wish they'd backported the script enhancements to TC.

Just for browsing the scripts you might get away with just opening the files in a web browser, with x2script.xsl in the same folder. Though its possible the TC scripts\x2script.xsl doesn't understand AP.

Agree on the wrap around, not a big problem. I think I did the 64 bit enhancement just for the challenge of it, I wish I had that much spare time on my hands nowadays

[dizzy]

OMG, how dumb I am, it never crossed my mind to search for an xsl, I did my first changes to X3 scripts (a week ago) by changing the xml file directly, lol

(buying AP is not the issue, buying from Steam is the issue, I bought X3/TC in one form or another about 3 times already, and I promise, if anyone is listening, that I will buy AP 5 times and gift 4 of them on this forum if it ever gets to be DRM free on GOG!)

BTW, I did notice significant stuttering in my game yesterday, about the time I started having a large number (>50) of free OK Traders. Almost everything I do (like slowly turning in an M7) stutters every second or so. My machine is pretty good (Nvidia GTX 780, i5 3570k OC-ed to 4.4Ghz).

I have a bunch of other scripts (SEWN which is configured to check for enemies every 20 minutes, dockware manager, Ship Browser) but it only started to stutter last night so I'm somewhat confident this is OK Trader related. In the worst case I may have to give up using OK Traders for free roaming traders and just use them homebased as a CAG replacement. The built-in UTs are very decent in my game (almost never get themselves killed, probably because I'm not enemies with the pirates) but was looking to turn in a larger profit if OK Traders are better :)

I looked a bit at the code and it's doing a bunch of random sleeps between steps in the trader scripting logic, I may try to boost those values up and see if it helps. If not, an alternative would be to use a single "queue" (sorted chronologically) of events that need to be processed at a certain time and have a single script/loop read and process them for all traders (so each trader logic becomes a state machine) instead of a script instance/loop per trader doing sleeps.

Did you remember testing/running with many (>50) free roaming OK traders?

[dizzy]

OK, I got this working nicely. If you have Xtended Mod 2 (I have 2.2a) and OK Traders already installed, unpack this archive and overwrite the files. It will:

• - change the Xtended Mod ship statistics page to show OK trader profit
  - change the statistics center to also list OK traders in the "list of all traders" page
  - changed the "list traders of a given type" page to have a subsection, "list all of OK Traders" where you can see just the OK traders you have

All ship lists above that include OK traders will also show OK trader profit. Because the OK traders script does not track profits for homebased OK traders I made the choice to ONLY list free roaming OK traders in the above lists.

Download it here.

Files changed:

• - changed scripts/plugin.XTC.STC.Ship.det.xml to show OK trader profit in the ship detail page
  - changed scripts/plugin.XTC.STC.Ships.xml to include OK trader profit if an OK trader ship is in the given list of displayed ships
  - changed scripts/plugin.XTC.HK.08.StatisticCenter.xml to consider OK traders as a trader ship and to add the additional "list all of OK traders" specific trader type
  - changed t/7212-L044.xml to add text for the new submenu entry, I used text ID 690 that shortly followed the existing submenu entries and was available

[Shimrod]

The most free traders I recall having were in the range 20-25. Trouble is I was most recently using with XRM, and it's difficult to separate out what lag is related to OK and what to XRM.

Yes the waits at the following points are a good place to try tuning.

Code: Select all

Get.Best.Ware.To.Buy
Get.Best.Ware.To.Sell

Increasing the waits can extend decision time between missions considerably however. I also recall this can exacerbate delay from collisions where multiple traders end up with the same mission plan and need to retry, another possible optimization point but I'd need to re-familiarize with the code.

Note that economy boost mode uses its own method which lacks wait calls. I never used a lot of these, I expect I'd need optimized.

Code: Select all

Get.Eco.Mission

I'll make time to try it, but can't guarantee when, work and family really squeeze my spare time.