[MOD 0.18] Robot Army. v0.4.4

[kyranzor]

Well perhaps I broke it? I'll put a git issue on it. I'm currently working on a zombie mod but I'll whip over and squiz at the code

[Gazer75]

Noticed at one point the game lagged a lot. Found that I had probably 100+ terminators that appeared confused about half way between the alien bases and the assembler.
Had to pick them all up manually. Not even a rally flag would make them move.

[kyranzor]

Noticed at one point the game lagged a lot. Found that I had probably 100+ terminators that appeared confused about half way between the alien bases and the assembler.
Had to pick them all up manually. Not even a rally flag would make them move.

Could you tell if they were all in the same squad or not? what are your settings for squad size, hunt radius, and retreat (even though it doesn't seem to work... maybe this was it half-working?)

Were they stuck in a forest or something?

[Gazer75]

Thinking about it they may have gotten confused by stuck squad members. At least some of the squads were divided and I found like 2-3 of the members inside forests.

I've tried and used anywhere from 10 to 25 for squad size. Anything less than 25 now and they get slaughtered quite fast by the behemoths
Currently using retreat size 20 as I've noticed they loose effectiveness rapidly going below 20 at this time.
Changed the default hunt size to 15 and retreat to 10. But it should be overridden by the settings in game as mentioned above.
Everything else is default.

[b38917ce-3ad3-4fae-b]

I haven't given the balancing thing enough thought in order to answer your previous question. I will say that the terminators are an overwhelmingly more efficient investment, but that may be an outlier. I've dug deeper however into bot behavior and some performance issues.

Now I've mentioned previously that pathfinding was causing performance issues, but I'm no longer certain about that. It may still be true, but I'd need to load up my previous map and check again to be certain.

Since stuttering came back in this playthrough, but this time the bots were just sitting around, I looked through your code and by a process of elimination (since I'm not familiar with the performance characteristics of the game's API nor lua in general) I uncovered that the only thing causing my stuttering this time around was the call to get the nearest enemy within a given radius. I then remembered that (for this playthrough at least) I increased the seek distance to the maximum of 10k tiles, and it does make sense for it to be significantly more costly since I quadrupled the number of tiles the method has to check by doubling the distance.

What I'm trying to accomplish is to clear large map areas since I want to use trains, so even though checking 100 million tiles seems to be expensive (worst case, I guess, since searching should stop once it finds the closest, as the method name indicates), it's not all that impressive for a player looking at the map. There's also no need for every squad to search for enemies on the same tick, and staggering the costs of the call would probably result in much better overall performance. But I think I remember reading somewhere that you're already intending to process each squad on a separate tick, so that's neither here nor there.

However, since they're supposed to be hunting by default and not guarding, I think that having them go in a direction (maybe random if deployed by hand, and the direction the assembler output is facing otherwise) would make much more sense and it would give players the ability to keep them out of their bases. The added benefit to this is that you could then drastically reduce the seek distance since they're not just sitting around any more.

[hitzu]

However, since they're supposed to be hunting by default and not guarding, I think that having them go in a direction (maybe random if deployed by hand, and the direction the assembler output is facing otherwise) would make much more sense and it would give players the ability to keep them out of their bases. The added benefit to this is that you could then drastically reduce the seek distance since they're not just sitting around any more.

This is a great idea! Cutting half of the map for the squad deployed by the position and orientation of the spawner. I doubt it is possible though 'cause they use just the generic biters' pathfinding.

[kyranzor]

However, since they're supposed to be hunting by default and not guarding, I think that having them go in a direction (maybe random if deployed by hand, and the direction the assembler output is facing otherwise) would make much more sense and it would give players the ability to keep them out of their bases. The added benefit to this is that you could then drastically reduce the seek distance since they're not just sitting around any more.

This is a great idea! Cutting half of the map for the squad deployed by the position and orientation of the spawner. I doubt it is possible though 'cause they use just the generic biters' pathfinding.

Hitzu, they use biter pathfinding to get from A to B - but I am the one who tells them where that is. I control where they are trying to go.

There are many problems I can think of making squads move outwards and hunt based on the direction of their original spawner - some people (including myself) like to use multiple assemblers in one spot in order to spawn faster, but the units all end up joining a single squad (which is what I want). What if the two assemblers are not even facing the same direction? What should I choose as the direction to send the squad?

There are so many ways to make things more complicated - but each new way of doing something adds in special cases all over the place, and adds more chance of bugs or complexity issues. I need the way the squads/units behave to be as intuitive and simple as possible with as little fancy logic as possible.

For a while now, I think a major re-work might be in order. A re-work where units are organized by their "home" assembler, and users can use how many assemblers they place to limit how many squads are active. Active droids would be droid squad size * number of assemblers. When the droids become assembler-centric, i could easily have them retreat to their own assembler, move out in the direction the assembler faces to hunt (as b38917ce-3ad3-4fae-b suggests) and other interesting things.

The code would probably end up faster too, because i'd only need to iterate through each assembler and check for spawning, the associated squad's AI/condition, etc. rather than iterating through every assembler and every squad separately.

[aubergine18]

I always liked the way droids were managed in the game "Warzone 2100"...

Factories (WZ equivalent of assemblers) had rally points that could be placed on map. They also had options to apply to newly built droids, for example their battle stance (guard, patrol, etc), group and so on.

So they were essentially 'assembler-centric', to use your terms, but you could preconfigure them to some extent by settings on the factory.

Another thing that WZ2100 had was repair stations. When badly damaged, droids would retreat to nearest repair station, get repaired and then attempt to return to their previous task or group. It was possible to set what level of damage would cause a droid to seek repairs (but you could also turn it off so they would fight to the death).

Some info and screenshots https://warzone.atlassian.net/wiki/page ... Id=3309684

If the Robot Army could implement some stuff like that it would be very cool!

[impetus maximus]

testing 5 terminators patrolling in a new game i found them to keep disappearing.
it was a circle around a smallish lake. it was wooded to the south which they blasted through.
seemed they didn't really patrol but wander back and forth from poll to poll which were connected by a colored wire.
went and got a sandvich. came back and there were only two left of the five. no biters/worms in the area.
mind you this is a brand new game so i don't think they were detroyed by the low level biters and worms.

the hunting aspect of this mod is the most useful ATM for me. clearing out new spawners in an area.

the work you've done is great though. keep at it.

[kyranzor]

The aggressive de-spawning the devs have in place that removes any unit that cannot find a path in only a few seconds. This happens all the time with any unit that tries to path around or near water, gets stuck running into other units, or generally has a bad time in non-open ground..

It's something I cant do anything about..

Also the patrol mechanism is still super rough and needs more work

[impetus maximus]

ah. that would explain it.

[hitzu]

Thank you for the answer. Now I understand it better.

P.S. I'm really looking forward for woodcutter droids. ^_____^

[b38917ce-3ad3-4fae-b]

Regarding the assembler direction suggestion, while I don't much care for it and it's just a solution to some of the behavior issues that doesn't introduce any new concepts/entities, I do believe that it actually is more intuitive than the current behavior from a player's standpoint.
Right now, when you deploy a group, they might go to the nest you think they will, or they could just turn around and do something totally unexpected. While the direction thing wouldn't be obvious, it can be quite easily communicated via text: either in the assembler description, or you could have a player message as you do when a squad dies saying "Squad xx has been created and is heading West/North/etc".
As for your edge case, if you would hypothetically go this route, it stands to reason that if a squad is forming that's about to go East and you have another assembler pointing West, its output would form a separate squad.
The whole thing seems to be much easier to deduce through trial and error and the feedback loop is actually there.

Now there are issues with them just bee-lining in a direction, and what you said about them becoming assembler-centric does make sense (and it also allows you to make further design choices regarding their upkeep and the whole logistic side of them), and even though doing the direction thing doesn't introduce anything new to the player, I realize that the changes to the codebase aren't all that small and the whole thing is better left for a redesign. The most important thing from my suggestion, I believe, is that the robots should just move somewhere and scan a smaller surface for potential enemies.

Regarding performance and pathfinding, I went back to my previous save to check if pathfinding was actually a factor in my stuttering.
I found that it was, but not when standing in forests. That may still turn out to be an issue, I haven't tested that part extensively.
Looking at the pathfinder timings, I noticed that from the usual 0.0x ms/frame it would jump to 2ms/frame at times. It happened when engaging nests. Looking a bit at the pathfinding/targeting info available for debugging I believe that the cause for this is that when engaging nests with biters, some biters happen to get stuck (it happened more for biters this time around, but I guess the same applies for your units).
While stuck, they're quickly switching targets and (I think) calculating new paths. I guess n to n combat wasn't extensively tested or optimized since the game's combat is usually n to 1.

[kyranzor]

I always liked the way droids were managed in the game "Warzone 2100"...

Factories (WZ equivalent of assemblers) had rally points that could be placed on map. They also had options to apply to newly built droids, for example their battle stance (guard, patrol, etc), group and so on.

So they were essentially 'assembler-centric', to use your terms, but you could preconfigure them to some extent by settings on the factory.

Another thing that WZ2100 had was repair stations. When badly damaged, droids would retreat to nearest repair station, get repaired and then attempt to return to their previous task or group. It was possible to set what level of damage would cause a droid to seek repairs (but you could also turn it off so they would fight to the death).

Some info and screenshots https://warzone.atlassian.net/wiki/page ... Id=3309684

If the Robot Army could implement some stuff like that it would be very cool!

I really like Warzone 2100 as well, it was an amazing game. Yes I could introduce a new building that is a dedicated repair place instead of self-heal or having them go back to their home assembler. My plan for the next release is a simple combat engineer/repair bot that just repairs any bots in his squad, which to me is better than sending individuals or the squads back home (pathing is something I want to avoid).

Something that I could implement for now, is the squads having a reduced hunt-radius (it's based on their current position, so if they have found enemies and are engaging, then even just a few hundred tiles max is good enough) and if they cannot find a target, then they can simple be told to move x hundreds of tiles in a random (or maybe pre-configured) direction. They can search again when they get there, and if no enemies, move again.


This will still have issues for when the droid squads reaches the end of the map - if there ARE no biters, then they wont find any enemies anyway, and they cannot keep moving in a direction because the chunks/map doesn't even exist anyway. The player needs to go over there and trigger generation of more chunks ( and enemies! ).

It's not sustainable to have the droids themselves cause chunk-generation, because they will make a save-game become very large if left unchecked. You may not even have wanted to expand in whatever direction they went, and it's just wasted space slowing down your megafactory and save/load speed.

[Optera]

This will still have issues for when the droid squads reaches the end of the map - if there ARE no biters, then they wont find any enemies anyway, and they cannot keep moving in a direction because the chunks/map doesn't even exist anyway. The player needs to go over there and trigger generation of more chunks ( and enemies! ).

It's not sustainable to have the droids themselves cause chunk-generation, because they will make a save-game become very large if left unchecked. You may not even have wanted to expand in whatever direction they went, and it's just wasted space slowing down your megafactory and save/load speed.

This is why I once asked for squads to have their hunting radius bound to the place where they spawned.

[Qon]

This will still have issues for when the droid squads reaches the end of the map - if there ARE no biters, then they wont find any enemies anyway, and they cannot keep moving in a direction because the chunks/map doesn't even exist anyway. The player needs to go over there and trigger generation of more chunks ( and enemies! ).

It's not sustainable to have the droids themselves cause chunk-generation, because they will make a save-game become very large if left unchecked. You may not even have wanted to expand in whatever direction they went, and it's just wasted space slowing down your megafactory and save/load speed.

This is why I once asked for squads to have their hunting radius bound to the place where they spawned.

But if you do expand you probably want them to go to the new area and clean that up instead of having to pick them up and respawn them because their original spawn point was far away from the new perimeter.

[Optera]

What is more of a hassle, having your bots chasing single worms and nests into oblivion and eventually being force despawned or picking up a squad idling at their spawn?
I keep seeing squads paving an almost straight path from their spawn into oblivion where they eventually die or get stuck instead of cleaning around their spawn first.
If that's what hunting squads are supposed to do, please make defense squads more reliably hunt down things in a configurable radius around their spawner.

[Gazer75]

After playing some more and watching their behavior I think it is the AI that is getting confused.
I added a mod that makes the tree hitbox very small and I've burned down most of the trees where they appeared to get stuck.
They still went crazy going back and forth about half way between the assembler and the alien bases. Nothing that should be blocking them in any way.
And when this happen the game start lagging. Game drop FPS/UPS from stable 60 to around 50-55.

[b38917ce-3ad3-4fae-b]

Can you press F4, check "show_time_used_percent" and post two screenshots with that enbaled, one while it lags and one while it doesn't?
After you've selected time_used_percent, press F4 again to toggle that menu away.
A screenshot of the map showing both the biter base and yours would also help.

[Gazer75]

Lagging:
http://steamcommunity.com/sharedfiles/f ... =762897063
Not lagging:
http://steamcommunity.com/sharedfiles/f ... =762897254
Map:
http://steamcommunity.com/sharedfiles/f ... =762897165

Think I might have solved some of the problem at least. I believe I am at the edge of the robots range.
Also there was a small cluster of worms on an island that robots would not be able to get to. After taking care of that they seem to behave a bit better.