Hi fellow modders

For some time I'm having this dilema, should I force some references or not? In the wiki it states that:

http://www.creationkit.com/Reference_Alias


But when you look to Bethesda quests, plenty of them use this forced system, another problem are all things not actors, like for example triggers boxes. In order to use Location Alias Reference one should create plenty of Location Ref Type's because if for example one have 2 trigger boxes in the same location, both need different Location Ref Types or else alias fill is going to fail.

So, should one use forced reference for other things that aren't actors or does it consume too much memory? Or should everything be done with Location Ref type?

To force or not to force, that is the question.

Sometimes I think all of this sort of stuff just adds more complexity to modding, when the effects of "not doing it right" are not as bad as it might appear they are.

I guess, technically, you should only use a persistant reference when you are going to make lots and lots of (future) use of that character/alias. If it is just a brief walk-on-part you should probably use Properties, instead of aliases

... but, like I said, it will probably make so little difference to saved-game sizes - and compatability with other mods/vanilla - that it isn't really worth all of the worry (in my opinion). Especially if it prevents people releasing their stuff.

I never thought about that to be honest. I always use ref alias and link to a specific actor or specific reference.

Not sure if it matter but I've started actually stopping Stop() my quests when they're complete. So that aliases are cleared. Whether it makes a difference I don't know lol.

Don't properties for actors also make them persistent?

From everything I've been able to tell, this is what you should be doing - calling stop(). A forced reference the way that wiki page describes is only persistent while the quest is running. I've verified this countless times during the work on Open Cities. As soon as the quest is shut down, you can make all the changes you want to a reference and they'll show up as expected. Not before.

Yes. Setting something as a property in a quest makes it eternally persistent, even beyond the conclusion of a quest. So I think the wiki page may have this backward. You can't move any records that are used as properties in ANY script, the changes simply won't take.

Not exactly true -- you can edit properties, but you have to change them as though you were changing a script's variables.

(SomeQuest as SomeQuestScript).ThisProperty = ThisOtherProperty

You can do that for pretty much any script attached to anything (quest, reference, alias, etc.), but it'll be really tedious if you intend to make a bunch of changes to vanilla properties.

Now, if you mean changing the properties by editing the quest, alias, or whatever itself, those changes won't take effect if the quest's been started.

Arthmoor is not talking about properties in the script, he's referring to the world objects the properties point to. You can't edit any of them because of the persistence flag being set, so any changes made to them simply won't happen.

What Thomas said. I was referring to actually moving the object reference the property points to. Anything assigned as a property in a script is permanently persistent for the life of the game, whether or not the quest was started.

A forced reference alias only asserts the persistent status while the quest is active. It's a MAJOR difference, and most likely the reason Bethesda violated their own advice, because once the alias is emptied, you can move the target around freely. Which means the persistence is lost, and therefore NOT consuming the memory they say it is.

Just for the sake of my poor old brain ...

• An actor assigned to a property in a quest makes (the reference to) that actor persistant "forever"
  
• An actor assigned as a alias (forced only???) makes (the reference to) that actor persistant only while that Quest is running

(Which is backwards to what the dear old wiki says, as noted by Arth and others, up above).





If this is true, the wiki needs an edit ... because world+dog will almost certainly be getting it backwards

Correct, and it doesn't actually matter what kind of alias it is. An alias is, at least as far as I've seen, always temporary unless the quest is one that never shuts down.

Thanks for all the replies.

Tell me something then, when a quest is completed should I stop it anyways?

A completed quest will still show as Running if you use an SQV command.

Wow, that is some important news. So, in order to not mess with player notifications (quest completed, etc), when is the best moment to stop the quest? In the quest stage tab? Won't this mess with notifications and stuff?

Thanks.

I just thought of stopping because I've started using quests that run a script on the Player as an alias, and also started using GetQuestRunning conditions. In the final stage for the completed quest, after all my scripts, I just use Stop()

This then stops the quest, and removes any aliases and stuff. That's what I've found anyway.

Ok thanks, I have to do some tests so I find the perfect time to stop a quest.

That's the best way mate just play around with it

Usually the best place to call stop() is in your final stage where you notify the player that everything is over and done with. Something not even Bethesda did in all cases.

Does stopping a quest in the same quest itself do anything odd? That just makes me think there would be some odd conflict...

I see, but will the player receive the end notifcation anyways? Thanks.

The very last, last, last line of script in your Quest should be a Stop()

(note: depending on your quest design - multiple paths through it - you may need more than one Stop() ... )

You can set a stage as the Completed Stage, which is where your player gets his final "thanks for playing" notifications. So the Stop() goes in that stage (at the end of any other scripting in that stage)

Yes, so long as you have the "complete quest" box checked it will notify them that it's been completed and mark is as such in their journal.

A lot of the ones Bethesda left open don't need to be either and as they're found I'm closing them off in the USKP. Saves memory that way.

Thanks for the info guys, I appreciate it.