Talk:Error message

Should never occur

I have the impression some could occur by hacking the excutable (this is most relevant with DeHackEd, as direct hex editing is nonstandard), or with the kind of overflow that the engine does not make checks against (because data events are dependent on gets deleted). I think I've seen "P_RemoveActivePlat: can't find plat!" with some intercepts overflows. Some demos that have these overflows (and don't cause a crash) may provide examples. Who is like God? 21:49, 10 April 2008 (UTC)

It is possible that some of the errors I have marked that way could occur in event of memory corruption or other undefined program behavior; that's one reason I have them listed -- they are reachable code, and any reachable error message could technically occur if the program state is just right. I based the "should never occur" on the flow of execution assuming that everything is behaving in a defined manner. An intercepts overflow overwrites a good chunk of memory, and thus introduces bizarre emergent behaviors.--Quasar 00:01, 11 April 2008 (UTC)

Ah, I see, though as some errors specifically refer to the two things mentioned in the intro (network instability and memory corruption), such as "Z_Free: freed a pointer without ZONEID" or "consistency failure (%i should be %i)", some readers may be lead to read it as a general "from this to that" referring to the nature of the errors, and not that some errors could come of general instability producing unpredictable results. Great work with the comprehensive list and descriptions, by the way! Who is like God? 14:32, 11 April 2008 (UTC)

Wait, that was Quasar?  Now we're getting somewhere!  Best "initial commit" of an article ever.    Ryan W 02:25, 13 April 2008 (UTC)

Adding Flats Incorrectly

I don't think that the description of the W_ChacheLumpNum error is entirely accurate. It says that it will happen if flats are added incorrectly, then it will cause an error. As far as I know, even if you do everything perfectly fine, the PWAD will still cause an error (This works perfectly fine if the flat replaces one already in the IWAD). If I recall correctly, this is why they had to use DeuTex and such in order to run wads with Flats. -Wagi 69.51.157.227 18:20, 6 May 2008 (UTC)

Earlier versions worked like you say, and then with later versions (not sure exactly which was the first to allow new flats) a good number of users didn't know of the change, and continued to either replace flats or set the wad up to require DeuTex. If you place flats (with new names) between FF_START and F_END the engine uses them without problems. Thus, wads that "require DeuTex" due to flats, don't really need it; renaming FF_END to F_END with a WAD editor is all that's really necessary (although you might still have to patch up with sprites, if sprite replacements are included). Who is like God? 18:39, 6 May 2008 (UTC)

R_MapPlane: %i, %i at %i (Should not occur.)

This phenomenon can already be widely known among the Doom community, but I couldn't find any wiki coverage about it. I describe it here so that you can test it out if you like. (I used vanilla Doom II, v.1.9)

This error can be triggered (deliberately) in MAP27: Monster Condo (Doom II). The level has a type 10 door (sector 11) that closes when thirty seconds have elapsed from the startup. If the player prevents the door from closing by standing in the sector, the door will reopen as usually but its ceiling will pass the level of the adjacent ceiling and go on rising. If the player allows the ceiling of the door rise high enough (by waiting about two minutes) and then moves into the sector or out of it, the game will crash and display the error.

I got different combinations of numbers but the location (third) value was often either 201 or 255. There, however, was one 211 too. Could the phenomenon be worth adding to the article or is it too trivial? --Jartapran 23:25, 11 August 2013 (UTC)

That sounds like the Numeric overflow crash in tall areas, though it *usually* fails in R_MakeSpans, it would be equally possible for it to fail in R_MapPlane. That one glitch can cause a number of different crashes because it writes bad values to the clip arrays which are used by both columns and spans. --Quasar 14:32, 12 August 2013 (UTC)