[r302] Lights on (de)activated objects don't change

Bugs that have been resolved.

Moderator: Graf Zahl

Locked
Chris
Posts: 29
Joined: Fri Nov 28, 2008 1:18

[r302] Lights on (de)activated objects don't change

Post by Chris »

Don't really know what, if anything, can be done about this, but I thought to mention it anyway. GZDoom's lights.pk3 includes light objects that are added to Hexen's torches. Hexen added the ability to activate/deactivate objects, and when used on various objects like torches, they would switch to a lit/unlit state respectively.

In GZDoom, it seems the added dynamic lights are only applied given the initial state of such objects. If a torch is initially active, the object will continue to shine a dynamic light even after it's deactivated, and if it's initially inactive, it won't get a dynamic light after it's activated. This is noticeable in MAP02, in the side rooms leading to the Guardian of Steel/Fire/Ice maps.

Attached is a screenshot that shows this: the torches on the walls (initially enabled) continue to have dynamic lights after being disabled, and the torch further back (initially disabled) does not have a dynamic light after being enabled.
Attachments
snapshot1.png
snapshot1.png (439.49 KiB) Viewed 668 times
User avatar
Enjay
Developer
Developer
Posts: 4748
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Post by Enjay »

On a quick check into lights.pk3, the reason for this is obvious:

Code: Select all

object ZWallTorch
{
    frame WLTR { light WALLTORCH2 }
}
That allocates the light "WALLTORCH2" to every frame in the ZWallTorch actor that uses a sprite with the WLTR name. However WLTRI0 (the unlit frame) should not have a light attached so the code should look like this (I think):

Code: Select all

object ZWallTorch
{
    frame WLTRA { light WALLTORCH2 }
    frame WLTRB { light WALLTORCH2 }
    frame WLTRC { light WALLTORCH2 }
    frame WLTRD { light WALLTORCH2 }
    frame WLTRE { light WALLTORCH2 }
    frame WLTRF { light WALLTORCH2 }
    frame WLTRG { light WALLTORCH2 }
    frame WLTRH { light WALLTORCH2 }
}
That allocates the light to all the WLTR frames except frame I.

I think that other switchable decorations are also similarly affected.
User avatar
Enjay
Developer
Developer
Posts: 4748
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Post by Enjay »

Doing a quick search for the switchable Hexen items in GZdoom.pk3, I think these are all the ones that need to be changed, with suggested code:

[edit]Code removed and consolidated in another post further down the page[/edit]

Note, the cauldron is different because it is the A frame that is not bright. The light definitions are just the same as the ones currently in lights.pk3.

I thought that there might be more, but those 4 were the only ones that I spotted.


Whilst I was in there, I noticed that the two burnable trees did not light up. Here are some suggested definitions that may be useful.

[edit]Code removed and consolidated in another post further down the page[/edit]

They seem reasonable, but might need a bit of tweaking.
Last edited by Enjay on Sat Feb 28, 2009 22:22, edited 1 time in total.
Chris
Posts: 29
Joined: Fri Nov 28, 2008 1:18

Post by Chris »

On a quick check into lights.pk3, the reason for this is obvious:
...
That allocates the light "WALLTORCH2" to every frame in the ZWallTorch actor that uses a sprite with the WLTR name.
If that's true, then why wouldn't an initially-disabled actor have a light attached? It's only objects that are initially-enabled, then later disabled, that continue to shine a light, while initially-disabled objects that are later enabled don't light up at all.
User avatar
Enjay
Developer
Developer
Posts: 4748
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Post by Enjay »

Don't know. Perhaps internally GZdoom doesn't set a light on a switchable decoration that is disabled at map startup - which I suspect is a bug.

If that is what is happening then, presumably, it is possible for someone to define a switchable item that has a dynamic light in its inactive state (perhaps imagine a warning light that is green when active and red when inactive) and GZdoom would not show the red light if the item was placed in the map dormant.

Unless this is not a bug and there is some technical reason for this, it seems to me that the lights should be correctly allocated to the frames which need them in lights.pk3 (or custom gldefs - as appropriate) and the actor should show lights when the frames in question are being used - regardless of whether the actor is dormant, active, newly placed in a map or activated/dectivated during play.
Last edited by Enjay on Sat Feb 28, 2009 21:49, edited 1 time in total.
User avatar
Enjay
Developer
Developer
Posts: 4748
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Post by Enjay »

Forget the above. I'm not getting what you are getting. If I place a twined torch in a map and another one beside it: one dormant, one not, they both have a dynamic light attached at map startup when using the current lights.pk3. I can activate/decativate them as often as I like and they always have the light.

However, there are these actors:

ZTwinedTorchUnlit
ZWallTorchUnlit
ZFireBullUnlit
ZCauldronUnlit

These do not have any light definitions allocated to them in lights.pk3. When you place them in a map, initially they are unlit. However, they can be activated and when they are, they do not have a dynamic light attached. They should be given light definitions. They inherit from the other versions so exactly the same light definitions as the ones I posted above should be used for these actors too.


Summary:

4 switchable actors that should not emit light under certain conditions have a light allocated to all their frames in lights.pk3. They need to have lights.pk3 redefined to remove the light definition from their unlit frame.

4 decorations that inherit from these decorations do not have any dynamic lights allocated at all, but they can be activated in game, so need the same light definitions as their parent actors.

In addition, 2 tree actors that can burst in to flames do not have any lights attached and these should, IMO, have light definitions added to lights.pk3
Last edited by Enjay on Sat Feb 28, 2009 21:57, edited 2 times in total.
Chris
Posts: 29
Joined: Fri Nov 28, 2008 1:18

Post by Chris »

Ah, I see. Figured it might be something like that, but I wasn't sure (haven't done any Hexen map editing in quite a while).
User avatar
Enjay
Developer
Developer
Posts: 4748
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Post by Enjay »

To keep all the suggested code in one place:

Suggestions for the 4 switchable decorations and their inheritees

Code: Select all

// Twined torch 
flickerlight2 TWINETORCH 
{ 
    color 1.0 0.7 0.0 
    size 46 
    secondarySize 52 
    interval 0.1 
    offset 0 64 0 
} 

object ZTwinedTorch 
{ 
    frame TWTRA { light TWINETORCH } 
    frame TWTRB { light TWINETORCH } 
    frame TWTRC { light TWINETORCH } 
    frame TWTRD { light TWINETORCH } 
    frame TWTRE { light TWINETORCH } 
    frame TWTRF { light TWINETORCH } 
    frame TWTRG { light TWINETORCH } 
    frame TWTRH { light TWINETORCH } 
}

object ZTwinedTorchUnlit
{ 
    frame TWTRA { light TWINETORCH } 
    frame TWTRB { light TWINETORCH } 
    frame TWTRC { light TWINETORCH } 
    frame TWTRD { light TWINETORCH } 
    frame TWTRE { light TWINETORCH } 
    frame TWTRF { light TWINETORCH } 
    frame TWTRG { light TWINETORCH } 
    frame TWTRH { light TWINETORCH } 
} 


// Wall torch 
flickerlight2 WALLTORCH2 
{ 
    color 1.0 0.7 0.0 
    size 24 
    secondarySize 28 
    interval 0.1 
    offset 0 24 0 
} 

object ZWallTorch 
{ 
    frame WLTRA { light WALLTORCH2 } 
    frame WLTRB { light WALLTORCH2 } 
    frame WLTRC { light WALLTORCH2 } 
    frame WLTRD { light WALLTORCH2 } 
    frame WLTRE { light WALLTORCH2 } 
    frame WLTRF { light WALLTORCH2 } 
    frame WLTRG { light WALLTORCH2 } 
    frame WLTRH { light WALLTORCH2 } 
} 


object ZWallTorchUnlit
{ 
    frame WLTRA { light WALLTORCH2 } 
    frame WLTRB { light WALLTORCH2 } 
    frame WLTRC { light WALLTORCH2 } 
    frame WLTRD { light WALLTORCH2 } 
    frame WLTRE { light WALLTORCH2 } 
    frame WLTRF { light WALLTORCH2 } 
    frame WLTRG { light WALLTORCH2 } 
    frame WLTRH { light WALLTORCH2 } 
} 


// Fire bull 
flickerlight2 FIREBULL 
{ 
    color 1.0 0.7 0.0 
    size 64 
    secondarySize 70 
    interval 0.1 
    offset 0 40 0 
} 

object ZFireBull 
{ 
    frame FBULA { light FIREBULL } 
    frame FBULB { light FIREBULL } 
    frame FBULC { light FIREBULL } 
    frame FBULD { light FIREBULL } 
    frame FBULE { light FIREBULL } 
    frame FBULF { light FIREBULL } 
    frame FBULG { light FIREBULL } 
    frame FBULH { light FIREBULL } 
} 

object ZFireBullUnlit 
{ 
    frame FBULA { light FIREBULL } 
    frame FBULB { light FIREBULL } 
    frame FBULC { light FIREBULL } 
    frame FBULD { light FIREBULL } 
    frame FBULE { light FIREBULL } 
    frame FBULF { light FIREBULL } 
    frame FBULG { light FIREBULL } 
    frame FBULH { light FIREBULL } 
} 


// Cauldron 
flickerlight2 CAULFLAME 
{ 
    color 1.0 0.9 0.0 
    size 24 
    secondarySize 26 
    interval 0.1 
} 

object ZCauldron 
{ 
    frame CDRNB { light CAULFLAME } 
    frame CDRNC { light CAULFLAME } 
    frame CDRND { light CAULFLAME } 
    frame CDRNE { light CAULFLAME } 
    frame CDRNF { light CAULFLAME } 
    frame CDRNG { light CAULFLAME } 
    frame CDRNH { light CAULFLAME } 
}

object ZCauldronUnlit
{ 
    frame CDRNB { light CAULFLAME } 
    frame CDRNC { light CAULFLAME } 
    frame CDRND { light CAULFLAME } 
    frame CDRNE { light CAULFLAME } 
    frame CDRNF { light CAULFLAME } 
    frame CDRNG { light CAULFLAME } 
    frame CDRNH { light CAULFLAME } 
}

And suggestions for the burnable trees

Code: Select all

// ZXmasTree 
flickerlight2 XMASFIRE1 
{ 
    color 1.0 0.7 0.0 
    size 16 
    secondarySize 24 
    interval 0.1 
    offset 0 48 0 
} 


flickerlight2 XMASFIRE2 
{ 
    color 1.0 0.8 0.0 
    size 32 
    secondarySize 48 
    interval 0.1 
    offset 0 48 0 
} 


flickerlight2 XMASFIRE3 
{ 
    color 1.0 0.9 0.0 
    size 48 
    secondarySize 64 
    interval 0.1 
    offset 0 32 0 
} 


flickerlight2 XMASFIRE4 
{ 
    color 1.0 0.8 0.0 
    size 32 
    secondarySize 40 
    interval 0.1 
    offset 0 120 0 
} 


flickerlight2 XMASFIRE5 
{ 
    color 1.0 0.7 0.0 
    size 12 
    secondarySize 20 
    interval 0.1 
    offset 0 140 0 
} 


flickerlight2 XMASFIRE6 
{ 
    color 1.0 0.8 0.0 
    size 10 
    secondarySize 14 
    interval 0.1 
    offset 0 148 0 
} 


object ZXmasTree 
{ 
    frame XMASB { light XMASFIRE1 } 
    frame XMASC { light XMASFIRE2 } 
    frame XMASD { light XMASFIRE3 } 
    frame XMASE { light XMASFIRE3 } 
    frame XMASF { light XMASFIRE4 } 
    frame XMASG { light XMASFIRE5 } 
    frame XMASH { light XMASFIRE6 } 
} 




// TreeDestructible 
flickerlight2 TDESTRUCT1 
{ 
    color 1.0 0.8 0.0 
    size 48 
    secondarySize 56 
    interval 0.1 
    offset 0 32 0 
} 


flickerlight2 TDESTRUCT2 
{ 
    color 1.0 0.9 0.0 
    size 56 
    secondarySize 72 
    interval 0.1 
    offset 0 32 0 
} 


flickerlight2 TDESTRUCT3 
{ 
    color 1.0 0.8 0.0 
    size 40 
    secondarySize 48 
    interval 0.1 
    offset 0 20 0 
} 


flickerlight2 TDESTRUCT4 
{ 
    color 1.0 0.7 0.0 
    size 16 
    secondarySize 24 
    interval 0.1 
    offset 0 12 0 
} 

flickerlight2 TDESTRUCT5 
{ 
    color 1.0 0.7 0.0 
    size 8 
    secondarySize 12 
    interval 0.1 
    offset 0 4 0 
} 




object TreeDestructible 
{ 
    frame TRDTH { light TDESTRUCT1 } 
    frame TRDTI { light TDESTRUCT2 } 
    frame TRDTJ { light TDESTRUCT2 } 
    frame TRDTK { light TDESTRUCT2 } 
    frame TRDTL { light TDESTRUCT2 } 
    frame TRDTM { light TDESTRUCT3 } 
    frame TRDTN { light TDESTRUCT4 } 
    frame TRDTO { light TDESTRUCT4 } 
    frame TRDTP { light TDESTRUCT5 } 
}

Chris, you could try saving that to a text file called gldefs.txt and loading it at the command line to see if it fixes your problems. I think it should.
Chris
Posts: 29
Joined: Fri Nov 28, 2008 1:18

Post by Chris »

That seems to work. Thanks. :)
Locked

Return to “Closed Bugs”