its all part of spike's evil plan to stop people from using nearest-filtering!...
*cough*
that or I was just trying to get DP's effects to match, as well as fte's existing particle configs too. high-res stuff (unlike vailla quake) imho looks better with linear.
mix-n-match stuff stops it from being a 1-line change.
probably I'll add some 'nearesttexture' command for it in the particle configs.
side note: the classic particles don't respect gl_texturemode either.

and yeah, the build that I provided is a win32 build, so you'll need the 32bit dependancies.
I could provide both binaries, but for me its easier to focus on a single arch (yes, I'm that lazy).

I have fixes for sock's issues, but I got distracted by the huge deltas... and I now have to fix a load of code, and finish writing a load more. :s 

true, but you can make classic particles square using another cvar, which i think is good enough.

Good point on the high-res content, but then, I'm not sure which is the best way to mix low-res quake textures with high-res effect images, there is an inherent clash of styles there. But if someone wants to make a quakey-looking low-res raindrop, they should be able to make that nearest-filtered. 

Which cvar is that for making the standard particles square? 

r_particles 2 

In file included from progs.h:27:0,
from quakedef.h:226,
from gl_refrag.c:24:
progdefs.h:25:23: fatal error: progdefs.q1: No such file or directory 

The code from quakespasm-spike-r2.zip, that is. 

Grab the progsdef.q1 from:

https://sourceforge.net/p/quakespasm/code/HEAD/tree/trunk/quakespasm/Quake/

To solve your immediate problem. 

type map i_dont_have_this_map

Quakespasm 0.92: Console: couldn't spawn server maps/i_dont_have_this_map.bsp
Quakespasm Spiked: Fatal error dialog: "Quake Error: SV_ModelIndex model progs/player.mdl not precached

Maybe some sort of missing model support similar to DarkPlaces and presumably FTE.

But not having the map will kick you out of Quakespasm as it is a "Quake error" that terminates Quake. 

Host_Error: Mod_LoadLeafs: 121741 leafs exceeds limit of 70000.

So..why is there this concept of a limit anyway. Why can't we just keep allocating more memory as needed and just use more RAM until we run out.

On a related note, why not just precache the entirety of the progs and sound folder at start and forget about precache warnings. Just use more RAM. 

Is the map sealed?
If it's leaking, seal it and the number of leafs should go down by half or more.

No hard limit on leafs is a thing on my wishlist.

Just precaching everything: I guess it would make loading slower, cause issues on old/slow computers, and content depending on that feature would not work in other engines. 

cl_precache_progs 1
cl_precache_sound 1
cl_precache_all 1

Or maybe something like heapsize would be better:
-precache 3 (1 = folder only, 2 = sound, 3 = all)

That way there would still be compatibility with old hardware such as only 1GB ram. 

Quoth has a method to automatically precache custom sounds and models in entities in a map. AD very likely has this too.

Might tell the people in the mapping help what you are trying to do. The solution via QuakeC probably already exists. 

small note: fteqcc's new #merge feature allows 'merging' new code into an existing progs. Combined with the __wrap keyword, you can change existing functions and stuff rather than just adding.
it would be worthwhile even if it was only ever used to add something like misc_model into every mod.
The feature is still a little raw and a little wasteful, and maybe a little too permissive as well, but should otherwise work without needing to decompile anything (and without all the resulting breakages of decompiling). 

That way there would still be compatibility with old hardware such as only 1GB ram

A full Quake install is about 80 mb... 

The idea of precaching all available models is flawed anyway. Health and ammo boxes are .bsp models.

Are you going to precache all the maps in the map folder? No. And there isn't a non-hacky way to distinguish between .bsp that is an ammo box vs. one that is a an actual map.

/Although Mark V actually cracks open the .bsp models and looks for an info_player_start and if it doesn't find one, assumes it is a health box or ammo box or non-playable .bsp

All of this is skipping that to record a demo in anything resembling standard Quake, you have to have the model precaches known in advance. So then you would have to add protocol modifications too.

You would also need to add DarkPlaces missing model support for the feature to work right, because since you aren't using precaches a client has no idea of what it actually needs to play the game.

/Quoth and probably AD already have misc_model support and some sort of equivalent for sound. The right tool for the job already exists. 

I only mean progs folder and sound folder, not the maps folder.

I'm merely curious from a technical perspective why the precaches are even needed. If, let's say, a mod were to precache each and every model and sound in world.qc then no further precaches would be needed any and all info_notnull hacks would work fine as an example benefit (also modders wouldn't need to care about adding those ugly precache lines that are so easy to forget about).

So why not just precache each file in those two folders in a for loop whenever worldspawn is first called. Seems like a pretty neat feature to me.

I don't follow what you mean by demos requiring precache or even what the protocol has to do with it. If its all precached its precached. Mind you I'm only coming at it from a qc perspective. 

Because it isn't compatible with standard Quake.

And that's always been the goal with conservative engines like FitzQuake and Quakespasm.

DarkPlaces is the engine you are looking for. Doesn't DarkPlaces give you a haughty warning like "You didn't precache this, precaching anyway".

That's LordHavoc saying "You are not doing it right". 

In fact, I think it used to say "Model is not precached. Fix you mod. Precaching anyway". 

Precache everything ...

DarkPlaces has client/server download of maps, models, sounds, etc.

Someone does a coop game, the client asks for a list of maps and models from the server.

The precache everything idea would cause a client to download a whole ton of stuff off a server, whether or not it was needed. 

In the case of DarkPlaces, map + model + sound +etc download ...

The server load the progs. If there are no Shamblers in the map, there is no precache of the shambler model, the shambler head, the shambler sounds.

Same if there are no Vores. Etc, etc.

This allows the server to offer the bare minimum of required assets to client.

See this:

void() monster_shambler =
{
if (deathmatch)
{
remove(self);
return;
}
precache_model ("progs/shambler.mdl");
precache_model ("progs/s_light.mdl");
precache_model ("progs/h_shams.mdl");
precache_model ("progs/bolt.mdl");

precache_sound ("shambler/sattck1.wav");
precache_sound ("shambler/sboom.wav");
precache_sound ("shambler/sdeath.wav");
precache_sound ("shambler/shurt2.wav");
precache_sound ("shambler/sidle.wav");
precache_sound ("shambler/ssight.wav");
precache_sound ("shambler/melee1.wav");
precache_sound ("shambler/melee2.wav");
precache_sound ("shambler/smack.wav");

self.solid = SOLID_SLIDEBOX;
self.movetype = MOVETYPE_STEP;
setmodel (self, "progs/shambler.mdl");

setsize (self, VEC_HULL2_MIN, VEC_HULL2_MAX);
self.health = 600;

self.th_stand = sham_stand1;
self.th_walk = sham_walk1;
self.th_run = sham_run1;
self.th_die = sham_die;
self.th_melee = sham_melee;
self.th_missile = sham_magic1;
self.th_pain = sham_pain;

walkmonster_start();
};

If there are no Shamblers in a map --- i.e. no monster_shambler --- it doesn't get precached, the server never has to offer any of that stuff to the client --- in the case of a client offering download like DarkPlaces.

In the case of even a standard Quake client in single player, these do not need loaded into memory. 

no precaches = no name->index->name network compression = omghowmuchdatadoesthisgameneedtosend.

precaching everything = oh look you have more than 256 models that were auto-downloaded from that server you forgot about 10 years ago, so I'm just going to crash now.


that first thing is the real benefit here. if you don't bother precaching then there are issues and lag between when the signal to precache and the model change happens. the second, combined with horrendous loading times, is what prevents the server from scanning+precaching (although if you really wanted that you could always use the search_* builtins from ssqc).

Late-caching (as I'm going to refer to it here), like in DP,FTE,QS'S', is fine for the most part, but there are still some significant gotchas...
Essentually, precache updates are generally sent over the reliable channel, and reliables are 'slow' - they can only be delivered if the prior reliable was already acked. So, if you do a precache_sound("foo");sound("foo"); pair (or the precache is implicit), it is very likely that the sound event will arrive before the precache. The client will then not know what the heck the server is talking about, and the client will be forced to ignore that first call.
This is why engines still have a hissy fit about implicit late-caches. The correct way to use it is to still do it ahead of time. When a client first connects in the case of their player model+sounds for instance, before other players are likely to see their model, or need their sounds.
late-caching an mdl is generally safe, the client should start to display the model once the precache does finally arrive. however, csqc may have issues with it if it can't figure out the model names.
late-caching a bsp is probably problematic because its likely that the client won't rebuild all the lightmaps.
late-caching a sound is likely to result in sound events within a short period just getting lost. The same applies to particles if the engine isn't automatically making up some random precaches on your behalf.

The clients in question are fully within their rights to only actually load the model/sounds once they're needed (vanilla quake's flush command will actually purge mdls and wavs from memory and reload as needed, thanks to its cache mechanism to run on only 8mb ram).


So yeah, precache things properly but not wastefully. If your precaches are dynamic then be sure to leave a delay between the initial precache and when the resource is used. And if you're lazy, at least admit that by putting the 'precache' right next to your setmodel call in a way that should feel as icky to the quakec coder as the resulting behaviour is to the engine).

Otherwise yeah, what Baker said. 

Aren't precaches done locally? If it's server-side does the server send the client a list of models used? Does it matter how long the list is?

So if Mr.Modder, thinking he will save himself the trouble of all those pesky precache warnings (Insert a "Stop all the warnings!" meme here teehee)creates a mod where all 300 custom models and all 654 sounds are precached from the progs and sound folders inside his mod's pak0 file and all these "wasteful" precaches are done in the worldspawn function at game start...what would happen? Crash? Or would it only cause problems for multiplayers joining his game and demo creation? 

The server does send the client a list of models/sounds needed to connect, there is a limit but it is fairly large. DarkPlaces shows this as a bar at the bottom of screen even in single player, Quakeworld clients do it as well.

Other stuff: try it. Start up DarkPlaces twice and have one connect to the other. See what the loading/downloading time is, keeping in mind the internet is way, way slower than LAN or same computer. 

 

I talked Gunter into doing a review of Quakespasm.

He's a very detail oriented guy who plays a coop mod online:

Quakespasm Review by Gunter