142
edits
Difference between revisions of "Talk:Door"
→Random teleports
DavidJCobb (talk | contribs) |
DavidJCobb (talk | contribs) |
||
| Line 46: | Line 46: | ||
Verified by reverse-engineering the LE CK. [[User:DavidJCobb|DavidJCobb]] ([[User talk:DavidJCobb|talk]]) 21:22, 30 June 2024 (EDT) | Verified by reverse-engineering the LE CK. [[User:DavidJCobb|DavidJCobb]] ([[User talk:DavidJCobb|talk]]) 21:22, 30 June 2024 (EDT) | ||
:Additional reverse-engineering: | |||
: | |||
:First, let's define some terms to make this easier. When the player interacts with a door ref whose base form has random destinations, that door ref — the ''source door'' — needs to be linked to a ''destination door''. The random destinations in the base form's list are ''destination spaces'' i.e. worldspaces and interior cells, and the game must find a suitable destination door from a randomly-selected destination space. The ''source space'' is the worldspace or interior cell that contains the source door. | |||
:When two load doors ''A'' and ''B'' are linked, we say that ''A'' is ''B'''s ''opposing door'', and ''B'' is ''A'''s opposing door. Lastly, every functional load door has a ''teleport marker'', which is a piece of data specifying the position and rotation that an actor should arrive at (in the same space as the opposite door) after traveling through the door. Teleport markers are not refs; they are named for the visible marker you see in the Creation Kit when fiddling with load doors. | |||
: | |||
:'''The process for linking a source door to a destination door is as follows:''' | |||
:# Pick a random destination space. | |||
:#* If we've already tried this destination space, re-roll until we've tried all spaces. | |||
:#* If we've tried all spaces, give up on finding a destination door, and don't link the source door to anything. The algorithm has failed. | |||
:# Search all doors inside of this destination space, stopping on the first eligible door we find. (If it's a worldspace, we search its persistent cell.) A door ref is eligible to become the destination door if it meets these requirements: | |||
:#* Not in the same space as the source door | |||
:#* Not deleted, disabled, or [[Destructible Objects|destroyed]] | |||
:#* Its base form also has random destinations, and one of those is the source space | |||
:#* The door is not already linked to any other load door | |||
:# If we find a suitable destination door, then link it to the source door. | |||
: | |||
:'''Failure case:''' If the game fails to pick a random destination for a randomized teleport door, then it shows the value of game setting ''sRandomDoorTeleportFailureMessage'' as a notification. The default value of that setting seems to be, "This door leads nowhere." | |||
:'''Success case:''' Link the source door to the destination door. By default, given two randomly-linked doors ''A'' and ''B'', door ''A'' will have its teleport marker positioned directly in front of door ''B'', at a distance of ''fRandomDoorDistance'' units (or, if the other door is an automatic door, at a distance of ''max(fAutoDoorActivateDistance + 100.0, fRandomDoorDistance)'' units instead), and vice versa. This should generally work fine, but in order to allow for positioning teleport markers more precisely, the game ''does'' support the <code>REFR/XRTM</code> subrecord. This subrecord allows a potential destination door to specify a separate marker ref; if the door is randomly linked (i.e. if it's a source door or a destination door), then the position and rotation of that marker ref will be copied to serve as the position and rotation of the opposing door's teleport marker. | |||
:[[User:DavidJCobb|DavidJCobb]] ([[User talk:DavidJCobb|talk]]) 22:53, 30 June 2024 (EDT) | |||