Menu
▾
▴
#201 Generalised Crusher Bug
Generalised Crusher Walkover Linetypes do not work. They are line types 12232, 12233, 12264 and 12265.
This is apparently a very old Boom bug.
This bug has been fixed in zdoom,edge and vavoom and will be fixed in Risen3Dv2.2.04.
The bug is present in prboom and eternity/WinMBF
Test wad attached.
test wad highlighting the bug
Boom does not have support for walk generalized crushers. It is known. PrBoom can't change it because of compatibility reasons. PrBoom does not like to change things in zdoom way. To change something we should introduce new level of compatibility (new demo version), but such things should not happen often. RjY has list with such fixes for next complevel (18) and I am pretty sure this issue is present there and waits 2.6.x or something.
And my personal point of view: it should not be changed never. All changes after Boom is unnecessary and it is a reason of the mess. 99.9% of demos are recorded with complevels 2, 3, 4 and 9. MBF+ complevels are total mess, because behavior of engine is 'random' and depends from options of compatibility. It's just impossible for mappers to support such random crap, because your map will work with some options, but does not with another. Mostly it can be fixed with (unsupported) OPTIONS lump, but who will care about it in 2009?
Here is an extract from Boomref.txt dated 22/12/98 ...
-------------------------------------------------------------------
generalized crushers (128 types)
field description NBits Mask Shift
-------------------------------------------------------------------
trigger W1/WR/S1/SR/G1/GR/D1/DR 3 0x0007 0
speed slow/normal/fast/turbo 2 0x0018 3
monster n/y 1 0x0020 5
silent n/y 1 0x0040 6
DETH Nomenclature:
W1[m] Crusher S [Silent]
WR[m] N
S1[m] F
SR[m] T
G1[m]
GR[m]
D1[m]
DR[m]
Notes:
1) Speed is 1/2/4/8 units per second, faster means slower damage as usual.
2) If silent is 1, the crusher is totally quiet, no start/stop sounds
... so according to this, Boom, and all its derivatives, should support walkover generalized crusher triggers.
>... so according to this, Boom, and all its derivatives, should support walkover generalized crusher triggers.
Of course it should, but it does not. We cannot change history. We just want to be a good compatible port.
We cannot change history.
No ... but you can fix past mistakes.
... and how would it break compatibility ?
>and how would it break compatibility ?
If you mean to fix it in new complevel, then it will not break compatibility, because old prboom will not able to play new demos. And it is already bad. Plus nobody should use "no complevel" mode. If you mean to fix it with "complevel 9" (mostly using complevel for demo recording on Boom levels) - it will never happen, because old prboom will not able to play demos recorded by new prboom and vice versa
>No ... but you can fix past mistakes.
It is not prboom way. At least it is not my vision of prboom way. All such doom/boom bugs should not be estimated as bugs at all. They are Doom's quirks, they are Doom (Boom in case of this topic). In any case, I am sure it will be fixed for 2.6.x for new demo version code, but I do not know will it happen ever or not. Ask RjY :)
Just to add ... I stated that it affects 4 linetype numbers. I was wrong. It affects 32.
I'v just discovered that even Legacy has had this Boom bug fixed at least as far back as 2004 ! I have been informed that Eternity will have this bug fixed. So I guess prboom\prboom+ will end up being the only "boom compatible" port not to have a boom bug fixed, if not attended to ...
Here we see the difference between a port meant for recording and watching demos, and a port meant for "simply" playing. Bugs cannot be fixed because they are necessary when demo compatibility is the primary goal. Whereas when it's not considered truly important (Eternity) or even considered totally irrelevant (ZDoom), then bugs are fixed.
I also think that the compat flag system used by ZDoom seems a lot more sane than complevels.