Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
I was thinking to have 2 set of antenas on each dispatcher
One with a very short range for compile and assign really really nearby drones
and a long range antena for the rest of functionalities, remote access, etc.
and just make sure to turn off long range antena while setting up drones.
I'll give it a try
I have a base at a moon's surface and my main ship both with its own dispatcher.
"command:create-task:group-constraint:B" should not be hard to implement though.
I understand the purpose of group-constraints to limit the task to a single type of agent. Not trying to run multiple tasks on a single dispatcher, just use one group to trigger a different group.
What I was hoping is that it was possible to trigger a group-constraint for a different group than the triggering agent. For example:
Drone group A: SG miner w/ H2 thrusters.
Drone group B: LG miner w/ Ion thrusters.
Drone A moves into position above the deposit via RC. Uses a 'create task' command, but instead of triggering the task in group-constraint for type A, it routes it to type B (<<This is the part I'm not sure if it's possible). Drone A moves away via RC, while drone type B moves in to start drilling.
Something like "command:create-task:group-constraint:B"? Though I don't think that exists, is there something with a similar functionality?
Is there a way to 'create-task' but aimed at a different group-constraint? I (think I) understand how those interact, but not sure how to pipe the 'create-task' command to a different group.
(So that, for example, a SG drone might be able to send LG miners to its location ... or a non-miner drone running as an Agent can scout out deposits, and then send mining drones to dig it out.)
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?
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..
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.
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.
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.
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.
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??
*// 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 :)
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.
Looks like it shuffled the shaft order in a weird way. Are shaft ids alright when you hover over them on GUI?
image [freeimage.host]
Gonna test different option combinations to see what happens
Thank you!
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.
Great job!
BTW, is the new TerrainClearingMode functionality already documented somewhere? Looked through the docs and did not see it.
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
Certain scripts may be broken by 206 by the way, I expect some amount of reports from script authors.
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.