Devious Devices Framework Development/Beta

[thedarkone1234]

Random issue I just found: catsuits are considered nude by EVG conditional idles. Any idea what condition I can add to EVG to consider catsuits as clothing? Maybe some keyword thatt indicates that the boobs and holes are covered?

[Miauzi]

Vor 13 Minuten sagte thedarkone1234:

Zufälliges Problem, das ich gerade gefunden habe: Catsuits werden von EVG-bedingten Leerläufen als nackt betrachtet. Irgendeine Idee, welche Bedingung ich zu EVG hinzufügen kann, um Catsuits als Kleidung zu betrachten? Vielleicht ein Schlüsselwort, das darauf hinweist, dass die Brüste und Löcher bedeckt sind?

 

then one would perhaps still have to differentiate ... because in a transparent catsuit one is really "naked".

if you also have a chastity belt and the matching metal breast cover on your body - you should NOT be considered "naked" according to the usual definitions.

I have finally deleted the whole thing from my "catalogue" of meaningful comments and I ignore NPC's linguistic statements.

(whether the necessary programming and testing effort is really worth it - of course only the authors themselves can decide)

[Taki17]

1 hour ago, thedarkone1234 said:

Random issue I just found: catsuits are considered nude by EVG conditional idles. Any idea what condition I can add to EVG to consider catsuits as clothing? Maybe some keyword thatt indicates that the boobs and holes are covered?

The issue is that the "zad_DeviousSuit" keyword used on catsuits is also used to denote any other restraint that replaces the body when equipped, which means it's also used on the breast yoke, the box binder or hobble dresses.

 

Ideally, the keyword that marks such items should be separated into a new one like "zad_BodyReplacer". I may do something about that in the form of another contribution, however I need to assess its impact first.

 

Edited June 30, 2023 by Taki17

[thedarkone1234]

10 minutes ago, Taki17 said:

The issue is that the "zad_DeviousSuit" keyword used on catsuits is also used to denote any other restraint that replaces the body when equipped, which means it's also used on the breast yoke, the box binder or hobble dresses.

 

Ideally, the keyword that marks such items should be separated into a new one like "zad_BodyReplacer". I may do something about that in the form of another contribution, however I need to assess its impact first.

 

 

Tbh that wouldn't be an issue in my case because FNIS wins against OAR/DAR so the yoke would prevent nude animations anyway. As long as the end result is my character is NOT considered naked with arms free, the rest doesn't matter

[krzp]

5 hours ago, thedarkone1234 said:

Random issue I just found: catsuits are considered nude by EVG conditional idles. Any idea what condition I can add to EVG to consider catsuits as clothing? Maybe some keyword thatt indicates that the boobs and holes are covered?

I have a "cover yourself" animation as well, without EVG - iirc, this is what I've added to the condition set so the catsuits don't trigger.

 

NOT IsWornHasKeyword("Devious Devices - Assets.esm"| 0x02AFA3)

 

[Hex Bolt]

As it is, every mod that checks for body clothing or armor concludes that the wearer of a catsuit or hobble dress is nude.  It might make sense for the rendered non-transparent versions to have the ClothingBody keyword.  Although they're form fitting, they provide a lot of coverage.  That would remove the need for player workarounds for nude idles or helpless when naked mods.

 

Edit: A few posts below explain why this is not practical.

Edited July 2, 2023 by HexBolt8

[GreatCroco]

21 hours ago, Maddac said:

I agree with all of the above, which is why I still prefer LE to SE. its crazy that SE is 64 bit yet performs worse than LE. I couldnt imagine running SE with all the mods I have in LE, and I also do manual install and tweaking in tes5edit where needed to ensure stability.

Naturally, if you just take the mods you have on LE and use their SE conversion you run into the risk of leaving performance on the table. It is usually a wise choice to clean up the load order a bit and replace as many mods as possible with newer versions. Of course, the first thing you do on SE is to install all of the engine fixes and performance mods that LE doesn't have. It's not a magic "get 60FPS for free" solution, but even a Ryzen 7 2700X and a 1080 are sufficient to run a quite heavy load order with ENB at around 40 FPS. Although, it might be wise to leave out the ENB with that Hardware.

 

11 hours ago, Xenoramos said:

But my hardware still theoretically should be enough to play SE without heavy mods with good performance, but in fact even pure vanilla game with 0 mods runs lower than 60FPS, which, added to other things I mentioned, is making SE much worse personal experience than LE

which is quite odd given that a NVIDIA GTX 780 3GB is really nothing powerful. Do you have the game on a SSD or spinning Rust?  

Edited June 30, 2023 by GreatCroco

[knots1353]

On 6/22/2023 at 2:13 PM, Kimy said:

It's unfortunately not a clear win for either solution. Both have their ups and downs. In favor of switching you could argue that any new features I might add to DD at this point would likely make use of SE-exclusive functionality anyway, so it's not that remaining LE content mods and LE users would lose out big time here. They could still use the latest LE DD version, and it's not that I couldn't back-port serious bugfixes to the LE version. I have zero plans to make another API-breaking DD release, so the impact on LE content mods might be marginal?

 

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

 

So... I never *released* any of the mods I was working on, but for a year and a half back in 2021/22, I did some rather extensive work on a replacement extensible event framework mod.   As part of that, I did pretty extensive testing and experimentation on both SE and LE, on how event threading worked, how mod upgrades affected existing threads, and a lot of different edge condition testing in both papyrus and C++.   The framework would have meant fairly significant rewrites of a lot of mods if they wanted to take advantage, but my early performance testing suggests a massive improvement in pretty much every area because it would have taken so much processing out of Papyrus and done it in C++.

 

That said, while I think such a framework would have *hugely* benefited mod development had it come out six or seven years ago, I ultimately realized that there was just too much legacy modding out there, even for SE, for it to make the impact I wanted.   And when I realized I'd need to abandon LE support, well, it took a lot of wind out of my ideas.   Other games caught my interest, and I shelved the project, although there's a good chance I may revive a version of the framework for Starfield if it looks like it can benefit from it - by getting it out early, it might catch on much better.

I mention that mainly for background because of the part where I had to remove LE support.   There were a lot of reasons I had to do that.   One big one was that papyrus threading is less significantly less quirky and much more forgiving in SE, especially when you have multiple papyrus threads calling each other and papyrus threads are running on a script which is being updated across a save.  (For those unaware, the *original* version of the compiled script is cached and loaded from the save so it can resume the thread exactly where it left off, and that papyrus thread continues running that older version until it returns outside the script... but functions it calls in *other* scripts may load the new version of those scripts... and if those scripts call a function in the original script it's likely to run the new version of that script.)

But the big one was the strings limit.  LE has a hard limit of 65535 strings... if you have more, it will start failing in unpredictable ways without warning you.   SE also has limits on this, but they're a couple orders of magnitude higher.   And I could see that the framework design I had, which used named events, and was designed to break down events into chains of smaller events with decision branches and nested events and a lot of other things like that, was going to be used to make unpredictably huge number of event strings.   I tried a redesign which worked with numeric IDs instead of names, but it broke some of the core design concepts, so I had to abandon LE completely.

 

Once I made the decision to abandon LE, it greatly simplified development of the remaining version.  Only one version of the DLL needed to be built, I didn't have to worry about significantly different versions of SKSE built with different compilers, and the papyrus side became a lot simpler as well as I didn't have to worry about a lot of the LE quirks.

I'm not sure if any of those reasons have any application to you, but I thought I'd put them out there for you as part of your decision.
 

[Maddac]

On 6/30/2023 at 3:09 PM, naaitsab said:

It's a very stubborn misconception that 64-bit is some kind of magic trick to make everything twice as fast. It isn't. It only allows a program to natively use more system recourses so in theory it can run faster and more stable as it has to swap less. A bit like removing a restrictor on a bike, without swapping the engine it's still the same engine but it can output more power.

 

SE also ships with a lot more graphical ENB like stuff, which impact the performance out of the box. But I'm quite curious what PC's you both are running as on my rig SE runs a lot better in FPS and more important way better 0.1% lows (stuttering etc). 

Intel I7 11700k, 16GB ram, Gigabyte Z590 Aorus Master Ultra, Gigabyte 3060 graphics card, 1TB PCI4.0 NVME SSD, 3 x 2TB sata drives. but its the monitor that surprised me when I upgraded recently from 24" Viewsonic 1ms 60Hz to Samsung G50A @ 165Hz, as Skyrim for LE loads superfast, whereas it loaded like a dog on the old viewsonic. doing a new game with my 400+ heavily modded skyrim would take a few minutes, whereas with the new monitor its done in 30 seconds. loading an existing game is really fast, like 1 second. I never thought a new faster monitor would make such a difference.

[Taki17]

15 hours ago, HexBolt8 said:

It might make sense for the rendered non-transparent versions to have the ClothingBody keyword.

That I can see causing issues with existing mod implementations that check for items worn by the player or being in their inventory. So far Devices not having clothing and armor keywords was a safe and straightforward of differentiating them for regular outfits.

[naaitsab]

2 hours ago, Maddac said:

Intel I7 11700k, 16GB ram, Gigabyte Z590 Aorus Master Ultra, Gigabyte 3060 graphics card, 1TB PCI4.0 NVME SSD, 3 x 2TB sata drives. but its the monitor that surprised me when I upgraded recently from 24" Viewsonic 1ms 60Hz to Samsung G50A @ 165Hz, as Skyrim for LE loads superfast, whereas it loaded like a dog on the old viewsonic. doing a new game with my 400+ heavily modded skyrim would take a few minutes, whereas with the new monitor its done in 30 seconds. loading an existing game is really fast, like 1 second. I never thought a new faster monitor would make such a difference.

Probably something else going on here. The only game I know of that has a FPS load menu bug is Fallout4. On which increasing/unlocking FPS using a mod greatly reduces load times. This involves the load screen, so not desktop -> main menu load time. As far as I know this was fixed when they modified the engine for SE. I haven't seen much difference between LE and SE load times on general if you use a custom DLL loader procedure (ENB). SE loading takes a bit longer from desktop but as it crashes almost never anymore it's something I don't care about. One of the benefits is that SE has some ENB functions buit in natively. So if you don't want to tinker a lot with it you could run SE without ENB vs LE with ENB to make it more even, will greatly increase performance.

[Xenoramos]

14 hours ago, GreatCroco said:

which is quite odd given that a NVIDIA GTX 780 3GB is really nothing powerful. Do you have the game on a SSD or spinning Rust?  

I don't have any SSD, they were really expensive by the time I got my PC, so I remained on HDDs.

[GreatCroco]

2 hours ago, Xenoramos said:

I don't have any SSD, they were really expensive by the time I got my PC, so I remained on HDDs.

Well that's probably the cause, as HDDs are just too slow nowadays. I'd suggest getting a decent SATA SSD, which can be had for around 50 bucks per TB. That's just 10 bucks more than an equivalent HDD.

 

 

3 hours ago, naaitsab said:

Probably something else going on here. The only game I know of that has a FPS load menu bug is Fallout4. On which increasing/unlocking FPS using a mod greatly reduces load times. This involves the load screen, so not desktop -> main menu load time. As far as I know this was fixed when they modified the engine for SE. I haven't seen much difference between LE and SE load times on general if you use a custom DLL loader procedure (ENB). SE loading takes a bit longer from desktop but as it crashes almost never anymore it's something I don't care about. One of the benefits is that SE has some ENB functions buit in natively. So if you don't want to tinker a lot with it you could run SE without ENB vs LE with ENB to make it more even, will greatly increase performance.

I don't know if the duration changed between SE and LE, and I'd have to check the ini files;  but there's a setting that forces the game to stay in the loading screen. This setting exists to give the game some time to ramp up the loaded papyrus scripts.

 

 

13 hours ago, knots1353 said:

So... I never *released* any of the mods I was working on, but for a year and a half back in 2021/22, I did some rather extensive work on a replacement extensible event framework mod.   As part of that, I did pretty extensive testing and experimentation on both SE and LE, on how event threading worked, how mod upgrades affected existing threads, and a lot of different edge condition testing in both papyrus and C++.   The framework would have meant fairly significant rewrites of a lot of mods if they wanted to take advantage, but my early performance testing suggests a massive improvement in pretty much every area because it would have taken so much processing out of Papyrus and done it in C++.

[...]

That's very similar to what the "Fully Dynamic Game Engine" plugin does. I wanted to try it, but there's a VCPKG issue that prevents me from getting all the required dependencies. That's a bummer, but VCPGK is what it is.

[knots1353]

1 hour ago, GreatCroco said:

Well that's probably the cause, as HDDs are just too slow nowadays. I'd suggest getting a decent SATA SSD, which can be had for around 50 bucks per TB. That's just 10 bucks more than an equivalent HDD.

 

 

I don't know if the duration changed between SE and LE, and I'd have to check the ini files;  but there's a setting that forces the game to stay in the loading screen. This setting exists to give the game some time to ramp up the loaded papyrus scripts.

 

 

That's very similar to what the "Fully Dynamic Game Engine" plugin does. I wanted to try it, but there's a VCPKG issue that prevents me from getting all the required dependencies. That's a bummer, but VCPGK is what it is.

Looking at that, FDGE looks more like a wrapper for more easily creating DLL plugins -- although it's hard to say because the docs are incomplete and the sample project they point to doesn't exist.  XEvents was going to be a way of doing Papyrus events differently, by adding extensible ModEvents that had a context containing arbitrarily large datasets of tagged parameter data, a return mechanism so you could identify when an event was complete and return a result, allowing triggering a chain of events in a list, with special handling for Conditional events (events which trigger different choices based on data in the context), Alternative events (events which trigger different choices based on a random weighting), and cleanup events which can be scheduled by an event, during it's handling, that will be triggered when the major event list is complete.   All sub-events could access the context of their parents, and mods could make certain events public by name (such as a Alternative list) and other mods could easily add to it.

So, if Mod A provided a trigger (say - fast travel via cart), and a event which operated on that trigger that had weighted alternatives, OTHER mods could easily add their own weighted alternatives based on the event name, and it would just work - and the other mods wouldn't even need to do soft dependency checking -- if the alternatives event existed, they simply add their own to the list.  A lot of the Conditional checking would have been doable without even calling back into Papyrus as it was going to have a set of basic event operators built into the DLL that could compare, test, and even modify data in the context.  The net effect is that most of the busywork that goes into every mod ends up in the Xevents DLL, leaving smaller and more maintainable Papyrus fragments to do the actual unique behavior of your mod, and encourage coding of Papyrus in those smaller fragments instead of huge monolithic functions which do setup, then comparison checking, then more setup, then execute the compared result, then do cleanup, often with manually defined delays to allow other events to complete because they had no return to indicate completion.

[Hex Bolt]

7 hours ago, Taki17 said:

22 hours ago, HexBolt8 said:

It might make sense for the rendered non-transparent versions to have the ClothingBody keyword.

That I can see causing issues with existing mod implementations that check for items worn by the player or being in their inventory. So far Devices not having clothing and armor keywords was a safe and straightforward of differentiating them for regular outfits.

Could you explain a little bit more about the problem?  I don't see it, but I might be missing something.  Just to be clear, my suggestion was to add the ClothingBody keyword to a few devices that cover the body, leaving all the existing keywords in place.  Mods that check for those keywords would continue to work as before.  The zad_DeviousSuit keyword on the worn devices would distinguish them from regular outfits.  The inventory devices wouldn't need to change.  That seems very compatible with existing mods, but possibly you're aware of a conflict situation that I haven't considered.  In the absence of any conflict, the advantage is that NPCs will stop reacting as if the wearer is naked despite being covered neck to foot in a catsuit (or hobble dress).

Edited July 1, 2023 by HexBolt8

[thedarkone1234]

2 hours ago, HexBolt8 said:

Could you explain a little bit more about the problem?  I don't see it, but I might be missing something.  Just to be clear, my suggestion was to add the ClothingBody keyword to a few devices that cover the body, leaving all the existing keywords in place.  Mods that check for those keywords would continue to work as before.  The zad_DeviousSuit keyword on the worn devices would distinguish them from regular outfits.  The inventory devices wouldn't need to change.  That seems very compatible with existing mods, but possibly you're aware of a conflict situation that I haven't considered.  In the absence of any conflict, the advantage is that NPCs will stop reacting as if the wearer is naked despite being covered neck to foot in a catsuit (or hobble dress).

 

I am not sure about the implementations, but for example, if a single mod punishes you for wearing clothes (like some DCL collars), it would kill you for being stuck in catsuits. You need exactly one mod that exists that punishes clothes and is not dependant on DD, and that mod will break, and require an external patch to fix it.

 

I bet other uses for ClothingBody for other reasons. Each one that would need to logically exclude catsuits would have the same issue and require a DD-specific patch.

[Hex Bolt]

1 hour ago, thedarkone1234 said:

 

I am not sure about the implementations, but for example, if a single mod punishes you for wearing clothes (like some DCL collars), it would kill you for being stuck in catsuits. You need exactly one mod that exists that punishes clothes and is not dependant on DD, and that mod will break, and require an external patch to fix it.

 

I bet other uses for ClothingBody for other reasons. Each one that would need to logically exclude catsuits would have the same issue and require a DD-specific patch.

I see, it makes sense.  That's what I was missing.  Thank you.

[GreatCroco]

5 hours ago, knots1353 said:

Looking at that, FDGE looks more like a wrapper for more easily creating DLL plugins -- although it's hard to say because the docs are incomplete and the sample project they point to doesn't exist. 

The sample plugin is another program in gitlab. What you want to do it can as well, via function hooks, although those seem to be more low level, seing as the user needs to deal with addresses themselves.  However, what you say could've been a real game changer back in the day. Even today, if it was to be implemented into something like CommonLibSSE.

[krzp]

On 6/22/2023 at 4:00 PM, ponzipyramid said:

Just wrote a quick version of the plugin using CommonLibSSE-NG. Thanks to @zarantha for suggesting this. I am by no means an expert on DD's scripts so it's tough to validate whether or not what I've done actually works; feedback is appreciated.

I have updated to 1.6.40, finally, and, despite the overall flaming wreckage that is my mod list is right now, your plugin seems to be working A-OK, not seeing anything DD plugin related in my logs, so another confirmation of it working from me. ?

[naaitsab]

Small adaptation to the script "zadBQ00" on the "StartValidDDAnimation" procedure that currently does not allow the 'center on' parameter to pass to the associated SL function. If you want to use that you need to use the SL function which then needs to go the filter adding latency.

 

zadBQ00.psc

line 1352:
Bool Function StartValidDDAnimation(Actor[] SexActors, bool forceaggressive = false, string includetag = "", string suppresstag = "", Actor victim = None, Bool allowbed = False, string hook = "", bool nofallbacks = false, ObjectReference CenterOn = none)

line 1406:
SexLab.StartSex(Positions = SexActors, anims = Sanims, victim = victim, CenterOn = CenterOn , allowbed = allowbed, hook = hook)

 

Edited July 2, 2023 by naaitsab

[krzp]

Have anyone ever got their character in a device called Rope Armbinder?

If you did, you probably know that in case anything triggers the DDArmbinderSolo animation leads to your character's hands casually exiting the device like it isn't there.

 

I've looked at the code,

Function CreateDDArmbinderSolo(int id)
<...>
Anim.AddPositionStage(a1, "ZapArmbHorny01", 0, silent=false)

 

That animation isn't working at all with elbowbinder-type devices.

 

So, what I'm proposing, is to either replace ZapArmbHorny01 with something more... both arm binder and elbow binder friendly (I did that, I'm lazy - ft_horny_elbowbinder_1 works well enough, especially if you tweak the elbows just a little bit for regular arm binder-type devices), or create a separate animation group, something like:

 

Spoiler

Function CreateDDElbowbinderSolo(int id)
    libs.Log("Creating DDElbowbinderSolo")
    sslBaseAnimation Anim = SexLab.GetAnimationObject("DDElbowbinderSolo")
    if Anim != none && Anim.Name != "DDElbowbinderSolo"
        Anim.Name = "DDElbowbinderSolo"
        Anim.SetContent(Sexual)
        int a1 = Anim.AddPosition(Female)
        Anim.AddPositionStage(a1, "ft_horny_elbowbinder_1", 0, silent=false)

        Anim.SetStageTimer(1, 20.0)
       
        Anim.AddTag("Solo")
        ;    Anim.AddTag("Masturbation")
        Anim.AddTag("F")
        Anim.AddTag("Elbowbinder")
        Anim.AddTag("DeviousDevice")
        Anim.AddTag("NoSwap")
       
        Anim.Save(-1)
    EndIf
EndFunction

 

Edited July 3, 2023 by krzp

[Kimy]

Lots of good points here! Thanks for the input, everyone!

 

A few points to consider from my own side:

 

1. Anyone guessing that I have limited experience with SE is correct. I have SE installed, but never really used it much. I guess a lot of the new and exciting SE features you guys are talking about I might have never heard of. Some of them sound definitely intriguing, though!

2. I do agree with many of you that SE should have better support than it has now.

3. I have no plans to outright retire the LE version.

4. I am also not too keen on the idea to outright fork DD and hand SE development to an independent maintainer. I'd like the two versions still follow the same vision.

5. One idea I have been toying with is lifting the current requirement that everything added to DD also must be in the LE version. Which would allow us to compile a list of desirable SE-only features to add to DD and see if we can add them to the SE version. This would not hurt LE players, as these features are not available for LE anyway.

6. One exception from the above is devices, which I still would love to offer both the LE and SE version. But I don't expect devices to use any SE exclusive features anyway (I can't think of any SE only features they could use, at least), so it should be all good.

7. New features that make sense on LE will get backported whenever possible, as will bugfixes.

 

While this will make the development process a bit more complicated on my end, DD is largely a mature project at this point, so the workload should be manageable (I'd probably see this differently if I expected DD still to evolve and grow dramatically, but I think it's fairly feature complete at this point). The only caveat is my own inexperience with SE, so I'd probably need some help with the new features.

 

Thoughts?

[Hex Bolt]

24 minutes ago, Kimy said:

Thoughts?

It seems like a balanced approach that offers benefits for SE players, while keeping LE players and developers in the fold, and maintaining a common vision across both versions.  The common vision will facilitate mods that want to offer LE/SE/AE versions, knowing that the concepts behind the devices will be consistent.

[naaitsab]

30 minutes ago, Kimy said:

 

Thoughts?

I went a full 180 on LE vs SE a few months ago and I can only suggest others to try it (again). Near everything is ported now or even surpassed and it's wayyyy less of a let's keep it positive, "adventure" to get it up and running without crashing every 5 minutes or running like crap 

 

I think the setup you've written is about what most people are aiming for. Foremost it will give SE some very much needed spit and polish and can integrate all nice tweaks instead of being "just" a conversion. It will also shift the 'new stuff' attention more towards SE as there are awesome mods that just don't exist for LE. So it does not feel like LE is the ball and chain keeping it tied down. We do need to keep an eye out to keep the main API calls the same. How it works under the hood can be totally different of course.

 

Might be a good time for the discussion to shift it towards the how and not the why anymore. Perhaps splitting this beta/dev thread into a LE and SE version would help? Posting stuff here and marking it LE or SE with discussions in between probably will be a mess. For code only stuff Git could still be a great tool to use. As it allows merging and change tracking on the text based script files. So it does not have to be a forumpost that can get lost in other chatter. And then it can be marked as merged or getting comments on it by other contributors.

[t.ara]

1 hour ago, Kimy said:

Lots of good points here! Thanks for the input, everyone!

 

A few points to consider from my own side:

 

1. Anyone guessing that I have limited experience with SE is correct. I have SE installed, but never really used it much. I guess a lot of the new and exciting SE features you guys are talking about I might have never heard of. Some of them sound definitely intriguing, though!

2. I do agree with many of you that SE should have better support than it has now.

3. I have no plans to outright retire the LE version.

4. I am also not too keen on the idea to outright fork DD and hand SE development to an independent maintainer. I'd like the two versions still follow the same vision.

5. One idea I have been toying with is lifting the current requirement that everything added to DD also must be in the LE version. Which would allow us to compile a list of desirable SE-only features to add to DD and see if we can add them to the SE version. This would not hurt LE players, as these features are not available for LE anyway.

6. One exception from the above is devices, which I still would love to offer both the LE and SE version. But I don't expect devices to use any SE exclusive features anyway (I can't think of any SE only features they could use, at least), so it should be all good.

7. New features that make sense on LE will get backported whenever possible, as will bugfixes.

 

While this will make the development process a bit more complicated on my end, DD is largely a mature project at this point, so the workload should be manageable (I'd probably see this differently if I expected DD still to evolve and grow dramatically, but I think it's fairly feature complete at this point). The only caveat is my own inexperience with SE, so I'd probably need some help with the new features.

 

Thoughts?

Yes, of course....if you want?!

 

This all discussion can easily become answered:

SSE is for best to be used for sexLab and it´s all 3BBB suporting bodies-simply for sex-action-that´s it. Most people use it for such a gameplay. But those simply can not follow that DD/ZAP can´t become "ported" with all their features - but WHY??? ...

SexLab and other mods which mostly are mentioned to work and have been created into or FOR the LAB of that mod (sexLab), means: animation replacers and specially all the new body-designs with overstyled collision and marco-detailed sex-part(s), simply do not suit to lot of assets coming inside of DD and also of ZAP. In the past ZAP did not even spend one single asset for Bodyslide-was pretty a lightweigted and easy to convert version, that ZAP 6.11...

 

That´s why I absolutly do not go to support all those stuff by trying to follow an unserious way of serving SSE with content, which simply has no suiting technology to offer.

Aside of a no serious smp-physic inside of SSE (yes it is lacking in compare with LE, I´m sorry to say so), SSE is lacking in different other technical aspects, which make us seriouly say, that lot of special mods can simply not become converted: you can convert particulary some stuff-but lot of assets and functions simply don´t work seriously, so...at the end of the day, smp is not even working inside of the race-menu of sse, and their sliders only work with a tremendious delay, which makes race-menu nearly to become a not serious working mod inside of sse. Another port. Maybe SKSE for SSE has not the necessary bandwith compared with LE...

While the whole code-stuff is mostly untouched or more ideal to program by using a professional format under SKSE inside of SSE, lot of creators think that everything is FINE to switch to SSE-but that´s wrong.

SSE will always stay at it´s technical limitations, compared with LE and that is now since some years not a changer and won´t become a changer in future.

SSE is ideal for CONSOLE-gameplay, sexLab-sex-mods and there it mostly has been made for...

Of course CAN we "port", but the whole SSE seems to be such a "PORTISSIMO" and simply it can´t be supported even by suiting tools. Converters also are not error-free and mostly and endless textures of LE now run inside of SSE, which normally is been made for a much more better depth of gamebryo-file-creation.

The LL threads are full with request for porting from or to LE/SSE, specially for the confusion of the existing body-models in any direction....on the one hand it seemes to be cool to have an individual game(pla) but on the other side are comsumers drowning between third-party mods and endless physics-versions up- and down LL and also NEXUS. The users oversee for which version a mod has been created and often want to convert stuff, which really needs a deeper insight of the different techniques of both games, which sadly have the same name: SKYRIM !!!

 

If one is bringing a new framework/old framework for SSE, it is HIGHLY recommended to offer that mod by using ONLY NEMESIS-compatible new animation-behaviors (nothing, what has been made under/by FNIS, to avoid another parallel use !!!. The price is herewith, to drop the creature animations, but on the other hand you get a fully working and game compatible animation-behavior for also BD/SM stuff. COmpatible means solid animations which "rock" onto the original behavior of skyrim. Lot of work but if created, you have it with all the official game features.

 

Modding into SSE means specially to me to begin FOR SSE to create stuff and NOT TRY to port !!!! This is a very, very important difference and it is the only chance to allow NEW and cool stuff for SSE in future. SOme few modders/creators on NEXUS went that HARD way with a few NICE and serious new results for SSE-which can´t by the way become "ported" into OLDRIM. A serious mod, which has been made for SSE can indeed not become converted to LE, same is for LE->SSE.

SKYRIM SSE and SKYRIM LE are DIFFERENT games, comparable like SKYRIM LE with FO3. This is the crux.