Jump to content

A Real Explorer's Guide to Skyrim


Recommended Posts

We looked at LAL in the beginning of the pack development and it only had an inconsequential conflict with ETaC (Dawnstar) as far as I remember. Since we cut out all the non-vanilla- matching stuff from ETaC (in morthal, dawnstar and falkreath) there shouldn't be any issue running LAL at all. Pretty sure we can add LAL to the list of confirmed compatible mods. I know 100% sure that the Unbound quest works, as it is essentially the same in all starts. SRLE (which includes LAL) so far works flawless with REGS in all my testing. Each time I started a new char with LAL (like 2x a day last month) to test out some stuff (not a fan of coc anymore) I tried to chose a different start and haven't had an issue with it yet. But CJ can give a definite answer as he (probably) knows how LAL looks in the CK :P

Okay, that's good to know. I had also been using the coc console command to jump into a "new" game for testing purposes, but then in the last two weeks I read that there are some mods which don't work properly if you start a game with coc. So I'd like to start using LAL from now on. I'm curious, Nearox - where do you have LAL in your load order as compared to the REGS plugins - before or after? I ask because of those NavMesh records that I see LAL overriding when I check in TES5Edit. Should I change the order so that the REGS - Cities.esp and REG Patch - Cities.esp load after LAL's plugin?

Edited by keithinhanoi
Link to comment

I have everytging sorted exactly as srle and regs instructions. LAL has no special override and is henceforth sorted after after the regs patches.

Great. I am thinking of actually using one of LAL's alternate starts once I'm ready for the "real" play through, so I'm going to do some testing with them.

 

If I find any issues, I'll report back here, though I'm still curious what CJ2311 thinks about the NAVM records in LAL that "override" some of the ones in your REGS plugins.

Link to comment

I guess that's the problem with me using BOSS3/Loot instead of BOSS 2.

Now that the BOSS team has released Boss 2.2 I'll be using that instead of Loot and will add a bunch more compatibility patches for navmeshes. You see, BOSS 3 was loading 3DNPC and AS:LAL quite early in my load order.

Guess I got my program for the day then, after I finish fixing the rest of the minor SFO compatibilities with ETaC...

 

As for your questions: the game will always use the last VMAD entry in any record, even if that entry is empty (already tested that), same goes for NAVM. If more than 1 script are attached to the same object/npc, you will have to forward both in a patch.

Link to comment

Errr, well AFAIK Enboost actually makes the game use less RAM but requires even more VRAM, no?

At least that's what I thought it did, which is why I stopped using it so that my GPU would make less noise...

Ahh really?? Crap lol! Maybe I won't use it then... I might have to start optimising textures...I avoided it as it looks tedious

Link to comment

ENBoost's primary function is to get rid of the 3.1GB RAM cap of Skyrim. Directx9 mirrors VRAM to RAM so it is easy even for users with 2GB GPUs to reach the 3.1GB cap (as RAM is also used for other functions within Skyrim). It shouldn't increase VRAM at all.

 

If you use the memory patch by Sheson/SKSE 1.7/SSME, then your RAM use will be increased by the extra amount you set in the values for the blocks. If you would increase the 1st block by 256MB over the default of Skyrim, then you can immediately see in SPM/VMMAP that the RAM usage of the Skyrim.exe process has gone up by an identical amount because this is now 'reserved'.

 

Therefore if you use the memory patch, you will generally speaking hit that 3.1GB RAM cap earlier. At 3.1GB RAM you will almost always CTD. ENBoost simly offloads some of the RAM (the part that is mirrored of the VRAM) to the enbhost.exe process, thereby preventing this CTD.

 

This is my understanding at least. I'm sure keitinhanoi could go into a lot more detail if you were to ask him :)

Link to comment

ENBoost's primary function is to get rid of the 3.1GB RAM cap of Skyrim. Directx9 mirrors VRAM to RAM so it is easy even for users with 2GB GPUs to reach the 3.1GB cap (as RAM is also used for other functions within Skyrim). It shouldn't increase VRAM at all.

 

If you use the memory patch by Sheson/SKSE 1.7/SSME, then your RAM use will be increased by the extra amount you set in the values for the blocks. If you would increase the 1st block by 256MB over the default of Skyrim, then you can immediately see in SPM/VMMAP that the RAM usage of the Skyrim.exe process has gone up by an identical amount because this is now 'reserved'.

 

Therefore if you use the memory patch, you will generally speaking hit that 3.1GB RAM cap earlier. At 3.1GB RAM you will almost always CTD. ENBoost simly offloads some of the RAM (the part that is mirrored of the VRAM) to the enbhost.exe process, thereby preventing this CTD.

 

This is my understanding at least. I'm sure keitinhanoi could go into a lot more detail if you were to ask him :)

Yup, Nearox, that about sums it up, though in practice, not 100% of VRAM is mirrored with system RAM - but the important things to remember is that generally, the more VRAM you have, the higher Skyrim's memory usage will go, and the more useful ENBoost becomes, since it offloads cached object geometry and texture data out of TESV.exe (Skyrim) and into the enbhost.exe that comes with ENB.

 

I guess that's the problem with me using BOSS3/Loot instead of BOSS 2.

Now that the BOSS team has released Boss 2.2 I'll be using that instead of Loot and will add a bunch more compatibility patches for navmeshes. You see, BOSS 3 was loading 3DNPC and AS:LAL quite early in my load order.

Guess I got my program for the day then, after I finish fixing the rest of the minor SFO compatibilities with ETaC...

As for your questions: the game will always use the last VMAD entry in any record, even if that entry is empty (already tested that), same goes for NAVM. If more than 1 script are attached to the same object/npc, you will have to forward both in a patch.

Well, I can pretty easily set REGS - Cities.esp and REG Patch - Cities.esp to load after LAL for now, since it seems you made the NavMesh edits with that load order in mind.

 

So, with VMAD entries - from what you're saying, if there are three mods making changes to a record, and the earliest loaded one (on the left side when viewed in TES5Edit,) has a VMAD entry to attach a script, that will get carried into the game as long as the other two mods don't have any VMAD entries?

 

Then, as another example, again with three mods making changes to a particular record, if the first-loaded mod has a VMAD entry for one script, and the second-loaded mod has a different VMAD entry, but the third mod has no VMAD entries, will the other two VMAD scripts get pulled forward into the game to attach to that object / NPC?  

 

That second example is important because I've seen a number of mods adding VMAD entries to the generic "Prisoner" NPC, which is your player character, right?

 

Back to REGS, though, I am now going through towns / cities to check for any floating objects added by some of my non-STEP mods. One in particular I use that has these is Immersive Content - Extinguished Daytime Fires and Lights, which I chose as an alternative to Lanterns of Skyrim. It's similar to LoS in that it adds lights to some roads and bridges and puts them and some existing vanilla lights on an on at night / off in the day schedule - but with the main difference being not all added lights are laterns (eg., adding open fire braziers on bridges, which look much nicer, IMO.)

 

Anyhow, I'm wonder what method you've used to get rid of extra floating objects - the easiest way I can see is to set the Record Flag of Initially Disabled and the Z Position to -30000. Does that sound like a good plan if I'm trying to avoid opening up everything in CK?

Link to comment

So, with VMAD entries - from what you're saying, if there are three mods making changes to a record, and the earliest loaded one (on the left side when viewed in TES5Edit,) has a VMAD entry to attach a script, that will get carried into the game as long as the other two mods don't have any VMAD entries? Then, as another example, again with three mods making changes to a particular record, if the first-loaded mod has a VMAD entry for one script, and the second-loaded mod has a different VMAD entry, but the third mod has no VMAD entries, will the other two VMAD scripts get pulled forward into the game to attach to that object / NPC?

Nope, I said even if the VMAD entry is empty, it'll still get forwarded, and nothing else.So if mod A has a cleanup script, mod B has a quest script, and mod C has nothing, the game will load nothing and will ignore both scripts. I tested that with activators, but there's no reason why it wouldn't apply to NPCs

Anyhow, I'm wonder what method you've used to get rid of extra floating objects - the easiest way I can see is to set the Record Flag of Initially Disabled and the Z Position to -30000. Does that sound like a good plan if I'm trying to avoid opening up everything in CK?

Yes, that's enough to get rid of the object. Or you can set its flag to deleted, then run the remove UDR function to make sure it really gets disabled.EDIT: I have to say, that braziers mod looks great, are there really compatibility issues with it though? I can't really tell where there'd be floating lights since most mods in REGS don't even touch them afaik. Edited by CJ2311
Link to comment

Nope, I said even if the VMAD entry is empty, it'll still get forwarded, and nothing else.So if mod A has a cleanup script, mod B has a quest script, and mod C has nothing, the game will load nothing and will ignore both scripts. I tested that with activators, but there's no reason why it wouldn't apply to NPCs.

Good thing I asked. So that means VMAD entries should follow the normal process in TES5Edit for conflict management. Thanks a bunch for clarifying this. I'm going to remove it from my list of records / sub-records that don't need to be carried forward, and suppose I'll need to take another look through at VMAD entries I need to bring into my global conflict patch. 

Yes, that's enough to get rid of the object. Or you can set its flag to deleted, then run the remove UDR function to make sure it really gets disabled.EDIT: I have to say, that braziers mod looks great, are there really compatibility issues with it though? I can't really tell where there'd be floating lights since most mods in REGS don't even touch them afaik.

As far as I can tell, all the remove UDR feature does is set the Initially Disabled flag and the Z position to -30000. Anyhow, doing that manually seems to be working just great.

 

With IC-EDFL, it goes further than Laterns of Skyrim in that the author changes a lot of the vanilla exterior / city light sources (torches, candles, lanterns, braziers) to his scripted ones with a daily on / off cycle.

 

So any mod that moves vanilla lights or the buildings / structures they are attached to will result in "floating" lights from IC-EDFL. So I'm just going through each town / city to find lights that need to be "removed" due to changes that ETaC makes.

 

I also happen to use a different chimney mod from the one in REGS, called Chimneys for Skyrim - but not the one listed here on STEP, but rather one that is no longer available on Nexus (skyrim mod #17919). That also leaves a few unattached chimney's after ETaC's repositioning of some vanilla houses, so I'm "removing" those as well.

 

I encourage you to check out IC-EDFL as an alternative to Lanterns of Skyrim, but note that in addition to the patching that is needed when used with ETaC, it also needs some fixes if you're using the full complement of ELFX's plugins (since it also moves / removes some vanilla exterior lights).

 

Oh, and as a side note - I noticed that ETaC uses rounded-shape lanterns, while both Lanterns of Skyrim and IC-EDFL use the box-shaped vanilla ones. Nothing earth-stopping, of course. :)

Link to comment

I also happen to use a different chimney mod from the one in REGS, called Chimneys for Skyrim - but not the one listed here on STEP, but rather one that is no longer available on Nexus (skyrim mod #17919). That also leaves a few unattached chimney's after ETaC's repositioning of some vanilla houses, so I'm "removing" those as well.

Are you sure that's not the same mod which got hosted on TESA? :)Note that there'll also be clipping chimneys in the places affected by ETaC, not just floating. Same goes for the smoke. 

I encourage you to check out IC-EDFL as an alternative to Lanterns of Skyrim, but note that in addition to the patching that is needed when used with ETaC, it also needs some fixes if you're using the full complement of ELFX's plugins (since it also moves / removes some vanilla exterior lights).

Will check it out then, I don't use any exterior lighting mods anyway, ENBs are enough for that :D 

Oh, and as a side note - I noticed that ETaC uses rounded-shape lanterns, while both Lanterns of Skyrim and IC-EDFL use the box-shaped vanilla ones. Nothing earth-stopping, of course. :)

Well, not everyone is going to use the same type of lanterns after all :PFun fact: the rounded lanterns in ETaC were made by MannyGT, who also created the Lanterns of Skyrim mod :)On a totally unrelated note, a major update is coming soon, just have to make a couple more patches that were lost thanks to a power outage.It'll have support for both the current and upcoming version of Interesting NPCs that'll come out this Monday, plus some quest mods, a different Sky Haven Temple mod, and a few bugfixes for ETaC/REGS.Oh and Skyrim Sewers has been merged in the main file with permission from viltuska, so you won't have to download that anymore. Edited by CJ2311
Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.