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 

http://triptohell.info/moodles/junk/quakespasm-spike-r3.zip

Uses fte's replacement-deltas protocol extension by default. helm18 is actually playable for me now (the 10k knights map). The limit is now the renderer+server logic now.
Disable with eg: sv_protocol -666, but leaving it enabled won't hurt existing 666 clients.

Don't expect more big changes any time soon, although I'm still open to bugfixes for the things I broke in the hope that this gets stuff finds its way into the official quakespasm.

Why do I constantly feel like there's something I've forgotten to do?.. Feel free to remind me so I can get annoyed about it anew.
Ooo, maybe its multiple things! 

Minor questions for you whenever you have the time ...

I've tried seed at least fundamental information and examples including looking through engine code some ...

1. Is there a way to specify a particle effect should generate even if the particle would not be in view?

I know in the hands of someone who doesn't understand the mechanics this would be undesirable, but unlike deathmatch (Quakeworld uses of a particle system) where particle effects are primarily used for weapons blasts the uses in single player would be more for persistent weather.

If every time you look at the window, it has to restart the rain from nothing that is undesirable.

2. Is there is a method to see what the current particle count is?

So a mapper can measure the effect burden and make sure the author isn't creating situations where the particle count continually increases because the rate of creation exceeds the rate of destruction (die time, etc.)

3. What "attribute" would kill a particle if it hits a liquid?

4. It looks like models emitting effects is disabled in the particle system (like ability for a pent to emit stardust or what not --- I've seen this effect in DarkPlaces)? I could see that be used to make broken panels that emit sparks in a base map, for instance.

Was there a certain reason that you felt that was undesirable in an engine like Quakespasm or would it have introduced a code burden?

5. What method controls the particles count cap? How do you set that limit?

------

Very awesome feature set Spike! 

1. surface emittence is based on the distance from the view rather than frustum. so keep emitters away from teleporters and use short-lived particles you should be fine. snow will always be problematic in that regard.

2. r_partinfo

3. you can only do it on initial spawn. overwater or notoverwater will filter that effect. use the +foo stuff if you want the particle system to spawn one sort above water and one underwater.

4. using countextra/countabsolute for static effects on trails or emitters is evil and framerate dependant. that makes it undesirable. use r_effect if you want something to emit particles constantly. use r_trail if you want it to emit particles as it moves.
the previous build lacked any protocol extensions for entity fields. the replacement deltas stuff fixes that in r3, so you can resume using flawed stuff for compat with dp.

5. r_part_maxparticles or r_part_maxdecals. Changes to these cvars should take effect on map changes. 

Random stuff:

1. The delta compression should be a big help for coop.
2. Looks like you added makestatic so someone could, for example, make deadbodies from monsters into static entities.

(Is there a way in QuakeC to know if a monster's dead body is in on a lift (i.e. died on a brush entity, not worldmodel)? Specifically to not makestatic those particular dead bodies?)

3. In a previous reply to ericw, you had talked about implementing a mechanism to send multiple packets in the event they exceed 1542 +/- bytes for coop --- is that implemented? I can't tell from the readme if that was implemented.

4. DP_QC_GETSURFACE, so broken vanilla skies stop being broken -- raises this question --- what is a broken vanilla sky?

5. SOLID_CORPSE. Memory block, even reading the DarkPlaces description of SOLID_CORPSE, I can't recall the main use of the feature -- even though I remember it is useful.

6. Sprite groups. spritegroups will now animate properly - this was a vanilla glquake bug Are you aware of an existing mod that used sprite groups? Hipnotic? Rogue? 

(No one will care except Spike but I meant to type 1442, not 1542) 

Could particles be cached in their current state (i.e. paused/frozen), when out of view and then resumed when in view? 

2. makestatic was a vanilla thing. I've not touched it. I probably should do for extra fields, but that would mean that I'd have to actually add support for that.
either way, if the corpse isn't moving then the protocol changes mean that it'll only be retransmitted when it first appears/disappears, there's actually little need for makestatic now.

use tracebox to see if its sitting on a lift or something. or failing that a traceline. or just check thecorpse.groundentity

3. that's in this build, it probably ought to stick to a single packet due to burst, but I didn't include any prioritisation for players and skipping the player every other packet would make it a bit too jerky without better lerping, so it just spams.

4. those solid skys that give particle effects when shot, that affects some percentage of the vanilla maps.

5. so one tracelines and projectiles will hit corpses and yet monsters and players will just walk through them.

6. dpmod is one such mod. go on, get it to run in markv or something. 

"Why do I constantly feel like there's something I've forgotten to do?"

Everyone forgets to add support for 4 players and splitscreen... (FTE doesn't count cause I cant get it to work properly) 

I asked Gunter if he'd be willing to give your Spikespasm a test drive as a replacement for ProQuake server on his coop mod server fvf.servequake.com

I explained the benefits like the automatic server browser.

Something that immediately occurred to me, though ...

1) Quakespasm can't actually serve a protocol 15 game (i.e. standard Quake). The sign-on packet wrongly busts the standard Quake limit, causing the client to immediately disconnect.

2) Gunter asked if it would have ProQuake rcon. I said I'd bring that up.

/I could probably easily obtain more server operator volunteers, but Gunter has run a server for a while and he's already getting familiar with Quakespasm. ;-) 

I didn't make it clear: He said he'd be willing

I explained the single port server advantage, the ipv6 support, and automatic server heartbeat advantages.

(Although Polarite is the one actually in control of the server. I haven't talked to Polarite yet.) 

RCON

* To anyone that doesn't know what RCON is, if someone has a server, the owner can connect to the server and do "rcon changelevel e1m3" from the client.

It is a way to give yourself the ability to issue console commands to the server like change the map.