How hard is blackjacking in 1.04

[Springheel]

But if detected I can knockdown every Unhelmet Guard with just a quick hit on his head regardless which side facing. Even if he is facing me. Or worse just simply hitting the mouse button mindlessly a few times which also prevents the AI having any chance to even strike and hurt me

 

Yes, there is a bug right now where you can KO bare-head guards from the front even when alerted. That's not really supposed to happen.

[New Horizon]

Yes, there is a bug right now where you can KO bare-head guards from the front even when alerted. That's not really supposed to happen.

 

Is there? Is that 1.03 only, I don't recall seeing that behavior myself. The KO cones on un-helmeted AI are changing upon alert for me...or at least they were. I'll have to double check.

[fllood]

In thief 1 and 2, players could knock an AI out by hitting them anywhere on their body....including their feet. That's not even remotely possible in TDM.

Thanks NH, yes I'm aware of that My intention to say is that I think many people are more skilled in that discipline. Or in other words: If it's easy for me to blackjack a guard in TDM, anyone can do

 

What do you mean when you say you've been detected? Being 'detected' is not the same as the AI being on 'high alert'. ... When an AI with no helmet pulls out their weapon, they are mainly blackjackable from behind...although a stray hit might get through from time to time.

I do not speak about guards on high alert partrolling with sword drawn.

 

The situation is: The guard is unalert before I start my attempt. With been detected I mean if I fuck up in sneaking in proper position for a blackjack strike behind a guard because he hear or see me in that attempt.

 

If that happens the guard rushs toward me and draws his weapen. If I try to hit the AI within seconds after this detection I had like a one out of four chance to knock him down anyway in 1.03 (the reason I used to rather run and hide). In 1.04 I succeeded every time but one unharmed - also knocking from front - in about a duzon test I did yesterday.

[New Horizon]

Just ran some tests and Spring is indeed right. The un-helmeted guards of 1.04 are able to be blackjacked from the front while alert...which doesn't make any sense since I have the debug tools turned on and their ko cones are being activated properly. It shouldn't be possible. Helmeted guards are working fine on the other hand.

 

I'll take a look into it, I think I have an idea what might be happening.

[Springheel]

Spring is indeed right. The un-helmeted guards of 1.04 are able to be blackjacked from the front while alert

 

This isn't a new thing...it's been the case since the mod was released. I know I discussed it with Ishtvan at one point but I forget why he couldn't pinpoint the cause.

[New Horizon]

This isn't a new thing...it's been the case since the mod was released. I know I discussed it with Ishtvan at one point but I forget why he couldn't pinpoint the cause.

 

I honestly had no idea. It's boiling down to an inheritance issue of some sort. It's definitely not the blackjack passing through the head and hitting the cone, because this would then happen with the helmeted AI and I can confirm it isn't.

 

What I can see so far is that the AI cones physically change, but the 360 settings are over riding.

 

Going to try a few things and then I'll let you know how I fare.

 

Man, this totally explains the completely differing opinions we've gotten on blackjacking difficulty. lol

[New Horizon]

So far I don't seem to be able to fix this in the def files. The solution may lie somewhere in the source code...perhaps here....

 

void idAI::ParseKnockoutInfo()
{
m_bCanBeKnockedOut = !( spawnArgs.GetBool("ko_immune", "0") );
m_HeadCenterOffset = spawnArgs.GetVector("ko_spot_offset");
m_KoZone = spawnArgs.GetString("ko_zone");
m_KoAlertState = spawnArgs.GetInt("ko_alert_state");
m_bKoAlertImmune = spawnArgs.GetBool("ko_alert_immune");
idAngles tempAngles = spawnArgs.GetAngles("ko_rotation");
m_KoRot = tempAngles.ToMat3();

float tempAng;
tempAng = spawnArgs.GetFloat("ko_angle_vert", "360");
m_KoDotVert = (float)cos( DEG2RAD( tempAng * 0.5f ) );
tempAng = spawnArgs.GetFloat("ko_angle_horiz", "360");
m_KoDotHoriz = (float)cos( DEG2RAD( tempAng * 0.5f ) );

// Only set the alert angles if the spawnargs exist
const char *tempc1, *tempc2;
tempc1 = spawnArgs.GetString("ko_angle_alert_vert");
tempc2 = spawnArgs.GetString("ko_angle_alert_horiz");
if( tempc1[0] != '\0' )
{
	tempAng = atof( tempc1 );
	m_KoAlertDotVert = (float)cos( DEG2RAD( tempAng * 0.5f ) );
}
else
	m_KoAlertDotVert = m_KoDotVert;
if( tempc2[0] != '\0' )
{
	tempAng = atof( tempc2 );
	m_KoAlertDotHoriz = (float)cos( DEG2RAD( tempAng * 0.5f ) );
}
else
	m_KoAlertDotHoriz = m_KoDotHoriz;

 

 

I don't understand any of this. In any case, it looks as if the alert angles are only being initiated visually.

[Tels]

So far I don't seem to be able to fix this in the def files. The solution may lie somewhere in the source code...perhaps here....

 

The code just initialized the variables at spawntime. The code which uses them would be elsewhere and refer to

 

m_KoAlertDotVert
m_KoAlertDotHoriz

 

However, the code to parse these is abit strange, it would be easier to do:

 

       // Only set the alert angles if the spawnargs exist, also allowing
       // someone to set them to 0
       m_KoAlertDotVert = m_KoDotVert;
       if (spawnArgs.FindKey("ko_angle_alert_vert))
       {
               m_KoAlertDotVert = (float)cos( DEG2RAD( spawnArgs.GetFloat("ko_angle_alert_vert") * 0.5f ) );
       }

 

(and the same for the horizontal value)

 

Edit: Also, the normal angles are parsed way too complicated, too. A GetFloat() would have been enough.

[New Horizon]

I thought that I might have found the issue in ai.cpp.

 

In this section of code...the bolded red line was missing...so I added it. I figured if m_KoAlertDotHoriz = 0 was defined, then m_KoAlertDotVert = 0 should be defined as well. I thought that missing line may have been the reason for the settings failing to change. Perhaps it is one part of the issue, but after compiling a new dll the issue is still there for non-helmeted AI who go to alert.

 

m_bCanDrown = true;

m_AirCheckTimer = 0;

m_AirTics = 0;

m_AirTicksMax = 0;

m_HeadBodyID = 0;

m_HeadJointID = INVALID_JOINT;

m_OrigHeadCM = NULL;

m_bHeadCMSwapped = false;

m_MouthOffset = vec3_zero;

 

m_bCanBeKnockedOut = true;

m_HeadCenterOffset = vec3_zero;

m_FOVRot = mat3_identity;

m_bKoAlertImmune = false;

m_KoDotVert = 0;

m_KoDotHoriz = 0;

m_KoAlertDotHoriz = 0;

m_KoAlertDotVert = 0;

m_KoRot = mat3_identity;

 

m_bCanBeGassed = true; // grayman #2468

m_koState = KO_NOT; // grayman #2604

 

m_bCanOperateDoors = false;

 

m_lipSyncActive = false;

[New Horizon]

Well, I'm going to leave it alone for now. I've exhausted all my ideas. Clearly something in the code is failing to pass along the proper values when the AI are alerted.

 

I even tried commenting out these settings in the tdm_ai_base.def

 

"ko_angle_horiz" "360"

"ko_angle_vert" "360"

"ko_angle_alert_horiz" "110"

"ko_angle_alert_vert" "180"

 

...and then applying them directly to the AI head def's...but the "ko_angle_alert_horiz" and "ko_angle_alert_vert" settings are not being activated when the non-helmeted ai go to alert 4. Greebo, Grayman...any ideas?

[Springheel]

It's definitely not the blackjack passing through the head and hitting the cone, because this would then happen with the helmeted AI and I can confirm it isn't.

 

How are you testing it with helmeted AI? I can't remember the details right now, but I'm pretty sure there is a differently-sized bounding box on the head when AI are in combat vs when they're not. It's possible the problem only happens with the combat bbox.

[New Horizon]

How are you testing it with helmeted AI?

 

I'm just going into my test map and whacking them in the face with their default 110 horizontal and 180 vertical settings, which are the same as an alert un-helmeted guard. Can't KO them at all from the front, only from behind.

 

I'll look into this combat box and see if I can trace it to that. Thanks for the heads up.

[New Horizon]

Hmmm.

 

The notes in tdm_ai_humanoid say...

 

/**

* ishtvan: This larger box CM for the head is swapped in

* doing collision tests with the blackjack, at all

* times the AI is alive, except when in combat state.

**/

 

So the AI actually use a larger box when 'not' in combat state...so yeah, perhaps it is this difference that is causing the issue. I'll see if I can confirm this.

 

 

Edit:

 

Nope, I have no idea what's going on. This one's beyond my tweaking zone. Perhaps Ishtvan, Greebo, or Grayman could take a peek into the code to see what's happening later on. I'm stumped since I don't really understand the code at all.

 

If it is the box swap, I guess we'll want the box used at all times?

[Springheel]

If it is the box swap, I guess we'll want the box used at all times?

 

Well, the bbox is swapped for a good reason. I forget exactly what that reason is right now...something to do with being able to KO guards with def_attached helmets, while still allowing the helmet to protect from sword blows.

[New Horizon]

Well, the bbox is swapped for a good reason. I forget exactly what that reason is right now...something to do with being able to KO guards with def_attached helmets, while still allowing the helmet to protect from sword blows.

 

 

Ahh. Ok.

 

Anyway, I think we can safely confirm that this has to do with the head bbox swap.

 

I changed the base cone for all AI to 110 and 180. They can't be ko'd at all when their cones are set to this state while idle. When the ko fails, they become alert and then I am able to ko them successfully again.

 

It makes sense to have the swap happen for helmeted heads since they are set to immune upon going into alert 4. Non helmeted heads could be set to ignore this swap.

 

So if there were a setting that could be placed upon non-helmeted heads to prevent the swap, we would be golden.

[Tels]

The code that decides which angle to use is around line 9585 in ai.cpp:

 

       // Check if the AI is above the alert threshold for KOing
       // Defined the name of the alert threshold in the AI def for generality
       if (AI_AlertIndex >= m_KoAlertState)
       {
               // abort KO if the AI is immune when alerted
               if( m_bKoAlertImmune )
               {
                       return false; // AI is alerted, thus immune
               }

               minDotVert = m_KoAlertDotVert;
               minDotHoriz = m_KoAlertDotHoriz;
       }

 

And the code that decides which angle to use to draw is around line 9656:

 

       // Check if the AI is above the alert threshold for KOing
       // Defined the name of the alert threshold in the AI def for generality
       if( AI_AlertIndex >= m_KoAlertState)
       {
               // Do not display if immune
               if( m_bKoAlertImmune )
                       return;

               // reduce the angle on alert, if needed
               AngVert = idMath::ACos( m_KoAlertDotVert );
               AngHoriz = idMath::ACos( m_KoAlertDotHoriz );
       }
       else
       {
               AngVert = idMath::ACos( m_KoDotVert );
               AngHoriz = idMath::ACos( m_KoDotHoriz );
       }

 

Both look ok to me, but NH, I'd put in a gameLocal.Printf() to put out the angle used, so you can make sure the right one is used after all. Maybe the check above is not correct?

[Springheel]

So if there were a setting that could be placed upon non-helmeted heads to prevent the swap, we would be golden.

 

Well, let's not jump the gun. We're going on my vague recollections of what the swap is for. Ishtvan is the one to ask for specifics.

 

edit: here's an earlier discussion of the problem: http://forums.thedarkmod.com/topic/9564-ko-issues/page__view__findpost__p__192275

It never went anywhere, however.

[New Horizon]

Well, let's not jump the gun. We're going on my vague recollections of what the swap is for. Ishtvan is the one to ask for specifics.

 

Yup, I'll run it by Ishtvan, but after changing the idle non-helmeted guards to 110 and 180 and not being able to blackjack them from the front, seems like the swap is the issue at hand.

 

I'll see if Ishtvan can help me test the theory.

 

edit: here's an earlier discussion of the problem: http://forums.thedarkmod.com/topic/9564-ko-issues/page__view__findpost__p__192275

It never went anywhere, however.

 

Thanks, I'll check it out.

[New Horizon]

 

Both look ok to me, but NH, I'd put in a gameLocal.Printf() to put out the angle used, so you can make sure the right one is used after all. Maybe the check above is not correct?

 

Thanks Tels. We're chasing a different trail now. Think I've got it tracked down...just going to confer with Ishtvan.

[Bikerdude]

ok I tried 2 guards and a commoner and the BJ failed on all where on 1.03 its was fine.

 

the position is direclty behind, BJ raised and aiming for the back of the neck and shoulder..

 

Tels, while your at it can you fix the Ai navigation bug I mentioned in the other thread...

Edited March 5, 2011 by Bikerdude

[New Horizon]

ok I tried 2 guards and a commoner and the BJ failed on all where on 1.03 its was fine.

 

Very strange...nothing changed between 1.03 and 1.04 to account for anything being that different, but then again...before the tweaks I submitted over the last few days, these were the kind of unpredictable results I was getting too. It was very finicky. I think 1.05 is going to be much more solid in the blackjacking area...just have to squash this issue with unhelmeted AI being blackjackable from the front while on high alert, and I think we're going to be good. Just waiting to hear back from Ishtvan.

[Tels]

Tels, while your at it can you fix the Ai navigation bug I mentioned in the other thread...

 

Apart from be having more than a dozend SEED issues to still care for, I have virtually no experience with AI. And since I do not want to break anything, I will not work on AI at all. Sorry.

[Springheel]

For the record, I was playing the player build last night and KO'd three patrolling citywatch, on stone, with no problems at all. I walked up behind them, and swung just about at the moment they said, "Huh, was that something?" One of them I even ran the last step or two to try and get him before he rounded a corner.

[New Horizon]

For the record, I was playing the player build last night and KO'd three patrolling citywatch, on stone, with no problems at all. I walked up behind them, and swung just about at the moment they said, "Huh, was that something?" One of them I even ran the last step or two to try and get him before he rounded a corner.

 

Yup, I think the alert level bugfix really helped out with that behaviour. I don't think players can go on a strafing run and ko someone like you could in Thief, but a short burst with a quick thwack on the back of the head is certainly possible after that bug fix. Feels much better.

[Springheel]

Yup, I think the alert level bugfix really helped out with that behaviour.

 

It may have made it even more forgiving, but I was able to do that even before 1.04. AI on stone only go to alert 1 or 2 before I was in range to KO them.