Type: Mod
Name: Drone Command
Description: Swarms of combat robots controlled by circuitry.
License: CC BY 3.0
Version: 0.1.1
Release: 2015-10-13
Tested-With-Factorio-Version: 0.15.36
Category: Gameplay
Download-Url: Attached
Website: https://mods.factorio.com/mods/Adil/DroneCommand
License
License
You are free to:
Share — copy and redistribute the material in any medium or format
Adapt — remix, transform, and build upon the material
for any purpose, even commercially.
The licensor cannot revoke these freedoms as long as you follow the license terms.
Under the following terms:
Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.
Notices:
You do not have to comply with the license for elements of the material in the public domain or where your use is permitted by an applicable exception or limitation.
No warranties are given. The license may not give you all of the permissions necessary for your intended use. For example, other rights such as publicity, privacy, or moral rights may limit how you use the material.
Long description
Long description
This mod adds combat drones squads and utility buildings for them.
Defender and destroyer capsules, as well as a few of new ones can be put in the special "Transmitter" building, to be spawned as autonomous squad.
The squad behavior is defined by circuit signals you pass to the transmitter building.
Mod also adds the "Smart radar", a building that performs scan of specified position (based on the circuit input) and outputs the results through another circuit interface.
These building are comprised of two or more separate interfaces that you should use in your circuitry. Their input and output signals are updated once per second.
Additionally, there are landing pads for drones. Those are special buildings that catch dying or depleted drones near them.
These drones can be recharged and repaired with recipes cheaper than creating new robot capsules from scratch.
Among the new drones there are cargo and construction drones.
Cargo drones are capable of carrying 100 items per robot over long distances and can be sacrificed to spawn a provider chest.
Construction drone is actually a packed roboport, this drone can be used to remotely construct the roboport at a given position, or atop of the roboport ghost in the vicinity of specified position.
Good luck controlling them through combinators though. (Simpler schemes are easy to get working, but complex behaviors are challenging to implement through factorio combinators.)
This mod was designed for being fast by virtue of being conceptually simple. Battles with biters will still cause slowdowns due to, well, biters. But in normal conditions, drones themselves and their squads have microscopic effect on the fps.
Currently, the mod is mostly done in the programming part, albeit the graphics might end up a permanent placeholder.
Version history
Version history
0.1.1(13 Oct 2017): Initial release
0.1.3(14 Oct 2017): Internal changes.
0.1.4(6 Dec 2017): Probably fixed startup error happenning for some people.
Re: [MOD 0.15.36] DroneCommand_0.1.1 (13.10.17)
Posted: Thu Oct 12, 2017 11:49 pm
by Adil
Here comes the first writeup on the usage.
Doing smart radar
In this mod, I've tried to keep the interface of my special buildings simple. This however means, that much should be done on the player side. (this however is not set in stone, I just don't know better.
So, here comes part one of the guide to this mod, which is more of a guide to combinators.
Let's start small.
1
A smart radar is a composite building which has two interfaces. The one you place is the input which reads the orders and draws power. (Sorry for graphics, green never appeared to me as a bad tint before)
0.png (622.42 KiB) Viewed 7159 times
When you place it down, the output also appears.
To facilitate the use of bluperints, the spawned interfaces automatically connect to the combinators beside them, combinators build later are also affected:
05.png (102.05 KiB) Viewed 7159 times
Now, the radar itself has a very simple behavior. You pass it two special signals: "radar X" and "radar Y" and if the position specified by signals is not too far, it outputs the result of scanning a sector encompassing the position after some period of working (15 seconds currently).
1.png (167.63 KiB) Viewed 7159 times
2.png (277.39 KiB) Viewed 7159 times
The challenging part is to do the sending of the orders to the radar, which should be done with combinator logics.
2
Let's begin by fixing the outputs. I place the combinator next to input, to re-transmit the signal (input: "each" + 0, output "each"), any other elements can be attached to output of this one and the radar output will always attach itself to the input of the same transmitter.
3.png (172.14 KiB) Viewed 7159 times
I also use similar combinators in the network to uncouple signals or to introduce the delay. Lets name them "pass-through combinators".
Next, radar always outputs coordinates of the sector it is located in. Let's make it scan chunks based on the shift relatively to its own map sector. The shift can be specified in the constant combinator on the left, and the arithmetic combinators add in the radar position (rounded to up to chunk size, vanilla radars also operate on chunks).
2a.png (459.99 KiB) Viewed 7159 times
Note: I've also placed the pass-through combinator before the radar input. It is a good way of seeing the passed signals. When the networks get more complex, I stick such combinators at the interfaces between different subsystems.
3
The radar is still not doing much. We need to somehow iterate over different positions and send those positions to its input.
But first, let's implement the detection of the moment, when radar has scanned a sector. The top right opened combinator, checks the remaining time of scan. However, that signal is equal to zero for a whole second till the radar does its next update. So the other two combinators implement the edge detection. The arithmetic combinator delays the signal by one tick and multiplies it by -1. So the leftmost decider gets the signals which correspond to current tick and a previous one. Since those signals are of opposite sign, they cancel out on each moment except the moment when "N" becomes 1 for the first time (until it is zero again).
Thus each time the remaining time of the scan becomes zero, we get a single tick pulse of "N" (as in next) signal on leftmost combinator.
3a.png (863.01 KiB) Viewed 7159 times
4
Now, we need to do the counter for the pulses ("P"). That is done by the arithmetic combinator which is connected to itself. Each time it receives an "N" pulse, it increments "P" signal by one. Although we wish to have a signal that iterates over some range, rather than unbounded accumulator. We bound the output using the modulo operation and specify the quotent of that in the constant combinator.
For a glance, have a look at these two saves, where I've set up automated squads to clear biters. Have a look at them to see what can be done with this mod, however they are hardly a good learning material. These were done before the rest of the writing was done here, and feature somewhat different designs.
I was really interested in being able to automatically have drones zoom around and fight biter bases, but then I saw the combinator networks in your saved games and I have no idea what's going on and I'm not interested in learning how to build a contraption that complex.
I really hope you can find a way to make this more accessible. Perhaps look at the AAI Vehicles mod to see how his combinator setups work? There are some videos that explain it, seems quite a bit more simple than what you have. Or I'm completely misunderstanding what your saved games have in them. Either way, I have no idea how to use this mod.
Re: [MOD 0.15.36] DroneCommand_0.1.1 (Oct 13 17)
Posted: Fri Oct 13, 2017 10:45 pm
by Adil
Continuing.
5
We wish to iterate over two coordinates X and Y, so we take P = X + Q * Y .
A pair of the bottom combinators makes the Y of the P signal. (We have also changed the output label of the other combinator to X).
We finalize our arithmetic procedures by the paththrought combinator.
5.png (1.09 MiB) Viewed 7159 times
6
Now lets transform the X and Y signals into shifts for the radar positions. The constant combinator on the top left specifies the step of the shift. We could get away with the numeric constants in the arithmetic combinators, but this approach could also have its uses.
6.png (1.14 MiB) Viewed 7159 times
Now onto fixing the oversights.
7
So, now we have an iterator that runs X and Y values through 0 to Q-1 and transforms them into the orders for the radar.
Yet, we might prefer the radar to be in the center of the square that it scans. One way of achieving that is to shift X and Y so that they run from -Q/2 to Q/2.
Add one more combinator, change settings of another and we are done.
7.png (861.24 KiB) Viewed 7159 times
8
So, this is how we get the functionality of a vanilla radar by using a mod and 18 combinators. Well, almost vanilla. We still get counts of entities in the scanned sectors and could do something interesting with those. For example, I've used similar setups to find enemies before, in my setups radars would stop the iteration and continuously update the same sector where the enemy was sighted.
Now that functionality is achievable by adding a pair more of combinators to the mix. If radar does not finds enemy signals in the sector, one combinator simply passes the signal flow from radar output to the circuit which shifts the position. If there are enemies, the second combinator outputs a single time to scan signal down the circuit. This prevents the iterating circuit from incrementing coordinates.
You might change the criterion to find resources for example (searching for fish has never been so overkill before).
8.png (1.61 MiB) Viewed 7124 times
Note: a smart radar can also count the numbers of combat drones and other units in the given sector:
9.png (187.87 KiB) Viewed 7159 times
But the signals it outputs are not equivalent to those in the normal "combat" tab. The transmitter building will only react to the signals from normal recipe items.
(Located in the "combat" tab or wherever your mods put them).
Let this be a wrap for now. I will describe the setup for drone sending a bit later.
Here is the blueprint string of the resulting setup:
teenkertoy wrote:I was really interested in being able to automatically have drones zoom around and fight biter bases, but then I saw the combinator networks in your saved games and I have no idea what's going on and I'm not interested in learning how to build a contraption that complex.
I really hope you can find a way to make this more accessible. Perhaps look at the AAI Vehicles mod to see how his combinator setups work? There are some videos that explain it, seems quite a bit more simple than what you have. Or I'm completely misunderstanding what your saved games have in them. Either way, I have no idea how to use this mod.
Well, to be honest, these contraptions would be challenging for me too if I hadn't beaten (well, almost) the Spacechem before.
I've wanted to make something more involved that the Robot Army, but I guess I've overshoot with involvement.
I've skimmed through some AAI guide. My schemes are big because I've had to explicitly build the circuits for loops and for handling the duplicate orders. AAI does the former in the lua code and has no problem with spamming the same order to the unit. (In DroneCommand the order may involve the spawning of the robots, and continuous spam of those might be undesirable, yet in other situations one might want the similar signals to be handled twice.)
I guess I could move those two functions under the hood. But for now I'll take a break and wait for more replies. Who knows, maybe a swarm of diehard microcontroller fans will drift around.
Re: [MOD 0.15.36] DroneCommand_0.1.1 (Oct 13 17)
Posted: Fri Oct 13, 2017 11:19 pm
by Adil
Also, newer version is released. Inner workings reorganization was done. Maybe I've fixed something, maybe it wasn't broken before I've started updating.
Re: [MOD 0.15.36] DroneCommand_0.1.1 (Oct 13 17)
Posted: Sat Oct 14, 2017 4:23 am
by teenkertoy
The most significant thing I enjoyed about seeing your mod was since the capsules fly, they don't have the pathing problems that the AAI Vehicles and the Robot Army mods do. Instead of a very long single file line of robots slowly approaching a biter base and getting wiped one at a time, a gaggle of capsules can all arrive at the same time in a pack and not get overwhelmed as they trickle in.
Thanks for adding some explanations earlier, I didn't see that before.
I'm really interested to see where this goes. Have fun with it!
Re: [MOD 0.15.36] DroneCommand_0.1.1 (Oct 13 17)
Posted: Sat Oct 14, 2017 11:10 am
by Adil
Transmitter basics
1
Just as radar transmitter is a building comprised of multiple interfaces, you place the input entity, and the rest pop up on their own.
1.png (181.91 KiB) Viewed 7131 times
Note that transmitter (as well as smart radar) is not rotatable.
Once again, the spawning interfaces are automatically connected to the nearby (vanilla) combinators regardless of the build order:
2.png (149.13 KiB) Viewed 7131 times
The input interface does not autoconnect, since its wires are correctly handled by blueprints.
2
Once per second, the transmitter is checking its input signals. If it receives the "send" signal, it tries to make sense of the rest of signals passes order to the squad (and spawns drones if oreded). Each transmitter controls its own squad and only that one.
If it does not receive the "send" signal, then it does nothing:
3.png (219.4 KiB) Viewed 7131 times
4.png (155.55 KiB) Viewed 7131 times
5.png (473.93 KiB) Viewed 7131 times
Note, that if no position is specified, then it defaults to {0,0}. It is related to the fact that combinators and their lua api does not discern between no-signal and zero.
3
Also, each second it outputs the updated state of the squad.
The "order interface" outputs the order was recently accepted by transmitter.
The "output interface" reports the state of the squad. On the picture left to right:
Median remaining lifetime of the drones.
The distance of the squad from the transmitter.
The count of "protector" drones in the squad.
Current Y position of the squad
Current X position of the squad
The Y position of the transmitter
The X position of the transmitter
Apart from those, there are also signals that report the distance between the squad and the destination (zero on the pic) and the signal reporting the state of special orders (1 - done successfully, 0 - not a special order, -1 error). And of course, signals for other drone types.
6.png (205.17 KiB) Viewed 7131 times
The order of singals on the side view is determined by factorio, which tries to sort them by value.
In the detailed view (if you open the combinator) their positions are fixed (except robots).
You can manually change values of the output combinators if you want, those changes have no effect on the squad state and will be overwritten on the next update.
Re: [MOD 0.15.36] DroneCommand_0.1.1 (Oct 13 17)
Posted: Sat Oct 14, 2017 8:18 pm
by Adil
Using tansmitter
So, the transmitter does not do complex logic in the regard of the input signals. For example, if you pass it a signal "20 defender" it will just spawn those. What if the squad already has 20 "defender"s? Should the signal be treated as a desired number of drones in squad or as a reinforcements? Should it be treated differently if the squad is far away at the moment of order? What if half of the squad is about to expire? I've figured its up to player to decide on those.
Here I'll show how to make search and destroy circuit.
Terminology
Let me introduce names for a few common combinator settups that will pop up multiple times below. Surely, many of them can be found on wiki about combinators, but let the guide be self-complete.
Pass-through combinator - arithmetic combinator set to `(each + 0) -> each` or `(each * 1) -> each` . I use these everywhere throughout the design to fix a certain flow of the signals and simplify thinking about the design. Or to introduce delays.
01.png (38.05 KiB) Viewed 7125 times
Negate combinator - arithmetic combinator set to `(each * -1) -> each` or sometimes `(signal-name * -1) -> each`. It is used as element in setups determining whether some signal changed. Or to filter out some undesired signals.
02.png (45.8 KiB) Viewed 7125 times
Flip flop - decider set to `(anything > 0) -> everything=1`. If this combinator receives a signal on input, it will 1 on the output. To reset, send negative input.
03.png (54.94 KiB) Viewed 7125 times
1
First, lets, make the system where we can define a total number of drones in the squad.
So I usually split my squad logic into two different parts, one is defining the number of drones to send, and the other handles the orders. Depending on the function of the particular setup, this may change. But for now, there are two constant combinators, bottom one is for definition of the drone counts in the squad.
To prevent the continuous spam of drones, lets make a subsystem to substract the already present drones from the order.
We do so by placing six negators each taking a particular drone type and multiplying its count by -1. If we knew for sure, which drones would be used in the setup we could omit the other types (namely vanilla drones are rarely useful due to being short-lived). But we keep it general to allow further modifications.
So, the negated squad drones counts are then passed to the same point where we lead our order signals.
a1.png (1.3 MiB) Viewed 7125 times
2
Now we can send our drones on one-way trips by setting destination coordinates in the constant combinators.
Let's make the order to be defined relative to the transmitter position.
We just take the coordinates of the transmitter from its outputs and send them back to the input.
In this picture I've drawn straight arrows over pass-through combinators. A pair of the new ones is not really needed by logic but I've put them to make wires go around the previously built combinators not over them.
a2.png (1.37 MiB) Viewed 7125 times
3
Now the robots can fly to glory relatively from the starting position.
Lets make them come before they run out of their lifetime.
We'll make that as override order over.
The computations starts with taking the remaining time to live and distance from the base from output.
We substract some spare time (S) from ttl to get some remainder time while squad can be active (J). And divide the distance by velocity V to get the time to fly home T.
Then, if (0 < J ) (squad still living) and (J < T) (time to fly home becomes more than remaining time), we get the red signal at the "AND" combinator.
a3.png (1.73 MiB) Viewed 7125 times
The constants V and S were chosen empirically, they work well for this mods added drones. I wish I could output the squad move speed as radar output, but I couldn't make sense of the combat robot speed definition in prototypes, it seems to follow its own scale unrelated to units or anything else.
Also, note that the squad is moving with the speed of the slowest drone in it.
3a
The red signal will not glow continuously, if squad rushes home quickly, the return condition will not be satisfied at some times. This will cause squad to go back and forth instead of moving home (it will still make progress but a slow one).
To fix that, we add a flip flop unit that reacts to the "color red' signal. We'll talk about resetting it later.
We also might need the coordinates for the return order, the rightmost constant combinator and a pair of deciders are used for that. If we unset the H signal of the combinator, the transmitter position will not be used.
The leftmost constant combinator can be used to offset the return position (if the home position is used) or to specify one (if H signal of the other constant is zero).
All those inputs are accumulated in the the combinator set to send everything if red color is >0.
a4.png (1.67 MiB) Viewed 7125 times
3b
Almost done, we now need rework the input slightly, instead of the pass-through combinators there is decider, that blocks from the red signal. And there is a chain of pass-through combinators to get the return signal into the transmitter.
a5.png (1.76 MiB) Viewed 7125 times
3c
One last thing is to do the reset procedure for return circuit. We need that so that when old drones die off, the squad would move out with new ones.
Apparently, we need to reset the return routine when all drones die off (time to live equals zero) or if a few old drones die and the median life expectancy of the drones goes up.
The former is easily detected with a single combinator. To detect the upsurge in the lifetime we use similar scheme to the one used in the radar: one combinator negates the ttl and its result is sent to the decider along with the input. Due to delay, those two signals are one tick apart and their implicit summation at the input of the decider gives the delta. If that one is greater than zero, it's time to reset.
So the OR combinator outputs 1 red color, which is then negated and guided to the filp-flop we have used in the "go home" circuit.
Now, we place the landing pad. Offset the return order to point to the position of pad (we could get by without that, the landing range is 30 tiles). And set some order in the top constant combinator. The drones will fly out and return when the time to land comes.
Here are the blueprints that were used in the saves I've posted earlier. The main idea is the same, but there are some variations between them. For example, in them I've tried to filter out repeating orders. Or used different criteria for return reset.
Lets us now combine the current setup with the one for smart radar. Radar scans sectors till it finds one with enemy count > 0, so, we add combinator, which sends the position of the last scan to the combinators, that convert that to destination signals. Then using two pass-through combinators we guide the signal to the input of the squad command scheme (constant combinator opened on the picture).
Note the second signal in the combinator, it specifies whether drones are allowed to diverge from the set route in order to fight biters. Since the goal of our current setup is biter removal, the signal is there.
We also disable the combinator, that shifted the order position relative to the transmitter position. (We now receive absolute position from radar)
Zoom is quite high on this picture, if you do not see the green wire going to constant combinator, open the image at separate tab.