Alias perfectly filled, not filled though if added or moved in quest runtime.

[MOB2]

Hi, I am reposting my question here because I probably got the wrong forum.

I will try to explain my problem. I am creating a quest that is triggered by an onread event (a note) and proceeds smoothly through several stages and dialogues.

It's a “run once” quest, NOT “Start Game Enabled.” Currently there are about 30 aliases, almost all “UniqueActors” with “Persistent location,” plus a few specific references and a few “Allow Reserved” and “Reuse” aliases.

Actually, if I start the quest in game, all the aliases are filled and then the respective quest markers appear on the map. But if I add another alias or move an existing alias by changing its location in the Quest Aliases Tab and start the game from a save after the quest start, these new aliases (and the moved ones) are no longer filled and screw up the quest for me.

It took me a while to figure out that if I start the quest from the onread event, actually all the aliases are filled, because I strictly followed what was said on the page about Quest Aliases Tab in the Wiki.

What puzzles me is that as I have to continue the quest, every time I add an alias or move it, I always have to restart the quest in game from the beginning.

Is what I wrote above correct?

I also tried as Location Alias Reference. Nothing, it's a curse. Either I start the quest every time from the beginning, or every time I add new Aliases or move them the quest goes screwed up.

But I wonder, if while writing a quest I think of changing something, adding dialogues, new NPCs, new locations, each time I have to do the whole quest all over again?

Of course, I am only talking about the planning and testing phase. Once the whole quest is completed I will certainly test it from start to finish, but for the whole time of the design I really have to test it entirely each time, even if it involves numerous dialogues in different locations even on the other side of the map, different followers, some combat, and so on?

The only alternative I see possible would be to create several smaller quests, linked together, meaning that when one ends the next one begins. I've done that once before and it worked, but it made sense there because it ended one story and started a different one, whereas here it's just implementing different stages of the same story.

Then there would be other problems, such as manipulating other NPCs (not the dialogue one) through script fragments and/or papyrus fragments in quest stages, like having two or three NPCs follow me around, having them attack me (this just doesn't work, maybe I raised the NPC disposition too much), and so on. All things that in Morrowind I did easily through dialogue, and in Oblivion with some ease.

Thanks for your attention

Edited May 26 by MOB2

[Qvorvm]

There are number of strange behaviors in the quest/alias mechanism.  I do not believe I have encountered this one before though.

If by "changing or moving" an alias, you mean using ForceRefTo, I strongly recommend you do that only on a quest that is started and on an alias set to "specific reference: None".  All other combos have strange corner cases, often involving the quest not restoring into the same state after saving and reloading.

If you want to populate your "specific reference: none" aliases when the quest starts up, do it in the "OnInit" event, under a "isRunning()" condition.

Perhaps something like this:

ObjectReference[] property initialAliasRefs Auto

event OnInit()
  if isRunning() && getStage() == 0
    int i = initialAliasRefs.length
    while i
      i -= 1
      (getAlias( i) as ReferenceAlias).forceRefTo( initialAliasRefs[i])
    endwhile
  endif
endevent

 

Edited May 26 by Qvorvm

[MOB2]

I thank you, but I am not yet so deep into papyrus to implement what you suggested.

Perhaps I should correct what I wrote. I actually checked further and noticed that the only not filled aliases are those added to an already started quest and placed within the alias list, in between already filled aliases.

This leads me to think more about the initial principle found in the wiki about the need to plan a quest in advance, before starting it. It is correctly said in the wiki that you must create stages and objectives first, but I would humbly add that you should also create all aliases in their perfect order of appearance first.

In the case given above, it was a quest with 30 aliases and as many stages, which was completed with a ondeath event by starting the next quest. Unfortunately, as a true newbie, I started with two or three aliases, just to see if it worked, adding more later, but I would say that this is not a good practice. I had to learn in the field the importance of planning about aliases as well.

The next quest I have already divided it into two interconnected ones, and I think I will stay on 10 aliases per quest at most, given my initial level of modding regarding quests.

Edited May 27 by MOB2

[Qvorvm]

If you are not using "ForceRefTo" from papyrus, then what I wrote does not apply.

Perhaps then, you are trying to develop your mod and test it on a running game without starting new games.  You would then notice that new aliases that you add to the quest do appear when you reload your save game, but that the newly added aliases are unfilled no matter how you configure them in the CK.

That's the normal behavior of quests and aliases.  Aliases are only filled as part of starting the quest, even if you configure the alias (in the CK) to be filled with a constant value.  Your options do reduce to (1) create all your aliases from the getgo, (2) stop/start the quest to refill the aliases and/or (3) use papyrus code to force fill the aliases.

[MOB2]

Apart from the first obvious option, I am very interested in the other two, if you would kindly explain them to me.

The console command that seems useful to me in this regard would perhaps be “resetQuest <quest ID>”, but the question is: would resetting the stage to 0 fill all aliases? However then it would be necessary to redo the whole quest from the beginning, so that doesn't seem like a useful solution for me.

Aside from “setStage,” which can still start a quest, is there no command in the console that can stop and restart a quest at the stage it is at, without returning it to 0? Are "StopQuest <quest ID>" and "StartQuest <quest ID>" useful for this purpose?

In papyrus there are the functions “MyQuest.Stop()” and “MyQuest.Start()”, maybe I could put them temporarily in a stage, just so I don't have to redo the whole quest from the beginning. Would it be helpful to fill in all the aliases?

Thanks for your attention

Edited May 27 by MOB2

[Qvorvm]

The console commands "startquest" and "stopquest" are indeed useful in debugging.  However, I usually don't use stages, so I do not know if the stage number is preserved (I think it is, but there may be other implications I cannot fully describe).  Depending on how you configure your quest, using "setstage" after "startquest" can simulate advancing through the quest to bring you back to a point where you can continue testing.

Using papyrus is equivalent to the console but has the advantage that you can automate complex sequences.  You can also use "ForceRefTo" and other quest functions to affect the quest in ways not easily accessible through the console, but all that requires some familiarity with programming.  Not everything is doable with papyrus, so that's also not a panacea.

Having to start new games to test things is an unfortunate reality in many occasions.  Look for ways to artificially advance your quest so you don't actually have to actually play it through to get where you need to test things.  Console "setStage" is often useful in this regard, but you do have to specifically plan for that, and you often need some scripting.

Without knowing more about your quest, it's difficult to give more specific advice.

[MOB2]

Well, I tested both resetquest and stopquest + startquest. In no case are aliases filled, in fact all aliases are unfilled (including previously filled ones).

Therefore, the only option remains to start from the save where the quest begins (onread event) and eventually proceed with "setstage QuestID" 5, 10, 15, 20, 25, etc. (to properly update the journal) until you get to the stage to actually test.

Thank you really for the help and suggestions, I hope to get to a deeper understanding of papyrus, also because I would have other little problems, "such as manipulating other NPCs (not the dialogue one) through script fragments and/or papyrus fragments in quest stages, like having two or three NPCs follow me around, having them attack me (this just doesn't work, maybe I raised the NPC disposition too much), and so on (all things that in Morrowind I did easily through dialogue, and in Oblivion with some ease)."

[Qvorvm]

6 hours ago, MOB2 said:

Well, I tested both resetquest and stopquest + startquest. In no case are aliases filled, in fact all aliases are unfilled (including previously filled ones).

Earlier you had said you set your quest "run once".  If you do that, startquest will not work a 2nd time.  In those cases where all aliases are unfilled, you should also note that the quest is not running, even after startquest.

[MOB2]

1 hour ago, Qvorvm said:

Earlier you had said you set your quest "run once".  If you do that, startquest will not work a 2nd time.  In those cases where all aliases are unfilled, you should also note that the quest is not running, even after startquest.

You are right. I realized afterwards that after stopquest the quest never restarted. I think the only solution is to start from the save where the quest begins by proceeding with setstage.

By the way, I noticed that there are quests that keep running even if they are completed. Is that right? I guess with “stopquest” it could be possible to stop them, but does it make sense for them to keep running?

Edited May 27 by MOB2

[Qvorvm]

It makes little difference whether an idle quest is running or not, except if you have objectives for the log, or if you flag actors in aliases as reserved, protected, essential, quest item, etc.  It can make sense to keep them running, or be detrimental to other quests.