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

The place to discuss scripting and game modifications for X³: Terran Conflict and X³: Albion Prelude.

Moderators: Moderators for English X Forum, Scripting / Modding Moderators

Post Reply
User avatar
dizzy
Posts: 1019
Joined: Sun, 26. Sep 10, 06:00
x4

Post by dizzy » Wed, 3. Dec 14, 23:42

Yes, I have used Dockware Manager to periodically clean up the wares on my POED while the homebased OK Trader was servicing it. It would be great if this was the bug and now things shouldn't be laggy.

Also, since we are on this subject, I noticed that OK Traders assigned to my complex will stop what they are doing after I add new factories to the hub. Even if when adding new factories I make no change whatsoever to the configuration of products/resources/intermediary products (ie I add factories of a type that I already have in the complex). The homebased OK traders just end their current command and then stop doing anything and I always have to remember to restart them. I'd appreciate at least a message in the log otherwise I'm losing profitssss :)

Shimrod
Posts: 907
Joined: Tue, 18. Feb 03, 01:43
x4

Post by Shimrod » Thu, 4. Dec 14, 02:04

I've uploaded 1.7.1.

1.7.1
- Fix a bug which could lead to station ware limit settings corruption, causing traders to gradually use more CPU. If corruption is detected in 1.7.1 the station ware limit config will be reset to default.
- Fix a bug where homebased traders with jumpdrives would perform a 'best chance' station search instead of 'best price'.
- When evaluating docks to buy or sell at, examine other elligible docks trading at the same price to determine a more favourable stock level.
I noticed that OK Traders assigned to my complex will stop what they are doing after I add new factories to the hub
When I last investigated this, the game itself was terminating the trader's command script, rather than OK trade actually stopping. Script debugger shows no lines of script executing after modifying the complex. IIRC happens for standard buy/sell traders too. So there doesn't seem to be much I could do about it, outside of introducing a controlling intelligence say to the homebase itself to monitor and take ownership if the command stops. The broadcast option should hopefully help a bit with bringing them back up though.

User avatar
dizzy
Posts: 1019
Joined: Sun, 26. Sep 10, 06:00
x4

Post by dizzy » Thu, 4. Dec 14, 03:10

Yes, it's very easy to bring them back on once I realize they are stopped again. But sometimes it takes a long time for me to realize that o.O

Sad to hear it's the game doing something this dumb. Having an external "babysitter" task restarting OK Traders would be tricky because you wouldn't know if the trader was stopped because of this broken engine logic or because the user just stopped it through other, more explicit means. I guess you could try to detect this by caching the configuration of connected factories and every time the babysitter task detects that a homebased to a hub trader has been stopped, it can check to see if the configuration is different from the last cache if so it's likely stopped because the engine did so, however, it would mistakenly restart if the user stops a homebased OK trader and immediately changes the hub configuration so the babysitter task misses the explicit stop from the user.

Thanks for the fixes, I'll try them out! Do you think that this bug could be related to some of the random missions in Xtended being offered by people who's name shows as "ReadText30-... ReadText34-..."[1]? (that's the bug I'm getting in Xtended and was investigating at the same time)

Also, do we need to stop and restart our OK Traders for the new logic to kick in?

[1] http://postimg.org/image/szo77sj8p/

Shimrod
Posts: 907
Joined: Tue, 18. Feb 03, 01:43
x4

Post by Shimrod » Thu, 4. Dec 14, 11:56

The scripts are designed to restart themselves after the setup script advertises the new version number through the global variable.

It will certainly be useful to hear if the lag is fixed after applying the patch, ensuring logging is switched off while observing.

One way to see if it corrects the problem is, in the context of albazeus' free trader log,
- Before applying 1.7.1, enable level 8 logging on the free trader from which log was previously produced (($OK01) Mercury Hauler), and save the game.
- Copy in 1.7.1 and reload, check the log for the following traces from Lib.Config.Get.Station.Config:

Code: Select all

Lib.Config.Get.Station.Config: Clearing corrupt station ware config for %s
Check there are no traces about removing a null ware:

Code: Select all

Lib.Config.Get.Station.Config: Removed entry for ware null station Argon Equipment Dock(Legend's Home)
Finally be sure to disable the logging again before saving.
Do you think that this bug could be related to some of the random missions in Xtended being offered by people who's name shows as "ReadText30-... ReadText34-..."[1]? (that's the bug I'm getting in Xtended and was investigating at the same time)
According to zazie who encountered the same readtext symptom, he had no scripts or mods installed outside of XTC, so OK trade could not have been the root cause in that instance.

Note that the OK bug was introduced in 1.7.0 released on 22-08-2014.

albazeus
Posts: 76
Joined: Fri, 21. Feb 14, 17:21
x3ap

Post by albazeus » Thu, 4. Dec 14, 12:35

Shimrod,

thanks! The new version works perfectly. No lag so far! No more trip for 1 mosquito, only lots of profittttssss! :D

There's something I don't understand though: how does a trader manage the missiles he uses for defense?
I mean, I equipped every TS with 20 mosquitos and configured the 'Automated Missiles Resupply' accordingly.
Now every OK trader I checked has sold/lost the mosquitos, both the free traders and the homebased.
Let's take for example a trader homebased to a missiles complex (that produces and sells mosquitos):
- if the trader has the mosquitos in the cargo bay, he will drop them at the complex
- if the trader has no mosquito, he will not refuel at the complex (I think he refuels and then drops them)
This happens when 'Missiles' in 'on' global settings. When off, he just sells the mosquitos.
:?
Can look at this? Do you need logs?

albazeus
Posts: 76
Joined: Fri, 21. Feb 14, 17:21
x3ap

Post by albazeus » Thu, 4. Dec 14, 12:39

Sorry, I didn't see your last post.
I simply installed the new version. Everything seems fine.
Do you still want me to check that?

Shimrod
Posts: 907
Joined: Tue, 18. Feb 03, 01:43
x4

Post by Shimrod » Thu, 4. Dec 14, 13:34

Do you still want me to check that?
If the lag's gone and the OK's ware limit settings look sensible for the EQ dock in legend's home, then that sounds like it worked and it's not strictly necessary to confirm via logging.
how does a trader manage the missiles he uses for defense?
OK trade isn't integrated with any resupply settings. It ignores such settings and buys, sells and unloads only based on its own configuration.

Missile equipping is off by default and must be enabled via: OK Trade -> Global Settings -> [Equipment] Missiles.

If missile equipping is enabled the trader will lazily acquire up to 3 of each compatible type of missile. It doesn't go out of its way to buy them, but stocks up if a station it lands at happens to sell a missile of that type.

When missile equipping is disabled, the trader will treat missiles in the cargo bay like any other ware, and sell them when it has the opportunity.

Homebased traders unload any of the homebase ware in the cargo bay when they are in the homebase. If missile equipping is disabled and the homebase stocks mosquitoes, then the homebased trader will unload them all when at the homebase. If missile equipping is enabled and the missile is compatible, it should retain 3 of them instead of unloading.
Can look at this? Do you need logs?
What you're seeing may well be a bug, perhaps some order of precedence problem between the logic that unloads wares when docked at the homebase, and the equipping logic that loads missiles. I can't check until at least this evening, if I have free space, but certainly if you have a log at say level 7 verbosity of the trader, encompassing the suspicious unloading, I could take a look.
- if the trader has no mosquito, he will not refuel at the complex (I think he refuels and then drops them)
Refuelling is unrelated to missile equipping.

Traders will unload any fuel they have when docked at the homebase, if the homebase stocks energy cells. When starting out on a mission, they should then load any jumpfuel they need for that mission at that point, based on number of jumps the mission requires. This is part of recent changes to optimize down the amount of cargo space occupied by jump energy, as people found when setting max jumps 50 on their homebases, that energy could occupy a lot of cargo space.

If the trader leaves the homebase to go to another sector without loading any fuel, that's certainly unintended. I'm assuming some other sort of resupply system isn't interfering here.

albazeus
Posts: 76
Joined: Fri, 21. Feb 14, 17:21
x3ap

Post by albazeus » Thu, 4. Dec 14, 15:07

Forget about the missiles supply. ATM it's not a problem.
Back to these damn mosquitos: when my complex if full of them, the traders try to sell them no matter what. I see trips with 8/9 mosquitos now. Is it normal?
At this point I doubt I understood what the Min Stock Level Trade % setting is for.
Let's say we have a complex with the capacity of 16600 mosquitos and a Min Stock Level Trade set to 10%: can you please elaborate when and why a trade is expected to be triggered (possibly with a numeric example)?
Sorry for these dumb questions. This game can be really frustrating sometimes.

Shimrod
Posts: 907
Joined: Tue, 18. Feb 03, 01:43
x4

Post by Shimrod » Thu, 4. Dec 14, 15:28

In your case the problem doesn't appear to be the Min Stock Level Trade % setting, but that the market is saturated with mosquitoes.

1.7.1 adds more intelligence around selecting docks to trade wares at based on stock level, but at some point all the docks are going to become full of mosquitoes, then you end up in the same situation.

If the min stock level % setting is 10% then the homebased traders won't initiate a sell mission for mosquitoes until there are 1660 in stock. The trader in question will then load as many missiles as it can (and as permitted by station ware limit config), even if this exceeds the 10% since that was just a trigger threshold.

Currently when selecting a mission traders simply use stock level % as the priorty (100 minus stock% for buy missions), and attempt to trade the highest priority ware.

So the solution would be to somehow factor in how much of a cargo load the market could absorb into the calculation. However this needs careful thought as it may decide never to trade expensive low volume wares like PPCs if the market could only ever handle 2. So maybe as you suggested earlier, prioritizing the most profitable sale would be the best option. After all as long as we're making the most profit, why ever sell a less profitable ware?

The solution will need to avoid biasing sale missions against buying though, this is the tricky part.

albazeus
Posts: 76
Joined: Fri, 21. Feb 14, 17:21
x3ap

Post by albazeus » Thu, 4. Dec 14, 16:23

Sorry Shimrod but I still don't understand all this effort in considering stock levels when selling. I'm here to make profitttssss. Is my complex full of mosquitos? Well, fine then, it just will stop producing that ware. Is my complex low on firestorm torpedos? It's better to set a ware limit then.
When selling, I think a trader should just consider how much profit he will make: [price of ware] * [ware amount the target can buy] - [energy cells used for jumping (if it's a cost)] * [average price of energy cells]. Then pick the greatest number.
Buying is a total different business. I don't know what the right formula is and which one you're using, but we can discuss it if you want.

Shimrod
Posts: 907
Joined: Tue, 18. Feb 03, 01:43
x4

Post by Shimrod » Thu, 4. Dec 14, 16:50

For the moment just set mosquitoes to 'No Trade' and let the traders sell the other stuff until the market saturation on mosquitoes eases up. Allow perhaps 1 trader assigned to sell mosquitoes, maybe a little M5 who can economically shift small volume without a JD.

I'll have a think on improving the prioritization method.

albazeus
Posts: 76
Joined: Fri, 21. Feb 14, 17:21
x3ap

Post by albazeus » Thu, 4. Dec 14, 18:36

Thanks, that worked. I'll wait to see if the saturation level decreases

User avatar
dizzy
Posts: 1019
Joined: Sun, 26. Sep 10, 06:00
x4

Post by dizzy » Thu, 4. Dec 14, 20:03

albazeus wrote:When selling, I think a trader should just consider how much profit he will make: [price of ware] * [ware amount the target can buy] - [energy cells used for jumping (if it's a cost)] * [average price of energy cells]. Then pick the greatest number.
This is a topic of its own (and I expect lots of people on these forums to have written treaties around it) but a smarter profit formula would also consider the time it takes to make the sale. That means, one has to estimate the time it takes to go to the station to make that sale (distance from closest gate to the destination / speed of the trader, because OK traders automatically use docking computers the time can be estimated very well). The time to get back is always the same from any destination (since it's a jump to the closest gate to the homebase + traveling the same distance). After you get the total time, divide the profit from the above formula by it so you get "profit per second". Order potential sales on this value :)

(of course, this assumes jumpdrives which are a must for any profitable enterprise, in case of no jumpdrive just don't consider the time)

And that's just for trade runs that do one sale. You can try to be really smart and do multiple sales/buys per run but things get very complicated but not impossible (it can be reduced to the basic "travelling salesman problem"). Because factory configurations rarely change (the factories present in the various sectors and their positions almost never change) you can pre-compute in a table the distance from the closest gate to any factory in the game. Then lookup this table for computing how long will the trader take to get there (since you need to consider per trader speed).

User avatar
dizzy
Posts: 1019
Joined: Sun, 26. Sep 10, 06:00
x4

Post by dizzy » Sun, 7. Dec 14, 19:08

Yesterday I noticed a really bad case of OK Traders not taking distance/time to cover into consideration. I've noticed one of my complexes running out of energy cells and stalling but I knew it had a Caiman Hauler homebased OK Trader servicing it which should be fine. I looked for the trader only to find him trying to sell a few products for the homebase in Armstrong. For those unfamiliar with Xtended Mod, Armstrong is a sector where there is only one gate (the rest are trans-orbital accelerators) so traders can only jump at that gate, but this gate is a "hidden" gate, more 80k away from the sector center. So my Caiman Hauler takes forever to travel that distance, in the meantime the homebase goes out of energy cells :(

I could add one more trader to the base but most of the time he'd be idling as a single Caiman Hauler is more than enough for that complex, as long as he takes about 10 minutes in game time for a trade run. If he takes >40 then things will get bad. I'll try to bump up the max stock limits for resources for that base, to get a larger buffer of resources for these occasional very long trade runs but ideally the trader could take into consideration the time it takes to do the trade run because it can be computed very well, especially for OOS.

Shimrod
Posts: 907
Joined: Tue, 18. Feb 03, 01:43
x4

Post by Shimrod » Sun, 7. Dec 14, 19:44

OK uses the game's buillt in script commands for finding stations to trade at for 'best price', where OK takes the result off the top to be the best, with subsequent results (feeding in previous station to excludes array) being less desirable.

Sadly these APIs don't include a 'best price over time' option factoring in speed and distance from station to gate. I see no simple solution here and have insufficient spare time to work on large enhancements for the foreseeable future, possibly ever.

In addition to adding a 2nd trader perhaps restricted to buying resources, the sector could also be blacklisted.

Dazzard
Posts: 21
Joined: Sat, 10. Sep 11, 23:32
x4

Post by Dazzard » Sun, 14. Dec 14, 00:04

memeics wrote:Yesterday I noticed a really bad case of OK Traders not taking distance/time to cover into consideration. I've noticed one of my complexes running out of energy cells and stalling but I knew it had a Caiman Hauler homebased OK Trader servicing it which should be fine. I looked for the trader only to find him trying to sell a few products for the homebase in Armstrong. For those unfamiliar with Xtended Mod, Armstrong is a sector where there is only one gate (the rest are trans-orbital accelerators) so traders can only jump at that gate, but this gate is a "hidden" gate, more 80k away from the sector center. So my Caiman Hauler takes forever to travel that distance, in the meantime the homebase goes out of energy cells :(

I could add one more trader to the base but most of the time he'd be idling as a single Caiman Hauler is more than enough for that complex, as long as he takes about 10 minutes in game time for a trade run. If he takes >40 then things will get bad. I'll try to bump up the max stock limits for resources for that base, to get a larger buffer of resources for these occasional very long trade runs but ideally the trader could take into consideration the time it takes to do the trade run because it can be computed very well, especially for OOS.
You could just blacklist the sector so it won't get deliveries to/from it ;)

BlackArchon
Posts: 1016
Joined: Wed, 4. Feb 04, 17:37
xr

Post by BlackArchon » Thu, 5. Mar 15, 21:08

How are "OK traders" freighters compared to "MK3 Improvement Reloaded" freighters as universe traders? Where are strengths and weaknesses on both scripts?

BlackArchon
Posts: 1016
Joined: Wed, 4. Feb 04, 17:37
xr

Post by BlackArchon » Sat, 14. Mar 15, 17:17

I'm using OK Traders 1.7.1 and got two free traders. I blacklisted Pirate sectors, but one of my traders just flew through Olmancketslat's Treaty and got destroyed by a pirate ship. What is wrong here?

Shimrod
Posts: 907
Joined: Tue, 18. Feb 03, 01:43
x4

Post by Shimrod » Sat, 14. Mar 15, 17:20

OK uses egosoft's builtin move scripts. The blacklist doesn't affect the route ships take to get from A to B, it only influences which stations are excluded as trade destinations.

BlackArchon
Posts: 1016
Joined: Wed, 4. Feb 04, 17:37
xr

Post by BlackArchon » Sun, 15. Mar 15, 10:18

Thanks, so the rule is: never use OK Traders without a jump drive. :)

Post Reply

Return to “X³: Terran Conflict / Albion Prelude - Scripts and Modding”