Thanks for getting the board online again.

I'm trying to straighten out a few quirks in the Light tool regarding switchable lights. Do you know what's required from the engine to make them work correctly?

Specifically regarding the sharing of the same "style" key both in source and target entities. When there are multiple targets, the current logic is entity order dependant.

I even managed to create severe HOM effects in the engine just by manually inserting a "style" key in a bad place. Same behaviour in FQ and TyrQuake, so I assume this is an old problem. 

I know a fair amount about how it works in the engine. The logic you describe is all handled in QuakeC. Without the source in front of me, i believe the reason only the first entity gets the target is that the lightstyle message that is sent to the client will affect all lightmaps of a certain style. So this avoids redundant messages.

I can't imagine offhand why you would get those HOM effects, though. Please email me the bsp that demonstrates the problem, and i'll see if i can track it down specifically. 

Regarding Qcape - I have the same problem with XP, which is a shame because Qcape sounds good. I wonder if anybody has managed to find a workaround?

However, aguirRe pointed me towards TextPad4 and it has quite a lot going for it e.g. syntax highlighting and compiling directly from the editor.

If anyone's interested I can pass on aguirRe's very helpful e-mail. 

Provided aguirRe doesn't mind? 

Okay, well i did a lot of testing and code diving, and i found out exactly what the bug is, and what is causing it.

The bug occurs any time a clip brush in a bmodel extends past the bounding box of the visible portion of the model in any of the six axial directions (north, south, east, west, up, down.) If this happens, you can pass through the part(s) of the clip brush(es) that extend. The reason for this is that physics code uses the bounding box of the visible model (hull0) for culling -- if the player is outside of that box, quake doesn't bother doing collision calculations (which would use hull1) for it.

I haven't quite decided the best way to fix this in code. I also am not sure if the fix should be engine-side or compiler-side. However, if you are a mapper and encounter this problem, the solution/workaround you should use is to add extra visible brushes to the bmodel to extend the bbox as far in each axial direction as any of the clip brushes extend. 

I'll email you a small map+wad so you can see the HOM effect. This problem isn't very likely to happen, but it's quite an interesting effect. If anyone had showed me that symptom before and asked me why it happened, I doubt I would've found the cause.

Mike: Of course I don't mind, just pass it along to who ever that might find it useful. 

My map likes to crash. At first I thought it happened because of edicts, but it crashes even in deathmatch mode (with no monsters). I'm completely disappointed.

But it still runs fine in Tyr-quake (software), but crashes in glquake, winquake and telejano. At least I tested it only in these four engines.

aguirRe, can I bother you once again and e-mail it to you?

btw my comp has been down for two weeks, I wanted to ask it before, but couldn't 

Sure, just send me the zipped map+wad (no bsps please, I'll rebuild it myself). 

that's the same map, you already have that wad. 

i'm not sure if this is usefull or not, but:

in nesp06, i made a little fading light thing... for that i would manually assign one of the 'style' that are highup which is usually reserved for the light util... then, to change the style, all you do is change the intensity via (in qc):
lightstyle(#of style, " *letter of intensity* ");

the way normal light works is the compiler assigns a "style" to the light then the qc code does:
lightstyle(self.style, " *letter of intensity, so m for on and a for off and swaps between the two when triggered* ");

um... i don't know if that's helpful at all, or even what you were looking for... i'm tired. :P 

the style is global, no matter what lights are targeted, if the style is being changed, all lights with that style are being changed... 

I'll have to check more tomorrow, but first impression is that I think it's entity related. After a normal build (no vis/light) it crashes FQ 0.75 immediately, TyrQuake can handle it but with entity flicker.

After a fast vis it still crashes FQ after a few rooms as you said.

After adding compiler options -solid -noents, FQ seems to be fine even without any vis. Therefore it appears entity related (noents removes all entities except world and players). I'm not so good at tracking down entity problems though.

Metl: FQ crashes at 0x41aac5 (access violation) every time, can you see in the FQ map file where that is? 

what are you trying to accomplish, aguire? i seem to have forgotten... 

necros: he's busy unraveling the secrets of the cosmos. let the man work. 

Therefore it appears entity related

Hmmm that's bad, it seems like it's not simply edicts overload. 

Hello,
I would like to place a invicibily artefact above a well (to force the player to catch it and then falling down into the hole...) but, while testing the map, the artefact seems to "slip" down to the weel ground (gravity effect ???)
Is it possible to preserve the artefact position without this fucking "gravity" effect ??
Thanks 

...there's probably a tute somewhere, but basically:
1. Fill the well with a func_wall
2. Give the func_wall a name
3. Place a trigger_once at the player_start
4. Have the trigger "kill target" the func_wall by name
5. Place the PP on the func_wall

The effect is that the player arrives in the level, causes the trigger to function thus removing the func_wall but leaving the PP floating.

PS: that must be one very big well if the player can't jump over it? 

No, the well is not really big, the basic idea is that if player doesn't take the invicibility artefact, he die into lava at the ouput of the well... sorry for him...
Perhaps placing the artefact lower into the well will be more efficient to avoid "little sly" to take the item without falling down into the well... hmmm I think it will be better like this...
Thanks for the advice...
Bye.. 

sorry for him...

hehe, why am I not convinced =) 

... because you didn't try swimming into lava... it cannot be done without pain... don't you know ?? 

...just a language thing. 

I didn't understood the language subtelty... English is not my native language... sorry... 

Is this the same map you've been working on for a while now? I'm looking forward to see what you come up with. Good Luck 

Yes, that's the same map (my first one...)... I decided to restart from scratch after very interesting discussions and advices with aguirRe. He point up some major problems/errors that causes undetected leaks in the map (like off-frid brushes, unaligned textures, etc.. not reported during compilation...some beginner big scrappy and awfull errors in fact...) These ones were also very difficult to detect if not corrected early... Furthermore, he gave me some good basic advices about how to build a "good" map (with his point of view...), thanks aguirRe ;-)).
As I told him, an external point of view about my work was very usefull, and very encouraging, even he point up my mistakes... What does not kill you, make you stronger... no ???
So I hope now to map in a better way now...
To give you a quick status, I rebuilt 80% of the expected map... I'll post a message when it will be finally released...
Bye 

I'm trying to understand how the switchable lights are supposed to work as they're a collaboration of Light and the engine.

I've noticed several inconsistencies in the logic that sometimes generates confusing results and I'd like to fix this.

While checking many existing bsps, it seems like mappers have had problems with this functionality before.

You also noticed that a qbsp -onlyents run has always disabled the switchable lights and that is also something I'd like to fix.

Btw, did my attempt to fix the problem work for you?