Knockback is performed by this code in combat.qc:

// figure momentum add
if ( (inflictor != world) && (targ.movetype == MOVETYPE_WALK) )
{
dir = targ.origin - (inflictor.absmin + inflictor.absmax) * 0.5;
dir = normalize(dir);
targ.velocity = targ.velocity + dir*damage*8;
}

The MOVETYPE_WALK check is one more reason why in practice it only affects players - monsters are MOVETYPE_STEP. If it was simply whether the monster was on the ground (as I suggested earlier) then you would be able to interrupt a fiend's leap with a shotgun blast, but observation tells us we can't in vanilla Quake. The velocity is set directly, so there is no mass calculation (in fact, nobody has defined mass in vanilla Quake).

I tried to drop a hint before but you didn't pick up on it. Let's try again... In vanilla Quake there is some code for the interaction between line of sight and water. Here it is

if (trace_inopen && trace_inwater)
return FALSE; // sight line crossed contents

Now I will translate this code into plain English

if= if
trace_inopen = part of the trace is in the open air
&& = and
trace_inwater = part of the trace is in the water
return FALSE = then the answer to the question of whether the monster can see its target is no
//sight line crossed contents = (because the line of sight passed through the surface of the water)

Put that together:
If part of the trace is in the open air and part of the trace is in the water, then the answer to the question of whether the monster can see its target is no (because the line of sight passed through the surface of the water).

Can you please post your version of this code, and the English translation of your version? 

float (entity targ) visible =
{
local vector spot1;
local vector spot2;

spot1 = self.origin + self.view_ofs;
spot2 = targ.origin + targ.view_ofs;
traceline (spot1, spot2, TRUE, self); // see through other monsters

if (trace_inopen && trace_inwater)
return (TRUE); //was FALSE, sight line crossed contents
if (trace_fraction == TRUE) // Direct line of sight
return (TRUE);

return (FALSE);
};

I think the problem is due is id never intended monsters to see through water if their code 

For the third time, this is a bug entirely of your own making because you haven't thought through what you've doing.

Read my previous post, which anticipated the code you'd changed and the change you made. I carefully described exactly what the unmodified code does in plain English.

If part of the trace is in the open air and part of the trace is in the water, then the answer to the question of whether the monster can see its target is NO (because the line of sight passed through the surface of the water).

Look at the change you've made to that portion of the code, and make the corresponding change to that paragraph of text. Then post the paragraph of text. 

Preach, dude I appreciate you helping me out lot before man, but now feels like there's passive aggressiveness .... I don't get where it's coming from?

I suggested you could just tell me the code fix, as opposed to trying to explain the programming theory behind it... I obviously am not a programmer 

Here's where I disagree. You are a programmer, you're writing a mod. And you need to learn a bit of humility, especially at this early stage. Before you assume there's some obscure bug in Quake, maybe pause and ask if you could have introduced the bug yourself.

This thread does not come with a Service Level Agreement, and I think it's reasonable to try and get you to solve a few more problems yourself. I'm trying to help you help yourself here, and I don't think I'm setting you an problem you can't complete.

To keep things moving, here's the English translation of your code:

If part of the trace is in the open air and part of the trace is in the water, then the answer to the question of whether the monster can see its target is YES (because the line of sight passed through the surface of the water).

Can you see the problem with this yet? 

Honestly I don't really see... Is it because there's no explicit check for brush under the water?

Regardless if I know the "code to English translation", I still wouldn't know the solution 

My mod is actually lagging sometimes and I don't know what causes it??

It's not due to map brushwork.

All I know is it doesn't lag if I look away from roughly the center of the map

Is there any way for me to diagnose this cause, without having reverting my code line by line ?trial and error? 

*without line by line trial and error 

 

Regardless if I know the "code to English translation", I still wouldn't know the solution

Just caught up on this exchange and curious to know if you managed to figure out the answer? 

If there is no 'equal to' symbol in the statement

(I know the code),
(I want to know the solution)

know is equal

symbol in the statement
code to english translation

it means it is not an equation.

It will be considered as an expression.

translation is not a solution. 

did I win? 

if (x && y) is shorthand for if (x == TRUE && y == TRUE)

As far as I can tell, it's wrong because it now returns true too early before doing the requisite trace_fraction check, which was previously the only condition that caused the function to return true. So monsters can now see through solids so long as there is liquid at any point between the player and monster

I think the correct solution would be to just take out the clause altogether 

I think the correct solution would be to just take out the clause altogether

Yes, this is the answer.

I now wish I'd drawn more attention to the purpose of the last line of the function, because the function is easier to understand if you start from there. It's making the final decision about vision, and all you need to know is TRACE_FRACTION < 1 if there are solid obstacles on the LOS between the monster and player.

So what's the line above that doing in the original code? It's checking if the LOS enters both water and open. If it's both, it must have passed through the surface of the water, which is opaque in standard Quake. When we think about this check in relation to the final check, its function becomes: "if the LOS goes through the surface of the water, no need to bother with the obstacle check because the target isn't visible".

If you change that return value from false to true, you've swung the pendulum too far in the other direction! Now you're saying "if the LOS goes through the surface of the water, no need to bother with the obstacle check because the target MUST be visible". What you actually want is to stop caring about the water/air boundary, but still do the obstacle check, and simply removing the check gets you there.