Just ran FNVEdit and tried to create the patch and masters. Ten minutes into it processing it gave me an error code 0A0017E6. Has anyone else run into this?
I figured this one out. As it says in the description, the Lootable Statics mod must be in the 0A position. Every time I tried to run the patcher YUP would always automatically take that slot. I just disabled YUP from Vortex and then ran the patcher so that way Lootable Statics would be placed in the 0A position and then just re-enable YUP after the patch is made. When all is done correctly, this mod works just as advertised. A must have mod in my opinion.
I really like how easy this is to use and set up, the step by step guide was very helpful!
If I could make one small change it would be to the stumps, they're so common in DC that the stump loot becomes crazy, especially at higher levels and *especially* with perks like scrounger. Maybe the stumps could have a smaller loot table?
For example I've maybe gotten 10 scrap metal in total from car loot in DC, but hundreds of ammo loot from stumps- its starting to feel like ammo grows on trees(lol haha I'm dying)
Also the thin, smaller stumps I feel are less worthy of containing loot- just my two cents
Hey, Sorry about the Bug Post, I just wanst sure, so i knwo the problem now, but the thign is thr eason it happened i guess is that i tried to run this with TTW whic means that it has another .esm that is locked in the spot you require me to put the script in, would ther be a chance for you to make an edited version that works with TTW?
I'm not using TTW myself at the moment as I'm trying to successfully put together a vanilla+++ (highly modded, whilst keeping true to what New Vegas is) modpack for my partner to play. TTW is just a compatibility nightmare. You need to design your whole mod inclusion ethos around it, as it actually even edits the base game esms (notably Gun Runners' Arsenal), making the DLCs incompatible with mods that were based on those DLCs. So, yes, just a compatibility minefield.
I'm going to put together a TTW pack later on for them, but I'll be focusing around FO3 for that as just a better way to play FO3 than FO3 itself (which is the case, these days, TTW definitely supercedes FO3). But I digress muchly.
I didn't intentionally make this incompatible with TTW, I just... kind of forgot how TTW works. It's been a while. I forgot that it loads a bunch of extra masters because of course it does, otherwise I would've provided a TTW version of the script already.
Here's the important part that's relevant to you: This won't be a problem for me to do, just tell me what position you want it to go in and I'll do that. Like, 0B, 0C, 0D, or what have you. Since I don't use TTW, I don't automatically have that info. So, yes, I'll definitely do this but I need to know where you have a slot free.
My guess is that your MO2 instance is specifically named a TTW instance, rather than FNV. An FNV instance lets you move the TTW plugin files around and move plugins up in them.
What you can do is edit the xEdit script to adapt to a different index number. Replace FileByIndex(11) on line 66 with the equivalent priority (mine was 80) and each formID header from 75 to 131 with a new one (mine went from 0A to 50). I've generated a patch perfectly upon doing so.
An equivalent for the forced TTW positions would be 17 and 11 for each step. Once generated, the ESM doesn't have to stay there, it just has to go back for updating the patch file.
EDIT: Matter of fact, here you go. https://pslk.net/5gubo9p4
Thank you for doing this:3 I have some bad news though, I tried running the Script, It ran for almost an hour and then gave me this: [59:24] Exception in unit UserScript line 24: Load order FileID [11] can not be mapped to file FileID for file "Lootable Statics Patch.esp" [59:24] Error during Applying script "Lootable Statics - TTW": Load order FileID [11] can not be mapped to file FileID for file "Lootable Statics Patch.esp"
Question: To help automate the process, would it be possible to change the script to automatically add all plugins in a load order as masters to the new plugin, then clean the masters at the end?
Second question: If for whatever reason that cannot be scripted in xEdit, would your script as its currently written behave just fine if I manually added all plugins in my loadorder to the patch plugin and simple cleaned masters afterward?I have explained in my later response about this, but the answer to this question appears to be yes in my testing.
EDIT: Also noticing that the way its currently written takes the first records in order and doesn't pull forward any other mod changes, and erroneous worldspace records that lack any changes to items within them.It seems I was wrong about erroneous worldspace records, I only had a single ITM in the file post-generation, I misread the filter results when manually checking and I apologize. I'm glad I checked as I don't think the description makes note of this. I'm also not sure it can be resolved automatically (maybe running a second xEdit script to check such things? I dunno). While requiring a manual pass at the end, results look great. :)
It does add the masters as far as I've seen, that's in the script. I'm not sure what you mean otherwise?
And in regards to changes mods make to world records? I think the best option there is just to have xEdit make a merged patch or do a manual pass, that's what I do. I'm not really sure how I could manually check for what every single mod does to change a world record without making the script monumentally slow. Right now, the script only compiles in records that actually have containers in them. If another mod includes that worldspace record but doesn't have a container, I'm not sure how I could check for that without making things terribly slow. That does play on my mind as the script is already slow enough.
Basically, I was aware of this but because of understanding how these things worked, I imaigned that people would be creating merged patches anyway. Whenever one adds a new plugin it's worth checking for compatibility errors/conflicts. I actually have a plugin myself that's just world area records that overrides any plugins that add items to those areas without changing that world record.
What I could see if I could do is write another script to automate that particular process for those who want it. Basically, just to create a patch containing all non-vanilla (non-ITM) world records that could sit at the bottom of a load order. I'm not quite sure how I would do that, yet, but I tend to figure things out.
Edit: I'm sorry if this comes across as a bit surly. I do make an effort to be friendly as I don't want to be the mod author who's being a jerk when people are just trying to help. It's just been a stressful morning as I'm dealing with immigration stuff. I do want to try to figure this out, though. Do you think a script that compiles world record edits into its own patch would help? I could toss it in with a few other scripts I've made that might help people.
I appreciate your response, I didn't perceive it as surly but I appreciate you being concerned for that on the off-chance. I am in fact going to strikethrough and edit my original post after this with some corrections, as I answered my own question on one part and was incorrect on another.
"It does add the masters as far as I've seen, that's in the script. I'm not sure what you mean otherwise?" As it currently stands, it adds the masters one at a time, which pauses the script waiting for the user to click yes or no on the prompt. I did test the script by generating my own empty plugin with every single other plugin as a master in my load order, and it did work just fine. So my suggestion was to have it automatically add every other plugin as a master *first* before it starts parsing statics to convert to containers, and then clean masters at the end. It saved me a fair bit of time to have it be entirely hands-off on the second go around.
"What I could see if I could do is write another script to automate that particular process for those who want it. Basically, just to create a patch containing all non-vanilla (non-ITM) world records that could sit at the bottom of a load order. I'm not quite sure how I would do that, yet, but I tend to figure things out." This is what I was thinking/hoping could be done, but I freely admit that I am NOT intimately familiar with xEdit's scripting language and limitations. It would be a solid timesaver for big load orders (my patch has 38 masters for example) and would definitely help with Root 'n Loot compatibility, as currently the generated patch steps over some other statics that Root 'n Loot already converts to containers, which breaks Fortune Finder fixes built into Root 'n Loot as well.Seems this part was also wrong far as I can tell. You may not get identical loot but the Fortune Finder leveled lists are included, I apologize again.
Alternatively, a Root 'n Loot patch/version for the plugin could be done I suppose, but then it would have to be sorted down into ESP space, which as its currently written would be harder to do what with the hard formIDs and FileByIndex call.
Oh, uh, this does everything Root 'n Loot FNV does! Or do you mean the TTW version?
I'll get to the rest a bit later, I'm just a bit fried right now as I spent a little while on scripting projects, including landing sounds for power armour. I feel accomplished, but wasted! Fun, though.
"Oh, uh, this does everything Root 'n Loot FNV does! Or do you mean the TTW version?"
You are right, I apologize. I failed to notice that the CapsChangeFortuneFinder leveled list was included in identical containers. Still, the rest should be applicable and up for consideration. :)
I'll try and get to that! Just got a few plates spinning with ongoing projects (including the ongoing immigration nightmare). I will try and get to that soon, though.
If I recall Famine's code, it kind of goes for the nuclear option. Basically, when you enter a cell (interior or exterior), it builds an array of all the containers there. Then it just goes through them, dinks with the condition of items within, and removes some of the loot based on a per centage. This works on all containers except respawning or scripted ones. I remember this from when I was nosing through the code, because Famine is a bit arcane in how it works and I wanted to understand it better.
Right now, the containers in this mod don't respawn. I will be adding an option for that shortly, but as of now they don't. What this means is that Famine's code that builds an array of containers whil just gather up all of the ones I've added too. In other words, Famine should work with this seamlessly because I didn't set the containers to respawn.
TL;DR: Famine should be able to work its magic with all of the containers in this mod, you needn't worry.
I did the thing. It's been rough getting back on the saddle, I've been out of the modding game for a bit and I'm a little more exhausted these days so things slip by me.
Did you use a cloaking script for your mod? I was huge fan of the original dynamic things in Skryim and eventually figured out the nature the script that was a cloaking script. I have been researching something similar for FO4 but haven't made much progress. TY.
Skyrim and FO4 operate on a completely different scripting system than New Vegas. It's... kind of confusing, I know. it gets weirder because as I recall you can even compile/decompile scripts outside of GECK, and the scripts exist as files outside of esps (plugin files)??? It's called Papyrus, I think. But yes, totally different. Skyrim got a huge update to its script engine. I would absolutely adore to get something like that for New Vegas, or something like Morrowind's MWSE-Lua, but that's unlikely to happen.
Your thinking seems right for how Papyrus works, though. You can do all sorts of arcane chicanery with Papyrus that you couldn't do with GECKscript. Which I'm calling that. I mean, did it have a name before Papyrus? I don't know. I'm just going from vague memories, here.
Anyway, my script does nothing nearly as fancy as how Papyrus works. It's basically just a very elaborate and specific find and replace. It goes through all the records of a user's esm and esp files and replaces all of the base objects within the references as is necessary. This is achieved through a Pascal script, run via xEdit as xEdit has support for Pascal scripting.
I'm sorry I couldn't be more useful than that, but I wish you well in your endeavours!
So much more loot! It works well with Famine aswell if you want more places to find loot, but less loot in the containers. I'm a loot hoarder myself, so I'm not one to run Famine, but I've had a look at it and the two play together well. But yes, more loot! And you're welcome!
31 comments
If I could make one small change it would be to the stumps, they're so common in DC that the stump loot becomes crazy, especially at higher levels and *especially* with perks like scrounger. Maybe the stumps could have a smaller loot table?
For example I've maybe gotten 10 scrap metal in total from car loot in DC, but hundreds of ammo loot from stumps- its starting to feel like ammo grows on trees(lol haha I'm dying)
Also the thin, smaller stumps I feel are less worthy of containing loot- just my two cents
I'm not using TTW myself at the moment as I'm trying to successfully put together a vanilla+++ (highly modded, whilst keeping true to what New Vegas is) modpack for my partner to play. TTW is just a compatibility nightmare. You need to design your whole mod inclusion ethos around it, as it actually even edits the base game esms (notably Gun Runners' Arsenal), making the DLCs incompatible with mods that were based on those DLCs. So, yes, just a compatibility minefield.
I'm going to put together a TTW pack later on for them, but I'll be focusing around FO3 for that as just a better way to play FO3 than FO3 itself (which is the case, these days, TTW definitely supercedes FO3). But I digress muchly.
I didn't intentionally make this incompatible with TTW, I just... kind of forgot how TTW works. It's been a while. I forgot that it loads a bunch of extra masters because of course it does, otherwise I would've provided a TTW version of the script already.
Here's the important part that's relevant to you: This won't be a problem for me to do, just tell me what position you want it to go in and I'll do that. Like, 0B, 0C, 0D, or what have you. Since I don't use TTW, I don't automatically have that info. So, yes, I'll definitely do this but I need to know where you have a slot free.
Thank you for responding and for the help:3
EDIT: Here is what the Base game and DLC .esm's look like with TTW
What you can do is edit the xEdit script to adapt to a different index number. Replace FileByIndex(11) on line 66 with the equivalent priority (mine was 80) and each formID header from 75 to 131 with a new one (mine went from 0A to 50). I've generated a patch perfectly upon doing so.
An equivalent for the forced TTW positions would be 17 and 11 for each step. Once generated, the ESM doesn't have to stay there, it just has to go back for updating the patch file.
EDIT: Matter of fact, here you go. https://pslk.net/5gubo9p4
[59:24] Exception in unit UserScript line 24: Load order FileID [11] can not be mapped to file FileID for file "Lootable Statics Patch.esp"
[59:24] Error during Applying script "Lootable Statics - TTW": Load order FileID [11] can not be mapped to file FileID for file "Lootable Statics Patch.esp"
And im not good at figurign out what went wrong
I'm sorry if I'm a bit slow to. Just a lot of plates spinning right now.
Edit: Oh duh. I'm dumb. I see what I did. Uploading a new version now.
Edit II: New version up! There you go. Should work perfectly now.
Second question: If for whatever reason that cannot be scripted in xEdit, would your script as its currently written behave just fine if I manually added all plugins in my loadorder to the patch plugin and simple cleaned masters afterward?I have explained in my later response about this, but the answer to this question appears to be yes in my testing.EDIT: Also noticing that the way its currently written takes the first records in order and doesn't pull forward any other mod changes,
and erroneous worldspace records that lack any changes to items within them.It seems I was wrong about erroneous worldspace records, I only had a single ITM in the file post-generation, I misread the filter results when manually checking and I apologize. I'm glad I checked as I don't think the description makes note of this. I'm also not sure it can be resolved automatically (maybe running a second xEdit script to check such things? I dunno). While requiring a manual pass at the end, results look great. :)And in regards to changes mods make to world records? I think the best option there is just to have xEdit make a merged patch or do a manual pass, that's what I do. I'm not really sure how I could manually check for what every single mod does to change a world record without making the script monumentally slow. Right now, the script only compiles in records that actually have containers in them. If another mod includes that worldspace record but doesn't have a container, I'm not sure how I could check for that without making things terribly slow. That does play on my mind as the script is already slow enough.
Basically, I was aware of this but because of understanding how these things worked, I imaigned that people would be creating merged patches anyway. Whenever one adds a new plugin it's worth checking for compatibility errors/conflicts. I actually have a plugin myself that's just world area records that overrides any plugins that add items to those areas without changing that world record.
What I could see if I could do is write another script to automate that particular process for those who want it. Basically, just to create a patch containing all non-vanilla (non-ITM) world records that could sit at the bottom of a load order. I'm not quite sure how I would do that, yet, but I tend to figure things out.
Edit: I'm sorry if this comes across as a bit surly. I do make an effort to be friendly as I don't want to be the mod author who's being a jerk when people are just trying to help. It's just been a stressful morning as I'm dealing with immigration stuff. I do want to try to figure this out, though. Do you think a script that compiles world record edits into its own patch would help? I could toss it in with a few other scripts I've made that might help people.
"It does add the masters as far as I've seen, that's in the script. I'm not sure what you mean otherwise?"
As it currently stands, it adds the masters one at a time, which pauses the script waiting for the user to click yes or no on the prompt. I did test the script by generating my own empty plugin with every single other plugin as a master in my load order, and it did work just fine. So my suggestion was to have it automatically add every other plugin as a master *first* before it starts parsing statics to convert to containers, and then clean masters at the end. It saved me a fair bit of time to have it be entirely hands-off on the second go around.
"What I could see if I could do is write another script to automate that particular process for those who want it. Basically, just to create a patch containing all non-vanilla (non-ITM) world records that could sit at the bottom of a load order. I'm not quite sure how I would do that, yet, but I tend to figure things out."
This is what I was thinking/hoping could be done, but I freely admit that I am NOT intimately familiar with xEdit's scripting language and limitations. It would be a solid timesaver for big load orders (my patch has 38 masters for example) and would definitely help with Root 'n Loot compatibility, as currently the generated patch steps over some other statics that Root 'n Loot already converts to containers,
which breaks Fortune Finder fixes built into Root 'n Loot as well.Seems this part was also wrong far as I can tell. You may not get identical loot but the Fortune Finder leveled lists are included, I apologize again.Alternatively, a Root 'n Loot patch/version for the plugin could be done I suppose, but then it would have to be sorted down into ESP space, which as its currently written would be harder to do what with the hard formIDs and FileByIndex call.I'll get to the rest a bit later, I'm just a bit fried right now as I spent a little while on scripting projects, including landing sounds for power armour. I feel accomplished, but wasted! Fun, though.
You are right, I apologize. I failed to notice that the CapsChangeFortuneFinder leveled list was included in identical containers. Still, the rest should be applicable and up for consideration. :)
https://www.nexusmods.com/newvegas/mods/74985
Right now, the containers in this mod don't respawn. I will be adding an option for that shortly, but as of now they don't. What this means is that Famine's code that builds an array of containers whil just gather up all of the ones I've added too. In other words, Famine should work with this seamlessly because I didn't set the containers to respawn.
TL;DR: Famine should be able to work its magic with all of the containers in this mod, you needn't worry.
Your thinking seems right for how Papyrus works, though. You can do all sorts of arcane chicanery with Papyrus that you couldn't do with GECKscript. Which I'm calling that. I mean, did it have a name before Papyrus? I don't know. I'm just going from vague memories, here.
Anyway, my script does nothing nearly as fancy as how Papyrus works. It's basically just a very elaborate and specific find and replace. It goes through all the records of a user's esm and esp files and replaces all of the base objects within the references as is necessary. This is achieved through a Pascal script, run via xEdit as xEdit has support for Pascal scripting.
I'm sorry I couldn't be more useful than that, but I wish you well in your endeavours!