I have long reached the limit Max lightdata limit and have been avoiding it by scaling down textures.
But now i found out, that by simply giving rad the paramieter "-lightdata 10000" i can increase the value without any drawbacks, or am i wrong here? Im sure that todays pcs can handle memory dimensions of like 6 or 10 mb but the HL engine is a different thing...
If it would be no problem i could only concentrate on r_speeds when it comes to details!

Todays pc can handle it, but the engine can't. same reason you cant go over a certain amount of r_speeds. Pc's can handle more polies, but the engine will choke severely

There is a better way to decrease lightdata. use lots of point based lights to light screens like I did on my map. And then use -nodynbounce. I managed to get down from arround 90% to 39%.

do texlights increase lightdata too?

Nah not in itself, but what I use for example on a monitor: put 4 point lights in front of it (bightness 48 to 64). This can also be used on something else of that size which emits light

This way you have 4 points lights lighting the screen it looks pretty good (if ya ask me better then textlight) Plus the added benefit you safe a lot of point lights this way. If you would use a textlight for that same surface you will get a lot more lights, which have to be calcuated and stored.

This method is more work, but you get better performance overall and I personally think it looks better. This way you also don't have to use an overlay (func_illusionary) to light just the light area. Overall saving runtime entities.

Alright, what i think lightdata describes is the lighning look of all those "chopped" polygons hlrad generates. Scaled down textures create more of those polygons than larger scaled textures. Im not sure if this information is even stored in the graphic card's memory and would therefor even make impact to performance...
There is no limitation of lightdata described in the mapping guidelines - and maps could be sooo much prettier with a higher value.
Another point is, that i think this is only a client side related issue... The problem with the entities is only because of the servers having too much work

Well I say try and test it. I can only say what I've observed from my side. And since lighting takes long if ya get close to the 6144Kb (max default setting using -sparse?) I'm not even gonnah try

Maybe it won't impact the performance much. But it will increase the filesize, so I think it would also impact the engine it's performance. Maybe someone with knowledge of the compiling tools and engines internal working can enlighten us, I dunno. Cagey aint arround anymore

The runtime entities I was talking about has nothing really to do with lightdata. I just implied that using my method you can light the light emitting area of the texture and make it look good (IMHO better). This without the use of the runtime entities func_illusionaries eating away at the maximum runtime entity count...

I already tried it, and there is no noticable difference... my map ns_disonberg_alpha3, which you seem to have already tested , has about 7 MB lightdata. The map plays like normal and there are no lightning related errors...
Hmm you know any Hl-Engine expert?

Not an expert, but I've poked around the compile tools a bit...

The only thing that affects the lightdata used by each polygon is:

• The texture used: The following textures don't have lightmaps generated at all and don't contribute to lightdata:
  • SKY
  • NULL
  • Water (begins with '*' or '!')
  • Possibly trans (begins with '@' or 'TRANS')
• The size of the polygon: The Half-Life engine has a hard limit on lightmap size of 16x16 with each lightmap value covering 8 texels. Polygons larger than 256x256 are split to prevent this limit being exceeded.
• The polygon's texture scale: Decreasing the texture scale means the polygon's lightmap will cover less area (in world units) and the polygon will have to be split sooner.

Also, faces hit by more than one switchable/flickering light will have one lightmap generated for each unique light style that affect them, up to a maximum of four lightmaps. You can increase the threshold at which a face is considered to be affected by dynamic lights by setting the "-coring" parameter of hlrad to a value >= 1. This may result in harsher edges at light boundaries, though.

Texture lights and point lights are identical as far as lightdata/performance goes; they are both transformed into the same internal representation when hlrad begins (this is the direct lights/BuildFaceLights in the compile log).

Given the above, you can decrease the size of your lightdata by covering unseen polygons in NULL (those on the outside of the map will be removed by hlbsp, so don't bother with those); increasing the texture scale where possible; reducing the use of multiple lightstyle; and increasing the coring value. I'm not aware of any actual limit to the lightdata size; the "-lightdata" switch is really just because it's easier for hlrad to allocate all the lightdata up front rather than continually reallocate every time it finds out it needs more.

Therefor it is no Problem to go over the lightdata limit?

Shouldn't be, as long as you're not going ridiculously high

There's a number of people that experience performance problems when the lightdata goes above 4 mbs (the original limit Valve used on the tools).