LE Vanilla script Properties fill, non-vanilla script Properties do not...

[soupdragon1234]

There is a vanilla trigger box with a script attached. Fine, no problem. If I try and modify the script, also fine, no problem you'd think...

 

The problem comes with Properties. The extra properties added by my custom script do not fill. Very strange, until you realise that if I duplicate the original setup then Properties fill perfectly!

 

Vanilla trigger box + activator - no reference alias properties will fill. If I create a duplicate box + duplicate activator, a compete carbon copy of the original, but new - Properties then fill as intended!

 

(vanilla box + activator debug.notification reports "NONE" for properties. Custom but duplicate box + activator reports correct properties.)

 

Completing baffling. Anyone have a clue whats going on? I'm stumped. Virtual milk and cookies to anyone who can explain what going on.

 

Have I checked to make sure all properties are properly filled in both cases... yes.

[Sdesser]

Could you specify a bit more clearly on what is it that you're trying to do with the script exactly (perhaps copy paste the script you're modifying and your own variant of it)?

Also properties don't auto-fill unless there's an object in the Creation Kit with the exact same name as the property in the script. You can still enter the property manually, however.

[soupdragon1234]

Thanks for the reply. Properties are fine in the CK they either auto fill and I can add them all manually, I mean that they do nothing in game.

 

Put it this way, vanilla script contains NPC1. I add NPC2 to a script which is fine except... nothing shows up in game. I mean NPC1 is fine but NPC2's value is null and void in the game. Its absolutely fine in the CK though. All Properties filled a-ok.

 

The strange thing is I can modify scripts in vanilla quests just fine but modify a script attached to a vanilla object and it just doesn't want to know. :confused:

 

I've given up honestly and i'm replacing all the vanilla trigger boxes with my own box+script which work perfectly.

 

edit: and after hours of banging my head on my desk I've finally got my head around Functions. So theres good news at least. :happy:

Edited May 11, 2015 by soupdragon1234

[Sdesser]

I still don't know what it is you're trying to accomplish with the script. :confused:

There's probably something going wrong with the script that you're editing or with the quest, since you're using aliases. It's impossible to tell what it is since I haven't seen the script itself. :<

 

P.S. You should never edit vanilla scripts. You should copy the vanilla script into a new one and then edit it. Also, unless you actually attach the property into doing something in the source of the script, adding a property won't do anything on it's own.

[soupdragon1234]

P.S. You should never edit vanilla scripts. You should copy the vanilla script into a new one and then edit it.

 

Seriously? So all the mods I've ever downloaded that modified vanilla scripts got it wrong? I'm curious as to how you reached that conclusion. If you're talking about the vanilla source script and compiled scripts getting overwritten I'm well aware of that thanks all the same.

 

I could of course create a new script but then it gets baked into the savegame and theres nothing to remove it if the mod is removed. Vanilla scripts will at least revert to whatever default is present in the BSA etc if and when the mod disappears.

Edited May 12, 2015 by soupdragon1234

[Sdesser]

Changing vanilla scripts can cause problems with all other mods and vanilla content that use that script. Unless your mod especially needs to change the functionality of a vanilla script to work, I would advice against editing them. Even in such cases, it's a lot safer to make your own script and use that to prevent your mod from causing problems.

 

It's considered bad practice to edit pre-existing scripts, so yes. I'd say mods that you've downloaded, that modify vanilla scripts are probably doing it wrong. Exceptions of course exist, for example overhauls sometimes need to do it. It's easier to edit the existing script as the changes are applied to all objects that use it, but unless you know exactly what the script does and all the things it's tied to and you know it won't cause problems, it might be safe to edit it. Even then, you don't know what other mods might take use of that script and you might be creating incompatibilities with said mods.

[soupdragon1234]

Changing vanilla scripts can cause problems with all other mods and vanilla content that use that script. Unless your mod especially needs to change the functionality of a vanilla script to work, I would advice against editing them. Even in such cases, it's a lot safer to make your own script and use that to prevent your mod from causing problems.

 

It's considered bad practice to edit pre-existing scripts, so yes. I'd say mods that you've downloaded, that modify vanilla scripts are probably doing it wrong. Exceptions of course exist, for example overhauls sometimes need to do it. It's easier to edit the existing script as the changes are applied to all objects that use it, but unless you know exactly what the script does and all the things it's tied to and you know it won't cause problems, it might be safe to edit it. Even then, you don't know what other mods might take use of that script and you might be creating incompatibilities with said mods.

 

Alright, I'm aware of the compatibility issues but this is something that is indeed an overhaul rather than a minor mod that modifies a couple of things but thanks for pointing it out. :thumbsup:

 

 

I still don't know what it is you're trying to accomplish with the script. :confused:

There's probably something going wrong with the script that you're editing or with the quest, since you're using aliases. It's impossible to tell what it is since I haven't seen the script itself. :<

 

Ok heres an example. This is the vanilla script. The script in question is the BYOHRelationshipAdoptionPetDoorTrigger.psc script attached to the BYOHRelationshipAdoptionPetDoorTrig activator. Its attached to a trigger box thats situated outside every player home. It warps all creatures with the Housepet keyword i.e. dogs (FamilyPet) and critters (FamilyCritter) indoors once they enter the box. You need Hearthfires obviously.

ScriptName BYOHRelationshipAdoptionPetDoorTrigger extends ObjectReference
{Script for a trigger outside each of the player houses. Pets or critters entering this trigger will be warped inside the home (since they can't use doors normally.}

Keyword property BYOHAdoptionHousepetKeyword Auto
Faction property CurrentFollowerFaction Auto
LocationAlias property CurrentHomeLocation Auto
ReferenceAlias property SandboxHome Auto


Event OnTrigger(ObjectReference triggerRef)
	;Is this a housepet? Is it trying to get back inside?
	if (triggerRef.HasKeyword(BYOHAdoptionHousepetKeyword) && !(triggerref as Actor).IsInFaction(CurrentFollowerFaction))
		;Is the player inside? If so, we'll wait so the pet doesn't teleport in in front of them.
		if (Game.GetPlayer().GetCurrentLocation() != CurrentHomeLocation.GetLocation())
			triggerRef.Disable(True)
			triggerRef.MoveTo(SandboxHome.GetReference())
			triggerRef.Enable(True)
		EndIf	
	EndIf
EndEvent

Vanilla script with properties all filled as it looks in the CK, nothing touched or added by me:

 

 

 

It all works fine. As it should. Now if I add the following lines:

Debug.Messagebox("Family Pet is..."+FamilyPet)
 
ReferenceAlias property FamilyPet Auto

so the modified script looks like this

ScriptName BYOHRelationshipAdoptionPetDoorTrigger extends ObjectReference

{Script for a trigger outside each of the player houses. Pets or critters entering this trigger will be warped inside the home (since they can't use doors normally.}

Keyword property BYOHAdoptionHousepetKeyword Auto
Faction property CurrentFollowerFaction Auto
LocationAlias property CurrentHomeLocation Auto
ReferenceAlias property SandboxHome Auto
ReferenceAlias property FamilyPet Auto

Event OnTrigger(ObjectReference triggerRef)
    ;Is this a housepet? Is it trying to get back inside?
    if (triggerRef.HasKeyword(BYOHAdoptionHousepetKeyword) && !(triggerref as Actor).IsInFaction(CurrentFollowerFaction))
        ;Is the player inside? If so, we'll wait so the pet doesn't teleport in in front of them.
        if (Game.GetPlayer().GetCurrentLocation() != CurrentHomeLocation.GetLocation())
            triggerRef.Disable(True)
            triggerRef.MoveTo(SandboxHome.GetReference())
            triggerRef.Enable(True)
        EndIf   
    EndIf
    Debug.Messagebox("FamilyPet is..."+FamilyPet)
EndEvent

Properties look like this, all filled, ok? From the same quest as the other properties:

 

 

 

In-game the messagebox reports this (yes I know there is nothing in the picture the pet in question teleported indoors just before the messagebox popped up. You'll just have to take my word for that, ok?): :tongue:

 

 

 

But if use the same script on a duplicate trigger box and duplicate activator i.e. not vanilla one but identical in every respect with identically filled properties messagebox reports the correct pet this time. Theres the mystery. :ermm:

 

 

Knowing how fickle the save system in Skyrim is with scripts, the old version of the script could be lingering in the old activators and trigger boxes. Could also explain why new references of the same object work properly and the old ones don't. Did you try this with a brand new save?

 

The replacement script works fine, hence the messagebox. If it wasn't working it wouldn't appear. QED. The trouble is Properties as I've been saying all along.

 

If you mean a clean save with no prior version of the mod/script active, yes. If you mean start an entire new game, no. I will do that however it may take a while for me to meet the requirements for a new house... :tongue:

Edited May 12, 2015 by soupdragon1234

[Sdesser]

Knowing how fickle the save system in Skyrim is with scripts, the old version of the script could be lingering in the old activators and trigger boxes. Could also explain why new references of the same object work properly and the old ones don't. Did you try this with a brand new save?

[cdcooley]

It's almost certainly an issue with the script instances already being stored in the saved game file. To test modifications to existing scripts almost always requires a completely new game. That's another reason for avoiding editing original scripts, testing any changes is a major pain.

[Pevey]

I imagine it's what cooley said. Properties get filled on init. So if you are loading a save after whatever the script is attached to was already first loaded, the new properties will not fill correctly. You can try opening the console and using reloadscript, but I doubt even that would cause the new properties to fill if whatever the script is attached to was already initialized. Could be wrong on that, though. Worth a try.