Editting Papyrus Base Scripts - Actor.psc, ObjectReference.psc etc.

[osuf]

It appears to me that modders should not leave the power of editing base scripts untapped when needed. Naturally, the great caveat with this is that no two such edits will presently be compatible. I ask primarily what we can do about this.

 

I wonder

1. Is the premise wrong? That is, to contradict it, is there virtually always an alternative to modifying base scripts such as Actor.psc, ObjectReference.psc, etc.?
   
2. If not, what system could we device to render base-script edits compatible?
   
3. What mods do you know which presently edit base scripts?
   

 

Longer story

 

 

Synopsis in place, I have to admit - I have never before written a mod for TES; I may be greatly mistaken in this topic and if so, I apologize for jumping to conclusions.

 

My own motivation for this post was a dialogue-driven disposition system for Skyrim with multiple variables (affection, respect etc.). To this end, I aimed to add to every NPC a number of ActorValues accessible through in particular dialogues. Memory concerns besides the topic, I researched thoroughly for a way to achieve this and eventually gave up in lieu of modifying Actor.psc directly. This worked splendidly but I could find no apparent way to do so while maintaining compatibility with other scripts taking the same approach, unless we coordinate a system. Unfortunately you cannot `alias' a class. How would you do this?

 

For completeness sake, the (efficient) approaches I've so far seen in scripts modifying objects universally, e.g., all NPC's, guards, books, or the like, exploit one of the following four methods. Please correct me if you've seen more.

• Quests processing: possibly through aliases, one can run a script repeatedly on a set of objects, but as far as I'm aware, it does not offer efficient and persistent object-specific variables.
  
• Active (magic) effects: attaches to an actor and permits adding new variables as well as to process actor events. However, I know of no (simple) way to make newly-added properties accessible in universal dialogues. (Granted, one could force an event on the magic effect which causes it to store its variables in global properties, modify the same, and cause a new event to store them back). Might also be feasible if SKSE were to provide additional enumeration methods.
  
• ScriptDragon: also runs continuously and permits new variables. With e.g. hashes, also object-specific ones. However, I can not figure out how to hook such variables up to e.g. dialogues.
  
• Attach an actor script to every X: does not work with X's added by new mods, causes incompatibilities, and involves a ton of work.
  

These approaches will likely suffice for most scripts and should not be complicated further. However, they all possess limitations, some of which may be alleviated by modifying base scripts. It is power which one should be keen to give up in vain.

 

For those who wonder what I mean by modifying `base scripts': if you download the Creation Kit, you will find Actor, ObjectReference, Book, and other base Papyrus classes in the Creation Kit (Gameplay>Papyrus Script Manager), as well as text files in the <skyrim data>/scripts/source directory which may be compiled to pex files with the papyrus compiler. Modifying these scripts indeed affect all in-game objects instantiating these classes or extending classes thereof.

 

Enough blabbering. It seems to me that there is sometimes no other viable option but to modify base scripts. Am I wrong and if not, how can we do this while maintaining script compatibility?

 

Thanks for reading.

 

 

 

Bethesda Topic

Edited March 30, 2012 by osuf

[Astymma]

In programming we'd call this a "fork" of a project and it's acceptable practice. The drawback is once forked, that project is no longer compatible with any other fork without a lot of work. This practice has a ton of precedents in the modding community with examples like overhaul mods, gameplay mods, realism mods, body/clothing mods, etc.. My answer would be yes... if this is what you need to do in order to achieve the aim of your mod then do it but realize you will create a new modding "fork" that will narrow the userbase. Some of these forks end up becoming defacto standards though... BB in Morrowind and CM Partners in Oblivion are good examples. Modders should never be afraid to change things. They just need to carefully consider the ramifications and educate users on what they are. You should also, as a modder, be prepared for the nightmare of supporting such a mod as they invariably become lightning rods of "trouble". You end up being forced to not only support your mod but all mods that depend on your new mod.

 

1. You are not wrong. In some cases editing base scripts may be the only solution though attempting to find an alternative should always be pursued first.

2. The system currently used is for the conflicting mod authors to converse and determine a way to achieve compatability. That or a third party steps in and makes a patch.

3. Only one I know of was AP and that resulted in an immediate and very negative response from fellow modders though not so much from the community of users.

[BigKevSexyMan]

Well, we have this new OOP scripting language, right? So why can't you extend the player class instead of overwrite it? I'm pretty sure there's inheritance in papyrus via the 'extends' keyword.

[Astymma]

Well, we have this new OOP scripting language, right? So why can't you extend the player class instead of overwrite it? I'm pretty sure there's inheritance in papyrus via the 'extends' keyword.

 

A base class is automatically applied to everything it's intended to affect. Once extended, a class is applied to nothing unless you assign it in the CK.

That's why the OP is talking about editing base classes, because they are automatically applied without any other changes needed...

they even apply to other mods who extend the base class.

 

The OOP implementation allows casting from a child class to a parent but does NOT allow casting from parent down to child unless you also assign the extended class in the CK.

Kind of nullifies the whole point of downcasting imo.

 

For example you can't do the following:

Actor thePlayer ;base class
MyActor theExtendedPlayer ;extended class
thePlayer = Game.GetPlayer()
theExtendedPlayer = thePlayer As MyActor

 

You can do it if you go into the CK and attach your extended MyActor class to the player but that defeats the OOP polymorphism intent of downcasting.

You can cast upwards though without needing to do this so "thePlayer = theExtendedPlayer as Actor" works...

[LukeH]

I was just thinking of something as I don't feel good too about messing vanilla scripts, no time to test as I'm at work.

Could you do something like:

 

Scriptname MyActor extends ObjectReference Hidden

;add methods or anything you need

 

Then modify Actor script with this only change:

Scriptname Actor extends MyActor Hidden

 

Then only cast actors to MyActor when you wish to access something from it.

Do you think this would work? It should be leave everything a bit cleaner by not polluting Actor too much.

[osuf]

In programming we'd call this a "fork" of a project and it's acceptable practice. The drawback is once forked, that project is no longer compatible with any other fork without a lot of work. This practice has a ton of precedents in the modding community with examples like overhaul mods, gameplay mods, realism mods, body/clothing mods, etc.. My answer would be yes... if this is what you need to do in order to achieve the aim of your mod then do it but realize you will create a new modding "fork" that will narrow the userbase. Some of these forks end up becoming defacto standards though... BB in Morrowind and CM Partners in Oblivion are good examples. Modders should never be afraid to change things. They just need to carefully consider the ramifications and educate users on what they are. You should also, as a modder, be prepared for the nightmare of supporting such a mod as they invariably become lightning rods of "trouble". You end up being forced to not only support your mod but all mods that depend on your new mod.

 

1. You are not wrong. In some cases editing base scripts may be the only solution though attempting to find an alternative should always be pursued first.

2. The system currently used is for the conflicting mod authors to converse and determine a way to achieve compatability. That or a third party steps in and makes a patch.

3. Only one I know of was AP and that resulted in an immediate and very negative response from fellow modders though not so much from the community of users.

Thank you for the feedback. Regarding your comments,

1 - Thanks, it's hard to know.

2 - I am more curious if we can find a persistent and scalable solution to this issue where incompatibilities arise not due to technical limitations but to actual incompatibilities in game mechanics. For the latter, the conflicting mod authors would naturally have to converse, or users would have to choose one or the other. Presently, the technical limitations prevent any two edits of e.g. Actor.psc even though the two mods may have otherwise have nothing to do with each other, and it is this rather than I would be curious if we could find a consensus to alleviate, for those who do wish to resort to editing base scripts. Third party steps definitely sound like a good suggestion, e.g. perhaps one could provide a utility with all the base scripts and the compiler which will merge and compile any changes. It's a possibility, albeit with its own pros and cons.

3 - Sorry - AP?

[osuf]

I was just thinking of something as I don't feel good too about messing vanilla scripts, no time to test as I'm at work.

Could you do something like:

 

Scriptname MyActor extends ObjectReference Hidden

;add methods or anything you need

 

Then modify Actor script with this only change:

Scriptname Actor extends MyActor Hidden

 

Then only cast actors to MyActor when you wish to access something from it.

Do you think this would work? It should be leave everything a bit cleaner by not polluting Actor too much.

Yes, this is a good idea. This, or the other direction by renaming the default Actor. This was my initial idea, providing e.g. an esp with, say, 100 ancestors ActorXYZ of Actor. If a mod wanted to extend Actor, they could then pick any unused ActorXYZ and simply load after the provided esp. ofc the new script would not receive the name of one's choosing (unless you encapsulate), but it would work.

However, in the Betheseda forum, there was a comment that any property defined in a script is duplicated in any extending script. That is, if one script were to add a single property to Actor000 in the above example, it would in fact add about one hundred new variables, one for each ActorXYZ. I suppose one could instead provide a MyActor which calls the 100 ActorXYZ scripts which Actor does not extend from but merely pass function calls to before reaching the original Actor script, as well as making these scripts visible in e.g. dialogues. What do you think?