Actually yes, battery workaround would work, I just need to add set-value wrapper for required charge level. Halt kicks in at 0.2 charge, then a drone waits till it's 0.8.

Alright, been playing with this for a day. Still have some questions (see comments), but I've got a few ideas already.

Allow a "designator" vehicle, such as a scouting drone, or the carrier itself, via raycast tasks. Maybe specify a group tag as argument, and broadcast via IGC to all nearby dispatchers, who would release matching tagged miners.

Actually, do raycast jobs work with camera panning, or is it always straight out from the camera block? it's always forward, I checked.

Being able to start a task directly by passing a gps for example. This would allow for separate scouting, and also for manual "saving" of tasks for resuming later.

Actually, maybe also a simple pause/resume command. Would be useful early game, when you have one drone, a ♥♥♥♥♥♥ starter base, and a whole one cargo container that's constantly full.

Tag dispatchers, and allow manually assigning miners to a dispatcher tag, so you can have multiple carriers nearby, each with its own couple drones. While these would presumably go out in different directions, setup is likely to happen at base, where it wouldn't be uncommon to have multiple dispatcher carriers at a time.

You already mention H2 drone support, which is of course very desirable. I usually live on Pertam, where atmo thrusters are... of limited use.

Allow specifying a maintenance dock, area, something, so they can go to some place with welders or just park themselves out of the way.

Allow a drone to estimate its own dimensions for shaft radius default.

Lift thrust sanity check on startup: if all inventories were full of stone/ore/ice, would we still have enough lift in current gravity?

Is there anything you can do about the kinda-sorta-required row layout for base connectors? I tried a 3x2 layout, but it caused collisions aplenty.

I'd actually be very interested in looking through the unminified code of SCAM and AutoPillock, if you're okay with that.

Some sort of general status display on the dispatcher. How many drones out, how much ore collected, how much is left of the task, how many shafts done, are we currently active, idle, etc.

Some of the blocks seem to require special names, such as the connectors and the forward-gyro. Definitely would like to change that somehow, maybe by specifying the blocks manually via set-value?

I might have seen wrong, but I think the script cuts off and goes back to unload when the containers are full. In most drones, the drills themselves add a very significant amount of additional storage. It would definitely be worth letting them fill up.

Oh, and if you're worried about complexity for the user, bring it on. This thing is the best since sliced bread! I would also be 100% ok with using multiple PBs, especially if that makes things easier for you. Sounds like merging the scripts was a nightmare.

Oh and this happened to all active drones on world reload. Recompiling would see the same exception a few seconds into the run. Fix was to recompile, immediately clean state storage, then recompile again.

0.00: Assigned role: Agent
0.00: subset: 79
0.00: Added logger: Scm-A LCD Log
4.97: CommandAutoPillock: command:create-wp:Name=DynamicDock.echelon,Ng=Forward,AimNormal=-0.157004566704353;-0.776567004927712;-0.610158383447758,TransformChannel=docking:-0.0290336008183658:-0.309992214199156:-23.2477967508603:command:pillock-mode:DockingFinal
4.97: MinerController -> lastAPckCommand: command:create-wp:Name=DynamicDock.echelon,Ng=Forward,AimNormal=-0.157004566704353;-0.776567004927712;-0.610158383447758,TransformChannel=docking:-0.0290336008183658:-0.309992214199156:-23.2477967508603:command:pillock-mode:DockingFinal
4.97: Added DynamicDock.echelon, total: 1
4.97: Standby -> CwpTask
4.98: HC EPIC FAIL
NTV:docking
Behavior:Deserialized Behavior
System.InvalidOperationException: Nullable object must have a value.
at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
at Program.<>c__DisplayClass71_1.<Ų>b__12(Vector3D Â)
at Program.à.é(Int32 è, Action`1 ç, N Þ)

Początkowo opublikowane przez Kaito:

Alright, been playing with this for a day. Still have some questions (see comments), but I've got a few ideas already.

Thanks for your participation and awesome feedback, it's motivating to see truly engineers' response! I'll reply more detailed on everything a bit later, gimme some time.

Just now I can say some of your suggestions are already on the list, some I considered before but thought they were not in high demand.

About your bug report: that happens to drones that were in dock transition state when you re-init world. My approach to de-serialize everything from PB Storage (to let drones seamlessly continue their last actions) was wrong and led to this bug, when drone ends up in a state not appropriate to environment (it expects being fed with docking vectors by the Dispatcher, but Dispatcher purges state of its' connectors on initialization). I have to carefully revise my persistent state part of the script. You intuitively did the only thing that would rescue them from this faulty state.

Początkowo opublikowane przez Kaito:

Allow a "designator" vehicle, such as a scouting drone, or the carrier itself, via raycast tasks. Maybe specify a group tag as argument, and broadcast via IGC to all nearby dispatchers, who would release matching tagged miners.

Dispatcher can handle create-task-raycast, it requires user to set group-constraint value. I usually parked my flying base near spot and casted task from rotor designator turret. I haven't even considered having deeper relation tree like root->dispatcher->drone yet, because I've hardly imagined anyone bothering with more than one dispatcher carrier.
That makes sense for high G environments with large rover carriers and single base, for roleplaying reasons or whatever.

Początkowo opublikowane przez Kaito:

Being able to start a task directly by passing a gps for example. This would allow for separate scouting, and also for manual "saving" of tasks for resuming later.

Nice feature for planets, but no convenient way of doing that in zero-G with unknown affiliation plane/normal (use two GPS points?).

Początkowo opublikowane przez Kaito:

Actually, maybe also a simple pause/resume command. Would be useful early game, when you have one drone, a ♥♥♥♥♥♥ starter base, and a whole one cargo container that's constantly full.

It should be possible to use force-finish for that reasons. It does not clear task-related state and you can resume with command:mine directly on the drone, or command:global:command:mine for everybody (likely ignoring new group-constraint though!)

Początkowo opublikowane przez Kaito:

Tag dispatchers, and allow manually assigning miners to a dispatcher tag

Yeah that's another concern related to dispatcher-dispatcher relations. This might happen in the future, now the only workaroung is to turn-off idle Dispatcher instances or reduce antenna ranges so groups won't overlap.

Początkowo opublikowane przez Kaito:

Allow specifying a maintenance dock, area, something, so they can go to some place with welders or just park themselves out of the way.

Thats a big question to think about. Flying in grid damaged state can be dangerous, so all checks happen when already connected. In case of damage, drone halts itself and waits for fixes. In some critical state, like losing all thrust in some direction, there usually would be exception thrown and the drone tries to release control immediately. And there are no specific sanity checks like losing all drills or kind of that yet. Dunno, just now the benefit of freeing one occupied connector automatically seems not worth it considering added risks and complexity. Maybe at least add some halt command broadcast in case of autopilot exception so all drones would freeze in place or something.

Początkowo opublikowane przez Kaito:

Allow a drone to estimate its own dimensions for shaft radius default.

That would be nice to have, I already sketched a simple solution accounting for drills position relative to forward reference gyro.

Początkowo opublikowane przez Kaito:

Lift thrust sanity check on startup: if all inventories were full of stone/ore/ice, would we still have enough lift in current gravity?

Normally it should not be full. When you launch drones with mine or create-task commands, it starts in the same state as if it never stopped, trying to flush all containers, checking batteries, etc, and should not launch until all conditions are met.

Początkowo opublikowane przez Kaito:

Is there anything you can do about the kinda-sorta-required row layout for base connectors? I tried a 3x2 layout, but it caused collisions aplenty.

I consider some ways of doing that but haven't came up with smart/easy enough fix. One way of doing this would be sorting shafts by distance from dock and assigning echelons dynamically (atm they are tied to drones until recompile).

The reason it's complex is my approach to path locking. I ended up with only one critical section, it's area above mining shafts - only one drone can traverse it at a time. When drone goes docking, it climbs to echelon and releases that lock. Since this point, it goes to dock point in a Г-shape uninterrupted. Another drone departs as soon as it gets the lock. It ascends above dock and goes the same Г-path, but at different echelon. With only one lock drones spend less time waiting, but enforces that row layout for ports (imgaine farther row drone departs to lower echelon when higher one drone arrives at front row - they collide above front dock).

Początkowo opublikowane przez Kaito:

I'd actually be very interested in looking through the unminified code of SCAM and AutoPillock, if you're okay with that.

Sure, I'll clean up it a bit first, there are some half-аssеd or abandoned features after merge.

Początkowo opublikowane przez Kaito:

Some of the blocks seem to require special names, such as the connectors and the forward-gyro. Definitely would like to change that somehow, maybe by specifying the blocks manually via set-value?

There is a constant field on top of the script for dispacher dock naming, I'll add the same for forward-gyro. Set-values won't work as-is, because the initialization happens before set-value execution.

Początkowo opublikowane przez Kaito:

I might have seen wrong, but I think the script cuts off and goes back to unload when the containers are full. In most drones, the drills themselves add a very significant amount of additional storage. It would definitely be worth letting them fill up.

I don't distinguish grid inventories specifically. I think that's because I test fullness check against 0.8 for whatever reason - I'll relocate that one to set-values.

Thanks for addressing my feedback. I'll go over it again later.

Regarding the new release, setting ForwardGyroTag to anything other than the default results in an exception during initialization. I suspect you might have forgotten a hardcoded value somewhere?

Setting the host dock tag to anything other than the default (and renaming the host connectors) results in 2 duplicate (total of 3) entries in the dispatcher state for the same miner, all waiting for docking lock. That's fine, actually. User error.

Drone still often gets stuck on GoingToUnload and Docking, hovering up and down in place forever until I recompile the drone PB. The log doesn't seem interesting, should I post it anyway?

I have two dig "sites" near my base. One is a stone hole I'm using for early resources (something something scarce resources), and another is an ice hole. They're both about 700m away from base, both go over a ridge, but they are in opposite compass directions. Stone dig works fine, drone goes back and forth and is happy. Ice hole though, it always gets stuck both above the shaft, and above the dock.

command:set-value:getAbove-altitude:x works on the drone, but not on the dispatcher.

Początkowo opublikowane przez cheerkin:

Początkowo opublikowane przez Kaito:

Allow a "designator" vehicle, such as a scouting drone, or the carrier itself, via raycast tasks. Maybe specify a group tag as argument, and broadcast via IGC to all nearby dispatchers, who would release matching tagged miners.

Dispatcher can handle create-task-raycast, it requires user to set group-constraint value. I usually parked my flying base near spot and casted task from rotor designator turret. I haven't even considered having deeper relation tree like root->dispatcher->drone yet, because I've hardly imagined anyone bothering with more than one dispatcher carrier.
That makes sense for high G environments with large rover carriers and single base, for roleplaying reasons or whatever.

I don't normally put my cameras on rotors, since I play with weaponcore, which adds camera panning. I don't suppose that's accessible via script API?

Początkowo opublikowane przez cheerkin:

Początkowo opublikowane przez Kaito:

Being able to start a task directly by passing a gps for example. This would allow for separate scouting, and also for manual "saving" of tasks for resuming later.

Nice feature for planets, but no convenient way of doing that in zero-G with unknown affiliation plane/normal (use two GPS points?).

Mostly for planets, yeah. Perhaps a default normal of whatever orientation the dock connector has, since you want it more or less aligned anyway, with an option to specify a second GPS?

Początkowo opublikowane przez cheerkin:

Początkowo opublikowane przez Kaito:

Actually, maybe also a simple pause/resume command. Would be useful early game, when you have one drone, a ♥♥♥♥♥♥ starter base, and a whole one cargo container that's constantly full.

It should be possible to use force-finish for that reasons. It does not clear task-related state and you can resume with command:mine directly on the drone, or command:global:command:mine for everybody (likely ignoring new group-constraint though!)

Oh nice. Probably worth adding that to the command reference.

Początkowo opublikowane przez cheerkin:

Początkowo opublikowane przez Kaito:

Allow specifying a maintenance dock, area, something, so they can go to some place with welders or just park themselves out of the way.

Thats a big question to think about. Flying in grid damaged state can be dangerous, so all checks happen when already connected. In case of damage, drone halts itself and waits for fixes. In some critical state, like losing all thrust in some direction, there usually would be exception thrown and the drone tries to release control immediately. And there are no specific sanity checks like losing all drills or kind of that yet. Dunno, just now the benefit of freeing one occupied connector automatically seems not worth it considering added risks and complexity. Maybe at least add some halt command broadcast in case of autopilot exception so all drones would freeze in place or something.

When I wrote this, I thought maintenance happened upon damage. I now realize it happens when battery runs low. You're right that it's probably better to just not try to fly very far at all if a terminal block gets damaged, although I suppose you could see if what we lost is a flight system block or not. Complex damage assessment is probably not necessary. Probably either freeze in place, or try to land as close as possible outside of the shaft. Maybe worth alerting the dispatcher, and displaying an alert for the operator?

Początkowo opublikowane przez cheerkin:

Początkowo opublikowane przez Kaito:

Is there anything you can do about the kinda-sorta-required row layout for base connectors? I tried a 3x2 layout, but it caused collisions aplenty.

I consider some ways of doing that but haven't came up with smart/easy enough fix. One way of doing this would be sorting shafts by distance from dock and assigning echelons dynamically (atm they are tied to drones until recompile).

The reason it's complex is my approach to path locking. I ended up with only one critical section, it's area above mining shafts - only one drone can traverse it at a time. When drone goes docking, it climbs to echelon and releases that lock. Since this point, it goes to dock point in a Г-shape uninterrupted. Another drone departs as soon as it gets the lock. It ascends above dock and goes the same Г-path, but at different echelon. With only one lock drones spend less time waiting, but enforces that row layout for ports (imgaine farther row drone departs to lower echelon when higher one drone arrives at front row - they collide above front dock).

Sorting connectors based on proximity to the task would require reassigning echelons at trask creation time though. Maybe optionally lock the air space above the dock as well, and let the operator decide if he wants speed or a more compact dock layout?

Początkowo opublikowane przez cheerkin:

Początkowo opublikowane przez Kaito:

I'd actually be very interested in looking through the unminified code of SCAM and AutoPillock, if you're okay with that.

Sure, I'll clean up it a bit first, there are some half-аssеd or abandoned features after merge.

No rush, I'm mostly just curious, although I maybe take a stab at sending you a PR if I find myself digging through the code and fix something.

Also bear in mind that I don't think running 2 PBs is unreasonable, in case the unmerged code is easier for you to handle.

Początkowo opublikowane przez Kaito:

I suspect you might have forgotten a hardcoded value somewhere?

That's right, my bad :D
Already fixed, waits for the next update.

Początkowo opublikowane przez Kaito:

command:set-value:getAbove-altitude:x works on the drone, but not on the dispatcher.

Hmm just checked and it worked for me.
What I did: I had no set-value on drone, I changed command:set-value:getAbove-altitude:x to 100 on Dispatcher, recompiled Dispatcher, created task from the drone. Dispatchers' log said:
Propagating set-value:'skip-depth'
13.05: Preparing start for mining group 'h2'
Got new mining task
The drone flew mining, the first waypoint on create-task ignores getAbove-altitude (maybe that led you to suspicion that it didn't work?), but then dock-shaft transitions were way above 100m as expected.
Then I used command:recall on Dispatcher. The drone which mined flew as expected at 100+ altitude to dock.

Początkowo opublikowane przez Kaito:

Drone still often gets stuck on GoingToUnload and Docking, hovering up and down in place forever until I recompile the drone PB. The log doesn't seem interesting, should I post it anyway?

Damn that's bad. I think I saw something similar on gravity drone once, but wasn't able to reproduce (then though it was messed by external gravity field).

Can you check how looks its' relative forward-gyro position and current waypoint at that moment, if you have time? To do so you can toggle:show-pstate when it throws a tantrum again - you'll see all state listing on PB echo output (sorry for inconvenience, but for now just write down XYZ values for "currentWp"). The state should switch when forward-gyro is within 0.5m from currentWp.

Then maybe try to "help" drone by attaching to remote and WASD-ing it to the side or anywhere and look what happens. I suspect something goes wrong in thrust amount / braking path calculation in gravity when you are very close to target point and straight above/below at really low speed, or something... Just no ideas at this point.

Początkowo opublikowane przez Kaito:

I don't normally put my cameras on rotors, since I play with weaponcore, which adds camera panning. I don't suppose that's accessible via script API?

Ah I see... Haven't used WC (I wonder did they mod the PB api interfaces too?). I can use only blocks' or players' world matrices to infer the raycasting position. Yeah, in this case it's Forward unit of camera. I think I can add a sensor to detect player and then you could look with crosshairs to the point, attach to Dispatcher grid and exec create-task with raycast. That would be less precise though and require to be closer to actual camera.

I also have a fancy-аss method of making tasks with mouse point and click through a transparent-LCD wall but that requires a painful building and setting up another half-ready script.

Początkowo opublikowane przez Kaito:

Mostly for planets, yeah. Perhaps a default normal of whatever orientation the dock connector has, since you want it more or less aligned anyway, with an option to specify a second GPS?

Good point, not that hard to implement.

Początkowo opublikowane przez Kaito:

When I wrote this, I thought maintenance happened upon damage. I now realize it happens when battery runs low.

I think I was confusing you a bit. Maintenance indeed checks for damage, but the check happens when you are docked. Now the flow of checks is (damage->h2->battery->depart-clearance). My philosophy was "if I'm able to make my way do dock let's do it, otherwise throw exception and release control and pray for good". And sitting-on-connector times is when we sort things out.

I think we could improve things by adding some Decommission logic - check crucial blocks every N second in the field, check H2 and battery, if we are not good - force GoingToUnload state and delegate all problems to Docked state.

Początkowo opublikowane przez Kaito:

Maybe optionally lock the air space above the dock as well, and let the operator decide if he wants speed or a more compact dock layout?

I though I was a good idea, but it kinda kills the path-segment-locking approach entirely. It gets reduced to "one drone can move outside of the shaft at once, ever". You say you have 700-1000m path to mining areas. Both locks for above-dock area and above-shafts area would block horizontal transfer too, because it intersects at endpoints. So the drone that goes to unload would wait entire kilometer timing of the second drone that had beaten him in obtaining the lock seconds earlier, to return-to-shaft.

To solve this, I think we either need to rework echelon assignment, or rebuild the pathing entirely, adding smaller blocked segments. Or I just don't see some obvious simple solution.

Początkowo opublikowane przez Kaito:

Also bear in mind that I don't think running 2 PBs is unreasonable, in case the unmerged code is easier for you to handle.

Now I have the reverse problem because I fixed some stuff in AutoPillock core part and need to "reintegrate" that back to the main APck class, lmao. I think I'll just work on the "monolith" version until it stabilizes well, then reintegrate and try to use "delegated" approach again.

Here's a new one. Drone was docking when I sent out the recall command:

3112.49: HC EPIC FAIL
NTV:docking
Behavior:Deserialized Behavior
System.ArithmeticException: Function does not accept floating point Not-a-Number values.
at System.Math.Sign(Double value)
at Program.ɂ.Ƶ(Double Ļ, Func`2 Ⱦ)
at Program.ɂ.ȭ(Vector3D Ƨ, Single ȑ)
at Program.ę.Ɯ(Vector3D Ƹ, Vector3D Ț, Boolean Ç, Nullable`1 ș, Nullable`1 ĉ, Boolean Ș)
at Program.ę.é(Int32 è, Action`1 ç, J à)
3088.77: MinerController -> SetState: WaitingForDocking=>Docking
Inert -> CwpTask
Added DynamicDock.echelon, total: 1
CwpTask -> Inert
MinerController -> lastAPckCommand: command:create-wp:Name=DynamicDock.echelon,Ng=Forward,AimNormal=-0.443512792232986;-0.379342514850197;0.812031809446421,TransformChannel=docking:-0.163560647051781:-0.276571161579341:-143.247652911115:command:pillock-mode:DockingFinal
CommandAutoPillock: command:create-wp:Name=DynamicDock.echelon,Ng=Forward,AimNormal=-0.443512792232986;-0.379342514850197;0.812031809446421,TransformChannel=docking:-0.163560647051781:-0.276571161579341:-143.247652911115:command:pillock-mode:DockingFinal
3076.99: Inert -> CwpTask
Added GoingToUnload, total: 1
CwpTask -> Inert
MinerController -> lastAPckCommand: command:create-wp:Name=GoingToUnload,Ng=Forward:-3953855.66071188:-20791.1975651756:-791722.039640981
CommandAutoPillock: command:create-wp:Name=GoingToUnload,Ng=Forward:-3953855.66071188:-20791.1975651756:-791722.039640981
MinerController -> SetState: WaitingForLockInShaft=>GoingToUnload
MinerController -> Dispatching, callback chain: 1
MinerController -> general common-airspace-lock-granted
3043.80: Inert -> CwpTask
Added WaitingForLockInShaft, total: 1
CwpTask -> Inert
MinerController -> lastAPckCommand: command:create-wp:Name=WaitingForLockInShaft,Ng=Forward,SpeedLimit=2:-3953922.18763072:-20848.0989424031:-791600.234869563
CommandAutoPillock: command:create-wp:Name=WaitingForLockInShaft,Ng=Forward,SpeedLimit=2:-3953922.18763072:-20848.0989424031:-791600.234869563
MinerController -> SetState: Drilling=>WaitingForLockInShaft
2923.65: Inert -> CwpTask
Added drill, total: 1
CwpTask -> Inert
MinerController -> lastAPckCommand: command:create-wp:Name=drill,Ng=Forward,PosDirectionOverride=Forward,AimNormal=-0.443512792232986;-0.379342514850197;0.812031809446421,SpeedLimit=0.6:0:0:0
CommandAutoPillock: command:create-wp:Name=drill,Ng=Forward,PosDirectionOverride=Forward,AimNormal=-0.443512792232986;-0.379342514850197;0.812031809446421,SpeedLimit=0.6:0:0:0
MinerController -> SetState: GoingToEntry=>Drilling
2914.94: Inert -> CwpTask
Added drill entry, total: 1
CwpTask -> Inert
MinerController -> lastAPckCommand: command:create-wp:Name=drill entry,Ng=Forward:-3953918.57070781:-20845.0053403327:-791606.857131308
CommandAutoPillock: command:create-wp:Name=drill entry,Ng=Forward:-3953918.57070781:-20845.0053403327:-791606.857131308
MinerController -> SetState: ReturningToShaft=>GoingToEntry
MinerController -> Dispatching, callback chain: 1
MinerController -> general common-airspace-lock-granted
2891.96: Inert -> CwpTask
Added drill getAbovePt, total: 1
CwpTask -> Inert
2883.84: MinerController -> SetState: Docking=>ReturningToShaft
Inert -> CwpTask
Added Dock.Echelon, total: 1
MinerController -> lastAPckCommand: [command:pillock-mode:Disabled],[command:create-wp:Name=Dock.Echelon,Ng=Forward:-3953695.13878293:-20455.7148670006:-791513.381642913:command:create-wp:Name=drill getAbovePt,Ng=Forward,AimNormal=-0.443512792232986;-0.379342514850197;0.812031809446421:-3953855.66071188:-20791.1975651756:-791722.039640981]
CommandAutoPillock: [command:pillock-mode:Disabled],[command:create-wp:Name=Dock.Echelon,Ng=Forward:-3953695.13878293:-20455.7148670006:-791513.381642913:command:create-wp:Name=drill getAbovePt,Ng=Forward,AimNormal=-0.443512792232986;-0.379342514850197;0.812031809446421:-3953855.66071188:-20791.1975651756:-791722.039640981]
MinerController -> Dispatching, callback chain: 1
MinerController -> general common-airspace-lock-granted
2878.39: DockingFinal -> Inert
2866.44: Inert -> DockingFinal
CwpTask -> Inert
2826.51: MinerController -> SetState: WaitingForDocking=>Docking
Inert -> CwpTask
Added DynamicDock.echelon, total: 1
CwpTask -> Inert
MinerController -> lastAPckCommand: command:create-wp:Name=DynamicDock.echelon,Ng=Forward,AimNormal=-0.443512792232986;-0.379342514850197;0.812031809446421,TransformChannel=docking:-0.163560647051781:-0.276571161579341:-143.247652911115:command:pillock-mode:DockingFinal
CommandAutoPillock: command:create-wp:Name=DynamicDock.echelon,Ng=Forward,AimNormal=-0.443512792232986;-0.379342514850197;0.812031809446421,TransformChannel=docking:-0.163560647051781:-0.276571161579341:-143.247652911115:command:pillock-mode:DockingFinal
2814.86: Inert -> CwpTask
Added GoingToUnload, total: 1
CwpTask -> Inert
MinerController -> lastAPckCommand: command:create-wp:Name=GoingToUnload,Ng=Forward:-3953855.66071188:-20791.1975651756:-791722.039640981
CommandAutoPillock: command:create-wp:Name=GoingToUnload,Ng=Forward:-3953855.66071188:-20791.197565

Początkowo opublikowane przez cheerkin:

Początkowo opublikowane przez Kaito:

Drone still often gets stuck on GoingToUnload and Docking, hovering up and down in place forever until I recompile the drone PB. The log doesn't seem interesting, should I post it anyway?

Damn that's bad. I think I saw something similar on gravity drone once, but wasn't able to reproduce (then though it was messed by external gravity field).

Can you check how looks its' relative forward-gyro position and current waypoint at that moment, if you have time? To do so you can toggle:show-pstate when it throws a tantrum again - you'll see all state listing on PB echo output (sorry for inconvenience, but for now just write down XYZ values for "currentWp"). The state should switch when forward-gyro is within 0.5m from currentWp.

Then maybe try to "help" drone by attaching to remote and WASD-ing it to the side or anywhere and look what happens. I suspect something goes wrong in thrust amount / braking path calculation in gravity when you are very close to target point and straight above/below at really low speed, or something... Just no ideas at this point.

Did that. Wrote down the number, not sure how to get the current position of the gyro to compare though.

But I moved it to the side slightly and then it docked. I suspect maybe this might be faulty gravity compensation? I'm on Pertam, in 1.2G.

Początkowo opublikowane przez cheerkin:

Początkowo opublikowane przez Kaito:

I don't normally put my cameras on rotors, since I play with weaponcore, which adds camera panning. I don't suppose that's accessible via script API?

Ah I see... Haven't used WC (I wonder did they mod the PB api interfaces too?). I can use only blocks' or players' world matrices to infer the raycasting position. Yeah, in this case it's Forward unit of camera. I think I can add a sensor to detect player and then you could look with crosshairs to the point, attach to Dispatcher grid and exec create-task with raycast. That would be less precise though and require to be closer to actual camera.

I also have a fancy-аss method of making tasks with mouse point and click through a transparent-LCD wall but that requires a painful building and setting up another half-ready script.

It's not WC specific, another mod called Camera Panning, by the venerable Digi, is very very popular. WC does have a PB API which does tap into the cameras for gun aiming purposes, but that won't be present with Digi's mod.

But if this is a lot of work, I'd honestly rather have a separate little designator drone. I suppose this would require a fourth mode of operation, where a grid is able to generate tasks for the network, but not claim dispatcher ownership, and also not try to carry out the task.

Początkowo opublikowane przez cheerkin:

Początkowo opublikowane przez Kaito:

Also bear in mind that I don't think running 2 PBs is unreasonable, in case the unmerged code is easier for you to handle.

Now I have the reverse problem because I fixed some stuff in AutoPillock core part and need to "reintegrate" that back to the main APck class, lmao. I think I'll just work on the "monolith" version until it stabilizes well, then reintegrate and try to use "delegated" approach again.

Doesn't MDK (VS2019 really) allow for shared "library" projects via Mixins? That might be useful for this. Keep APck separate, but merge during build, and use it as a library.

Początkowo opublikowane przez Kaito:

Here's a new one. Drone was docking when I sent out the recall command:

Interesting! Thanks, I'll look into it.

Początkowo opublikowane przez Kaito:

Did that. Wrote down the number, not sure how to get the current position of the gyro to compare though.
But I moved it to the side slightly and then it docked. I suspect maybe this might be faulty gravity compensation? I'm on Pertam, in 1.2G.

The idea was to set fw-gyro ShowOnHUD checkbox and then compare to GPS point created at those XYZ.

Gravity compensation itself is OK, it is added after everything else. I suspect the problem with accelerate/reverse logic when in close proximity to target point. I've just found that APck core does not utilize full acceleration capacity when really close to the point, but it should do. Maybe when I account for gravity in total thrust capacity I mess up that part, and drone thinks it's time to brake, earlier than needed. I'm experimenting with that core stuff tonight on Pertam too.

Początkowo opublikowane przez Kaito:

Doesn't MDK (VS2019 really) allow for shared "library" projects via Mixins? That might be useful for this. Keep APck separate, but merge during build, and use it as a library.

I completely forgot about that feature, probably could help. MDK minifier itself gave me hard times because it messed up enum identifiers and other stuff that relied on type names. Had to refactor a lot and use multiple #ignore sections.