Difference between revisions of "Talk:Error message"

Revision as of 13:20, 6 May 2008

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)