How do Mods interact with each other?

[KicklerOfButts]

This question is more on the topic of "what are the practices of the modding community" than a technical detail of skyrim, but it's the closest section I'm aware of.

 

What's the standard way of letting other mods access your scripts and use them in skyrim?

More specifically, how is it done?

 

I'm working on a framework, and I want to make sure other modders have it as easy as possible to use.

I figure it's a utility script, but I can't seem to figure out how script linking works in the Skyrim engine, so I'd like to know how other modders typically do it.

 

Thanks for any help in advance.

[AlyssaAwoo]

This Probably doesn´t answer your Question but i would search for Mods that could use your Framework or Ask Modders if they need something like that.

 

Aki

[KicklerOfButts]

Thanks for the suggestion, but I don't think that would produce much.

 

The framework in question is meant to handle/check nudity levels, and other mods can either call on functions that evaluate it or check some pre-determined bools for particular conditions.

The idea of a framework for it is that it would unify how it's done so modders can work with a baseline functionality rather than having to make their own.

 

What I don't know is the specifics behind how modders usually handle mod-to-mod interaction.

Do framework mods tend to come with a utility script to hook into? Or do they usually hook into the core? Etc.

 

How is a script made "hookable" in an easy-to-do fashion? <----(This one's probably the only real question that needs a specific answer)

 

Because it's a framework that others are meant to use as well, I want to know both how can I do it, and how should I do it.

Are there any "industry standards" established?

[Nazzzgul666]

Hmmm, i'm not a modder myself, i know a little bit about coding, though.

If you want to see how other frameworks work in general, sexlab itself, DDi and the Sexual Fame Framework are pretty well documented. Probably you can learn a thing or two by checking how they do stuff.

 

From a point of view as a user: what you should avoid at all costs is script stress. Which means, avoid redundant running scripts (maybe that answers your utility vs core question), and avoid scripts running more often than necessary, and finally avoid to run a lot of scripts (or events from one script or one script many times) at once.

 

Can't find a papyrus log anymore, but an example for the last one: i had a mod that ran a script every time a devious device was attached or removed to determine if i'm wearing any. Doesn't sound problematic? Well, i was enslaved by another mod which used the "removeall" command, and i was wearing a lot of items at this point, and the mod listening broke my game because too many scripts were running at once.

 

Again, from a point of view as user: the most advanced system to determine if somebody is naked is in Scent for Sex. The original author CPU is also known to be very capable and helpful, asking him directly if he doesn't find this thread might be an idea. Not sure if Kimy is willing to help because she's really busy these days, but i'd dare and try it... if she & CPU would be intrested in your framework you have pretty good chances it'll be a success, considering that you'd have 2 authors with successful mods which could use your framework.

[WraithSlayer]

When it comes to Papyrus script based frameworks, the simplest way involves having your framework define a quest and related quest script, which contains functions allowing access to all the features you intend to provide. Mods wanting to make use of your framework only need to set your framework ESM as a master dependency, and create a property that points to the quest script you created. As an example, this is how the SexLab framework is designed: see the SexLabQuestFramework and its associated script SexLabFramework.

 

It's also possible to access other mods without a hard dependency, but if you intend to create a framework, rather than just have two or more mods include support for each other if present, then this isn't really necessary.

[KicklerOfButts]

When it comes to Papyrus script based frameworks, the simplest way involves having your framework define a quest and related quest script, which contains functions allowing access to all the features you intend to provide. Mods wanting to make use of your framework only need to set your framework ESM as a master dependency, and create a property that points to the quest script you created. As an example, this is how the SexLab framework is designed: see the SexLabQuestFramework and its associated script SexLabFramework.

 

It's also possible to access other mods without a hard dependency, but if you intend to create a framework, rather than just have two or more mods include support for each other if present, then this isn't really necessary.

 

Been looking into this for a few hours now, and I cannot understand how it works.

Where should the core script with the core functionality be "located" in order to be accessible to the utility script? In Quest Script?

Nowhere at all?

 

What about the Utility script? Also in Quest Script?

I've had both there and defined the Utility script as "scriptname rc_util extends rc_core" but it doesn't seem to link properly and the functions in Core still can't be accessed. (rc_core is the name of the core script)

 

 

 

Why is it so complicated to link two scripts together?

Why the shit did Bethesda make this system so garbage? I've been programming for years, and I'm about to skin a cat right now! AFHNKRTGARHA

 

 

[WraithSlayer]

 

I've had both there and defined the Utility script as "scriptname rc_util extends rc_core" but it doesn't seem to link properly and the functions in Core still can't be accessed. (rc_core is the name of the core script)

 

When you extend a script, you inherit all of the parent's properties, functions, etc. While this is useful for many applications, it's probably not what you want if you're building a framework, because every mod that uses it will end up with their own independent instance of rc_core as they extend it in their own scripts. What you probably do want is just one instance of rc_core, housed within your framework, that other mods communicate with. Let's go through a really simple example of how this is done:

1. Create new mod, let's call it ExampleFramework.esm. (CK doesn't actually allow you to create masters, only plugins, so you'll need something like TES5Edit to convert it to an .ESM file)
2. Make a start-enabled quest, called ExampleFrameworkQuest, and attach an ExampleFramework script to it. This script can simply extend Quest, no need to get fancy with object-oriented programming yet while you're still getting used to Papyrus.
3. Every functionality you wish to be available to other mods, should be accessible through functions in the ExampleFramework script. Let's assume you have 3 main features in the framework, each with their own scripts Example1, Example2, and Example3. In the ExampleFramework script, you'll want to create a function to access each of those, so that mods making use of your framework only need to have a reference to ExampleFramework, not every single script your framework implements. (or to make it simpler, you could just have your entire codebase inside ExampleFramework to begin with, but as the project grows in complexity you'll probably want to rethink that approach)

That's all you need to do on the framework side. Now, on the mod side:

1. Set ExampleFramework.esm as a master dependency.
2. In every script where you want to call a framework feature, create a new property of type ExampleFramework, and have it point towards ExampleFrameworkQuest.
3. Using this property, you can call the functions contained within ExampleFramework.

That's pretty much it when it comes to making mods access a framework's scripts. It's also possible to have the framework communicate with its dependent mods, but that's more complex and we'll get to that if/when you need it.

[KicklerOfButts]

 

1. Every functionality you wish to be available to other mods, should be accessible through functions in the ExampleFramework script. Let's assume you have 3 main features in the framework, each with their own scripts Example1, Example2, and Example3. In the ExampleFramework script, you'll want to create a function to access each of those

 

This is the thing I'm having trouble comprehending.

How does a function with access to another script look like? What is the code that creates a link to another script?

 

The things I've tried, I haven't quite been able to evaluate if they work or not.

 

Say I have a script named rc_core (the script which other mods are intended to hook into) and a script named rc_checks (experimentation script while I try to get the connections to work). Both are scripts in start-enabled quest, rc_core extends quest and rc_checks extends rc_core.

 

How do I now access the contents of rc_checks from rc_core?

 

I'm the kind of programmer who learns through deconstructing a functioning example rather than building a theoretically working one.

My reading comprehension isn't the best you see. (Yes, I'm aware of the irony in being a hobbyist programmer who lacks reading comprehension.)

[WraithSlayer]

 

This is the thing I'm having trouble comprehending.

How does a function with access to another script look like? What is the code that creates a link to another script?

 

A function with access to another script would look exactly the same as any other function, no changes are needed. Papyrus isn't like most OOP languages where you can declare your fields and methods private/public/protected/etc; everything in your Papyrus scripts is always public, for ease of use.

 

Linking to another script is done mostly through CK, not code. The only code you'll see on your script is a single line with a property definition. I explain in more detail below.

 

 

 

Say I have a script named rc_core (the script which other mods are intended to hook into) and a script named rc_checks (experimentation script while I try to get the connections to work). Both are scripts in start-enabled quest, rc_core extends quest and rc_checks extends rc_core.

 

How do I now access the contents of rc_checks from rc_core?

 

Since your two scripts are housed by two independent quests, they communicate the same way another mod would communicate with your rc_core or rc_checks: via a property defined in the script, and linked through CK. A property is essentially a variable that stores a reference to any form defined in a ESM/ESP file, or any scripts defined within said forms.

 

Short tutorial on setting a property: In CK, open the quest that houses rc_core, go to the Scripts tab, select the rc_core script, and go to Properties. This window lists all the properties defined in your script, you'll want to create a new one to reference your rc_checks script, so you can access functions with it. Select Add Property, and in the new window, set the type to rc_checks (I know it's a dropdown box, but you can just write your own type in), and the name to myRcChecksReference.

 

You'll see the newly created property in the list, but it doesn't have a value yet. Select it, Edit Value, and the dropdown box will give you a list of all forms that house an rc_checks script. In your case, it'll probably be just one form, the quest you defined rc_checks in, so select it. Press OK to close the properties window, and your script source will now have the new property.

 

With the property defined and pointing towards your rc_checks script, all you need to do is use it the same way you'd use any class in programming. For example, let's say you have a function in rc_checks called CastSpellOnActor(Actor actor), that applies a custom spell to a given actor. Now let's assume you want to cast this spell on the player, from within your rc_core script. All you need to do is:

myRcChecksReference.CastSpellOnActor(Game.GetPlayer())

That's all. This is also pretty much the exact same way a mod would access your framework script functions, the only difference is they need to set your framework as a master so they can see the rc_checks quest when they're giving their property a value.

 

Note that for scripts within the same mod, you could repeat the above process in the opposite direction (set a property on rc_checks that links to rc_core) allowing for two-way communication between the two scripts, in which case rc_checks wouldn't need to extend rc_core at all, they could both just be Quest scripts. Whether you use class extension or property linking depends on what your goal is: extending is a better solution if you have multiple scripts that work independently of each other but share a common codebase, whereas property linking is used for virtually everything else.

[KicklerOfButts]

-snickt-

 

 

 

I think you misunderstood what I was saying and asking for a little bit, but your posts have helped me figure things out anyways.

I had to take some detours and leaps in logic to get there, but I've got it working now and I think I get the setup after analyzing your statements and letting them ferment in my head for a bit.

 

My Notepad++ setup apparently doesn't show suggestions and available functions across script-links, which threw me off for a bit as well.

(Makes sense in hindsight since it doesn't technically have access to the link. I'm a bit dense~)

 

Thanks a lot for the help, I know this was a bit more of an answer than most questions typically require. I appreciate the effort!