Thanks for the elaborate reply. From your answer, it seems as if there's no need to access specific frames within a frame group. This might explain why the engine uses the same parameter for either a specific frame in a single series variant or a specific group in a group variant. This seems to indicate that the current engine logic is still valid also for frame groups, so the real error is in fact the QC request (which anyway is the prime suspect).

I forgot before to ask about the frame names, but you brought it up anyway. As you say, the mdl frame names seem arbitrary and don't affect anything in the engine. This matches what I've seen in the code; the names are not used for identification, only the frame/group numbers are important. And the names used in QC source are only used there (i.e. by qcc).

I also know that QuArK is not the best tool here, but it has been sufficient before when repairing skins. As far as I can see, there's no indication at all in QuArK for the actual frame grouping, so I don't know if/how it reads/writes this info. At least it hasn't generated any obviously bad mdl files so far. Maybe it's using the names to generate grouping?

As for paks with these errors well, there are quite a few. The most recent one is the Chapters pak. Enable cvar developer 1 (should always be enabled when troubleshooting and IMO otherwise too) and load the map shamblertest. You will immediately get warnings from basically any engine with more or less helpful info.

With my current GLQuake beta, I get the warning R_SetupAliasFrame: no such frame 159 ('stand1', 94 frames) in progs/shambler.mdl. This tells me that it's a single series frame and requested frame index is way beyond the # frames available (94) in the shambler mdl.

Why such an excessive index is requested from QC, I don't know. A vague theory is that the shambler mdl is somehow mixed up with the drole (which has many more frames) and/or there's something fishy with the last teleporting shambler in this test map. It doesn't seem to happen in the actual pak maps so it's not a big problem here, just puzzling.

Otherwise, the pak I'm trying to fix right now is the old Abyss of Pandemonium. There are many problems here; get all weapons and try the new ones (6-9) out. You'll find that with at least three of them, there are frame errors. Use my latest engine to track models. There are also errors when breaking a glass window in aop1m4 to get a quad and when killing the Blud monster in aop1m6. Not to mention demos being royally screwed up ...

If you need more examples, just let me know.

The poses I mentioned before are variable names (firstpose, numposes) in the mdl/frame objects which I think are related to the modulo operation you mentioned; they're used together with a frame time interval. It's a bit confusing with the naming convention here; group vs frame vs pose ... 

I noticed a complimentary problem in the Xmen TC, with the quakec calling skin numbers that don't exist. In glquake this caused a white skin IIRC, but in software quake it just stayed on whatever previous skin it was using. I believe i changed fitzquake to emulate software quake in this case, except with a warning message. 

Yeah, that's Floyd. He's already animated, walks around, shoots people, and dies. I regret not modelling the gun muzzles, but at this point i am loathe to touch qME again after using real modelling tools. So i'll probably use him as is. 

Yes, the original GLQ had bad handling of missing skins; it displayed them in some psychedelic colours. I also just copied WQ handling (reset skin to 0) and added a warning. A lot of paks have skin problems too, e.g. the original Source of Power.

Often the pak author added new skins to the main mdl, but completely forgot about the corresponding h_* mdl (gibbed head). Gibbing a Custents' baby shambler could e.g. cause an engine crash. 

Is there a way to make a trigger_multiple be triggerable by monsters? 

If you mean 'by walking into it' then no, not in default id progs. Only by monster death -> target -> targetname.
With custom qc, probably. Monsters certainly can use trigger_teleports, so presumably a custom trigger can be created that allows monsters to affect it. Preach would be able to answer that question. 

Overscaling textures does not, in my experience and as far as I know, have any negative effects on either the map or the engine. It's purely a matter of aesthetics. 

I have a door that, for various reasons, needs to be triggered by a custom-sized trigger_multiple. It looks strange when monsters can't open it, but other strange things happen if it's opened like a normal door.

Oh well, I guess I'll live with it one way or the other. 

If you want to use custom QC, it's a pretty easy fix. The function you want is
void() multi_touch
in triggers.qc, and you'll spot right at the start the function says

{
if (other.classname != "player")
return;

This, of course, locks out anything that isn't a player, so we want to change that. If you want it so that every trigger_multiple can be affected by every monster on the map, you could replace that line with

{
if (other.classname != "player" && !(other.flags & FL_MONSTER))
return;

If you don't want a global change, just the option to toggle it, then you'll want to do this.

{
if (other.classname != "player" && (!(other.flags & FL_MONSTER)||(self.style == 0)))
return;

Then set the style of the triggers you want to be monster usable to 1, and leave the others with style 0. 

Thanks for your comment. Unfortunately, I would really prefer to stick with default Quake progs. Thanks anyway, though. :) 

...finally tracked him down http://www.planetquake.com/gg/fmp/foxy.html 

Is there any such QC I might be able to implement to levitate a monster?

I figured I could take a crucified zombie and have it follow path_corner - but it didn't move. I figured I could place a func_door, plat or train beneath it and it'd push the zombie up -- nope.

My only other option is to make the zombie out of brushes and apply it's texture, then make that a func_whatever - which I'm going to try. 

How active do you need the monster to be? If it's just a matter of having a crucified zombie follow a path/float up and down a bit, that's quite simple. If you want to make a monster that works completely, attacks and dies and stuff, while levitating, that's a much bigger change(you'd probably have to make it a full blown flyer like a scrag is). 

Just a simple levitation - 2 paths for it to rise up and down to "hover" from, and a speed I can set. 

I am having some problem with my map, qbsp.exe crashes with an "Error 40: Portal not bounding leaf" error. What could be causing this? 

I've ever seen that error before. It happens during generation of the prt file.

Please send me the zipped map+wad and I'll see if I can at least add more info to the message. 

Does anyone have a working link to this? The previously mentioned Edgefile link doesn't seem to work (Invalid URL request). 

Try this:-

http://www.xs4all.nl/~renep/quakeme/qme31_p2.zip

The .zip has a patch file to take the Lite version to the retail 3.1 version. I have this and there is no restriction on the number of frames it can handle.

It is now free, not warez. 

I already tried that file, but it didn't seem to work with the Lite version. However, I finally managed to find the full 3.0 via Google's cache of Edgefile. Now I could patch the 3.0 to 3.1 and all seems good. 

Weird, I have removed some complex structures and the error vanished. 

I have a platform that won't be useable until the power is turned on to full. It's actually a func_door, and I have a trigger_once inside the plat cage that will start the plat only when the player is inside it.

I was wondering if theres anyway to, once the power is on (a func_button or something) - it will make that trigger_once valid - but until then, it wouldn't work.

Otherwise I'll just have to make a func_door in front of the plat that will be open once the power is turned on. 

what bsp, light and vis compilers are the beautiful people using nowadays? 

http://user.tninet.se/~xir870k/

Compile utilities from Aguire aka Bengt Jardrup. 

muchas gracias. may your camel never stumble or fall. 

I've been searching around a few editing sites and can't find the answer.

1.) -- How do you switch a texture upon trigger? I have a set of lights that turn off, one by one (player passes through several trigger_once brushes), I'd like the light fixture's texture to switch to the less-bright light texture, once that particular light is switched off.

2.) -- Where/how might you edit the end episode text, or add such a thing to the last of a set of maps?