Modding help

[Balor64]

I'm working on a mod that I would like to be able to store a couple variables so that even if the mod is disabled, the file is saved, and then the mod is reenabled, the mod will still remember the values of those variables. I also need to have the mod be able to change those variables, so game settings won't work. Ideally, this should be unlikely to conflict with another mod, and I'd rather not use OBSE if I can avoid it. I've come up with several ways to do this, but I'm not sure which to try.

• Using OBSE, I think I could change the name of some random piece of scenery, look it up later, and do different things depending on what the name is. Downsides are that the name is a string, not a number, making it harder to work with, and that it obviously requires the user to have OBSE.
  
• I've read that stuff created using placeatme never disappears, so I might be able to do something with that and changing various values about the copied actor, such as strength, level, and health. I'm not sure how to get the mod to remember the ID code for the actor though.
  
• I could also use npcs that appear in-game (easy to get the ID that way) and change values that they never use. For example: Acrobatics, alchemy, armorer, mercantile (unless the npc is a merchant), and spell skills that they have no spells for. I think this npc would have to be both essential and non-leveled though, or the skills might be reset.
  
• I think the best way to do this might be to appropriate variables from other scripts that are no longer used. The tutorial quest must include many variables that aren't used once you've finished it, and there might also be a few test scripts that are never used in-game, much like how the testing hall is never supposed to show up. Does anyone know of any of these?
  

Has anyone ever tried this before? Am I being clear enough in my explanations? Do you have any suggestions on ways to do this?

[David Brasher]

You have some interesting ideas. It is frustrating that TES CS is so weak on variable usage. It is like they never thought anyone would want to use a variable. It can be ugly and messy, but I have used quest items that you cannot drop to carry "variables" over from one play session to the next. The script will eventually remove these items at the proper time, so your inventory doesn't get choked with quest items.

 

Using quest stages as your variables is great as long as things proceed in an orderly fashion in one direction only for a limited period of time.

 

I attempted to use faction ranks of NPCs as variables, but it proved to be unreliable.

 

Placeatme is taboo. People hate it because it creates savegame bloat, and in extreme cases, savegame bloat can make a savegame inopperative so that the player has to give up and start a new character.

 

I guess it depends on how many variables and in what context. There is also the question of aesthetics, functionality, and plausibility. I am sure there must be some way to do what you are trying to do in an acceptable and pleasing manner.

[Balor64]

You have some interesting ideas. It is frustrating that TES CS is so weak on variable usage. It is like they never thought anyone would want to use a variable. It can be ugly and messy, but I have used quest items that you cannot drop to carry "variables" over from one play session to the next. The script will eventually remove these items at the proper time, so your inventory doesn't get choked with quest items.

I'd rather the information be hidden from the player, but maybe I could do this with some container/npc's inventory.

 

Using quest stages as your variables is great as long as things proceed in an orderly fashion in one direction only for a limited period of time.

No such luck, since one variable will be jumping to a random number between 1-30ish repeatedly.

 

I attempted to use faction ranks of NPCs as variables, but it proved to be unreliable.

It wouldn't allow very large numbers anyway.

 

Placeatme is taboo. People hate it because it creates savegame bloat, and in extreme cases, savegame bloat can make a savegame inopperative so that the player has to give up and start a new character.

I thought it was fine as long as you don't use it repeatedly. I would only have used it once.

 

I guess it depends on how many variables and in what context. There is also the question of aesthetics, functionality, and plausibility. I am sure there must be some way to do what you are trying to do in an acceptable and pleasing manner.

I'm working on a mod that replaces the sigil stones, and I'd like to toss in a feature that pre-generates the next stone. That way the player can't just save/load to get whichever one he wants. It's probably excessive to make the mod remember which one comes next even after a clean save, but I like to be thorough. As I said earlier, I'd also like this to be invisible to the player, or he'll know which one comes next. I've got a couple other features I'm thinking about, but it's not very important that those be able to store information like this. If I can get this to work though, I might use something similar for any other mods I write.

[Argomirr]

You could use Pluggy's (a plugin for OBSE) INI functions; this allows you to store data outside the game, so it isn't affected by changes made to savegames and this way you prevent savegame bloating. It's also a reliable way of storing data.

 

Only downside is that you need to install Pluggy, something that I never managed to do...

 

Another way do this would be to add (vanilla) items to unused containers (such as the zombie in the tutorial dungeon), using them as variables. Because the zombie's a quest item and you're using vanilla items, they should stay on its corpse even if you disable the mod. Of course, they won't show up in other saves this way.

 

Good luck! :thumbsup: