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. 

Originally i had tried to just use straight vertex manipulation. This looked fine in-editor, but everything was hopelessly broken in-game. I then tried cutting my base structures into triangles before doing my vertex manipulation thing, and it ended up looking decent in-game.

Is this the right way to do it, or am i setting myself up for worse problems down the road? 

While time consuming, tris are the way to go. 

Thanks again Preach.

You helped me with a thing I was crunching for years with. So glad I found it yet!
Replacing monsters was a tough job, adding even more.

It helped me with understanding a little more
of the qc scripting, which in my opinion still
has something of pure magic. 

Is there any engine out there yet that lets you view the different hulls or is the "-hull #" option of aguire's qbsp the only option available? 

http://disenchant.net/engine.html
(Only implemented in the GL version) 

I really miss fitzquake/q3 style movment in noclip mode though and I think the hulls would be better displayed as some kind of wireframe or semi-transparent representation. Shouldn't complain though since it is very usefull even as it is.

Now that I've seen the ones I felt and some additiional ones I just have to figure out how to get rid of the evil clipping problems... 

Glad my attempt, adding a monster, succeeded.
http://members.home.nl/gimli/rat02.zip 

Two things:-

1) the trap operates on its own once you have triggered it for the first time - about every 12 seconds. Is this intentional?

2) Huston, we have a dead mouse flying.

http://img296.echo.cx/img296/2507/fitz00003il.jpg

I shot this mouse and he flew up in the air and stayed there?


Other than that, they are good, nuisance monsters like spiders and vorlings. 

While the Quake engine can't collaps objects (in stead of the Custent) I made the trap like a func_train.
My idea was to hurt the rats, but as they have no pain-frames in it, that won't work.
The flying mouse you see, is one that has fallen on the trap itself. It isn't flying.

Took me some time to make them fall on ground the same way, as the h_gib1.mdl frame and the squish-frame in the rat.mdl aren't in the same position.
ThrowHead function make them land lower, reason why they just disapear.

Would like to make them jump and retreat. 

I looked inside GFX.wad and also the GFX folder of the PAK's and can't seem to find the big console graphic. Where be it? I saw one .LMP that might be it, but QPED said it wasn't viewable. 

conback.lmp and used to have a limit of about 64k in size, but some paks use larger and might cause some engines/tools to fail (or even crash) to load it. Carved in Flesh is such a pak.