Ai and chairs & tables

[Bikerdude]

Evening

 

This may be one for G-man, but here goes. I run into this issue everytime I build an area with Ai and tables & chairs.

 

1. you place the Ai, chair and table so its correctly positioned etc.

2. you alert Ai and they either get stuck on the stable or the immovable chair, so you increased the distance between chair & table. but then the gap looks between chair/table looks stupid.

3. you change the chair to moveable, but then the alerted Ai kick the chair so when they come to sit back down, they do so in mid air.

4. you then change the chair back to immoveable, and get the Ai to turn around after they have sat.

 

Before now I have made the table noclip and then put a smaller nosolid brush to support anything on the table and then a similar sizer monsterclip brush to stop the Ai getting stuck on the table - but this is a hack job at best. What I would like to do is have the Ai turn around in the opposite direction to the one in step 4. when they are alerted. Atm they don't, they just stand straight up.

[grayman]

The best setup for the table is to monster_clip it and run the clip to the ceiling. This guarantees that AI won't walk into it. If you don't clip it, they can walk into it because pathfinding doesn't recognize func_statics. (There's no plan to make it do so, since rooms are chock-full of func_statics and checking every one of them takes time and my testing shows that all sorts of weird things can happen due to the unlimited shapes of func_statics.) Since 1.04, any AI treadmilling into a func_static should be making attempts to get himself out of trouble.

 

The best setup for the chair is to make it non-movable and monster_clip it to the ceiling as well. You have to move it far enough from the table so that when the AI sits and turns into the table his legs don't hit the table.

 

AI have the spawnarg "sit_down_angle" which is the compass angle they turn to after sitting down. So you place the path_corner at the side of the chair, rather than in front of it, have the AI turn their backside to the chair, then sit down. The sit_down_angle should then turn them to face the table.

 

When alerted or the sitting path_node is finished, they should do the same thing: turn back to the angle they had when they sat down, and stand up from there.

 

If they're standing straight up when alerted, then that's a bug and should have a bugtracker issue filed for it.

 

Movable chairs are always subject to getting knocked around.

[Bikerdude]

When alerted or the sitting path_node is finished, they should do the same thing: turn back to the angle they had when they sat down, and stand up from there.

 

If they're standing straight up when alerted, then that's a bug and should have a bugtracker issue filed for it.

 

Ok will do a small test map to see whats what and if it is a bug and one hasn't been filed I will do so.

 

thanks for the quick feedback etc.

[Springheel]

Check the sitting AI in A Score to Settle. They spin around when alerted rather than standing straight up. (though I still made the stools nonsolid).

[Bikerdude]

Hmm I will have to look at those Ai then, which one are the best examples so i can see the args etc

[Springheel]

The dice players or Sykes himself should both have those spawnargs set.

[Sotha]

I have reasonably well working chairs in my WIP.

 

The chairs are func_statics with monster_clip.

The path_nodes that bring the AI to the chair are 16 units away from the monster_clip. (16 units from the m_c edge to the path_corner box edge. path_corner box edge, not path_corner origin.)

The path_sit has the angle thing grayman mentioned (so that the AI sits down from a direction he can and after sitting turns towards the table.) You can put the sit_down_angle to the path_sit instead of the AI if you want to have the AI sit somewhere else too.

The AI has sit_down_slide_dist 24. This makes the AI slide into the chair so that there is no gap.

 

My AI can sit down and get up repeatebly without problems. Seems to work. I recommend you to give it a go.

[Bikerdude]

Sotha, could you pm that small section of your Wip so i can have a look please..?

[Sotha]

Sure. Here it is:

 

http://www.mediafire...37p6ec3a8qi9r62

 

Plot: Lord Softass inserts his bottom in comfy places.

 

I left the 16 unit measuring sticks as nodraw in the map. I used them to as a helper to position the path_corners. Usually you can identify the correct path_corner position rather easily with them. However, the system is not foolproof: if the AI happens to approach the seat from a totally different direction, the sitting might go a bit amiss.

 

Still, I am inclined to think that the ultimate solution for the AI difficulty of sitting would be some kind of target_AI_asshole_here kind of sitting helper entity. It would be cool if the mapper could just place such an entity on the chair where the AI's ass should be centered. Then the path_sit would somehow target this and the sitting AI would gracefully slide into the custom placed correct seat position. When standing up, the AI would do everything in reverse, ending back to the path_sit entity position.

[Bikerdude]

sweet, ta.

[Bikerdude]

Sotha, here is your little map with eye candy.

 

 

nb. I had remove the nobleman as he was doing a weird "im almost going to get up " anim when he lays down. Does anyone one know if that bug has been reported...?

sitv2.zip.txt

[Sotha]

Strange.. I never spotted any issues with the nobleman. He sat on the bed and got up without problems.

[Bikerdude]

Strange.. I never spotted any issues with the nobleman. He sat on the bed and got up without problems.

I changed him the sleeping on the bed and only he would atempt a part get up unlike other Ai.

[Sotha]

I changed him the sleeping on the bed and only he would atempt a part get up unlike other Ai.

 

path_sleep? You'd better check the spawnargs of the sit entity you changed. There are probably sit-entity specific spawnargs there: sit_down_angle and stuff. Also the AI has sit_down_slide_dist. For sleeping, he needs the corresponding spawnarg for sleeping. If the sleep entity is in the same position as the sit entity was, the same 24 units should be fine.

[Bikerdude]

Yup did all that including the wait time on the sleep entity, but I also had to put a wait right after the sleep, otherwise any Ai would get right back up.

[Tels]

Sure. Here it is:

 

http://www.mediafire...37p6ec3a8qi9r62

 

Plot: Lord Softass inserts his bottom in comfy places.

 

I left the 16 unit measuring sticks as nodraw in the map. I used them to as a helper to position the path_corners. Usually you can identify the correct path_corner position rather easily with them. However, the system is not foolproof: if the AI happens to approach the seat from a totally different direction, the sitting might go a bit amiss.

 

Still, I am inclined to think that the ultimate solution for the AI difficulty of sitting would be some kind of target_AI_asshole_here kind of sitting helper entity. It would be cool if the mapper could just place such an entity on the chair where the AI's ass should be centered. Then the path_sit would somehow target this and the sitting AI would gracefully slide into the custom placed correct seat position. When standing up, the AI would do everything in reverse, ending back to the path_sit entity position.

 

Even further going, the AI should be able to spto a chair/stool/whatever (when it is tagged with "AIUSE_SIT" and determine the rest automatically. For static things (like a bench build out of brushes) we likely need an invisible "place ass here" entity, tho. So maybe we (er paging Dr. grayman) just add support for that, and then just build combined entities that are a stool and automatically def_attach the required atdm:info_position_sit entity on them.

[Bikerdude]

Even further going, the AI should be able to spto a chair/stool/whatever (when it is tagged with "AIUSE_SIT" and determine the rest automatically.

How would I do that then, would I even need to used a path_sit or just place a path_wait next to the chair..?

[grayman]

Put it in bugtracker, this request for an AIUSE_SIT thingy.

 

Be explicit about how you expect incoming AI to decide whether they should use it or not. We can't have everyone in the dining hall heading for the same chair at the same time, or have AI that aren't supposed to use the chair at all using it.

[Tels]

Put it in bugtracker, this request for an AIUSE_SIT thingy.

 

Be explicit about how you expect incoming AI to decide whether they should use it or not. We can't have everyone in the dining hall heading for the same chair at the same time, or have AI that aren't supposed to use the chair at all using it.

 

This seems to me a slightly related topic: Currently, we have AI on patrols, but if you want some randomness, the mapper needs to lay out a sort of "tracks" system with a lot of path nodes that are interconnected - and the to debug this system is quite complicated - and god forbid you change the map then you need to retest it all again.

 

The only other way we have is for the "animal patrol" used by our rats (but is is neither very rat specific, not very usuable for anything else).

 

This all ties in into the "ambient AI" idea where you just plop an AI into a space and the AI itself finds things to do - look at paintings, stir a pot, sit at a chair, read a book etc. Of course, there should be still some mapper control (e.g. forbit a specific AI to use a chair or a utiltiy (the nobleman does not sweep the floor)), but that would be vastly simpler and could lead to more varied behaviour.

 

Of course, this is quite a daunting task to design and implement such a thing.

 

But maybe for the future we should keep this in mind instead of making the path system more and more powerful and thus more and more complicated to use to the point where most maps can't eve use all the features because the mapper grow old planting path nodes

[Bikerdude]

+1 on the random idea, I like that a lot. In fact is there a way to create a bunch of path nodes thats done link but are of the same group, such as basement_guard_1,2,3 etc and the guard can decides which order he visits those nodes..?

[Springheel]

Be explicit about how you expect incoming AI to decide whether they should use it or not. We can't have everyone in the dining hall heading for the same chair at the same time, or have AI that aren't supposed to use the chair at all using it.

 

I don't see a generic "aiuse_sit" tag working for all cases...our seating models are quite varied, and even something like which angle to approach the seat at varies widely (behaviour that might work on a stool wouldn't work on a chair with arms or a long bench).

 

Some kind of "sit_position" entity could be valuable, however. It would be a square entity with angle spawnargs, that you would position exactly where you wanted the AI's butt to be, as if the AI were actually sitting on the entity. You would rotate the entity so that it was facing the direction you wanted the AI to face when seated. The path_sit node would target the sit_position entity. Essentially, the path_sit tells the AI where to inititate sitting behaviour, and the sit_position tells it where to be when it's finished.

 

In essence, the new entity would just be duplicating the functionality of existing spawnargs on the path_sit node, but it would be FAR easier to position and rotate a visible entity than have to guess at (and continually test and adjust) rotation and position values.

[Tels]

For even easier usage, the "sit_position" entity could be (invisible in game) model of a sitting AI - then you could position it very easily in the editor, but in game the model would be hidden at map start and from then on never visible.

[Tels]

+1 on the random idea, I like that a lot. In fact is there a way to create a bunch of path nodes thats done link but are of the same group, such as basement_guard_1,2,3 etc and the guard can decides which order he visits those nodes..?

 

No, that is the problem with the current setup. You can have the path "branch", and "loop", but there is no real way to have a bunch of guards use the same path nodes, without them f.i. piling up, or all choosing the same branch. It's also not easy to have two sets of "path loops" and then have a guard switch between these two at a given time - unless you somehow script it.