staalo18

Thanks for that hint. That approach actually works nicely!

Hmm, just a thought: Add a package to the top of the dragon's package list. That package has condition "if in illegal worldspace". Attach script fragments On Begin (disable dragon if currently enabled) and On End (enable dragon if it was disabled on Begin). I'll experiment with that thought a bit.

Yes, was thinking about that type of approach as well. But I fear that for my case it will not be as clean as in the setup you describe, because I have no control over the player's worldspace transitions. They might even use COC , and it still needs to work reliably. I can catch the worldspace change, eg via OnCellDetach() on the dragon, and there test for "illegal" Worldspaces. I could disable the dragon right away when it follows the player into a such a worldspace. But how to reliably re-enable it when the player returns to Tamriel (or Solstheim, for that matter)? And how to ensure that it re-appears at the location where it was before the initial worldspace switch? Not to forget that OnCellDetach() might not even fire if the dragon is not one of the neighboring cells of the player (ie is already detached). I might be finding answers to this, but I don't like the complexity of this approach, because it's too easy to make a mistake in the bookkeeping. I don't want a dragon to get lost through it, or to be bugged in other ways.

@Sphered Makes sense. That also matches my further testing. In contrast to what I stated earlier, also vanilla dragons switch worldspace along with the player, as long as they are flying, and Tamriel is the parent worldspace. (I must have tested with a grounded vanilla dragon). So they behave the same as my inserted dragons. Those also only switch worldspace when they are flying. When they are grounded, their Worldspace stays Tamriel. My problem with this is that sometimes my dragons are triggered to land (via script, SetAllowFlyingEx()). When the player switches worldspace while they are in the process of landing, they switch along with the player, and then land in a city, instead of where they should have been landing in Tamriel. I can catch these situations in my scripts, and re-enable flying for them. Then they will take off again and fly away from the city. But it's still breaking immersion to see them show up in the city, when they should be somewhere else. Any ideas on how to approach this?

What I learned so far: Dragons are switching Worldspace along with the player as long as the new worldspace has the same parent worldspace, AND that new worldspace has the "Use Sky Cell" checkmark activated. Ie it shares the same sky cell with the parent worldspace. Flying dragons seem to be part of the Sky Cell. Eg WhiterunWorld's parent worldspace is Tamriel, and it has "Use Sky Cell" activated. When the player moves from Tamriel to WhiterunWorld, the hand-placed dragons are moving as well. On the other hand, when the player moves from Tamriel to Solstheim (does not have a parent worldspace), the dragons do not move along. Likewise, if you uncheck "Use Sky Cell" for WhiterunWorld, the dragons also don't move along when the player switches from Tamriel to WhiterunWorld. Haven't figured out yet why vanilla dragons (and handplaced dragons in ESM'ed mods) do not follow this procedure.

I only tested with vanilla levelled dragons so far, and the answer for them is: no. When I check for Worldspace via console for such a dragon after travelling to Whiterun ("getinworldspace tamriel"), there is no result in the console (ie neither 0 or 1, just no answer returned). So I made mod I had generated a master file (ie set ESM flag in SSEdit). Then I see the same also for the inserted dragon, ie no result returned. Same with hand-placed cows.

It seems that unlike other actors in Skyrim, object references of dragons are switching worldspace along with the player. You can test this by creating a new (empty) mod: Place a new dragon (object reference) somewhere into Skyrim. Add this mod to your mod list and start Skyrim. Use the console, select the dragon (so that the dragon's id is showing), and type "getInWorldSpace tamriel". It will show 1 as answer. As soon as you fast travel to (eg Whiterun) via map, the same command will yield 0 for the dragon, but "getInWorldSpace whiterunworld" will now show 1. Doing the same with other type of actors (I tested a cow that I placed into Skyrim) shows that they remain in Tamriel Worldspace, and not switch worldspace along with the player. So this mechanism for dragons seems to be hardwired into the game engine. I am wondering what's the reason for this, and of course if there is any way to circumvent this. Ie how can I make the dragon references stay in their worldspace when the player switches to a new worldspace? Any feedback is welcome!

@xkkmElThanks much for these additional investigations and findings! I fully understand you were doubtful and needed to test yourself - that's what I usually do when I incorporate stuff I read somewhere (my real name actually IS Thomas :-)). And yes, of course, the PlaceAtMe should better be fenced by isRunning() (and while we're at it, also check for IsStarting(), which catches the case where the startup phase is not yet completed): BTW, for my mod, I probably will end up replacing the ForceRefTo() approach with dropping the ObjectRef into Skyrim and then filling the ReferenceAlias with that ObjectReference via the Quest Dialogue, ie provide it as a property value directly in the CK. Even though this is a bit more effort for me, and overally may make my mod architecture somewhat more involved, that way I am completely avoiding any risk with ForceRefTo().

@xkkmEl Yes, OnInit() fires multiple times, depending on the case. But I don't think this fact relates to the observed issue: The issue shows regardless if you check "Run Once" or not (no stages in this quest). What I wanted to say is that the (repeatable) observation is that when you use this version of OnInit() in a quest that is not "Start Game Enabled" the alias will be 100% cleared by save-game / reload-game steps. Ie the savegame is broken (BTW: as long as you continue to play after saving without reloading, the alias is still filled). I consider the other version of OnInit() to be the expected behavior (ie alias to 100% remains filled in the Savegame): I do not see a reason why those two versions of OnInit() should behave differently, so I consider this observation to be a bug in the game engine. All the rest is guesswork on my end. My interpretation is that in case a quest is "Start Game Enabled", and one of the quest's RefAlias is filled via ForcRefTo() in OnInit(), this engine bug results in random alias clears in the savegames. "Random" because I assume that the sequence in which the engine is starting the quest and firing OnInit() (which is ForceRef'ing the alias) is not defined. And in case ForceRefTo is fired before Start, your next savegame will be broken. So my suggested workaround for the (presumed) game engine bug is to not use "Start Game Enabled" in case you have to ForceRef Aliases during OnInit(), because then you do not have control over the sequence in which Start and ForceRef are handled. If you instead de-activate "Start Game Enabled", and start the quest via OnInit () (possibly gated by checking for IsRunning() ), you have control over the sequence and therefore can navigate around the bug, while still effectively starting the quest immediately. Better solution still would be to avoid ForceRef'ing the alias during OnInit() in the first place - if it's possible to delay filling it to a later function call; or if you can pass the reference directly as parameter value for the ReferenceAlias via the ESP instead.

Pulling out this old thread, because I have been having this issue as well in my mod. I think I found out what is causing it: Setting "Start Game Enabled" in a quest seems to be causing this issue in combination with filling the quest's ReferenceAliases via ForceRefTo(). In my mod, some users reported that the quest's ReferenceAliases where no longer filled after making a savegame and reloading that savegame, even if they were filled initially (before making the savegame). While for other users, no such issue. Consider a small test mod, which only contains a single quest, which is NOT "Start Game Enabled". It has a ReferenceAlias with a script (MyQuestAliasTestScript - see below) that calls OnInit(): With the first version of OnInit() the ReferenceAlias will reliably get cleared after Saving the game and reloading it (GetActorRef() == NULL), while with the second version the Reference alias will stay filled when Saving / reloading the savegame. My _assumption_ on this is that for a "Start Game Enabled" quest, the sequence in which the game engine starts the quest executes OnInit() is not determined, ie random when first starting the game with the mod. In case the engine executes OnInit() before it starts the quest, the ReferenceAliases get cleared during saving the game. While if the quest starts before OnInit() is executed, no issue. This is why the issue appears to be randomly hitting some users, while others don't ever see this. The take-away for me is: If you are filling ReferenceAliases of a quest with ForceRefTo() DO NOT use "Start Game Enabled". Instead keep "Start Game Enabled" off, and use OnInit() to Start the quest, and only AFTER Start() fill the RefAliases with ForceRefTo().

Thank you, found it. But it seems I am no longer able to post into that forum...

Ok, change the ESP version from 1.71 to 1.70 via SSEdit seems to do the trick.

Unfortunately I had let Steam upgrade my CK to 1.6.1130 when it became available in Dec. And now I realized that the ESPs I've saved with this new version won't load into Skyrim 1.6.640 or even the corresponding CK anymore... Is there a way to revert my ESPs back to be readable in the older versions? BTW, not sure if this is the right forum to ask that question - not yet familiar with the new Forum setup (there used to be game specific subforums which I do not find anymore).

Thanks again for the answers so far. As Sphered is guessing, this is to provide manual mounted dragon combat. So it needs to be highly interactive. Scripted shout will definitely solve this, so I know that I do have a solution. But I haven't given up yet on package-based shout. After some more testing it seems that it's not necessarily the change of the combat target which is the issue. Looks more that changing the package while the shout is ongoing is derailing the dragon.

Thanks, these are two good suggestions, I will try them both out. I actually had planned to use the AnimationEvent approach anyways for some other controls anyways. But I somehow had shied away from it for the shout case. Maybe because I thought that a package how it _should_ be done...