I'll look into it. Currently there is basically no error checking, and only bsp 29 is supported, so there are bound to be lots of places where shit goes wrong :) 

I examined the texture info lump that I had extracted and found that entry at index 176 was garbage. No idea what caused this; The textures before and after are all fine, so it doesn't seem to be some kind of problem with my reader, but I'll have another look. I can probably get past the error if I just ignore entries with an empty name, so I'll try that for now.

Can texmex open the file? How many textures does it contain? I get 263.

My tools don't care about limits, so maybe there is a problem with this going over the 256 texture standard limit causing an error I haven't handled? Then again, the textures are simply read from the offsets defined in the file, and 176 seems to be the only one that has read as garbage.

Any help you can offer on this would be appreciated. 

I fixed the bug by ignoring entries with no name. This is the data I extracted from the file regarding the garbage entry:

compression: 0
dsize: 21656952111104
name: ""
offset: 5770699
size: 21656952111104
type: 68

Clearly the size and filename are wrong. The offset seems OK, and the type and compression are both the same as the other entries in the file, so it looks like it's just a corrupted entry. 

If anyone has any experience loading models in three.js, please let me know. I am having a lot of trouble formatting MDL data in the format required by three.js because the documentation is very poor. Thank god for Chrome's awesome debugger. 

https://github.com/fzwoch/mdl2js

https://github.com/fzwoch/bsp2js

https://github.com/michaelhoward/Quake-PAK-viewer 

I didn't even bother to search because I just assumed nobody would have bothered. Anyway, that should make things easier :) 

they are c programs. Kinda defeats the point :/

Source might have some insights though. Thanks! 

Seems he already did all of it. It's also pretty fast. Weird thing is that it only lets me play the sounds even though the messages in the log show that it's also parsing the other files.

Now I feel I've just totally been wasting my time and that I should kill myself. 

Do you know if there is a version online somewhere that can preview the other types (I can only get it to preview sounds if I run it locally - even with a webserver behind it) 

I looked at the code and he's just parsing the BSPS but not showing them in a viewer. Also, it's from two years ago, so I guess he got bored. Still pretty neat though, and I can steal his wav preview code for my own nefarious ends >:D

Thanks for the links, and sorry to spam the thread with another thanalogue. 

Well, after basically an entire day spent trying to get MDLs to render using three.js, I have finally got... non-textured pink and white MDL reviews. The texture is previewed below the window.

I will get this working one day, but probably not today. I'm so fucking pissed off with three.js's BufferGeometry class and lack of good documentation that I am going to give it a break for a day or two and perhaps work on .spr instead.

I also fixed that bug that Necros found.

http://pecope.co/experiments/quake_web_tools/QuakeWebTools.html 

i see 261 textures in texmex O_O 

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.