I've been looking at the problem of resuable design in the Creation Kit. As a rule, I like to create a test cell when I mod. There I can experiment and work out how I'm going to achieve my aims, and test the resulting code with a minimum of interference from other game entities.

That approach works well, but it has a drawback. On my current project I have a large quest with lots of aliases and packages and complex dependencies between them. Now I find myself faced with a dilemma: Do I re-purpose my test quest to handle the "live" actors, and destroying the test setup in the process? Or do I replicate the quest, including the web of dependent aliases and risk many subtle bugs due to missing a link somewhere.

Ideally, I'd like to be able to duplicate my test quest, and change one alias and have everything else just work. It turns out that there's a lot of support for this sort of design in the CK. It's just not always obvious what it's for and how it's supposed to be used. I'd like to share some of the ideas thoughts I've had on the subject, and maybe see how some of the others on this forum have approached the same problem.

The project at hand is a follower mod with a twist.

A fellow called Welynn has moved into the Drunken Huntsman. He has three followers who are essentially automata. The can perform useful functions and obey some commands, but that's about it. To control them, each follower has a Token which they will follow and a tracker item which if equipped will allow their location to be divined by means of a quest marker. They also each have a backpack with its own storage which is implemented as a chest in the test cell. There are a couple of markers that get placed by scripts for some functions where a scene would have been problematic.

(I also feel obliged to point out that I'm developing this on LoversLab, so forgive me if I sound a little vague on the fine detail in places ).

Reuse aside, it's a good idea to minimise the use of forced references. One way to do this is with a Root Marker. Take an x-marker, and then take your actors and link them to the marker. Now you can force the x-marker into an alias and then pick up the actors using "near alias" and a condition based on GetIsId or maybe HasKeyword.

This has the advantage that if you have a copy of the quest running on a different set of actors, you can have a separate root marker and point the new actors at that. Then the quest just needs to change one forced reference. Admittedly, you still need to set the actors pointing at the marker, but at least you can organize these spatially and see the links in the render window.

My first cut at a control quest for the followers involved giving Welynn and his charges each a forced alias in a quest. But I also needed copies of the actors in the test cell. (Multiple copies of unique actors with follow packages yields strange behavior). Using this approach simplifies things greatly.

Each of Welynn's followers has an associated token, a tracker, a marker and an inventory chest. My initial approach was to force-ref the chest and create the other items as aliases in the container. That avoids some force refs, but still has problems. If we have a follower in Alias F, then we also need aliases called F_token, F_Tracker, F_Marker and F_chest.

This in turn means that all the packages the followers use have to have a variant for each follower, with the targets changed to reflect the alias they need to follow.

The way around this is to link-ref the actor to that actor's accessories. Each link needs a keyword: you're only allowed one link per keyword plus one non-keyworded one, and the non-keyword link needs to be to the root marker. So we have kw_token and kw_tracker, kw_marker and kw_chest.

This means I can largely do away with the aliases for all these things. The marker and token are available to packages via link-ref and keyword, scripts can find the references via GetLinkedRef and if I do need anything in an alias I can always force it in an initialization script.

Also, again, I can lay the whole thing out spatially. My test cells tend to be free-floating slabs of Imperial Floor floating in the void and connected by walkways. So I can stand Follower F on a slab and nearby I can arrange F's chest, and marker as well as a table with the token and tracker items. All links are visible in the editor and it's easy to see if I missed something.

Notice that all of this still depends on the root marker. The root marker points at the actors, and the actors at their accessories.

One side effect of having multiple instances of actors is that it messes up dialogue conditions. I have a unique, essential "Follower F", and I also have a "Generic F" which can be found in the test cell in multiple locations. The trouble is that the condition "GetIsId" works on the base object. If it works for "Follower F" then doesn't work for "Generic F". So I end up needing to either double the conditions on most of my infos, or else have separate dialogue quests for test and live.

What I plan to do (this is tonight's project) is to define a "Base F" actor and have the live and generic ones inherit from that actor. I can tweak stats on both of them while still consolidating most of the info in the base actor. And hopefully GetIsId on the base actor will recognize both variants. (If not there's always giving each of the three follower types a keyword and conditioning on that, but I'd sooner not since the doesn't limit the voice types used)

The big payoff here is to have most if not all of the dialogue in a common quest. There may be some issues with quest stages, but that should only apply if someone jumps back and forth between the "real world" and the test cell, so it's unlikely to cause problems in practice

The other tool in the arsenal for this type of work is Location RefTypes. This is the basis of many a radiant quest and lets you add information to established areas in a non-invasive manner.

In my case, I plan to have a series of radiant quests that send the player hither and yon in search of an Argonian named Seldom-Still. In each case I want a town or city, a primary contact, a secondary contact and a fallback. The primary knows where Seldom-Still is, the secondary doesn't but can point the player at the primary, and the fallback can step in if the primary has been killed for whatever reason. So you can define location ref types for each of these and add them to the location information. Then the quest can pick them up based on location.

My aim here is to set up a quest in test mode, and to have it depend solely on a single forced reference. This will let me develop the quest in isolation, test it and then when it is ready, duplicate the quest and change the root marker to one pointing at the "live" actors. I can then continue to develop the test version and repeat the process for the next release.

Looking at the link-ref mechanisms in particular, it seems likely that this is how Bethesda intended these features to be used. I'll let you know how I get on.

And my apologies for those cases where I'm teaching Granny how to svck eggs