Ok so I'm trying to change the vampire quest script. I got to work on it and forgot all about how your not supposed to change the original scripts! So I need to know how to extend it or whatever so I'm editing my own script and not the vanilla vampire script.

For the most part I'm going to rewrite the entire script. If I'm not mistaken, isn't extending a script just adding new functionality? I need to pretty much gut out the old vampire script and change everything, so do I just attach the vampire quest to my new script, or do I need to extend it?

Also, I need to revert the old script back to vanilla. Do I have to reinstall Skyrim or does steam have a way to revert any files that may have changed?

(In your Quest)

if vanillaquest.GetStage(45) == 1 then

myNewQuest.SetStage(10)

end if

OR

you can also check whether a quest is completed and then start your quest

(and some more ORs too)


Aliases and references mean that this can be quite complex to get your head around. And note the "script" I wrote above is not correct for syntax!!

Search the wiki, Script Reference, you will find many Quest Related "GET" and "SET" functions that you can use (but, like I say, you may need to set and use shared references/aliases for it to work - depending on exactly what you want to do).

Check through MQ101 (Main Quest), it checks and fires off a number of sub quests, via script, in a similar way.

That doesn't really help me, I don't want a new quest, I want to extend a vanilla quest with new functions without editing the vanilla quest script. I want to use the same quest, just extend it with another script in the drop down box that has the scripts.

Right now I have

Scriptname UnholyDarkness extends Quest  Function SomeFunction()  RegisterForSleep() ; Before we can use OnSleepStart we must register.EndFunctionEvent OnSleepStart(float afSleepStartTime, float afDesiredSleepEndTime)	Debug.Messagebox("Player went to sleep at: " + Utility.GameTimeToString(afSleepStartTime))	Debug.Messagebox("Player wants to wake up at: " + Utility.GameTimeToString(afDesiredSleepEndTime))endEvent

Under the vampire quest, but I can't seem to get the sleep function to do anything. Mainly its just code I grabbed off the wiki to test and see if the script is even running.

You'd need to manually call the SomeFunction() from somewhere to kickstart it.

Changing the function to 'Event OnInit()' will do that when the quest starts, (or when the script is first attached.)

EDIT: Add an unregisterForSleep() at the end of your OnSleepStart() Event.
These registed events persist and fire in savefiles even after your mod is removed.

http://www.creationkit.com/RegisterForSleep_-_Form
Your script does not extend an active magic effect, alias, or form, so it will not recieve the sleep event.

If I understand what you want to do, then I don't think you can. I don't think you can have more than one script file attached to a Quest in that way (though someone else may come along and tell us both I am wrong ... that wouldn't be a first ... Indeed, someone may just have done so ^^^^^)

(If I am right) So, it depends what you mean by extend a Quest?

If you want to add or change how a particular stage or objective works, then - I think - you will have to amend the vanilla quest/script.

If you added a new stage then - I think - you could add a new script/fragment for that new stage, in a new script (but you would have amended the actual quest)

If you want to add new objectives/stages to a quest, then you may be able to do so by making a new quest (which will be seen by the Player as a new quest, but you could add it to the same journal entry subset as the existing quest). The way I described will let you do that (I have done it, with the Main Quest).

I guess it depends on what you mean by "I want to extend a vanilla quest with new functions"

I just want to totally redo the vampire quest script, but since scripts are no longer part of the ESP file, I read somewhere it is bad to edit the vanilla scripts, since it would be akin to replacing meshes.bsa, skyrim.exe etc etc etc. A mod which requires the user to completely reinstall the game to get rid of the mod would be bad.

So I was told by a scripter you shouldn't modify the vanilla quests in order to make your mod, but rather make a new script, and remove the old one from the quest, and attach your new script, or extend it with a new script.

That probably belongs in a new debate thread. I can't think of a better way to stuff up peoples games and make your mod less compatible with others than removing an ingame script.
As you had it with the script above alongside the other is probably the most compatible.

It will depend on what you are actually doing though on how much impact you make.

Hmmm now that I'm looking at it, the vanilla scripts are NOT in the data/scripts folder unless you mod it. They are in the misc.BSA files, so in my opinion, modding the vanilla quest scripts should be ok, just tell the users to delete the script when they uninstall and the vanilla script would be used once again, as far as I can tell anyway. So I personally don't see what the big deal would be to mod a vanilla script. I mean sure, if other mods are using functions contained in the vanilla script it could cause problems, but since what I'm doing is isolated to vampires it should be ok I would think.

The main problems with editing scripts are the following:
1. Until a recent patch, scripts that overrode vanilla scripts would work as loose files, but would not take effect when packaged into a BSA, so it wouldn't work on the Steam Workshop. This no longer applies.
2. Edits to scripts are now saved to the source file, so if you change a script for one mod, and want to make a DIFFERENT change for another mod, you have to keep backups of the source file in question.
3. MAJOR problem is how scripts are handled by saved games. some details are here:
http://www.creationkit.com/Save_File_Notes_(Papyrus)
The main problem is that elements of scripts are saved. Objects remember which script was attached to them, so if you create a new script and change the object to use it, any objects that the player has already encountered would still be using the vanilla script. When your mod is deactivated, objects that were using the new script will stop working entirely (because they were saved as using the new script, and the new script no longer exists). This particular problem is actually less of a problem if you edit vanilla scripts rather than making new ones, but there are other issues.
For example, the last function that was running will continue to run until it finishes, if you create new aliases on a quest they will not be filled, properties have problems as well, I think ...
It's generally quite annoying trying to modify existing scripts at all.
And when your script is removed, traces of it remain, for example if you registered for OnUpdate() events, they continue to be sent to it even if isn't using them anymore.

In fact, I believe someone has already attempted modding the vampire stuff, and encountered some serious problems ...


Also, one thing from a modder - if you edit vanilla scripts and upload them as loose files to the Nexus, can you please have the source code separate? Or in a custom folder? So that it doesn't overwrite my own source files when I install the mod

Sounds like your saying your damned if you do and damned if you don't?

You also said in #2 that edits to scripts are saved to the source file. What source file are you talking about?

What would be better?
1.) make a new quest with a new script that simply does a stopquest command on the vanilla vampire quest, and leave those scripts alone.
2.) Edit the vanilla scripts and quest?

With 1, uninstalling should be fine as long as you create a function for uninstall which shuts everything down and then starts the vanilla vampire quest up. or you could tell them to start it manually with a console command after they uninstall your mod.

I am, a little. Quite disappointed with the new system actually. It's fine for the developers who don't have to deal with changing the scripts in between saved games and who have a version control system in place, but a bit of a pain for us.

The *.psc files that the CK installs into Data\Scripts. When you "edit source" on a script, it opens them from there. AND saves over the file, in addition to compiling a *.pex file.
You can get the originals back by running "Verify Tool Cache" from Steam. But if you wanted one of them to stay edited, you have to make backups.

What exactly you should do depends on what you want to change ...
I'm hoping the other modder who worked with vampirism will show up .. I forget who it was. Someone more experienced than me. They said they ended up having to create a new quest to replace the vampire one, as per your "1.)".

The problem with an uninstall function is how do you ensure it is run when the mod is deactivated??

The poster above is talking about the Script file (I believe) when he says "source".

Search on here about Dirty Saves. Once you play the game with a MOD, there is a chance - depending on what the MOD does - that changes to that MOD, or it's removal, will cause all manner of nasties (from a crashing game to a save game no longer working, to the mod - or vanilla - quest/script no longer working).

Best practice, at the moment, is to try and avoid modding Vanilla scripts (and so probably Quests, too) if at all possible.

Compatibility with other MODs is a whole other minefield (just adding a door, or a player house may break another mod that the player installs), worrying about that will just prevent almost any mod being made ... That's not to say a modder should not think about it ...

What would be better?
There is no better, just a series of choices, any of which may break a Player's saved game. The only way to guarantee no impacts is to create mods that are intended for "New Game Only" and do not touch Vanilla scripts ... but that is hardly practical.

If I were you, I would write a new quest that:

1) Checks the status of the vanilla quest you want to replace and - as cleanly as possible - disables it (if it is not already complete)
2) Write your new quest

(You could include in the first "checking script" a dialogue box choice for the player to select whether he wants to run the vanilla or your quest)

Note that, uninstalling your MOD, once it is part of a saved game, may cause similiar problems for the player. There is also the issue that, once you have disabled it, the player may have no way to re-enable the vanilla quest.

So far - and there are threads discussing this issue - I have not seen any workaround which is 80%, nevermind 100%, guaranteed to work in all situations.

Editing scripts didn't need to cause problems always. If you add funcionts there is no problem at all. The same is applied if you change functions that are not supposed to stay active.

The problem is that the active functions remain active in their previous version, but once a function is finished, the next time the function is called it will use the new version. Adding a function won't cause any problem. Events are functions, so the same applies to them.

In the example you provided, the event will run when the player is sleeping and I think you can't save yor file while your character is sleeping (I may be wrong, if so, simply add a warning about making a save while they are not sleeping for the update), so you can update it without problems as the event won't be active in any save.

For the Vampire quest I don't think you have much choice. Stopping that quest is not really an option.
That script holds the VampireStatus variable, which is marked as a conditional.
Meaning it is probably used all over the place, and needs to be up to date.

So yeah, editing the orig script is probably the best way to go. You could then leave the external interface to it intact.
The problem is then the same as if you were updating one of your own quest mods, but this mod is hugely popular, and everyone and anyone is basing other code off of it.