yes that is not a bug it’s just because you use the cargo hold ans not ore hold
i can make an update in my bot for set option for use cargo hold or ore hold but i think it’s not worst because ore hold is more big than cargo hold
I’m actually having the exact same issue when flying in a Procurer. The code isn’t recognizing the ore hold % and does not warp back to station when at the specified capacity. The code worked perfectly when i was flying the same setup with a Retriever but not in a Procurer.
When docked, it reads the core hold, unloads and undocks perfectly, just doesn’t read the % capacity in hold while mining.
“CaptionString”: “ore hold fill: %, mining range: 15000, mining modules (inactive): 2(0), shield.hp: 100%, retreat: , JLA: , overview.rats: 0, overview.roids: 4, offload count: 2, nextAct: InBeltMineStep”,
you can see where it leaves “ore hold fill: %” instead of writing “ore hold fill: 45%” for example.
Like i said, everything works great in a venture and retriever but just doesn’t pick up the hold in a procurer for some reason. i haven’t tried out a covetor yet, though.
What does the API Explorer show you for OreHoldCapacityMilli?.Used and OreHoldCapacityMilli?.Max?
Maybe, the important difference will be visible from a screenshot. Therefore I suggest you take a screenshot for both setups, one for working and one for not working and show them here. The most important part here is the capacity gauge in the inventory window which is where the capacity values are parsed.
“CaptionString”: “System.Exception: compilation error: (67,1): error CS1529: A using clause must precede all other elements defined in the namespace except extern alias declarations\r\n at BotSharp.ScriptRun.ScriptRun.<>c__DisplayClass61_0.b__0()”,
In Current State tab, this shows this:
Next statement to execute
Location: Line 66