filesystem dirs are part of the search path too, not just pak files. It looks something like:

1. mod/pak0
2. mod/
3. id1/pak1
4. id1/pak0
5. id1/

Where the first items in the list are the highest priority. 

<a href="https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/QW/client/gl_mesh.c#L296">Here's where glquake constructs the path to the ms2 file. It manually builds the path. 

sorry, messed up the link. Here 

@ericw: That is correct. After these lines, the engine attempts to load the file through COM_FOpenFile(), by looking through the search path, which is the part I was getting confused about.

@metlslime: Yes, I just confirmed that the search path is exactly as you said. In fact, I think I figured out what is going on. Here:

https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/QW/client/common.c#L1513

There are many things that aren't allowed if you're using the *shareware* game data. One of them, it seems, is to read from anywhere that isn't ID1/pak0.pak. That *includes* reading files from the glquake/ dir :) . So, apparently, if you're playing the shareware demo, you're not allowed to use the cached alias models.

I wonder if that was intentional or a "bug"... 

Once upon a time, Tonik wrote a tutorial at Quakesrc.org on how to remove the need for .ms2 files.

There aren't any current GLQuake engines that use .ms2 files. Nobody has used .ms2 files in a very, very long time.

If you want to see the change, take the JoeQuake source code and use WinMerge or whatever Diff GUI you like and compare original gl_mesh.c in GLQuake vs. JoeQuake. JoeQuake page

If I recall, it was a single file change.

I would say you could compare vs. or FitzQuake 0.80 ---metlslime's engine which later was used as a base for Quakespasm --- but the gl_mesh.c changes do a lot more than remove the .ms2. 

Remove the need for .ms2 files? Whoa.

While certainly the engine does not, strictly speaking, need them, I'm not sure I see the need to eliminate them from code. Aren't they used to speed up loading of alias models? Or is there something else I'm not seeing here, a bug, or something else that makes .ms2 files undesirable? 

They do not speed up the load. Your cpu can calculate it faster than it can a read from disk and parse it, according to the original tutorial from Tonik, which may as well be dead as quakesrc.org died ages ago. 

If you keep them there are some bugs to be fixed.

For example, if id1 has a soldier.ms2, and you run a mod with a replacement soldier.mdl, then the engine will use the id1 version of the ms2 and it will look completely messed up. 

ditch them. ditch them completely.
if you want performance, you would just use trisoup (consoles may still benefit from degenerate triangle strips, but that's not the strips+polys apprach that glquake/ms2 goes for). 

Now that's a VERY interesting take on these cached models. It most definitely sounds like a design bug from GLQuake.

Now that we're on the subject, what else have you guys found that might cause issues with custom mods that I should be wary of? 

See http://celephais.net/fitzquake/

And click the "readme". The changelog will give you a pretty good idea.

FitzQuake 0.85 became a defacto standard for mods around 2009 and Quakespasm pretty much carries that torch for a few years.

http://forums.insideqc.com/viewforum.php?f=12&start=50
https://sourceforge.net/p/quakespasm/code/commit_browser

The short version: original Quake had a 640 entity limit. No modern engine has honored that in a decade. And mappers like to make larger maps.

Then in 2009 came FitzQuake 0.85 with big limits for about everything. Then in 2013 came BSP2 (a map support supporting bigger limits), authored by MH with Spike essentially porting it FitzQuake/Quakespasm.

Individual cumulative bug-fixes from GLQuake->FitzQuake 0.85->Quakespasm is likely over 100 --- things from bounding box bugs to palette and texture and skin fixes and a littany of minor bugs discovered since 1999.

Short version: Probably living with most of the limits of 1996 Quake is the right thing to do. If you load up, say, Quakespasm you'll see animation interpolation, rendering improvements, fullbrights, skyboxes, fogs, yada, yada and that state of things evolved over the course of 16 years. 

Thank you, @Baker. These links have helped me a lot to understand the current situation.

Now, I'm intrigued by something you said: There are various engines with increased limits and tons of bug fixes, but at the end you said "Probably living with most of the limits of 1996 Quake is the right thing to do", which sounds like the opposite of what you said earlier... Care to elaborate further on that? 

I tried to paint as accurate a picture as possible to fill you in.

What you decide to do is your choice, obv. 

regarding .ms2, quake was written for opengl 1.0-with-GL_EXT_texture_object.
with gl 1.1, you should be using glDrawElements to draw the entire mesh in a single draw call (which requires either using only triangles, or triangle-strips-with-degenerancy[read: listing the same vertex twice to introduce a discontinuity in the strip, which can have better cache performance if the gpu explicitly optimises for that]).
that's why I say ditch ms2. not just the files on disk, but the ENTIRE strips-and-fans stuff in the engine, regardless of whether you write the file to disk or not.

regarding other engines:
the right thing to do is to go through your engine and make sure you properly bounds check your various limits and/or just remove the limit completely (may still be limited by format/protocol/api datatypes). By now there are maps/mods/demos that will violate every single limit expectation from vanilla, sometimes rediculously so.

at a minimum, expect to need bsp2+protocol 666 support (for the raised limits).

I wouldn't worry too much about dp/fte specific mods (support for those can only really be a long term goal, and you'll never be fully compatible without forking). with quakespasm being crippleware for qc modders, custom qc code isn't really an issue for you, you just need increased entity+precache+static ents/sounds+map format limits, as well as the stuff that baker mentioned (with .alpha support that he forgot to mention). With that list you're pretty much set. Go play some AD maps and you're pretty much set. 

This is relevant; it's a note Carmack wrote back in 1999 or so for the benefit of Linux driver writers and discusses Q3A's use of OpenGL: https://web.archive.org/web/20000303225420/http://www.quake3arena.com/news/glopt.html

During gameplay, 99.9% of all primitives go through a single API point:

glDrawElements( GL_TRIANGLES, numIndexes, GL_UNSIGNED_INT, indexes );

So, for a single texturing card with the current (1.03) Quake3 release, there is one single set of conditions to optimize: completely full featured (vertex, color, texture coord) discrete triangles going through the DrawElements path.

(Carmack's comments about CVA are only really relevant to software T&L cards.)

Since roundabout then the "single glDrawElements" approach has been optimal for all cards and drivers, and since it only needs GL 1.1 (which even Microsoft's software implementation supports; I think the only cards you'd be excluding are first-gen 3DFXs, and if you're using any other GL 1.1 feature - such as calling glBindTexture directly - you've already excluded them anyway) it can be confidently implemented in any engine.

The really nice thing about this path is that there's a clean sequence of steps for upgrading to higher GL versions for better performance.

First you realise that you can set your glVertexPointer/etc in place, offsetting it to point at the start of the frame data, and you don't need to be copying data around all the time.

Then with the data being static you can easily port it to buffer objects.

Then if you want to do frame interpolation you can set up separate glVertexAttribPointers for each frame and add a vertex shader to interpolate (there's an old GL_ARB_vertex_blend extension which can do it without a vertex
shader but no vendors implement it).

From there you can go nuts and add instancing, multi-draw, etc. 

While it would be nice for you to add all the modern limits, the number of mods available to even a 1996 era Quake engine is massive.

Just open up quakedef.h and change MAX_EDICTS 600 to 2048. I mistakenly said 640. 640 ought to be enough for anybody.

#define MAX_EDICTS 600 // FIXME: ouch! ouch!

And you'll be able to run about everything made through 2005 and even some of the releases made later like Travail.

https://www.quaddicted.com/
https://www.quaddicted.com/reviews/

You get all of the classic stuff like Zerstorer, OUM, Soul of Evil and most of the middle period classics like Marcher Fortress, any of the Quoth single player releases --- you'll have the ability to run about 1000 different single player releases.

Sure you won't be running Arcane Dimensions or Warpspasm or anything BSP2.

But if you go with that classics + edicts limit bump, you can still focus on the experimentation you seem to like to do, without dropping everything to implement a big laundry list of stuff.

Anyway, only you know your goals. I hope the info helps. 

Marcher works with MAX_EDICTS 600

/smugface 

or just fork an existing engine instead of trying to create your own.
At this point if you're basing your mod on the vanilla source, you'll have too long an uphill struggle to be able to justify it. 

>uphill struggle

Which is what happens when you decide you want NPR quakes sketch render and take a look at the glquake based source code and compare it to darkplaces. Ouch.