I read its a good idea to scale distant textures as in terrain textures, by 2x - so that there is um... less lightmap... er, whatever. Efficiency.

But is there any drawback to this? I know if you scale DOWN textures it's not a good idea for the engine, if done in large. 

Can someone please explain a bit regarding Q1 model frames? I've noticed that pretty many paks seem to have problems with these; you'll get warnings about no such frame ....

I've tried using QuArK and repair the mdl files by just c'n'p frames, just like I do with missing skins and sometimes it works and sometimes it doesn't. The alleged missing frames are often way higher than the actual # frames in the mdl file.

I've managed to see that there seem to be at least two frame variants; single series frames and frame groups. This can often be seen in the mdl file as either one steady series of frame names (e.g. flame0-6) or several series which I assume are the frame group ones (e.g. fire0-6, firebig0-9).

The requested (and alledgely missing) frame in the engine seems reasonable when dealing with single series frames; then it's just a matter of c'n'p one or more frames to satisfy the request.

But when dealing with frame groups, the requested frame seems to be interpreted by the engine as the frame group and usually they're just a few.

If e.g. there was a request for frame 7 in the above frame group example, the engine will check against the # frame groups (here 2), warn about the missing frame, change it into group 0 and then proceed to render it (I assume the first frame of this group).

Is it possible that the requested frame should, at least when it's missing, instead be calculated from all of the frames in the mdl regardless of group, i.e. use the frame firebig0 as it's the eighth frame (index 7)? Does QC actually know about the frame groups?

And what are the poses, that seem to be some sublevel of frames? 

There are indeed two types of frame, grouped and non grouped. From the point of view of the QC, all of the frames in a framegroup count as one frame. Once this frame is set, the animation is out of the hands of the QC, it just plays at the speed set in the model until the QC sets a different frame.

As to whether the QC knows about the framegroups, the answer is maybe : - ). There are two ways to specify frames in QC. The first and simplest is by index, setting the frame of an entity to 5 will call the frame with index 5. This can be useful for cycling through an animation, by setting frame = frame + 1 at the right rate, for example in player.qc.

The second way is to use the frame names, but this only works some of the time. The QC files doubled up as control files for the model compiling tool ID wrote. If you look at the top of, say, ogre.qc you can see a load of lines about $origin and $base and $frame. All of this was information just for the model compiler, so altering it won't change anything if you recompile the QC files.

The use of it for the QC is the list of framenames. In ogre.qc, if you write self.frame = $stand1, the compiler will look up which index corresponds with $stand1 in the model header section, and replace $stand1 with the correct number. This is largely a readibility thing, but it also has the benefit that you cannot call a frame that does not exist, assuming the model you're using matches the frames in the header. If you tried to call $stand27, you'd get a compiler error.

The difficulty with calling the framenames is that different models often have the same names for frames, and rarely have the same index for that frame. The solution is that the framenames are only valid in the QC file that they are defined in. Since this would require a new QC file for each model you want to do this on, it's only really used for monsters and players. Most of the simple models are all defined together in models.qc, and any animation that they use is done directly with the frame indexes.

Which I'm afraid to say means I'm at a loss on how you'd call a framegroup using the framenames method in QC, as the only models ID made with framegroups are the torches, and they are defined in models.qc but coded for in misc.qc. Maybe I'll have an experiment and get back to you.


I was also under the impression that when you called the frames with numbers, all the numbers acted modulo the maximum frame index, so if the model had 6 frames, frame 6 would call frame 0, #7 called frame 1 again, and so on.

I now remember why I though this was how it worked - because of a server side mod I saw with optional client side models. The mod added lots of weapons to deathmatch, like pressing 4 twice gave you a flamethrower, that kind of thing. The trick was, if the nailgun v_model used frames 0-8, the flamethrower would use 9-17, and the next weapon 18-26. Then the client side models you could download would have a different model showing for those frames on the v_model. If you had the model pack, you'd see a different model for each weapon, but if you connected to the server without the pack you'd just see the nailgun each time, but it would still animate.


Do you have any examples of the paks that are causing these errors? I might be more helpful with a specific example than in general. It's possible that QuArK isn't reading the framegroups right, since it's designed to work with lots of model formats. Qme might be better for fixing those models.

Also, I've never heard of poses, unless it's the same as the base frame, used to generate the two sided planar map for the skin. Can't help you there... 

Hey Metlslime, is that realy the Floyd model in post #3792? Didn't knew it already excisted.

Here some screenies of my last model. Rather a heavy weight: 397 vertices - 1076 triangles.
Hard to find the vertices get messed by transposing them by dxf!
Only marginal textured.

http://members.home.nl/gimli/fitz00.jpg
http://members.home.nl/gimli/fitz01.jpg 

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.