Travel Mule only starts when the cargo space can be filled to 100%.

[morgenrot68]

Travel Mule only starts when the cargo space can be filled to 100%.

Only when 100% of the cargo space can be loaded, the travel Mule finds trade orders. It doesn't matter whether the source or the destination limits the trading volume. Also settings are not important.

FOR EXAMPLE: I want to transport 2999 units of a good to my own warehouse. The ship can load a maximum of 3000 units. The ship will not start a trade order. But if I want to transport 3000 units (max cargo), Travel Mule will start immediately.

No matter if the source generates sell orders with the quantity or the destination generates buy orders with the quantity.

I have tested this with cargo sizes of 69,000, 57,000 and 45,000. It is always the same behavior. As soon as trading is possible with only one unit less, Travel Mule will not find any trade. (searches for trade offers). According to the documentation, the limit is 80% of the cargo space of the ship before Travel Mule starts a trade. However, this limit is completely ignored.

• X4 Foundations : 3.3 (DLC Vendetta)
• Mules Extended Mod : V6.13
• I downloaded the mod from: Nexus

[bhayden53]

The travel mule has a cargo percentage slider already?

[morgenrot68]

no matter what the setting is, it will be ignored.

[bhayden53]

Can you provide a link to the nexus version you installed? Just want to double check, because someone has uploaded their own branch off of our work.

[morgenrot68]

the slider "Fill Cargo Hold"

[morgenrot68]

ok, wait a moment.

[morgenrot68]

https://www.nexusmods.com/x4foundations/mods/416

[bhayden53]

Thanks, that looks right.

Are you using civ fleets? I don't see anything that would have broken this and the code looks fine.

[morgenrot68]

Yes. But i have not use it.

[morgenrot68]

I had previously installed the original mod with supply mule.

[bhayden53]

It's possible that egosoft has changed something in one of the params we use, but this all seems fairly straightforward to me.

Could you just do a quick double check of your mod installs and make sure any previous installs are cleaned up? I wasn't sure about what your last message meant, but make sure all old travel mules are gone and only ours is there.

Could also be useful to restart the travel mule order in the game, if you find you need to clean anything up.

If none of that is a problem, I will try to get into the game later tonight and see if I can reproduce and look for a bug.

[morgenrot68]

ok, i have old versions of the mod (from the original mod) still in the extension folder. But the mod is disabled in the game menu. Is it better to delete the folder in extension?

[morgenrot68]

I have installed this mod before. But it is off in the game menu. https://forum.egosoft.com/viewtopic.php?f=181&t=417350&sid=d1482905318676efe95468f93dc05153

[bhayden53]

I think I would delete it just to be safe, especially since I'm pretty sure the ai scripts will have the same name. And definitely restart the travel mule order if you've ever had the old version of the mod activated.

[morgenrot68]

ok, I have deleted the folders. With restart you mean switching off the mod in the game extension menu again, then restart the game and switch on the mod again and restart the game. Correct?

[bhayden53]

Sorry, no I meant go to the ship, change their default order to something like "hold position" or whatever, then re-set the default order to the travel mule.

[bhayden53]

That effectively restarts the aiscript to ensure that you're using the right version

[morgenrot68]

ah,ok. it will take some time.

[morgenrot68]

unfortunately the same problem.

Here is my test environment: My own warehouse as source. My own warehouse as target. Goods: Field coils Ship: Sonra with 45.000 qm freighter capacity = Field coils max 3000.

Target warehouse Buy Offer quantity (set with logical view): 2999 Is also displayed with right click "Trade with....

Settings Travel Mule

Max Jumps: 8/15 Profit override: 90/100 "Lock Wares to use" activated Goods: Field coils Fill Cargo Hold%: 80 (I tried it with 95 and 25) Custom Stop List: Target Warehouse (of course)

Result: Search for trading orders

all as above, but with Target Warehouse Buy Offer quantity: 3000 (max freighter cargo space) Result: Mule finds trading orders and starts trading immediately.

I hope you can reproduce this.

[bhayden53]

Thanks for the specifics. I will take a look.

I see what you're trying to do to get around the issue you mentioned yesterday. Travel mule was not necessarily designed to do this, however, from reading through the code, I can't see any reason why it wouldn't work. So there's probably some subtle issue that I'm missing that will require me to get in and try to replicate your player-to-player, manual buy offer setup.

I will not be able to start actual debugging for several hours.

[morgenrot68]

Yeah, that's right. I wanted to try it again and then I came across this bug. I thought the 80% limit should work, but it didn't. After a few hours of testing I found out that the freighters only start when 100% of the cargo is transported. And that should not be the case. I think they will always do that no matter how I use travel Mule. But I am not sure.

[bhayden53]

That's definitely not how it used to work, I have used this slider a lot in the past. So an egosoft change to something we're using is not off the table either.

[morgenrot68]

Did you use the mod under 3.3 or still under 3.2 /3.1 ? Because, then it could be of course, the ego has changed something.

[bhayden53]

Yes, of course, last time I played and developed Mules significantly was pre-3.3. Not many bug reports have rolled in post-3.3 so we've been assuming things are working ok.

I would say it's likely I will only play again significantly after the next expansion, so for the time being we're definitely in maintenance mode. But this kind of potential bug obviously requires maintenance.

[morgenrot68]

Yeah, maybe nobody noticed the mistake. I've found bugs in mods that were released a long time ago but nobody noticed. The modders then fixed it and made a new version. With XR this was sometimes the case. Somehow I always seem to do something that others don't do.

[bhayden53]

Taking a look now. The first thing to mention is that I can tell the slider does work in some circumstances.... I found a ware in my save that would fill my cargo to 50%, and without setting a custom destination, trades for that ware are only found if I reduce the slider below that value.

Now, however, I am trying to get it to trade between two player-owned stations, and even with the slider low, it's not finding the trade. So as of now I think it has something to do with manually setting a player-owned destination.

I am guessing we just never anticipated using travel mules in this way. Will keep looking for the cause and if the solution is simple, I'll try to get a fix so you can use them in this way.

Worth mentioning it's probably good if you want to use a travel mule to move wares like this to lower the profit override slider. It's not the cause of this bug, just worth mentioning.

[morgenrot68]

Hello again, i have now tested the mod again on a clean x4 installation. No other mods, except the Mule mod. i wanted to make sure that a mod conflict doesn't cause the error. since i don't have my own stations on my clean test installation, i tested the behaviour with npc as source stations. I have created a trade which at first is more than 29.000 sqm (more than max freight). This worked. Exactly 29.000 qm were transported. But then I created a trade from an npc station to my PHQ. This trade had about 28.500 freight. So a little under max freight. That didn't work, they were looking for trade offers. As I said, NPC to the player. Apparently it does not work as soon as Target is the player.

[morgenrot68]

Maybe it helps.

[bhayden53]

I believe I found an issue related to integer division. i.e. 80/100 in X4 returns 0, not 0.8.

However, this should cause the slider to always fail, so I need to double check why it worked for me earlier.

[morgenrot68]

Yes, that makes sense. I think you can handle it.

[morgenrot68]

of course it is 0, when its an integer division.

[morgenrot68]

it must be floatpoint.

[bhayden53]

Python3 changed integer division to produce a float because it was such a common bug for python2 developers.

Unclear when this bug was introduced in our code, or if egosoft changed the behavior of integer division.

Me being a python developer, there's a decent chance I introduced this bug :) But I wouldn't rule out egosoft changing it (or the variable I'm pulling from a float to an int) either.

[morgenrot68]

Ok, I'm not familiar with Phyhton but in C++ I have to make sure that I use the right variable.

[morgenrot68]

maybe ego wanted to correct the code.

[bhayden53]

Ok, this fixes it.

But there appears to be integer-division all over-the-damn-place in this script.... and probably in station and dist and maybe even supply mule as well. I feel like I need to take a pass through and make sure any division is explicitly float-ified

[morgenrot68]

oops, that sounds like work. sorry, that wasn't my intention. but i had some other things with the other muls. i just hadn't dealt with that in detail yet.

[bhayden53]

That's alright, regex is making the search tolerable.

I'll try to get something merged tonight.

[morgenrot68]

very good, ok, it is already night in germany. i will come back tomorrow.

[bhayden53]

https://github.com/Misunderstood-Wookiee/Mules-and-Warehouses-Extended/pull/97

[Misunderstood-Wookiee]

Float point hmm I really cannot recall it being the case before I think Egosoft may have decided to change how the math works. I'll check the changes for modders later tonight. I have the game installed again too.

On Thu, 22 Oct 2020, 8:54 am Brian Hayden, notifications@github.com wrote:

Ok, this fixes it.

But there appears to be integer-division all over-the-damn-place in this script.... and probably in station and dist and maybe even supply mule as well. I feel like I need to take a pass through and make sure any division is explicitly float-ified

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/Misunderstood-Wookiee/Mules-and-Warehouses-Extended/issues/96#issuecomment-713899128, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFH3SZY5BJVANBP43MOZGKDSL5KAHANCNFSM4SZ7OXOA .

[Misunderstood-Wookiee]

@bhayden53 > #97 Went ahead and released these fixes. df54a6b

[morgenrot68]

Hello, thank you for the quick repair. It seems to work. Great work. But now I have a new problem.

It's about Supply Mule. Should I open a new bug tracker? I think I found another bug. :-(

[bhayden53]

Go ahead and open a new ticket and explain it the best you can

[morgenrot68]

Can you tell me what errors were caused by the integer bug in the mules, or which functions were affected?

Maybe so: Travel mule, I already know. Distribution Mule? Supply Mule? Station Mule?

[bhayden53]

The only error I definitively identified was the one in travel mule; the rest of the scripts, I simply made sure every division I could find had at least one float involved.