Plugins and Dependencies

[NorthWolf]

Normally I tend to be overly verbose regarding things, so here's a quick summary of my problem:

 

I'm using a NVSE + GECK Power-Up enabled v1.3 GECK. I was attempting to do a scripted Project Nevada patch, to add visors to an armor pack. It looked simple, so I loaded up the .esm/.esp files as such:

 

FalloutNV.esm

Project Nevada - Core.esm

Desert Armor.esp

 

I began the patch by adding a quest, PNxPDesertArmorPatch, and the associated script, PNxPDesertArmorPatchSCRIPT. I'll leave the script's contents out of the way for the moment because they are peripheral to the real problem. I saved and proceeded to test. The script did not add the visors at all. I tested for a while, eventually opening the script in FNVEdit, at which point I noticed Desert Armor.esp was not considered a master. As a result, the script file had several references that failed. By manually changing these references (only the mod portion of the index needed to be changed after I added Desert Armor.esp as a master), the script worked in-game and seems exactly what I want.

 

I don't understand, because after testing, whenever I save the patch file in GECK it discards Desert Armor.esp as a master and causes a plethora of problems. I am guessing this is part of optimization and the scripts are simply not monitored for reference counting, but I thought the GECK automatically made all files loaded for a new plugin master of that particular plugin. Notably both the .esm files remained masters throughout, including Project Nevada - Core.esm.

 

Does anyone know what I'm doing wrong here? I want to churn out these scripts and having to mess with references in FNVEdit is basically a brick wall to me.

 

Also, the script, which works perfectly fine with its references manually changed before anyone holds it suspect:

 

scn PNxPDesertArmorPatchSCRIPT

Begin GameMode

if getGameLoaded == 0
  return
endif

; BASE (RED) DESERT HELMET
listAddForm PNxCVisorOverlay06NCRRangerList RarasDesertHelmet
listAddForm PNxCVisorConditionVisualsList RarasDesertHelmet
listAddForm PNxCVisorVisionEffect01List RarasDesertHelmet
listAddForm PNxCVisorVisionEffect03List RarasDesertHelmet

listAddForm PNxCVisionModeNightList RarasDesertHelmet
listAddForm PNxCVisionModeHeatList RarasDesertHelmet

; BLUE DESERT HELMET
listAddForm PNxCVisorOverlay06NCRRangerList RarasDesertHelmetb
listAddForm PNxCVisorConditionVisualsList RarasDesertHelmetb
listAddForm PNxCVisorVisionEffect01List RarasDesertHelmetb
listAddForm PNxCVisorVisionEffect12List RarasDesertHelmetb

listAddForm PNxCVisionModeNightList RarasDesertHelmetb
listAddForm PNxCVisionModeHeatList RarasDesertHelmetb

;GREEN DESERT HELMET
listAddForm PNxCVisorOverlay06NCRRangerList RarasDesertHelmetg
listAddForm PNxCVisorConditionVisualsList RarasDesertHelmetg
listAddForm PNxCVisorVisionEffect01List RarasDesertHelmetg
listAddForm PNxCVisorVisionEffect05List RarasDesertHelmetg

listAddForm PNxCVisionModeNightList RarasDesertHelmetg
listAddForm PNxCVisionModeHeatList RarasDesertHelmetg

;VIOLET DESERT HELMET
listAddForm PNxCVisorOverlay06NCRRangerList RarasDesertHelmetv
listAddForm PNxCVisorConditionVisualsList RarasDesertHelmetv
listAddForm PNxCVisorVisionEffect01List RarasDesertHelmetv
listAddForm PNxCVisorVisionEffect13List RarasDesertHelmetv

listAddForm PNxCVisionModeNightList RarasDesertHelmetv
listAddForm PNxCVisionModeHeatList RarasDesertHelmetv

;WHITE DESERT HELMET
listAddForm PNxCVisorOverlay06NCRRangerList RarasDesertHelmetw
listAddForm PNxCVisorConditionVisualsList RarasDesertHelmetw
listAddForm PNxCVisorVisionEffect01List RarasDesertHelmetw
listAddForm PNxCVisorVisionEffect02List RarasDesertHelmetw

listAddForm PNxCVisionModeNightList RarasDesertHelmetw
listAddForm PNxCVisionModeHeatList RarasDesertHelmetw

;YELLOW DESERT HELMET
listAddForm PNxCVisorOverlay06NCRRangerList RarasDesertHelmety
listAddForm PNxCVisorConditionVisualsList RarasDesertHelmety
listAddForm PNxCVisorVisionEffect01List RarasDesertHelmety
listAddForm PNxCVisorVisionEffect10List RarasDesertHelmety

listAddForm PNxCVisionModeNightList RarasDesertHelmety
listAddForm PNxCVisionModeHeatList RarasDesertHelmety

; Refresh visor script to register any changes
set PNxCVisorMain.update to 1

return

End

Edit: In retrospect that wasn't much of a quick summary and instead was horribly verbose. D'oh. Hopefully someone will read enough to help cure my stupid anyway. :sweat:

Edited June 25, 2011 by NorthWolf

[ripple]

In the past I've had problems with referencing .esp as master via the GECK. In fact, I don't think I've ever managed to (anyone else?). It might be something as simple as that? Have you tried making using another esp as master to see if that is saved by the GECK, just for testing purposes?

[NorthWolf]

:wallbash:

 

Feeling pretty stupid. Yeah, I guess you can only set .esp's to masters in FNVEdit... guess that made me assume you could do it in the GECK, because, you know... no reason. Some of the glitches I got were pretty cool and confusing, at least... the other patch I did caused some of the (apparently) compiled references to disappear completely.

[NorthWolf]

Alright, well, even though I can't do it a nice way, I've been able to hack it in through FNVEdit using reference swapping to completely avoid the issues that seem to crop up as a result of referencing .esp material as another .esp. It works really well and does exactly what I want it to do, which is play nicely with my other Project Nevada enabled mods. If there's a cleaner way to do this that somebody knows of, please, let me know.

[Quetzlsacatanango]

Make the esp a master via fnvedit. Don't change the file extension.

Build your plugin.

Once you're done, you can change it back to esp, it will still work as if it was en esm, users can use it without masterizing, etc.. Just don't edit your plugin while the "master" is an esp.

[davidlallen]

I would have been willing to swear that there is no way to reference an object in the first esp from a second esp. I thought the only way to do it was to make the first one a master (which is a one click change in fnvedit, btw). Can you describe more about your method? What happens if the user does not have the first mod installed? This will defeat a lot of the dependency management stuff in the game and in FOMM. Both of these try to arrange your load order so that masters come before their related plugins. Your users will have no way to manage this automatically, and many people may complain due to a user error where they put the first mod lower in their load order.

[Quetzlsacatanango]

Assuming this is directed at me...

 

I would have been willing to swear that there is no way to reference an object in the first esp from a second esp. I thought the only way to do it was to make the first one a master (which is a one click change in fnvedit, btw).

That's what I do. It is a master when you build your plugin. After that it doesn't matter.

Can you describe more about your method? What happens if the user does not have the first mod installed?

It will crash at the loading screen I assume.

This will defeat a lot of the dependency management stuff in the game and in FOMM. Both of these try to arrange your load order so that masters come before their related plugins. Your users will have no way to manage this automatically, and many people may complain due to a user error where they put the first mod lower in their load order.

That's what readmes are for I guess.

 

This is exactly what I did for my Rhyme Renegade mod. NVBII is an esp, not an esm, and I needed a way to reference it. You can check it out if you are skeptical.

If you are going to open it in geck, make sure nvbII is masterized first, or it will lose the reference.

[NorthWolf]

I would have been willing to swear that there is no way to reference an object in the first esp from a second esp. I thought the only way to do it was to make the first one a master (which is a one click change in fnvedit, btw). Can you describe more about your method? What happens if the user does not have the first mod installed? This will defeat a lot of the dependency management stuff in the game and in FOMM. Both of these try to arrange your load order so that masters come before their related plugins. Your users will have no way to manage this automatically, and many people may complain due to a user error where they put the first mod lower in their load order.

Okay, well, this is surprising. After reading your post I tried testing it with an improper load order; I had the patch below the .esp originally because I fully expected a crash if I did anything else. Surprisingly, the game not only loaded successfully, but the patch worked exactly the same as before. I'll test more but it appears to not matter where I place this thing in the .esp order, even if it's above its master .esp it loads successfully and doesn't crash my game.

 

I can describe the method, which is as follows. Note that I'd not call this "clean" by any stretch of the imagination.

 

1.) Load the master files you want for the .esp. In my case, that was:

 

- FalloutNV.esm

- Project Nevada - Core.esm

- DesertArmor.esp

 

2.) Create the script with the references. Here's my example:

 

scn PNxPDesertArmorPatchSCRIPT

Begin GameMode

if getGameLoaded == 0
  return
endif

; BASE (RED) DESERT HELMET
listAddForm PNxCVisorOverlay06NCRRangerList RarasDesertHelmet
listAddForm PNxCVisorConditionVisualsList RarasDesertHelmet
listAddForm PNxCVisorVisionEffect01List RarasDesertHelmet
listAddForm PNxCVisorVisionEffect03List RarasDesertHelmet

listAddForm PNxCVisionModeNightList RarasDesertHelmet
listAddForm PNxCVisionModeHeatList RarasDesertHelmet

; Refresh visor script to register any changes
set PNxCVisorMain.update to 1

return

End

 

3.) Save the .esp, which for me we can say is named DesertArmorPatch.esp, then close the GECK completely.

 

4.) Open FNVEdit, with these plugins yet again:

 

- FalloutNV.esm

- Project Nevada - Core.esm

- DesertArmor.esp

- DesertArmorPatch.esp

 

5.) Set DesertArmorPatch.esp to use DesertArmor.esp as a master.

 

6.) Navigate to the scripts in DesertArmorPatch.esp, then open the script which is currently not operating. Then, check the bottom of the properties to see its list of references. Some of them will be broken.

 

7.) Change the indicies to match the content in DesertArmor.esp. In the two cases I did this, this was as easy as changing the mod portion of the index to match the master index. I.e. [03000ADE] becomes [02000ADE].

 

8.) Save the mod. It's now complete, but you cannot open and save it in GECK or it will not work.

 

Originally I pursued this method simply because it was intended for personal use only... I didn't need it to be user friendly. However, as noted earlier, it doesn't seem effected by load order at all.

Edited June 25, 2011 by NorthWolf