Shit I see, this is applying additional friction? 

Well, I commented it out and the player still slows to a halt when swimming underwater, so the engine clearly applies underwater drag anyway. So I'm still not clear on the purpose of those two lines. 

interesting, you're quite right:

void SV_WaterMove (void)
{
int i;
vec3_t wishvel;
float speed, newspeed, wishspeed, addspeed, accelspeed;

//
// user intentions
//
AngleVectors (sv_player->v.v_angle, forward, right, up);

for (i=0 ; i<3 ; i++)
wishvel[i] = forward[i]*cmd.forwardmove + right[i]*cmd.sidemove;

if (!cmd.forwardmove && !cmd.sidemove && !cmd.upmove)
wishvel[2] -= 60; // drift towards bottom
else
wishvel[2] += cmd.upmove;

wishspeed = Length(wishvel);
if (wishspeed > sv_maxspeed.value)
{
VectorScale (wishvel, sv_maxspeed.value/wishspeed, wishvel);
wishspeed = sv_maxspeed.value;
}
wishspeed *= 0.7;

//
// water friction
//
speed = Length (velocity);
if (speed)
{
newspeed = speed - host_frametime * speed * sv_friction.value;
if (newspeed < 0)
newspeed = 0;
VectorScale (velocity, newspeed/speed, velocity);
}
else
newspeed = 0;

//
// water acceleration
//
if (!wishspeed)
return;

addspeed = wishspeed - newspeed;
if (addspeed <= 0)
return;

VectorNormalize (wishvel);
accelspeed = sv_accelerate.value * wishspeed * host_frametime;
if (accelspeed > addspeed)
accelspeed = addspeed;

for (i=0 ; i<3 ; i++)
velocity[i] += accelspeed * wishvel[i];
}

seems to apply normal ground friction while in the water, and then the qc is apply extra friction.

you can see this in action by setting sv_friction to 0. you'll slide forever on ground, but in the water, you will still slow down.

very bizzare. 

i suppose... at some point they wanted the player to move slower than normal friction reduction..?
maybe it was easier to do it in QC than to modify the engine.

is there QC from the older version of the progs? maybe this was added in a later version? 

It's like that in the 1.06 progs.

Also, this doesn't actually apply friction either, since player velocity is overridden by the exe based on the player's controls. It acts as a max speed cap, one that caps speed at 96%.

I'm leaning towards cruft/typo. 

This still does the work of creating extra friction and should be left in. It doesn't have much effect when the player is actively swimming in a direction, as the new input tends to overcome the subtracted velocity every frame. It is important for when the player's velocity is not coming from input, like coming to a halt after the player stops swimming. Another example is where the player enters the water with a higher velocity than they can achieve by normal movement - like if they're falling from height into the water. Remove that code and the player will plunge deeper after falls into water, and there's a bigger chance they'll take fall damage from the bottom despite the water. 

96% might not be big, but remember that its 96% every single frame.
it builds up.

quakeworld killed most velocity changes in the qc thankfully. the only one left is from damage. This was basically required for reliable prediction. 

Is there a way to modify the color saturation in the DarkPlaces engine? I was curious about making an infrared vision effect by making the colors black and white, enabling fullbright, and setting fog to black with a short falloff, and maybe also toying with hdr settings to simulate eyes hurting from bright lights. Anyways are there hsv settings I'm missing? 

Where I can download sources v1.06 (*.qc) with fixed problems? 

Maybe try this one?
Or the wike tools
originals from 3D 

Thanks, but:
1. Looks like it's not single player sources
2&3. versions without fixed bugs 

After downloading I also was surprised to find a mod progs.
I searched my whole archive as I was sure I downloaded it.
Can't find it though.

Seven made a new progs but it only works in DarkPlaces.

I wonder if the errors that appear in FTEQcc can be overcome by new coding, on behalve of the double count rotfish. 

This one is probably the best with all the SP fixes:

https://gitorious.org/quakec-v1-01-clean

It took changes from "clean source" and "qip bug fixes" and combined it into one.

(Ignore the fact it says "1.01" -- that was the GPL base, you don't want to know more ...) 

Thanks!
After compile a have same 7 warnings. Example

doors.qc:626: warning F307: type mismatch: void() to void(entity attacker, float damage) entity.th_pain

doors:626: self.th_pain = SUB_Null;

function th_pain require 2 params, SUB_Null without params. Is it will work correctly? 

http://celephais.net/board/view_thread.php?id=60097&start=1343&end=1367 

should work fine, see the 3 or 4 posts in the forum link above. 

@QMaster thanks 

So, I'm spawning monsters after the start of a level. Not just hiding them and then turning them on later, but actually creating new monster entities.

This involves a lot of tricky with spawn functions and precaches, but it works fine (props to gb/Preach).

What doesn't work is incrementing the monster count properly.

I'm using a custom writebyte to do this:


total_monsters = total_monsters + 1;

WriteByte (MSG_BROADCAST,SVC_UPDATESTAT);
WriteByte (MSG_BROADCAST,STAT_TOTALMONSTERS);
WriteLong (MSG_BROADCAST,total_monsters);


Which also works fine, but only the first time a monster is spawned. After that it increments the counter by 2 instead of 1. It doesn't keep on incrementing, no matter how many more I spawn, it just sticks at +2 per spawn.

I'm trying various solutions, but it almost seems like there is some engine side value which is being affected invisibly.

I've traced back all the occurances of total_monsters = total_monsters + 1; I can find and no luck. I've also shifted where/how its incremented a few times and turned off various parts of the process to try and localise the issue, but no luck so far.

Yes, I have an exclusion in walkmonster_start so that doesn't also add to the count...

Any ideas? I'm tempted to make it so that spawned creatures just don't add to the count, meaning the player can get >100% kills, but that's a sloppy fix. 

Stupid mistake in walkmonster_start 

Can I make a recursive function? What is the maximum stack depth? 

You can create a recursive function, the maximum stack depth is 32. This is possible to hit, see http://tomeofpreach.wordpress.com/2013/08/09/going-overboard-with-field-pointers/ for an example and a bit more detail.

Spike posted a warning somewhere on here that local variables to a recursive function are not reset between calls. So you should initialise all your variables like you would in C when writing a recursive function, rather than assume they get initialised to zero. 

Thanks. 32 is very small for my task. I'll have to think of something else 

How much time can be in progess the function? Can the engine to break it off if it is too long time? 

The engine does have a limit, not strictly on time spent, but on number of instructions. You can only run 100,000 instructions in a single think, touch, spawn (etc) function before the QC concludes that there's a runaway loop and the engine packs it in. 

regarding locals getting clobbered in recursive functions, you can try '#pragma warning enable F302' to get fteqcc to print warnings when it detects that locals were not initialised before use.

fte/dp have a higher limit than 32.

you can get around the instruction limit by splitting up your routine into multiple thinks. in general your mod will be unplayable if you do not do this in the first place due to the stalls induced by running the qcvm.
in fte, there's some obscure 'sleep' builtin which will defer the current invocation/coroutine until a later time. doing this will preserve locals but not globals/fields. the instruction limit will be reset in the process. hurrah for infinite loops that won't lock up the game. just make sure nothing is harmed if some other think or whatever function removes the entities in the mean time...