I would not like to be so "radical" ;) 

Antilights works basically like normal lights with all extra keys. But it can only affect light with the same style, e.g. you can't darken a flickering light with normal light (style 0). Also, you can't use antilight as ambient light, e.g. minlight.

In TyrLite (which I think you use) there are some other possibilities, e.g. you must add the option -nominlimit to make antilight force levels beneath ambient minlight.

Check readmes for more details. 

Thanks for the information, I will try it this evening: I now suppose this option was missing in my light process.. ;) 

/*QUAKED misc_fireball (0 .5 .8) (-8 -8 -8) (8 8 8)

Am I right in thinking that the second and third group in the above are the dimensional off-set from the origin of the entity based on the size of the model and that the bounding-box is therefore 16x16x16?

If not, what are they?
If my assumption is correct, is this how the entities origin is determined i.e. I could redifine the entities origin by altering the parameters to (say) (-8 -8 -12) (8 8 4) to have my origin higher up the model but still within a 16x16x16 bounding-box.

What is the first group relating to?

I have Googled but cannot find a decent definition of this anywhere (14000 entries offered, a couple of dozen checked, and then I thought that I would use my favourite search engine:-) 

These are all just fields to tell the QuakEd editor about the entity.
First group specifies it's color, the two following specifies the minimum and maximum bounds of the entity relative to it's origin.
This is just for the editor though, it won't have any effect on the actual in-game entity.
If you change the bounds, the box in the editor will appear to change, but the origin will still be in the same place. (Unless you move the entity, obviously, to acommodate for the change in the box.) 

Thanks. A couple more questions:

How does the Colour Group work - what are the three values telling the editor?

Also, if the other groups are there to tell the editor about the entity, how/where/why is the origin of an entity determined? I can see that the editor 'knows' the origin and passes this detail to the compile routines via the .map file, but this is only calculated from the *Quaked definition. So, is the origin only determined by the entry in the *Quaked definition and can I therefore change the origin simply by changing that definition?

I haven't a clue why I would want to do that but i am trying to understand the relationships between the editor and .map files, the .bsp file, the progs.dat and the engine. 

if you change the Mins and Maxs in qc, it would affect the collision of the entity against other entities, but not the model positioning (which is always centered on the origin, rather than centered in the bounding box. Back to the collision thing, it will affect its collision against other entities, but the collision against the world will always use one of three hard-coded sizes: zero-sized (0 0 0)(0 0 0), player-sized (-16 -16 --24)(16 16 32), or shambler-sized (-32 -32 -24)(32 32 64). 

Thanks for the explanation.

Is the world collision detection routine run three times, one for each of the hard-coded sizes, or does each entity have one of those fixed sizes 'allocated' to it somehow? (Of course, I don't actually know how collision detection is carried out as the game progresses - is it only after (or perhaps just before) each individual entity movement, or cyclical on every entity all the time or ???)

These questions have come to the fore because I have a model but no *Quaked definition. By trial and error I have created a bounding box and can fit it the map OK but do not know how to decide the origin for the entity: should I just use player-size or shambler-size according to the size of the model or is it a bit more complex than that? It is only a static model at present but if I ever get the hang of animation, it could become a 'monster'.

I notice that the Bounds dimensions shown for standard Quake models in QME 3.1 never match the *Quaked definitions - what am I missing?

Metlslime, do you map or do you just stick to programming?

Mmmm, a lot of questions again. Hopefully there are others who are as novice as I am and will learn from the answers as well. 

I can't answer you're more technical questions, but I can shed some light.

should I just use player-size or shambler-size according to the size of the model or is it a bit more complex than that?

In my earlier reply about the narrow beam, I was not entirely accurate when describing the player bbox. In fact, the player and monsters don't have a bounding box, they're just point entities that collide with the 'expanded into the map' hulls 1 or 2, which creates the illusion that they are in fact boxes.
This mechanism vastly simplifies the amount of information calculated for collision. The ( acceptable ) trade off is slightly longer compile times and larger file size of finished maps.

The other limitation however is that you can only have moving entities ( i.e. players and monsters ) that are the size associated with the collision hulls. In Q1 there are only two sizes: player and shambler. ( HL1 had more collision hulls afaik, allowing for a greater variety of monster sizes )

From my experience working with necros on monster creation, I believe that it's possible to specify the weapon collision box for a monster, which needn't be the same as the architectural hull1/2 box size. In the case of the vermis for example, because it doesn't move from it's location it only has one very wide and very tall box for calculating weapon hits, but no box specified for either hull 1 or 2.

For a regular monster that moves about and will bump into walls and stuff, you got player/knight/scrag size and ogre/fiend/shambler size. That's it.

I notice that the Bounds dimensions shown for standard Quake models in QME 3.1 never match the *Quaked definitions - what am I missing?

The information shown for model entity properties is not for collision, it's simply the maximum and minimum extents that the verts of the model occupy in any given frame and also over the course of all frames throughout its animations.
This is relevant because of the way the Q1 .mdl format saves the location of verts. Unfortunately, it is ( as Kinn helped me to crudely understand ) sort of a case of mdl being, like the Quake color palette, limited to 256. That is to say, the farthest distance apart the verts reach in any single animation frame is used to define the 'grid' into which all the other verts in all the other frames will be fitted. The max/min extents are divided into 256.
So for example, a monster with an insecty proboscis that it can shoot out of its mouth at the player a long way is going to have its front to back 'grid' stretched out because of the distance of the verts in that one animation frame. As a result, the rest of the verts will have to be fitted into the nearest grid locations along that length, giving rise to visible innaccuracies. In-game, this makes the verts wobble about a bit - it's called 'vert dancing' or the 'jello effect' for obvious and rather regrettable reasons.

Generally, the exact numbers are not of interest when modelling in .mdl format. Just try to keep the verts of your monster within a fairly defined space - don't have it reaching out to far in any direction in any frame. The more detailed the model - the finer the grain of the verts you've placed - the more of a problem vert dancing will become.

Metlslime, do you map or do you just stick to programming?

Metl has for some time been one of our community's illustrious professional devs. He used to map for Q1 and Q2. His first map was The Crawling Chaos, a nice bit of stygian horror. His most memorable map for Q1 was Rubicon, for which he also created a competition winning (?) texture set, still used for Q1 maps. One of the best base texture wads evar.
Rumours of Rubicon 2 are not baseless, but apocryphal or at least wildy innacurate.
He is a supremely talented bloke in all areas of game design, though he also suffers from an inexplicable aversion to bees.

HTH 

Yeah i map, but i have a lot less time for it at home now that i do it as a profession. Since my homepage has been taken down temporarily, the only place to see screenshots and stuff is my portfolio, here:

http://www.celephais.net/cv/portfolio.htm

Um and to answer your question, the choice of which of the three sizes to use for world collision (point-size, player-size, shambler-size) is based on the bounding box you specify in quakec. I don't know for sure if it rounds down, rounds up, or picks the closest of the three sizes. 

I'm aware that you can set sounds by putting in a number in the entity's sound field (by turning off SmartEdit in Worldcraft, the name of the actual sound is referred numerically).

I'm basically looking for a list of available sounds and their corresponding numbers -- since I only get about 4 or 5 *named* sounds to choose from (or just 1, for func_train). 

Thanks for all the pointers.

And here's a little story just to make all of those of you who know about these things smile knowingly: I just drifted around my MIP (map in progress) with r_showbboxes on to see what I could see, and came across a bbox where I knew there shouldn't be one. I thought it must be something I accidentaly duplicated and must be hidded in the brushwork.

So, into the editor and sniff around, moving brushes backwards, forwards, up and down, but no, I can't see anything. Back into the game and look again, and it's still there. I line it up in each plane and reference it to the nearest piece of architecture which, because it was a brick wall, enabled me to work out exactly where it should be in the map.

Back into the editor and I still can't see it. I then think that I will need to look in the .map file and look at the bboxes co-ordinates based on my lining it up in-game.

You're already there aren't you? Yes, it's 0,0,0. Oh, ha ha ha; how I laughed. Mmmm.

Still, that was a good way to waste a quarter of an hour whilst waiting to see if the Lions were going to pull a rabbit out of the hat. Fat chance - they didn't. 

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.