[MOD 0.18] Robot Army. v0.4.4

[kyranzor]

haha wow, damn robot mining site. so you can confirm that the droids are trying to attack/target the robot mining sites?

[hitzu]

haha wow, damn robot mining site. so you can confirm that the droids are trying to attack/target the robot mining sites?

When I removed all droid mining sites, battle droids started working well and went for hunting. For the sake of experiment I built another mining site just near the deployer, waited for the new squad... and the squad just ignored it and went for biters hunting. So weird...

[kyranzor]

I am not sure if it's the mining site or the robots that come out of it but something in that mod has a "force" which is considered an "enemy" to the droids so they are given attack-area commands but there aren't any enemies there

[hitzu]

So what does force the squad to disassemble then? Is it normal behaviour?

[kyranzor]

The squad disassembles and re-groups if it fails to do whatever task it was given. It's a failsafe in the new code.

It's to help deal with constant lag spikes if they cant get somewhere and keep trying forever.

[kyranzor]

Guys if you haven't checked out the dev branch yet, please do. These are the major features I can think of right now that need testing:

* Droid Assemblers self-limit spawning around them to max 1.5x squad hunting size to avoid run-away-spawning situations (spawning into a huge blob and making a mess)

* new config file options for squad targeting mechanisms - assembler-centered, squad-centered, or "radius clear" around assembler and then squad-centered if the radius is clear.

* super complicated logic and automatic failure recovery for squads who have issues pathfinding or otherwise failing orders - automatic squad disbanding and recovery and joining nearby squads after retreat.

* rebalancing of droid build times

* massive performance improvements, distributed squad AI processing across multiple game ticks instead of all at once


See the original post in this thread for info on how to use the dev branch from github, and remember to rename your mod folder to "robotarmy_0.2.4".

[onebit]

Thanks for the update!

* Green bot color is very nice
* Would be nice to be able to set GLOBAL_TARGETING_TYPE at the Droid Settings Module
* I used targetingTypes.defendAssembler and SQUAD_HUNT_RADIUS=500 to have them defend 500 tiles around the assembler. Would it make more sense to use DEFAULT_KEEP_RADIUS_CLEAR in findDefendAssemblerTarget()? My intent is to have the radius cleared and then have the robots stop until biters move back in.

I got this when I laid down the Droid Rally Beacon. I'm using targetingTypes.defendAssembler. Seems like the squad of 40 was unable to path there and was broken into squads of 1. After 10 mins some droids have not found their way back and continue to trickle in.



Maybe they are confused by the forest?

[kyranzor]

Hi Onebit,

I'm not sure what those guys are doing stuck in the forest, perhaps the path back to the rally point is obscured by walls and they cannot find a legal path?

One other thing that i've found is if the time between retries of giving them a command is too soon, and their target movement location was REAALLY far away (like being recalled 10,000 tiles by a rally beacon) then the pathfinder can take SOO long that it never actually manages to find a path before the next command is re-issued to get them to move, and they just get permanently stuck like this. Try putting a rally beacon closer to them. They will path to the closest beacon.

Thank you for playing Robot Army, and for mentioning it on the forums/reddit! I've seen you around.

----------------------------------------------------------------------

Can I get people's opinions on the flying robots? Has anyone actually used them? Or perhaps people can't use them because the tech is bugged and it isn't unlocking properly?

[hitzu]

Can I get people's opinions on the flying robots? Has anyone actually used them? Or perhaps people can't use them because the tech is bugged and it isn't unlocking properly?

I don't like them because they are very weak and almost everytime they outrun stronger robots and die one by one first. Also I don't like flamebots. They cause forset fires, kill other robots and often stuck in front of rocks not being able to kill them with fire, silly bots

[kyranzor]

Can I get people's opinions on the flying robots? Has anyone actually used them? Or perhaps people can't use them because the tech is bugged and it isn't unlocking properly?

I don't like them because they are very weak and almost everytime they outrun stronger robots and die one by one first. Also I don't like flamebots. They cause forset fires, kill other robots and often stuck in front of rocks not being able to kill them with fire, silly bots

Okay, thanks for the feedback. How would you prefer balancing of these? Cost decrease or effectiveness in combat increase?

[hitzu]

Okay, thanks for the feedback. How would you prefer balancing of these? Cost decrease or effectiveness in combat increase?

I made flying bots once when I faced the problem with robots got stuck inside my factory. I thought flying bots are really flying above and don't get stuck over belts, but they do. So I abandoed this idea and didn't came back to them. I checked how they behave in combat and wasn't impressed either. Perhaps they could be more powerful and fast, or fire while constantly moving (do they do like this?). Or maybe they would be useful to be like kamikaze-bots aiming worms exlusively and exploding?

But really the main reason I don't use flying bots it's because I find it hard to manage complex squads cosisted of different robot types. I 100% rely on riflebots. Even then they cannot push boundaries easily against behemot biters, they either don't give biters a chance to colonize in a huge area around my base. They are relatively cheap and there are up to 5-6 25-bot squads at any given moment that do their work very well so I don't even have any turret and I'm sure I'll be fine.

[kyranzor]

Fair enough... if you try using squads of distractor robots in the same numbers (or larger, squads of 50) will do better and move much faster than riflebots.

I'm glad you still find a use for the riflebots

[hitzu]

Fair enough... if you try using squads of distractor robots in the same numbers (or larger, squads of 50) will do better and move much faster than riflebots.

I'm glad you still find a use for the riflebots

Hm, I'll check this
The problem is that I'm too lazy to change something that works just fine
I have to change production setup, delivery service and every deployment point so I hesitate a bit.

Also as far as I remember fluying bots are affected by belts, though they don't collide with entities, so it's impossible to control them using walls. Correct me if I'm wrong.

By the way another way to improve fluing bots would be the ability to control squad size for individual deployer. Making squad size setting for huge swarms of flybots would make ground robot squads too huge for them to perform well.

[onebit]

I will try some flying bots. I've just been using squads of 40 rocket bots. They destroy everything.

edit: maybe rocket droids should be advanced circuit? they are pretty powerful. battle droid could use heavy armor instead of light because of the extra hp.

[kyranzor]

I will try some flying bots. I've just been using squads of 40 rocket bots. They destroy everything.

edit: maybe rocket droids should be advanced circuit? they are pretty powerful. battle droid could use heavy armor instead of light because of the extra hp.

That's a good idea! I will change them to use a few adv circuits instead of just lots of green ones.

[Jürgen Erhard]

I just now ran into the despawning... damn. Such a nice mod hampered by such shitty game AI (sorry, devs... ).

It sucks especially if you're somewhat tight on resources, because all those processing units (gods, I hate processing units)... I suspect there's no way to (quickly, or in fact at all?) tell why a bot disappeared (enemy kill vs automatic despawn)? Because if there were a way to determine that a bot was despawned by the game logic and not through enemy attack, you could add those bots to the queue to be remade without spending fresh resources? Maybe with a special building, say, a "Bot Reintegrator".

Still, having a nice big squad run all over the place and whiping up those stupid biter nests is still so *sweet*.

[kyranzor]

Hi Jurgen,

Thanks for playing my mod

Yes it's very annoying that the game de-spawns my droids - I think it might be possible to detect this situation for example if I had a record for a droid in a table, and I iterate over it, if it suddenly becomes ''nil" when it wasn't killed normally or by my own scripts, then it could be re-created and re-added to the squad. The code for that might be difficult though because the droid might be nil when killed by means that i am not monitoring. For example, I do not monitor the "on killed" event for every single entity, but maybe I should be?

What my code does is periodically go through the table of squad members and if they are dead (by whatever means) remove them and update squad member count, and if the squad gets to 0 members then the squad is deleted and you get a message saying they all died.

The reason I don't like the "on killed" event is that ANY entity in the game that dies for any reason would cause that event handler code to run, and unless I can find a way to instantly find a squad table based on a single member's (now invalid/nil entry) ID or unique signature it would be too costly in terms of processing to find out how it died.

Right now, events do not tell you if an entity was killed by another entity or not, or by a game script. In fact, if the game de-spawns a droid I doubt any event is thrown at all (because it's the game's internal garbage collecting script probably calling Entity.Destroy() on it).

[Optera]

What my code does is periodically go through the table of squad members and if they are dead (by whatever means) remove them and update squad member count, and if the squad gets to 0 members then the squad is deleted and you get a message saying they all died.

The reason I don't like the "on killed" event is that ANY entity in the game that dies for any reason would cause that event handler code to run, and unless I can find a way to instantly find a squad table based on a single member's (now invalid/nil entry) ID or unique signature it would be too costly in terms of processing to find out how it died.

Right now, events do not tell you if an entity was killed by another entity or not, or by a game script. In fact, if the game de-spawns a droid I doubt any event is thrown at all (because it's the game's internal garbage collecting script probably calling Entity.Destroy() on it).

on_entity_died returns the entity which should hold a unique unit_number.
Using a metatable SquadsByUnitID = {[entity.unit_number], squadID} could give you instant access to the squad without iterating over every entity in every squad.

[kyranzor]

on_entity_died returns the entity which should hold a unique unit_number.
Using a metatable SquadsByUnitID = {[entity.unit_number], squadID} could give you instant access to the squad without iterating over every entity in every squad.

Thanks Optera! That's handy info. Now I might be able to replace droids killed "unofficially" by the game cleanup script.

[Optera]

on_entity_died returns the entity which should hold a unique unit_number.
Using a metatable SquadsByUnitID = {[entity.unit_number], squadID} could give you instant access to the squad without iterating over every entity in every squad.

Thanks Optera! That's handy info. Now I might be able to replace droids killed "unofficially" by the game cleanup script.

You're very welcome.
I hope modded biters have a unit_number. If not now seems to be a good time to ask for api enhancements.