I have two ESPs, and one has some scripts that have properties that point to things in my other ESP file. For some reason, these properties keep getting reset to "none." Am I not allowed to do that? To have properties pointing to other ESPs?

Is there a way to fix this?

i think you can only slave esp's to esm's, as far as i know. if you are using multiple esp's that need to access the same pool of data, what i would suggest is to have the shared data on a esm file and have each esp slave to the master esm, but not to each other. that way each esp can access the same root data without needing to "talk" with each other.

Can I have two ESMs and then have a single ESP that uses objects from both ESMs?

Basically, I have two ESPs that modify and add lots of stuff to the normal game, but they are independent from each other. Then I have a third ESP that checks for dummy perks on the player, added by the other two ESPs when they are loaded. Depending on whether the player has one perk or the other, or both, the scripts in this third ESP does different things. The third ESP doesn't modify anything in the first two ESPs, it only adds new objects that point at new objects in the first two ESPs. The first two ESPs add new content and modify vanilla content.

I am reading now about using wrye bash to master-slave these things. It looks like lots of people make ESMs with a bunch of ESPs that modify the ESM, but I need the reverse, I need two masters and one esp that looks for things from both.

Thanks for the reply!

you can have multiple esm's be the master of a single esp.

for example when you load the CK:
Skyrim.esm
Update.esm
YourMod.esm
YourESP.esp (Active file) - slaves to all 3 and has access to all 3's data


note though that master-slave relationship is one way only.

the master tells the slave what to do, never the other way around. masters never listen to slaves


if you want an additional esp to access the same thing as the slaved esp, you wil also have to slave that new esp to the same esm masters (but not the first esp), and make sure that the info accessed by the second esp is rooted from one or more of the master files. if said information is edited by the first esp, your second esp will have to load AFTER the first esp in order for the info that it accesses be up to date.

Sounds like it should work ok, just so I understand though, when you say masters never listen to slave you mean that my ModInstallHelper.esp can get info (as in, I can have script properties or objects that point to objects) inside MainModA.esm and MainModB.esm?

here's an example setup:


skyrim.esm (master)
mymod.esm (master)

expansionpack.esp (slaved to both)


in mymod.esm - there is a new quest called MyQuest. in MyQuest you have several properties and variables that is edited and queried by expansionpack.esp.


you make a new esp called myarmormod.esp

myarmormod.esp adds a new set of armor, but needs to access the same quest as expansionpack.esp.

myarmormod.esp would then have to be slaved to mymod, and query the same data that expansionpack.esp is editing.


when you play your mod, you should load myarmormod after expansionpack.esp.


but also note, if myarmor mod EDITS anything that expansionpack is already editing, it will overwrite ALL changes of that type that expansionpack makes to mymod.esm.

so make sure that when you have this kind of setup with multiple esp's that you are doing only queries and not actual edits.

you should only have one esp that handles all of the edits for the main esm. all other esp's should query the esm and/or add additional new content that doesnt need to be accessed by other esp's.

Thanks so much! I ran into a problem though.

This is what I am doing: I am making two mods. One physical combat perk overhaul, and one magic combat perk overhaul. Both are independent from one another, and change/add different things.

Since they both replace vanilla perk trees (they do not change the perks, they simply make them inaccessible because they are no longer part of the new perk trees) I need a system to allow players that have already leveled up and have a bunch of vanilla perks to use my mod. If I did nothing, and say a level 25 dude installed the mod, the perk trees would be replaced, the player would have a bunch of the old perks, and would start filling in the new trees on top of his vanilla perks that he has, it would just be a giant mess.

So I made a separate ESP. This esp creates a system when it is first installed where it goes through, removing vanilla perks and counting them, and then giving the player a complex menu system to get a "perk refund" and spend these "points" on the new perks. Since the scripts obviously have to have the new perks from the two other mods in them, I need a way to have this mod be a slave to the other two masters. This mod also handles things that are common to both mods, such as running scripts when the player increases a skill level (which would conflict if each of the original mods tried to do this individually, because SM Event Nodes are wierd.)

The problem here is that having my two original mods be master files for this "helper" esp, is that they are no longer optional, the game will crash if the helper esp that is a slave to both masters is missing either one, which is the whole point of having the helper esp in the first place, as I want to customize the refund system based on which of the two, or both, of the original mods are installed. The reason I need this is because say someone has both the magic and the physical combat mods, and they have perks in both types of skills, I need them to be able to spend refund points from magic trees in physical trees and vica versa. If the two original mods just did this separately, refund points from magical perks could not be transferred over to the new physical perks or vica versa, and that would be a problem.

What should I do about this? Do I need to create dummy versions of the two files, MagicPerkOverhaul.ESM and PhysicalPerkOverhaul.ESM that contain the neccesary perks without implementing them in any way in the game, just so the Helper.ESP can access them and not crash? Then that way someone using MagicPerkOverhaul.ESM and a dummy PhysicalPerkOverhaul.ESM would then replace PhysicalPerkOverhaul with the full version of the file later if they decided they wanted it?

There has to be a better way.

dummy esm's would allow for the control esp to launch properly, but you should read up on how save games handle info in files just to make sure that down the road if a player decides to install the real esm over the dummy, that the info that is edited in the real esm does not behave strangely.

i'm assuming that if you use dummy esm's your control esp that is accessing the would-be data of the real esm is just left as a "placeholder" until the user installs the real esm.


so my only concern with going this route would be what happens to users with existing save games when they do upgrade to the real esm data and what happens to that placeholder data in the savegame file.


ideally if at all possible, you would want to set up a single control-master esm that has root data in place (even if it is not currently being accessed) and the magic and physical combat mods access this root data.

i don't know exactly how you have your mods set up and which data they access, but i think it would be better to have both magic and phycical in the same esm (even if they do not "actively" do what they are supposed to do) and then have separate esp's for the magic and physical combat that "enables" the features already in place in the master esm.

if the master esm contains all data for both magic and physics as well as whatever quests that are supposed to hold the scripts for events and perk distribution, those quests can lay dormant until called into action by the esp.


so basically the entire mod is contained in the esm (which currently does not actively alter the player's stuff), but each esp is just a "light switch" that turns on those features in the esm and then runs the chain of events in your scripts/quests which would then actively change all your player's stats and perk trees. if that makes any sense.


the advantage of this is that either esp stays independent of each other and they each have access to the same data (both physical and magic, and can query both)

Well, it would be the same.

So for example, I have the following files.

PhysicalPerkOverhaul.ESM - Has a bunch of new One Handed perks AND the perks replace the default tree, along with other stuff like changes to vanilla objects.

PhysicalPerkOverhaulDummy.ESM - Has the same One Handed perks, but they are unobtainable by the player in this file.

MagicalPerkOverhaul.ESM - Has a bunch of new One Handed perks AND the perks replace the default tree, along with other stuff like changes to vanilla objects.

MagicalPerkOverhaulDummy.ESM - Has a bunch of new One Handed perks, but they are unobtainable by the player in this file.

Refund.ESP - Has a script that points to all the perks in MagicalPerkOverhaul and PhysicalPerkOverhaul, doesn't care whether the player can normally obtain them or not or anything else in the file, just needs those perks.


Then the user has to have both ESMs, but two versions of each are available depending on whether they actually want to change that aspect of gameplay or not. So really, the dummy ESM would be identical to the real ESM (in both mods) but would not have the required changes to actually implement the new objects into gameplay.

Really, I just do not like this method at all. Is there a way to do this without using ESMs? Does it really break the game if a mod tries to point to something in another file that doesn't exist? If not, is there some way to trick the ESP into thinking the other ESPs are masters when they are not, so if they are not present then I just "work around" those errors with if statements in my script so it never does anything with the data that is missing, if it is missing?

yeah, i don't like the dummy esm route either, but check my edit in the post above and let me know if that is a possibility for your mod.

Unfortunately I don't think that is a possibility. I have come up with another option:

Have 3 versions of the Helper.ESP.

So both my mods would be ESMs, and then each would have their own helper ESP. Then I would develop a third ESP that would "bridge" the gap between the two, and simply explain in a readme which ESP to use. One for one ESM, one for the other, and one if both ESMs are working.

The problem with having all the data in a single ESM and then just "activating" it is that it doesn't help me accomplish what I need to, which is to have a menu system that shows different menus depending on which mod is installed. The menu system could be contained in the single ESM, but I see no way to give version 1 (for only the first ESP) version 2 (for only the second ESP) and version 3 (for both ESPs) since I cant "point" to anything in the ESPs from the ESM.

you can, to a degree.


lets say the esm has the following data:


MagicMenu
CombatMenu
MasterMenu



by itself, the esm does nothing, but it stores the data of all 3 menu messageboxes

you may also need global variables to keep track of which mods are installed. globals would also be in the esm


in the quest/script called "ControlQuest" it has something like this in stage 10 (by default it stays at stage 0 or is not even running)

if MagicInstalled == 1 && CombatInstalled == 0
MagicMenu.Show()

ElseIf MagicInstalled == 0 && CombatInstalled == 1
CombatMenu.show()

ElseIf MagicInstalled == 1 && CombatInstalled == 1
MasterMenu.Show()



so magic.esp changes the following:

global variable MagicInstalled = 1

ControlQuest.SetStage(10)


it will run through the quest and only show the magic menu




then sometime later along the user installs Combat.esp


Combat.esp makes the following changes to the esm:

CombatInstalled = 1

ControlQuest.SetStage(10)


it will run through the conditions again and this time it will run the master menu that has both magic and combat.


of course your scripts and quests will have to be able to account for multiple scenarios where the user has only installed one or the other, or installs either in different order.

but containing the entire mod in the esm allows either esp to access data of each esp (so long as the esp doesnt introduce new data).

because the esps are pointing to the same data on the esm, the value which returns on both esp's will be the same, hence they can query the same data so long as that data is in the shared master.

That is a fantastic idea. Thanks for all your help. I am gunna go with a single ESM, and just put all the spells and quests in there. Then just update it over and over, and release ESPs that will "activate" the mods within the ESM by swapping out vanilla perks in the trees for the ones in the ESM.

I love your idea of using globals to detect when ESPs are installed to modify the menu in the ESM.

That should cut it down to 3 files.