0.17 Unit & AI additions

[abregado]

Edit: Also, a flag to prevent units from attacking blocking trees and other obstacles would be nice. I couldn't make a unit without an attack, so I tried making one with 0 damage but it gets stuck endlessly attacking trees for no damage.

Thanks for the detailed reply. There are a lot of good points here for us to look at. We ran into a few of these while building the more complex behaviours for Compilatron, but also for scripted Biter attacks. The one i have quoted above is still an issue, but wont be for much longer.

[mk-fg]

As a person maintaining a unit-related mod, definitely love new fixes!
Biter-specific destructive pathing have been a problem for adding anything peaceful in particular.

One thing I'd love to have that wasn't mentioned is having something like .light on units - to have units emit light, which can definitely be useful for Will-o-Wisps mod, but also any kind of machine/robotic units or a portable lantern-bot.
Current workaround for that is to create explosions under units on every other tick, which is quite suboptimal hack in many ways.

[wheybags]

Turned out to be a bit of a wall of text, but here's some responses to a few questions:

Would it be possible to use this new path finding for vehicles?

No, but I imagine something like this could be faked using invisible units.
In fact, I think Earendel already does something like this in his AAI Programmabvle Vehicles mod.

Does "Units will now avoid pathing through all friendly entities, as opposed to the old behaviour of only avoiding same-force entities" mean that units will intelligently avoid pathing through (and getting stuck on) belts and walls?

No, just that before if you had two friendly forces (let's say A and B), and you surrounded a unit from A in walls belinging to B, the unit would smash its way out if it was commanded to go outside the walls, where if the walls belonged to A, it would just fail the command.

Will there be a toggle for not separating groups "automagically" under circumstances that are hard to precisely characterize?

Yes.

I’m aware this might be difficult, depending on pathfinder implementation, but I’d love to be able to get paths that obey the constraints of vehicles — specifically the limited turning radius.

Not likely, this could be done as a custom pathfionder in lua, and you could just pass the result into the game.

is it possible to limit pathfinding to a vector of tile names?

Again, I would do this as a custom pathfinder in lua.

It would be great if an asynchronous pathfinding request could be made so that the path of a failed status code could be returned and I could use the returned path data to drive the vehicle. The kinds of data to send and get back are outlined here: viewtopic.php?f=28&t=39896

Allowing the patrhfinder to return partial results on failure is on my todo list.

Sometimes units disappear ...

I've solved this with a prototype flag, destroy_when_commands_fail.

... or lose their orders

There will be a callback when a command finishe (whether it succeeds or fails), so you should always be able to recover from this.

almost impossible for figure out if a unit actually had a proper order already

Yeah, this does suck a bit atm. Our current workaround for compi is we set a global var when we give him a command, and unset it when he completes the command, but it's not ideal. This works when you have full control from lua over the unit, but if you're letting the biter behaviour do it's thing too, i t wouldn't really work.
We could maybe add some better way to detect this.

...it is necessary to check that a unit's position is still valid...

What do you use this for?

Being able to make a unit prototype immune to all 'stickers' would be great.

That makes sense, yeah.

it would be great if the a lot of the unit mechanics could be extended to vehicles

That's unlikely to happen for now, sorry

Also, a flag to prevent units from attacking blocking trees and other obstacles would be nice.

Sure, that make sense.

[eradicator]

it would be great if the a lot of the unit mechanics could be extended to vehicles

That's unlikely to happen for now, sorry :(

What about characters?

Possibly slightly off topic but i just remembered an old problem: making the player character walk somewhere (old thread, forum update apparently broke the code sample.)

The goal was to make the player walk a short distance (10-40ish tiles) towards an entity. As far as i understand currently i can't use ai commands on a player character, but i imagine the ability might come in handy in the campaign, i.e. for cutscenes. Would that be a reasonable request? ;)

[wheybags]

Also unlikely unfortunately.
If you really need it, you could switch the player's controller, delete the character entity, and place a unit with the same animations, then swap back at the end.

[eradicator]

Also unlikely unfortunately.
If you really need it, you could switch the player's controller, delete the character entity, and place a unit with the same animations, then swap back at the end.

I thought about that too, but that would make the toolbar/inventory behave in weird ways. Not sure why i'd need to switch the controller (type?) for that though? Might still be better than the laggy character.walking_state. Thanks for the answer :).

[wheybags]

You'd need to change the controller because the default (character) controller will ask you to respawn if you destroy its character entity.

[eradicator]

You'd need to change the controller because the default (character) controller will ask you to respawn if you destroy its character entity.

I see. Setting character to nil works though, and i'd need the old character to attach it back later anyway. Just need to find a place to hide it ^^. Just out of interest... is lag hiding applied to all "character" (i.e. "player") type entities? Otherwise it might be worth trying walking_state on a disconnected character.

[wheybags]

I'm not sure, I haven't worked with that part of the code. I would guess lag hiding is only done when there is an actual player attached though.

[Earendel]

...it is necessary to check that a unit's position is still valid...

What do you use this for?

It's not specific to units exactly, but comes out of using units for pathfinding.

Example 1:
A vehicle is following a found path, often the vehicle is moved by activating the real vehicle acceleration, but in some situations it's necessary to teleport the vehicle. The movement is supposed to be fake vehicle movement so the distance each frame is far less than the collision radius and therefore checking that the target position is empty won't work because the target position overlaps the vehicle's current collision box.

Example 2:
A vehicle is rotated via script and now overlapping something and can't move. The inability to move is detected because the vehicle is not changing position, but correcting the situation required finding a valid nearby position, but again the vehicle's own collision box needs to be ignored when finding that position otherwise it would jump at least as far as it's own collision box. (FYI I use a different prototype with a box size equal to the extends of a 45 degree rotated vehicle box to make sure it fits otherwise it would still be invalid).

Example 3:
The player is in zero gravity and is floating around on space tiles until they land on a solid tile. The player is teleported per frame so you get the appropriate floating motion is space. Checking collision for the teleport location is usually not required because a tile lookup is done the next frame anyway and would slow things down unnecessarily, plus the movement distance is lass than the player radius so the check would always return false. When arriving on a solid tile, there's a chance that there is a structure there and they are intersecting the structure. On the single frame where this happens I need to check the player position validity so I co a collision check, but again since the player is already there it will always return false, so I move the player out of the way before checking the position and move them back if valid.

[wheybags]

That makes sense then, yeah.

[CJ5Boss]

The patrol waypoint thing made me curious.
Would there be any way to code a mod, with the release of this version, where I can create robots that will patrol until an enemy comes in range, then proceed to engage in combat?
I haven't seen any mods like this yet, if there is one, please let me know, I want to test stuff out.
Thanks!
CJ

[Klonan]

The patrol waypoint thing made me curious.
Would there be any way to code a mod, with the release of this version, where I can create robots that will patrol until an enemy comes in range, then proceed to engage in combat?
I haven't seen any mods like this yet, if there is one, please let me know, I want to test stuff out.
Thanks!
CJ

In my mod (the one with patrol), they will engage if a enemy comes into range, and once dead, continue patrolling:

[CJ5Boss]

Is there supposed to be a link here? If there is it is not showing up. Thank you!

[Brambor]

I think a link is not supposed to be here as I believe that this is for 0.17, which hasn't been released yet.

[ownlyme]

• Allowing units to path through and open friendly gates.

Has this been added already? My biters don't seem to be able to open my gates

Or am i doing something wrong?

Code: Select all

/c test.set_command {            
 type = defines.command.compound,                      
 structure_type = defines.compound_command.return_last,                     
 commands =
  {                        
  {type = defines.command.go_to_location, destination = {20,0}}          
  }         
 }

it's a behemoth-biter with the "player" force, and walls/gates placed manually

edit: Seems like the go_to command doesnt work at all, but the attack (target=player character) command fails too, while it does work when i'm not behind a wall

[Klonan]

• Allowing units to path through and open friendly gates.

Has this been added already? My biters don't seem to be able to open my gates

Or am i doing something wrong?

You need to put `can_open_gates = true` in the entity prototype