Before I get too much farther in making this mod I've been wondering whether I am attacking it from the right direction.

Should a mod like mine that has one main quest, and many smaller quests that are required to complete, be separate or all put into the SM and combined?

Would it actually simplify things if they were all put under one roof?

Or is it mostly user preference?

Thanks!

If the side quests need to be completed in order to do the main quest, then putting them in one file is probably the easiest way to do it.

Even if the side quests are completely standalone it's probably fine to put them in one file along with the main quest. I made a large quest mod for Oblivion with one main quest and tons of side quest that were completely unrelated to that main quest, and I put them all in one .esp. Nobody really complained.

Hm. I've assumed you were talking about having separate quests rather than separate esps, but tell me if I'm wrong.

I think that multiple small quests is the best way, in nearly all cases. Here are some possible reasons I have thought of:

Alias lifetime
Aliases should exist for as little time as possible. Aliases applied to vanilla actors/objects will be making those behave in ways other quests don't expect, so for compatibility you want to stop that as soon as you can. But even aliases applied to your-mod-specific items are better gone, once they aren't needed, so that the game doesn't have to run their scripts any more.

Dynamically assigning things
Popping an actor into a shortlived alias is much the easiest way of giving them a temporary package or script or ability. And keeping track of when they've got these items is simple if it's confined to a quest.

Events
To respond to game events you need to put a quest in the relevant Story Manager event node. Using events rather than registering for updates allows you access to the event data. That's useful both for creating aliases only at the point you need them (From event), and for reducing use of properties (which may be persistent in a save game after your mod has finished).

Complex conditions
Conditions are great as long as they're all ANDs. But it's very tricky to set more than two conditions on an item, of which at least one is an OR, and get it right. The story manager branches and nodes help you set conditions in stages and avoid this problem.

Mental clarity
Well, perhaps this is just me. But I find it much easier to keep track of what's happening in my quests if I make them as modular as possible.

Bethesda do it
The vanilla quests are all very modular. I think this might be because Bethesda know what they're doing.

I'm referring to either using the Story Manager or scripting/conditionals.

Sorry, I should have posted a more descriptive question

"Dynamically assigning things"
That's something I hadn't considered or read about. Seems complicated, no?

"Events"
I've been using the Story Manager for a couple of quests but stopped because I can't find enough information on which type of quest would require the different types of Events.

The two events I've used were within tuts that show the steps involved.

If you have several quests how can you put them all under one event type or do you have to?

Here's a screen of how I have two quests in the SM: http://www.freeimagehosting.net/m7gsy

in regards to aliases, the lifetime (persistence) = forever regardless if the quest is finished or not

Unless you add a script to disable and delete, right?

No. Aliases aren't even forms. They can't be deleted, you can clear the object they are pointing at and you can also delete any object that has been pointed by an alias, but there is no method to delete an alias.

Ok...does this mean that aliases should be used sparingly?

I mean...I have a couple dozen already and I'm just getting started really.

Is it really a big impact?

No, it's easy with aliases, I do it a lot. I often want to change the way NPCs behave according to what the player is doing or has done, and don't want to have to set them all up with conditional packages from the start.


You can but you don't have to. The main reason to put them under a particular event is that you need to react to that event and you want to access the event data for it - for example if you want to do something every time the player kills something, or goes up a level, or enters a certain area. The main reason to start quests with script events is that you want to be able to pass data to them when they start up.

One might also use the ChangeLocationEvent for a quest that ought to start shortly after something else has happened, but doesn't need to start immediately, or after a set update time.

As for the persistence issue: you should certainly listen to Amethyst on this subject rather than me. I rather gave up hope of avoiding it after reading the http://www.creationkit.com/Persistence_(Papyrus), and learning that script properties make references permanently persistent. How else should we refer to things?

Oh, another reason to use small quests: you can fill their aliases with Create reference to object, and Find matching reference with conditions, which can be much more convenient than the Papyrus FindClosest... and FindRandom... functions.

Great response guys

I think I understand it a lot better now.

I'll probably continue on my current track and use the SM for times when I need to do so.

You guys are great...thanks!

using GetLinkedRef() is one way to cheat a property having to be filled. but you may find that calling getlinkedref sometimes returns errors, and in that case you probably need the ref to be persistent depending on what it is you are trying to do and when (and where). in which case, use a objref property instead of calling linkedref. but for most cases, getlinkedref works great, and is also a great way of being able to query in a condition function in place of a variable in an external script


one such example:

i have a quest that needs to access whether akSpeaker's script has a certain value for a boolean property. but since the script is not part of the quest, you cant run getvmquestvariable, and vmscriptvariable also would not work.

so instead i linked an xmarker to the reference, and in the reference's script i can enable/disable getlinked ref in place of a boolean.

so that in the condition function of the topic info i can query whther akspeaker's linked ref is enabled or disabled, without ever needing to access akSpeaker's script. a bit of a complicated setup, but in my case there wasnt really an alternative, and getlinkedref really allowed that to work

Oo, interesting idea! Thank you.

i should mention though, xmarkers are usually perma-persistent by default, so use them sparingly... although a single xmarker is an incredibly miniscule performance tax, but it is a flagged perma-record regardless, and should be treated as such. at the very least its a lot less tax burden than a perma-referenced actor

the getlinked trick really comes in handy if the xmarker is already being used for something, such as a placeatme or enable parent whatever, then you essenttially get it for "free" since it is mooching off of persistence that would be needed regardless of the freeloading getlinked function call.

True, but only for the "Forced Reference" type of alias. The rest are all unloaded once their owning quest is terminated. It's the forced ref type that should be used sparingly. The rest of them you can feel free to go wild with, Bethesda sure did.

If I understand you correctly here.

In these instances you're using the enabled/disabled xMarker as a True/False boolean replacement for a quest you don't have access to?

It really seems to be a good idea

Can you clear an alias within it's own attached script, or does that make the game **** the bed?