Prop_keys deleted?

[Ishtvan]

Why were prop_keys deleted? Do we have to put in our own attachment information any time we want to attach a key to an AI's belt now? That's not ideal, as that stuff can take half an hour of teaking to get the right attachment coordinates and angles. Or is the entity with the attachment info still there but moved to a different name?

[Tels]

Why were prop_keys deleted? Do we have to put in our own attachment information any time we want to attach a key to an AI's belt now? That's not ideal, as that stuff can take half an hour of teaking to get the right attachment coordinates and angles. Or is the entity with the attachment info still there but moved to a different name?

 

They should be there:

 

# grep "prop.*ke" def/*
def/tdm_prop_items.def:entityDef prop_goldkey {
def/tdm_prop_items.def:entityDef prop_silverkey {

 

However, I questioned why we have these and the normal keys. It seemed Fidcal could add a "normal" key to the AI without using the prop ones. But then, I am not firm in these things yet.

[Springheel]

The prop keys have the attachment joint and offset information contained within them, where the moveable key entity would (likely) not. I'm not sure exactly how "bind" works, so I don't know what Fidcal did. But unless we're going to stop using def_attach to add things to AI, we should key the prop*.def files intact.

[Tels]

The prop keys have the attachment joint and offset information contained within them, where the moveable key entity would (likely) not. I'm not sure exactly how "bind" works, so I don't know what Fidcal did. But unless we're going to stop using def_attach to add things to AI, we should key the prop*.def files intact.

 

Wouldn't it then make sense to add the attachment joint and offset information to the normal key entities and get rid of the duplication? Or is that for some reason not possible or usable?

[Springheel]

I'm fairly certain we had this conversation a few weeks ago. You can't put multiple joint definitions into the same entitydef (at the moment) so if you need different entitydefs for each joint. So it makes more sense to keep all the attachable entities in the same place.

[Tels]

I'm fairly certain we had this conversation a few weeks ago. You can't put multiple joint definitions into the same entitydef (at the moment) so if you need different entitydefs for each joint. So it makes more sense to keep all the attachable entities in the same place.

 

Yes, but the point is we have only _one_ attachement joint for each prop key (and we only have two prop keys, but like 5 normal ones).

 

Sorry if that wasn't clear from my post above

 

So, specifically, if keys always go to the hip joint, would it make sense to add this to the normal key entity def? That would avoid the duplication between these key entity def groups.

[Springheel]

The current ones might always go on the right hip, but there will also need to be an entitydef for the hand if we ever want AI to hold keys. There might also be one in a breast pocket, etc. If we put the default in the generic moveable_key entity, then mappers would get confused about where to go for the other attachable keys.