Using D3 Heads

[New Horizon]

Yeah. But first we have to implement this, and then you must ask Orbweaver nicely.

 

Already posted in the wishlist.

[sparhawk]

I implemented it and are now putting it on CVS.

 

The syntax is:

entityDef prop_helmet_test {
"inherit"		 "func_static"
"model"		 "models/darkmod/props/kitchen/chamberpot.lwo"  
"joint"		 "Head"	 
"origin"		 "2 -10 0"
"angles"		 "10 190 80"
"origin_atdm:ai_builder_guard"		 "0 0 20"
"angles_atdm:ai_builder_guard"		 "0 0 0"
"remove"		 "0"
}

The name must match the "classname" on the entity.

// entity 1
{
"anim" "idle"
"classname" "atdm:ai_builder_guard"
"name" "atdm:ai_builder_guard_1"
"origin" "192 -456 -376"
"angle" "90"
"def_attach" "prop_helmet_test"
}

 

If no modelspecific value is defined then the default one is used, if present, otherwise it's 0 0 0 in both cases.

[sparhawk]

The latest revision is on CVS.

[Springheel]

That's awesome Spar, thanks. This should really increase our flexibility in designing unique AI.

 

Now I just have to hit up our modelers for more accessories.

 

Btw, there's a way to make attached objects non-solid, right? We don't want arrows to bounce off regular cloth hats or hoods. If we can make them non-solid, then they won't affect arrows, which could then pass right through to the head beneath (which is what we would want to have happen).

 

I know you can put non-solid in the material definition, but ideally we don't want to have to make a separate material for an attached object--can you put a nonsolid key into the prop entity definition?

[sparhawk]

Now I just have to hit up our modelers for more accessories.

 

Where are they? I seem to not have seen much of them lately. I get the impression that it is mostly NH, ascottk and you around here at the moment.

 

I know you can put non-solid in the material definition, but ideally we don't want to have to make a separate material for an attached object--can you put a nonsolid key into the prop entity definition?

 

If it is in the entity def, then it should be possible. Just try it and if it doesn't work I can implement it as well.

[Springheel]

Where are they? I seem to not have seen much of them lately. I get the impression that it is mostly NH, ascottk and you around here at the moment.

 

Well, Pink just posted the boar head. I don't know where Atti or BT is right now.

[Springheel]

If it is in the entity def, then it should be possible. Just try it and if it doesn't work I can implement it as well.

 

It looks like the key/var is "solid" "0". So that means we can set hats, hoods, etc, to be nonsolid, so they won't block arrows.

[New Horizon]

It looks like the key/var is "solid" "0". So that means we can set hats, hoods, etc, to be nonsolid, so they won't block arrows.

 

That's awesome Spring. Those poor sods won't know what hit their pansy hat covered heads.

[sparhawk]

[Springheel]

We can also make it so hats actually fall off if the character is KO'd. Might be a nice visual effect.

[ascottk]

We can also make it so hats actually fall off if the character is KO'd. Might be a nice visual effect.

It'd be another opportunity for hidable evidence too. I'd also like to have whether or not a certain type of hat would have a small percentage of staying on.

 

One type of hat would have a greater percentage of falling off while others would be harder to knock off.

[Springheel]

Having more than one thing fall off a character is probably overkill (unless it's loot). But it would be a nice touch for civilians. Whether other AI react to it or not I don't know. Seeing a cap lying on the floor seems less troubling than seeing someone's sword, for some reason.

[Domarius]

Well hats get blown off and misplaced a lot more often Plus swords are a weapon and are buckled on. And typically only guards and thugs would be armed? So it would be more suspicious to see a weapon laying around.

[sparhawk]

You can delete or move this post, but I couldn't find the thread with offsets being added for other things. How is this different from what's currently done in the attachment process, where "origin" is used as an offset value from the joint origin you're attaching it to?

 

This was the thread and I merged it in now.

[Springheel]

One thing that's making the attached heads more difficult to work with is the way AI sometimes look up and to the left or right, like the image below. It often creates a gap in their neck.

 

 

Looking up like that isn't really likely to spot the player...I was just wondering how people felt about modifying the 'look around' angles so that they don't look up like that?

[ascottk]

One thing that's making the attached heads more difficult to work with is the way AI sometimes look up and to the left or right, like the image below. It often creates a gap in their neck.

 

Looking up like that isn't really likely to spot the player...I was just wondering how people felt about modifying the 'look around' angles so that they don't look up like that?

Yeah, that is a problem The only way to truely resolve that without modifying the angles is to use the copy_joint decl so the mesh of the neck moves with the body.

 

I think modifying the angles would be a good solution. The rest of the body, as it is, can make up for that.

[Domarius]

Looking up like that isn't really likely to spot the player...

But what if you actually are above the guard? In the rafters, or on a balcony?

[Springheel]

It's probably better to have them not turn their head so much to look up (as was the case in all previous games) then to have a big gap in their neck regularly appear.

[Domarius]

All previous games with head turning was T3. T1 and T2 necks were bolted to the torso

 

I see your point. I guess you meant "not likely to see the player" as in "they will rarely have to do this to see the player".

[Springheel]

All previous games with head turning was T3. T1 and T2 necks were bolted to the torso

 

I know. I'm basically saying that any slight head-tilt they do upwards is going to be better than the previous games, which basically did none at all.

[Ishtvan]

It's fine if they don't look up during regular idle animations, but if you make a noise in some rafters above them, you would expect them to look up at the source of the noise, and see you if you're lit. It would be rather silly if they could never get a visual on you even though you're jumping up and down, full-bright above them, because they can't turn their heads to look at the sound.

[Springheel]

The AI didn't do that in any of the previous games, and no one complained about it. Although if they're tilting their head to look up at the player, then the player won't be able to see the gap in their neck anyway.

 

I'm not suggesting AI look straight ahead if the player is above them, but they don't need to tilt their head ninety degrees so they are facing straight up. If you stop what you're doing right now and glance at the ceiling, I bet you'll move your head only about ten degrees or so--most of the movement is in your eyes.

[Domarius]

But currently the game uses the angle of the head to determine the eye angle, doesn't it?

 

If we can seperate the two, then yeah, there will be no problem.

[Springheel]

How did the previous thief games--where the AI could not tilt their head at all--do it?

[SneaksieDave]

I almost posted the same thing. I'm not really sure. Either they'd have to have constant vertical vision, or it would have to change not based on head movement, which already controls left/right.

 

Maybe there's a way to be generous with vertical vision when alerted, and otherwise still allow for some head tilting (not enough to show razor-throat though).