Projectile lights occasionally don't work

[Guest]

Windows 64-bit, drivers up to date, happens on default settings without GZDoom ini,
latest g4.8pre-369-g0a208597c from drd and GZDoom 4.7.1.

In normal gameplay this pretty much never happen(?) but in some instances in a random fashion:

some fireballs go fully unlighted,
some fireballs are lighted from the start,
some unlighted fireballs snap lights on while in midair.

Here's a test map and a demo file recorded on that latest g4.8pre-369-g0a208597c
but it plays on 4.7.1 with the same results.
https://www.dropbox.com/s/tw35dhf3ya8hl ... n.zip?dl=1

Play the demo with:
gzdoom.exe -iwad doom2.wad -file lights.pk3 imp+baron.wad -playdemo imp+baron.lmp

[Guest]

Animated gif from the demo:
https://imgur.com/k35TGNG

[Guest]

I noticed that this issue doesn't occure if I add just one constant light source (a candle, torch, tech lamp) on the testmap.
If there are none the fireball lights won't emit light occasionally.

So repeatable:

+ Happens in 4.7.1 and the latest gzdoom-x64-g4.8pre-386-gc12c4444e.
+ Doesn't happen in 4.7.0.
+ Happens in vulkan, opengl, softpoly and opengles; GTX 960 and Intel HD.
+ Happens on default settings and without mods.
+ The above wad above is a Doom format map without extra lumps, ZScript, Decorate, ACS.

A video in better quality:
https://imgur.com/a/oBGN2v4

[RKD]

Afaik, dynamic lights need a GLDEFS lump definition. Perhaps the map format is also playing a role in that strange behaviour? If I wanted to use dynamic lights in a mod, I'm pretty sure I'd need to use "GZDoom: Doom (UDMF)". Not sure about "GZDoom: Doom (Doom format)" though.

[Guest]

> Perhaps the map format is also playing a role in that strange behaviour?

No. The lights have worked even for Doom original iwads.

And it doesn't happen in 4.7.0 (Sept 21) but it happens in drdteam build g4.8pre-4-g3ef60a40a (Sept 24).

I can reproduce this in a random manner on a single 512 x 512 sector wad. Just the player, one imp and GZDoom's own lights.pk3 only. Some times the imp's fireball has the light, some times not.

[RKD]

This person also has a similar issue, apparently: viewtopic.php?f=2&t=75250

It may as well be a bug in the dev builds. Have you tried DMing your test wad to devs? Considering that yours is able to reproduce the bug, it could be worth a shot. Can't suggest anything else with my limited knowledge, sorry.

[Rachael]

We can't fix intermittent bugs if we have nothing reliable to test with that at least somewhat consistently causes their occurrence.

[Blue Shadow]

Attached below is a test map to reproduce the problem. Here's how:

• Load the map with Doom 2 and start a new game. Let the imp fire at you for a little bit. You should notice that some of its fireballs emit light while others don't, or occasionally do mid-flight.
• To your right in that alcove, there's a switch. Activate it to spawn an explosive barrel on the opposite side.
• Go back to the imp's view, and let it fire more at you. This time, all of its fireballs should emit light properly.
• Go and activate the switch again to get rid of the barrel (destroy it).
• Back to the imp again, let it fire at you. Just like when there was no barrel initially, some of its fireballs emit light, while others don't.

My test was done using GZDoom 4.7.1.

(Edit: attachment removed, since there is no longer need for it.)

[Guest]

Two attempts for a repeatable test:

lighttest2.zip (1 kb)
https://mega.nz/file/3T4n3CyC#koWGQtM20 ... QYHfPfyahA

UDMF format one sector wad. GLDEFS included, ACS script will shoot imp fireballs towards a wall.
For me the first fireball always has the light, the second has not, the third usually has not,
then the fireballs either have light or not.

lighttest.zip (3 kb)
https://mega.nz/file/GHZXgSwb#44wgRlrST ... wPXSP5XHn0

The same as in the first post. A doom format wad and a demo file recorded with 4.7.1.
It has one imp and one baron behind monsters blocking lines in a darkish room.
For me the demo playbacks on 4.7.1 and again on the latest drdteam build on three
different computers with the same result:

0:02 imp ball #1 turns it's light on approx one second after it has been shot
0:09 imp ball #2 has no light
0:12 imp ball #3 has no light
0:18 imp ball #4 gets the light after 1/3 second
0:20 imp ball #5 has the light on
0:24 imp ball #6 has no light
0:26 imp ball #7 has the light on
0:32 imp ball #8 has no light
0:37 baron ball #1 has no light
0:40 baron ball #2 has the light on

If those do not happen to anyone else or they aren't testable then I don't know.

And yeah, that other topic by SPZ1 is most likely from the same issue. Thanx for everyone's time!

[Graf Zahl]

fixed. I had to disable one check in the processing code - fortunately it was something that's not really relevant for performance.