. 

http://kinn.spawnpoint.org/SA/what3.gif 

I managed ten. There's no way you can do it in less than nine without noclipping. 

I have a .qc file called ogre.qc where he fires only grenades. I have another one called ogre.qc where he fires only nails. (Where I use a single gender term, I of course relate to both genders.)

If I rename one ogre1.qc and compile them both into progs.dat, is that enough to identify and use two different ogres in the game without changing anything else in the .qc file. I do not want them to have different skins - I want the player to see two ogres one of whom fires nails and the other grenades. I do not want the player to see this until it happens. I assume I will need to name them monster_ogre and monster_ogre1 in the map file.

I do not know anything about QuakeC except how to decompile and complile.

Your assistance will be appreciated muchly. 

Also, can someone explain in easy to understand bullet points, what the pros and cons are for using models instead of brushwork.

I have a statue of Anubis made up of 450 brushes. If this was a model instead of brushwork, how would playability be affected.

My start point for this question is the tree in Marcher Fortress: why a model, why not brushwork?

Don't forget now, not too technical: play with me here, not against me:-) 

I'll start with your second question first...

In Quake, complex brushwork is very expensive in compiling terms, for various reasons. Quake has no support for detail brushes, so every bit of world geometry is is chopped up and merged with the rest of the world, and put through the same vis calculations (which can grow exponentially when you have lots of fine detail in large outdoor-type areas).

There are situations where turning brushwork into a func_wall can be useful. Basically, because the brushmodel is now an entity, it will not split up adjoining world geometry, nor will it affect vis. However, if a brushmodel gets too large, it can become a problem, especially if it straddles visportals. Also, brushmodels are rendered less efficiently than world geometry, so you will see an increase in polycount. I generally steer clear of this method, although I use it in a few instance in Marcher, such as for the torches in the upper cavern, where they butt straight into the terrain brushes.

.mdl models, like my tree in Marcher are most definately your best bet when it comes to those kinds of mapmodels - mainly for the fact that it would be very difficult to create that structure using brushwork, compared to how relatively easy it is to model it in a 3d app. 

Regarding your QC question:

Well, if that really is the only distinction between the two ogre qc files, then the compiler will abort if it finds any redefinition of the same function (i.e. two functions sharing the same name). If you want a quick and dirty method to rectify this, just change all the function names in your second ogre qc file so that they are unique.

A better solution would be to let your second ogre call most of the same functions as the original ogre, but with a few changes to implement the nail-firing attack, although you may find this tricky if you're completely new to QC.

Note that the entity classname you place in the editor is the name of the function called in the QC that spawns the monster into the level. Scroll down to where it says: void() monster_ogre = to get a feel for this. 

Your method won't quite work, if you attempt it, you'll get lots of errors about functions being redeclared. This is because although the functions are in different files, they will still have the same names, and this is a problem.

The solution is to rename all the functions in one of the files, replacings ogre by ogre1(if that's the naming convention you want). Probably the best bet is to just do a find and replace on the string, and then just correct a few things like the setmodel command - as I expect you want the two ogres to both use ogre.mdl. No doubt somebody will point out the gameplay problem with that in due course...

Then compile and with luck yo should be fine. One thing to note is that the name of the QC file doesn't determine what entity name you need to put in your map. You could call the second file banana.QC if you liked. The thing that determines the name of what you add to the map is the name of the function right at the very bottom of the file. If you've done all the renaming I told you, this will now be called void() monster_ogre1
This is the spawn function. Whenever quake loads an entity in a map, it looks for a function with the corresponding name in the QC. This function sets up the entity, gives it the correct model and behavior.
If you renamed this function to monster_ogre_nail, you'd have to add a monster_ogre_nail to your map.

(A kinda unnecessary aside here, read only if you're quite confident with QC and understood all the ideas above. Creating all these new ogre1 functions is actually quite inefficient! Most of the time, for walking and pain and so on, both ogres will use exactly the same code, just renamed. If you were careful, you could make it so that for all the functions which they do the same, like walking, pain, death, they in fact called the same function(ogre_pain for example), and only had different sets of functions for the firing sequences. You'd then just make two copies of the monster_ogre function, rename one to monster_ogre1, and set the appropriate line:
(for example)

self.th_missile = ogre1_nail1;

You could, of course, go in totally the opposite direction and decide that, given all these extra functions, you'll make use of them and completely rewrite the AI for the nail ogre, make it more agressive or something. But it's probably not worth it unless the nail attack lends itself to it rather well.

If none of that made sense or sounds rather daunting, then just rename the functions like I said and all is good)

Well, the aside is longer than the real post, but the idea of making lots of types of monsters simply by changing a few functions in the spawn function has grown on me while I wrote it. For example, to make a beserker monster variant that never goes into pain, simply set

self.th_pain = SUB_Null;

The mind boggles(or shrinks in horror!) 

Beaten, but I typed more! 

In addition to Kinn's comments, there are some other differences between polymodel and brushmodel.

The most obvious one is the 2D image applied across the surface. For brushes, that would be a map's ordinary textures, which are projected along the major grid axes. For polys, it would be a skin, projected front and back onto the model when you sculpt and arrange it in the editor ( qME ). You can specify almost any size for a .mdl's skin and have more control over what's shown ( detail, form etc. ). However, the skin has to be loaded along with the rest of a map's assets and all of it will be rendered whenever the model is in view. It's unlikely you'll have any problem with the size though - it's actually making the skin that will take a bit of effort.

The other obvious thing will be lighting: apart from DarkPlaces, Quake engines light models more simply than world architecture. A value of lightness is read from the point on the first surface directly below the model's origin ( i.e. the floor ) which is then applied across all its polys. A rudimentary shading effect is achieved by making one half of the model brighter than the other, but this is done without regard to the direction of any incoming map lights and is applied regardless of the direction the model is facing.
This means that a pmodel will always stand out as different from its surrounding architecture and is why mapobjects, such as trees and statues, are uncommon in Quake.

To address the question of framerate: unless you make Anubis high polycount ( over 600 say ) and/or you intend to place many statues in a wide open area, it will be far simpler.
For a comparison, Chthon is 555 polys, the highest polycount of the original id monsters. Even for Quake's original specs, id had no worries placing him in a combat area with, to be frank, no visblocking whatsoever. These days, I'm sure you could place a half-dozen Chthons in a giant boxmap and FitzQuake wouldn't even blink.

As long as you're up to the craftsmanship, a .mdl is definately your best bet. 

hi, has anyone got the dulight (q1rad & tyrlight) mentioned in this thread? Ive been looking for it for ages with no success :( 

would you like ? 

to add a fraction to the wisdom above, and so you don't learn the hard way like I did, mesh models are rendered with a bounding box; instead of the collision being detected per poly surface as the case is (ideally) with brushes.

You probably already know this but if you are as stuborn as I am about these things, you will be tempted to create something like an arched door way as a mesh model and place it up against a rectangular portal. If the mesh model is purely decorative and the player can't touch it, fine, but anything involving collision will look weird, though .mdl floors make for interesting skating rings. 

Yes, email to gona-ss1@lycos.com please!

Thank u very much! I wuv you! 

That all sounds attainable even for a novice like me. If time is on my side, I'll be back with more questions later.

I'll work on the monster thing first, models second. The Anubis model is for a Karnak-like area so there will be several statues, in bright sunlight and they will be against walls, not in the open.

How would you, as players and not mappers, react to not knowing what a common monster (say, the ogre) was going to throw at you until he started doing it.

Also, that one ogre would take more damage than another, or that one would be more evasive than another?

I suppose I am asking should all 'different' monsters be skinned differently. I think not knowing until you are fighting them could add a more interesting aspect to the map (given that the map itself and other gameplay is of acceptable standard) 

 

I suppose I am asking should all 'different' monsters be skinned differently

I would say most certainly yes. I would imagine it quite frustrating having to wait for the monster to attack first before it can be identified. Knowing in advance what you're up against is cool because it gives you that vital split second to plan your combat strategy before the monster starts attacking - I think that's an important part of Quake (and shooters in general) and it would be unwise to change that. 

Not that I am disagreeing with you, but I do find that when I play a map these days I know that the ogre is going to fire grenades at me and that I can jump over them or side-step them, and I need nine shots with the single barrel shotgun. So there is no challenge.

But what do I do if when I side-step, he does the same? And what do I do if after nine shots he doesn't die? Now I have to think a bit and take stock and learn again.

If they have different skins then I have advance warning that something is different. Just a thought. 

trust me. don't do that. if you have new monsters, give them new skins.

it's not relearning, it's just annoying since you have no way of knowing what kind of monster you're going to fight. imagine playing quake again, with every monster looking like an ogre. it's an extreme case, but it helps to get the idea.

if you were to change the ogre itself, ie: make it shoot both grenades and nails, that's different. players will learn that they can expect different behaviour from ogres at the start, but doesn't attempt to 'hide' when those differences are going to surface.

also, sidestepping monsters that don't fly or swim look stupid, unless you were to animate some new frames for them. 

I thought that some ogres firing nails and some chucking grenades would make a change.

I haven't seen the effect of monsters taking more evasive action but I read that it could be done. Also that you can make them run away when they got low on health, which would mean you had to chase them to finish them off if you wanted 100%.

I wasn't thinking of a new game, just some 'changes' to the existing format. I actually do not want totally new monsters as it would not be the same game anymore.

Just thinking out loud. 

I'm working on an inside/outside transition area
in a Q1sp and I was wondering if anyone knows
of a tutorial that adresses Facades and/or
outdoor areas.

Suggestions of maps to look at as examples
would be a help as well.


(wow we have a preview button :) 

I need some help again, please.

I am still playing with the code stuff and have been trying out some monster amendments. I am trying to get my monsters to duck when being fired on and have found a tutorial at AI Cafe. But when I try adding the code to the .qc files, compile fails. I can comment out various lines so can see which 'seem' to be causing the problem.

Can one of you coding gurus spot a problem here:

void() enf_duck1 =[ $paind4, enf_duck2 ] { ai_face(); self.solid = SOLID_NOT; };
void() enf_duck2 =[ $paind5, enf_duck3 ] {};
void() enf_duck3 =[ $paind6, enf_duck4 ] {};
void() enf_duck4 =[ $paind7, enf_duck5 ] {};
void() enf_duck5 =[ $paind7, enf_duck6 ] {};
void() enf_duck6 =[ $paind7, enf_duck7 ] {};
void() enf_duck7 =[ $paind7, enf_duck8 ] {};
void() enf_duck8 =[ $paind7, enf_duck9 ] {};
void() enf_duck9 =[ $paind7, enf_duck10 ] {};
void() enf_duck10 =[ $paind7, enf_run1 ] { self.solid = SOLID_SLIDEBOX; };


The above is in the enforcer.qc and then below goes in the ai.qc

if (self.classname == "monster_enforcer" && time < self.enemy.attack_finished && random() < 0.25)
{
enf_duck1();
return;
}

and the above goes immeditely after the line:

enemy_yaw = vectoyaw(self.enemy.origin - self.origin);

Unfortunately the formatting is not quite right here but is OK in the .qc files.


Oh, I have written to the code's author but not had a reply so far. I have used other code sections from this site and everything else worked OK.

Any help you can give will be appreciated. 

i'd stay away from ducking...
in order for it to work, you'll need to change the bbox size during gameplay. i've noticed some very wierd and annoying things happen when doing this, most specifically, monsters become able to walk through walls.

also, don't forget, you'll need to actually animate some frames for the model to duck.

and you'll probably get a lot more help concerning qc things on the inside3d forums:
http://forums.inside3d.com/
most of the dudes here are mappers. :) 

just read the code over again for the enforcer ducking frames,
you actually set the monster to nonsolid there, which, in terms of not fuxoring the bbox is good since you don't change the size, but you do realise this will cause the monster to become unshootable for what looks to be about 1 second...
if you do decide to go with the bbox idea, and not the nonsolid one (which imo is kind of lame) don't forget to reset the bbox size in the pain frame.

the bbox size setting is : setsize (e, mins maxs)
e is the entity to modify and mins and maxs are vectors coming from the origin of the entity.

finally, if you don't go with the bbox idea and stay with switching the self.solid states, don't forget to test to see if the monster is in something else before becoming solid again.

with the way it is, if the monster ducks, and you walk into it, it will become solid while you are standing inside it, and you'll get stuck until you kill the monster.
check out the zombie.qc for code on how to check if it's ok to get solid again (it has to do with when they fall. every 3 seconds, they check to see if they can become solid, and if so, stand up) 

Thanks, but I need to explain that the code is not mine so if there is anything good in there, I had nothing to do with it.

The monster has to unshootable 'cause when he ducks, you missed him :-)

I now know that the line -

{
enf_duck1();
return;
}

is causing the problem as it gives an error in Frikqcc : Unknown value "enf_duck1"

Anyone??