PatchingUpdating: Any red flags with this method?

Post » Wed Jul 24, 2013 7:52 pm

Hey everyone,

So I've made a decision on how to handle patching and updating for Falskaar. I just wanted to go over it briefly here, and why I chose certain things, to make sure there wasn't anything terribly wrong with this method. So, if you can think of any terrible reasons not to do something mentioned below, let me know so we can discuss!

I'm basically presented with three options:

1. Released patches and updates like Bethesda. Something like FalskaarUpdate.esm for smaller patches. Then in the event I do an expansion or something, it would be a new esm based on the original.

2. Release patches in a mixed fashion. I'd have an update esm and bsa, but huge updates or expansions would simply be to the single original Falskaar.esm file. (With all bug fixes merged in from the update, which would then start over)

3. Release everything together in one file. No matter what I simply upload a new Falskaar.esm and BSA file. It's one simple file.

Now, of course each one has it's ups and downs. Manageability, complexity, download and upload times. Well, I've chosen to go with option three, and here's why.

Patching mods with Skyrim is tricky. With the new system of script baking and all the other problems that updating/removing mods mid-play has, I believe the best approach is that when the mod updates, you don't install the update unless you're starting a new playthrough. This concept works well with the other half of my patching decision, to release fewer larger patches. I don't really want to release a patch every week, or more often. I could, fixing up tiny things and whatnot. But it each release would take a lot of time, and since there are no HUGE issues that need to be fixed, frankly it isn't urgent enough to warrant such work. Instead, releasing huge patches less often has less overhead, even though it has more upload/download sizes and times when it does happen, it will happen far less often, and will change a lot more. (One a month? Every few months? Sort of a Bethesda timescale) In addition, I'm not sure what my schedule in the future will be, so this lets me work when I want on the mod, and I can simply release a patch when I feel it does plenty. This also gives me larger periods of work time if I wanted to add new features or larger chunks of content, beyond simple fixes.

So, basically, every month (or few) I will upload a new FULL version of Falskaar.esm and Falskaar.bsa (And the video files). The instructions and method for update will be, do not install this new version unless you're starting a new playthrough. That will eliminate (Or should, at least...) a HUGE amount of potential issues if people are just updating randomly as they play the mod, since we all know that doesn't work so well.

I certainly want to support Falskaar, and even keep adding new content for it (I'm already going through level-design withdrawl, I need to add more levels or I am going to fall over), I just want to do so in a manner that works best for everyone, and mainly myself.

Hopefully with this I can continue to support Falskaar until the next Fallout comes out. (Which according to E3 rumors could be October of 2015, giving me 2+ years, woah!)

Anyway, sorry for the wall of text. Does anyone see any MAJOR issues with why I shouldn't approach updating like this? I'm going to post a big update about everything that's going on, and what I'm going to do, and patch discussion will be part of it so I'd like to know if I should make tweaks before tomorrow morning! (About 12 hours)

Thanks,

Alexander

User avatar
Spaceman
 
Posts: 3429
Joined: Wed May 23, 2007 10:09 am

Post » Wed Jul 24, 2013 3:17 pm

There are only really two issues i can see for users by you going with method 3. Some will complain about having to start a new game, and there are some users out there who extract their mod BSA files... needlessly and without thinking ahead, possibly leaving loose files behind.

To be honest with you i haven't had any issues with doing mod updates, I'm sure you mod like i do and are always aware of what can change in a save and what can't. However of course there are times that i need to change a quest for example, which means a user who updates whilst in the middle of that quest may have issues. You just have to trust that they read your updating instructions... in my case it would say "Finish X quest before you update".

You know what some users are like though, their complete lack of reading makes you wonder if they even read the name of your mod lol. But that's just the way some people are.

My advise, update however you see best, and give the user as much info as possible so they don't hurt their game. If they choose not to read it, too bad.
User avatar
TRIsha FEnnesse
 
Posts: 3369
Joined: Sun Feb 04, 2007 5:59 am

Post » Wed Jul 24, 2013 11:30 pm

Method 3 is what I'd go with too. No sense in issuing a separate ESP patch for things because then you'd have some people not downloading it and then complaining about bugs you've fixed.

That said, advising people to start whole new games every time you update Falskaar isn't going to fly with today's user base. Not even Bethesda has required such a thing with official patches to Skyrim itself. They have patch updaters exactly for this purpose.

Most of what you fix won't need to be forced into it. It's basically the need to adjust quests and Papyrus properties post-release that will cause you problems. For that, I'd suggest looking into the USKP and how we handle the progressive updates via the retro-scripts. Feel free to clone the system exactly if you want. I use it in LAL as well. The system works great, even with as many different updates as we've had to do over time, and the way I designed it makes it immune to executing the fixes out of order should you end up with a later fix depending on a previous one already being done.

Mod updates are not as scary and unapproachable as they might seem. You just have to plan ahead for it. You're in a much better position to get it right the first time though now that others have done this before you.

User avatar
sara OMAR
 
Posts: 3451
Joined: Wed Jul 05, 2006 11:18 pm

Post » Wed Jul 24, 2013 3:43 pm

I am unfamiliar with such a system. How would something like this work? A script that checks if the 'bug' has occurred then fixes it or something?

As for telling them to start over; I'll simply say I don't support updating the mod mid-playthrough. They can if they like, it just may have some hiccups. It really does depend on what I have to change. Add a new dungeon? Should work no problem with users already in Falskaar. Want to tear out the bard system and redo it? That would cause issues...

User avatar
Victoria Bartel
 
Posts: 3325
Joined: Tue Apr 10, 2007 10:20 am

Post » Wed Jul 24, 2013 6:36 pm

Best way I can explain it is by example:

Spoiler
Scriptname USKPRetroactive133Script extends Quest  Quest Property MQ101 AutoActor Property PlayerRef AutoUSKP_VersionTrackingScript Property USKPTracking AutoQuest Property DA13 AutoActor Property Orchendor AutoFormList Property VoicesFollowerAll AutoVoiceType Property FemaleNord AutoQuest Property MS05Start AutoQuest Property MS05 AutoReferenceAlias Property UHToggle AutoQuest Property TGTQ04 AutoReferenceAlias Property Nurelion AutoQuest Property MS12 AutoFaction Property TGNoPickpocketFaction AutoReferenceAlias Property WoundedSoldier AutoFaction Property CWPrepareCityCitizenCityCenterExlusion AutoReferenceAlias Property Froki AutoReferenceAlias Property Haming AutoFaction Property CrimeFactionRift AutoQuest Property MS09 AutoScene Property WhiterunCivilWarArgueScene AutoKey Property MorthalGuardhouseKey AutoReferenceAlias Property Arrad AutoPerk Property MGEnthirVendorPerk AutoQuest Property MG06 AutoGlobalVariable Property GameDaysPassed AutoGlobalVariable Property USKPMS06StartDay AutoQuest Property MS06Start AutoQuest Property MS06 AutoFunction Process()    ;Bug #12889 - FemaleNord voice type is not available, preventing some NPCs from being hired as stewards.    VoicesFollowerAll.AddForm(FemaleNord)        ;Abort this if chargen is not sufficiently advanced. We do not have any bugfixes for the cart ride scene in Helgen.    if( MQ101.GetStage() < 70 )        USKPTracking.LastVersion = 133        Stop()        Return    EndIf    ;Orchendor can show up dead yet not trigger the quest to advance.    if( DA13.GetStageDone(40) == 1 && DA13.GetStageDone(75) == 0 )        if( Orchendor.IsDead() )            DA13.SetStage(75)        EndIf    EndIf    ;Bug #12953 - Investingating the college after finding the book skips stage 75 and goes directly to 90. Previous bug fix only caught stage 75.    if( MS05.GetStageDone(90) == 1 )        if( MS05Start.IsRunning() )            MS05Start.SetObjectiveCompleted(10)            MS05Start.Stop()        EndIf    EndIf        ;Bug #12832 - Uttering Hills Cave is not returned to normal use after TGTQ04.    if( TGTQ04.GetStageDone(200) == 1 )        UHToggle.TryToDisable()    EndIf        ;Bug #1453 - Nurelion needs to get added to TGNoPickpocketFaction after MS12 is done.    if( MS12.Getstage() >= 100 )        Nurelion.TryToAddToFaction(TGNoPickpocketFaction)    EndIf        ;Bug #13021 - Wounded soldier from the temple could get pulled into a CWPrepareCity alias.    WoundedSoldier.TryToAddToFaction(CWPrepareCityCitizenCityCenterExlusion)        ;Bug #13027 - Froki and Haming have no crime faction and thus no reaction to werewolves or the Dawnguard vampire lord form.    Froki.TryToAddToFaction(CrimeFactionRift)    Froki.GetActorReference().SetCrimeFaction(CrimeFactionRift)    Haming.TryToAddToFaction(CrimeFactionRift)    Haming.GetActorReference().SetCrimeFaction(CrimeFactionRift)        ;Bug #12720 - Fralia's argument scene should not play past MS09 stage 10.    if( MS09.GetStage() >= 10 )        WhiterunCivilWarArgueScene.Stop()    EndIf        ;Yep, the other field CO needed one too. Imagine that.    Arrad.GetActorReference().AddItem(MorthalGuardhouseKey)        ;Bug #6693 - If you don't speak to Enthir before becoming Archmage, you can't trade with him without completing the Thieves Guild "Hard Answers" quest.    if( MG06.GetStage() >= 60 )        PlayerRef.AddPerk(MGEnthirVendorPerk)    EndIf        ;Improved fix for MS06 level 81 bug    if( MS06Start.GetStageDone(250) == 1 && MS06.GetStageDone(5) == 0 )        int DayV = GameDaysPassed.GetValueInt()        USKPMS06StartDay.SetValue( DayV + 7 )    EndIf        debug.trace( "USKP 1.3.3 Retroactive Updates Complete" )    USKPTracking.LastVersion = 133    Stop()EndFunction

Some things have to be set regardless. Other things only need to be touched if the user is past that point in the game. The way we have this set up is through a quest that has an alias attached to the player, and a script that runs the whole show:

Spoiler
Scriptname USKP_VersionTrackingScript extends Quest  int Property LastVersion Auto;Yes, this list of quests will probably get tedious as time goes on.USKPOnload02Script Property Retro103 AutoUSKPOnLoad04aScript Property Retro110 AutoUSKPOnLoad05Script Property Retro120 AutoUSKPRetroactive121Script Property Retro121 AutoUSKPRetroactive122Script Property Retro122 AutoUSKPRetroactive123Script Property Retro123 AutoUSKPRetroactive124Script Property Retro124 AutoUSKPRetroactive125Script Property Retro125 AutoUSKPRetroactive126Script Property Retro126 AutoUSKPRetroactive127Script Property Retro127 AutoUSKPRetroactive130Script Property Retro130 AutoUSKPRetroactive131Script Property Retro131 AutoUSKPRetroactive132Script Property Retro132 AutoUSKPRetroactive133Script Property Retro133 AutoEvent OnInit()    ;Only fires once, assumes that none of the retro-scripts have fired. They chain-fire each other, so only start the oldest one here.    LastVersion = 0    ProcessRetroScripts()EndEventFunction ProcessRetroScripts()    if( LastVersion < 133 )        if( LastVersion < 103 )            Retro103.Process()        elseif( LastVersion < 110 )            Retro110.Process()        Elseif( LastVersion < 120 )            Retro120.Process()        Elseif( LastVersion < 121 )            Retro121.Process()        Elseif( LastVersion < 122 )            Retro122.Process()        elseif( LastVersion < 123 )            Retro123.Process()        Elseif( LastVersion < 124 )            Retro124.Process()        Elseif( LastVersion < 125 )            Retro125.Process()        Elseif( LastVersion < 126 )            Retro126.Process()        Elseif( LastVersion < 127 )            Retro127.Process()        Elseif( LastVersion < 130 )            Retro130.Process()        Elseif( LastVersion < 131 )            Retro131.Process()        Elseif( LastVersion < 132 )            Retro132.Process()        Elseif( LastVersion < 133 )            Retro133.Process()        EndIf    EndIfEndFunction

Scriptname USKP_VersionTrackingPlayerAliasScript extends ReferenceAlias  USKP_VersionTrackingScript Property USKPTracking AutoEvent OnPlayerLoadGame()    USKPtracking.ProcessRetroScripts()EndEvent

It might look a bit complex, but it works well and hasn't caused us any faults so far.

User avatar
Carolyne Bolt
 
Posts: 3401
Joined: Mon Jul 10, 2006 4:56 am


Return to V - Skyrim