Hi thank you for the mod! Just wanted to report that /scripts/masterambushscript.pex seems to conflict with Vanilla Script (micro)Optimizations. Might be worth including the optimizations from that mod in your script if possible?
It doesn't "conflict", one has to choose. I've often expressed my opinion about the pseudo(micro)optimizations. The next one referring to them on my pages shall be insulted, abused, and even called names.
I just noticed your update, where you've removed the esp (thanks!). I always wondered whether the esp for script mods is redundant. After all, they aren't needed to meshes, textures, audio and animation files, so the idea they are needed for scripts (which i've heard elsewhere, and have a few mods which include a dummy esp), seemed strange. I assume scripts would work in the same way as other file types, such that loose files would have priority over those same-named files in BSA files, and so would safely be loaded without an esp.
The esp was all about two modified AI packages, not about the scripts. I always had the feeling that those edited (sit linked reference) packages did the same as the vanilla ones (sleep linked reference.) Now I played a few months without them and still don't see the issue, so I'm under the impression that they're not needed.
Unfortunately, this is not a science-based mod, because the real cause of the issue escapes me. It's what's left of tens of failed blind shots, and also based on the extremely wrong assumption that if something doesn't happen for long enough, then it might never happen again :D
The dummy ESPs are used just to load BSAs (and possibly custom INI files) and place the BSAs in the desired position in the load order. If for some reason you wish to archive your edited vanilla scripts instead of having them as loose files, you need the empty ESP. On the other hand, you need "not-dummy" ESPs for edited vanilla scripts if you also need to modify the forms they're attached to (like filling new properties, for example.)
Sure, but removing a plugin with only two edited vanilla AI packages (no quests, no scripts) is totally safe anytime. I think that it would be better removed.
To be even more exact, you might want to replace the generic "records" with "new formIDs" -- there's no limit for records that are overrides of existing ones.
In my experience anything above 1,200 ESLs begins to cause small problems in the game. Merging them down to 1,100 ESLs got rid of the seemingly random glitches I was experiencing. I'm using the same mods; I just merged them down to below 1,200 ESLs.
As I understand it 4096 or 2048 is just a hard limit. It's possible, but the engine won't be happy about it. Maybe I'm wrong, but that many ESLs seems like a happy myth, simply too good to be true.
@Peter254 There's also this little issue, I guess. Not in your case if merging fixed your problems but, even if the plugins are small, when there are so many of them the reference count might go up quickly.
It's possible any problems thought to be from too many esl's, is actually coming from the number of "file handles". Once that limit is reached, then the game has problems loading additional files. The limit can be increased in enginefixes.toml file. I've seen players with load orders containing over 3000 esl's, which work fine once the number of file handles is increased.
Hello! Thanks for the mod! You really are an OG in the Skyrim modding community, so thank you for all your mods and everything. It really is appreciated. So I was curious, is there a way for you to make this an esl? I notice in my plugins it states .esl but it doesnt actually count as an esl plugin. Thanks again!
It is an esl -- a light master to be precise. Where do you get that it doesn't actually count as an esl plugin from? If you don't want it to be a master, please read the answer to the post below this.
Hmm, thats my fault. There wasn't a flag (yellow circle) for the plugin as an esp marked as esl (which seems to be the usual case for my other esl plugins), which led me to believe it was an esp. Sorry.
If Tarlazo would stop creating mods, Skyrim would remain more buggy that it should. And no more funny clips from youtube either.
EDIT: one thing though, a request for espfe version. Esl loads first and this makes me worried about renumbered FormIDs on all later loading mods on existing load order. And when FormIDs changes, all scripts attached to those later mods may misfire as I read.
Rename the file extension from .esl to .esp -- the plugin is already ESL-flagged. But this just edits two vanilla AI packages which no one would ever consider renumbering (well, no one in his right mind.)
And I'll stop publishing mods, not creating them -- this is my swan song :)
I've installed a mod that doubles all critters ("Increased Enemy Spawns" - Great mod, by the way). A glitch of that doubling is that one draugr is still inside the sarcophagus but the other, duplicate one is standing in front of it , and doing nothing.
If someone knows: Does "Standing Ambusher Fix" fix these duplicates and let them attack?
No, because the duplicates have the ambush script attached like the originals but don't have an "activate parent" which triggers them -- so they just stand there, sheep-like, with aggression 0. Looks like the author of the great mod hasn't a clue about how these things work :)
@superhpio I see it uses a lot of NPCs with "ambush" in the editorID, but they have neither an ambush script nor an activate parent. I don't understand how they "ambush" -- looks to me that they just behave like any non-ambush one and of course attack the enemies. But the fact that I don't understand means nothing -- I might just be too dumb to get it.
Oh, I see now. They're not "ambushers" in the traditional Skyrim way -- they start disabled, suddenly pop out of nowhere, and attack. So, yes, I think all is fine if you can accept something so weird.
46 comments
Comments locked
The author has locked this comment topic for the time beingI've often expressed my opinion about the pseudo(micro)optimizations.
The next one referring to them on my pages shall be insulted, abused, and even called names.
Please congratulate me.
I felt so sure, and after one week they start popping up like jack-in-the-boxes.
I always had the feeling that those edited (sit linked reference) packages did the same as the vanilla ones (sleep linked reference.)
Now I played a few months without them and still don't see the issue, so I'm under the impression that they're not needed.
Unfortunately, this is not a science-based mod, because the real cause of the issue escapes me.
It's what's left of tens of failed blind shots, and also based on the extremely wrong assumption that if something doesn't happen for long enough, then it might never happen again :D
The dummy ESPs are used just to load BSAs (and possibly custom INI files) and place the BSAs in the desired position in the load order. If for some reason you wish to archive your edited vanilla scripts instead of having them as loose files, you need the empty ESP.
On the other hand, you need "not-dummy" ESPs for edited vanilla scripts if you also need to modify the forms they're attached to (like filling new properties, for example.)
I think that it would be better removed.
Does the description mention requirements?
- ESL: limit is around 4096 (a plugin that contain less than 2048 records)
- ESP-FE: share the limit with ESL (plug ins that are loaded with ESPs, but can only contain less than 2048 records)
if i said any thing wrong correct me.As I understand it 4096 or 2048 is just a hard limit. It's possible, but the engine won't be happy about it. Maybe I'm wrong, but that many ESLs seems like a happy myth, simply too good to be true.
There's also this little issue, I guess.
Not in your case if merging fixed your problems but, even if the plugins are small, when there are so many of them the reference count might go up quickly.
But seriously, yes, it's safe.
Where do you get that it doesn't actually count as an esl plugin from?
If you don't want it to be a master, please read the answer to the post below this.
EDIT: one thing though, a request for espfe version. Esl loads first and this makes me worried about renumbered FormIDs on all later loading mods on existing load order. And when FormIDs changes, all scripts attached to those later mods may misfire as I read.
But this just edits two vanilla AI packages which no one would ever consider renumbering (well, no one in his right mind.)
And I'll stop publishing mods, not creating them -- this is my swan song :)
If someone knows: Does "Standing Ambusher Fix" fix these duplicates and let them attack?
Looks like the author of the great mod hasn't a clue about how these things work :)
Big fan, the eternal running gag of you quitting made my day once more.
About this issue with mods spawning enemies do you think this mod author has got it covered?
Hand Placed Enemies - More populated spawns dungeons and POIs
I see it uses a lot of NPCs with "ambush" in the editorID, but they have neither an ambush script nor an activate parent.
I don't understand how they "ambush" -- looks to me that they just behave like any non-ambush one and of course attack the enemies.
But the fact that I don't understand means nothing -- I might just be too dumb to get it.
They're not "ambushers" in the traditional Skyrim way -- they start disabled, suddenly pop out of nowhere, and attack.
So, yes, I think all is fine if you can accept something so weird.