[DuduKrazy]

is there a way to disable polymer lights for specific actors? specifically, i want to disable them for the explosions, the atomic health and the green-canister-barrel-thingy, as such things brings my fps down when there are lots of them on screen.

[gibfrag]

i think you can turn them off by settings.

[Roma Loom]

DuduKrazy, on Apr 25 2010, 10:52 PM, said:

is there a way to disable polymer lights for specific actors? specifically, i want to disable them for the explosions, the atomic health and the green-canister-barrel-thingy, as such things brings my fps down when there are lots of them on screen.

not yet, they are hardcoded.

[Plagman]

If you're willing to throw in some CON code, setting htflag 256 on such actors should prevent them from casting hardcoded lights (cf http://wiki.eduke32.com/wiki/Htflags)

[DuduKrazy]

ok. but in which con file should i add this code?

[DuduKrazy]

hello? which con file should i add the "htflag 256" code?

[Jblade]

If you open up GAME.CON (I'm assuming you've got them extracted and stuff) and then search for the following line:

actor ATOMICHEALTH

and add underneath it:

actor ATOMICHEALTH
setactor[THISACTOR].htflags 256

If you search for 'actor EXPLOSION2' and 'actor NUKEBARREL' and add that extra line underneath those, it should work for those as well

[OpenMaw]

James, on May 1 2010, 12:05 PM, said:

If you open up GAME.CON (I'm assuming you've got them extracted and stuff) and then search for the following line:

actor ATOMICHEALTH

and add underneath it:

actor ATOMICHEALTH
setactor[THISACTOR].htflags 256

If you search for 'actor EXPLOSION2' and 'actor NUKEBARREL' and add that extra line underneath those, it should work for those as well

I love you, man.

[Roma Loom]

Well, I cant find OOZFILTER in game.con, looks like it's hardcoded.

[Danukem]

Roma Loom, on May 1 2010, 03:21 PM, said:

Well, I cant find OOZFILTER in game.con, looks like it's hardcoded.

OOZFILTER emits light? I'm not sure that's a good idea, considering there could be dozens of those in one room.

At any rate, the functionality of OOZFILTER is hardcoded, but you can still add the flag to the sprites in GAME.CON (or in any other CON for that matter).

I would try doing it like this:

gamevar temp 0 0

state nolight
  getactor[THISACTOR].htflags temp
  orvar temp 256
  setactor[THISACTOR].htflags temp
ends


onevent EVENT_LOADACTOR

ifactor OOZFILTER state nolight

endevent

You could add that block of code to the top of GAME.CON, or to the bottom of GAME.CON

For every tile that you want to prevent from emitting light, just add a corresponding line such as "ifactor DIPSWITCH state nolight" to the event. Notice that the code uses orvar to add the flag for no light, so as not to erase any flags the sprite may already have. This method will only work for sprites that are in the map. It will not work on sprites that get spawned, such as respawns, projectiles, etc.

[DuduKrazy]

ok. now is it possible to use the modified con file with another mod, like Duke Plus?

[Gambini]

DeeperThought, on May 1 2010, 07:43 PM, said:

OOZFILTER emits light? I'm not sure that's a good idea

It´s not a good idea just as it´s not a good idea to make all the switchs and and accesswitchs to emit a gaudy and loud light.

[Roma Loom]

DeeperThought, on May 2 2010, 01:43 AM, said:

OOZFILTER emits light? I'm not sure that's a good idea, considering there could be dozens of those in one room.

Yeah, but that's not that terrible even when You have dozens of them like in e2l9 in the boss room in terms of performance. The trouble is that their light sums in a strange way making the room completely overlightened. Also there are hidden OOZFILTERS used justs like SEENINEs for blowing walls in the very same e2l9 and they emit light too.
So I've put Your code right after include defs.con and user.con, the state "nolight" works for sure when I put "state nolight" in Atomic Health actor definition, but it wont work in the event EVENT_LOADACTOR for me. OOZFILTER still emits light. What am I doing wrong? (note that I have pretty poor basic knowledge of the CON language) - have mercy on me

[Danukem]

Roma Loom, on May 2 2010, 02:33 AM, said:

Yeah, but that's not that terrible even when You have dozens of them like in e2l9 in the boss room in terms of performance. The trouble is that their light sums in a strange way making the room completely overlightened. Also there are hidden OOZFILTERS used justs like SEENINEs for blowing walls in the very same e2l9 and they emit light too.
So I've put Your code right after include defs.con and user.con, the state "nolight" works for sure when I put "state nolight" in Atomic Health actor definition, but it wont work in the event EVENT_LOADACTOR for me. OOZFILTER still emits light. What am I doing wrong? (note that I have pretty poor basic knowledge of the CON language) - have mercy on me

I dunno. You can try using EVENT_GAME instead of EVENT_LOADACTOR. That will constantly set the flag on the sprites, and it will work on spawned sprites as well. The reason I didn't use it in the first place is because the code has to run constantly, which is less efficient. But it shouldn't affect performance if that's all you're doing.

[DuduKrazy]

DeeperThought, on May 1 2010, 07:43 PM, said:

OOZFILTER emits light? I'm not sure that's a good idea, considering there could be dozens of those in one room.

At any rate, the functionality of OOZFILTER is hardcoded, but you can still add the flag to the sprites in GAME.CON (or in any other CON for that matter).

I would try doing it like this:

gamevar temp 0 0

state nolight
  getactor[THISACTOR].htflags temp
  orvar temp 256
  setactor[THISACTOR].htflags temp
ends


onevent EVENT_LOADACTOR

ifactor OOZFILTER state nolight

endevent

You could add that block of code to the top of GAME.CON, or to the bottom of GAME.CON

For every tile that you want to prevent from emitting light, just add a corresponding line such as "ifactor DIPSWITCH state nolight" to the event. Notice that the code uses orvar to add the flag for no light, so as not to erase any flags the sprite may already have. This method will only work for sprites that are in the map. It will not work on sprites that get spawned, such as respawns, projectiles, etc.

i pasted the code, but the OOZFILTER actor still emits light. i also added the flag "setactor[THISACTOR].htflags 256" on some of the actors, and it worked on them. well, except for the atomic health which still casts light unless i'm on the thing's sight.
so far, i got a noticeable fps boost, although i still get fps drops with lots of lights on screen at once and with maps that use spotlights. and E1L1 is still unplayable for me.

[Roma Loom]

EVENT_GAME did the trick, thanks.

[DuduKrazy]

it did work for me, too.

now, what if i want to do that stuff on mods like Duke Plus? what should i do?

[Danukem]

DuduKrazy, on May 2 2010, 09:28 AM, said:

it did work for me, too.

now, what if i want to do that stuff on mods like Duke Plus? what should i do?

Add the code to your DEFS.CON or USER.CON

Then it will be used with whatever mods (such as DP) that use those CONs, and you won't have to edit the code for the mods.

[DuduKrazy]

i added the code to those files, but most actors still casts light in Duke Plus. (except the oozfilter) in the original game, however, it works as intended.

[Danukem]

DuduKrazy, on May 3 2010, 05:38 PM, said:

i added the code to those files, but most actors still casts light in Duke Plus. (except the oozfilter) in the original game, however, it works as intended.

Ah, I'll bet that's because DP has code that tells sprites to not be processed in EVENT_GAME by default. It's an important optimization that should remain. What you would need to do, then, is add the cases you want to the big switch statement of EVENT_GAME in DUKEPLUS.CON, instead of having the code in a separate CON file. This is complicated by the fact that some sprites that you may want unlit could be listed in the switch statement already, so adding them in somewhere else would create duplicate cases and prevent other code from working. I could show you how to do it, but I would rather not because I think a better way to go about it is to make the sprites taggable or provide some other user friendly method of turning off the lights. There's also the possibility that the light will be toned down in future builds without us doing anything.

So I'm just going to wait it out for a while.