Devious Devices Framework Development/Beta

[naaitsab]

6 hours ago, HexBolt8 said:

That's not my job.  I'm advocating for a compromise, one that considers the human factor of the equation and doesn't cut anyone off, because DD is an important framework with a far-reaching impact on every mod that depends on it.

 

In a compromise, each of the parties gets something that they like, and loses out on something else that would have been nice.  LE players would merely get the status quo, continuing features & fixes.  They'd lose out on the cool stuff being done for the SE version, things that likely wouldn't get ported to LE, whether for technical constraints or unwillingness to go to the trouble.  Well, okay.  SE players would gain whatever the clever minds of the SE contributors can come up with that works with the common DD core.  That's a huge improvement over the nothing they have today, where the SE version is just a port of the LE version.  In return, they'd lose out on things that they can't figure how to make work with the DD common core, and people would have to give up their time to do that development -- possibly Kimy if she wishes to take that on, possibly a team of contributors.

 

I'm seeing flexibility from pretty much everyone else who's spoken up, but you don't seem willing to accept any compromise.

Can you elaborate in what way you see the LE built making any compromises in this? Technical limitations are no compromise, that's a solid given and one of the main reasons why one should/could switch over. In this situation it's still a LE only mod and SE can sort themselves out. It feels very one-sided to me.

 

Keeping in line with your 'core-mod' principle. Which could be one of the solutions. There would have to be a LE team and SE team to maintain both sides of the core that differentiates from each other on SE code/optimisations. "luckily" there are not that many changes put forward in a monthly or sometimes even quarterly basis so if Kimy would be willing to merge both branches that would be the only even weighed compromise solution. Like I said before running both environments on a PC works perfectly fine. And she can so see if SE aligns with her interests in the process. If the SE side needs to hold their own pants up so to speak the details about that need to be discussed. Like appointing a "SE Kimy". Otherwise we revert into the current "fan made conversion with patchfest". Which I think we should al agree on, sucks. Especially for the mainstream LL visitors. Who don't like tinkering.

[Scrab]

1 hour ago, naaitsab said:

Can you elaborate in what way you see the LE built making any compromises in this? Technical limitations are no compromise, that's a solid given and one of the main reasons why one should/could switch over. In this situation it's still a LE only mod and SE can sort themselves out. It feels very one-sided to me.

 

Keeping in line with your 'core-mod' principle. Which could be one of the solutions. There would have to be a LE team and SE team to maintain both sides of the core that differentiates from each other on SE code/optimisations. "luckily" there are not that many changes put forward in a monthly or sometimes even quarterly basis so if Kimy would be willing to merge both branches that would be the only even weighed compromise solution. Like I said before running both environments on a PC works perfectly fine. And she can so see if SE aligns with her interests in the process. If the SE side needs to hold their own pants up so to speak the details about that need to be discussed. Like appointing a "SE Kimy". Otherwise we revert into the current "fan made conversion with patchfest". Which I think we should al agree on, sucks. Especially for the mainstream LL visitors. Who don't like tinkering.

 

Maintaining this "core" isnt really an issue honestly

 

DD is very straightforward in telling you "zadlibs are public API scripts. Use them, everything else is implementation"

If you were to go the path of "Kimy maintains LE, someone else maintains SE" then really all that means is "someone else doesnt change the interface functions in zadlibs and has free reign otherwise". The importance of a git here is that areas which havent been changed in some versioning breaking manner should obviously be forwarded/upstreamed to the LE/SE version to keep the general layout of both versions the same so that both versions can benefit from any improvements that can be forwarded/upstreamed

 

Im basically doing that very thing in SL+ right now. The only compatibility issues you have in that mod, are either direct overwrites (ie things that are "intended" to conflict with everything) or people not respecting this "that script is public API, use it, everything else is implementation" ruleset, whereas every mod that does listen to this ruleset;

(DD itself, SubLola, Devious Followers, Blue Forgs lineup, Lauras Bondage Shop, etcpp)

..All of these mods that do listen, dont run into any issues whatsoever

 

 

Edited June 24, 2023 by Scrab

[GreatCroco]

5 hours ago, Scrab said:

Maintaining this "core" isnt really an issue honestly

 

DD is very straightforward in telling you "zadlibs are public API scripts. Use them, everything else is implementation"

That's a good mindset and I have absolutely nothing against it. However, it only works with Papyrus code. SKSE plugins are not compatible, and need at least a recompile. More realistically, since you should use CommonLibSSE-NG (not available for LE) to remove much of the boilerplate and make developing easier, you need a complete rewrite or fall back to a Papyrus implementation (which is what Jaxonz Positioner does).  For models, animations, etc. you could argue that DD only ever gets new stuff once in a lifetime so doing work again is not a real issue. For the rest it's doing the work twice, but that's also what would happen either way.

 

I won't call that impossible, but I won't call that "not an issue" either.

 

5 hours ago, Scrab said:

The importance of a git here is that areas which havent been changed in some versioning breaking manner should obviously be forwarded/upstreamed to the LE/SE version to keep the general layout of both versions the same so that both versions can benefit from any improvements that can be forwarded/upstreamed

 

Which is pretty much the camp I was in from (almost) the beginning. Develop on SE and port back the bugfixes that can be ported back and add new features that don't rely on SE only stuff  can be added. What I argued against was staying LE centric because that limits the growth of the SE version or at least results in more work for everybody involved.

 

 

  

13 hours ago, HexBolt8 said:

I'm seeing flexibility from pretty much everyone else who's spoken up, but you don't seem willing to accept any compromise.

My second reply on this topic was literally:  "I never said to IMMEDIATELY switch, that's why I said 'with the next big patch';" and in the same post " Papyrus changes could """very easily""" be ported back. But what about the SKSE plugin? [...] If [the plugin] can be done, I'm for it by all means."

 

I fail to see where this is not offering compromise. But whatever...

 

6 hours ago, naaitsab said:

Can you elaborate in what way you see the LE built making any compromises in this? Technical limitations are no compromise, that's a solid given and one of the main reasons why one should/could switch over.

I'd like to know that, too.

Edited June 24, 2023 by GreatCroco

[naaitsab]

5 hours ago, Scrab said:

 

Maintaining this "core" isnt really an issue honestly

 

DD is very straightforward in telling you "zadlibs are public API scripts. Use them, everything else is implementation"

If you were to go the path of "Kimy maintains LE, someone else maintains SE" then really all that means is "someone else doesnt change the interface functions in zadlibs and has free reign otherwise". The importance of a git here is that areas which havent been changed in some versioning breaking manner should obviously be forwarded/upstreamed to the LE/SE version to keep the general layout of both versions the same so that both versions can benefit from any improvements that can be forwarded/upstreamed

 

Im basically doing that very thing in SL+ right now. The only compatibility issues you have in that mod, are either direct overwrites (ie things that are "intended" to conflict with everything) or people not respecting this "that script is public API, use it, everything else is implementation" ruleset, whereas every mod that does listen to this ruleset;

(DD itself, SubLola, Devious Followers, Blue Forgs lineup, Lauras Bondage Shop, etcpp)

..All of these mods that do listen, dont run into any issues whatsoever

 

 

Well this is one of the reasons a hard cut-over is the easiest way to proceed. But that will mean that the LE crew, which are a lot smaller in numbers but still alive and well are being left out. Or at least don't get new things. It's not that it becomes unusable the instant when development is halted. As the frameworks DD uses are long abandoned themselves. Guess one of the upsides of a EOL game.

 

That's why I would like to suggest if we do the 'dual-dev' is that all function calls are identical. So lockdevice has the same result on LE as SE and the same parameters. If in the background the SE version uses a whole different approach to do it faster than LE or more reliable etc that does not matter. Same goes for animations. If a MT animation is applied when wearing a device it should not matter if it's FNIS or OAR that does it. It's called from the same function on LE as SE. But I still like to see Kimy's view on the matter before we discuss things down to this level. 

[HexBolt8]

8 hours ago, naaitsab said:

Can you elaborate in what way you see the LE built making any compromises in this? Technical limitations are no compromise, that's a solid given and one of the main reasons why one should/could switch over. In this situation it's still a LE only mod and SE can sort themselves out. It feels very one-sided to me.

I believe you you're taking a glass-half-empty view if you think it's one-sided to develop & maintain a common core set for LE and offer an enhanced version for SE players, which would be a substantial gain for them over just mirroring the LE version as is currently done.  Importantly for SE players, by having a common core, DD-based mods developed for LE would continue to work with an enhanced SE DD.

 

There will be technical challenges and SE players might not get everything they want.  On the other hand, LE would get none of that, probably less if Kimy's time for the LE version is reduced.  I'd expect good communication between the core development and SE enhancement efforts, with changes implemented on the LE side wherever possible to facilitate the SE effort, working together to help each other.

 

The sticking point for some seems to be that building on an LE-developed core means that they won't get everything they'd like if they were free to gut DD and built it again from the ground up for SE.  They'd have to be satisfied with half a glass of water and recognize it as half full rather than half empty.

 

@Scrab had recently posted here about working with a core set of DD functions in an SE environment, speaking from personal experience with a positive, can-do attitude.  We might look to that as the model to follow.

Edited June 24, 2023 by HexBolt8

[naaitsab]

53 minutes ago, HexBolt8 said:

@Scrab had recently posted here about working with a core set of DD functions in an SE environment, speaking from personal experience with a positive, can-do attitude.  We might look to that as the model to follow.

 

Let's see what Kimy thinks about it. Reading from the posts made here I think there are a few options to choose from. Which I will deliberately state quite broad. As there first needs to be taken a direction before we spend time on the details.

 

1. Leave it as is. So developed on and for LE. SE stays supported on a basis of users converting it and adding patches in the thread.

LE Positives: It's designed for LE

LE Negatives: None, bar any SE fixes that can't be implemented (a LE problem in general of course)

SE Positives: None

SE Negatives: Fan supported LE->SE ports, patches are posted in the thread can get lost and will get combability issues between patches. No official SE 'single-file' download.

 

2. Leave LE and mark the current version as the last build. Switch over to SE for future releases.

LE Positives: Current version will continue to work as frameworks that DD rely on are long abandoned. Fan made patches can always be made and contributed

LE Negatives: No new shiny things until patched in by fans.

SE Positives:  Make use of all the good things SE and it's mods bring to the table. Performance and stability being the primary ones.

SE Negatives: None

 

3. Split the mod into a LE and SE development cycle with official releases of both. Keeping a general core whilst each version get's their own change "under the hood" codewise.

LE Positives: New features. devices and tweaks are added

LE Negatives: Needs to be kept compatible with SE in the core. Needs more dev time and/or mod owners

SE Positives: New features, devices and tweaks are added. SE will get it's own official release. No patchfest

SE Negatives: Needs to be kept compatible with LE in the core. Needs more dev time and/or mod owners

 

 

If we look at it at a pure numbers game. So the amount of players and new mods made for SE then option 2 is the clear winner. But if we want to keep LE up to date, with all of it's EOL issues we need to work out 3. Which can be quite a hassle. Option 1 in my opinion is off the table. As Kimy said there are enough reasons now to shift our attention to another route. And if we keep running 1 I fear the ever dwindling popularity of LL will continue as SE players look elsewhere.

 

I propose we use this system to bring options to the table. If someone has a 4th or 5th option post it here.

[AndrewLRG]

12 minutes ago, naaitsab said:

1. Leave it as is. So developed on and for LE. SE stays supported on a basis of users converting it and adding patches in the thread.

SE Positives: None

 

2. Leave LE and mark the current version as the last build. Switch over to SE for future releases.

LE Positives: Current version will continue to work as frameworks that DD rely on are long abandoned. Fan made patches can always be made and contributed

 

That's funny.

 

[HexBolt8]

1 hour ago, naaitsab said:

Let's see what Kimy thinks about it. Reading from the posts made here I think there are a few options to choose from.

Yes, it's already past the point where it feels weird talking about DD's future without Kimy's thoughts on the matter.  After Captain Kimy sets a course, it would be a good time to consider fruitful ideas for how to accomplish it.

 

Edit:  I know you were going for conciseness, which is appreciated, but points 1 & 3 above don't recognize the SE Player benefit of being able to continue to use LE-developed mods that use DD without extra conversion effort, possibly needing a third-party effort or patches.  That might include the newly re-released Captured Dreams, which targets DD 4.  It should work pretty well with DD 5.2, but maybe not so much with a divergent SE DD.

Edited June 24, 2023 by HexBolt8

[Scrab]

1 hour ago, naaitsab said:

Needs to be kept compatible with SE in the core. Needs more dev time and/or mod owners

This isnt really a negative but a rather neutral circumstance that is pretty common in a lot of ways. This "core" isnt really a big deal in the way you may think of it. Perhaps imagine this like a big room that is split in mutliple small ones:

 

Spoiler

 

Now, consider that in order for DD and other mods to interact, there needs be some extra layer that allows DD and these other mods to tell wtf is going on and this central layer is whats called an "API" and is also what HexBolt referred to as "Core" (I presume)

We use this API as a "middle man" to allow controlled and well defined data exchange between mods and DD itself:

 

 

The great thing here is that these mods are not actually interacting with DD but only with its API. This middle man acts essentially as an "interpreter". Similar to how you cant talk to someone that speaks a language that you cant through a middleman that speaks both languages, the API allows you to translate your requests to DD into some way that DD understands them

Now, what if DD were to change? Thats not a problem because if you tell the interpreter: Translate "I want cookies" into... french so that DD understands but DD then makes a change that causes it no longer speaks French, it now speaks German, then really all you need to do is change the interpreter. Then you got a different interpreter but you dont actually change anything on the dialogue, do you? The interpreter may be a different one, but you can still just tell that interpreter "I want cookies" and they will translate request for you into german so DD still gets it and give you cookies despite it no longer speaking french without you changing anything on your routine

 

This is why API are so powerful. They arent just there to give you some kind of easy access point into the framework but they also allow you to abstract the way you interact with a framework which gives the framework more ways to breathe

I hear some people cry over how SL+ is incompatible with a lot of things, but the reality is that SL+ made such a change and no longer speaks ... spanish. SL+ now speaks Japanese and if you try to make a request in spanish to SL+; avoiding or ignoring the interpreter/API it just wont understand you anymore, but mods that use the interpreter/API, can still make their request in spanish, and the interpreter will just translate it for you to Japanese, you will still get your expected result from that without actually noticing that SL no longer speaks spanish

 

Ok now, consider that we want to split DD into 2 parts, one that only speaks LE and another that only speaks SE, then really all we need to do is to make sure that the interpreter we use still speaks the language that the mods use to talk to DD and that that specific interpreter can speak the respective language of DD (either SE or LE) and that is all we need to care for. Essentially, going with that idea you basically turn this whole interaction model into something like this:

 

 

We have DD SE which only works on SE, we got DD LE which only works on LE, we got one and the same API for both and if you look at our mods room at the bottom, literally nothing changes. Theres still just 2 arrows, one in and one out and thats it. Both mods are indepdent from another, both mods could in theory have their own extra API if they wanted to but fundamentally, mods will that only use that one central API, will work fine with both DDs, no matter which version, no matter what either of them do as long as they dont mess with that central API everything will be fine

 

And what if one of them makes an important change that the other one should also get? You simply put a git between them and allow them to communicate through that:

 

 

And that is literally all

For mods using DD; nothing will change. They wont even notice this. Its essentially already like this except that Kimy is sitting in the DD LE chamber and the SE one is empty just getting an occasional visit to rid some dust because you dont use DD LE in your SE game and vice versa

 

These here are your 3 solutions:

 

                

 

 

Edited June 24, 2023 by Scrab

[naaitsab]

1 hour ago, HexBolt8 said:

Yes, it's already past the point where it feels weird talking about DD's future without Kimy's thoughts on the matter.  After Captain Kimy sets a course, it would be a good time to consider fruitful ideas for how to accomplish it.

 

Edit:  I know you were going for conciseness, which is appreciated, but points 1 & 3 above don't recognize the SE Player benefit of being able to continue to use LE-developed mods that use DD without extra conversion effort, possibly needing a third-party effort or patches.  That might include the newly re-released Captured Dreams, which targets DD 4.  It should work pretty well with DD 5.2, but maybe not so much with a divergent SE DD.

That's the exact reason I supposed to keep the calls the same between both versions. As mods are mostly API calls anyways. Otherwise you run into these kind of issues. Which are mostly easy fixes but one to mention non the less.

 

 But let's see what cap'n thinks of the options.

 

1 hour ago, Scrab said:

This isnt really a negative but a rather neutral circumstance that is pretty common in a lot of ways. This "core" isnt really a big deal in the way you may think of it. Perhaps imagine this like a big room that is split in mutliple small ones:

 

  Hide contents

 

Now, consider that in order for DD and other mods to interact, there needs be some extra layer that allows DD and these other mods to tell wtf is going on and this central layer is whats called an "API" and is also what HexBolt referred to as "Core" (I presume)

We use this API as a "middle man" to allow controlled and well defined data exchange between mods and DD itself:

 

 

The great thing here is that these mods are not actually interacting with DD but only with its API. This middle man acts essentially as an "interpreter". Similar to how you cant talk to someone that speaks a language that you cant through a middleman that speaks both languages, the API allows you to translate your requests to DD into some way that DD understands them

Now, what if DD were to change? Thats not a problem because if you tell the interpreter: Translate "I want cookies" into... french so that DD understands but DD then makes a change that causes it no longer speaks French, it now speaks German, then really all you need to do is change the interpreter. Then you got a different interpreter but you dont actually change anything on the dialogue, do you? The interpreter may be a different one, but you can still just tell that interpreter "I want cookies" and they will translate request for you into german so DD still gets it and give you cookies despite it no longer speaking french without you changing anything on your routine

 

This is why API are so powerful. They arent just there to give you some kind of easy access point into the framework but they also allow you to abstract the way you interact with a framework which gives the framework more ways to breathe

I hear some people cry over how SL+ is incompatible with a lot of things, but the reality is that SL+ made such a change and no longer speaks ... spanish. SL+ now speaks Japanese and if you try to make a request in spanish to SL+; avoiding or ignoring the interpreter/API it just wont understand you anymore, but mods that use the interpreter/API, can still make their request in spanish, and the interpreter will just translate it for you to Japanese, you will still get your expected result from that without actually noticing that SL no longer speaks spanish

 

Ok now, consider that we want to split DD into 2 parts, one that only speaks LE and another that only speaks SE, then really all we need to do is to make sure that the interpreter we use still speaks the language that the mods use to talk to DD and that that specific interpreter can speak the respective language of DD (either SE or LE) and that is all we need to care for. Essentially, going with that idea you basically turn this whole interaction model into something like this:

 

 

We have DD SE which only works on SE, we got DD LE which only works on LE, we got one and the same API for both and if you look at our mods room at the bottom, literally nothing changes. Theres still just 2 arrows, one in and one out and thats it. Both mods are indepdent from another, both mods could in theory have their own extra API if they wanted to but fundamentally, mods will that only use that one central API, will work fine with both DDs, no matter which version, no matter what either of them do as long as they dont mess with that central API everything will be fine

 

And what if one of them makes an important change that the other one should also get? You simply put a git between them and allow them to communicate through that:

 

 

And that is literally all

For mods using DD; nothing will change. They wont even notice this. Its essentially already like this except that Kimy is sitting in the DD LE chamber and the SE one is empty just getting an occasional visit to rid some dust because you dont use DD LE in your SE game and vice versa

 

These here are your 3 solutions:

 

                

 

 

 

In this case the left and right options still need patches if there are no official releases. In a "the needs of the many outweigh the needs of the few" usecase one could argument that LE should then go for the patch-support route. But let's see if we can get the middle one worked out. Or someone else has another angle to it all?

[thedarkone1234]

On 6/23/2023 at 8:54 PM, GreatCroco said:

Name a mod, any mod, that exists only on LE and, does not work with SE and has no replacement.

 

Not exactly something that "exists only in LE" per se, but BHUNP version 1.8 no longer exists as far as I searched on the internet. Current versions of it are incompatible with UUNP as too many sliders have been removed, added or changed. Which means: if I want to move to SE, I'd need to find myself good new armor replacers that work with the currently available versions of BHUNP (there aren't any good ones yet. Nothing like "Remodeled armor for UUNP"), or give up on BHUNP and just use UUNP, which has inferior breast physics and a much inferior vagina.

 

Not to mention that it appears HDT SMP is almost mandatory in most SE things (while on LE I can do with PE just fine), and I see a multitude of issues of people struggling to deal with havok objects and unworking physics, while mine work out of the box, on BHUNP 1.8, without me having to manually fix a bunch of files like all the solutions suggest.

 

If you can give me an actually simple-to-use one-fit-all body and armor replacers that fit it which also have compatible DD morphs, I might actually consider trying out a transfer. Else, if I can't even get my character to look right nude or clothed, with or without devices, without making me work manually through hundreds of bodyslide files, it's enough of a reason for me (and for most users of sex mods, I would guess), not to go for it.

[GreatCroco]

CBBE 3BA? That's what I'm using and I have BodySlide for every armour, with one or two exceptions iirc, but it's been a while. DD Sliders might be a bit wonky if memory serves correctly, but I don't have any problems. Unless I try to match ingame morphs to Bodyslide itself, but that's a completely different topic. CBBE 3BA also allows you to select between HDT-SMP and CBPC, or a mixture of both.

Edited June 24, 2023 by GreatCroco

[TrickyK]

7 hours ago, thedarkone1234 said:

Not to mention that it appears HDT SMP is almost mandatory in most SE things (while on LE I can do with PE just fine),

HDT SMP is HDT PE, just the SE version with a different name.

 

It also is outdated, because FSMP exists ( https://www.nexusmods.com/skyrimspecialedition/mods/57339 ). It's a vastly improved HDT version that can use modern CPU instruction sets and GPU acceleration.

 

7 hours ago, thedarkone1234 said:

I see a multitude of issues of people struggling to deal with havok objects and unworking physics, while mine work out of the box

 

Probably people running unlocked framerates above 60 causing the engine to spaz out. FSMP has a fix for this (or atleast some fix out there exists if I can remember it).

 

I've never had an issue with physics not working on SE when using FSMP, with one notable exception. The chains on some DD objects don't connect right. Zarantha has done some pretty heavy work getting them to look almost right though. That being said, the FSMP devs are actively working on a fix for this, and someone in the discord sent the dev a working bit of code for this specifically.

 

8 hours ago, thedarkone1234 said:

If you can give me an actually simple-to-use one-fit-all body and armor replacers that fit it which also have compatible DD morphs, I might actually consider trying out a transfer.

 

As croco said, CBBE 3BA is the best choice here. It is in no way inferior to BHUNP like UUNP vs CBBE was. 3BA can also have realistic jiggle if you choose the right options during install, if that's one of the reasons you went to BHUNP. You can also edit the config files to fine tune it.

 

As a bonus, it's also the most widely supported physics body, and has quite a few armor replacers. I'll just list a few.

 

Spoiler

https://www.nexusmods.com/skyrimspecialedition/mods/68235

 

https://www.nexusmods.com/skyrimspecialedition/mods/32518?tab=description

Note that this one wasn't updated to include the thigh gap slider, but is otherwise fine to use.

 

https://www.nexusmods.com/skyrimspecialedition/mods/81673

 

https://www.sunkeumjeong.com/post/the-amazing-world-of-bikini-armors-remastered-6-0

 

https://www.nexusmods.com/skyrimspecialedition/mods/70583

Replacers for the Anniversary edition DLC should you choose to buy it. Also includes zaps in the bodyslide.

 

https://www.nexusmods.com/skyrimspecialedition/mods/68238

Made by the same person as above, not a full replacer however.

 

 

[GreatCroco]

First a (small) bug report: If you have a keyholder and you loot a key from a container without looting the entire container (i.e. you right-click on the key to loot it) you might get the "cannot find the key" message in addition to "keyholder takes key". I have not checked if the keyholder actually gets the key or not. This does not happen if you loot the entire container.

Possible solutions:

1. The key always gets handed of to the keyholder no matter what

2. You first "loot" the key and it then gets handed to the keyholder. This also fixed the ""bug"" that you can just set the keyholder duration to one day, never return to them and not having to worry about dropping your keys ever again. If you need the keys you just waltz to the keyholder get the keys, remove devices and repeat the above. This could also be fixed by the keys magically getting returned to you when the duration is up, forcing the player to be more careful when exploring.

 

 

 

Second: I played around with CommonLibSSE-NG a bit and ported the DD SKSE plugin it it. Took me a whole of 30 minutes and now it has better logging, a dll for SE and AE, proper versioning, a single development setup with CMake that works with VSCode, VS, CLion, EMACS, etc. The plugin can now also be configured by a simple YAML fiel (e.g. for log levels) and supports hooking int SKSE and unit testing. It should also support easy ESP/ESM/ESL and FOMOD installer generation, although I haven't looked into that yet. It also integrates AdressLibrary and is therefore (almost) Skyrim version independent. SKSE is also dropped as a static dependency (users still need it though), making developing much less of a hassle.

 

Only downsides: Not compatible with the LE plugin in any case (No CommonLib), every change needs to be manually be ported back. I'd also like a better Conan integration instead of VCPKG, but that's still in beta.

 

 

20 hours ago, Scrab said:

This isnt really a negative but a rather neutral circumstance that is pretty common in a lot of ways. This "core" isnt really a big deal in the way you may think of it. Perhaps imagine this like a big room that is split in mutliple small ones:

Kimy already stated that they have no intention of making another braking change to the API as they did with V3->V4. 

Any future changes can then just add new API methods and deprecate the old ones with a simple log message, but otherwise keep them intact. This is similar to the way MathWorks and Microsoft do things and no matter how much I hate MATLAB, I give them, that I can run 15 year old programs with the latest version and maybe get a warning in the console.

 

But that was my idea anyway if a hard cut isn't done. Still wouldn't call that "common core" though.

[naaitsab]

1 hour ago, GreatCroco said:

But that was my idea anyway if a hard cut isn't done. Still wouldn't call that "common core" though.

Well if you look at it from a programming standpoint. The software core itself will be different. The calls (API "layer") to this core should not change. But one could also argue that the core could also be referred to as the core of the mod shared by both versions. So the meshes, animations, textures and functions of DD. (yes LE and SE in this also differs I know). This is used in more mods, mostly FOmod systems to define the mod without any patches, tweaks or addons.

 

Because we are dealing with different nationalisaties and backgrounds it might be best not to use pre-defined terminology before we make assumptions on each others outings.

[ChandraArgentis]

On 6/23/2023 at 12:54 PM, GreatCroco said:

Name a mod, any mod, that exists only on LE and, does not work with SE and has no replacement.

 

Devious Regulations.  Here's the compiled pack with the upgrades and patches for LE.  Doesn't work in SE.

Devious Regulations.zip

[GreatCroco]

The problem with Devious Regulations is not SE/AE, it's that it was built for DD version 2. See the topmost entry in the changelog:
 

Quote

1.7e
- Fixed camera getting stuck during Stormcloak scenes
- Improved behaviour with 3rd party collars and plugs
- Updated for DDi 2.8.1

Devious Devices had breaking API changes with version 4, which is what put Captured Dreams to its multi year hiatus.

Edited June 25, 2023 by GreatCroco

[naaitsab]

I've been running a customized version of that one on SE for a while now. Only thing that needs to be changed to make it work is some devices which one of the patches for LE also does. So yes, it's a DD "issue" not a LE-SE issue.

[ChandraArgentis]

2 hours ago, GreatCroco said:

The problem with Devious Regulations is not SE/AE, it's that it was built for DD version 2. See the topmost entry in the changelog:
 

Devious Devices had breaking API changes with version 4, which is what put Captured Dreams to its multi year hiatus.

1 hour ago, naaitsab said:

I've been running a customized version of that one on SE for a while now. Only thing that needs to be changed to make it work is some devices which one of the patches for LE also does. So yes, it's a DD "issue" not a LE-SE issue.

 

It works fine with LE though, so it does appear to be a LE-SE issue.  Tested with 5.1, I think.  I don't think I've tested with 5.2.

There are 3 variants of Regulars.  The initial mod, an update to it, and a patch to that one.  The file I provided is the most up-to-date I've found and works with LE and DD 5.x, but not SE.

Edited June 25, 2023 by ChandraArgentis

[TrickyK]

17 minutes ago, ChandraArgentis said:

I've found and works with LE and DD 5.x, but not SE.

 

I did a small amount of digging. It's because no one has bothered to post a converted version as most people just do it themselves with Cathedral Asset Optimizer. From the original thread >

On 1/13/2022 at 9:07 AM, Baltasarr80 said:

You can use the cathedral asset optimizer to make it work in se ... i tright it the the dev regulations plug version on se

 

This takes like 10 minutes to do. The plugin might also need ran through SSEdit for the bugfix patch, but probably works with no effort.

[DonQuiWho]

1 hour ago, TrickyK said:

 

I did a small amount of digging. It's because no one has bothered to post a converted version as most people just do it themselves with Cathedral Asset Optimizer. From the original thread >

 

This takes like 10 minutes to do. The plugin might also need ran through SSEdit for the bugfix patch, but probably works with no effort.

 

I hate to butt in on the technical discussions of my, maybe not elders, but almost certainly betters, but there some of us out here, maybe even quite a lot of us, who might well not have the faintest idea what you're talking about, let alone start to try to do what you suggest. 

 

Very grateful for the scraps from the masters' tables, but that's about the best some of us can hope for

 

DQW

[TrickyK]

11 minutes ago, DonQuiWho said:

there some of us out here, maybe even quite a lot of us, who might well not have the faintest idea what you're talking about, let alone start to try to do what you suggest. 

 

Alright, https://www.nexusmods.com/skyrimspecialedition/mods/23316 Cathedral Asset Optimizer is a mod made specifically for porting assets from LE mods and converting them to work with SE. Full use instructions are on the Nexus page ( https://gitlab.com/G_ka/Cathedral_Assets_Optimizer/-/wikis/Porting-a-mod ). As you can see, it's not a very long process.

 

As for SSEdit, it's the SE version of XEdit. It's not exactly needed to convert them however, but I use it to verify nothing went wrong.

 

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.

Spoiler

 

 

As for why I'm bringing this kind of stuff up in the DD development page, there seems to be a sizable number of users here that seem to think going from LE to SE is a massive chore or will break everything, or will make them lose half of their mods.

 

Most of this is misinformation, and it's actually much easier than people think if they don't mind doing a bit of research. I was forced to move to SE because of the save string limit, a hard limit on the amount of data a save can contain before it just starts crashing your game. I kept getting into about 50 to 100 hours and then my saves all die to it.

 

This is not even remotely an issue on SE as long as you install SSE Engine fixes.

 

At no point did I ever regret switching over. The new mods only on SE more than made up for the ones I didn't bother converting on LE (which was like 4 mods, and nothing major).

 

I'm also of the opinion that sticking to LE is holding back the DD Framework. DD is already losing out on features and performance for the sake of backwards compatibility. I'd rather the mod authors on LE move forward with us than stick with LE, and show them that it really is not that hard to switch over. I don't like the idea of leaving anybody behind, but if we don't switch now, than when some other incredibly useful SE only mod comes along that DD could very much use, this discussion will end up coming back again.

[qawsedrftg765]

On 6/23/2023 at 4:13 AM, Kimy said:

In the end...I am not sure. Feel free to let me know what you guys think! 

I am not a major mod author on this site for SE/LE but I can say that in my experience as a heavy end user Skyrim SE has been a massive boon. The SE platform with things such as .NET scripting framework are just capable of offering more to the end user. On top of that outside our pervy corner of the internet ALMOST all MAJOR Skyrim content is SE first. I am personally running a save game with DCL, DD, and LotDB since March 2020 with hundreds of hours played and the save game is super stable with minimal issues. I could see an argument in 2019 to not swap over as there were still a lot of the major mods not ported over. But now It is really had to think of more than a handful of the 'big' mods that have not been outright ported or superseded in some way. The ones that I can think of tend to be the horny ones. 

the DD framework and mods that use it are probably one of the few that are LE first and SE second with Zarantha doing a hero's effort to make things like DCL and DD work on SE.

More users play on SE, SE is more powerful and has more options these days. Let us not forget SE came out in 2016. It is a matured game now... it has been the 'main' version of skyrim for longer than LE was the main version of skyrim. SE is obviously not the 'only' way to play skyrim and I OBVIOUSLY, hold nothing against people who play LE.

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.

There are then two ways to frame the question

"Is it fair to not improve the end user experience as much as possible to accommodate legacy users? "
OR
"Is it fair to not accommodate legacy users to make the most complete version of the software?"

The easy option is to just say 'JuSt MaKE iT WoRK oN BoTh'. Which anyone with more than 2.3 minutes of dev experience will tell you is if not impossible, massively implausible.

There isn't a perfect answer but in my experience the overwhelming majority of people will swap. People will kick, scream, and hollar all the way upto and during release; whatever choice you make the unhappy group will ALWAYS be the loudest; I once got a furious email from someone upset my company was no longer supporting WINDOWS PHONE. But then they almost always swap and the project is better for it.

 

I would say go to SE, but I am on the outside looking in and the only one who can make the ultimate call is the dev and whatever Kimy decides should be respected.

As a note. Remember the Modernwarfare boycott where people where FURIOUS about MW2 and WOULD NEVER play it without dedicated servers, how forum users would make sure the game was a failure.


Edit: I have seen a lot of people mention Cathedral Assets Optimizer (CAO) and how it can be used to port mods over the SE. Which is true, but the more complex the mod the less likely it will work out of the box. Something like "Being a Cow, DCL or DD" do NOT work without specific effort being put in by people like zarantha. It is also not likely that every user will both use CAO and use it well.

It is also worth noting that if users will not swap for a new update, they still have the old stuff they like. I would assume Kimy would not just delete and LE content if SE became the primary development branch.

Edited June 26, 2023 by qawsedrftg765
CAO

[HexBolt8]

Thank you, @qawsedrftg765.  Although I'm one of the people hoping for ongoing LE support for Devious Devices, that was a thoughtful and well-stated post.

[krzp]

Speaking of "easy to develop on LE and then convert to SE", there is a popular mod made for DD, it's being currently developed on LE and then converted by someone else to SE.

Has like 250 k downloads on SE (in fact, it's LE version is at 100k downloads, so SE is the more popular version)

 

It also has this:
 

Spoiler

 

 

 

 

 

 

.... ooops.

(I'm not missing any dependencies, it's a HITME thing)

 

P.S. Tbf, the mod works - trips up DynDOLOD and my OCD, but works.

Edited June 26, 2023 by krzp