What can I change when updating my mod?

[thousande]

> Hmm. Would that cause some case issues? That's kinda, hmm curious.

 

Mostly cosmetic, I believe. Eg. you print the string on the screen and the casing is wrong.

Your code says the string is capitalized, but the string is always printed in lowercase because a mod before yours (load order) creates the same value in lower case.

Head scratching may occur.

Strings are case-insensitive so if-tests will be true if "gold" == "Gold"

If the string is just used for presentation / screen you may get around it by adding a space before the variable, but then you have to make sure no one else uses it for logic/if/control flow :wink:

 

More details here,

https://github.com/joelday/papyrus-lang/wiki/Papyrus-Types

(See String Literals / Character casing)

[NikaCola]

Having released hundreds (actual number) of in place updates for my complex scripted mods, the quick off the cuff (not comprehensive OCD proof) guidance I can give is;

 

You can ADD new forms, objects, scripts and script elements no problem.

 

You CAN NOT change:

Start game enabled quests, except attached scripts, because they can not be stopped and restarted.

Base game forms that have instantiated ObjectReferences in the world.

 

You can change existing things if you can stop/clear and restart them and then test the sh1t out of them, such as;

Scripts (to add new properties, variables, functions) but not change existing stuff like Structs unless you are EXTREMELY thorough in testing.

Non start game enabled Quests (adding new Aliases/Scene/Dislogue is fine, changing existing stuff is inconsistent).

 

If I have to change existing quest/script stuff I typically migrate to a new quest/script (leaving the old detritus in place for pointers) to ensure continuity.

 

Take a look at how Bethesda patch the base game through the Patch_1_* quests.

 

 

This is really comprehensive and good advice, thanks for posting it!

[SameOldBard]

Having released hundreds (actual number) of in place updates for my complex scripted mods, the quick off the cuff (not comprehensive OCD proof) guidance I can give is;

 

You can ADD new forms, objects, scripts and script elements no problem.

 

You CAN NOT change:

Start game enabled quests, except attached scripts, because they can not be stopped and restarted.

Base game forms that have instantiated ObjectReferences in the world.

 

You can change existing things if you can stop/clear and restart them and then test the sh1t out of them, such as;

Scripts (to add new properties, variables, functions) but not change existing stuff like Structs unless you are EXTREMELY thorough in testing.

Non start game enabled Quests (adding new Aliases/Scene/Dislogue is fine, changing existing stuff is inconsistent).

 

If I have to change existing quest/script stuff I typically migrate to a new quest/script (leaving the old detritus in place for pointers) to ensure continuity.

 

Take a look at how Bethesda patch the base game through the Patch_1_* quests.

 

Again you have lot's of very helpful information.

 

Thanks SKK50.

 

Regarding the very specific case of the structs. You think there is risk if I add a field, let's say a float, to a Struct while updating the mod? Of course I will test it a lot. But have you done that in the past and had issues?

[SameOldBard]

> Hmm. Would that cause some case issues? That's kinda, hmm curious.

 

Mostly cosmetic, I believe. Eg. you print the string on the screen and the casing is wrong.

Your code says the string is capitalized, but the string is always printed in lowercase because a mod before yours (load order) creates the same value in lower case.

Head scratching may occur.

Strings are case-insensitive so if-tests will be true if "gold" == "Gold"

If the string is just used for presentation / screen you may get around it by adding a space before the variable, but then you have to make sure no one else uses it for logic/if/control flow :wink:

 

More details here,

https://github.com/joelday/papyrus-lang/wiki/Papyrus-Types

(See String Literals / Character casing)

 

Unless another mod used " gold" before you hehe.

 

Cool, I will read the link

[SKKmods]

 

Regarding the very specific case of the structs. You think there is risk if I add a field, let's say a float, to a Struct while updating the mod? Of course I will test it a lot. But have you done that in the past and had issues?

 

 

Yes I have tried to extend script level structs and can not get it to work if it has been used. That's a case of leave the old one (zero out usage) and copy the info to a new extended struct.

 

You can look at my Ammo-O-Matic mod for that which uses structs as fake ammo constructible object records and needed in lifecycle updates to include DLC requests.

 

 

 

Struct AmmoDataStructure
	FormList	AmmoFormList	;The Formlist this ammo is on
	Int   		iIndex 		;The Formlist index this ammo is on
	String		sName     	;Text Ammo Name
	Ammo 		ThisAmmo	;pSKK_AOMAmmoDataIndex.GetAt(iIndex) or AmmoFormList.GetAt(iIndex) to allow DLC mapping 
	Bool 		AmmoIsAvailable	;To allow DLC or lockout 
	FormList 	AmmoCMPO 	;SKK_AOMAmmoScrapBallisticCMPO	c_Components 		needed to make ammo
	FormList 	Ammo_Scrap	;SKK_AOMAmmoBallistic_Scrap 	c_Components_Scrap	generated from scrapping ammo
	Int 		AmmoInput	;Ammo needed to make 1 Ammo_Scrap
	Int 		AmmoCMPONeeded	;Ammo_CMPO needed to make one box
	Int 		AmmoOutput	;Size of ammo box produced 
	Perk		PerkNeeded    	;if enforced
	ReferenceAlias	AmmoAlias	;To force the name into messages
	GlobalVariable  AmmoCount 	;The counter
EndStruct

Struct ScrapDataStructure
	Int 		iIndex
	FormList	ScrapCMPO	;same as AmmoCMPO 
	FormList	Scrap_Scrap	;same as Ammo_Scrap
	Int		iQuantity	;The number that can be crafted in the current container
EndStruct

AmmoDataStructure[]  Property AmmoData  Auto 
ScrapDataStructure[] Property ScrapData Auto  

 

 

[SameOldBard]

Well... that certainly complicates things for me.

 

My idea is to update my mod with specific parts as to avoid taking too long to come up with eveything until I would reach 1.0. That would be when the mod would be feature complete. I am testing now the first update after adding the needed data and a few minor features, but for it to work properly I need to add a float field to my target Struct... if it can be a problem for it, it might be for the rest of the data of the future updates as well.

 

I just did not want to have to consider all possible issues now for all said modules as it will take me way more time.

 

=/

[SKKmods]

Just to add for posterity incase someone digs this up through the power of search.

 

Adding new things like scripts is fine, but you need to consider if they will be attached to things.

 

Example: A quest has an existing RefCollectionAlias that holds all current active workshop settler actors when the game saves. You attach a new script to the RefCollectionAlias, load the save ... but the script isn't firing. Probably because the aliasscript:objectref pointers are generated when actors are added to the aliasscript. So part of the OnPlayerLoadGame update mechanism needs to remove all the actors and re-add them so the script applies.

 

Example from my standardised OnPlayerLoadGame update function;

 

 

 

Function RunUpdates()

If (bUpdatesRunning == FALSE) && (pSKK_CSETVersion.GetValue() < fScriptVersion) 
	bUpdatesRunning = TRUE
	
	If (pSKK_CSETVersion.GetValue() < 19)
		(pSKK_CSETQuest as SKK_CSETWorkshopListScript).Shutdown() ;script demised unregister all events and clear all variables
		(pSKK_CSETQuest as SKK_CSETFindWorkshopScript).Shutdown() ;script demised unregister all events and clear all variables
		Alias_SettlersThisWorkshop.RemoveAll()                    ;clear to attach new scripts
		If (pSKK_CSETEnabled.GetValue() == 1)
			SwitchEnabled()                                   ;this will add local settlers	again
		EndIf
	EndIf
		
	pSKK_CSETVersion.SetValue(fScriptVersion)
	bUpdatesRunning = FALSE	
	
EndIf

EndFunction