Difference between revisions of "Talk:Slime trail"
From DoomWiki.org
(Slime trails, or "why do the floors and ceilings stretch tward my position when I noclip outside of a level in Doom?") |
|||
| (11 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | 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 | 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) | a linedef (a wall, border between two objects, etc) | ||
| Line 7: | Line 7: | ||
and face it. | and face it. | ||
| − | + | Anyway, a slime trail happens when there is | |
a "hole" in a linefef that seperates two or more | a "hole" in a linefef that seperates two or more | ||
sectors (a.k.a rooms, non-sprite objects, etc..), | sectors (a.k.a rooms, non-sprite objects, etc..), | ||
| Line 13: | Line 13: | ||
hights or lighting are different between the two | hights or lighting are different between the two | ||
sectors. | 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? [[User:Ryan W|Ryan W]] 21:26, 6 March 2007 (UTC) | ||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
| + | |||
| + | Is a slime trail still a slime trail if it's not visible unless somebody walks in front of it [https://doomwiki.org/w/index.php?title=News_board&oldid=48215#Found_a_slime_trail_in_Ultimate_Doom_E4M1]? [[User:Ryan W|Ryan W]] 19:24, 24 September 2008 (UTC) | ||
| + | |||
| + | :You mean like "[[Wikipedia:If a tree falls in a forest|If a tree falls in a forest and no one is around to hear it, does it make a sound?]]" <small>[[User:Who is like God?|Who is like God?]] 12:27, 30 September 2008 (UTC)</small> | ||
| + | |||
| + | ::''"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."'' [https://groups.google.com/group/rec.games.roguelike.angband/browse_thread/thread/8ae85f6602e051dc#] So I guess the answer to that question is [[Wikipedia:Observer effect (information technology)|"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. [[User:Ryan W|Ryan W]] 15:31, 30 September 2008 (UTC) | ||
| + | |||
| + | [https://www.doomworld.com/vb/doom-editing/47001-reliable-nodebuilding-for-large-maps/ Apparently], the presence/absence of certain slime trails depends on the numbers of the adjacent sectors (!). [[User:Ryan W|Ryan W]] 21:26, 16 July 2009 (UTC) | ||
Latest revision as of 02:18, 14 December 2019
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)
Is a slime trail still a slime trail if it's not visible unless somebody walks in front of it [1]? Ryan W 19:24, 24 September 2008 (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." [2] 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)
Apparently, the presence/absence of certain slime trails depends on the numbers of the adjacent sectors (!). Ryan W 21:26, 16 July 2009 (UTC)
