is that an ogre on the ledge there???
*is interested* 

Holy mother of godfuck I want that map 

ok, i've reposted in the screenshots thread, along with two more pictures :).

necros: yup, ogres et al are present and accounted for, joining a comprehensive bestiary of new and old monsters.

lol @ headthump - don't be so hard on yourself :) 

I've actually also thought of the intense local light effect of the inverse attenuation modes delay 1/2. In my Light there is already some programmatic flexibility for the attenuation formulae, mostly due to my emulation modes (IKLite etc).

I don't think your variant can be achieved with existing logic, so some modification must be done. I'm just wondering how I can add this without just adding a -kinn option.

E.g. have you also modified the delay 1 (1/x) lights? They will also get very intense close to the light. Maybe it should be added in the form of new delay modes, e.g. delay 5 would be a modified delay 2 variant? I can see that you might object to this solution although it appears rather logical, after all this is a new attenuation formula.

If I add it in the form of an option, what name would you suggest and should it also affect delay 1 lights similarly? 

Thx Preach & kinn
Do you know the naming convention for texture replacements? I've tried the actual texture name & the format used by DarkPlaces for model texture replacements but neither work. I'm using DP (& fitzquake altho I don't expect it to implement this). 

Another delay 2 attenuation variant is to cap the formula at the light intensity value, i.e. use the standard 1/(x*x) but no more than 1. This will conform more to the existing delay 2 light distribution, but will weaken the halo around the light.

The advantage is that light intensities don't need to be scaled so much just to get rid of the intense halo. The obvious disadvantage is that the lights in kinn's map are already adapted to the higher attenuation.

I just checked how this capped variant looks and it's not bad. Kinn, have you considered this? Does anyone else have an opinion of this issue? 

For darkplaces, to replace the frames of s_explod.spr you'd need to call the textures s_explode_0.tga, s_explode_1.tga and so on. The numbers correspond to the frame in the sprite you wish to replace, so if it's a simple, single framed sprite, you'd only need to stick a _0 after the name. 

That's the first thing I tried & it didn't work. I put them in the progs directory..perhaps I should try textures. 

I haven't used the sprite options in Dark Places, but my texture replacement file structure looks like this Quake ---> HeadThump ----> Textures. If you are using Quake 3 BSP format, of course you will need to add the name of the texture file you used in editor below the texture file, like this Quake ---> HeadThump ----> Textures ---> EvilLair8. Hope that helps. 

thanks, aguirre. firstly, you mentioned a "capped" option - i probably wouldn't use this option much, as it would still leave a halo of constant brightness around the light, which could look unnatural.

the problem with using my atten. method for a new delay value, eg. delay 5, is that I would have to go back and change the delay field for all existing lights in my map - possible but not entirely desirable, unless there's a search/replace function in Hammer, I dunno.

i don't really mind too much how you want to support this - either "delay 5", or "-kinn", it's all good :) of course it would be logical to do a similar thing with the delay 1 lights, as well.

if you do it as an option "-kinn" would be awesome, but of course you're free to choose whatever name you feel is best :)

again, many thanks for this :)

===============================================

glassman - for sprite textures in DP, you must name them like s_explod.spr_0.tga, rather than just s_explod_0.tga, i.e. you need the ".spr" extension before the "_0.tga". keep them in the same directory as the sprites and it should be fine. 

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?