Devious Devices Framework Development/Beta

[GreatCroco]

9 hours ago, TrickyK said:

The preferred way to convert plugins is to open the LE plugin in the SE creation kit, and save it. This converts it to form 44. This usually is not even needed though, but if you do want to, here's a tutorial. I just do it because mod organizer throws a warning if you don't.

Both Arthmood and Mator, (for those who don't know: two of the most well known and respected mod authors for Skyrim) recommend to resave the plugin because the structure is different. They say it most likely won't make a difference in small saves, but the longer you play the more likely a total save corruption becomes.

 

5 hours ago, qawsedrftg765 said:

As a someone who has done a lot of dev work IRL (mostly for iOS and Android) I know the pain people like Kimy are in where you can look @ the user data and see that a small(er) percentage of people have not changed to the 'new thing' are simply happy with their windows XP/Vista machines (Seriously like 2% of users in 2023) But you want to do an update and you KNOW that those people can not have it no matter how much you would want to.

The usual approach from companies like Microsoft, Apple, Google, and whatnot is either:
* Drop the support entirely (Google)

* Offer the people a year long upgrade path (Apple)

* Switch to the new version, and only port back the most serious of problems, but don't retire anything either (Microsoft and Intel)

 

 

 

 

 

 

 

A few more anecdotes from my "porting DD SKSE to SE" adventure. Porting the plugin itself was easy. But when I tried porting some heavier Papyrus functions to C++ it got wonky. Since you can't call Papyrus from C++, porting needs to start at the very core lib and since Papyrus and C++ are so different in how they approach Skyrim, it means you can keep the API surface the same, but not the underlying implementation. That means, that if the computationally intensive parts are ported to native code, it automatically means you can't back or forward port bugfixes without rewriting them entirely. I tried starting the with furniture library, as this is the area, which the least amount of mods depend on, but that calls the core lib, so that's a dead end for now.

 

 

There's also another problem I ran into: DD makes heavy use of StorageUtil to store states. While this is SKSE based, I can't find the sources, so I can't use it in C++. Whether I can leverage the SKSE co-save is tbd. 

 

 

 

 

@Scrab How did you interface with SexLab? That would be my next problem in porting some of the code

 

 

[naaitsab]

1 hour ago, GreatCroco said:

Both Arthmood and Mator, (for those who don't know: two of the most well known and respected mod authors for Skyrim) recommend to resave the plugin because the structure is different. They say it most likely won't make a difference in small saves, but the longer you play the more likely a total save corruption becomes.

 

It's not that difficult to convert a "plain" mod from LE to SE. 

 

-If it has a BSA, unpack it first

-Open the ESP/ESM in the CK and just click save to upgrade it to the new form and possible change some other things under the hood. Using Tes5Edit alone is not recommended.

-Convert the meshes and texture using Cathedral or manually for small mods using DD tools on Photoshop or GIMP and Bodyslide. Or NifSkope if you know what you are doing.

-Optional: Repack the unpacked files into the SE BSA format.

-Optional: use Tes5edit to convert the newly saved ESP to a ESL.

 

If it has animations these need to be converted as well. I'm not sure there are any batch processing tools for this and will probably require a import in blender and export to the new format. But I'm not skilled in animating so don't know the details.

 

If it relies on dll's like SKSE addons you start to run into problems quite fast. Those mods are not for new player to try and convert. Unless you are skilled in C++ and know how SKSE works under the hood.

 

Also anything physics based also needs a manual conversion. For example the poisoner chains in DD are a "fine" example of something that causes issues. Which seem to be quite a challenge to fix.

Edited June 26, 2023 by naaitsab

[GreatCroco]

I want to add that BSA's must be converted, they will crash the game if they are in the old format. It's also recommended to not have loose files because you might run into hard to debug conflicts, although the latter is somewhat mitigated by ModOrganizer.

And while converting into an ESL sounds fine, you should know when to convert it. All records are moved into the FE id-space, you can only have at most 2048 records in the plugin and ESL are loaded before ESPs, but after ESMs.

[Scrab]

2 hours ago, GreatCroco said:

How did you interface with SexLab? That would be my next problem in porting some of the code

You can compare my work on the front end to default SL on my github:
 

https://github.com/Scrabx3/SexLab/tree/animation

 

When Im done with some certain block of code I usually push it over asap. While my indev has a lot more changes, the scripts which I will focus on in the following text are pretty much completed:

• sslThreadSlots.psc
• sslThreadLibrary.psc
• sslAnimationSlots.psc
• SexLabFramework.psc

When you go over these scripts the sslThreadLibrary one will likely look the most intriguing to you as almost everything in this script has been re implemented as a native function but consider scripts like sslAnimationSlots where little native declarations are found, or even sslThreadSlots which has no native functions at all despite being a core script in SLs implementation, arguably even the most important one as it is fetching new threads for scenes to play on.. yet there isnt a single native declaration on it, why?

Also consider SexLabFramework.psc underwent some big changes  with large chunks of its code no longer being part of the API but if you take a closer look, you will find that all of its functions are still there, just made redundant and potentially having its content delted. I.e. you can still call them, they just dont do anything. These particular fucntions are breaking backwards compatibility as they make logic unavailable that is required for previous versions

Another important detail is that sslAnimationSlots is entirely redundant, this is the old registry that other versions run on, the registry that mods like SLAL and SL itself load animations into and there too, theres actually not a whole not native code there. I made 3 native functions and p much called it there

 

However, If youre trying to do what I think you are trying to do, then I will tell you right now that you are going to run into more walls than you can count and majority of these walls you will build yourself because of premature optimizations on the code base where they arent needed and may even be contra productive, may complicate things or create issues that cant be fixed in a way that will allow LE to continue using it - and this will also mean that you are going to split the community and likely result in your attempt being a failure because I will be supporting a SE exclusive DD (under these conditions) as much as HexBolt will

In these kind of projects, C++ is NOT the front end. Its the back end, and as the back end is has no actual control over what is happening on the front end, i.e. what papyrus does and to that end, papyrus needs to retain full control over what is happening. This is why sslThreadSlots is all in papyrus. I would have no issue porting everything into C++. in fact It would be an easy task to just move everything into C++ but doing so would mean that C++ is in absolute control over the framework when in it actually should just be there to control the data, offer access to it, offer some misc utility and otherwise be stateless

 

In order for this to work, you need to first understand what the actual issue in DD is and how you can approach them in a way that is compatible and necessary. Dont just run in there with a sledgehammer and hope for the best doing so. Quality is a matter of perception, putting "native" after every function isnt quality, its just a bunch of native functions

This is why I keep tellin ppl to hold their breath when they wish to compliment me on SLp+, because this first phase of this project (SL+) is literally only there for me to understand what I should be doing, what I can do, and to that end: If you look at what I did in p+ you will notice that I didnt really do anything in the dll at all. Like sure theres this cute little integer that looks kinda fancy and a dozen native utility functions but fundamentally? Nothing in there is really impressive. In fact all of the things in that dll could easily be done in Papyrus as well and you wouldnt notice any major  difference in how SLp+ performs

 

Understanding what DD is missing is literally what Kimy has been doing all along. If you read my first post which got this whole discussion started; This one here (avoiding the embed)

You will notice that in this post, in these 3 major points I made, I didnt actually mention anything about "fixing DD" or "addressing its issues" or anything like that. I did mention it once as a side effect, but thats a side effect resulting from doing something else (in this case overhauling the device hider). Performance, speed is literally not the point of why you would want to do anything SE exclusive. Of course its nice to be faster, operating in real time is the holy grail for mods like this but if you just blindly move everything into C++ and call it "optimization" without actually knowing what is wrong in first place, what you should address then all you really do is making the live of DD authors harder who now have to add a another 100ms delay between device equipping because DD trips up twice as fast as before

 

I know this all sounds incredibly harsh and I hope that doesnt completely kill your vibe to do anything modding, but I really want to stress that C++ and SKSE plugins arent some kind of wonder drug that fixes all issues just by being there. Youre probably super excited because you got your C++ setup running and can compile things and that is super cool, its great that it motivates and that youre trying to actually get things going but remember:

All of these things that you have access to in SE are just tools and as with any tool, you not only need to learn how to use them, but you also need to learn when to use them. So, if you wanna help getting DD forward with your SE Toolkit then you first need to understand what you should be doing and the best way to do this is to not actually use your SE toolkit at all. Help Kimy improve the Papyrus code base without using your dll understand why it has issues, address these issues and if you ever run into some kind of wall that Kimy has to walk around because LE you can look at your Papyrus toolkit and maybe youll have something in there that will help you either smash that wall or just go over it and that is when LE and SE go different paths: LE will go around that wall, SE goes straight through it. The important thing is that once you go through this wall, and you get to a path that LE is also walking, you dont strive from that path just because you can. Walk with LE again, and walk with LE until another one of these walls pop up. Rinse and repeat until both of you have a path that works and is optimal

 

Edited June 26, 2023 by Scrab

[GreatCroco]

1 hour ago, Scrab said:

You can compare my work on the front end to default SL on my github:

That sadly doesn't help me one bit, as your code is entirely in Papyrus. That was not what I was looking for.

 

1 hour ago, Scrab said:

Youre probably super excited because you got your C++ setup running and can compile things and that is super cool, its great that it motivates and that youre trying to actually get things going but remember:

 

Naww... I'm programming stuff for more than two decades now. Finding out what the customer needs (not wants) is literally my daily job. So, getting any C++ stuff running is more chore than pleasure and often not more than just a few shell commands. Sure, if I could, I'd take SKSE and port it to some sensible language with proper package and version management (I did already integrate Rust with UE, so nothing totally out of the ordinaty). I'm just glad it's not PASCAL or COBOL I'm dealing with?.

The thing is: Most of what's currently written in Papyrus is totally fine. For example: The device hider logic is totally fine, sure "UpdateSlotmask" runs in O(n), but that won't change in native code, nor does it run that often. The problem with the device hider is the MCM, that could use a total overhaul. I didn't even look at most of the scripts, because they have no purpose being native. Why should I be concerned with the 65 LoC in zadx_RopeHarnessScript? That's totally irrelevant.

 

zadclibs and zadlibs are the interesting bits, where most of the stuff happens

  

1 hour ago, Scrab said:

address then all you really do is making the live of DD authors harder who now have to add a another 100ms delay between device equipping because DD trips up twice as fast as before

Most of the tripping that DD does, at least in my (anecdotal) testing, was due to Papyrus throwing a hissy fit because the VM was overloaded. This has gotten better in SE because of... well SE. In LE I could go and make myself a tea while I waited for a complete unequip with every slot covered to complete. In SE this takes just a few seconds.

In the best of cases, moving stuff from the VM to native should help.

 

 

 

1 hour ago, Scrab said:

I know this all sounds incredibly harsh and I hope that doesnt completely kill your vibe to do anything modding, [...] 

Also on a side note, I may argue that going hands on with the "SE exclusive port" before Kimy actually has given any statement to any of this is a little bit rushed

I had never any drive to start it up (again) in the first place. The whole thing was just me messing around at a free weekend to see how easy it could be to move the most computationally intensive functions off Papyrus and into native code. Just move the plugin into CommonLibSSE-NG, improve some stuff, drop it here and leave it at that.

 

Even if you did "kill the vibe", it's not like I have a full disk of other open source project lying around. Maybe I really should finish that Papyrus Compiler finally?

 

  

1 hour ago, Scrab said:

offer some misc utility and otherwise be stateless

I come from a functional programming background, Haskell was the first language I learned in university. Having everything stateless is nothing new, or even remotely challenging.

Edited June 26, 2023 by GreatCroco

[ponzipyramid]

6 minutes ago, GreatCroco said:

Getting any C++ stuff running is more chore than pleasure and more often than not just a few shell commands.

 

I'm not sure any sane person would consider setting up VS to be a pleasure.

[Scrab]

25 minutes ago, GreatCroco said:

That sadly doesn't help me one bit, as your code is entirely in Papyrus. That was not what I was looking for.

The source code for SL+s dll is closed as I cant trust a certain group of people to not plunder it for my own disadvantage

If you want to know how exactly a native function is defined in the Cpp side you can take a look here:

https://github.com/Scrabx3/Acheron-SKSE/blob/master/src/Papyrus/Functions.h

 

Also my apologies for underestimating you like that

 

[naaitsab]

50 minutes ago, Scrab said:

Also on a side note, I may argue that going hands on with the "SE exclusive port" before Kimy actually has given any statement to any of this is a little bit rushed

 

You dont even know if Kimy wants to give up on maintainin the SE thread or if they already have someone already in mind for it. It would be kind of unfortunate to invest all this work and get hopes up now just to be told off because Kimys plans dont align with yours

Well on the Fallout 4 version I kind of made a shadow version of DD. Unofficially it is abandoned for a few years now and in the thread quite a few optimisations where posted by different users but it was a pain in the ass to get them all combined for players. So I took it upon myself to migrate all these changes, make them compatible with each other and added a few extra's to it. And removed a dead framework that causes issues. Another user has now taken over the project to further optimize it and when they release the next build I want to propose that as the new version to upload. As now all new players are redirected to my last upload post in the thread.

 

I'm going to make an assumption that Kimy has not used SE very much if at all, but I can be completely wrong on this point of course. Whatever the case I would like to suggest we stick together to make a testcase "real" SE version to at least see what it can do if we get all the bells and whistles going. I can see that getting uploaded as a beta version and it could then come down to a system we currently have with DD that users submit code and it get's merged by the "Kimy-Git" and compiled into 1 upload. It's not like SE has a completely different code behind it. It's just that some things work a bit different if we convert to beter/newer frameworks like OAR over FNIS etc.  This would at least fix the current "patchfest" situation no matter the outcome of the current discussion. All SE players would benefit from that action alone.

 

It could be quite a challenge to get everything working but when the bulk is implemented in a team effort (and more so making use of existing knowledge) it's a matter of maintaining it and adding smaller new features/fixes. Which is a lot smaller to process. This might also make one of the proposed "dual-version" outcomes way less intensive to implement.

[GreatCroco]

39 minutes ago, Scrab said:

If you want to know how exactly a native function is defined in the Cpp side you can take a look here:

I know how to define a native Papyrus function, both with raw SKSE from back in the LE days when we didn't have nice tooling and with CommonLibSSE-NG, where it's really just "vm->RegisterFunction("FunctionName", "PapyrusScriptName", p_fn);" My question was how you'd interact with native SexLab code, as I had assumed you had some sort of native plugin for SLp+. Maybe should've worded that better, my bad.

 

I a perfect world DD would migrate to the "Fully Dynamic Game Engine" (dumb name as it's not an engine), which would allow stuff like dynamic config files (like JUtils just better), custom console commands, or the creation of Papyrus script objects in C++, and therefore stateful Papyrus->Native calls. But we don't live in a perfect world.

But before I would've made that suggestion I'd have implemented a test plugin first; or more realistically ported Jaxonz positioner, seeing as I use it more than once every game session and the Payurus code is painfully slow, even with PapyrusTweaks.

 

 

Edited June 26, 2023 by GreatCroco

[Scrab]

13 minutes ago, GreatCroco said:

My question was how you'd interact with native SexLab code, as I had assumed you had some sort of native plugin for SLp+.

Though the front end/papyrus

 

In cases where my dll would require something that SL offers on the papyrus side I simply reimplement it. Nothing in SLs dll is overly complicated, and Ashal offered me the source code for the creature stuff so It wasnt difficult too implement that either

Unless I still misunderstand, ayah

 

13 minutes ago, GreatCroco said:

or the creation of Papyrus script objects in C++

The last time someone tried to make Papyrus objects at runtime they ran into issues with memory, something about the objects not being saved correctly causing them to glitch out or just be deleted

Edited June 26, 2023 by Scrab

[GreatCroco]

1 hour ago, ponzipyramid said:

I'm not sure any sane person would consider setting up VS to be a pleasure.

Funnily enough. MSVC is pretty decent to set-up. It's when you leave the MS ecosystem and use gcc, CLion, CMake, etc. when it gets dumb.

 

1 hour ago, naaitsab said:

Whatever the case I would like to suggest we stick together to make a testcase "real" SE version to at least see what it can do if we get all the bells and whistles going.

That would also be my suggestion. Take the current SE version, update the SKSE plugin (done easily enough), replace DAR merge patches, etc. Then let that run as a beta for a while an see how it goes.

 

  

32 minutes ago, Scrab said:

In cases where my dll would require something that SL offers on the papyrus side I simply reimplement it. Nothing in SLs dll is overly complicated [...]

Yeah, I'd have guessed nothing is really that complicate. But if working in the industry has taught me one thing: If you don't have to reimplement stuff, don't do it. Or you'll work a whole year on a simple A* implementation because your client has so much red tape that you could wrap every house in Solitude twice.

  

32 minutes ago, Scrab said:

The last time someone tried to make Papyrus objects at runtime they ran into issues with memory, something about the objects not being saved correctly causing them to glitch out or just be deleted

Might be, VMs can be a bitch sometimes. That's why I said I would've tried it out first. No point in doing all the work and then seeing it all blow up.

Edited June 26, 2023 by GreatCroco

[natybs]

hi the box binders are turning all of my character invisible when i equip them. i am using the CBBE body. i built everything in body slide so no idea what to issue is.

[zarantha]

10 hours ago, natybs said:

hi the box binders are turning all of my character invisible when i equip them. i am using the CBBE body. i built everything in body slide so no idea what to issue is.

 

Then you need to check if your bodyslide settings are right. There's a section on the troubleshooting post for how to troubleshoot bodyslide to make sure it's going to the right place. Follow that.

 

Not sure why you're posting in here instead of staying in the SE thread and waiting for a response. You were in the right thread to start with.

[krzp]

Got an idea to share, after venturing thru the source code to find how the alternate animation application process goes.

There's a zadboundcombatscript's function EvaluateAA which picked the correct FNIS set,
 

Spoiler

If !HasCompatibleDevice(akActor)
        libs.log("EvaluateAA: Reverting to unbound AA")        
        ClearAA(akActor)
        ResetExternalAA(akActor)
        RemoveBCPerks(akActor)
    Else
        libs.log("EvaluateAA: Applying animSet = " + animSet + ", animState = " + animState)
        ClearAA(akActor)
        ApplyBCPerks(akActor)
        int animState = GetSecondaryAAState(akActor)
        int animSet = SelectAnimationSet(akActor)
if animState == 1
            FNIS_aa.SetAnimGroup(akActor, "_h2heqp", HBC_h2heqp, animSet, "DeviousDevices", Config.LogMessages)
            <...a million of those...>

 

it first calls for ClearAA to reset the FNIS animations to the standard set (which has a Debug.SendAnimationEvent(akTarget, "IdleForceDefaultState") but only for if akActor != libs.PlayerRef, i.e. not the player, if i understand how it works?),

Spoiler

Function ClearAA(actor akActor)
;This function forcibly reverts animations to the vanilla state
;On its own it is used in transitions between different animation sets
;In order to revert to animations from compatible AA mods, remember to use ResetExteralAA() afterwards
    
    FNIS_aa.SetAnimGroup(akActor, "_h2heqp", 0, 0, "DeviousDevices", Config.LogMessages)
<...>
    akActor.SetAnimationVariableInt("FNIS_abc_h2h_LocomotionPose", 0)
    if akActor != libs.PlayerRef && !akActor.isDead()
        akActor.EvaluatePackage()
        Debug.SendAnimationEvent(akActor, "IdleForceDefaultState")
    EndIf
EndFunction

 

and then EvaluateAA sets the abc_, hbc_ or pon_ prefix for movements.

 

Nowhere in evaluateAA is there a Debug.SendAnimationEvent(akTarget, "IdleForceDefaultState"), so the player's idle doesn't get updated here after equipping the device.

 

This function is being used by zadlibs.

Spoiler

Event StartBoundEffects(Actor akTarget)
<...>
    if akTarget != PlayerRef
        BoundCombat.EvaluateAA(akTarget)
        ;BoundCombat.Apply_NPC_ABC(akTarget)
        return
    EndIf
    Log("OnEffectStart(): Bound Effects")            
    PlayBoundIdle()
    RegisterForSingleUpdate(8.0)
    if aktarget == PlayerRef
        UpdateControls()
    Endif
EndEvent

 

EvaluateAA isn't being used for the player here, but for NPC's (akTarget != PlayerRef), the player character gets the PlayBoundIdle() instead

 

Spoiler

Function PlayBoundIdle()
    BoundCombat.EvaluateAA(PlayerRef)
    if !IsAnimating(PlayerRef) && !PlayerRef.IsInFaction(SexLabAnimatingFaction)
        ApplyBoundAnim(PlayerRef)
    EndIf
EndFunction

Still no IdleForceDefaultState?

I'd assume FNIS used to send it itself somewhere after the application of AA, but I didn't go thru it's sources closely yet.

 

This seems... kinda convoluted?

 

My proposition for the DAR version is to either:
 

Spoiler

Function EvaluateAA(actor akActor)
 

   libs.log("EvaluateAA(" + akActor + ")")
    if !libs.IsAnimating(akActor)
        Debug.SendAnimationEvent(akActor, "IdleForceDefaultState")
    EndIf

    libs.UpdateControls()

    If !HasCompatibleDevice(akActor)
        libs.log("EvaluateAA: Reverting to unbound AA")        
        ClearAA(akActor)
        RemoveBCPerks(akActor)
    Else
        ApplyBCPerks(akActor)    
    endif
EndFunction

 

Function ClearAA(actor akActor)
    if akActor != libs.PlayerRef && !akActor.isDead()
    akActor.EvaluatePackage()
        if !libs.IsAnimating(akActor)
        Debug.SendAnimationEvent(akActor, "IdleForceDefaultState")
        EndIf
    EndIf
EndFunction

or simply move the Debug.SendAnimationEvent(akActor, "IdleForceDefaultState") into zadlib's StartBoundEffects.

 

The StopBoundEffect hasn't got a problem calling it, and the idles refresh momentarily after you unequip stuff:

 

Spoiler

Event StopBoundEffects(Actor akTarget)
    Log("OnEffectFinish(): Bound Effects")        
    Debug.SendAnimationEvent(akTarget, "IdleForceDefaultState")    
    if aktarget == PlayerRef
        UnregisterForUpdate()
        UpdateControls()            
    EndIf    
    BoundCombat.EvaluateAA(akTarget)    
EndEvent

 

and leave evaluateAA for the combat perks at best, or - even better, leave it as a legacy function and just move everything into StartBoundEffect?

 

Can anybody who's actually understands this take a look and tell me why this is a bad idea?

P.S. Speaking of, is there a reason why in PlayBoundIdle() the evaluateAA isn't hidden behind a !IsAnimating(PlayerRef) check?

P.P.S. Is there a person on this planet who ACTUALLY uses both FNIS Sexy Move and DAR at the same time this day and age, or can I do away with the ResetExternalAA function too? ?

 

Edited June 27, 2023 by krzp

[Xenoramos]

On the topic of LE to SE\AE - I will leave here my opinion (which won't change anything anyway lol)

While I can understand that some thing on technical level are better in SE (like engine capabilities etc.), but for me, as for a regular player, SE is worse in most ways than LE, and here's my reasoning:

1 - LE is done in development, it does not receive patches, so game won't accidentally break in case of a sudden patch, and while I was playing SE, few unneeded-for-gameplay patches got released (I believe they fixed something in CC store) which completely broke SKSE and a few mods, so I had to wait around a week to play again, when mod authors released compatible patch for new update

2 - Manual mod installation is much easier in LE. Yes, I know what most sane people use any type of mod manager, but it's very difficult to come to it after many years of installing mods manually. I have tried... with very much patience from nice people who helped me understand at least basics of how to use it... but it's way too complex for me.

3 - Some things in general I can't understand and fully accept in SE.

3.1 - One of these - is very long fade-out from black screen when loading a game, when I can't do anything, but enemies are already active for several seconds, which is most important while playing higher difficulties and do save-load tactics, have to load and immediately open console to wait through that stupid inability to do anything ingame while enemies can land several hits on you. 

3.2 - Other thing - is that some genius decided that "Esc" button should lead to quest log instead of save\load\config screen. Yes, there's mod "fixing" it, but the mod isn't completely stable so sometimes it still opens quest log on "Esc"

3.3 - Overall performance. My LE modpack has pretty stable performance, dropping a few FPS only when something HEAVY happens (like first loading a heavy modded stuff, e.g. Angeli's DD Addon, because of it's huge textures), while SE with just a few mods works way worse, it's MUCH more resource-intense, so if I would want to do a serious playthrough with mods - I would have to accept being constantly below even 30FPS . That again, is my personal issue, but I can run some modern games better than SE with a few mods (literally a few, less than 20 already noticeably drop performance) in terms of FPS.

 

That are my main reasons why I keep LE as my main installation. If DD at any point will become SE-exclusive - that would be incredibly sad for me, even though I understand that it might be better overall.

DD was actually one of reasons I even started playing Skyrim many years ago (and probably the most important one too).

 

But anyway, good luck in further development, no matter what way you will choose.

[GreatCroco]

1. That's what AdressLibrary and disabling updated on Steam are for. If you missed that there are multiple tools to backpatch your SE version. Normal SE updates also don't break mods that use AdressLibrary (that's the whole point of it). What you probably refer to is the upgrade to AE, that was released at some point. That version of the game was compiled with a newer version of MSVC and therefore the address layout changed, which made AdressLibrary useless. The only other thing I can think of was that weird CC fix and JP translation, that broke AddrLib by changing the layout of the base classes. But that's really rare and I vividly remember how much worse it was in LE. That said it is a good idea to disable Skyrim updates, it always was.

2. Manual Mod installation hasn't changed between LE and SE, not a bit. You should use a ModManager, either MO2 or Vortex, because that helps a ton if you ever go more than two mods and therefore have to deal with conflicts. At some point it becomes even a necessity, e.g. when dealing with multiple NPC replacers.

3.1. I don't know what you mean exactly, as I don't have that. As soon as my SE has finished loading I'm in the game.

3.2. I don't know what mod you're using, but the easiest is StayAtTheSystemPage, that mod is absolutely stable. The alternative is QUI, which is also stable and has some other neat features (it's what I'm using)

3.3. a) How much time did you invest in getting it stable b) How many mods do you have?
       If your SE version performs worse than LE, you frankly did something wrong. I can run about three times more mods on SE than on LE (currently at 1.2k mods compared to the previous 450) without problems and my frames only drop to 30FPS (usually more) when I have 70+ NPCs in a single cell. Granted most are (4k) textures, but I my load order also has 468 plugins. And the stuff I had to do to make it stable? Nothing. It took me a week to sort out the conflicts between textures. But beyond that I just ran LOOT, Nemesis and Bodyslide.

Edited June 27, 2023 by GreatCroco

[krzp]

38 minutes ago, Xenoramos said:

1 - LE is done in development, it does not receive patches, so game won't accidentally break in case of a sudden patch, and while I was playing SE, few unneeded-for-gameplay patches got released (I believe they fixed something in CC store) which completely broke SKSE and a few mods, so I had to wait around a week to play again, when mod authors released compatible patch for new update

1.5.97 SE is done in development too, AE is "bleeding edge". ?

 

[Xenoramos]

17 minutes ago, krzp said:

1.5.97 SE is done in development too, AE is "bleeding edge". ?

 

1.5.97 isn't available to 'press "Install" and start installing mods', one have to do some inconvenient stuff to get that version. There isn't any "legacy" version on steam available for it sadly

[thedarkone1234]

1 hour ago, krzp said:

1.5.97 SE is done in development too, AE is "bleeding edge". ?

 

 

Good luck downloading LAL for it, though. The mod author is a bit of a prick and hates the idea of supporting anything but the newest version

[krzp]

2 hours ago, Xenoramos said:

one have to do some inconvenient stuff to get that version.

You can use this, it's barely a few clicks after installation ?

 

However, if you do want to upgrade at some point, I wholeheartedly recommend doing it using the latest AE version, I'm currently preparing to move from 1.5 to 1.6 and there's literally one small mod I haven't seen a direct replacement for yet, everything else is either AE-compliant or has a direct replacement - and I have 50 different SKSE plugins, so I've looked at fair number of them.

 

41 minutes ago, thedarkone1234 said:

Good luck downloading LAL for it, though. The mod author is a bit of a prick and hates the idea of supporting anything but the newest version

The first link after you google "ASLAL for 1.5.97" brings you here. So while I understand that this is an inconvenience having to search for it, but specifically using outdated software is a personal choice, so it's natural to expect to deal with some hoops to jump through while doing that.

 

And for alternate starts, why use mods made by "pricks" when there exists a great alternative made by none other than @Scrab, and a number of other ones. ?

[GreatCroco]

The LAL plugin for DD is probably one of the things that should get a conversion to Alternate Perspective ASAP, because frankly it's superior in almost all cases and avoid some stupid Arthmoor shenanigans.

If you do any other than the vanilla start and then do the Chloe quest, you need to traverse the cave as normal until you get to the spider, and then traverse the entire cave back (or use the backport Athmoor put in, because "cheating") and enter the cave from the rear end and collect your Riverwood companion. That's just a stupid decision.

[chaimhewast]

On 6/28/2023 at 6:21 AM, GreatCroco said:

The LAL plugin for DD is probably one of the things that should get a conversion to Alternate Perspective

There isn't a LAL plugin for DD. Certain mods that use DD might have LAL starts, but the framework itself doesn't.

[GreatCroco]

My bad, meant the DCL LAL plugin.

[zarantha]

On 6/28/2023 at 6:21 AM, GreatCroco said:

you need to traverse the cave as normal until you get to the spider, and then traverse the entire cave back (or use the backport Athmoor put in, because "cheating") and enter the cave from the rear end and collect your Riverwood companion. That's just a stupid decision.

 

I agree. Someone did figure out a workaround for it, and there's a patch to get rid of the forced teleport out of the caves up with all the other patches.

 

But I would also love to have the princess start for AP too. I wasn't able to figure it out myself and I tried. Or even a alternate start agnostic mod, where you go somewhere, get conked on the head or drink something (like trappings of fate) and wake up as a prisoner. then the princess start proceeds as normal. That way, people using realm of lorkhan could use that start too.

[krzp]

7 minutes ago, zarantha said:

I wasn't able to figure it out myself and I tried.

I've tried as well, but recompiling DCL is a major pain - it fails without Aradia, Captured dreams, all that jazz.

 

I used to just "setstage dcur_hq" after starting out on a unrelated start with AP, which isn't terribly... immersive ?

But the quest worked for me without ASLAL, so maybe someone with more creation kit experience can just create a sort of a bridge for the other mods, some new alternate start quest that starts up the dcl delivery refused quest?