[x64-g3.4pre-236-gc1ce6c90ca] Another Dynamic Lights Issue

[Xaser]

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.]

[_mental_]

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]

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!

[Xane123]

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?

This was taken on commit 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.

[Graf Zahl]

We cannot test and debug screenshots. If you want something checked, post a map or a link to a map.

[Nash]

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.

Care to clarify? Does that mean a size of 64 should be edited to be 38.4? (64 * (2 / 3))

[_mental_]

Yes, something like that. Radii are integers internally though.

There is a better solution: 'lightsizefactor 0.667' on top of GLDEFS.