Can a Scrag fight back against a Faust? 

You could have searched that out in the dev pack.
Faust will fight a wizard, mongrunt,enforcer, army and stratos but they won't respond.
Faust will fight a demon and ogre and they will fight back.

It looks as if most monsters become astrayed when attacked by Faust. 

What about a quake dog? Will that fight the faust? 

I know that the chasm spider also has this issue, where is that code from, a quake fiend? 

When I started coding the Chasm entities I assumed they were alert enough to fight the player. The idea they would fight eachother wasn't in my viewpoint.

The spider code is the same as the rottweiler without the jump code. It will attack other chasm monsters. 

Also check the mincer 

Can you test chasm spider vs quake grunt? 

The map starts with a grunt and a spider. It isn't that hard to check.
For clearance, quake sodier is monster_army, chasm soldier is monster_mongrunt. 

I remember army becoming lame after being attacked by a chasm spider, is this true for you? 

I never had trouble with infighting since I used AD's classtype system, but the magic should happen within T_Damage...usually located in combat.qc or foght.qc depending on the mod's organization.

Lemme take a look at your dev2.09...be a bit 

Bah! It's all pak'ed up. Do you have just the qc files available separately not in a Pak file? I can't open the pak on mobile.

I'm needing to check combat.qc, ai.qc, and monsters.qc and maybe fight.qc. 

Here is the chasm_quakeqc_dev2.09.zip.
It's also in the included progs file in the pak.

And yes, my Army soldier has no attack against spider.

I changed the fight.qc with the same kind of attacks like the army soldier. So the cause must be there somewhere. 

For infighting to work make sure that all the new monsters have monster flag FL_MONSTER.

This is the bit in T_Damage:

if ( ((self.flags & FL_MONSTER) && (attacker != world)) ) {

if ( ((self != attacker) && (attacker != self.enemy)) ) {

if ( ((self.classname != attacker.classname) || (self.classname == "monster_army")) ) {

if ( (self.enemy.classname == "player") ) {

self.oldenemy = self.enemy;

}
self.enemy = attacker;
FoundTarget ();

}

}

}
Check to make sure your enemies are actually different classnames.

So for instance for this entity
void monster_chasmthing = { .....

the classname is monster_chasmthing

Two monster_chasmthings won't fight unless you want them too in which case remove the check for if the classnames are the same. 

Ah hang on, was typing that before you sent the link, let me look at your source. 

It all looks good so far. Not seeing anything obvious. FL_MONSTER is getting set in monsters.qc, you aren't doing any weird classname masking, it's a simple classname check too so nothing fancy there in T_Damage in combat.qc, and the enemies you've mentioned all have a walkmonster_start.

Not sure yet...maybe because in ai.qc inside the CheckAnyAttack function you only ever assign the basic CheckAttack? Try adding in your specialized CheckAttacks for the new monsters? 

Currently, this issue affects three monsters, spider, mong, and faust. Still need to check whether alien warrior will fight back after being hit by mincer and fiend. 

Part of the infighting code works, when a enforcer is hit by a mong, it will turn around and run towards the mong, but it will never fire it weapon. So I guess the more accurate question is: what causes the enforcer to just run in infighting? 

All of the monsters that do not respond have ranged attacks, so maybe that has something to do with it as well. 

Just checked, mincer has this bug also 

Mincer doesn't fire its long range attacks because in progs.src you are compiling mincer.qc and it only has melee. Maybe change to use mincer1.qc since it has a th_missile attack.

Not seeing any reason why the enemies won't shoot back...won't be back home for a couple days so I can't test it myself.

Are the following true??:
Enemy hit by spider will not change enemy
Enemy hit by mong will not change enemy
Enemy hit by faust will not change enemy
Or only enemy with ranged attack hit by spider/mong/faust will not change enemy?
Enforcer hit by spider will change enemy but not attack ever
Enforcer hit by mong will change enemy but not attack ever
Enforcer hit by faust will change enemy but not attack ever
mincer is same as enforcer?
Or Enforcer hit by mincer will change enemy but not attack 

Most of the special CheckAttack functions in fight.qc don't ever get used anywhere and all the new enemies default to the basic CheckAttack()...FYI in case their behaviour isn't quite like it should be. 

Qmaster's post #116 piqued my curiosity because he already looked at, and ruled out, the sorts of problems I would have expected this to be.

I took a look at the code, and the problem is that the new monsters have unusual-sized bounding boxes.

The CheckAttack function (in fight.qc) contains a test where it does a traceline from the attacker's view_ofs to the target's view_ofs. If the traceline doesn't hit the target, the function returns FALSE and the attacker won't launch an attack:


spot1 = self.origin + self.view_ofs;
spot2 = targ.origin + targ.view_ofs;

traceline (spot1, spot2, FALSE, self);

if (trace_ent != targ)
return FALSE; // don't have a clear shot


There's a similar test in e.g. SoldierCheckAttack() etc.

A monster's view_ofs represents its eye level, and is set in walkmonster/flymonster/swimmonster_start_go(). Walking and flying monsters have it at 25 units above their origin, while swimming monsters have it at 10 units above.

The problem with e.g. the Scorpion, Stratos, and Faust is that their bounding boxes are very "short", and don't extend 25 units above their origin. So their view_ofs ends up outside their bounding box. Consequently, when *CheckAttack() aims a trace at the view_ofs, it doesn't collide with the bounding box, and the check fails.

This can be solved by using regular-sized bounding boxes for the new monsters. For a player-sized bbox:

setsize (self, VEC_HULL_MIN, VEC_HULL_MAX);

... or for a shambler-sized bbox:

setsize (self, VEC_HULL2_MIN, VEC_HULL2_MAX);

Alternatively, you could modify the *monster_start() functions to allow you to specify a custom view_ofs. That way you could keep the current bbox sizes. However, I'm not sure that would be a good idea. I've seen other issues in the past involving moving entities with weird-sized bboxes. It seems less problematic to just stick to player- or shambler-sized bboxes; that way, there's no risk of violating assumptions made by existing code (or the engine). 

Dah, that makes sense. For collisions against the world the nearest sized hull is used but for raycasts the actual setsize specified at whatever size is used (might be a limit, not sure). So shooting or sight checks would fail, but collisions for moving stay the same (unless using DarkPlaces hacks but those are horribly buggy). 

Chasm contains three boss monsters bigger than Shamblers, will this become an issue once again? 

For collisions against the world the nearest sized hull is used but for raycasts the actual setsize specified at whatever size is used

Precisely! An entity that isn't VEC_ORIGIN, VEC_HULL, or VEC_HULL2 sized effectively ends up with two different sizes, one of which is used for hull checks against the world etc., and one of which is used for other types of collisions and traces. Which is evil, and can lead to confusing issues. This is one of the reasons I'd recommend against using unusual bbox sizes for monsters in general.

Chasm contains three boss monsters bigger than Shamblers, will this become an issue once again?

It depends.

Big bosses shouldn't be affected by the infighting problem. As I said above, that was effectively caused by the bbox being too short, so that it didn't contain the view offset. A big bbox shouldn't have that problem.

But IIRC, hull-based collision (e.g. collision with the world) is broken for entities that are larger than shambler-size, because as Qmaster said, the engine uses the closest hull size, which is shambler-size. This is presumably why Chthon and Shub are designed such that they don't move around.

So if the bosses don't need to move around, they should be OK?

Alternatively, if a monster's model is bigger than a shambler, but not too much bigger, a mod can probably get away with using a shambler-sized bbox without this being obvious to the player. IIRC, the Gug (from Quoth) is an example of this.

I don't know if either of the above are applicable to the Chasm bosses (bear in mind I know very little about Chasm.)