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)

I'd propose renaming the article to something like "Map error with segmented raising bridges", or "raising bridges do not change sector type", something like that. --Gez 14:21, September 16, 2009 (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. —The preceding unsigned comment was added by 71.205.26.227 (talk • contribs) .

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#Bugs and Tag 667#Bugs, 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)

Deletion

The content associated with this talk page was considered for deletion, and either was deleted, or was kept after a period of discussion. This page has been retained for historical reference regarding the deletion process, or in case of future restoration of any deleted content.

Nominating per the above discussions, which include several people who actually work with the code regularly.  User:70.243.161.125 originally created the article as their sole contribution to the project, and neither that user nor anyone else has challenged Fraggle's argument of "undue weight" (as it's called on Wikipedia).  Unless someone can provide real sources establishing that it's an engine bug, I propose replacing this article with a note in E2M2: Containment Area (already there), a note in MAP12: The Factory, and a footnote to the appropriate entries in Linedef types.

• Merge and delete.    Ryan W 21:30, June 3, 2010 (UTC)
• Keep — although it is not technically an engine bug, it is still an issue where the map can behave in a way unintended by the mapper, and therefore it is useful for modders to have access to a page that explain the nature of the issue so they can try to take measures against it. It's easier to have a "neutral" page to link to (in forum discussion, IRC, etc.) rather than a small section in an IWAD map. Keeping it as its own page rather than notes in map article also avoids duplicated information and makes for a more elegant solution if the same issue appears in some PWAD maps documented here. --Gez 20:50, 26 November 2011 (UTC)

Keep

Referenced for DoomLegacy fixes. Please keep such info in a common place, not scattered about in pages irrelevant to coding and level creation. If needed to create a separate category for "level editing oddities" instead of engine bugs, that would be acceptable, but there is very little difference to use in sorting them into one category or the other, and it invites repeated sorting differences of opinion. Knowing that something cannot or should not be fixed, and WHY, is just as important as knowing the fix for a known bug. I am looking here now to make sure I do not make a fix that I will later have to reverse. —The preceding unsigned comment was added by Wesleyjohnson (talk • contribs) .