I suggested the cap variant as I noticed that your new attenuation will completely change lighting in a map, which will make it very hard for others to try it out.

It might also be a reason why some found the lighting in your map washed out, this might be a result of the high attenuation scheme. With the capped variant, you still have the normal light distribution of a delay 2 light, but the halo is greatly reduced.

I understand that my delay 5 suggestion is a problem if you can't automate the replace process in or off the map editor. In QuArK (which I'm using), such replacing can be very quick and simple. Please check if there's such a way in Hammer, you might use it for other stuff later.

Another way is to just use a normal text editor and change the map file but I'm unsure if you can import it back into the rmf format. Maybe you or another Hammer user know?

I'm just trying to make new tool features as generic and flexible as possible and also make them fit together. Adding a delay 5 for your attenuation mode seems like the structured way of doing it. But since you're probably the first (and possibly the only) one to make use of it, it feels important that it's reasonably simple for you.

There's also the time frame issue, I'm just about to release a new version of Light and it's a bit late for changes. How far off is your release?

Finally, I'd like the zipped map+wad and your modified TyrLite.exe to test the new light feature, since there are no existing maps prepared for it. Is that possible? 

aguirRe, don't worry about the timing - i won't be releasing for at least a few weeks yet. sending you the whole map might be a bit tricky at the moment, as i'm only on dialup - but i'll put together a small test map when i've got a moment. i'll keep you informed :)

as for the "washed out" look - well, i'm convinced that is an outdoor lighting issue - coupled with the contrast adjustments i did to the screenshots. if anything, my method should result in a darker map than normal tyrlite would produce, because my method removes the halo entirely.

i've checked and hammer allows automatic replacing, so feel free to use delay 5 :) 

I'm also on dialup so keeping the size down is always good. However, it's usually not the map file that's a problem, it's the wad that doesn't compress so well.

Please don't forget the modified TyrLite.exe since I want to compare results with it. 

Hello,

Aftre some reply concernig my post about screenshots preview, some of you thought my rock cliff are too clean..... so I'm looking an example of Cliff design (map or tutorial) to improve my map quality: Does someone know where I could find this stuf??

Thanks 

Try these tutorials:

Tutorial 1: http://www.snarkpit.com/editing.php?page=tutorials&id=16
Tutorial 2: http://www.snarkpit.com/editing.php?page=tutorials&id=18
Tutorial 3: http://www.snarkpit.com/editing.php?page=tutorials&id=17 

The terrain tutorials are relevant..

I have a terrain map, which (bordering on the ridiculous, I know) is 32,000 brushes. It is on a grid 4096 x 4096 and is the 'canyon' part of a Caves and Canyons map. No brush exceeds the boundary. Before I set the BrushMerge operation going, which is likely to take 24+ hours, I want a quick look at it in Quake.

I knew clip-nodes would be a problem so placed two large Clip Brushes over the terrain and left just a small area for the player entity - I planned to 'no-clip' to look around. The map is not sealed.

It compiles OK (-nofill) with a 3.98M .bsp file but Fitzquake crashes i.e. straight to Windows without an error message.

OK. So no one is surprised. But do you know how I might get such a map into FitzQ? 

You could try TyrQuake instead, it's more tolerant to troublesome maps.

Another way is to remove the clipbrushes and use qbsp option -fill instead. This will force fill (i.e. basically remove) hulls 1/2 if they leak (which you indicate they do).

The actual size of the bsp can't be a problem; I've loaded bsps up around 15 MB.

Anyway, I'd like to have the zipped map+wad if possible. It sounds like a good test case for the compilers. 

Am I right in thinking that the transparent colour on sprites - the pink No. 255 - does not act as transparent on models? If so, is there any way of getting transparency on models? 

Hello R.P.G
Thanks for the link, it gives a good overview how to build very good rock and cliff design.... and also how to use the "clip brushes" feature... I haven't used this before so thanks a lot, I'll made the try ASAP..
Bye... 

at http://user.tninet.se/~xir870k . Main features are soft spotlights and more flexible fast option. Please see readme for details.

Any comments are welcome. 

Yeah, you're right that you don't get transparency with that pink, with the possible exception of one software quake engine that claimed it had added that. Only way I know that you can get transparency is with an external tga texture with alpha channel. 

I've had problems in the past when a brush was at one of the 4096 bounds, but it didn't exceed it. I can't recall if it crashed the QBSP or the engine; I think it might have been QBSP. Anyway, if I just moved the edge of the brush 1 unit inside the 4096 bounding it eliminated the problem.

This may or may not be relevant, but I thought I'd put it out there. 

I want a func_door to fall on the player and not retreat back into the open position after it hits the player's head. Because Quake doors don't have a crusher spawnflag like Quake 2, this isn't possible, is it?

/me doesn't want to use func_trains 

Thanks, it did make a difference in as much as I now get an Alloc bloc Full error. Oh well, I think I'll just run the Merge Brush program first and do things normally. 

Would not a "wait -1" accomplish that? 

headthump's suggestion will work, but it will only go down once. if you want it to keep going up and down, you will need to also set the toggle flag on the door, then put a trigger everywhere around the crusher, with a wait key of it's own that would be the approximate time the crusher takes to go from one state to the other. 

Mike: The alloc block full error comes from a brush with a face that is far too large for glquake to handle. don't know what the exact unit X unit amount is, but a safe bet is to just chop anything larger than 2048x2048 and go down from there until the error stops. It should be noted that this may also be caused by an invalid brush which Quake thinks has an infinite face, you can test for these by loading the map in dos or winquake and noclipping outside the map, the offending face will be pretty apparent if you take a good once around. 

Qbsp chops large faces up so I don't see how that would ever happend and I've think we've had this discussion before (although I don't remember what the conclusion was). 

is to just stretch the texture a whole lot, if it's in an area the player can't see (I've gotten errors like that just from using really big boxes to seal off the level using a non-sky texture) 

jesus crap! wtf is wrong with it?! when working on small brushes, selecting the right vertex is a pain in the ass... for some reason, clicking on one vertex will select another, and clicking far away from the brush will select another vertex... is there any way to change settings so that clicking on a vertex will select that specific vertex and not another one? it's nigh on impossible to create some decent organic shapes as it is. 

I wish I was home so I could get GTKRadient so I could be completely certain (anyway to get it running without one of the specified games being on your harddrive, btw) but if you look on the second toolbar down there is a set of buttons marked x/x y/y z/z this will change the screen that is the current one to reverse the given view so if you were looking from the front you are now looking from the back.
That should help, but I have a feeling someone may need to clarify, and please feel free to do so. 

so I could get GtkRadient up and running 

This happens in the lightmap code. Two reasons you'd see this:

1. you too much surface area in your map. Reduce the surface area, or scale up the textures (which reduces lightmap coverage on a surface.)

2. you have messed with the -subdivide option in some qbsp variant, and produced a single surface which is too big for its lightmap to fit anywhere in the memory arrays glquake allocates for lightmaps. You shouldn't be messing with -subdivide stuff anyway, becuase it breaks compatability with old engines (like quake.exe, winquake.exe) 

I don't play with scissors, matches or -subdivide.

Do you mean by "surface area", the amount of the 4096 x 4066 grid that is filled with a brush or brushes? Or is it the total surface area of each and every brush added together, on which light falls?

The point being that my terrain map (following the amendment suggested by R.P.G.) covers the full 4032 x 4032, and contains 32K triangular brushes. Height is only 0 to 1024 at present. And I have not yet added the Caves section of the map, which will add another 32K brushes.

At Brush Merge stage, the brush count will reduce to <8000 brushes but the grid area and the brush surface area will not change.

Perhaps a smaller terrain? 

Surface area meaning actual polygons in the game, becuase these are what consume lightmap space. Either reduce the terrain area, or scale up the texture on it (lightmap resolution is tied to texture resolution.)