Regarding lightstyles

[Dr. Shadowborg]

I'm trying to do a switchable fluorescent flicker type light, I know that the regular light style equates to 32, and I was wondering, while the qc source states that 32-62 are used by the light util for doing switchable lights, are any values above 32 actually used? (It seems like there's only one type of switchable light in stock quake, and that's the normal one...which is also implied by the source...)

Anybody know?

Edit: did an entity list check on e1m1.bsp's lightup lampposts, looks like maybe it uses those separate values for each switchable light, meaning that stock quake only supports a maximum of 30 switchable lights?!

[mh]

Looking through the engine source, there is a protocol limit of 255 for the number of lightstyles. I'm not sure why it was restricted to 62 (especially as the engine define for MAX_LIGHTSTYLES is 64), and this is something that should probably be changed.

The max length of a lightstyle string is definitely set to 64 though, but that only gives you 63 as it needs to be null terminated. No real reason why this can't be dynamically allocated or at least extended.

[Dr. Shadowborg]

Okay, so this means that quake has a hardcoded limit of 64? Or can you actually go up to 255 without the engine complaining at you?

If the former, I suppose I could always just use some sort of flag checking hack to get what I want working. (that uses the existing 30-32 max switchable...)


Oh man, now all of a sudden I have this urge to make a map where you can yank torches off walls and use them as weapons...not to mention modifying the spawn (tarbaby) into a fiend sized shoggoth-esque monster that's mostly immune to your weapons with the exception of the walltorch...

[mh]

The engine will complain very loudly if you go over 64.

Now that I come to think of it, I only checked in GLQuake for the protocol limit, there may be something else in the software renderer that enforces 64 as a hard limit.

[Spike]

yeah, 32 or so switchable lightstyles. you'll get error messages above that.
you can supposedly hack the map file a bit so you can get more.

note that this is lights with specific targetnames. you can have loads of ents, just 32 different targetnames on them.

Exceed the map and servers will start to do Bad Things, while clients will just error out.

Just bumping the max will make an engine incompatible with saved games.

The BSP format can hold up to 255 without errors. But don't try setting the style strings (ie: don't turn them on/off in legacy engines). The extra 64-255 ones will be fully switched on.

The limit truely is on the style strings themselves.

This is true for both GL and SW.

[mh]

you can supposedly hack the map file a bit so you can get more.

Take note QC people - "supposedly" doesn't mean you should.

Just bumping the max will make an engine incompatible with saved games.

There's one reason, although in a MP-only environment it would be do-able.

[Dr. Shadowborg]

Okay cool then, thanks guys!

What I'm gonna do is just leave assigning style number to the light util, but make the code check the spawnflags to set what kind of behavior it has. (and avoid using more than 32 different lightstyles.)

[Spike]

Take note QC people - "supposedly" doesn't mean you should.

Heh, alternatively you could modify the qbsp to not waste the 16 or so after the built in ones and before the switchable ones.
How you do that makes no difference to the engine - only to the mods that will be able to run it.
Presumably it could just assign from 63 downwards, and mods that define too many will just get stomped on (including #62). But that's okay because the map won't know it could use them anyway.

But yeah, it should be 32 switches, not 32 lights. I hope... Which is 640/20 so it should be enough for anyone. However, I have no idea why I just made up that /20. But hey...

Oh yeah, you can't just change a light's style value. It doesn't work like that.
lightstyles work by way of a lookup table.
Each surface can be affected by up to 4 styles. Each frame, the active lights are poked a bit to see if they're meant to animate or not. If they animate then all the lightmaps that are affected by that style are updated.
But yeah, light.exe builds those 4 style affectors into the bsp when it runs. You can't change which lights use which style past the light stage, at least not without recompiling the bsp.
The style field is useful only for two things. 1: telling light.exe which style to paint the light into. 2: telling the qc which lightstyle to switch on/off in a way that is compatible with the style numbers that light.exe used.
Don't forget that you can animate style 0 too. :)

[Dr. Shadowborg]

Oh yeah, you can't just change a light's style value. It doesn't work like that.

Wasn't planning on it.

I'd already figured that the style value was essentially a "channel" much like the various CHAN_* used with sound().

[mh]

Take note QC people - "supposedly" doesn't mean you should.

Heh, alternatively you could modify the qbsp to not waste the 16 or so after the built in ones and before the switchable ones.

I'd assume that they just exist to allow mods to have some headroom for expansion. If you're talking about what I think you're talking about though (deliberately overflowing a byte data type in order to cause it to wrap and thereby access some data that would otherwise be off-limits) I have only one question...

Were you born evil or do you make a special effort to be evil?