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.