that's (eg) self.noise1 = "doors/ddoor2.wav";

not the same as ambientsound or sound

The code that makes the sounds is

void() door_go_down =
{
sound (self, CHAN_VOICE, self.noise2, 1, ATTN_NORM);

It's using sound, like I said. noise2 is just somewhere to note down which sound to use later. Your solution with the think is a way to achieve what I said about delaying the sound until after the spawn function.

1 what controls how fast an anim plays/speed?

The default is 0.1 seconds per frame. You can manually set the nextthink time in each think function with self.nextthink = time + frame duration;

2 how do i make other player weapons knockback monsters or monster weapons knockback victims? (i know player explosions knock back already)

All weapons knock back like explosions, knockback is proportional to damage. Explosions make the effect obvious because they inflict a big burst of damage and cause self damage. But if you play multiplayer you can see how a full-on shotgun boosts you.

The problem with monsters is that they instantly cancel out velocity with their own movement when in contact with the ground. You'd have to pop them up into the air like how dogs and fiends leap. But note that dogs and fiends have a strategy to unstuck themselves if they land in an awkward position. You might need a plan for other monsters, else players may abuse this feature to easily strand them in stuck points.

3 I'm trying to make monsters see through water with AI.qc trace_inopen && trace_inwater = TRUE, but seems monsters can see through the floor that's under the water? (thus some of my monster faction get angry at enemies located in unreachable areas, "under" the water surface)
can be fixed with code? or engine bug?

If you wrote...
if (trace_inopen && trace_inwater)
return TRUE;
..then the bug is entirely of your own making. Work out what you've done, then ask yourself if sometimes less is more. 

for the water i just flipped some values of defaults from ID... dunno how it actually works

how do you make them not see through the underwater floor? 

about knock back, is there "mass" in quake physics or is every monster as light as the player? 

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. 

 

The current issue is the sounds only start after 7.5s have passed ingame, but if i reduced "self.nextthink = time + 7.5;" to "self.nextthink = time;"/"self.nextthink = time + 0.1;" then the sounds starts crackling because it's playing repeatedly before the sound is supposed to loop?

void () wallfire_sound =
{
sound(self, CHAN_BODY, "ambience/f1.wav", 0.33, ATTN_STATIC);

self.think = wallfire_sound;
self.nextthink = time + 7.5; //3.8 // Schedule next sound play in 1.2 second
};

void () wallfire_sound_Start =
{
sound(self, CHAN_BODY, "ambience/f1.wav", 0.33, ATTN_STATIC);

self.think = wallfire_sound;
self.nextthink = time;
};

void () light_torch_small_walltorch =
{
self.solid = SOLID_BBOX;
self.movetype = MOVETYPE_NONE;
self.skin = 0;
self.frame = 0;
//self.effects = EF_DIMLIGHT; //real light EF_BRIGHTLIGHT
precache_model ("progs/f.mdl");
setmodel (self, "progs/f.mdl");
setsize (self, '-8 -8 -8', '8 8 8');
precache_sound ("ambience/f1.wav");
self.health = 1;
self.th_die = f_break;
self.takedamage = DAMAGE_YES;

sound(self, CHAN_BODY, "ambience/f1.wav", 0.33, ATTN_STATIC);
self.think = wallfire_sound_Start;
self.nextthink = time; 

Try self.nextthink = time + 1; in wallfire_sound_Start

From memory, the first four frames in quake happen at

time = 0
time = 0.1
time = 0.2
<- player connects to server here
time = 1

At the moment, because you're running your functions as fast as possible, your first call to wallfire_sound is happening at time = 0.2. This is too early, so the player can't hear it, and has to wait for the first repeat at time = 7.7 seconds. 

you're saying the minimum delay before a dynamic looping sound can play is 1 sec after the level loads? 

any reason why "sound(self, CHAN_BODY, "ambience/f1.wav", 0.33, ATTN_STATIC); " by itself doesn't work and it needs the separate wallfire_sound_Start wallfire_sound thinks?

f1.wav has a loop marker tho 

You probably only need the sound in wallfire_sound, you can skip the other two. And potentially you can remove a layer of complexity by cutting out the middle function - just have wallfire_sound run after 1 second delay directly after the spawn function.

The old thought experiment goes: if a tree falls in the forest, and nobody is there to hear it, does it make a sound? Is it possible for this to happen in Quake? Yes, in multiplayer it's obviously possible! You can run a dedicated server, carefully simulating the world, even though nobody connected yet.

If a player connects after 30 seconds, they only start hearing the sounds that are triggered from that point onwards*. Even if a 6 second long sound started playing at 27 seconds, they don't hear the back half of it - they heard nothing.

Are the rules different for single player? Not substantially, single player is run under the multiplayer system, just with both ends of the conversation taking place on the same machine. And the crucial thing is that the player doesn't connect immediately in single player, it's more like after the first second. Before that moment, certain actions are being performed to an empty stage, and it appears like they never took place.

One final thing to watch out for is save games. Loading a save that's 30 seconds into the level is very much like connecting to a server after 30 seconds have past. The 6 second long sound that started playing at time = 27 is not logged as partially complete in the save file.

*Ambient sounds are the exception, these are logged and played back to each player as they connect. 

also can TE_EXPLOSION TE_TAREXPLOSION TE_LAVASPLASH be modified? or hardcoded?

and can particles "particle (self.origin, '0 0 10', 5, 2);" be further changed like: increase lifetime of them, make accelerate, change in size, only use a range of or specific colors...

and what causes MOVETYPE_BOUNCE to fall through the floor? i noticed grenades don't, but my custom MOVETYPE_BOUNCE things sometimes do 

also can TE_EXPLOSION TE_TAREXPLOSION TE_LAVASPLASH be modified? or hardcoded?

They are hardcoded, look into TE_EXPLOSION2 for the customisable version.

and can particles "particle (self.origin, '0 0 10', 5, 2);" be further changed like: increase lifetime of them, make accelerate, change in size, only use a range of or specific colors

The only one of those things you can control is color, the 5 in your example code is a palette index (in practice the engine distribute the pixels over a range of palette entries which includes the supplied index).

and what causes MOVETYPE_BOUNCE to fall through the floor? i noticed grenades don't, but my custom MOVETYPE_BOUNCE things sometimes do

Only guess I have is entities are getting spawned in stuck positions. The existing code is careful to make sure grenades spawn inside a solid entity which is their owner. The ownership means that the two do not collide with each other, while at the same time the solidness of the owner will generally prevent any other solid objects from invading the same space.