Hi everyone,

Just noticed "adaptive docking". I didn't see the drones doing that before, but now they are and it causes a lot of crashes around the docking location.
Is there any way to disable it?

I can't find it in the arguments section, custom data, or code. Perhaps I overlooked it?

https://steamcommunity.com/sharedfiles/filedetails/?edit=true&id=3492922450 is my ship in it's current state if you want to give it a shot at trying to get the drones to move.

like, right now i dismantled the one in space, now they aren't waiting for it to do whatever so they can go next, they are trying to launch while connected to the connectors. 3 are idle, one is docking, the other is changing shaft. all are actually docked. they wont take off but they'll happily empty their hydrogen tanks trying. haha

yea i just get them reset, and not launch and if one of them is stuck in space, and i can't see the screen i just have to dismantle it.

Alright i've been having a hell of a time getting them started on teh server, they worked for a bit but when they get stuck and wont respond to commands i can't get them to get back in their paces. the drones and dispatcher have all been clear-storage-state 'd and i used a camera to run the create job task because issue

1) most of the job screens on the drones just go dark at some point so i can't use those. but i have camera job creation so that's fine i guess. recompiling a-menucommand block doesn't do it. sometimes the screen is in a different font and you can't interact with it.

2) they are all docked and on job creation they say 'ChangingShaft' while docked and they just sit there lol feel free to import and play around with the ship, i can't seem to make this script perform better than a single seat mining ship and i really want it to. Weather it's them just hanging out because they're in some queue waiting for one of the drones to hit the next step or what..

The logic is simple, look up "group-constraint" in the script arg reference. Regarding multi tasking work-around, probably I've meant using two dispatchers and two sets of drones differentiated by that value (you still can't have more than one task per dispatcher instance).

Hi @cheerkin, Thanks for the reply. You are totally right, they would collide, I was mistaken.

I see there is a group constraint, which you suggest can be used to differentiate between thruster and grid types. How can you set this up, and is it possible to create your own groups?
My goal is to have multiple tasks running from the same dispatcher. "assigning some "group-constraint"-like tag now seems as a quick dirty solution - until we get multi-tasking."
That is your comment from may 17th 2022, that is how I got the idea.

The problem is that they can collide when one of them ascends in the mining area, and another one is on the go to dock or back. In that case vertical trajectory intersects with the horizontal.
Horizontal transitions work in parallel though, they wait if they need to cross the mining "cylinder" volume.

If you imagine all possible trajectories from dock to shaft you'll see that some of them intersect because echelon is fixed for each drone).

Proper solution is to dynamically assign echelons for every transition based on how far apart shaft/dock are, but I haven't got there just yet.

I have built a dispatcher ship with 16 drones on it. Sadly, when executing a task, the dispatcher sends 1 drone over at a time ot the mining site or dispatcher. This means drones wait in the pits for a long time burning hydrogen.
Each drone has their own horizontal layer in which they move. In other words, they are stacked on top of each other in the air. Combining this with that each of them has their own connector, they could theoretically never collide in the air as they move vertical, then horizontal and then vertical again.
I found that 3 or 4 drones in the most efficiënt. With 4 drones, 1 waits in the pit for a couple of seconds before the 4th drone starts digging.

Another way to solve this is to basically split it into 4 groups of 4 and reduce the mining area for each group and start 4 tasks at the same time. Also possible, but perhaps risky.

Thank you and sorry. I looked there but oversaw it somehow.

yes there is you can use command:getAbove-altitude to change it by default its set to 20 and also look in the script argument refrence discussion before posting a comment that could be easly solved by just taking a minute and reading what they do.

Hey there,
i am pretty new to this script and doing my first tries with it. Allready got it set up.... i think.
But is there a way to get the drone to first climb up highher before return to base? There is a mountain between an my drone always want to hug this dude when returning.

im not 100% about the apck part tho

the ui turns black for perfomance and your drone issue might be because maybe the scripts arent updated on your ws drones that your using and for the command to swap from ui to just normal control is toggle:cc if you use apck otherwise just use a timer to toggle the stuff on your pilot seat

I never did figure it out but i can use the camera from the Barge to make them work and that works just fine. any tips on bringing back the UI that escapes me would be helpful when you get a minute :) the drones do appear to get locked up at times and be non productive BUT it seems they are waiting for one of the drones to pass a point then they all follow. not sure what's going on but if you leave them alone they get to work eventually JUST LIKE REAL LIFE!! (so immersive)

I have probably a really simple question, the drone screens are sometimes black and stay that way even after compiling. a-menuwhatever compiles but command:cc doesn't turn the interface off so i can pilot the drone with mouse. they all do this now. some screens are just black and recompiling a-menuwhatever doesn't do it. clearing save state on that drone wont' do it either.

it seems to be switching from local to this drone. i'm using Pro100's drone. number 1 which i did not change is set up to stop and start me controling the interface. for some reason now it wont do that. what can i do??

alright good luck

alright i didn't try it on the dispatcher, I wish there was a discord where we could go and just talk about this, i was using that command on the drones and that got them back (usually) but lemme give it a go here.

*// that did appear to fix most issues. i guess i need to clear task on dispatcher once everyone is back? the drones still have a waiting for shaft lock in issue but if you leave them go and the others seem to finish theirs the locked one figures it out it seems. I just want to remote into a drone carrier, use carrier camera raycast on asteroid start job, check back in 25min and jump it back home :)

on both the drones and dispatcher

try using command:clear-storage-state for fixing the drilling issue

Alright Mac and Cheese, i got em to rush off to do their thing but some of them actually drill, some of them waitforshaftlock or whatever others think they're drilling and they're not. when they get board of doing nothing eventually they all do unload final. on the screen they are all set to 'docking' and usually one is up in the air just waiting for shaftlock. some not adaptive and some are.. if you want you can PM me because i've got no idea.

no problem! :D

you got me, that did the trick and we're good. :) thanks for you help

the top of it is suppost to face the forward of the drone and the drills down

your forward gyro is setup wrong

I cannot for the life of me figure out how to asteroid mine, it will only move laterally, i can't stop controlling the screen to fly around to even test asteroid mining. what do i need to hit @_@

It seems to work fine for me, at least the hex pattern algorithm is okay. In your case maybe the issue is caused by some state leftovers or adaptive mode shenanigans - please put more context in bug reports discussion if you are able to reproduce this.

Yep the missing shafts are marked completed.
I stayed here for some time and thats what is happening:
It finishes one shaft and switches to another. It starts approaching surface where the new shaft should be, but before it touches the surface it suddenly steps back starts to switch shaft again.

Haha no way
Looks like it shuffled the shaft order in a weird way. Are shaft ids alright when you hover over them on GUI?

Hexagonal pattern is not exactly hexagonal
image [freeimage.host]

Gonna test different option combinations to see what happens

Got it!
Thank you!

Good to hear!
It does not require new user input so I haven't updated the docs. Basically now it switches the mode instead of toggling UseConveyorSystem, it still relies on the skip-depth being set correctly by a user. And the descent speed during stone clearing is faster now too.

I can confirm that now script is working fine!
Great job!

BTW, is the new TerrainClearingMode functionality already documented somewhere? Looked through the docs and did not see it.

Looking forward to the announcement of the fix. Good work so far.

Thanks, that's cool! I'd wait for the pending hotfix though, it addresses this issue. Should go live soon. After that the 0.9.251 (as well as previous versions) would work as intended (I've checked it already on the last dev build).

Hey I fixed the error, now have some warning but the compilation is fixed

change :
public VRage.Scripting.MemorySafeTypes.MemorySafeList<byte> ShaftStates = new VRage.Scripting.MemorySafeTypes.MemorySafeList<byte>();

and

ShaftStates = ParseValue<VRage.Scripting.MemorySafeTypes.MemorySafeList<byte>>(values, "ShaftStates") ?? new VRage.Scripting.MemorySafeTypes.MemorySafeList<byte>();

Hoppe will help you

I'm also having the same issue, i throw the new code into the PB and it gives the error. the old BP's dont seem to talk to each other either. i'm can't wait to finally use this though! good luck on figuring it out.

Hmm, interesting, it may be caused by certain PB system changes (that error can't be related to 0.9.251 additions). What is confusing is that I had tested it on my dev206 local build and it worked fine.
Certain scripts may be broken by 206 by the way, I expect some amount of reports from script authors.

It ddoes not work unfortunately. The error is Cannot implicitly convert systen List<byte> to VRage MemorySafeList<byte>. Seems like it is something wrong with ShaftStates field

@cheerkin Nice! Looking forward to updating the script and see how it performs.

0.9.251 is out. It takes advantage of the new drills TerrainClearingMode to remove stone even faster, and new HexSpiral task layout (enabled by default) for better coverage.

This version is intended for SE 206 update (Fieldworks) which would be shipped today evening.

Special thanks to @lizelive (discord) for providing the hex spiral algorithm.

Thanks, looks like it works. Must have been too far from the targeted asteroid. Lost a drone or two so far. But otherwise working.

Yes, no

Can create-task-raytrace to used with a camera on a subgrid? If so is there a specific way the camera needs to be set?

Idk, I'll try it later, or you can do and tell me results. You mean there were some known issues?

coming back to SE after a bit of a break, SCAM working on servers yet?

The concept of locking is allowing access to a shared thing to a single user at a time. Giving it to every miner makes no sense as it defeats the purpose in the first place. In this case, shared thing is the path were miners can potentially collide (e.g. changing shaft while other drone ascends to unload). Whoever gets the lock, owns it until its path is complete. Others must wait, otherwise they are put to the risk of colliding. Not all path segments are locked, e.g. they can go horizontally simultaneously (but not in the mining area as there are both horizontal and vertical transitions that may cross).

Yes, I noticed the collisions happening. I tested SCAM with 20 miners. one is flying to the drill site, another one is drilling, and another has finished drilling but is now just waiting for all the other miners to arrive. That’s the problem, because (as far as I understand) the dispatcher can only handle or issue a single lock to one miner at a time. I want to expand that so the dispatcher can manage and distribute multiple locks to multiple miners. If I’ve misunderstood something, my apologies.

Locking mechanism is there to protect from collisions, there is no built-in way to disable it. They mine simultaneously, locking does not affect that. You can try looping a timer with "command:dispatch" on every drone to emulate 'purge locks' I suppose, but I don't recommend that.

Hey, can the dispatcher accept multiple Miner locks at the same time, allowing several miners to do their work simultaneously (similar to the 'purge locks' command, but always active)?