Linedef 96 can miss tags set by later multitagging linedefs
Linedef 96 acts in this way: in the same loop as 97-99, it searches for sectors with the specified tag and applies a new tag to them. Now assume the following linedefs exist somewhere in this order in the LINEDEFS lump:
- ...
- Linedef 96; applies tag 2 to sectors with tag 1
- ...
- Linedef 97; applies tag 1 to the front sector
- ...
Linedef 96 will search for sectors with tag 1, but it won't find any, since linedef 97 will only apply its tag after 96 has already occurred in the loop. Intuitively, though, when seeing your linedefs on the map, you'd expect to have both tag 1 and 2 on that sector.
Moving linedef 96 to a loop that runs after 97-99 will only partly help the problem. Observe:
- ...
- Linedef 96; applies tag 3 to sectors with tag 2
- ...
- Linedef 96; applies tag 2 to sectors with tag 1
- ...
Assuming there is a sector with tag 1, it will only have 1 and 2 by the end, not 3 at all. This behaviour is still wrong.
At the moment, I can't think of an easy way to fix this (iterating through the linedefs array as many times as there are linedef 96's is a really bad solution, and it would also be unfortunate to have to remove 96), but 2.2.10 shouldn't be released with this problem since it will really adversely affect mappers trying to use linedef 96. The best I can think of is to move 96 to another loop and tell mappers not to use 96 pointing to another 96 but allow 96 pointing to 97-99.
(A note: I can't actually test this in actual SRB2 since I can't compile anymore, but according to the code, I'm certain that this will happen.)