Make Continuously Falling Sector setup more intuitive for map makers
Since the relevant topic was locked and I couldn't post any further comment to suggest or question something, I'm going to post my comments here:
Why should a falling FOF use the a floor height for its ceiling's ending point? And why should a rising FOF use the a ceiling height for its floor's ending point? The thing is that it's counterintuitive a ceiling value being used for floor and vice-versa. If I set a FOF to go from 192 & 128 (ceiling & floor values) to 64 & 0, I don't expect it to go to 0 & -64. But it does.
It would be easier for level designers to figure out if ceiling values were used for ceiling heights, and floor values for floor heights, just for consistency (e.g. Linedef Type 60). If the FOF is falling, the ceiling height of the linedef's back sector could stay unused, as is now. If rising, the floor height of the linedef's back sector could stay unused too. The linedef's back sector heights would work as limits of FOF's movement: it wouldn't move any further.
If the current working way is desired (which in my opinion is confusing -- I've spent months to workaround it), I think I would understand if it was explained.
(Plus, I discovered this linedef type, #52, doesn't require a sector tag number to work. It can be zero, and still works.)
Besides, the wiki description was corrected.
Since the relevant topic was locked and I couldn't post any further comment to suggest or question something, I'm going to post my comments here:
Why should a falling FOF use the a floor height for its ceiling's ending point? And why should a rising FOF use the a ceiling height for its floor's ending point? The thing is that it's counterintuitive a ceiling value being used for floor and vice-versa. If I set a FOF to go from 192 & 128 (ceiling & floor values) to 64 & 0, I don't expect it to go to 0 & -64. But it does.
It would be easier for level designers to figure out if ceiling values were used for ceiling heights, and floor values for floor heights, just for consistency (e.g. Linedef Type 60). If the FOF is falling, the ceiling height of the linedef's back sector could stay unused, as is now. If rising, the floor height of the linedef's back sector could stay unused too. The linedef's back sector heights would work as limits of FOF's movement: it wouldn't move any further.
If the current working way is desired (which in my opinion is confusing -- I've spent months to workaround it), I think I would understand if it was explained.
(Plus, I discovered this linedef type, #52, doesn't require a sector tag number to work. It can be zero, and still works.)
Besides, the wiki description was corrected.
Last edited: