Stuck after removal of mods

[The Sith'ari]

OK, I installed some mods, then I played the game and saved. Then, before I started a new game, I removed some mods. The next time I tried to load some of the game saves I made BEFORE i removed the mods, the game always cracked. But just some, not all game saves fail to load. The problem is, I don't know WHICH MOD is causing the problem. Are there particularly some files that must be identical when making the save and when reloading? If so, maybe I can restore those files and try loading the saves again. Anyone has any idea?

[ChAiNz.2da]

Yeah, anytime the game saves, it loads anything a mod uses/adjusts into the savegame informations as well..

 

When you're restarting that save and it can't find those (now missing) files, the game gets grumpy and decides to throw a fit.. thusly crashing..

 

You would either need to re-install those mods you had deleted, or retire that particular savegame...

 

The trouble is, when you go to re-install those mods... unless you re-install in proper order (and if you've used the TSLPatcher) the .2da entries may not be in proper order which might cause even more problems once the game loads... again, assuming you used mods that used .2da files. If not, might be alot easier to get up & running... *

 

Probably not what you want to hear, but unless you only need to re-install 2-3 mods.. I personally would retire the saves..

 

If you think you might know the items giving you trouble, you could try using KSE to delete the modded items from your Party's inventory.. assuming it's items causing it, KSE would more than likely rescue your save

 

KotOR Savegame Editor:

http://www.starwarsknights.com/tools.php

 

 

EDIT: Hold on a tick... that may not be right. Assuming a mod uses the TSLPatcher you might be in better/safer waters since it would change the .uti as well... OK, sorry about that... I haven't had my coffee yet hehehe

 

* EDIT 2: Unstriked my edit.. thanks Darkkender for the reminder

[Darkkender]

EDIT: Hold on a tick... that may not be right. Assuming a mod uses the TSLPatcher you might be in better/safer waters since it would change the .uti as well... OK, sorry about that... I haven't had my coffee yet hehehe

 

Actually you should unstrike the comment and remove the edit Chainz.2da. The reason being that the GFF files that the patcher modifies get saved as part of the save game data. So before when the patcher patched everything lets say the item pointed to baseitems entry "340". Now lets say after you remove the mods and begin to re-install the mods again you change your installation order, now maybe your baseitem entry points to "290" instead of "340" The save game data is still looking for "340" which may not be there at all anymore. So the TSLpatcher does not bring you into safer waters for saved game data.

[ChAiNz.2da]

Hmm.. does it save line entry data? Or just the fact that the item is physically in the inventory and then it uses in-game resources to track which line the uti is pointing to (like dynamically linking)..?

 

Wasn't sure so I thought I'd strike it out until someone corrects me hehehe..

[Darkkender]

The ".sav" file is an ERF file format. So likely it copies the the gff files into the ERF file and as the game progresses everytime you save or it auto saves it rebuilds the erf file with a copy of the gff file. Just like if you or I were building an area module. However unlike a module file the data contained within the save file has priority before the data in the overide folder. This is like the process we deal with when building a mod itself. If your adding new stats to the item your player is wearing you have to use the giveitem cheat for the game to load a new copy of the item based off of the updated data in the overide folder.

 

 

Now for your items that are saved in the ".sav" file all of them are linked with 2da entries from before the save. If the 2da entry changes after the save you endup having crashes or glitches depending on what 2da file the gff file is trying to point too. Big 2da files that like to produce crashes are things like appearance, heads, portraits and sometimes baseitems.2da. The reason you'll get crashes with the above 2da files is because you will have your PC showing references to data from these 2da files. Such as the lightsaber in your hand, if it's uti file is now pointing to a non-existant 2da entry it will crash the game. The same goes with Appearance and Heads entries. Portraits can give you mixed results.

 

If the items or npc's saved in the save file have references to non-existant entries they will likely not spawn or in the case of items spawn null grenades depending. However you can also receive game crashes.

 

Now of course if your mods are only texture files you can hot swap them within the game because the textures I believe are refreshed every gamecycle maybe it's got a different rate.

[ChAiNz.2da]

This is like the process we deal with when building a mod itself. If your adding new stats to the item your player is wearing you have to use the giveitem cheat for the game to load a new copy of the item based off of the updated data in the overide folder.

Duurrrr...

 

You're absolutely right! I can't believe I totally forgot about that and the many null-nades / old-stat items I encountered in the good ole days...

 

Good point... guess I'll go unstrike that comment.. hehehe

[stoffe]

The ".sav" file is an ERF file format. So likely it copies the the gff files into the ERF file and as the game progresses everytime you save or it auto saves it rebuilds the erf file with a copy of the gff file. Just like if you or I were building an area module.

 

Not quite. Just to clarify, The UT* files are usually** Template files, i.e. they don't represent an object in a game world, but a blueprint of information used to create an object in the game world. E.g. an UTI file is used when the item is first created into the game world, either when the area loads (for pre-placed items), when a script spawns them, or if the giveitem console command spawns them.

 

In either way, an in-world instance of the object is created using the data in the UT* file, which is not referenced any more after that. Where this instance is stored depends on where the item is placed. If it's in a creature's inventory, all it's data is added as a STRUCT to the ItemList sub-field of that creature's in-world instance. The creature's in-world instance in turn is stored as a STRUCT field in the Creature List list-field of the area-instance GIT-file of the area it exists in. (GITs are used both for area templates and in-world area instance data.)

 

Items equipped on a character is similarily stored in structs under their Equip_ItemList fields. The party's inventory is stored separately in the inventory.res file. This is also a GFF format file which contains an ItemList field that holds in in-world instance data for all items in the party inventory.

 

I.e. there are no UTI files per-se inside the savegame, the instance data (whose GFF field layout differs a bit from the UTI template data) is stored as STRUCTs in LIST fields inside other GFF format files (usually the area GIT file for placeables and non-party NPCs).

 

 

All this technobabble aside, the result is just as you mentioned. The BaseItem references for in-world instances of items and Appearance_Type of in-world instances of creatures are no longer read fron the UTI/UTC files from which they were made, but is stored within those STRUCT fields in the GIT, RES and party table UTC files, making maintaining compatibility with external references whose values suddenly change very difficult.

 

Static, non-gameobject resources (DLG files, audio-files, scripts, models, textures etc) are never stored in the savegame though, and can safely be messed with without invalidating a savegame.

 

** In one case UTC files are stored in the savegame. The party table content is stored as a set of UTC files, which are generated dynamically. Those files are used to spawn your party members back into the game world when you add them to the party.

 

However unlike a module file the data contained within the save file has priority before the data in the overide folder.

 

I think this is not quite true. The override folder seems to have higher priority than save games, which results in a quite broken game if you put an area's GIT file in override, since the template file would override the in-game area instance GIT file with the same name found in the savegame, thus resulting in the area state being "frozen" where nothing the player does seems to be saved.

 

* * *

 

Anyway, in my experience the most common causes for crashing savegames after a mod has been removed are these situations:

1. A character in the savegame knew a feat or force power that no longer is specified in the game data 2DAs.
   
2. A character or item uses an appearance that no longer is specified in the model 2DAs (baseitems.2da, appearance.2da).
   

 

Generally the game engine doesn't handle very gracefully a situation where it is asked to look up a non-existing line in a 2DA file. It tends to crash whenever that happens.

[The Sith'ari]

Wow, that's complicated! as i'm new in modding.

I'll try to understand it all though, might as well boost my knowledge of modding. Thanks for the help!