For people who have in-progress maps that rely on the broken method, what exactly are the steps required to preserve the look after the fix is made (e.g. the OP)?
[Before someone asks: I don't have any said maps myself. Just advocating.]
[x64-g3.4pre-236-gc1ce6c90ca] Another Dynamic Lights Issue
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Re: [x64-g3.4pre-236-gc1ce6c90ca] Another Dynamic Lights Iss
Multiply size and secondarySize by 2/3. This should be done for all lights that have no attenuate property or it is set to non-zero value.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [x64-g3.4pre-236-gc1ce6c90ca] Another Dynamic Lights Iss
To ease transition I'll add a LightSizeFactor that will apply to all following lights in a definition file. That'll mean you will only have to add one line at the top instead of changing every single light.
My reason for not keeping the bogus code is that it creates inconsistencies. It's only attached attenuated lights that are affected so it won't behave properly if the light was manipulated externally. The past has clearly shown that every bit of inconsistent behavior will inevitably cause problems and in the end still need a workaround so that it can be used in a reliable fashion.
Not again!
My reason for not keeping the bogus code is that it creates inconsistencies. It's only attached attenuated lights that are affected so it won't behave properly if the light was manipulated externally. The past has clearly shown that every bit of inconsistent behavior will inevitably cause problems and in the end still need a workaround so that it can be used in a reliable fashion.
Not again!
- Xane123
- Posts: 165
- Joined: Tue Nov 24, 2015 1:58 pm
- Graphics Processor: nVidia (Modern GZDoom)
- Location: Inwood, WV
- Contact:
Re: [x64-g3.4pre-236-gc1ce6c90ca] Another Dynamic Lights Iss
Not to add a potential second dynamic light bug, but is this related to this oddity where dynamic lights only light linedefs facing directly west or east but not diagonal or any other orientation?
35596dbbc44713c9ab9521f0d044f1d9b0cb0397 and many commits are after this, so I don't know if this bug still exists, whether it is related to this or not.
This was taken on commit - Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [x64-g3.4pre-236-gc1ce6c90ca] Another Dynamic Lights Iss
We cannot test and debug screenshots. If you want something checked, post a map or a link to a map.
Re: [x64-g3.4pre-236-gc1ce6c90ca] Another Dynamic Lights Iss
Care to clarify? Does that mean a size of 64 should be edited to be 38.4? (64 * (2 / 3))_mental_ wrote:Multiply size and secondarySize by 2/3. This should be done for all lights that have no attenuate property or it is set to non-zero value.
Re: [x64-g3.4pre-236-gc1ce6c90ca] Another Dynamic Lights Iss
Yes, something like that. Radii are integers internally though.
There is a better solution: 'lightsizefactor 0.667' on top of GLDEFS.
There is a better solution: 'lightsizefactor 0.667' on top of GLDEFS.