Bug 890

Summary: Very first door in cc4pbet4.wad map 21 does not work (generalized lift action 13433)
Product: Odamex Reporter: ckassap
Component: ClientAssignee: Odamex Bug Reporter <odamex-bug-reporter>
Status: RESOLVED FIXED    
Severity: blocker CC: ijgjgr
Priority: P1    
Version: 0.6.x   
Hardware: x86 (Windows, Linux, etc)   
OS: Windows   
Bug Depends on:    
Bug Blocks: 900    
Attachments: Hacky (and incomplete) fix

Description ckassap 2012-08-15 20:19:40 UTC
The very first door (lift) in map 21 of cc4pbet4.wad does not lower when used. The linedef in question has generic lift action 13443 applied to it. There is another linedef with action 6 directly in front of this line, but this line is flagged as passThru, so it should still work.

The lift works fine in zdoom, eternity, prboom, prboom+, and zdaemon.
Comment 1 Amateur Spammer 2012-08-16 09:54:56 UTC
(In reply to comment #0)
> The very first door (lift) in map 21 of cc4pbet4.wad does not lower when used.
> The linedef in question has generic lift action 13443 applied to it.
This turned out to be irrelevant.
> There is
> another linedef with action 6 directly in front of this line, but this line is
> flagged as passThru, so it should still work.
... but doesn't, due to broken translation to Hexen-like internal format.
Comment 2 Amateur Spammer 2012-08-16 10:17:34 UTC
Created attachment 394 [details]
Hacky (and incomplete) fix
Comment 3 Amateur Spammer 2012-09-03 21:08:31 UTC
Problem: Boom's PASSTHRU flag that allows the line to not "eat" the Use action is only honored for Use-activated special lines. It is ignored on walkover-activated and hitscan-activated lines. This patch makes the translation to internal format honor PASSTHRU on walkover-activated lines, but does nothing about hitscan-activated lines (fixing this requires to add another activation type, SPAC_IMPACTTHROUGH, but then the activation method won't fit in 3 bits, and on-disk linedefs' flags and internal flags would have to be separate. Or take another approach...)
Comment 4 Mike Lightner 2012-12-14 22:36:29 UTC
A patch has since been applied for this in r3505.  Marking fixed.