I had deleted the teleporter-brush without deleting the func_teleport. Reason the map became waxed.
Sorry for my short sighted mapping value. 

... "c'est le metier qui rentre".... :) 

New feature added to my code which supports
day\nite cycle in quakeworld but i noticed
not all spots get lit. All the outside edges will not light up. Its a big map because
it supports helocopters. Any ideas? 

lightstyles with quakec? Some engine hack? 

I hope day/night cycles are not 24 hours !! I've never found somebody who played Quake for 24 hours consecutively... or this guy was a real fool Quake-maniac player 8p 

Its in the C code(mod) and not engine but I do
work with the QW engine too.

No, not base on 24hr clock...hehe. its configurable but like to have it cycle 2 or 3 times in 35 min map time limit.

Starting looking at the light code and suspect a bug or limitation but need to confirm one more thing with my code first 

we can't help you without more information. 

I have a key door that I want to trigger multiple events. It triggers its own door, some other doors, some monster spawns and a 'trigger_once'. This last item has a delay set before it then triggers more doors - only it doesn't trigger them. All 'target' and 'targetname' entries are correct. The direction on the doors is set. I have tried trigger_once and trigger_multiple, also to no avail.

I want to use the delay as I do not want too much going on at one time: there are 12 other doors and several monsters involved, all within close proximity.

Is it me, or the wrong trigger, or what? Anyone tried something similar before? 

Tried setting the "Entity only" spawnflag (1)?
You may also try using the trigger_relay entity, which is a point entity. Use it exactly as trigger_multiple, except it hasn't got a brush. 

also note, if your trigger has a "killtarget", it will fail to fire it's regular "target". I consider this a bug in SUB_UseTargets, where the function exits too early if it has a killtarget set. 

that trigger_relays don't work quite rightly in certain custom engines. Try playing the start level to the classic Tale of Abbot's Rune with Dark Places and you will see a royal fuck up. 

czg: tried Entity Only, still no go. I am not clear on setting an entity without a brush?

Kinn: I didn't use KillTarget.

HeadThump: I am using Fitzquake. I am up to 430 entities with only 87 monsters (I have about 20 yet to be placed) 

I'd go with czg's advice and try replacing your faulty trigger_once with a trigger_relay - the trigger_relay is designed to obsolete the trigger_once in that situation anyway. 

also note, if your trigger has a "killtarget", it will fail to fire it's regular "target". I consider this a bug in SUB_UseTargets, where the function exits too early if it has a killtarget set.
jesus christ, how did i not know this? this caused me a lot of grief doing the end of pbrsp1. oh well :) 

My doors were touching and I had not set the the door_dont_link flag.

The doors in question were originally solid brushes that I converted to doors for effects. However, the second doors (via the trigger_relay) did not move with the first doors. Had they have done so, I would probably have twigged it straight away.

This lack of movement is not really a bug: first door is triggered, second door does not move because although it is touching, it has a different 'targetname'. Then the trigger_relay kicks-in but the engine gets confused because the doors were touching. Well, maybe.

Anyway, all now OK so not far from finishing the map. ('bout bloody time) 

Hello all,

I have a little problem during QBSP process. I use in my map some arches which are rotated of 45 degrees, and it generates me a lot of CutNodePortals_r warnings, even if I forced brush to grid (dot corner by dot corner), and as well for textures alignment.. So, what is the good method to avoid this kind of problems ??

All good ideas and advices are welcomed.. thanx

PS: I'm using QuArK6.4 editor and aguirRe's TxQBSP tool..;) 

but rotation of full objects can be tricky. Did you make the gridsnapping (for each vertex) before or after the rotation? In which hull(s) do you get the warnings?

If you can't sort it out and you're not having obvious problems in the area (clipping errors, HOMs, bad shadows etc), you might ignore the warnings. Make a full build to verify these things.

If you wish, you can send me the zipped map+wad and I'll take a look at it. 

I made the gridsnapping and texture re-alignement after the rotation... And if I remember well, the warnings occured in hull 0...
These arches are added just to break some uniform huge grey areas... and I can easily find a turnaround without any additional arches use... it is just an "aesthetic" add...
anyway, I just would like to know if there is a method to avoid these fu****g warnings that pollute my log file...

Thanx... 

you can say FUCKING here. we're not that easily offended :D 

...I know you've said ...[t]hese arches are added just to break some uniform huge grey areas... but it's probably best to keep angular irregularity quarantined from other spaces in the level, so smaller vestibules rather than huge grey areas. Mind you, nowadays at least, you might just as easily say "fuck the CutNodePortals_r warnings" as long as r_speeds are within limits. 

... it's rather a design aesthetic issue than an real QBSP compilation problem... I have a huge places where all walls and ceiling are grey (like reinforce concrete bunker walls...), and I just would like to break this uniformity....
Anyway... I have a little idea to avoid this kind of FUCKING "troubleshootings"...
(I said it, yesssss.... ) 

...will set you free! Occasionally... for a while... perhaps... then comes the vacuum... and the need... then the drugs... etc. 

i personally wouldn't rotate anything that had multiple brushes that had to line up. I'd build it from scratch at the angle i wanted it. 

Rotating doors consisting of multiple brushes 90 degrees has never caused me any issues.