Factorio Forums

I've been attempting to write a mod that alters the way biters interact with the players (attacking in waves, rather than the small packs, more advanced grouping behaviors) and manipulating larger groups of biters (100+), and the factorio API is too coarse for this sort of mechanics. I've found the Surface.set_multi_command to have serious limitations, it appears to have a maximum range of around 200 (requesting an attack on a location farther away than that has no effect, and silently fails w/o indicating any sort of problem). When I did use set_multi_command in shorter distances, where it did work, it only seemed to cause a small number of biters to follow the command, biters already in a unit group (swarming to build a new base or attack pollution) ignored commands. Also, I did discover set_multi_command has a 3rd optional argument (command, number, and force), which was not documented in the wiki - however this is not particularly useful.

Giving commands to individual units seems to work without the same distance limitation, but it is a lot slower in terms of performance. More problematic still, when the command finishes (like a go-to-location command), the biters immediately return to whatever they were doing before, which makes advanced groupings hard to maintain, without repeatedly giving them the command each tick - a massive performance drain. I've fiddled around with creating unit groups in the hopes that this might be a solution, but I haven't seen positive results. Creating a unit group from the nauvis surface, and using add_member seems to have no effect on existing biters. Giving biters the command to group with the new unit group also does not seem to work. I would suspect that biters have some sort of pre-existing unit group and so the game is rejecting adding them to a second group, but there is no way to get the unit group a biter is currently a member of, nor remove them from it.

I think the easiest improvements here would be the following:

• Give set_multi_command an additional optional parameter to specify the maximum range to search for units to fulfill the request, and allow set_multi_command to interrupt existing unit grouping behavior
• Expose a field to access a biters current unit group
• Fix adding members to unit groups (or clarify the documentation on how it is supposed to work)
• Add a method to disable/enable the standard biter AI behavior (wandering, attacking pollution, etc) so modders can have complete control if desired
• Add events for when a unit is given a new command, a biter base is built, etc. It would be nice to script modifications to this behavior, or move the location of the biter base, override the command, etc

Well, it a moot point whether non-targeted function should silently override the previous command assignments on any unit it finds.
But at least some feedback would be nice.
For example set_multi_command could return number of biters it has actually send, so that if it's unacceptably small, modder could know when it's time to fallback on slower explicit method of manually gathering biters in groups and sending those.

Obtaining unitgroup info seems important as well. Unit do have has_command field but that's actually not that informative.
An event for when unit group finishes its task would be useful too.

Also, new commands like: wait and follow might be good.

As for

Afforess wrote:Add a method to disable/enable the standard biter AI behavior (wandering, attacking pollution, etc) so modders can have complete control if desired

there's already writable field in force which switches AI. While completely disabling all biters for the sake of ones mod might be a bit immodest, one could create a bitter_spec_ops force and move each unit he takes over into that, before issuing commands to them.

Adil wrote: As for

Afforess wrote:Add a method to disable/enable the standard biter AI behavior (wandering, attacking pollution, etc) so modders can have complete control if desired

there's already writable field in force which switches AI. While completely disabling all biters for the sake of ones mod might be a bit immodest, one could create a bitter_spec_ops force and move each unit he takes over into that, before issuing commands to them.

Good idea on that particular item. I never thought to look at forces for unit behavior.

Afforess wrote:

Adil wrote: As for

Afforess wrote:Add a method to disable/enable the standard biter AI behavior (wandering, attacking pollution, etc) so modders can have complete control if desired

there's already writable field in force which switches AI. While completely disabling all biters for the sake of ones mod might be a bit immodest, one could create a bitter_spec_ops force and move each unit he takes over into that, before issuing commands to them.

Good idea on that particular item. I never thought to look at forces for unit behavior.

That only disables the expansion planner. I.e. the thing that makes biters create new bases. Biters will still keep doing their thing, even if you set this to false.

The name is incredibely confusing, I know. Sorry about that.

Oxyd wrote: That only disables the expansion planner. I.e. the thing that makes biters create new bases. Biters will still keep doing their thing, even if you set this to false.

The name is incredibely confusing, I know. Sorry about that.

Does it disable all biter unit-grouping behavior (grouping to attack pollution, expand bases) or just grouping to expand bases?

Resurrecting this a bit. Unit group and AI handling has improved some in recent releases, but I am vexed at another problem. I find that spawning biter units when a player is > 300 tiles away results in biters that simply de-spawn the next few ticks, even if given immediate orders or created as part of a unit group. Basically, it seems that biters despawn at will when not under the active influence of a player, or inside a pollution cloud. This is rather frustrating, as I haven't come up with a way to keep biters from despawning. I have gone as far as to spawn fake player-character entities near the biters in the hopes that would trick factorio into believing a player was nearby, but no such luck.

A flag or other setting to prevent biters from being naturally culled would be extremely useful.