DUDE you rock... Thank you for explaining this. So many viedos out there do not explain what each item does or how to do it. This is starting to make since now. TYVM!!
Thank You, unfortunately the only place where some of my behaviors have been shared currently is Desynced Discord. This point to point behavior however I deemed too simple to share prepared, apologies for that. There should be 'generation 5 dump' however that includes mostly autonomous mining teams.
my transporter do not wait to its full by that check space on item... it just take off even with 1 stack ... hm. .rest of the script work. i made exact same settings on all the boxes as you.. and i see it work for you on video.. wierd it not work for me then..
I am looking for help with mining bots and a single transport bot.. problem i am seeing is i want the transport bot to stay until he is full and then transport items
Simplest method, used widely in the community is to use reloading method or bot in form of 'coordinator' or 'commander' bot. This way simply set the 'reloading' bot as a store for miners, and use behavior from here to keep the transporter going between the reloading bot and the base. It is possible however to create more advanced automation, though I would stay simple early on.
Hello,I play this game yesterday.I'm using behavior system,I can't let the robot automatically get the storage block it should go to.I have to manually link the storage block like you.Could you solve this problem？
Franly automatic storage block assignment is not something that I would recommend for most cases before most recent public update, but currently: Set up the storages to send specific signal, perhaps 'green', 'yellow' or whatever other signal You will not be using. Then get your robot to loop through the entities with the signal in question, and save it as a variable or register You want to use as storage. Loop signal can be used to read signal from any distance.
As the tutorial was mostly on basics, I failed to cover one detail of behaviors, which is my bad, and I will have it corrected as soon as I am able to, which might be on 15th of August, as that is the Early Access release date. Now, the important part - explanation why: Some instructions in Desynced have hidden (or more precisely - implied/implemented) delays. Reason for those delays differ depending on instruction itself, however the key point to take out of that detail is that some instructions, while implemented, will not continue with logic until the instruction is complete. In case of 17:04 that would be both Pick Up Items instruction and Drop Off Items instruction. As they are functionally nearly identical let me break them down into 'substeps' of instruction, as they were when recording it, and both have added delays: - Step 1 - move to target - Step 2 - perform the exchange (request item -> transfer item if present -> finish the exchange) Step 1, is, just like 'move' command (any move command with exception of 'move (async)' command) orders unit to go to the target, and wait until the unit is near to, or next to the target. Step 2 on the other hand is the 'transfer' part. As You could see when unit transfers the goods, the transfer is not instantenous (though close to it), If my memory serves me correctly it should be about 1 tick of the transfer animation/procedure. This tick is also part of 'waiting' until it is finished, before any further logic is performed. Thus both 'Pick Up items' and 'Drop Off Items' act in this case as delays. All in all nstructions, from top of my head that include hidden delays are: - Radar (unit is waiting until scan cycle completes, and then returns a value) - Scout (unit is moving to close unexplored coordinates) - Move (all variants - move, move distance, move in direction, with single exception of move (async) - unit is moving to the target, and continues after it arrives to the destination, which is usually next to the target) - Pick Up Item, Drop Off Item, (and other item transfer commands) - delay is waiting until the transfer is completed or moving to the target in case of pick up and drop off variants. I think that equipping or unequipping components and mine command also have that delays, for performing the processes involved, though I am not willing to make that a definite claim without access to working demo at the very least.
Unlock seems too counterintuitive. I think it would have been better if 'pick up' did the same and had 'can't fit any more' output, may be with a register slot to output/save what was picked.
Unlock itself is simply designed to process multiple behavior instructions within a single tick, and to boost the speed of logic in rest of behavior. It does not do anything beyond that. It would be a nice idea to see pickup have 'error' branch where the command failed, possibly with 'no space' being one of those.
I like your videos, but I'm struggling to follow sometimes. I think its worth it to motivate solutions a bit more. For example, in the very beginning around 2:35 you said you don't want to be limited by the power range. What you wanted to say is that this form of automatic logistics movement works only within the power range (if that is true) and you are now going show a method that works even for nodes outside your power range. I noticed this in the other videos as well. You explain in great detail a solution, but you should also explain what problem you are actually solving right now.
@@Sebastian-hg3xcThank You very much for insight. I will attempt to include more of explanations of the problems that need to be solved explanations in the next remake of those videos, as I will be remaking them partially due to low sound volume on multiple cases. I appreciate the feedback. New version of some guides should appear either later today, or tomorrow evening.
DUDE you rock... Thank you for explaining this. So many viedos out there do not explain what each item does or how to do it. This is starting to make since now. TYVM!!
Thanks for taking the time to explain things. finally a good tutorial
thanks, well explained, seriously helpfull!
Nice, I didn't know how to do it! thanks!
Спасибо большое
Great vid. Do you have a link or a place to get the behaviors you’ve made?
Thank You, unfortunately the only place where some of my behaviors have been shared currently is Desynced Discord. This point to point behavior however I deemed too simple to share prepared, apologies for that. There should be 'generation 5 dump' however that includes mostly autonomous mining teams.
my transporter do not wait to its full by that check space on item... it just take off even with 1 stack ... hm. .rest of the script work.
i made exact same settings on all the boxes as you.. and i see it work for you on video.. wierd it not work for me then..
I am looking for help with mining bots and a single transport bot.. problem i am seeing is i want the transport bot to stay until he is full and then transport items
Simplest method, used widely in the community is to use reloading method or bot in form of 'coordinator' or 'commander' bot. This way simply set the 'reloading' bot as a store for miners, and use behavior from here to keep the transporter going between the reloading bot and the base. It is possible however to create more advanced automation, though I would stay simple early on.
What I have to do to take every item, but not specific ones?
Apologies for late reply - simplest method would be to use 'pick up items' with only source set and keeping item/amount blank.
Hello,I play this game yesterday.I'm using behavior system,I can't let the robot automatically get the storage block it should go to.I have to manually link the storage block like you.Could you solve this problem？
Franly automatic storage block assignment is not something that I would recommend for most cases before most recent public update, but currently: Set up the storages to send specific signal, perhaps 'green', 'yellow' or whatever other signal You will not be using. Then get your robot to loop through the entities with the signal in question, and save it as a variable or register You want to use as storage. Loop signal can be used to read signal from any distance.
17:04 Strange that the game didn't notify you that comand limit per tick was reached in loops without "Wait 1 tick" comands.
As the tutorial was mostly on basics, I failed to cover one detail of behaviors, which is my bad, and I will have it corrected as soon as I am able to, which might be on 15th of August, as that is the Early Access release date.
Now, the important part - explanation why:
Some instructions in Desynced have hidden (or more precisely - implied/implemented) delays. Reason for those delays differ depending on instruction itself, however the key point to take out of that detail is that some instructions, while implemented, will not continue with logic until the instruction is complete.
In case of 17:04 that would be both Pick Up Items instruction and Drop Off Items instruction. As they are functionally nearly identical let me break them down into 'substeps' of instruction, as they were when recording it, and both have added delays:
- Step 1 - move to target
- Step 2 - perform the exchange (request item -> transfer item if present -> finish the exchange)
Step 1, is, just like 'move' command (any move command with exception of 'move (async)' command) orders unit to go to the target, and wait until the unit is near to, or next to the target.
Step 2 on the other hand is the 'transfer' part. As You could see when unit transfers the goods, the transfer is not instantenous (though close to it), If my memory serves me correctly it should be about 1 tick of the transfer animation/procedure. This tick is also part of 'waiting' until it is finished, before any further logic is performed.
Thus both 'Pick Up items' and 'Drop Off Items' act in this case as delays.
All in all nstructions, from top of my head that include hidden delays are:
- Radar (unit is waiting until scan cycle completes, and then returns a value)
- Scout (unit is moving to close unexplored coordinates)
- Move (all variants - move, move distance, move in direction, with single exception of move (async) - unit is moving to the target, and continues after it arrives to the destination, which is usually next to the target)
- Pick Up Item, Drop Off Item, (and other item transfer commands) - delay is waiting until the transfer is completed or moving to the target in case of pick up and drop off variants.
I think that equipping or unequipping components and mine command also have that delays, for performing the processes involved, though I am not willing to make that a definite claim without access to working demo at the very least.
Unlock seems too counterintuitive. I think it would have been better if 'pick up' did the same and had 'can't fit any more' output, may be with a register slot to output/save what was picked.
Unlock itself is simply designed to process multiple behavior instructions within a single tick, and to boost the speed of logic in rest of behavior.
It does not do anything beyond that. It would be a nice idea to see pickup have 'error' branch where the command failed, possibly with 'no space' being one of those.
I like your videos, but I'm struggling to follow sometimes. I think its worth it to motivate solutions a bit more. For example, in the very beginning around 2:35 you said you don't want to be limited by the power range. What you wanted to say is that this form of automatic logistics movement works only within the power range (if that is true) and you are now going show a method that works even for nodes outside your power range.
I noticed this in the other videos as well. You explain in great detail a solution, but you should also explain what problem you are actually solving right now.
You actually motivated the need for the behavior to solve transportation of full cargos quite nicely. 😀
@@Sebastian-hg3xcThank You very much for insight. I will attempt to include more of explanations of the problems that need to be solved explanations in the next remake of those videos, as I will be remaking them partially due to low sound volume on multiple cases. I appreciate the feedback.
New version of some guides should appear either later today, or tomorrow evening.
its boooooring game