I just checked and I get 261 too. With the broken texture it's 262, so I guess texmex ignores it also. Not sure why it's there or how it got there. 

now working properly after I rewrote all the code to create three.js compatible data:
http://pecope.co/experiments/quake_web_tools/QuakeWebTools.html

Maybe I'll do spr then bsp viewing next. Need to start adding more controls for the viewers too. 

the MDL viewer:
- needs view controls, yes
- should play anims at 10fps, they're all too fast now
- should allow me to select anims based on frame name and play them individually, or skip to an individual frame
- could easily support skin selection too
- would replace moldy old QME23 as my model previewer if you did this 

Thanks for the tips. I plan to do all of those things, but haven't yet, since I was just concentrating on making things work. Definitely want to do all that though, along with the option to display with or without vertex blending (with only at the moment, but trivial to disable) and it might be nice to display some kind of reference model for scale (a 128x128x128 3d box or something...)

I might also add skin lump editing, since that should be easy enough to do, but it will be something for later.

Will also be nice to allow you to preview models and other files that are inside pak files. 

In WaterMove()

if (! (self.flags & FL_WATERJUMP) )
self.velocity = self.velocity - 0.8*wl*frametime*self.velocity;

self.velocity is reduced by an amount that is scaled by frametime, when self.velocity itself is not a framerate-relative variable. I also notice that the player doesn't actually move any slower in liquids. Is this a typo or another weird QCism? 

doing frametime * self.velocity gives you the amount of movement for that frame. 

Yes, I understand that. The player isn't being moved there. The player isn't moved in qc at all, except when teleported, only his velocity - in units per second - is manipulated. The physics moves him. 

I must have misunderstood what you meant then. Why do you say that velocity is not framerate relative? 

Oh, ok, I see. Yes, so velocity itself is not framerate dependant; it's constant. But because we want to reduce speed by a constant amount, we have to multiply by the (varying) frametime to get the constant amount to reduce per frame. 

... because it's in units per second.

Your framerate can vary as much as it wants and your velocity in units per second just is what it is. The amount the engine moves you per frame is different, but that's not the progs's business.


Okay, look.

if (! (self.flags & FL_WATERJUMP) )
self.velocity = self.velocity - 0.8*wl*frametime*self.velocity;

wl is waterlevel, which if you're in over your head is 3. Let's say self.velocity is '100 0 0'. Let's also say the framerate is 60, so frametime = 0.01666.

0.8 * 3 * 0.01666 * '100 0 0' works out to '4 0 0', so the player's velocity when underwater is reduced to '96 0 0'. What's the point? 

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