Misunderstood-Wookiee / Mules-and-Warehouses-Extended

Compliation and Maintenace for the famous mule mods.
Creative Commons Attribution 4.0 International
12 stars 12 forks source link

Supply Mule - game stuttering #161

Open pimpace opened 1 year ago

pimpace commented 1 year ago

I've attached 7-10 Supply Mule ship to a station to support. Until 6-7, it went OK, but I added more than 10, then I added 8 sup mule to another station, and then realized the stuttering, and micro freeze "effect". I'm talking about massive lag spikes. Like every 30-60 sec. I use the default setting and set the jump gates 7.

For now this is game ver 6.0 beta5, and Mules Supply and Warehouses Extended ver 6.4.2

I really like this mod, due to the vanilla should work like this, however after adding 10-20 supply mule ruins the whole game play performance wise.

I can provide any report, screenshots, setting, log if you want. I hope you haven't stopped maintaining the mod.

regards;

Misunderstood-Wookiee commented 1 year ago

Unfortunately, maintenance has ceased for now as have moved on to other games and projects. Might pick it up again sometime in the future sounds like the trade script is wasting a lot of resources calculating continuously or too fast or broke somewhere between X4 5.0 and 6.x,x this issue has been reported a lot in later versions of X4 picking the code now I would have remember what half of it did in first place haha.

bhayden53 commented 1 year ago

In general, this problem happens when the search space is too large; i.e. too many sectors and/or too many wares. And then if you have too many mules for the budget and demands of the station, they are working hard to find something to do.

For various reasons the current version of the code doesn't really allow me to slow down the search (the game engine keeps booting me out of the library script we factored out if I try to add any waiting). So the only real solution is to be a little careful about how large the trade search space is.

dephekt commented 1 year ago

Really appreciate you trying to fix issues here still @bhayden53. Thanks for the info around the search space and mules with nothing to do. I generally keep my search space pretty small (e.g. never more than 10 systems, usually closer to 5-7) but the issue I was running into may have been "too many mules for the budget and demands of the station". I'll try to be aware of that moving forward.

bhayden53 commented 1 year ago

@dephekt thanks for the comment. One other thing worth mentioning; on the budget aspect, what I've found in the past is that if you don't give the manager the full budget they ask for, they'll only allow one trade to be queued for a certain ware. So, say you're trying to move 10 shiploads of a ware, so you assign 5 mules; if the budget isn't maxxed on the station that needs the wares, they won't allow all 5 ships to start trading with them, just the first one or two to queue up the trade. They quietly stop returning trade requests for that ware (my hunch is in order to preserve money for trades for other wares). I say "quietly" because the trade menu still shows the same demand, the engine itself just stops returning the trade(s) through the function we have access to in aiscripts.

Sakata-MC commented 1 year ago

Really hope that someone can pick up on this, as the supple mules are super useful, but generate so much lag that I can't use them.

Misunderstood-Wookiee commented 1 year ago

If someone is willing to re write stuff so we don't need the other script running and the work is done in the ai scripts per mule then yeah we can tidy that up fairy easily with the usual wait function

Best Regards, Geoffrey Hughes

On Tue, 18 Apr 2023, 1:16 am Sakata-MC, @.***> wrote:

Really hope that someone can pick up on this, as the supple mules are super useful, but generate so much lag that I can't use them.

— Reply to this email directly, view it on GitHub https://github.com/Misunderstood-Wookiee/Mules-and-Warehouses-Extended/issues/161#issuecomment-1511571162, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFH3SZ2GVI4NU4JNUKPTWPDXBVNF5ANCNFSM6AAAAAAVVDUWK4 . You are receiving this because you commented.Message ID: <Misunderstood-Wookiee/Mules-and-Warehouses-Extended/issues/161/1511571162 @github.com>

bhayden53 commented 1 year ago

I have an idea, let me investigate if it will work

bhayden53 commented 1 year ago

Ok I don't think there are any technical blockers, here is the proposal.

Misunderstood-Wookiee commented 1 year ago

Could actually tie it into how many mules are concurrently active.

Less mules more aggressive More mules less aggressive And ramp up an orders aggressiveness in based on how long its been trying.

That way it doesn't start out at full send so to speak and if you have a lot of mules or badly configured empire the whole system kind of operates like a multi threaded machine and allocated how aggressive the searching is

Best Regards, Geoffrey Hughes

On Tue, 18 Apr 2023, 3:10 am Brian Hayden, @.***> wrote:

Ok I don't think there are any technical blockers, here is the proposal.

  • A new param called "search depth". Ranging from 5% to 100%
  • the param controls the amount of available trades the mule will evaluate before picking the best one. At 100% it is the current behavior. At 5% it's evaluating 20 times less trades than it is currently.
  • Each list of trade offers will be shuffled every time the script runs, so if the setting is low and the mule finds no valid trades, it might find one the next time.

— Reply to this email directly, view it on GitHub https://github.com/Misunderstood-Wookiee/Mules-and-Warehouses-Extended/issues/161#issuecomment-1511763779, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFH3SZ2FXNUWUK3FC6HXQFLXBV2QVANCNFSM6AAAAAAVVDUWK4 . You are receiving this because you commented.Message ID: <Misunderstood-Wookiee/Mules-and-Warehouses-Extended/issues/161/1511763779 @github.com>

bhayden53 commented 1 year ago

hmm. I don't know if I have access within an aiscript to how many ships are using that order.

Misunderstood-Wookiee commented 1 year ago

No but you should be see how long a ship has been trying for in ticks then ramp up to try expedite the order.

While orders being fulfilled reset this what lack of better term priority level.

So consistently idle mules will try hard for s while then ramp down if ticks go on too long maybe just pop up yo plauer that mule is taking too long and manually intervention is needed to resolve as be the case with improper use or something.

That means in theory, mules which are busy are on a low priority and low attention level while ones still searching get higher attention.

Best Regards, Geoffrey Hughes

On Tue, 18 Apr 2023, 3:16 am Brian Hayden, @.***> wrote:

hmm. I don't know if I have access within an aiscript to how many ships are using that order.

— Reply to this email directly, view it on GitHub https://github.com/Misunderstood-Wookiee/Mules-and-Warehouses-Extended/issues/161#issuecomment-1511771688, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFH3SZ7Z6PAY3KP23KAZFNTXBV3H5ANCNFSM6AAAAAAVVDUWK4 . You are receiving this because you commented.Message ID: <Misunderstood-Wookiee/Mules-and-Warehouses-Extended/issues/161/1511771688 @github.com>

Probe1 commented 1 year ago

[=ERROR=] 679235.89 AIDirector::Move(): Possibly infinite wake request loop: supplymule on entity 0x388b0, wake reason mask=0020 (Most likely cause: Script calls a script that returns immediately)

L class trader was set to supply mule and ten L class traders were set to mimic commanders orders. Performance tanked after a some time. I checked the debug log, found this, removed the assignments and orders for the fleet and all the performance issues went away.

Vectorial1024 commented 1 year ago

[=ERROR=] 679235.89 AIDirector::Move(): Possibly infinite wake request loop: supplymule on entity 0x388b0, wake reason mask=0020 (Most likely cause: Script calls a script that returns immediately)

L class trader was set to supply mule and ten L class traders were set to mimic commanders orders. Performance tanked after a some time. I checked the debug log, found this, removed the assignments and orders for the fleet and all the performance issues went away.

According to experience, you either insert a "sleep 1ms" somewhere in the AI script, or just refactor to use Mission Director; using MD does not have this very strange restriction.

I vaguely remember Civilian Fleets having this problem in one of the very very early version, and I decided to refactor the main "reaction" AIScript library function to a "signal-the-galaxy" MD listener script.

bhayden53 commented 1 year ago

I've seen this error as well, and my suspicion was that it was happening when there were no valid trades sent out to the trade evaluation script, just empty lists. I didn't think it was specifically causing performance issues, so I didn't bother figuring out how to fix it. But perhaps it is causing problems, according to this user.