Ai: attach keys

[Bikerdude]

Evening

 

Have attached keys to some of my Ai using the following -

 

"def_attach6" "atdm:prop_silverkey"

"pos_attach6" "belt_back_right"

"name_attach6" "gate_key"

"set inv_name on gate_key" "gate key"

"set name on gate_key" "gate_key"

 

1. How do I make the spawned key unfrobable?(as In i want Ai to be able to unlock a door, and the player not be able to steal the key) or is the only way to do this to place an actual key entity inside the Ai, bind it to said AI and make the key unfrabbable..?
2. How do I make the above spawn keys undropable, currently TDM will alow the player to drop in mid air where AI and the player can get stuck on them.

[PranQster]

My guess is you may have to do the old fashioned way of adding the key entity and bind to the AI, make unfrabable/ungrabable, and tinker with the position. Otherwise it may require editing the properties for all keys wherever they are defined in a .pk4.... at risk of all keys becoming unfrobable, perhaps?

But perhaps there is a way to do it through a script??

Edited September 21, 2011 by PranQster

[grayman]

Is it acceptable that the player not see a key hanging on the AI's belt?

 

If so, AI can unlock a locked door using this spawnarg:

 

"can_unlock1" "Door1"

"can_unlock2" "Door18"

"can_unlock" "func_static_187"

 

It's just "can_unlock" with the optional numbered extensions, and the name of the door.

[grayman]

How do I make the above spawn keys undropable, currently TDM will alow the player to drop in mid air where AI and the player can get stuck on them.

 

If there's no current issue filed against this problem, would you please file one? Thx.

[Fidcal]

Another possibility is create a new def and attach that entity instead, eg,

 

text file:

def\mydef.def

 

entityDef my_unfrobbable_key
{
"inherit" "atdm:prop_silverkey"
"frobable" "0"
}

 

So on your AI you would have...

 

"def_attach6" "my_unfrobbable_key"

[Springheel]

Wouldn't an unfrobbable key be confusing to the player? If I see a key on an AI's belt, I immediately assume it can be pick-pocketed.

[Bikerdude]

Ah lots of ideas, thats what i like!

 

But to clear up the confusion, what my orginal plan idea was to give Ai the ability to unlock a door etc. But I have another question as a result of all the info you guys have given.. can Ai lock the same door after passing through aka T2 style.

[grayman]

Wouldn't an unfrobbable key be confusing to the player? If I see a key on an AI's belt, I immediately assume it can be pick-pocketed.

 

That's a good point. Sometimes it's tough getting in the right position to highlight the key and grab it. If it doesn't highlight, I'm going to spend extra time hovering around that AI trying to get in just the right spot to make it highlight.

 

And spending more time near an AI increases the chance of getting caught.

[grayman]

can Ai lock the same door after passing through aka T2 style.

 

If one AI is involved (no one else is in the queue), he'll lock it behind him if he had to unlock it in the first place.

 

If more than one AI is using the door at the same time (there's a queue), the first AI unlocks the door, and the last AI through will only lock it if it's marked "should_always_be_locked" AND they have a "can_unlock" for that door or they have a key for that door. The last AI to use the door doesn't know that the first AI found it locked, because that info is kept per AI, and not per door.

[grayman]

In the rare case where a door is set up to use door-handling position entities (necessary for AI to use sliding doors), either or both of those entities can have the "ai_no_lock" spawnarg, which means AI aren't allowed to lock the door from that side.

[Bikerdude]

Awesome thanks G-man.

[Fidcal]

I've now just added this about locking doors behind them to the wiki: http://wiki.thedarkmod.com/index.php?title=Doors#AI_Door_management

[Bikerdude]

Ah thanks Fids.

 

If there's no current issue filed against this problem, would you please file one? Thx.

 

Will do :-)

[SeriousToni]

There seems to be something wrong with:

 

Keys carried by AI

 

So you have a door and you have a guard Ai and you want the guard to be able to open/close/lock the door but you also want the player to be able to pickpocket the key. For more info on attaching key, props etc - see Attaching Props to AI.

• "def_attach6" "atdm:prop_silverkey" //the entity to spawn - in this case a key.
  
• "pos_attach6" "belt_back_right" //where the key will spawn on the Ai.
  
• "name_attach6" "door_key" //this gives 'attach6' arg the name "door_key" and is the name the arg "used_by" will need, eg: "used_by" "door_key"
  
• "set inv_name on door_key" "Door key" //The name the key get when the play adds it to their inventory.
  
• "set name on door_key" "door_key" //here it gets a name to be used in the map in general.
  

updated by bikerdude.

 

I tried it out:

 

AI:

• def_attach6 atdm:prop_key_simple
  
• pos_attach6 belt_back_left
  
• name_attach6 doorl_key (doorl means door locked)
  
• set inv_name on doorl_key unlock_key
  
• set name on doorl_key key01 (I have to alter the names key01,key02,etc. otherwise map won't start (multiple entities with same name))
  

Door:

• name doorl
  
• locked 1
  
• used_by doorl_key
  

What happens ingame:

The AI can not open the door. Me neither, as I pickpocket the key.

 

Solution: change the door to

• used_by key01
  

I don't know what is the difference between the attach name and the set name but it happens to be that the attach name is not the one that let's the door go open. It only opens if it is linked to the set name.

So you would have to change the set name for each AI using it and on each door you would have to do a used_by for each key that is usable.

Edited January 15, 2012 by SeriousToni

[SeriousToni]

For more clarity:

[SeriousToni]

Hm when I attach the keys, they're not aligned well. They look like they would lie on a table instead of hanging down on the AI.

 

Is there a way to change this? I tried

"attach_pos_angles_newpos" "0 0 0"

but it doesn't turn the key at all.

[Springheel]

Different keys have different angles of rotation, so you can't mix and match values. It's probably easiest just to "bind" them.

[SeriousToni]

Yeah, guess that's a good idea. Since adding all those different spawnargs would take a long time for all the ai and all the doors, I guess I just use bind and can_open for the ai and used_by for the doors

[Fidcal]

If you use bind you must also use one of the following:

 

bindToJoint LeftHips_Dummy

bindToJoint RightHips_Dummy

 

Otherwise the key is bound to the origin of the AI not the joint so it will move about in the air at an offset from the origin.

[Springheel]

If it's on the belt, it would be better to bind it to "Hips". Neither of those two dummy joints are moved in animations, while the Hips are.

[SeriousToni]

Oh okay, that's very important! Thanks. The wiki was confusing me a bit, what method I should use as it says "this method is outdated, use the def_attach"

[Nort]

On 2/2/2012 at 9:20 PM, SeriousToni said:

Hm when I attach the keys, they're not aligned well. They look like they would lie on a table instead of hanging down on the AI.

 

Is there a way to change this? I tried

"attach_pos_angles_newpos" "0 0 0"

but it doesn't turn the key at all.

Be sure that you're using a prop entity, and not a regular entity. They look and work deceptively similar, the only difference (I've noted) being that props (for example “Props\Keys\atdm:prop_key_simple”) come with default attachment angles, while regular entities (for example “Keys\atdm:key_simple”) do not.

Take care to attach belt items to the "belt_back_right" attachment point, and not the similarly named "belt_back_r".

If you would still like to attach a regular entity, or rotate a prop to a custom angle, you can use the "attach_pos_angles_[attachment point]" properties. However, take note that in the case of attachments to belts, the names of the attachment points are wrong, and so the property you want to assign angles to, is actually the "attach_pos_angles_hipbackr" property (its default values being "90 90 0").

Do not use the "bind" method unless you really have to. It's not meant to attach equipment to AI, and you won't get the AI to interact with it properly. (They won't use the correct animations, automatically unlock doors, and won't say the right lines when the item gets pick-pocketed.)

 

Edited May 23, 2022 by Nort
Cleaned up a lot of misinformation. Sorry about that.

[Nort]

I would also take this time to appeal to the developers to fix/move/rename the attachment points on their models, to something more correct. (The belts on the citywatch AI is rotated 90 degrees, for example, and with five belt attachment positions already existing (although misaligned), I question whether using a sixth is needed at all.)

Edited May 23, 2022 by Nort
Cleaned up my post.

[Nort]

Also, if any of you guys are into editing the Dark Mod wiki, feel free to add my instructions to the attachment page, because I bet they will clear up a lot of confusion and frustration.

Edited May 23, 2022 by Nort
Completely changed the content of the post - lol.