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)


 * I rewrote the article and gave it language more suitable to what it's talking about. I can't change the title, but I guess that's best left to other people. I still would have rather had it removed, but I guess it could be a good idea to make something useful of it. -Wagi 69.51.157.227 20:17, 15 January 2008 (UTC)


 * Rereading Tag 666 and Tag 667, I'm starting to agree with you. In those two cases there are legitimate logic problems in how the engine determines the sequence of events.  Here, on the other hand, the tagged linedefs do exactly what the specs say they will do; if a designer puts in a sequence of platforms as in E2M2, he/she can predict the anomaly in advance.  Does that make it a level design bug?  I'm not sure.  Is the arch-vile jump on TNT 30 a level design bug?  What about rocket jumping to the exit on E1M4?    Ryan W 01:51, 16 January 2008 (UTC)


 * For that matter, it could be that the level designers of E2M2 and MAP12 were fully aware of this sector behavior and left it alone, on the basis that the player must follow the entire path from beginning to end. In that case it's not a bug or error of ANY sort.


 * By the way Wagi, your rewrite looks great! Zack 06:04, 16 January 2008 (UTC)


 * Thanks Zack! And Ryan, you hit where I'm coming from right on the dot. The executable is doing exactly what it's supposed to when this phenomenon happens. How would the engine know if the player is trying to use Arch-Vile jump or Rocket Jump to get to somewhere they shouldn't be? Likewise, how would the engine know what properties the sector is meant to change to? -Wagi 69.51.157.227 19:54, 16 January 2008 (UTC)