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?? 

ai.qc goes before enforcer.qc in the progs.src file.
The compiler will look for the void enf_duck1() function when it gets to ai.qc but it's not defined before it gets to enforcer.qc.

Therefore you need to define a void enf_duck1(){...} function prototype (I'm not sure it that's the correct name for it in qc) somewhere before the reference to it in ai.qc. I'm not exactly sure where it would be the proper place to put it, but if you put the text void enf_duck1(); just before the function in ai.qc that calls enf_duck1() function, you should be fine.

Hope this helps!
-love czg 

Thanks. I'll try that.

So, do you think that it would be a good idea to have a dummy .qc file that is made up of all the new functions one is adding to the various other files, and that the dummy file (only a dummy because it has no purpose other than to declare the function names that will be found later) is placed higher up the compile ladder? Or perhaps just list them all automatically at the top of ai.qc.

(I don't really know what I'm talking about here, I am just trying to follow the logic) 

to have a dummy .qc file that is made up of all the new functions one is adding to the various other files...

Or perhaps just list them all automatically at the top of ai.qc.



Both should work just as fine, but the question is which one is the neatest, tidiest and most correct. If that doesn't matter to you though, just pick one at random... 

eenie, meenie, minie, mo... 

Placed the function declaration at the top of ai.qc as I saw there were some there already.

Compiles fine now. Thanks czg.

The function works in-game but because it relies on you shooting the enforcer, when he ducks it looks just like he's been hit, and not that he's ducked your shot. Therefore, it works, but I won't be using it.

But a nice introduction into coding nonetheless and I am now looking for some more things to try. 

Is it possible to change the speed and color of laser projectiles shot by trap_shooter? 

Speed is altered by use of the 'wait' key from within the map editor: 1.0 is the default.

The colour of the laser projectile can by changed by using a program such as qME and painting the laser.mdl, which is found in PAK1.PAK. You can use a program like PakExplorer to unpak the file.

Hope this helps. 

The laser.mdl is in the 'progs' folder in PAK1.PAK.