Random Idea: Attachable Armor?

[Ishtvan]

Helmets *are* supposed to make them impervious to damage. Metal armour causes arrows to bounce off and break, so no problem there. Cloth hats and hoods aren't supposed to stop any damage at all, and making them nonsolid ensures that, so no problem there.

I'm talking about melee damage. Is the intended design that any helmet will stop 100% of melee damage? You hit a guy with a chainmail coif with a fully "powered up" overhand sword blow and no damage? If that's the case we're okay, if not, we would have to write extra code to propagate the damage, or make the chain coif part of the head model instead of a separate entity.

[Springheel]

Yes, plate is supposed to stop all melee damage as well, which is why only the elites have much plate armour on them (well, them and the builder guards, but the builders have bare heads to compensate--I was actually thinking of this stuff when I did the concepts. )

 

Chain mail is the only problem, as I said. It could either be part of the head model (which makes the head less versatile, since it can only be used for warriors), or it could be a separate model set to non-solid. That means chainmail on the head wouldn't give you any protection, but I can live with that.

[Crispy]

That means chainmail on the head wouldn't give you any protection, but I can live with that.

Yeah, that sounds perfectly reasonable to me. A sword to the head is going to hurt even if you are wearing chainmail, I expect; and while it technically should give you some protection, it's not like anyone's really going to notice. Even if they do, they won't care; simulating armour is not a very critical problem.

 

I think this particular corner sounds like a good one to cut. If it turns out to be a noticeable problem (which I doubt) we can worry about it after release.

[Ishtvan]

Okay, that sounds like it should work. We can still have the chainmail give some protection via the texture dependent damage code. Assuming that is still a viable option performance-wise. Atti's stress test map of multiple textures on the same entity seemed to indicate that it's not that big a hit, but now that we're talking about separate heads and more attached entities, that increases the number of things that need to be displayed separately, per AI.

[Ishtvan]

Hmm, on second thought, this system might still need a change to propagate the damage. The thing is, if the helmet is a separate entity, any and all kinds of damage will only be applied to the helmet and not the AI. There are certain things that definitely should kill/damage an AI with a helmet, like a giant stone block falling on them, or a steam bot cannonball (if we decide to have those) hitting them right in the head. [EDIT: Imagine if you had a trap room with a ceiling that comes down and crushes things. It would be pretty silly to have the ceiling stop when it hit an AI's helmet and just have the AI be wedged in there supporting a whole ceiling without any damage.]

 

Explosions might still work because they have splash damage (although maybe not if it does a trace to determine splash damage, since the explosion epicenter would be on the other side of a solid object).

 

So there are some cases where we want the damage to be propagated from helmet to AI. I wonder if there's an easy way to do that in scripting. It should be possible using SIGNAL_DAMAGE (see documentation forum) to call a script that damages the owner of the helmet, but we're still not sure that signals were completely implemented by Id, since Gildoran said he tried to set up a signal and it didn't do anything.

 

Or, we could also look at how damage gets propagated from the attached head entity to the AI, since that is also technically a separate, attached entity. I think that would be best initially.

[sparhawk]

AFAIK the scripting language is in the SDK. I'm not 100% if really everything is there, but when I tracked the bugs with the arrows, that we had some months ago, I stepped through the scripting code. The interpreter should definitely be there, so I assume also the parser will be there. So if these signals are missing, or we need some additional functionality, we can extend that.

[ascottk]

Related issue:

A lot of the guard models have cloth on the outside of the armor/chainmail. So if we fire an arrow at a guard, like the proguard, the arrow will kill him because the arrow will hit the cloth first. Would it be better to treat that cloth like it's chainmail?

[Springheel]

A lot of the guard models have cloth on the outside of the armor/chainmail. So if we fire an arrow at a guard, like the proguard, the arrow will kill him because the arrow will hit the cloth first. Would it be better to treat that cloth like it's chainmail?

 

Absolutely! The material type isn't supposed to identify what you see visually, it's what you would impact if you hit it. The hardest surface type should be the one listed, regardless of how many layers there are (eg, cloth over metal plate over chain would be 'metal'.)

 

Hmm, on second thought, this system might still need a change to propagate the damage. The thing is, if the helmet is a separate entity, any and all kinds of damage will only be applied to the helmet and not the AI.

 

Hmm, good catch. Though those are probably rare situations.

[Ishtvan]

Okay, a little research on how damage is passed from the head shows the following: Head is class idAFAttachment.

 

/*
============
idAFAttachment::Damage

Pass damage to body at the bindjoint
============
*/
void idAFAttachment::Damage( idEntity *inflictor, idEntity *attacker, const idVec3 &dir, 
const char *damageDefName, const float damageScale, const int location, trace_t *tr ) {

if ( body ) {
	body->Damage( inflictor, attacker, dir, damageDefName, damageScale, attachJoint );
}
}

 

So AFAttachments have a member var "body" that must be set to their parent body, by calling this:

idAFAttachment::SetBody( idEntity *bodyEnt, const char *model, jointHandle_t attachJoint )

 

In other words,

1. All attachments that we want to propagate damage should be of class idAFAttachment, meaning they must have spawnclass "idAFAttachment" in their def.

 

2. We need to modify my idActor::Attach code to call SetBody on AF Attachments. I tried to do this just now. I'll upload to CVS shortly, but I'm not sure about one part of it, the part where it gets the modelname. I'm trying to get "model" from the spawnArgs of the thing that's attached, but I'm not sure that's the right way to go about doing it. The only way to find out for sure if that works is to try it out with a test helmet.

[Springheel]

I'm going to assume this thread was locked by accident...if someone did that on purpose, PM me.