Dammit Than, you pre-empted both my ideas there. Here's a bunch of mdl replica of the id ammo crates:

http://people.pwf.cam.ac.uk/~ajd70/ammomdls.zip

They are lit according to the light levels in the map, so you'd have to place them in well lit areas. Some of the skins have fullbright lights on them, ala doom 3. But since fullbrights don't work in some engines you have to be careful. Also at the moment there is one replacement for each model, none of them are combined, but with a bit of care you could get four or more models combined.


For point entity based triggers, there's a neat 4 line change that will give you every type of trigger at once:

Find the line

setmodel (self, self.model);// set size and link into world

and replace it with this chunk of code

if(self.model)
setmodel (self, self.model); // set size and link into world
else
setsize(self, self.pos1 - self.origin, self.pos2 - self.origin );

Then simply add a point entity with the correct classname(eg trigger_multiple). Set pos1 to the absolute coordinates of the minimum point of the trigger, and pos2 to the absolute coordinates of the maximum point.

Doing things so quickly, without making any new entity classes, does have one downside. In worldcraft if a classname is already defined as being a brush entity, it can cause problems making point entities with the same classname.
Adding some extra classnames like

void() trigger_multiplep =
{
trigger_multiple();
}

can help with this, as now you can make trigger_multiplep a point class. This has the advantage that if you need to make changes to trigger_multiple then you only change the code in one place and both classnames are affected.


Other model optimisations:

* Combine all the generic gibs into one gib with three frames, perhaps even combine the zombie gib while you're at it.

* To take it a step further, you could have an optional global flag for maps to disable head gib models(to be replaced by a generic lump of flesh). A saving of one model per monster it pretty good by my reckoning, even if it's a bit of a loss in visual terms.

* Combine the silver/gold keys into a single model with two skins. Only saves you one but it's a total waste right now.

* Combine the flames into one model with multiple sequences - Start with the flaming torch and shrink down/hide all the wooden bits for the other flame. Only a saving if you use both of them in your map, but gets you an extra model if so. This was better when I thought the large flame had a different model to the small one, but that optimisation is already present.

* Combining all the sprites into one large sprite could save you a few models if you're willing to do the work...

There's also a very desperate way to optimise bsp models if you have models that don't overlap in skill settings/coop. For example, you have a wall that appears only in coop, and a totally different brush entity that appears only in non-coop, so that the two are never loaded on the same map. I think I'm right in saying all of the brush entities in a map have their models loaded, even if the actual entity that uses that model is removed because of spawnflags. If you find an entity for which it's worth strictly checking it's in the map before precaching its model, then there is a way: Compile the model as a seperate bsp file, in the way that the original ammo boxes are bsp models. Then have the spawn function for the entity precache the external model.

This last tip is quite fiddly and it's most likely that it's not helpful for any given map. On the other hand, there might be some maps where it makes quite a difference, if the map is very different for coop than single player for instance. So it's worth a mention. 

Thanks for the info.

AFAIK, Kell and Necros have already made a lot of optimisations to Quake's use of mdls. The gold and silver keys, for instance, are already combined. This is basically why I mentioned the other stuff - I thought it might be easy for them to do and wanted to know if there was a reason that they hadn't for instance, optimised the ammo boxes - I'm guessing it's mainly because of the lighting thing.

BTW, there is no spawnflag to set something to COOP only - only DM. 

Aye, we already did the key trick cos it was easy.

The other stuff...not so much. Combining different models - e.g. the gibs - into one is very very fiddly.

Changing the ammo boxes from bmodels to pmodels is something I've contemplated, but not for Quoth. I've always thought it would be a case of 'messing with fundamentals'. However, those replacement models are absolutely top, Preach - nice work! I think we shold test them out in a map to see how objectionable the lack of lightmaps on them really is.
I'd like to hear what other mappers feel about this - do you guys hate the idea of changing the way you have to think about placement and lighting of ammo and health? Or might it actually look better? Will players reject the change?
Of course, unless those models are combined in some way they aren't going to use any fewer precaches are they?

The option to globally disable gib head models sounds fine to me, though I doubt I'd ever use it as a mapper myself.

Likewise, the use of a point entity to define mins/maxs of trigger volumes raises no objections with me, that's really a necros decision.

The sort of model optimisations you're suggesting are feasible, but as I say: very very fiddly and time consuming and prone to irritating errors. And in the end, it might free up, what... a couple of dozen precache slots? Not ultimately efficient enough imo. Rather than asking necros and I to go through all the model optimisation for the sake of two-dozen model slots, it'd be much simpler to ask metlslime to bump FitzQuake's precache limit by two-dozen :P

Re: skin fullbrights. Ack >_< I know, the little bastards always slip through. It seems to be the second line of fullbrights, the flame orange colors, that are the culprits. The only blanket method is to load them into TexMex to clear them of FBs, but the remove fullbright feature is imperfect I think.

BTW, there is no spawnflag to set something to COOP only - only DM.

A "coop only" spawnflag is something I asked necros about waaay back. We wanted to develop some coop specific features for Quoth. It's on the cards, but right now down at the bottom of the deck.

Finally, I'd be interested in seeing Necros' Doom 3 stuff. Has anything been released yet? There is currently nothing on his PQ site.

I'd better let necros answer that himself :/ 

If you wanted to keep the ammo boxes bsp model, you could at least double up the large and small shells/nails by renaming the textures cleverly. If you had a small box with shells textures +0smside, +0smtop and nails textures +asmside, +asmtop you could toggle the "skins" like the textures on a buttons are switched. You could also do that with medpacks. The rest of the ammo is all different sizes so you'd only save three models, but it's better than nothing.

On the other hand, the fact that you'd have to light every place you put an ammo crate isn't that bad in practice. As long as you made it an optional optimisation you can turn on with a worldspawn key then it'd be fine. Regular maps would have bsp lit models, and ones that want the extra model slots would opt in and be more careful with where they put health packs.

I'm pretty sure you can put 11 skins into one model, so I might give that a go. The skins themselves would need some of the textures stretched, since you'd need to apply the same skinmap to each one, but I think it should be possible. The large rockets are awkward though, since they have an irregular shape. Might have to settle for 10... 

QME has a pretty good means of removing fullbrights on the skin. Open the model, go to view -> skin palette map editor, then you can uncheck the two bottom rows of the palette. It then remaps to the nearest colour in a range that is checked. Initially only rows that have already been used somewhere are checked, but you can improve the effect sometimes by checking all the other rows first. You can revert the changes, so you can make multiple attempts and see what looks best.

Also you can swap all the pixels of one colour with another one by double clicking the colour you want to replace, and then selecting the target colour from the palette that pops up. Neither of these methods consider the neighbouring pixels, but generally they'll get rid of fullbright speckles well. Bright red tends to cause a problem, but if your skin has patches of bright red it's best to make them dull/dark before you convert. 

force fields
ladders
entity based triggers

will be in.

can probably convert all ammo box .bsps into 1 .mdl with different frames for different sizes (large, small and different types) along with different skins.
lighting will be better than it is with bsps, because, afaik, quake uses the lighting that was calculated when the ammo box maps were compiled. using mdls for ammo boxes mean the engine will light them appropriatly.
if done correctly, players won't notice any difference at all.

coop only flags is something i'd like to put in. busy atm, but i hope to get that in there.

the thing with spawnflags is that, it appears that the ones in quake already actually control if an entity is spawned before it gets precached at all. this is really good.

a coop flag would be done progs-side, and so would first be loaded by the engine, then removed by the progs. this is less good, but still ok. just not as nice as true engine spawnflags.

as for d3 stuff, i haven't uploaded anything yet. currently, off and on working on a map with those sandstone bricks mixed with tech. kinda like some strange hydroelectric plant. also have a more 'traditional' white brick gothic map in the works. 

I'm pretty sure doing co-op flags progs side will make them as effective as the engine side flags, as long as you make sure the removal code preceeds any precaches the entity code has. All the bmodels in the map are cached regardless of whether the entities that use them are spawned or not - you can check this with the mcache command. So it's only precaches of external files that are reduced by spawnflags, and these are the ones a co-op flag would help. 

i like this a lot!!!

"force fields" 

i was refereing to bmodels. 

and i didn't know that! (wish i could edit posts...) 

You are both so sexy when you talk Quoth. Meanwhile -- ooh, dibs on starting the coop pack idea again! 

It's great to hear from both of you again, and a relief to know that you are still interested in finishing up the Quoth pak1 content.

I've been doing some optimisations to my big map myself, and have managed to add a couple of new enemies without going over the limit for precache models, but I have a lot of secrets that need triggers (more than red777 ;) so that trigger code is going to be a life saver.

I'd really appreciate the head model disable worldspawn flag if it's not too big a deal to implement.

By the way, the info_trap works really nicely - I set them up in my map last night. The only thing it's lacking right now is the ability to set custom models (I really want to use lava balls). There is a lot of flexibility there otherwise - seems like one might be able to make some really nasty surprises for the player with some creative use of the entity.

I think I've asked Metlslime multiple times about increasing limits in Fitzquake, but I don't think he's been working on FQ lately for whatever reason. I'd prefer the max marksurfs were knocked up over the precache models though... that's the real killer right now :/ 35577 :(

By the way, I've been doing a fair bit of texture modification for both my basemap and the knave map, and haven't noticed any problems with texmex's colour conversion or removal of fullbrites. Generally it seems pretty good. 

i will look into the head model disable option. i'm not a fan cause that would just be so ugly, but i can understand the need to scrounge precache slots. on the other hand, entity triggers may be all you need...

also, info_trap was never finished, and it will definatly have the ability to have custom models (sprites and mdl) as well as as much flexibility that is possible. 

And what about new monsters (i.e scourge, ogre_flak, eliminator, pyro, sentinel...) Will they be included finally ? 

I got the bright idea of checking hotmail.com to see if I could find a working copy of your map since the msn file was mangled, and it does have a working file (guess that means msn and hotmail use different means of storage, kinda interesting).

I'll beta test it first thing tomorrow evening when I settle in. 

I saw your email this morning, and I have just sent the stuff again ;P Check your mail box ! 

I'll write up a report soon. I have a lot of comments, but at the moment I'm a bit stuck (in the sludge corridors). It may be something flakey
I've done to screw it up, so I'm going to replay it tomorrow. Maybe with a fresh run I'll have a better idea what the problem may be. 

I'm a bit stuck (in the sludge corridors)

he he he... so you didn't find the exit... I think you still need to explore it a little bit more ;) 

I think that ent based triggers will be all I need to stay under the limits so long as I can use most trigger types in this way... trigger_multiple, void (not so important), once, secret and hurt (again, not so important) support would be nice, but if that's not possible, then once and multiple would be the obvious choices.

By the way, do you have any plans on how the triggers will be implemented? Will we enter the min and max coordinates, or a width and height about the origin of the entity? Either way seems ok to me - I'm really looking forward to implementing them in my big map :)

Also, I think I've found a tiny bug with the monster path follow code. I think this code was modified in a previous version of Quoth so that monsters would face the right way when stopping at a path point. I've noticed that with the ogre at least, there is a barely audible high pitched noise that plays when it gets near a path_corner and continues to play whilst it is near. I'll set you up a map with this in if you can't reproduce it and don't know what the cause is. 

c/d 

the ogre is wierd in that the saw dragging sound gets played whenever it hits a path corner in the old progs. it's possible that that's interfering with the new path corner stuff. i don't really understand what you mean though, but i'll look into it for sure.

also, there's no reason not to support all trigger types as entity triggers. 

ELEK�s unfinished SP "Technophobia" has nice "techy" monster skins, maybe they would fit well into the pack ?

http://tertiary.planetquake.gamespy.com/
http://shub-hub.quaddicted.com/files/maps_singleplayer/techphob.zip 

no.

I'm the first to admit I'm not the greatest skinner ever, but I can do a bit better than slapping some generic Q2 bollox onto the Q1 monsters who, frankly, don't deserve such abuse.

Also, any base map that uses Enya as an ambient sound is to be treated with caution :P 

ELEK did have nice sense of style, nevertheless :-) 

I just completed the level. I'm writing up a report right this moment.

Cheers