What can I change when updating my mod?

[SameOldBard]

So, I am working on my mod first update.

 

What can I change on it to make it still compatible with the previous installed version?

 

I am testing it locally and etc. But I would like to know what I can and can't do.

 

Can I change a function parameters? Or do I need to keep the same function signature?

I guess I can change what I am doing inside a function and that I should not change event's callbacks.

Can I add new fields to my structs?

 

What else I must not do? My mod makes no changes to cells or world data. It only adds new forms, mostly quests, globals and terminals.

 

Thanks a lot!

SameOldBard

[markusm1000]

My mod makes no changes to cells or world data.

These things (landscape, statics) you can change.

 

 

 

It only adds new forms, mostly quests, globals and terminals.

But you can't change scripts, quests, movable statics, outfits, activators etc. - all the things, which can be changed ingame. They are saved in the SaveGame as soon as they have been used ingame.

The SaveGame is the ultimate SuperMod, everytime the last in the loadorder, wins every conflict, overrules everything else.

[SameOldBard]

So, If I have a function which prints "ABC" at version 1.0. and I change it so it prints "DEF" at 1.1, it would still print "ABC" or what would happen?

[markusm1000]

So, If I have a function which prints "ABC" at version 1.0. and I change it so it prints "DEF" at 1.1, it would still print "ABC" or what would happen?

 

This depends on how you created your function and variables(local/global) and whether this function was called ingame before the changes.

 

print("ABC") changed to print("DEF") should work.

 

a$ = "ABC"

print(a$)

 

changed to

 

a$ = "DEF"

print(a$)

 

may not work because the SaveGame says a$ is "ABC".

[SameOldBard]

Ok. That makes sense.

 

So changing logic which is not based on stored that works.

 

How about adding fields to the model? Is it ok to add a field to a custom struct?

 

And thanks for the answer so far!

[SameOldBard]

Also, let's say I have a function like:

 

Function ConcatStrings(string a, string b)

 

And I add a param string C. Would it cause issues?

[markusm1000]

Function ConcatStrings(string a, string b)

 

And I add a param string C. Would it cause issues?

 

I don't know, if you can extend functions parameters on runtime.

[thousande]

You should do some testing :smile: Changing a string literal in a print statement should work, I guess.

 

A bit related. String variables are stored in a case insensitive string cache.

 

; A mod creates a string value.

someoneElsesString = "Gold"

...

; Then my mod creates a string value.

myString = "gold"

 

Instead of creating a new entry in the cache, myString value will just point to someoneElsesString value.

[SameOldBard]

 

Function ConcatStrings(string a, string b)

 

And I add a param string C. Would it cause issues?

 

I don't know, if you can extend functions parameters on runtime.

 

 

 

Ok, I will avoid doing it anyway. Though I might try and make some tests with it.

 

You should do some testing :smile: Changing a string literal in a print statement should work, I guess.

 

A bit related. String variables are stored in a case insensitive string cache.

 

; A mod creates a string value.

someoneElsesString = "Gold"

...

; Then my mod creates a string value.

myString = "gold"

 

Instead of creating a new entry in the cache, myString value will just point to someoneElsesString value.

 

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

 

Anyway, the strings thing were just examples. I am just worried that I can modify existing function to improve performance, fix issues and add new situations as the mod grows.

[SKKmods]

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.