Talk:Raising sectors change to orphaned sector type

Visplanes are dynamically generated rendering structures. Are you sure you don't want to use "sector" here? While it's true that visplanes associated with the walkway will continue to display sludge when the bug is triggered, that is because the type & texture of the underlying sectors fails to change, not because of any rendering-specific bug. 71.58.109.233 23:20, 4 October 2007 (UTC)

It seems that this is a mapping error and doesn't really need a full article to itself. I'd argue merging with the article for the level that it's referring to (also: MAP12 is the factory, not MAP13, so it's unclear which level is being refered to). Fraggle 00:36, 5 October 2007 (UTC)


 * Probably the "blood" area with the radiation suit on MAP12.   Ryan W 02:02, 5 October 2007 (UTC)

If nothing else, this is not a good title for the article, whereas it is hardly specific to one map (for example, it also occurs in the yellow key room of Doom E2M2), and whereas the initial situation has nothing to do with visplanes (which would require a difference in sector properties as explained here). I was under the impression that it was a well-known quirk of certain linedef types (e.g. type 59) and therefore, while it could be written up as an "oddity", it is certainly not in the same class as, say, Savegame buffer overflow. Ryan W 02:02, 5 October 2007 (UTC)

Not an engine bug
This could be considered a quirk with the level, but it's not the engine's fault. When the sector first starts raising for this action, it changes it's flat to the highest adjacent one. If you don't walk on them in order (say, stepping on the middle one first), then the flat will not change, because the highest adjacent sector in that case will be the blood. I think this article should be removed, becuase as far as I know, it's not fixable.


 * It could be fixed by a port that added more data fields to the SECTORS lump (like a post-trigger floor type) or an extra tag to the sector it should resemble after rising. Maybe there's some way to do it with scripting too.  But with vanilla, no, probably not.


 * I don't understand why we should remove the article as a consequence, though. Savegame buffer overflow isn't fixable either and can clearly be worked around by changing the map.    Ryan W 22:22, 10 January 2008 (UTC)


 * I figure, if this article is not deleted (or at least merged with a map article), it will probably need the following adjustments:
 * A complete rewrite so it's easier to read, without any run-on sentences.
 * Proper vocabulary; i.e. use of the word "sector" and not "visplane"
 * Renaming for clarity and simplicity, to be less specific, and to meet standards (ex: "Sector properties do not change when triggered")
 * A strong, clear explanation as to why it can be argued that this is not "merely a mapping error"
 * Accurate and clear detail of the "bug's" occurrence in MULTIPLE maps, not in just one map.
 * Or, if it can be clearly demonstrated that the problem is a mapping error, and only occurs on MAP12 or MAP13 (whichever we're talking about), then it should be merged with the article for that map. If it turns out to be a mapping glitch on multiple maps, those map articles should have an explanation added to their "Bugs" sections.
 * Zack 03:08, 11 January 2008 (UTC)


 * I agree entirely. As 71.205.26.227 says, this could occur on any level with a series of sequential rising platforms; it is only considered rare because such platforms happen to be rare in the stock levels.  One option would be to list such quirky behaviors at the bottom of the list of linedef types, as we do in the Tag 666/Tag 667 articles, rather than giving each one its own article.  The E2M2 article lists it too (although not as a "design bug", since you're supposed to try to trigger the platforms sequentially after all, and if you fail, perhaps you shouldn't expect to come out unscathed).    Ryan W 03:52, 11 January 2008 (UTC)