MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001398Zandronum[All Projects] Bugpublic2013-07-14 08:512013-07-21 08:26
ReporterPresident People 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusacknowledgedResolutionwaiting for zdoom 
PlatformAppleOSMac OS XOS Version10.4-10.7
Product Version1.0 
Target VersionFixed in Version 
Summary0001398: Pulselight dynamic light type bugginess
DescriptionDepending on its position in the dynamic light binding sequence, pulselights may not correctly appear. I have arranged three actors to demonstrate this. They are copies of the ExplosiveBarrel, and each have dynamic lights assigned to them in different order. The explosion staying after they are destroyed is intended behavior.

BrokenExplosiveBarrel has only one dynamic light in the sequence: a green pulselight. when you destroy the actor, the light appears on the last frame and persists (as intended).

BrokenExplosiveBarrel2 has two lights: a red flickerlight on the first frame, and a green pulselight on the last. When the actor is destroyed, the green pulselight appears very brightly for an instant, and disappears completely.

BrokenExplosiveBarrel3 has three lights: a green pulselight, a red flickerlight, and a green pulselight again. The green pulselight on the first frame appears fine. When the actor is destroyed, the red flickerlight and green pulselight will appear very brightly in sequence for an instant, and the green pulselight will persist.


This can't be intended behavior for pulselights? The Zdoom wiki mentions nothing about this strangeness.

Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files? BrokenBarrel.pk3 (1,322) 2013-07-14 08:51
https://zandronum.com/tracker/file_download.php?file_id=1011&type=bug
? BrokenBarrelv2.pk3 (1,357) 2013-07-14 22:32
https://zandronum.com/tracker/file_download.php?file_id=1013&type=bug
Issue History
Date ModifiedUsernameFieldChange
2013-07-14 08:51President PeopleNew Issue
2013-07-14 08:51President PeopleFile Added: BrokenBarrel.pk3
2013-07-14 08:59President PeopleNote Added: 0006626
2013-07-14 13:32DuskDescription Updatedbug_revision_view_page.php?rev_id=3685#r3685
2013-07-14 13:32DuskNote Added: 0006627
2013-07-14 15:32Torr SamahoNote Added: 0006629
2013-07-14 22:32President PeopleFile Added: BrokenBarrelv2.pk3
2013-07-14 22:35President PeopleNote Added: 0006642
2013-07-14 22:36President PeopleNote Edited: 0006642bug_revision_view_page.php?bugnote_id=6642#r3698
2013-07-16 17:23ArcoNote Added: 0006669
2013-07-21 08:25Torr SamahoNote Added: 0006721
2013-07-21 08:25Torr SamahoStatusnew => acknowledged
2013-07-21 08:26Torr SamahoResolutionopen => waiting for zdoom

Notes
(0006626)
President People   
2013-07-14 08:59   
Sorry, I explained Barrel3 completely wrong. It's late, and I've wasted my whole night trying to figure this crap out. Here's the correct explanation:

BrokenExplosiveBarrel3 has three lights: a green pulselight, a red flickerlight, and a green pulselight again. The green pulselight on the first frame appears fine. When the actor is destroyed, the red flickerlight and green pulselight will appear very brightly in sequence for an instant, and the green pulselight will persist.
(0006627)
Dusk   
2013-07-14 13:32   
Updated description with the corrected paragraph.
(0006629)
Torr Samaho   
2013-07-14 15:32   
Is this any different in GZDoom?
(0006642)
President People   
2013-07-14 22:35   
(edited on: 2013-07-14 22:36)
It is not any different in GZDoom.

At first I was fooled into thinking it was, as I borrowed a light from Zandronum's DOOMDEFS. The red light did not appear (since it didn't exist), and the green light persisted on all three (since it was defined in the example - which is interesting actually).

But it is indeed broken, as I've updated the example to be self-contained (gldefs-wise, at least); both the red and green lights are defined within the example now.

Same results in GZDoom as in Zandronum with version 2 of the example.
(0006669)
Arco   
2013-07-16 17:23   
I tested this with the latest verison of GzDoom (1.8.2) and it appears to have the same problems as defined on this ticket. GzDoom 323 also suffers from this.
(0006721)
Torr Samaho   
2013-07-21 08:25   
Then this should be taken care of in GZDoom first.