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.) 

I thought to get away with smaller bboxes to make the aim point a bit stronger, but it seems I got my game breaking up with infight errors.

Thanks yeh1 for making this clear to me and qmaster for tracing the bug down.
Thank to iw the monsters now infight in game works decently, which was something I always wondered about. Your explanation was usefull to my modding witz.
I am already glad a monster appears ingame and has the commen subroutines. No infight escaped my vieuwpoint.

Still things I'm struggling with like the double shotgun launch of the Captain and Stratos.
Only the wizard has sort alike attacks, but I want to get them unstrangled.

I am also not so famaliar with the chasm monsters, I only played the first two maps. What I wanted to see was the helicopter . Scratching my beard how to get in somehow.

dev2.10 

Just to clarify, that is the code used by monster_seeker in AD for the double rocket attack.

I also think AD's Zombie knight code will be useful for the Chasm skeleton, and the seeking missile code of the Rockeeter is useful for the Faust.

Perhaps Qmaster can offer some advice on where to track this code down? 

an minor issue, now the stratos corpse sinks into the floor 

Yes I know. And when I lever it's death pose it won't go up in air. 

I think you should improve the melee damage for the Mong, Faust and Stratos, right now, it sometimes takes 7-8 punches from a mong to kill a grunt. Thats too low. The Faust should also have higher health, as they are suppose to wear heavy armor 

You can get the code from either AD or Keep, but the file and organization is the same for most normal projectiles: projectiles.qc

Then of course the calls to launch_projectile are in each monster's qc file: mon_seeker.qc, mon_zombiek.qc, and mon_soldier.qc for the Rocketeer (down near the bottom of the file).

Use notepad++'s CTRL+SHIFT+F to search for the defs for different values (most are in defscustom.qc) for the ALLCAPS_VALUES for damage and speed etc. for each projectile, usually they start with PROJ_


Stratos calls CorpseThink when it dies. I couldn't find it since I donpt habe notepd++ to search on mobile but I assume this fades and sinks the corpse into the ground?