For now, the Game.FastTravel() solution works better, at least in my opinion. Hopefully we'll get some tools to change the size of the collision mesh in the AutoLoadMarker01.nif file.Nifskope doesn't seem to be working for that... yet.

I'll put the time change down to some strange form of relativistic time dilation...

If only you could force the PC to sleep ... Then you could quite convincingly put it down to "exhaustion" after performing the "magic" necessary to use the system.

I guess you could use a Lighting Effect to make it appear as though the PC was waking, or its vision clearing (there is some very funky stuff to be done with ImageSpace and Lighting) instead of actually sleeping? Similar, I guess, to how the Power-Word-Walls work, when you learn a new Phrase ...

Then a simple "help-text" message to say that "You have woken from your Teleport and some time has passed" (just a print to screen, so it isn't shoved in the Player's face every time) ...

So I have been putting my teleports against rock formations and cliffs. This allows me to use the AutoLoadDoor by pushing the majority of the mesh inside the cliff. So I can get pretty close to the teleport before it fires. Not an ideal solution, but it works for now.

I've also created a teleport room in an interior cell, and placed the teleports using a similar principle, however the roon is huge. Huge enough in fact to place a couple of Dwemer elevators inside, so I'll use that to create multiple levels and also to connect to the outside world at some, as of yet unknown, location.

If someone could shrink the \meshes\autoloadmarker01 mesh in the X and Y directions by a factor of 0.3 (leave Z as-is) I would be eternally grateful. I've tried this using Nifskope without success (the door still triggers at the original distance from the teleporter), and I've not been able to make the Blender importer work.

I don't understand why you couldn't just do this with your trigger:

Scriptname SC001Teleport extends ObjectReference ObjectReference Property TeleportDestination  Auto Event OnTriggerEnter(ObjectReference akActionRef)    if (akActionRef == Game.GetPlayer()|| ((akActionRef as Actor).IsPlayerTeammate())	    akActionRef.MoveTo(TeleportDestination)    EndIfEndEvent

That would move both the player and any followers they had

because your followers would not be inside the trigger at the same time as the player, hence akActionRef would never be the follower unless they unwillingly walked into it on their own by mistake.

even if you could run a "get" function instead of the "is" boolean, it would grab your followers that are sandboxing (if you set them to "wait" or are using a follower relax type mod). of course you could run additional conditions to query for these situations, but why bother? what is the point of creating a large function when the same can be achieved with a door activation (does not pass game time) or a fast travel (passes game time)

tuche' I guess I just naively assumed that if you walked forward and dissapeared, that your follower would walk forward as well

unfortunately, when the player enters the trigger and the load screen appears, the cell and all 3D inside it is unloaded, so even if the game tracked follower's positions in the world, they have no loaded 3D model to trigger a collision-based trigger box. load doors on the other hand are a different story, since it traces the path back to you using navmesh, which is why the door trick is the most reliable way of teleporting, but is limited to only placing you and your followers on the teleport marker (you cant specify your destination otherwise, unless you physically move the door's teleport marker in the CK, but for most teleport applications, the teleport marker on the existing door is more than enough)

For anyone who might be interested, I have put a proof of concept mod on the Nexus @ http://skyrim.nexusmods.com/mods/18509

I think with the additional knowledge I've gained from playing with the construction set that I finally understand what is being said here. Will give it a try tomorrow...

Successfully hooked up a trigger to a door this morning. I bow down to Amethyst Deceiver, this solves all of my issues with the trigger area being too big for the teleport platform! If I can sort out the messaging part (and this should be easy), I can implement my original teleporter network concept. Keeping my fingers crossed...

...and the followers don't teleport with me. Now I have two doors linked in the standard way. Using the door teleports followers with the player. Using a script to activate the door - Door.Activate(Game.GetPlayer()) - doesn't teleport followers. What gives?

Could it be that I'm using If (ObjectRef == Game.GetPlayer()) to determine if the trigger is being activated by the player?

Either you are correct (and so I can't think of a fix).

Or it is to do with the abDefaultProcessingOnly Flag (which is Off by default): http://www.creationkit.com/Activate_-_ObjectReference

(Though reading the description of that ... turning it On won't help you either ... Might be worth testing that behaviour anyway, though?)


I'm surprised that it does just work by default ... So something a bit wonky with how Activate is implemented in papyrus as opposed to game functionality, it seems?