Spidertron automation: Movement and Interrupt conditions
Posted: Fri Mar 01, 2024 1:23 pm
TL, DR: Vast reduction of spidertron micromanagement inspired by functionality from Trains 2.0 update.
Hey there!
just to hedge: this is my first post. I did not find this idea on the forum but please do let me know if it is redundant.
Also: Given the insane changes displayed in the recent FFFs, I have the sincere hope that spidertron functionality will be/has been overhauled at some point - by devs with so much smarter ideas than a intermediate factorio player could come up with on his own <3.
That being said, here's my take on this:
I love using spidertrons mid-late game instead of a bot construction network - usually I chain many together and send them off to build a blueprint I placed in a remote location. They are also an excellent choice of clearing biter nests without artillery and a defence perimeter - and if a big defence perimeter is set up, they can maintain wall repairs/replacement.
But I find that spidertrons require a lot of micro-management, especially with the usual blueprints being much larger than the roboport build areas of each spidertron. I usually send a batch of spidertrons scurrying around a blueprint, but they usually lose some bots along the way, some buildings are not placed, they run out of buildings and other issues occur.
Current remedy:
This issue is less noticable after a certain bot speed research as bots are able to catch up with running spidertrons (granted they have no movespeed increase), recharge and resume building. Also, sending a squad of 50 spidertrons all loaded to the brim with most common buildings and sending them back to "recharge" usually addresses the issue of running out of buildings.
Furthermore, with logistic groups coming to 2.0, managing the inventories and excess/garbage will become a breeze (no more countless zero-item requests to manage deconstruction leftovers)
But I find that they have so much more potential - which imho clicks well with the changes coming to 2.0:
Spidertrons/STgroups with move point types and move/interrupt conditions.
The rough first draft idea:
Move point types:
Spidertrons have three different move point types (Logically, Anchors could also just be single-point routes which would reduce move point types to two):
Just as for trains, spidertrons include two conditions:
Move condition:
Introduce a way of automating spidertrons without needing to micro-manage them nearly as much. If there's a routine task that spidertrons can do well, why not have it do that task automatically and logically.
Upgrade spidertrons to a sort of automatron - whilst keeping the possibilities of manual control - just like with trains.
Issues
How to deal with Children/chained spidertrons:
This in my mind is a bit more difficult. Usually, the children should copy routes and operation of the parent spidertron. But what if an interrupt condition arises on a child but not the parent? Well, the parent dictates to move on as usual but now the child is lacking capability. What if the child could ask the parent to interrupt? Well, now a single interrupting child disrupts the entire flock. All not good ideas and solutions in my opinion.
A solution could be spidertron groups/bunch/crew - multiple spidertrons sharing the exact same conditions. However, I do not know the technical limitations of this.
What about a spidertron automatic mode?
This is another idea that is not fleshed out:
If a build alert arises, a spidertron with certain conditions (eg. Bots and the necessary items) could pick up the alert and respond by automatically making a move to location and waiting for the work batch (move, interrupts and satisfaction of the alert).
This too has issues:
I am aware of the mod aai-programmable-vehicles and mods such as spidertron-extended - and to some extent their functionality is similar. However, embedding spidertrons logic into the factorio train system logic may be a more logical choice: The system now in place for trains would through similarity make spidertron automation logic much more accessible.
And it could in theory imply that all vehicles may be able to receive move/interrupt conditions; though movement systems such as turn radius may make this more difficult than with the very versatie spidertron.
I would really be thrilled to hear some opinions on these ideas!
Thank you for your time - Ben.
Hey there!
just to hedge: this is my first post. I did not find this idea on the forum but please do let me know if it is redundant.
Also: Given the insane changes displayed in the recent FFFs, I have the sincere hope that spidertron functionality will be/has been overhauled at some point - by devs with so much smarter ideas than a intermediate factorio player could come up with on his own <3.
That being said, here's my take on this:
I love using spidertrons mid-late game instead of a bot construction network - usually I chain many together and send them off to build a blueprint I placed in a remote location. They are also an excellent choice of clearing biter nests without artillery and a defence perimeter - and if a big defence perimeter is set up, they can maintain wall repairs/replacement.
But I find that spidertrons require a lot of micro-management, especially with the usual blueprints being much larger than the roboport build areas of each spidertron. I usually send a batch of spidertrons scurrying around a blueprint, but they usually lose some bots along the way, some buildings are not placed, they run out of buildings and other issues occur.
Current remedy:
This issue is less noticable after a certain bot speed research as bots are able to catch up with running spidertrons (granted they have no movespeed increase), recharge and resume building. Also, sending a squad of 50 spidertrons all loaded to the brim with most common buildings and sending them back to "recharge" usually addresses the issue of running out of buildings.
Furthermore, with logistic groups coming to 2.0, managing the inventories and excess/garbage will become a breeze (no more countless zero-item requests to manage deconstruction leftovers)
But I find that they have so much more potential - which imho clicks well with the changes coming to 2.0:
Spidertrons/STgroups with move point types and move/interrupt conditions.
The rough first draft idea:
Move point types:
Spidertrons have three different move point types (Logically, Anchors could also just be single-point routes which would reduce move point types to two):
- Moves (think single click with the remote or chains of single clicks through holding shift. This is exactly their current movement logic)
- Anchors (Fixed locations on the map which may be called by the interrupt conditions - eg. going home to the mall to recharge items until no robots are en route/inactivity)
- Routes (Fixed list of locations, however, unlike moves, this list is permanent. Going from one point to another will require move condition to be true. This is used for routine tasks - routinely repairing a wall perimiter, clearing near biter nests, setting up logistic robot supply lines (logistics roboport? could that be a thing?))
Just as for trains, spidertrons include two conditions:
Move condition:
- This condition must be true in order for the spidertron to advance to the next specified waypoint.
- Usual examples: Robots in inventory == 100, Inactivity >= 5sec, Combat == false (maybe?)
- This condition interrupts the current Moves/Routes and must be addressed before continuing the Move/Route.
- Examples could be: a low energy threshold (==> Wait), Combat == true (==> Go home to anchor), Inactivity after last move condition ==> Start routine route
Introduce a way of automating spidertrons without needing to micro-manage them nearly as much. If there's a routine task that spidertrons can do well, why not have it do that task automatically and logically.
Upgrade spidertrons to a sort of automatron - whilst keeping the possibilities of manual control - just like with trains.
Issues
How to deal with Children/chained spidertrons:
This in my mind is a bit more difficult. Usually, the children should copy routes and operation of the parent spidertron. But what if an interrupt condition arises on a child but not the parent? Well, the parent dictates to move on as usual but now the child is lacking capability. What if the child could ask the parent to interrupt? Well, now a single interrupting child disrupts the entire flock. All not good ideas and solutions in my opinion.
A solution could be spidertron groups/bunch/crew - multiple spidertrons sharing the exact same conditions. However, I do not know the technical limitations of this.
What about a spidertron automatic mode?
This is another idea that is not fleshed out:
If a build alert arises, a spidertron with certain conditions (eg. Bots and the necessary items) could pick up the alert and respond by automatically making a move to location and waiting for the work batch (move, interrupts and satisfaction of the alert).
This too has issues:
- Pathfinding around water/lava etc. (Biter-pathfinding logic perhaps?)
- Build alerts outside botnet range are not collected/displayed as far as I know. The interesting part here could be that spidertron roboport build alerts (by spidertrons, who are unable to carry out a build request in their roboport range) could be picked up by other spidertrons capable of building, who then respond to the area.
I am aware of the mod aai-programmable-vehicles and mods such as spidertron-extended - and to some extent their functionality is similar. However, embedding spidertrons logic into the factorio train system logic may be a more logical choice: The system now in place for trains would through similarity make spidertron automation logic much more accessible.
And it could in theory imply that all vehicles may be able to receive move/interrupt conditions; though movement systems such as turn radius may make this more difficult than with the very versatie spidertron.
I would really be thrilled to hear some opinions on these ideas!
Thank you for your time - Ben.