The reason for "Slime trails" has to do with the way the engine works itself. All floor and ceiling info renders tward you (the player). It starts at a linedef (a wall, border between two objects, etc) and ends either at the bottom of the screen, or when it "hits" another linedef in it's "path". That's why the floors and ceilings stretch tward your position when you no-clip outside of a level and face it.
Anyway, a slime trail happens when there is a "hole" in a linefef that seperates two or more sectors (a.k.a rooms, non-sprite objects, etc..), or the linedef is missing entirely. This is noticible when the floor/ceiling textures, hights or lighting are different between the two sectors.
Some slime trails seem to appear only when the player is moving (e.g. looking southward through the doorway from the large octagonal room of E1M7). Why is that?
The description of Lee Killough's algorithm makes me imagine that a program/script could be written to identify a map's "hot spots" where slime trails were most likely, so that by playtesting one could compile a definitive list of trails. Presumably this is a gigantic amount of work which no one would ever do for such a cosmetic reason, but in principle, does it sound reasonable? Ryan W 21:26, 6 March 2007 (UTC)
- You mean like "If a tree falls in a forest and no one is around to hear it, does it make a sound?" Who is like God? 12:27, 30 September 2008 (UTC)
- "The problem is that the game is really complicated and gives poor feedback. You are almost certainly making lots of mistakes all the time that you don't notice, because they don't kill you."  So I guess the answer to that question is "yes, sort of". :> Actually, cph and e6y have talked about running doom2.exe in a single-stepping debugger of some kind, but I don't know if that's available to the general public. Ryan W 15:31, 30 September 2008 (UTC)