I have some problems with light textures in my level. The textures look in-game like on the below pictures. They look better after brightening nearly lights, but I don't want too much light there. I have converted this texture with Texmex from ikbaseq3.wad. Maybe I have done it wrong. What do you think?

http://republika.pl/quake_1/light.jpg
http://republika.pl/quake_1/light_1.jpg 

The problem there seems to be that when you converted you used the full quake1 colour palette rather than using a palette which had the fullbright colours taken out.

I haven't used Texmex but have a look if it has a palette with a name suggesting it has no fullbright colours in it.

(In original software quake and later fixed versions of glquake, the last few colours in the Quake palette will always appear at full brightness regardless of the light level) 

If it is a fullbrite issue then you can select the texture, right-click and choose Adjust Brightness, then click Remove Brites.

Don't forget to Save after you have finished adjusting the textures. 

if you make light textures (like a lamp) you actually DO want to have the a single fullbright color patch in the place where the lamp glass is. 

This reminds me... is there any way to turn off the "always-bright" factor of water, so that your lights will light only particular areas of the water? 

I want to have certain monsters 'see' further. I know I can change their range in ai.qc but this then affects all monsters, which I do not want.

Can someone point me in the general direction of the best way to achieve this - ideally by setting a flag on the individual monsters. I may give them a slightly different skin so could use "if skin = 5 then monster can see further" inside the particular monster .qc.

I am not yet clear about the relationship between the monster's own .qc and the ai.qc where the ranging seems to take place.

These particular monsters are to be used as covering fire to pin the player down whilst other closer monsters gang up on him/her. Of course, the better players will survive, and will eventualy get close enough to kill-off the long range slayers. Think of it like snipers shooting from a long way off.

Any suggestions? 

You have a valid point about fullbrights.

But I would note a conundrum about the use of fullbrights:

1. on light textures, fullbrights would spoil a switchable light as it would still be seen even when the light was off

2. many years ago (22Nov1998 to be precice, and some 35 years after the death of JFK, coincidence or what?) I incurred the wrath of Shambler (and him still a teenager) because I had used a fullbright texture on a shootable button. The button was in a dark area of the map but was clearly visible because of the fullbrights being used. Unless, of course, you were using GLQuake (and he was) in which case, fullbrights were not fullbright and therefore became effectively invisible.

So, I guess you pays your money and you takes your choice.

Now, who do you think killed JFK? 

Ankh:

To remove fullbrights from a Q1 texture in TexMex, go to View -> Preferences -> Workspace -> [Color Conversion] and uncheck Use Full Brites. Fullbright texels will be converted to other colors when the image is imported.
The Adjust Brightness -> Remove Brites function doesn't work properly afaik.

Phait:

No

Bambuz:

Not if you want a switchable light style associated with that texture e.g. turning the light off completely.

Mike:

Lee Harvey Oswald 

I have two solutions for you, one of which I have actually tested.

The tested way:
Find the line that reads

r = range (client);

in
float() FindTarget =
and replace it with

if (self.classname == "monster_ogre")
r = longrange (client);
else
r = range (client);

You can use any test in the if statement to decide which function to use. The next thing to do is find the range function and, suprisingly, duplicate it and rename the copy to longrange. You can then change the ranges as you desire. As you probably know from you experiments, the last value is probably the one to change. Altering RANGE_MELEE and RANGE_MID will change how the monster attacks and cause odd stuff, but might be desirable.

This method is good if you only want two classes of monster vision. If you have lots of monsters for the second type of vision, but don't want to have a big, slow if statement in
FindTarget like:

if (self.classname == "monster_ogre"|self.classname == "monster_vore|self.classname == "monster_shambler...)

then add a line saying
self.lip = 1
on all the monsters that have this kind of vision, and check for self.lip in the added code.
(lip is a nice variable to use, as the original quake only uses it for lifts/doors. So you can use it on monsters without having to define a new variable, which wastes memory on every entity in the level)

If you want several monsters all with different vision, and you're sure that you only want to change the maximum viewing distance for each, there is another method. Don't make any of the changes in the first method. Instead, change the line in range from
if (r < 1000)
return RANGE_MID;
to
if (r < (1000 + self.lip))
return RANGE_MID;

Then set self.lip to how much further you want the monster to see, eg: self.lip = 500 would mean the monster sees you at 1500 units,
self.lip = -200 would mean it sees you at only 800 units away, not 1000.
You could have written
if (r < (self.lip))
return RANGE_MID;
Why do it the way I suggest above, and not this way? Because it means that you don't have to change anything for the rest of the monsters, self.lip defaults to 0 so they will default to a range of 1000. Be warned, a mapper could in fact set self.lip on the monsters that don't have a range specified, and it would be obeyed. To avoid this you can force self.lip = 0 in the spawn function of these monsters, but then you're back to lots of work modifying all the monsters.

Finally, note that no matter how negative you make self.lip you'll always have a spotting distance of 500 from RANGE_MID. You could complicate things by having RANGE_MID altered by self.lip in some way too, but this might cause odd behaviour. Since you're going for longer vision this probably doesn't matter, but you might want to consider it. Poke around in the AI.qc and fight.qc files to check what happens at RANGE_NEAR/RANGE_MID. You might find it useful to have these ranges extended somewhat, but probably not. 

I have seen many a QC tutorial with less debt than what you provided. 

Thanks for this explanation - clear and concise. And you are right in that I do not want to affect the current monsters RANGE_NEAR and RANGE_MID settings. It's just the sniper effect that I'm after.


Kell: but what about the grassy knoll and the man seen running away. And what about the mafia who were clearly put-out by what JFK and his brother were doing? And what about the guy in Marseille? And what about Shambler, where was he at the time? 

Mike: heh, I also incurred the wrath in my last speedmap because I did exactly the same thing with a fullbright button in a dark area. :) 

Hey. This helps a lot. Thank you all for such detailed information. 

I use TexMex 3.4 and unchecking Use Full Brites in Options doesn't work. I am not sure if it doesn't work at all or if it misses some conversions. However, doing the right-click thing I mentioned does work.

http://img299.echo.cx/img299/472/quake004ax.jpg
http://img299.echo.cx/img299/88/quake017px.jpg
http://img299.echo.cx/img299/120/quake029lt.jpg

The first image is using Options with Use Full Brites checked. The second is with Use Full Brites unchecked. The third is Use Full Brites unchecked and then right-clicking on the texture and using Adjust Brightness/Remove Brites, which does the best job.

Images 1 and 2 are different, honest. 

Yesterday I have done some tests with ktech_3 and ktech_4 textures from the knave.wad dedicated for quake1. There are always some fulbright pixels you can see in darkness. Don't know if it is intentional. I'm using Hammer,Joequake and aguirRe's tools.
http://republika.pl/quake_1/knavelight1.jpg
http://republika.pl/quake_1/knavelight2.jpg 

This is the same kind of thing as shown in my earlier post.

I have now cleared this particular texture of all fullbrights. You can see in the screenshot below that where the new texture is, the bright red pixels are gone - check the brick pier to the right of the shotgun (old version) and then the layer of bricks closest to the lava on the left of the shotgun(new version):-

http://img105.echo.cx/img105/3186/quake031bz.jpg

I exported the individual texture from TexMex as a .bmp file, opened it in Grafixer, and immediately saved it without doing anything else. Then imported it back into TexMex and saved the .wad file.

I only wanted to get a little bit of colour on the bricks that were next to the lava. The two courses of bricks above the lava are the coloured version (minus fullbrights) and the third course of bricks is the uncoloured version of the same texture - they're from DktE3.wad.

Not too long-winded once you know what to do.
You'll find Grafixer here:-
ftp://ftp.sunet.se/pub/games/PC/idgames2/utils/graphics_edit/misc/

Maybe someone knows any easier way? 

Would you be so kind to look at my rat.qc and see why I can't lay a path_corner on them?
The download has the qc.script I tried sofar.
Could it be because it is an Add-on monster?

I've been looking all day, but I can't find the reason.
I finally got them ingame, but I can't see them jump, although I declared the options.
Also the damage impackt is far too high. 

Yeah, sure, either e-mail it to me or post a link here and I'll have a poke around. 

Just found a problem with Grafixer in that it only handles textures up to 320 x 200. Shame. 

I have a sense of deja-vu here so if this is repeating myself, sorry.

TexMex has a problem removing colour 255. So, if after doing the above routine you still have a single fullbright (fuscia) you will need something like Photoshop to highlight the offending pixel and change it to another non-fullbright colour.

It is straightforward although long-winded but I don't know how else to do it. 

You can use QME(yeah, the modelling program) to eliminate fullbrights at a pinch. Dunno if I'd want to do it on a large batch of textures though. Load up any model and change the skin size to the size of the texture. Import the texture, and go to view -> skin palette map editor. Then uncheck the last two rows of colours, and click ok. Finally, export the skin again, and it's done.

You can also use this to exclude other colour ranges, if the conversion uses a row of colours that look odd, like the grey/greens on a grey patch. It's also very handy if you're making a quake player model, since you can fix the shirt/pants colours easily with it. But yeah, fullbrights is the most useful thing it'll do. 

I posted a link above with the download zip.
It has a map, Qc, Sound and progs.
You even could game with it by what I sofar gained. Some functions won't work, like the bite distance is to far, as the damage is.

But when I try to put on a path_corner on it the game ceased as I mentioned in post 3713.
Maybe because it is not a monster replacement, but an add-on.

Here is the link once more:

http://members.home.nl/gimli/rat01.zip 

The fix is pretty simple, the explanation a bit more involved. What you want to do is find the following code:

void() rat_run1 =[ $run1, rat_run2 ] {
if (random() < 0.2)
sound (self, CHAN_VOICE, "rat/eep1.wav", 1, ATTN_IDLE); ai_run(8);};
void() rat_run2 =[ $run2, rat_run3 ] {ai_run(8);};

and edit it to this:


void() rat_run1 =[ $run1, rat_run2 ] {
if (random() < 0.2)
sound (self, CHAN_VOICE, "rat/eep1.wav", 1, ATTN_IDLE); ai_walk(8);};
void() rat_run2 =[ $run2, rat_run3 ] {ai_walk(8);};

Why? Well, although these functions are called rat_run1 and rat_run2, they are actually the WALKING frames for the rat. You can see this by looking at
self.th_walk = rat_run1;
in the definition of monster_rat. And why does it matter? Well, ai_run assumes that the monster has a target, and so you get problems when that isn't the case. ai_walk is built for just one thing, and that's following path_corners.

A few other things that you might wanna look at which I noticed while testing. One is the hitbox you use. It's narrower than it is long, which would be a good fit for the model, except that hitboxes in quake don't rotate with the model. So it's always facing the same way, which makes it harder or easier to kill the rat depending on which direction you attack it from. It's hard to explain, but easy to see, get the latest fitzquake and set r_showboxes to 1, and then look at some rats with god or notarget, especially ones who are patrolling. The fix would be to set the size to something like

setsize (self, '-8 -8 -8', '8 8 16');

A further thing, the gibbing death you have in there is bugged. If you do enough damage to gib the rat, the gib gets thrown, but the rat doesn't get removed. So you get an invulnerable rat that continues attacking. Use ThrowHead instead of ThrowGib - ThrowGib creates a new entity for the gib, ThrowHead turns the monster into the gib. Or you might wanna just remove gibbing, it'd probably look better.

Finally, when your models are dying normally, not gibbed, they remain solid. Usually it's best to have make them non solid, change the last death frame to do that.

I wrote the above two paragraphs, then decided to try and test it. Looking more carefully, the whole death sequence is quite buggy. You have a loop where rat_die calls rat_die1, which calls rat_die again. This is why you get that repeated clicking sound from all the dead bodies. Rather than detail all the little fixes, here's what it should look like

void() rat_die1 =[ $squish1, rat_die1 ] {self.solid = SOLID_NOT;};

void() rat_die2 =[ $squishb1, rat_die2 ] {self.solid = SOLID_NOT;};

void() rat_die =
{
// check for gib
if (self.health < -15)
{
sound (self, CHAN_VOICE, "rat/squish.wav", 1, ATTN_NORM);
ThrowHead ("progs/h_gib1.mdl", self.health);
return;
}

//regular death
sound (self, CHAN_VOICE, "rat/squish.wav", 1, ATTN_NORM);
if (random() > 0.5)
rat_die2 ();
else
rat_die1 ();
};


Notice which functions are calling which other functions, rat_die calls one of the two frames, rat_die1 or rat_die2. The frames do not call rat_die again, they call themselves, because the monster no longer needs to animate - it's dead.


One tip for people in general, with a word of warning. If you want to test a new monster quickly without having to create a new level, you can cheat and have it replace an existing monster in all levels. To replace grunts with rats, comment out all the code in monster_army(), and add

self.classname = "monster_rat";
monster_rat();

after the comment. The classname is very important, as if you don't do that the rats will be going around with monster_army as their classname. Some of the quake monsters have hacks in the AI based on their classname(knights are a good example of this), and so you might get odd behaviour that wouldn't occur with a custom map with rats in. It took me months to figure where that bug came from first time I met it... 

Thank you very much, Preach for your brilliant explanation of the qc periphericals!
I was looking to it so long now it realy became acracadabra to me.

I had changed something in the RatJumpTouch and then all my rats became earthbound, before they squished to the wall. Some of them kept flying at the skybrush.
It gave me the idea to make bats of them.

Now they're ok, and I can use them with a path_corner. I am very thankfull to you.

Last bugging question of me. How do I cange their damage. I changed ai_charge in the void rat_bite , but it doesn't change a thing. 

The lines that do damage are

ldmg = (random() + random() + random()) * 8;
T_Damage (self.enemy, self, self, ldmg);
in rat_bite and much less frequently

ldmg = 10 + 10*random();
T_Damage (other, self, self, ldmg);

in Rat_JumpTouch. Since random produces a number between 0 and 1, the first expression can produce anything from 0 to 24 damage, but is much more likely to lie close to the centre, about 12 damage. The second is uniformly distributed between 10 and 20 damage. Reducing the numbers here is probably wise. You might also want to reduce the attack range, which is set at 100 in rat_bite in:

if (vlen(delta) > 100)

Because this range is measured between the origin of the player and the rat, you can make it smaller than, say, the same range for a knight, as the rat can get closer to the player with it'ssmaller bounding box. 70/80 would probably be good.