Indexing Attachments For Dynamic Reattachment

[Ishtvan]

I'm starting to write the dynamic reattachment thing for AI's. One issue is we need some way to address the attachment. It hasn't spawned yet, so we don't know its entity name. What I was thinking of is using a number, which is the order it's attached. So for example if an AI has multiple attachments and the def file looks something like this:

 

"def_attach_purse"  "purse"
"def_attach_sword" "sword"
"def_attach_hat"	 "hat"

 

You would address the purse with 1, sword with 2, hat with 3 (or subtract 1 from all those and start at 0 if the programmer gets lazy ). So it's just the order they are in the def file.

 

You could also write "def_attach_1", "def_attach_2" in the def file, so it's easier to tell how to address them from looking at the def file, but this is not strictly necessary.

 

Anyway, once that is set, I'm guessing the console command would be something like:

 

reattach <ai name> <attachment index (the number described above)> <new joint> <new origin> <new angles (in pitch/yaw/roll format)>

 

Alternatively, I could make the console command do a trace to the AI you're looking at so you wouldn't have to type in the AI name. That might be easier.

 

I also plan to write a "frame command" version of this that can be called during animations, to switch attachment of the sword from the hip to the hand, for example. (The animator will have to make sure that the attachment bone on the hand lines up exactly with the sword at the hip before the attachment switch is made though, otherwise you might see it jump)

[Ishtvan]

I noticed a potential problem in Id's attachment code, and this may also be making it more of a pain than it has to be to attach things:

 

This is called on the entity that's being attached. origin is the joint origin and originOffset is the offset from the joint that you input.

ent->SetOrigin( origin + originOffset * renderEntity.axis );

The problem is: renderEntity.axis is the overall axis of the AI. This means the offset you put in is being resolved into the coordinate system of the overall AI model, not the joint. This is bad if you are trying to dynamically re-attach something, because at different times, the joint could have different orientations with respect to the AI, so the offset you enter in would put it in different places relative to the joint, based on the joint's orientation relative to the AI axes at the time.

 

When attaching things, we are defining an offset relative to a joint. Wouldn't it make more sense for the offset to be in the coordinate system of the joint? In fact wouldn't keeping it in the coordinate system of the AI make it impossible to consistently attach something to a joint during an animation for the reasons discussed above? If people agree with me, I'll change it so that the offset is in the coordinate sytem of the joint.

 

Unfortunately it means some of our current offset values for AI attachments may become incorrect (sorry Springheel). Although maybe not, if the joints are not rotated with respect to the AI. @Springheel you picked the hip joint and stuff because it did not rotate during the animation, is that correct? If so, the offsets you found may still work.

[Springheel]

@Springheel you picked the hip joint and stuff because it did not rotate during the animation, is that correct?

 

That was the goal, yes. I've only done a few objects though, so don't let that hold you back from any improvements to the system.

 

That said, I don't entirely understand what you're describing. Oh, wait, this only messes things up if you're attaching something after the model spawns? Ah, now I get it. I guess Id never did any dynamic attaching, though still seems like a strange thing to have in there.

[Ishtvan]

Yeah that's pretty much it. Lets suppose you wanted to have an AI draw a sword off of a sheath on their back. Initially, the sword is attached to their back. We want the AI to reach their hand back, and then switch the sword attachment from their back to their hand.

 

Now in the AI's coordinate system, the direction their spine points to the ceiling is "up." When they reach back over their shoulder to get the sword though, their wrist bone has a different orientation than that. If you call the direction the thumb is pointing "up", the hand's "up" is not the same "up" as the AI's spine. However, with the current code, the attachment offset coordinates acts as if this is true.

 

So if you found a good offset based on looking at how the sword sits in the hand after the AI has drawn it and is holding it in front of them, you couldn't use this same offset and get the same attachment result when the AI was drawing the sword, because their hand would be at a different orientation. Even if you decided to switch the time of attachment around just +/- a few frames of animation, the hand's orientation is changing during those frames and the offset you had found would no longer be valid.

 

That's why I think the attachment offset should be relative to the orientation of the particular joint you're attaching to, not the orientation of the AI's spine. That way if you find an offset that works to attach something when the joint is at one particular orientation, it will still work to attach something the same way when the joint is in any orientation.

[Springheel]

Yes, that makes perfect sense. I can't imagine why they would have done it any other way, frankly.

[Ishtvan]

I dunno, maybe they figured they'd only be attached at the beginning when the AI was in the starting AF-pose, or maybe they just fucked up.

 

Anyway that is fixed now. I'm adding some other functions like ShowAttachment( index ) and HideAttachment( index ).

 

What I'm wondering now is how to do stuff like attachments that become frobable when the AI loses consciousness, and how to define items that count as pickpockets (and make them stop counting as pickpockets when the AI loses consciousness). I have the opportunity to do this now, because I'm looking at the place in the code where the AI updates the attachments when it goes ragdoll.

 

Pickpocket SpawnArg

I'm thinking the items that may be pickpocketed can have a key set like "pickpocket" "1"

And when they die/KO, the code will go thru and set this spawnArg to zero, so it no longer counts as a pickpocket.

 

Removable on death/KO SpawnArg

Pretty self explanatory, the code would go thru and set these items frobable on death/ko, but they should start out with "frobable" set to "0".

 

Alternative to crappy def_drop system

Also, I'm not sure about this, but it looks like Id did dropping of attachments in a crappy way. It seems like you need both a def_attach and a def_drop, you don't actually drop the attached item, but rather spawn a dropped item. In some cases the dropped item teleports onto the floor under the AI. This is okay for Doom2, but for us I think we can get rid of this def_drop crap and just unbind the attached ent from their hand when they lose consciousness, if it has a certain spawnArg. Not only does that save the FM author from adding duplicate entities in def_drop and def_attach spots, but it also makes the entity fall from their hand rather than just appear on the floor.

 

The only issue might be if the item was clipping into the AI when it was bound, what happens when it's unbound.

 

The only reason I can think they might have done this is if something is horribly wrong with unbinding.

[Domarius]

I don't understand this bit;

"def_attach_purse" "purse"

"def_attach_sword" "sword"

"def_attach_hat" "hat"

 

is this saying that def_attach_purse is a pre-defined bone where a purse can be attatched?

 

I imagined you'd just specify a bone and an attatchment, and then start tweaking the position and rotation.

 

So something like

af_bind hips purse

where hips is the bone, and purse is the object def name.

[Ishtvan]

@Domarius:

That's how the attachments are initially spawned on the AI. The offset, angles, joint, etc are all stored in a particular entitydef, like "attached_purse" for example. This is also how they are stored permanently, once the author is satisfied with these values.

 

I'm going to write a "reattach" function that lets you change all this for one of the attachments on the list of things that has already been attached. For the initial values read from the AI's def file, they can put in arbitrary values, as long as something is there for the joint and classname.

 

I don't want to spend time writing a new ingame system that spawns any entity and then attaches it. This would take a lot more time (that I don't currently have), and it's not that much of an advantage. I think the mapper has a good enough idea of what they want to attach that they can add the objects in to the def file of the AI before starting up the game. They don't even have to enter in origin/angles since it'll default to 0 0 0, as long as there's a valid joint and classname for the attachment. Sure it would be more cool if they could just spawn anything ingame and attach it, but it's not that much of an advantage and would require major rewriting. Maybe in the future.

[Domarius]

Yeah makes sense. So all possible atatchments for an AI are listed in their def file, and they are only used in-game if... ?

[Ishtvan]

It doesn't need to be all possible attachments, just the ones that the FM author wants on that AI. However, if they want to attach a new thing to their AI, they first add it to the AI def file (only need to put in the joint and the class of the item being attached), then load up the game and fine-tune the position, and finally note down the final values and go back and put those good position values in the def file.

 

If there were a way to write it to the def file from the game that might help too, although I can't think of an easy way of doing that at the moment. It would be possible, but time consuming to find the right entry, modify the file to remove the old settings and then insert the new ones. Also I'm not sure if D3 even stores which file an entityDef came from.

[Springheel]

It seems like you need both a def_attach and a def_drop, you don't actually drop the attached item, but rather spawn a dropped item.

 

True, that's how it's done now, since the def_attach object vanishes at KO.

 

I think we can get rid of this def_drop crap

 

Your suggestion definitely sounds better, but I wouldn't get rid of the def_drop entirely. It could still be useful for certain things (a dead fire elemental spawning a fire crystal, as an irrelevant-to-TDM example).

 

Pretty self explanatory, the code would go thru and set these items frobable on death/ko, but they should start out with "frobable" set to "0".

 

Yep, we definitely want something like this, so that you can pick up dropped weapons without being able to frob them out of guard's hands.

[Domarius]

It doesn't need to be all possible attachments, just the ones that the FM author wants on that AI.

But what about the things that aren't always there? Like purses, and specific keys?

 

Does the FM author make a new def file for every different combination of AI and attatchments they want in their map?

I suppose that's no big deal, with the basic inheritance system made for def files, should be pretty nice actually. You could make a file called tdm_ai_mansion_guard_bafford_entrance.de

f, which inherits tdm_ai_mansion_guard.def, and the only entry in it would be the af attatchment for the front gate key.

[Springheel]

You should really only have to make one def entry for each object/joint combination. You have prop_gold_key with the origins and angles set to put it on the AI's belt. If you want to put the key around their neck then you'd need a different def entry.

 

It's also possible though that the origins and angles that look good on one character might not look good on another, so in that case you would need separate def files per character as well.

 

Once we get a good list of the typical things you'd want to attach and the joints to attach them to, it should be pretty straightforward for mappers to add their own by copying something that's pretty similar in size and then tweaking it.

[Ishtvan]

@Domarius:

Now that I think about it, if all the defs for attachments exist somewhere, you can add them to AI just by putting in "def_attach "<name of attachment def>" on the AI in the editor. We could keep all the attachment defs in a separate file like Springheel is doing now. This gets a little complicated by how some characters might need different joints/offsets for attaching things than others, but it should still be managable, even if we have to include the character type in the attachment def name or something.

[Ishtvan]

It is done!

 

Please see thread in "current build" section.