Please send .map and corresponding .wad file... 

sorry , forgotten.
on its way. 

or am I whishfull mapping? 

I still didn't started my part, I'm sorry but my current projetc has some complex issues that I need to solve.... I'll send you the stuff when ready, don't worry, I didn't forget you ;P

BTW Kell, any news on your side ? Or does somebody know how things are progressing on Quoth front ? 

necros and I are in communication, have started working on the beta pak1 content to finish it off. Can't really say more than that atm. 

Great to hear you guys are working on Quoth again. I don't really want to throw a load of crap your way, but I figure that this stuff is worth mentioning anyway...

Is there any chance that the ammo boxes could be changed to require less precaches? At the moment it looks like they use 8 altogether, one for each type of ammo and size :/

It's only of importance to my non-basepack quoth map, which is very large, but it is possible that it could help other mappers who want to make large maps with Quoth in the future.

I suppose the problem with changing bsp models to mdls is that the lighting changes. Is there no way around that?

If there are any other optimisations on this front that could be done that would be fairly trivial and not make a big impact, such as the voreling using less precaches (currently 4?), do you think you might have a look at doing those too?

You might remember that I mentioned something about bounding box triggers before. If it is possible to implement an additional trigger type that uses a user specified bounding box (min/max keys) instead of a bmodel, then it would be incredible. It would sure solve a lot of my precache model problems anyway

Also, I don't know if I mentioned this before, but some enemies have a few fullbright pixels on their skin in places where it looks as if there shouldn't be fullbrights. The drole is the first example that pops to mind, but I think that maybe the death_lord and edie have some very minor problems too.

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'm pretty sure Mindcrime added pure entity based triggers to Nehahra, where you specify bounding box size instead of using a brush (was to be able to modify maps without actually having to completely recompile them), so that's definitely possible. 

Good news: I'm glad to see you back on the Quake scene ! I am waiting patiently for the Quoth update :P 

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.