142
edits
DavidJCobb (talk | contribs) |
DavidJCobb (talk | contribs) |
||
Line 66: | Line 66: | ||
:'''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. | :'''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) | :[[User:DavidJCobb|DavidJCobb]] ([[User talk:DavidJCobb|talk]]) 22:53, 30 June 2024 (EDT) | ||
::There is a final wrinkle. The game uses <code>ExtraTeleport</code> to connect two load doors together. This data is pre-generated in the Creation Kit for normal load doors (for the purposes of this comment we'll call these "pre-linked doors"), and created at run-time (and recalled from the savegame) for doors that have been randomly linked. Notably, this means that if a potential destination door is pre-linked, it will fail the requirements listed above. However, it doesn't appear that the game checks whether a source door is pre-linked; so if you interact with a pre-linked random source door, and the game manages to find a destination door, that should end up clobbering the <code>ExtraTeleport</code> for the source door, but ''not'' the third door that it was originally pre-linked with. Potentially this could allow you to break the 1:1 mapping for doors, e.g. ''A'' and ''C'' both lead to ''B'', and ''B'' leads only to ''C''. I would not recommend doing this. | |||
::Potential shenanigans that could lead to this include: using third-party tools; or pre-placing a door, pre-linking it, and then editing its base form to have random destinations. [[User:DavidJCobb|DavidJCobb]] ([[User talk:DavidJCobb|talk]]) 23:02, 30 June 2024 (EDT) |
edits