Devious Devices Framework Development/Beta

[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.

[Hex Bolt]

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.

[GreatCroco]

39 minutes ago, Rogwar002 said:

nod nod nod

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

[AndrewLRG]

1 hour ago, GreatCroco said:

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.

 

It needs to be done only once when starting a new game.

 

1 hour ago, GreatCroco said:

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.

 

Non-coders can add new devices to .json file as well.

 

1 hour ago, GreatCroco said:

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.

 

DD for SE already runs on SKSE64. Doesn't that increase performance?

[Scrab]

1 hour ago, HexBolt8 said:

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.

This doesnt really work if we go by the basis of "making patches"; Forwarding changes would require these "patches" to be remade constantly every time a new version is released for DD. It lacks some kind of centralization

 

A more realistic approach - based on your suggestion - is to make a git with the current DD sources (papyrus source only) and get yourself some on SE focused mod author that is able to get everything out of SE that there is and knows what theyre doing to not break backwards compatibility. Then task this author to host their own version of DD while Kimy keeps focusing on LE

This approach would allow LE and SE to be developed independently but if there are important changes on either code base that are compatible with both, they could be forwarded or up streamed quite easily; manually comparing scripts isnt feasible for a big project like this (its painful even for small ones)

 

All of this under the condition that this doesnt end at the solution that Kimy goes to SE of course

 

Oh dear and here I am arguing in a topic that I didnt want to be involed in. Tragedy

 

 

Edited June 23, 2023 by Scrab

[Hex Bolt]

10 minutes ago, Scrab said:

This doesnt really work if we go by the basis of "making patches"; Forwarding changes would require these "patches" to be remade constantly every time a new version is released for DD. It lacks some kind of centralization

Yes, those doing the SE enhancement would very likely come up with a mechanism for centralization, such as GitHub that you mentioned.  However, I don't see this a "constantly every time a new version is released for DD" problem.  DD has had slow and careful development cycles.  Kimy will also probably be working on DCL at times.

 

While there is some inconvenience, the SE/AE player base has the numbers to make it work and have the enhancements they desire.  The alternative is dividing the community, cutting off many of the players who have been here the longest and made significant contributions during that time.  I do not expect to win over those who favor that alternative.  I'm just saying that it doesn't have to be that way.  Those who desire SE-specific enhancements can have them if they're willing to put in the effort for the things they've stated that they want so much.  When the choice is inconvenience versus leaving people out, I favor inconvenience.  (In my own mod development, which is for LE, I always consider the implications for my choices on SE/AE players, and I build in ways that include everyone.)

[naaitsab]

20 minutes ago, Scrab said:

This doesnt really work if we go by the basis of "making patches"; Forwarding changes would require these "patches" to be remade constantly every time a new version is released for DD. It lacks some kind of centralization

This. It results in again a SE version based on a LE version with patches made by members. That's not something I would call a good compromise but a full compromise on the SE version.

 

The big problem with the Git solution you proposed is that it can only be used for code files. ESM/ESL files can't be maintained as they are binary files and adding the textures/meshes makes the repo way to big. But on the other hand, like I said before the amount of changes that are made to said textures and meshes are very rare. So it should not be a showstopper. And these could still be managed by the Kimy-Repo so to speak  

 

It will provide an excellent way to contribute and keep the only real future ready solution workable. A LE version and a code wise separate SE version. So the LE folks can enjoy it on their game, and all SE players get a hassle and janky free built on and for SE build not hindered by legacy compatibility. Best of both worlds.

 

25 minutes ago, Scrab said:

Oh dear and here I am arguing in a topic that I didnt want to be involed in. Tragedy

 

Well in a lot of previous discussions around this subject members tend to use unnecessary drama or even name-calling to pressure a discussion to end quickly in the favor of their viewpoint. Probably why you are reluctant to reply. Which is never a good thing as shouting should never triumph over reasoning and conversation. As long as we keep it civilized there is nothing wrong with working something out, that if we do it correctly and not revert to the "deal with it" method can benefit all DD users in their own way. So don't feel intimidated to give your view and possible solution on the matter.