Devious Devices Framework Development/Beta

[HexBolt8]

1 hour ago, Kimy said:

To be honest, I am lacking numbers on how many DD content mods are still developed using the "development on LE, port to SE" approach. I would be interested in more information about this, so assuming that DD content creators are following this thread, please, by all means, post your approach/opinion here!

The main mods that I work on that use Devious Devices are Submissive Lola and Simple Slavery++.   For Submissive Lola, I develop on LE with full compatibility with SE, so although it's built on LE it runs as-is for LE, SE, AE, or VR.  Simple Slavery++ has a soft integration with DD; it has to recognize and handle devious devices if equipped.  I develop on LE, and coordinate with Herowynne, who ports it SE.

 

Advantages are that I can't accidentally use a LE-only script function because (as far as I know) none exist.  No one is left out.  My preferred development tool is TES5Edit.  It's much faster than the CK and has some advantages.  I compile scripts externally.  I mainly use the CK to design rooms and lay out furniture, but I don't do much of that.  It's a personal choice, but that's how I do it.

 

I know that Laura's Bondage Shop is developed on LE and ported to SE.  I mention it because Laura's time is limited, so she might not see this discussion.

 

For what it's worth, I suggest keeping DD development where it is now, on LE.  The general consensus is that porting from LE to SE is easier than going from SE to LE.  As others have noted, there is a large and growing pool of talented SE developers who can volunteer to port to SE.  No one is left out.  However, if DD were developed on SE, the burden of porting to LE would fall on a smaller group, of whom only a few might have the time and expertise to do the work.  

Edited June 22, 2023 by HexBolt8

[GreatCroco]

3 hours ago, HexBolt8 said:

You guys do realize that Kimy is one of members of the community you're proposing to throw overboard, right?  The one who spends countless hours bringing us enhancements to Devious Devices.  For free.  Suggesting that here on her own discussion topic.

Strawman argument that's playing the guilt card. At best you missed what I wrote, at worst you're grossly twisting it. I'm giving you the benefit of the doubt.

 

Again: I never said to IMMEDIATELY switch, that's why I said "with the next big patch"; if that's too close for comfort, shift it back the big patch after that. Furthermore, just because the development shifted to SE/AE, doesn't mean that DD and DCL are not working anymore, you can use them as long as you like, but you're not getting anything new. Which is the spot of LE in general, and -- as Kimy themself has already stated -- SexLab.

I'm also not advocating for dropping SE and going straight for AE, even tough I'm on that version; that would simply be too much, even tough the new MSVC version did give a bit of an additional performance boost.

 

 

1 hour ago, Kimy said:

- Nobody is getting left behind, no matter which Skyrim version they're using.

- LE CK might suck, but it's not that I am not used to its quirks after all these years, SE CK probably has OTHER quirks for me to stumble over, haha!

 

If you define "not getting left behind" by "it just works" (and not the Todd Howard way), then yes. However, if you define it by "the most stable and enjoyable experience", then the SE players are getting left behind, or at least not getting the most out of what could be. It's a similar story for CK64, sure it might have it's own quirky, but from what I gather (I'd have to reinstall it with all the fixes to confirm for myself), it's a smoother development process overall.

 

There's also one huge benefit for SE you missed: ESPFE's/ESL's . With that you can offer small patches, like DD for him and BRRF (must contain less than 2048 records), without them taking up space in the load order, as all of the FE plugins are placed in the FE range of ids

 

EngineFixes, PapyrusTweaksNG ("Speed up native calls", 'nuff said), SL+ and OSL are the main reasons I'm never, ever, going back to LE. They offer FAR more features than LE, with SL and Aroused; OSL being a drop in replacement that is far more fine grained in how it actually calculates stuff, while at the same time being much faster.

Who can say that they are getting almost 60fps with close to 100 NPCs in a single cell (Frostvale Estate), with ENB on LE?

 

1 hour ago, Kimy said:

I can see that traffic in the DD/DCL LE threads is waaaay down and traffic in the SE threads is waaaay up, which seems to support the point that LE is slowly but steadily getting crowded out in favor of SE.

 

On Nexusmods SSE is only 9k uploaded mods behind and is up 500 million downloads up; while being five years younger and with all the dead and outdaed mods for LE. On SE you now can also assume that everyone has all the main DLC because it is bundled with the main game. 

 

 

1 hour ago, naaitsab said:

But to make a suggestion that could fit both "camps". As there are some LE modders present, what would your stance be to officially move to SE, implement all the fixes like SL+ and OAR (at this time but more can come). And let the LE modders keep the LE version up to date by implementing scripts changed and devices that are for both versions. SE only code like SL+ of course should stay on SE and vice-versa.

That was my first idea as well. Papyrus changes could """very easily""" be ported back. But what about the SKSE plugin? As much as Papyrus has improved in speed with SE/AE, it's not going to beat C++. If this can be done, I'm for it by all means.

 

 

  

39 minutes ago, HexBolt8 said:

Advantages are that I can't accidentally use a LE-only script function because (as far as I know) none exist.  No one is left out.  My preferred development tool is TES5Edit.  It's much faster than the CK and has some advantages. 

 

a) LE only functions don't exist because Bethesda has stated that Papyrus is fully forwards compatible.

b) Kimy has already stated that they don't plan on another breaking change in the API. Meaning, if bug fixes are ported back from SE to LE, you can go on as usual

c) CK64 is much faster than CK86

 

  

45 minutes ago, thedarkone1234 said:

One reason why people stick with LE that I haven't seen here for some reason is simply that several of the mods I like to use have ceased to exist.

 

 

I have not found a single mod that either does work out of the box because it's Papyrus only, or hasn't got a superior replacement. I understand that people are reluctant to redo their load order, I really get it. It took me a whole week to do so. But in the end it was worth it. I now got everything I want in my game, which is not something I could ever do with LE, first and foremost because of the limited number of plugins.

 

 

 

Edited June 22, 2023 by GreatCroco

[ponzipyramid]

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.

 

DeviousDevices.dll

Source Code

Edited June 22, 2023 by ponzipyramid

[AndrewLRG]

So, could someone give an example of how SE improves DD? What functions does SKSE64 or SE plugins have that will make DD better or fix its issues?

[Frayed]

2 hours ago, Kimy said:

To be honest, I am lacking numbers on how many DD content mods are still developed using the "development on LE, port to SE" approach. I would be interested in more information about this, so assuming that DD content creators are following this thread, please, by all means, post your approach/opinion here!

 

My little mod The Trappings of Fate isn't a particularly large fish compared to some others and it hasn't existed even a quarter as long, but since you asked for perspectives, here's my two cents.

 

I don't have the time nor the willpower to actively support all Skyrim versions. I only have SE and the SE CK installed. I have put barely any effort at all into making Trappings work on LE, yet from what people on the support thread tell me, it works fine. The only thing I do is try to keep the mod dependencies minimal, and rely on the frameworks for the heavy lifting as much as possible. Frankly, that Trappings works on LE is probably almost entirely due to DD keeping compatibility with both. I don't know how many of my users are still on LE, but those that are are probably (or should be) thankful for you wonderful folks supporting both versions.

Edited June 22, 2023 by Frayed

[krzp]

38 minutes ago, ponzipyramid said:

Just wrote a quick version of the plugin using CommonLibSSE-NG.

Spoiler

checking plugin ...\Data\SKSE\Plugins\\DeviousDevices.dll
plugin ...\Data\SKSE\Plugins\\DeviousDevices.dll (00000001 DeviousDevices 00000001) loaded correctly (handle 18)

My SE loaded it without a hitch, tried unequipping and equipping some stuff, haven't noticed the <native> stacks too, so it's working good on my end.

Although it's the 1.6 users reports you're probably more interested in ?

 

I did load it on an existing save, though.

[Herowynne]

4 hours ago, HexBolt8 said:

Simple Slavery++ has a soft integration with DD; it has to recognize and handle devious devices if equipped.  I develop on LE, and coordinate with Herowynne, who ports it SE.

 

@Inte uses a similar development model for Skyrim Utility Mod (SUM), Devious Devices Equip (DDE), and Prison Overhaul Patched (POP).

 

Inte develops on LE, and I provide the ports to SE.

[GreatCroco]

4 hours ago, AndrewLRG said:

So, could someone give an example of how SE improves DD? What functions does SKSE64 or SE plugins have that will make DD better or fix its issues?

The reason to switch is not primarily SKSE64, it's simply SSE. Now that the game is 64bit you get some decent performance boosts, which help in situations where Papyrus is heavily stressed. Back in LE I had to tweak the Papyrus VM numbers, increasing them by 0.2ms or so. This resulted in better Script performance, at the cost of framerate (as all changes in the VM setting do). I never had to do this with SSE. Sure PapyrusTweaksNG helps, as there's and (experimental) setting that moves many function calls to the main thread, which in turn makes it possible to remove much of the synchronitsation mutexes that heavily slow the game down. Yes, that setting also costs FPS, but I found that this is only noticable when 30+ NPCs are on the screen at the same time.

 

Another benefit of SSE is the lack of most legacy mods. While this sounds bad at first, it's actually a boon. Back when Skyrim came out many modders didn't have a flying fuck of experience with modding, which for example resulted in the infamous overuse of the cloaking script, which tanked FPS even on the most high end machines. Today (or at least back when SSE was released), people know better (it's been a few years) and the quality of most mods has gone up dramatically. This comes from understanding the tooling better, improved tooling in general (CK64 with fixes for example), people actually caring about ITMs records (and therefore cleaning their mods prior to release), and generally better documentation. Think what you will of Arthmoor, but that dude knows what he's talking about and his writeups have been a massive boon the community.

Yes, people will need to search for quite a few mod replacements, I'm not denying that, but as I have already written: If a mod doesn't rely on SKSE (i.e. any texture and papyrus only mods), then it will work in SSE. There might be some minor changes needed for textures and animations, but that process is largely automated already and good tutorials exist out there.

 

 

SKSE was always a great piece of software and the people writing it definetly know their stuff, so the direct improvements on that front should not be expected, and in fact the patch notes post 1.7.3. are just various bug fixes, with the biggest addition being the plugin manager, but I don't exactly know what that brings to the table.

However, many newer mods finally tackle some stuff that was never really done in LE. EngineFixes, for example adds improved loggin (great for mod authors), adds the ability to change the time it takes for an hour to pass during wait/sleep, fixes the downward aiming bug, decuples vertical look sensitivity from the framerate (seriously Bugthesda?), and most importantly allows you to change the memory allocator to TBBmalloc, which gives quite a decent performance increase

PapyrusTweaksNG does the same, but for Papyrus itself, improved logging, allowing the Papryus VM to temporarily ignore memory limits (decreasing script lag) and other neat stuff, like Papyrus not allocating negative amounts of memory... Both of these mods have no real equivalent in LE, which is a bummer. 
The third mod in that category is powerofthree's Tweaks, which for example allows map markers to be set near fast travel points, even when fast travel is disabled or decoupling random number generation from the framerate (why Bethesda? why?). There's also Vanilla Script (micro)Optimizations, but that just does what is say on the tin and Scrambled Bugs, which is yet another bugfix mod but this time for more gameplay related stuff like player not getting experience when using staffs or players moving slower on slopes.

 

 

 

 

The biggest thing that I could think of benefitting DD is Base Object Swapper, which allows modders to use config files to replace objects (e.g. models like houses) with others without worrying about compatibility, or make static objects interactable. This could be interesting for DD: Contraptions.

The other one would be FormList Manipulator, which allows forms to be added to form lists on startup, or via ModEvents during the game, again driven by config files (which can include filters!). This could be interesting when DD needs to add new items. Directly benefitting Kimy would probably be Recursion Monitor, which allows them to find scripts that are haning in infinite recursion, since Bethesda in their unending wisdoms decided to NOT have stack overflows in Papyrus.

 

Actually now that I think of it... FormList Manipuator and BaseObject Swapper are huge.

Edited June 23, 2023 by GreatCroco

[AndrewLRG]

30 minutes ago, GreatCroco said:

The biggest thing that I could think of benefitting DD is Base Object Swapper, which allows modders to use config files to replace objects (e.g. models like houses) with others without worrying about compatibility, or make static objects interactable. This could be interesting for DD: Contraptions.

The other one would be FormList Manipulator, which allows forms to be added to form lists on startup, or via ModEvents during the game, again driven by config files (which can include filters!). This could be interesting when DD needs to add new items. Directly benefitting Kimy would probably be Recursion Monitor, which allows them to find scripts that are haning in infinite recursion, since Bethesda in their unending wisdoms decided to NOT have stack overflows in Papyrus.

 

Actually now that I think of it... FormList Manipuator and BaseObject Swapper are huge.

 

Honestly speaking, I don't see how that would benefit DD. Why would DD need to add forms to formlists mid-game? Whenever a new version of DD is released any new devices are added to relevant formlists in .esp file. And swapping Contraptions can be done with the use of Papyrus. Contraptions already have a script attached to them. We can add an OnLoad() or OnCellAttach() event and shape-shift them when specified conditions are met. That is, if Kimy wants shape shifting Contraptions at all. I don't think that Base Object Swapper and ForlList Manipulator are absolutely necessary for DD development.

[zarantha]

7 hours ago, thedarkone1234 said:

So I have the LE version of the mod (often, the only version of the mod), because I downloaded it when it existed. If I switch to SE I would have to completely give up on it, and I don't want to. That's all there is to it.

 

Unless those defunct mods have DLLs, there is no reason why you couldn't self convert those mods to SE. That is after all, exactly how SE modding started in the first place. Most of it was conversions at the beginning instead of new mods. 

 

 

6 hours ago, AndrewLRG said:

So, could someone give an example of how SE improves DD? What functions does SKSE64 or SE plugins have that will make DD better or fix its issues?

 

One hard example that I'm aware of is DCL actually.

 

In LE, to load the whip and chain inn, I see that tweaking memory settings, having memory fixes and such that i've long forgotten about, are often recommended or needed to load the cell without crashing.

 

In SE, the cell loads (slowly and not always well) without crashing. Yes, there are also memory and papyrus tweaks for SE, but they're largely to make things faster not make it less crash happy. I have never seen a report on the SE side for that particular cell causing a CTD in SE, it's something I've only seen in LE.

 

Improvements along those lines are what SE brings to the table. Better stability and performance with less effort even in a heavily modded and script heavy list. I'm not saying LE can't be as stable, just that it takes more effort to make it so.

[krzp]

8 hours ago, AndrewLRG said:

So, could someone give an example of how SE improves DD? What functions does SKSE64 or SE plugins have that will make DD better or fix its issues?

Aside from the things I've already talked about on the last page, this:

All of this.

DCL's defeat feature has been literally unplayable without it.

[kurotatsu]

12 hours ago, Kimy said:

To be honest, I am lacking numbers on how many DD content mods are still developed using the "development on LE, port to SE" approach. I would be interested in more information about this, so assuming that DD content creators are following this thread, please, by all means, post your approach/opinion here!

 

I'm LE user and developing extension to Unforgiving Devices framework, which is based on DD. https://www.loverslab.com/topic/208622-unforgiving-skyrim-lese/

It's LE/SE-compatible out of the box, leaving no one behind.

 

Please continue developing DD on LE. As was said many times before LE to SE adaptation is easy, reverse process has many quirks, caveats and in some places impossible (anims, for example).

[Scrab]

11 hours ago, AndrewLRG said:

So, could someone give an example of how SE improves DD? What functions does SKSE64 or SE plugins have that will make DD better or fix its issues?

Highly depends on the author; swapping in and on its own gives you little immediate benefit in terms of the mod itself, while you do have more frameworks, most of them wouldnt really benefit DD; Hence the question about if you should or shouldnt swap for the sake of some mod youre developing is a rather subjective one

 

That being said, in the long run you could benefit from certain SE exclusive mods more easily, but thats just a small one

The things that I would argue are more interesting are:

 

If you are comfortable with C++ you can

• improve NPC support by having each NPC be checked for devices independent of other NPC or some polling algorithm, which would get rid of a decent chunk of overhead DDs current NPC support creates
• Overhaul the device hider by checking each NPC/PC in real time and hide/show devices as necessary in greater detail as its currently possible
• Potentially move some of the back end into C++ to drastically speed up some of the calculations. While Kimy did an excellent job in regards to performance with DD5, theres still a lot of room for improvement. In particular the frame still likes to trip up when equipping too many items at once

If you then now AS2/Flash on top of that (and know some artist for assets) you can

• overhaul the locking interface to use newly created menus over the default Messageboxes
• Something that I admittedly havent tried yet but would like to see if its possible is adding a new column into the SkyUI Inventory Menu to express the current lock status of a device. I dont know if this is possible, but Parapets released some promising mod recently that may or may not go into a similar direction as this

Also, if you know assembly you can

• Intercept the equip and unequip functions to add another custom layer to it for treating DD items specifically. This would allow you to get rid of pretty much all overhead created by mods unequipping DD items "on accident" and combined with the above points create an incredibly smooth unequipment function where trying to unequip an item opens a custom menu (through Cpp) which then handles the actual unequipment of the item
• Intercept Papyrus Remove Item calls; similar to the above you could get rid of most overhead created by the attempt to not lose "locked" DD items

 

Doing all these things would remove pretty much all overhead created by DD, causing the strain it puts on the Papyrus VM to be negligible as opposed to now, where it requires multiple pollings for all sorts of things

 

Edited June 23, 2023 by Scrab

[Mister X]

13 hours ago, Kimy said:

To be honest, I am lacking numbers on how many DD content mods are still developed using the "development on LE, port to SE" approach. I would be interested in more information about this, so assuming that DD content creators are following this thread, please, by all means, post your approach/opinion here!

 

To throw my hat into the ring on that, even though I'm not that big of a mod author: I started developing on LE and porting the results to SE. In the meantime, I got a new PC and had to reinstall the whole stuff, so I decided to leave LE behind. All I have to say is, that it was and is the best decision in my eyes, regarding Skyrim. For both, playing and mod creation.

 

LE is so old, you have to do all kinds of workarounds to get only an semi-stable game. It has no native support for more than 4GB RAM, no support for more than ~4 CPU cores and no support for light plugins.

And yes, the SE CK got me sometimes with some crashes and weird quirks, but so did the old CK, too. And in difference to the old one, the SE CK got several patches on code level (not just inis), after which for me it never crashed even once anymore, something that I never achieved with the old CK. Another advantage is, you don't have to think about an ancient engine anymore. No more 1s waits to give the game a chance to keep up with your scripts and even some SE exclusive Papyrus functions where you don't need a weird workaround anymore.

 

Most of the time, when I see arguments pro LE those are "some mods aren't available for SE/AE", "I don't like the ENBs", "I have a more stable game with LE".

So here my arguments: most mods that "aren't available for SE" are a myth, as they either can be directly ported with no effort whatsoever or they are in a way outdated, that they only don't exist as there are superior alternatives for SE. As for the time I'm writing, the only thing that isn't available for the latest SE version (meaning AE/ v1.6.x) is .NET Script Framework and the plugins that depend on it. Still, the only one that doesn't really have an alternative is the "No Grass in Objects" plugin, which you probably only need once every umptillion years.

The next thing, if you don't like the visual style, the texture mods or the ENBs, then search for other ENBs, tweak them yourselves or port your old texture mods. I mean, textures are one of the easiest things to port! And for ENB, there are many for Oldrim that simulate some elements that SE got natively, so where's the real difference there?

And if you really have a "more stable game", how much effort did you have to put into that? SKSE with its memory tweak, ENB memory fix, much more other stuff, where all of it is unnecessary if one just would use a game that natively supports x64 architecture. It's like the comparison of stilt houses against Venice. Yes, both have their issues and a similar base, still it's a difference of night and day!

 

I personally came to the conclusion that some players simply are to afraid or too idle to switch over. They've got their base set up, and only rearrange some mods on top, and that's fine. I even understand that, I was at the same position. Still, using SE as the fundament to build a new ground really offers a whole new experience of stability and speed aswell as totally new options, like OAR. Man, you even can install Display Tweaks and run way over 60 FPS, I don't know of any Oldrim mod that offered that.

 

Oh, and regarding the point with the player base, here's the chart for the last two years:

Spoiler

As you can see, most of the times you have ten times the amount of players in SE compared to LE

 

 

Edited June 23, 2023 by Mister X
added graph

[krzp]

I'm kinda getting a vibe that two sides are not talking about the same point - what most of us advocating for better SE support are asking, I'd wager, is not the complete stop of the LE development, but a departure from the idea of "if it can't work on LE version, it shouldn't be in SE version" ?

[Mister X]

1 hour ago, krzp said:

I'm kinda getting a vibe that two sides are not talking about the same point - what most of us advocating for better SE support are asking, I'd wager, is not the complete stop of the LE development, but a departure from the idea of "if it can't work on LE version, it shouldn't be in SE version" ?

 

And here's a wrong conclusion: when developing with LE as base, you tie yourself to that fact. Or else you'll have two totally different versions of DD, as example. It's much simpler to just put out a version, maybe patch the necessities and then port it instead of putting out a version, patch the necessities then optimize it for another game instead of porting.

 

Or in other words: there's a reason why professional game developers (used to) put huge effort into optimization for different platforms. It's another level, but the same basic reason. Simply patching the necessities and then porting, results in a Starfield that'll only run 30FPS on a RTX 4090, so to speak.

 

I'd love to see LE vanish as a whole and leave that clusterfuck behind, as everything else restraints development in one way or the other. 

[GreatCroco]

9 hours ago, AndrewLRG said:

Honestly speaking, I don't see how that would benefit DD. Why would DD need to add forms to formlists mid-game? Whenever a new version of DD is released any new devices are added to relevant formlists in .esp file.

Adding items to text based configuration files instead of binary formats is always a benefit. Take it from somebody who has decades of programming experience: Binary sucks to work with.

If it was just "add every item to the form list and be done with", I'd agree with you; there'd be no point in using FormList Manipulator. However, FormList Manipulator gives you much mor flexibility. You now could make a FormList for every item category, like Leather, Steel, Golden, etc. collect them into Groups, filter them by available plugins, etc. That on it's own is already powerful, but here's the next big benefit: compatibility with other mod authors

 

Imagine you're a mod author and want to offer new items for DCL. Up until now you have to make the items, give them to Kimy and wait for a new version of DCL to release. With FormList Manipulator, DCL would offer a "ValidItems" Form list from which DCL pulls all items that can be equipped by traps. You as a mod author would then write your own mod (totally separate from DCL), which uses FormList Manipulator to add your items to the "ValidItems" list and DCL would pick them up no problems. You don't need to touch DCL, nor wait for Kimy. 

This naturally also includes DD and DCL. Currently DD has quite a few items that cannot be dropped by DCL because DCL was not yet updated. With FormList Manipulator this is a thing of the past, because adding the new items is just adding/changing a new config file, maybe not even that, but that'd depend on the structure of the equipping system.

 

9 hours ago, AndrewLRG said:

 

And swapping Contraptions can be done with the use of Papyrus. Contraptions already have a script attached to them. We can add an OnLoad() or OnCellAttach() event and shape-shift them when specified conditions are met.

Anything that reduces the number of Papyrus calls is a good thing. Papyrus is slow and if you can move it to C++, you'll get massive performance boosts. BaseObject Swapper also allows you to randomize the swapping.

 

 

9 hours ago, AndrewLRG said:

I don't think that Base Object Swapper and ForlList Manipulator are absolutely necessary for DD development.

Necessary? No, of course they are not necessary. But that was never my point. Those two objects allow for either more features, easier development or better compatibility with other mods.

 

 

 

 

 

 

4 hours ago, Scrab said:

If you then now AS2/Flash on top of that (and know some artist for assets) you can

Wouldn't that be fun if we got the lockpick interface when trying to pick the lock on a device?

 

4 hours ago, Scrab said:

Something that I admittedly havent tried yet but would like to see if its possible is adding a new column into the SkyUI Inventory Menu to express the current lock status of a device. I dont know if this is possible, but Parapets released some promising mod recently that may or may not go into a similar direction as this

Do you mean Inventory Interface Information Injector?

 

 

 

 

 

4 hours ago, Mister X said:

Man, you even can install Display Tweaks and run way over 60 FPS, I don't know of any Oldrim mod that offered that.

You could do that with some hacks and leveraging ENB with framerate caps. The problem was (and still is) that in Skyrim the Physics engine is tied to the framerate and goes totally bazonka when you exceed 60 just a smidge. IIRC SSE has this problem solved by decoupling the Physics from the framerate and then locking the physics at 60 UPS. This results in the Physics lagging behind every so often, but usually this isn't really noticeable.

 

3 hours ago, Mister X said:

Or in other words: there's a reason why professional game developers (used to) put huge effort into optimization for different platforms.

They still do, just somewhere else. The amount of work that goes into Engine optimizations is just mind boggling. Yes, for many teams this work has essentially vanished as the most crucial stuff is handled by engine developers like EPIC, but even then you have to optimize for your particular game anyway. The Satisfactory dev diaries give quite a bit of additional insight there.

 

3 hours ago, Mister X said:

I'd love to see LE vanish as a whole and leave that clusterfuck behind, as everything else restraints development in one way or the other. 

Lol, Just wait until 2038 when 32 bit datetime overflows or earlier when Intel kills x86, which seems to be in the works (Intels Whitepaper for reference). Additional benefit: FINALLY no more 8086 16-bit real mode in my CPU!

 

 

 

 

 

 

I think I have to stress this again:

Nobody (and I think especially Kimy), wants to leave LE behind just because SSE is newer. However, SSE offers so many more mature and stable options for development that it's getting harder and harder to justify an LE centric (i.e. developing on LE and porting to SSE) development approach.

 

Edited June 23, 2023 by GreatCroco

[AndrewLRG]

7 minutes ago, GreatCroco said:

Imagine you're a mod author and want to offer new items for DCL. Up until now you have to make the items, give them to Kimy and wait for a new version of DCL to release. With FormList Manipulator, DCL would offer a "ValidItems" Form list from which DCL pulls all items that can be equipped by traps. You as a mod author would then write your own mod (totally separate from DCL), which uses FormList Manipulator to add your items to the "ValidItems" list and DCL would pick them up no problems. You don't need to touch DCL, nor wait for Kimy. 

This naturally also includes DD and DCL. Currently DD has quite a few items that cannot be dropped by DCL because DCL was not yet updated. With FormList Manipulator this is a thing of the past, because adding the new items is just adding/changing a new config file, maybe not even that, but that'd depend on the structure of the equipping system.

 

But doesn't StorageUtil from PapyrusUtils already does that? Any mod can add, remove and retrieve forms from StorageUtil.FormList. We can use Jcontainer or JsonUtil (not sure about the last one) to retrieve base objects from any .esp and spread them to various StorageUtil.FormLists via Papyrus. That's how I would edit DCL.

[naaitsab]

8 hours ago, krzp said:

I'm kinda getting a vibe that two sides are not talking about the same point - what most of us advocating for better SE support are asking, I'd wager, is not the complete stop of the LE development, but a departure from the idea of "if it can't work on LE version, it shouldn't be in SE version" ?

That's the idea I also proposed. The only argument I can find that is brought on the table by the 'LE camp' is that LE should be on LE for the sake of compatibility. Whilst that is an important one, but on it's own that's getting less and less of an importance. At what point do we decide it's no longer viable to keep the focus on LE to support a very small number of players? And yes a LE -> SE conversion on most mods is easy. But at the moment a number of nice things are not part of DD because it's made on LE and those functions only work on SE. Thus hindering progress for the majority of the players, that should be a key decider to implement these new things into DD and thus splitting the development going forward. At this stage I think there are enough arguments brought to the table to outline that the time is right to make this swap.

 

The discussion therefore imho should not be if we swap but how we are going to do this swap. Like updating the LE build with LE/general code things only. It's not like every month 750 lines of code are submitted and we have a nightly build every day. So we should be realistic, it's perfectly doable if you copy-paste the changed code parts. So I would like to suggest we discuss how this can be done in a proper manner. Not if it should be on LE or SE and ditch the other. As that on it's own is a endless discussion at which are can never agree on. As personal preference is put above facts, which is a human thing to do. This method will probably result in the LE project getting abandoned after a while but that's part of the already long ongoing process. So I don't see that as a bad thing but just natural evolution of a EOL product.

 

 

And like the situation @Mister X sometimes it's just a matter of trying it and swapping around. Besides some minor annoyances I haven't found any showstoppers on SE. On the contrary it's very painless to setup and does not require a tinkerfest to get it working somewhat stable or look good anno 2023. But that's more of a general remark for LE players that still stick to LE without very specific reasons not to. 

Edited June 23, 2023 by naaitsab

[krzp]

6 hours ago, Mister X said:

And here's a wrong conclusion: when developing with LE as base, you tie yourself to that fact. Or else you'll have two totally different versions of DD, as example. It's much simpler to just put out a version, maybe patch the necessities and then port it instead of putting out a version, patch the necessities then optimize it for another game instead of porting.

Maybe I've worded myself poorly, but I was trying to make a point for SE version to finally start being more independent and stop being a patched LE? 

 

And yeah, it would initially result in two versions, one of them gradually getting better than the other. But instead of simply pressuring people to switch, which will certainly create a ton of unnecessary drama (lol, this whole discussion is teetering on the verge of that) - support them whenever possible, and let the regret for the lack of better features that could be possible with the newer versions pressure them instead ? Evolution over revolution, that sort of thing.

 

3 hours ago, GreatCroco said:

Wouldn't that be fun if we got the lockpick interface when trying to pick the lock on a device?

Unforgiving Devices already has that, lots of fun.

[krzp]

57 minutes ago, naaitsab said:

At what point do we decide it's no longer viable to keep the focus on LE to support a very small number of players?

There is a number of mod authors among that minority, so just cutting them off entirely outright might be detrimental - I understand that frameworks are being kept alive by the new mods that make use of it after all.

 

But, and that's just my opinion, I do believe that the over-reliance on the use of the legacy software that's incompatible with the modern stuff harshly drives down the potential user base, which in turn, makes less people want to make mods for it, which further drives down the user base, etc etc, creating a death spiral (there's a perfect illustration of that with what happened to the other framework). It would be immensely sad to watch DD fade into obscurity just because at some point the overdue evolution was postponed indefinitely because that evolution would make users of the LE version feel left out.

 

That's my motivation for speaking out on this topic, I don't want to see that happen.

Otherwise I couldn't care less what version people would like to stick to, it's their game after all. ?

Edited June 23, 2023 by krzp

[GreatCroco]

4 hours ago, AndrewLRG said:

 

But doesn't StorageUtil from PapyrusUtils already does that? Any mod can add, remove and retrieve forms from StorageUtil.FormList. We can use Jcontainer or JsonUtil (not sure about the last one) to retrieve base objects from any .esp and spread them to various StorageUtil.FormLists via Papyrus. That's how I would edit DCL.

FormLists are multiple magnitude faster than what JsonUtils can offer. It's not even close. If memory serves correct, switching to FormLists was one of the big performance boosts that DD v5 brought to the table. While PapyrusUtils offers the ability to add stuff to form lists, you still need to go through Papyrus before it then gets handed to C++. This takes away cycles for stuff that could be used elsewhere. With FormList Manipulator you configure it once in a file and then offloaded to C++ immediately. No Papyrus coding whatsoever necessary, improving performance and allowing non-coders to add stuff without needing to wait for Kimy. The only downside is that you can't remove items, but that was never the mod's intention.

 

Everything you describe can be done with existing techniques. But again, that's not the point. Newer techniques and mods offer a more streamlined development experience, better performance, more stability, or all of the above.

 

 

/edit:

  

1 hour ago, krzp said:

Maybe I've worded myself poorly, but I was trying to make a point for SE version to finally start being more independent and stop being a patched LE? 

That's not an option. DD and DCL are a on man/woman show and splitting Kimy's time between the two is not going to end well. That route would probably be the worst of all the possibilities we have ion front of us. It's either and LE or SE centric development and then porting necessary changes to the other version.

Edited June 23, 2023 by GreatCroco

[Rogwar002]

21 hours ago, thedarkone1234 said:

 If I switch to SE I would have to completely give up on it, and I don't want to.

nod nod nod

[naaitsab]

11 minutes ago, krzp said:

There is a number of mod authors among that minority, so just cutting them off entirely outright might be detrimental - I understand that frameworks are being kept alive by the new mods that make use of it after all.

 

But, and that's just my opinion, I do believe that the over-reliance on the use of the legacy software that's incompatible with the modern stuff harshly drives down the potential user base, which in turn, makes less people want to make mods for it, which further drives down the user base, etc etc, creating a death spiral (there's a perfect illustration of that with what happened to the other framework). It would be immensely sad to watch DD fade into obscurity just because at some point the overdue evolution was postponed indefinitely because that evolution would make users of the LE version feel left out.

 

That's my motivation for speaking out on this topic, I don't want to see that happen.

Otherwise I couldn't care less what version people would like to stick to, it's their game after all. ?

I don't have any facts to back it up but I get the strong feeling that the modding popularity of Skyrim in general here on LL is down quite severely from 1.5/2 years ago. One of the main fears I have is that if DD continues to be on the path of a "patched LE mod" for SE that does not implement any of the very popular SE frameworks like OAR natively and support SE script/engine optimizations mods it will fade into obscurity, because the main player base and modders will lose intrest in it. Not everyone likes janky animation swaps or SL issues in their game or want to shift though countless forum pages to install community patches. The majority of the players just want to play a sexy game. Not make it a hobby/masochists-job to get working.

[HexBolt8]

23 minutes ago, krzp said:

There is a number of mod authors among that minority, so just cutting them off entirely outright might be detrimental - I understand that frameworks are being kept alive by the new mods that make use of it after all.

Thank you for this.  It's gratifying to see the discussion progress beyond cutting off part of our community, which I believe is unhealthy, to considering ways to best support all players and mod authors who depend on an important framework like Devious Devices.

 

It's Kimy's decision, of course, but if she continues to develop on LE, our LE members will be assured of continuing new features and fixes, while the SE version could be free to add enhancements that would benefit our SE/AE members.  Ease of porting favors LE to SE, while the large and growing number of technically savvy SE players ensures ample resources to enhance the SE version.  No one is left out.  No one is cast in the role of "holding hostage" others.  By extending an LE-developed core, SE/AE players can have enhancements that they'd like, and I don't think any LE players will begrudge them that in a world where both versions continue to advance with common core features.

 

In such a win-win situation, LE players shouldn't get upset that SE/AE players will enjoy some cool improvements not available to them, nor should SE/AE players be upset that effort is going into the core LE version and keeping our community whole.  An added benefit for the SE/AE player base is that LE-developed mods can continue to be developed on the same up-to-date shared core framework, so those mods would be available to SE/AE players free of compatibility issues.  We're better together.