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)