SSE Getting child variables and functions to be used in a quest rather than parent ones

[Zeus0moose]

So, I'm trying to add a lot of functionality into DLC1NPCMentalModel, the quest that handles Serana's behavior and opinion of the player. To do so, I first created a script extending DLC1_NPCMentalModelScript and added it to the DLC1NPCMentalModel quest. I then removed the original script, since I would have access to all of its functions and properties anyway in the child script. I got to work on adding some new functions that I felt would be useful into the extended script, and quickly found that I would need to recreate the variables of the parent in the child as they cannot be seen by the child. This fixed compilation issues I had been running into when trying to copy/paste parent functions into the child script with the intention of modifying them there. However, I've noticed some problems...

 

• When entering sqv DLC1NPCMentalModel, two of every variable is shown. I assume that it is something along the lines of both the old parent variable and the child variable being called up, but I am not sure.
• Also when entering that same thing into the console, all the variables are still shown as having the value defined in the parent (DLC1_NPCMentalModelScript). For instance, I wanted to expand the axes min/max to -5/5 rather than -3/3, and make the assessments go from -5.0/5.0 rather than 0.0/10.0, and so I set them as that in the child. But pulling up the quest in the console still reads "__axisMin = -3, __axisMax=3, __assessmentMin = 0.0, __assessmentMax = 10.0". Note that each of these is repeated twice as mentioned above, using the parent value of -3/3 0.0/10.0 each time. Even if it is printing both the parent and child, only the parent variable's value is getting through.
• At least one function doesn't want to work when overridden in the child script. The function "Setup()" does not seem to run when I create a slightly modified version of it in the child script, and on game start all properties that SHOULD be given values (for example, AxisGuardedToOpen should start at -1) are just 0. Also, the boolean "__isSetup" is still False, so clearly it never ran the override function OR the parent one. If I rename the overriding function to SetupBlah() just to get it back to using Setup() from the parent, it runs that function fine, but there's still the duplication and parent values being shown...

I decided to test a possible explanation to this by adding a prefix to all the child variables and making overriding functions consistent with those new prefixed variables, to see if it changed the output. It did - all the prefixed variables were set to the right values by Setup() and the changes I made to the minimums and maximums were there, too. The parent variables, no longer touched by Setup(), were just set to either 0, empty or whatever was present in the parent script itself.

 

This is frustrating - do I really have to just create an entire parallel structure to get around this? It may just be that sqv is at fault, and the underlying structure is as I intend it to be. But if that's not the case, I don't think allowing the possibility for parent variable values to be used instead of the updated child ones is acceptable... and if the only solution to that is to create a whole new renamed set, it would mean I have to override every function to ensure only the new variables are dealt with, while the parent ones get left alone. Seems like it defeats some of the purpose of extending a script in the first place.

 

Edit: To further complicate things, I believe I might have to even create parallel versions of some properties... if I understand the wiki correctly, I cannot override things that a property does in a child, unlike a function. If so, since the get/set functions of the parent for some properties call on variables only in the parent, these wouldn't be consistent with stuff done in the child script and thus I'd need to make new properties entirely under different names to serve the same purpose, but instead interact with the child variables instead. This also means any checks using the affected variables in certain topics would need to be changed to used the new, prefixed properties... there's got to be an alternative here. I'd rather not touch the vanilla script, but if the only way to avoid that is all this renaming, then it's a pretty rough choice.

Edited August 4, 2017 by Zeus0moose

[cdcooley]

So, I'm trying to add a lot of functionality into DLC1NPCMentalModel, the quest that handles Serana's behavior and opinion of the player. To do so, I first created a script extending DLC1_NPCMentalModelScript and added it to the DLC1NPCMentalModel quest. I then removed the original script, since I would have access to all of its functions and properties anyway in the child script. I got to work on adding some new functions that I felt would be useful into the extended script, and quickly found that I would need to recreate the variables of the parent in the child as they cannot be seen by the child. This fixed compilation issues I had been running into when trying to copy/paste parent functions into the child script with the intention of modifying them there. However, I've noticed some problems...

I stopped reading your description after that part.

 

Don't do that! Your specific problem sounds like you are testing your new script using an existing game. If you already had a game in progress the original mental model script would already be attached to the quest and would remain attached in the saved game no matter what changes you might make in an ESP. Your change would have just forced the system to load both scripts independently and in effect you would have had your scripts and two versions of the original mental model all attached at the same time.

 

If you're goal was for compatibility you ruined that at the moment you detached the original script. You either need a completely separate script or better yet simply edit the original mental model script. There are cases where editing original game scripts is the right thing to do and this is one of them.

[Zeus0moose]

 

So, I'm trying to add a lot of functionality into DLC1NPCMentalModel, the quest that handles Serana's behavior and opinion of the player. To do so, I first created a script extending DLC1_NPCMentalModelScript and added it to the DLC1NPCMentalModel quest. I then removed the original script, since I would have access to all of its functions and properties anyway in the child script. I got to work on adding some new functions that I felt would be useful into the extended script, and quickly found that I would need to recreate the variables of the parent in the child as they cannot be seen by the child. This fixed compilation issues I had been running into when trying to copy/paste parent functions into the child script with the intention of modifying them there. However, I've noticed some problems...

I stopped reading your description after that part.

 

Don't do that! Your specific problem sounds like you are testing your new script using an existing game. If you already had a game in progress the original mental model script would already be attached to the quest and would remain attached in the saved game no matter what changes you might make in an ESP. Your change would have just forced the system to load both scripts independently and in effect you would have had your scripts and two versions of the original mental model all attached at the same time.

 

If you're goal was for compatibility you ruined that at the moment you detached the original script. You either need a completely separate script or better yet simply edit the original mental model script. There are cases where editing original game scripts is the right thing to do and this is one of them.

 

I've been exclusively using new saves to test this. The only things I've tested on old saves were some edits to some dialogue, but since changing scripts I've been testing on new saves. But whatever the case, after mulling it over and running through the options I have I'm also starting to agree that just editing the original is the only way to get it done without a preposterous amount of compensation in the form of new variables/properties. And your point about compatibility is true.

 

Luckily the mentalmodelscript isn't critical in the sense that it's integral to the game as a whole. Obviously it might break other mods that touch Serana but I suppose my plans were always going to do that since I need a lot of scripting anyway rather than just the small dialogue edits I started with.

 

Anyway, thanks. I guess I have too strong a fear of touching vanilla source files, which is sometimes good but can be way too restrictive and overblown when push comes to shove as this case goes to show.