You might already know this, add the " // "into monster.qc as shown below. You'll still have a duplicate line (not commented out) near the end in monster.qc



void() swimmonster_start_go =
{
if (deathmatch)
{
remove(self);
return;
}

self.takedamage = DAMAGE_AIM;
// total_monsters = total_monsters + 1; 

Is there a way to turn off the face shading that Hammer does in the 3D viewport? It's OK in most cases but it's kinda dark in a few directions. I don't see anything in the options screen... 

So, "no" I guess. "setgamma" ahoy! 

Do any of you Worldcraft/Hammer guys have any insight into this problem?

I find that tweaking entities is a maddening experience because I have to fight with Hammer to get it to write out changes to entity key/values. It just flat out doesn't do it half the time. I've taken to opening the MAP file in a text editor and verifying that the value I edited has written out correctly before bothering to compile.

I can't find the pattern. If I knew that a specific series of clicks would make it work reliably that would be one thing but I'm coming up empty.

Has anyone else experienced this? For example, I'm tweaking the "height" value for a func_plat and it seems to write my changes out randomly - sometimes will, sometimes won't.

Help? 

..very occasionally with WC1.6. always thought it would have been so much nicer to have an 'ok' button when entering entity values, as sometimes like you say it just doesn't properly read it.

that said, it wasn't as common a problem as what you are enduring by the sounds of it.. and i think it only ever happened when multiple entities were being updated at once. i found after a while that just clicking off and back on to an entity would confirm if it had been read properly 

shut the fuck up,........ 

spy

I didn't send you email again. Did you not receive it still? 

calm down ladies... so much stress?

what about when u guys will have ti kids+wife+work?

suicide? 

Take anti-aggression advice from Trinca. 

 

Where should someone put their Quake textures in Gtkradiant 1.5 if they wanted to make quake maps? 

 

I have textures here: F:\quake\id1\textures\ik2k
and here:F:\Program Files\GtkRadiant 1.5.0\q1.game\id1\ik2k

Still, I see no textures. 

Texture .wad files go in id1. I don't know where individual images go, or if that even works.

quake/id1/texture.wad 

i remember not too long ago, someone explained how models are lit in-game depending on their position & what not. can't remember the exact discussion!

i'm having some problems with crucified zombies.. here are two of them facing opposite directions at each end of the hall, same lighting:

http://isoterra.co.uk/quake/e2m6rq/zombie1.jpg
http://isoterra.co.uk/quake/e2m6rq/zombie2.jpg

one is barely visible, the other is far too bright (facing west & east respectively)

facing north & south they seem fine, again with similar surrounding light levels:

http://isoterra.co.uk/quake/e2m6rq/zombie3.jpg

how does it work again? is there a fix? :d 

Yeah I had this idea that the textures had to be unpacked as individual image files before gtkradiant would see them. 

is that fitzquake? Do you have the same problem in any other engines? (meaning, is fitzquake behaving differently?)

I've begun to suspect there is a problem with the way fitzquake interpolates light values, which results in stationary models getting lighting that may be different from the standard quake clients. 

yeah it is. the quakespasm sdl port. i'll try it with glquakebjp when i get home 

metlslime join this in to do list ;)and don't forget .jpg screenshot suport 

so it's not fitzquake. same problem on the aforementioned :/ 

What happens if you move the zombie slightly, or if you delete and reinsert (c/p) the brushes beneath him? 

Is the origin of the zombie directly above a single brush? Or is it above the edge between two brushes? Might be that it's randomly choosing one of the two brushes. 

check the angles on the lights again ;) 

origin is directly above the edge of the little wizmet brush

tried moving the zombies slightly. bizarrely, moving the east-facing one (the bright one) 2 units back into the wall fixed it; it now lights the same as the ones in shot 3. at the other end however, moving it 2 units into the wall makes no difference and moving it 2 units out makes it fullbright. no joy re-adding the brushes either.. 

The code says 12 units into the wall for a horizontal/verical wall. On a 1:1 diagonal wall, this should be reduced to 8 units.

Assuming that doesn't help, I have no idea...