Revamped AI -- share your experiences

[Tels]

Sotha, wile you are right, it should/could be an entity, grayman says the same - a path node is an entity after all.

 

However, using a table might not be wise, the AI would try to run to its center - it is better to have an extra entity and place that somewhere in the empty room. You could even have multiple of them. Using an extra entity class (or a path_node subclass) has the advantage that you can easily filter them in DR, too.

 

What grayman says is that "target" should be used to associate the door with these entities (otherwise the AI does not know which of these entities to search when they find an open door, they might pick the wrong one if they just use the closest one f.i.).

 

@grayman: I think using "target" as spawnarg is still a good idea, because it is already supported (in the editor, the editor knows a target links entity A to B, and there is even a special shortcut (CTRL-K if I am not mistaken). If you think up a different spawnarg, then this must be coded into in various places. The difficulty that "target" means something else for doors could be overcome, because, wouldn't a door be able to distinguish between on of these "search points" and anything else?

 

As for what this new entity should be, it doesn't really matter what class it is underneath (target_null or path_node), as long as the entity class has a good human readable name.

 

Say "atdm:search_spot". Then the mapper places one (create entity, select "atdm_search_spot", selects it, and the door, and hits CTRL-K. Done. The code ensures that the AI is sent over to this entity (or all of them) when the susp. door is found.

[grayman]

I'd prefer to not use the 'target' spawnarg because that already has a meaning for doors. Do we have a precedent for an entity's spawnargs to take on different meanings that are interpreted at runtime?

 

I like the idea of using any entity to focus the search. Since the AI want to go to that spot first, mappers just need to make sure monster_clip and world brushes don't keep the AI from getting there. After that, the hiding spot code takes over and gives the AI all kinds of goals, some of which are reachable, some of which aren't, and some of which (sometimes) can be on the floor above or below (a bug).

[Tels]

I'd prefer to not use the 'target' spawnarg because that already has a meaning for doors. Do we have a precedent for an entity's spawnargs to take on different meanings that are interpreted at runtime?

 

What meaning exactly does it have with doors?

 

 

Don't know from the top of my head of other cases, but I think that esp. the target spawnarg would be such a thing - it is used for all sorts of "targets" - f.i. SEED uses it to denote entities that should be cloned (and it uses I think even different target entities for different things if I am not mistaken), the teleport entity uses it to teleport entities, the message entity I think even uses different targetteed entities and distinguishes them based on their class.

 

So there would be precedent (to use the target spawnarg to target from one entity to the other). As I said, it has other advantages like that DR knows about it so you can actually *see* the connection in the editor.

[grayman]

If a door targets an entity and the spawnargs 'trigger_on_close', 'trigger_when_opened', and/or 'trigger_on_open' are set to "1", that entity is triggered when the door reaches its full close position, starts to open, or reaches its full open position, respectively.

 

So if the code is left as is, and the focal point for a suspicious door search is 'target'ed by the door, and one or more of these spawnargs is set, then the focal point will be triggered. To avoid that, the existing code has to be made smarter, and know when it's really supposed to trigger a targeted entity, and when it's not. And the new code for searching has to figure out which of the possibly many targeted entities is really meant to be the search focus.

 

And--yes--the 'target' spawnarg has multiple meanings when used on different entities, but each meaning is unique to that entity. What I'm wondering is if we've ever given multiple meanings to any spawnarg on the same entity. That's the precedent I'm wondering about.

 

On the other hand, we have precedents for tying two entities together that don't use the 'target' spawnarg. 'bind', 'ent', 'entityname', 'focus', and 'used_by' are a few that come to mind.

 

So I don't see a problem with placing, for example, a 'focus' spawnarg on a suspicious door and setting its value to the name of the focal entity for the search. The 'focus' spawnarg has no existing meaning for doors. Or we could define a new spawnarg, such as 'search', 'search_at', 'search_focus', etc.

[Springheel]

Would there be value in a generic "search_focus" entity that can be connected to any suspicious entity? Not just doors, but lights or loot as well?

[grayman]

Would there be value in a generic "search_focus" entity that can be connected to any suspicious entity? Not just doors, but lights or loot as well?

 

For situations where an entity is involved, yes. The code for all searches--regardless of reason--is pretty much the same: pick a spot and start searching from there.

 

For example, let's say you have a ballroom where an expensive scepter is on display. If a light goes out, or a door is found open, it might be more realistic if the guard starts searching in the vicinity of the scepter than around the door or light.

[Diego]

I have just replayed a couple o missions, but it's hard to tell if something is different. I haven't encountered a single AI stuck in corridors or doors, either alone or with another AI. Might have been luck but this was a frequent problem with AI.

[grayman]

Might have been luck ...

 

Nay, 'twas not luck, but by design.

[Tels]

If a door targets an entity and the spawnargs 'trigger_on_close', 'trigger_when_opened', and/or 'trigger_on_open' are set to "1", that entity is triggered when the door reaches its full close position, starts to open, or reaches its full open position, respectively.

 

So if the code is left as is, and the focal point for a suspicious door search is 'target'ed by the door, and one or more of these spawnargs is set, then the focal point will be triggered.

 

I don't think this is going to be a problem. Apart from the fact that the search_spot entities are pre-defined and do thus not having these spawnargs, even if they had, "triggering" them will do nothing. So even if the code stays, no harm is done.

 

To avoid that, the existing code has to be made smarter, and know when it's really supposed to trigger a targeted entity, and when it's not. And the new code for searching has to figure out which of the possibly many targeted entities is really meant to be the search focus.

 

This is dead-easy. Loop over all the targetted entities (this is btw, a very common routine) and only consider ones that that the right entity class.

 

If you do not use "target" as spawnarg, btw, it becomes much harder to actually *find* the search_spot entities that are associated with the door. Consider the possibilities:

 

* the mapper lists their name on the door: you need then to parse the list, and you need to find the entities by name - doable, but more cumbersome than a simple loop through the tagrets. AND you have the problem that renaming an entity will break that association (that is why target is so useful - DR knows about it and can care about it, freeing the mapper and avoiding pitfalls)

* the entities are alone, but list the door as their primary. Finding all spots that is a lot harder then, and you still have the problem that renaming f.i. the door breaks all the associations.

 

And--yes--the 'target' spawnarg has multiple meanings when used on different entities, but each meaning is unique to that entity. What I'm wondering is if we've ever given multiple meanings to any spawnarg on the same entity. That's the precedent I'm wondering about.

 

At least SEED has that precedent. Normal entities are used as "target class", while other NOSEED entities are used to block areas of (and these are not duplicated like normal entities).

 

The distinguishing between these entities happens on their entity class.

 

As I said, "target" has the nice ability that you can visually construct things in DR; whereas spawnarg-based name-lists are a bother for the mapper...

On the other hand, we have precedents for tying two entities together that don't use the 'target' spawnarg. 'bind', 'ent', 'entityname', 'focus', and 'used_by' are a few that come to mind.

 

So I don't see a problem with placing, for example, a 'focus' spawnarg on a suspicious door and setting its value to the name of the focal entity for the search. The 'focus' spawnarg has no existing meaning for doors. Or we could define a new spawnarg, such as 'search', 'search_at', 'search_focus', etc.

 

I am not a big fan of these other spanwargs - most of them are there for historical reasons, and they all have one problem or another. That the connections are not drawn in DR is a small one, that the code needs to handle each of these spawnargs special is another one - there is code to modify a "target" list - hell, there are even script functions to add/remove targets. But there is f.i. no code to add/remove entities from a "focus" list, or from "used_by" etc.

 

Unifying these things with the same underlying connection mechanism would realy simplify some things, so my vote goes to not invent yet-another-spawn-arg-that-is-like-target-but-only-implements-80% of it

[Springheel]

If a light goes out, or a door is found open, it might be more realistic if the guard starts searching in the vicinity of the scepter than around the door or light.

 

Would it work if the "target" spawnarg went on the search entity itself? That way it could target more than one thing (a light and a door, for example) and it wouldn't interfere with the door's targets.

[grayman]

Would it work if the "target" spawnarg went on the search entity itself? That way it could target more than one thing (a light and a door, for example) and it wouldn't interfere with the door's targets.

 

The suspicious stim (door, light) is the one talking to the AI, so it needs to define where to start searching. The search entity knows nothing; he's just a focal point for the search.

[grayman]

I prefer to not overload the 'target' spawnarg.

 

This opens the door to making any entity the focus of the search. A mapper could use a generic target_null, a path_node, a light switch, a table, the lord of the manor, whatever. ('lord of the manor' - a guard finds something suspicious and needs to search for his boss to make sure he's not in any danger. Even if his boss is on the far side of the house, the guard will seek him out.)

 

If I use 'target', none of that is possible, because if the entity chosen is triggerable (i.e. a light switch, the lord), it will be triggered if the suspicious door is already set up to target things via the open/close/opened spawnargs.

 

So I'm still proposing that suspicious doors, suspicious electric lights, items marked 'absence_noticeability/1', etc. can be given the optional spawnarg pair

 

"search_focus" "<entityname>"

 

to invoke the requested change in search behavior.