...I've spike shooters firing at all sorts of angles in qte2m2? I'll check tonight, but I pretty sure all I did was add an "angles" field to the shooters then plug in pitch and yaw. 

so you're thinking like, sneak into the storage shed, unscrew a light bulb so that someone from across the couryard notices it and comes over to investigate, kill him, but then hide the body so that nobody notices it and sounds the alarm, then throw a pine cone over behind the trucks so that they guards hear it and go investigate, leaving the front gate unguared when approaching from the west, then sneak up and garrote the other guard, then take his keycard and use it to recode the security locks... 

All is fine. I have a prt file.

I fixed two leaks in e1m2. One was two parts of a slanted roof not lining up, the other involved some seriously twisted brushes (like, really deformed.)

qbsp had silently (grrr) produced point files, which contained leaks that quest didn't see. 

yeah except the player would have a sneaking suit.


and a box.

or a few boxes. 

...adding the "angles" field with value "pitch, yaw, roll" to the shooter was how I got them to fire at angles. 

That sounds way easier. thanks distrans :-) 

I'm still missing the fishcount correction for my progs.dat of the proxsys mod.
Where can I find a good fish.qc ? Or was it qstats?

Also still searching for the angle error of the newboss. 

it's a one-line fix. Just look at the swimmonster_start and swimmonster_start_go and related fish functions; you should notice that there's two copies of the line that increments the monster count, and you just delete one of those copies.

(this is from memory so the details may be wrong, but I know that if you look at the source, it becomes ovbvious.) 

but I'm a madcap when it's concerning qc.
even changing a line and correct it makes the compiler peak to errors.
I'm using fricdos, others won't even compile.

and I see two times swimmonsters_start but I can't delay them. If I delete the first one the fishcount still is double. 

Hopefully an obvious one.
I was sitting around with some free time today so I decided to try and make a little speedmap. However I've encountered a frustrating problem along the way...

I have three doors, all with different names. They all go down. They are all within a close proximity to eachother. I have a trigger_counter that causes one set of doors to go down. When this happens the other two doors that do not yet have triggers also go down. Any ideas as to why?
I tried copying and pasting, then changing the name of one door. No doors moved at all, even when triggered... Can someone help with this?
Thanks 

if the doors' bounding boxes overlap or touch, they might be automatically linked by the func_door logic. To prevent this, you can use the spawnflag "DONT_LINK" or whatever it's called on each door. 

does the same logic affect func_trains? 

i don't think so. 

How do I open a Keydoor at the moment I'm in front of it? So not when I find the key somewhere else and return to an open keydoor. 

set a spawnflag on the door (8 or 16 I think, one is for silver and the other is for gold) 

In Hammer/Worldcraft there is a "Gold key required" tick box in the properties field of a door entity. This way you can change the proper spawnflag. If your editor doesn't have such simple "feature" you should really change it :) 

I am using Quark65, and when I set a door to a key it changes the spawnflag to 8 or 16. If I return to the keydoor it is already opened. 

maybe you have added some wrong spawnflags to the key? 

You don't need to set a 'target' on the Gold Key or a 'targetname' on the door as you would for a button operated door.

I don't know if this helps? 

For further details about flags, etc... please take a look at Quake Map Specs link below

http://www.gamers.org/dEngine/quake/QDP/qmapspec.html

Enjoy ! 

You would find also precious information about Quake C here


http://www.gamers.org/dEngine/quake/spec/quake-spec34/index0.htm


Enjoy ! 

For Quake C try this one... sorry...

http://www.gamers.org/dEngine/quake/spec/quake-spec34/index1.htm 

It was rather simple. I always used a targetname to a keydoor.
Then they open straight away.
Without target/targetnames they open at the trashold. Me donkey.

Thanks for your reply.
Another strange thing. Can changing texture (so not polys) influid the lightmap texture?
I mean just correcting a few margins, not scaling.
My map crashed on allocblok=full after I tried to retexture it.
The original map compiled fine. 

Switching textures should not affect lightmap size, but rotating a texture on a polygon might increase lightmap size just like scaling does. 

what metl said, but I'd guess that since you typically change the texture in the editor, it's very likely that minor brush variations occur, leading to a slightly different lightmaps requirement.

Since you're using QuArK with its float coordinates, this is probably even more likely. As you're also flush to the lightmap limit to begin with, even small changes might put you over the edge.