Devious Devices Framework Development/Beta

[Scrab]

20 minutes ago, HexBolt8 said:

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

The issue is that "just make decentralized patches and hope they centralize" is essentially what you got right now and it obviously isnt working out very well otherwise this whole discussion wouldnt exist

People wont see these "patches" if all they see is "Thats DD 5.2 SE port, thats the Im gonna use, and thats all I gonna see until I run into issues, and start hunting random patches" when to make this "best of both worlds approach" should ideally go like "Thats the official DD version for SE and thats all I need. There are no essential patches beyond that"

 

I certainly disagree with some kind of hard cut, but having a minimally maintained SE port creating these kind of discussions is most certainly not ideal either, and indicates a problem. Telling people "to make patches on their own accord", ie "leaving everything as is" is certainly just the most convenient way out for someone that doesnt care about SE and now consider that a lot of people here look exactly the same at LE

 

Thats why Im saying having independently from LE maintained, official version of DD would be this "best of both worlds", because then you can give LE users what they want (Kimy) while having the SE users get all the fancy SE exclusive things (dlls and performance). The term "official" is really important here

However, that again forces Kimy to make the sacrifice, by giving someone else the responsibility of maintaining an official SE port (partially) independent of the LE version. If you really want to resolve this issue, then someone has to be willing to pay something. May it be losing preference in development, a decentralized patch hunting or losing absolute control over the SE port

 

 

 

Edited June 23, 2023 by Scrab

[GreatCroco]

1 hour ago, AndrewLRG said:

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

Yes and no. With the additional headroom from SSE itself, performance, but more importantly, stability have already increased. But I'll say this again: By itself SKSE64 gives you almost nothing compared to LE and if it was just SKSE64, then the switch would be absolutely pointless. However, as others and I have already stated: It's everything around SSE (not SKSE) that makes life much easier. SSE has more bugfix mods, more performance improvement mods, and on average a higher quality of mods in general.

Nobody wants to switch "just because" and leave LE behind. But the fact is: For all the flaws (it's a Bethesda game after all), SSE/AE is the superior game by far. Sticking to LE means sticking to a buggier game, that performs worse, has less features, gets no updates anymore, crashes more often and requires much more user interaction for it to get even close to what SSE offers almost out of the box.

 

Just take NPC mods as yet another example. I have replaced almost every NPC in the game, meaning I sometimes have six mods that change a more popular NPC. In LE I have to go into TESVEdit, find the NPC in question (you better know the id, because searching by name is pain), and then resolve conflicts by moving the desired changes into a new plugin one by one, hoping you didn't miss some stuff or else you get black fac

es. With SSE you have the Face Discoloration Fix SKSE plugin, eliminating black faces entirely but more importantly, you have EasyNPC. With that tool you search for the NPC by name, select from which mod you want the appearance, and fix the errors that are automatically presented by the tool and then click on "build" which copies over all the required data and generates the proper ESP so you can even free up your load order. A

smoother, less error prone experience that makes it much easier for the end-user.

 

2 hours ago, HexBolt8 said:

while the SE version could be free to add enhancements that would benefit our SE/AE members.

Who is going to implement these changes? Kimy? That would mean even more work for them. If you mean other modders: Who is going to take their time to rewrite parts of the internal code, sync with Kimy for every change? Not to mention that most people would just dump the Bug reports on Kimy because either they don't care or don't know about the development structure. Even in the best case it's more work for Kimy because they now have to categorize the reports into LE and SE stuff.

 

Yeah, not going to happen.

 

 

2 hours ago, HexBolt8 said:

No one is cast in the role of "holding hostage" others. 

But that's precisely the thing happening; LE is holding SE hostage. OAR is not going to be ported back to LE, the authors have already stated that way. So players have to stick to the vastly inferior DAR. None of powerofthree's (essential) bugfix mods are going to be ported back (they didn't state it directly, but seeing as their LE mods have not been updated in three years, tells the entire story). The engine fixes don't exist for LE.

The author of DisplayModel3, the mod that got me to switch from LE to SE, won't port DM3 back to LE because of performance and stability reasons.

 

There are some things that are impossible in SE without breaking LE compatibility. So unless you advocate for two divergent branches of the mod, one for LE and one for SE/AE, then your argument is just false.

 

2 hours ago, HexBolt8 said:

Ease of porting favors LE to SE

If you only look at porting in isolation your point is true. But that's not what's happening in the grand scheme. There are more and more mods out there that do stuff different (for all the reason I have stated already) or require SE only mods and therefore make patches for DD necessary. SL+ is such a mod for example, where I now have to decide: Do I drop the massive perf boost for SexLab, or do I drop DD? Currently the hand points to DD unless we're getting (yet another) DD patch.

 

 

  

16 minutes ago, naaitsab said:

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.

Not to spoil your party: What if an SE mod does things differently than LE? OAR is probably (yet again) a good example. It now uses a different folder structure than DAR, which are incompatible and need converting.

It's getting even worse: By using more modern mods you can cut out parts of the internal DD code to improve performance. So every time DD gets updated you'd have to diff the whole thing and only apply the changes that are relevant to you.

All of this will result in the two forks speeding apart very fast. Is that what's truly best for the mod?

 

Any change to the plugin files is the next big problem. Binary files can only be diffed in very rare circumstances and currently there exist no way to do this for Skyrim plugins. So any change to plugins would mean double the work because you can't simply overwrite the SE version with the LE version and vice versa. That means, manually keeping a minute log of every change to every plugin so they can be incorporated by the other party for the second time. Much more work for everyone involved (yet again), for what gain?

 

  

25 minutes ago, Scrab said:

I certainly disagree with some kind of hard cut, but having a minimally maintained SE port creating these kind of discussions is most certainly not ideal either

Probably the best way going forward would be similar to what CoffeeStain did with Satisfactory: Port your whole development setup from LE to SE and fix the bugs that are resulting from that, no new models, no new quest, no new features. That's the next big(-ish) patch and we're all months older.

Edited June 23, 2023 by GreatCroco

[krzp]

Speaking of SSE exclusive mods for which can directly benefit DD if it starts to utilize their potential:

Animation motion revolution

 

The animations are different between LE and SE, iirc, so won't affect LE users at all, but if SE starts getting more love instead of being an port, this perhaps might come in handy?

Edited June 23, 2023 by krzp

[krzp]

19 minutes ago, GreatCroco said:

If you only look at porting in isolation your point is true.

Speaking of "Mods being made on LE are easy to port to SE", I've got a casualty of that approach, Prison Overhauled - due to this mod's incompatibility with Papyrus Tweaks, I had to drop it from my load order with a heavy heart. I really liked that mod, and still haven't found a good replacement for it - but I can't play without Papyrus Tweaks, it's pure torture once you've tried it, there's no going back.

 

So it's not always that easy, apparently.

[GreatCroco]

PapyrusTweaksNG is out of the question. If a mod is incompatible with it, it gets the boot, no matter what. If tomorrow Sexlab would be incompatible, I'd remove it and every dependent mod in a heartbeat.

 

20 minutes ago, krzp said:

Animation motion revolution

Oh yeah, true root motion is always a great thing. But I don't see the benefit for DD directly, but certainly for SexLab itself..

[naaitsab]

52 minutes ago, GreatCroco said:

Not to spoil your party: What if an SE mod does things differently than LE? OAR is probably (yet again) a good example. It now uses a different folder structure than DAR, which are incompatible and need converting.

It's getting even worse: By using more modern mods you can cut out parts of the internal DD code to improve performance. So every time DD gets updated you'd have to diff the whole thing and only apply the changes that are relevant to you.

All of this will result in the two forks speeding apart very fast. Is that what's truly best for the mod?

 

Hence one of the proposed solutions to keep SE in a limbo by continue using 3rd party patches is not something I would call a solution. When a SE version would adopt OAR it can be suited to that framework and make use of it fully. Now you have to search the thread for a patch and hope it still works. And that patch might conflict with another patches. So it requires another patch to keep the patches compatible. In short, a terrible experience.

 

I think it would help a great deal if there would be a true SE version that LE users can try. The tweaks/mods revolving the performance and animations of the game itself or SL mentioned in the discussion are really amazing. I don't think there is much more evidence required to justify it's true, uncaged place here. 

Edited June 23, 2023 by naaitsab

[Hex Bolt]

1 hour ago, Scrab said:

Thats why Im saying having independently from LE maintained, official version of DD would be this "best of both worlds", because then you can give LE users what they want (Kimy) while having the SE users get all the fancy SE exclusive things (dlls and performance). The term "official" is really important here

I think we're in full agreement.   Of course the official SE version would be the "patched" (enchanced) version.  In that situation, SE/AE players would have one source, one current version.  We're having a lot of discussion without Kimy here, but presumably she would delegate much of the SE enahancement while keeping overall control.  If it's a team of SE developers, they likely would use something like GitHub to coordinate their work, but that's a side issue that those who wish to participate in could decide.

[krzp]

17 minutes ago, GreatCroco said:

PapyrusTweaksNG is out of the question. If a mod is incompatible with it, it gets the boot, no matter what. If tomorrow Sexlab would be incompatible, I'd remove it and every dependent mod in a heartbeat.

Same.

 

I really don't know how do people play without it.

 

17 minutes ago, GreatCroco said:

Oh yeah, true root motion is always a great thing. But I don't see the benefit for DD directly, but certainly for SexLab itself..

I felt like the hopping animation can make use of it, for the staccato type move, to feel more like an actual "hop" instead of the... glide-ish way it's working right now ?

[Hex Bolt]

 

1 hour ago, GreatCroco said:

There are some things that are impossible in SE without breaking LE compatibility. So unless you advocate for two divergent branches of the mod, one for LE and one for SE/AE, then your argument is just false.

Not what I've been saying.  DD can have a common core shared by both versions, with extra/divergent functionality in the SE version.  Developers who want to support all versions could target the core features and functions.  Others who prefer to use SE-specific features would be free to do so.  We're often told how many SE players there are.  Great!  Let's leverage that.  That many people should be able to come up with ways to add SE-specific enhancements to the common, maintained core that the LE version of DD would use.

Edited June 23, 2023 by HexBolt8

[naaitsab]

1 hour ago, Scrab said:

Thats why Im saying having independently from LE maintained, official version of DD would be this "best of both worlds", because then you can give LE users what they want (Kimy) while having the SE users get all the fancy SE exclusive things (dlls and performance). The term "official" is really important here

However, that again forces Kimy to make the sacrifice, by giving someone else the responsibility of maintaining an official SE port (partially) independent of the LE version. If you really want to resolve this issue, then someone has to be willing to pay something. May it be losing preference in development, a decentralized patch hunting or losing absolute control over the SE port

Sacrifice is a bit over the top here. Also I can't recall Kimy stating she refuses to use SE. And there are no issues at all in running LE and SE, and both CK's on the same PC. I've done it for years myself. So I find it a bit early to fully rule out and claim that she needs to make a complete LE sacrifice to add a SE environment. 

 

 

At this point I guess it would be wise to pause the discussion a bit and see what Kimy's stance on the given points is. And what solution/route would be worth venturing or need further detailing.

[GreatCroco]

You assume there'd be people wishing to take up that task. As of now we have one person doing the conversion, and we don't know if they are willing to be the person responsible for a de-facto independent fork. And let's not forget: this also applies to DCL. Even if Kimy is willing to give up parts of DD's development because they themselves have take over at some point, I'm pretty sure the same does not hold true for DCL.

Coordinating is also not a side issue, it's integral to the success of the SE version. Personally I'd nope out of a team, where I had to do the same work that was already done by another person again (which is the case for any plugin change), right away. Github (and Gitlab) also have the problem of limited space. Where do you host the binaries? Are you willing to pay for more space?

 

You make keeping two versions sound simple. It is not. Especially when a team is involved. Not to mention, that the person who has to the most amount of additional work is non other than Kimy themselves.

What some of the proposed solutions advocate for would result in people, that do everything in their free time, make changes twice to keep a version with far fewer players (Steam player charts are pretty clear on that front) on feature parity.

 

 

When looking rationally at the topic, the parameters point towards SE/AE, not LE.

 

18 minutes ago, HexBolt8 said:

 

Not what I've been saying.  DD can have a common core shared by both versions, with extra/divergent functionality in the SE version.  Developers who want to support all versions could target the core features and functions.

And how do you actually want to do that if the additional functionality for SE means ripping out parts of the old version? The shared code is precisely the thing that's holding the SE version back. The improvements made by the new SE mods are not just a shiny new thing pushed on top, they improve the way things work at the core.

Like, you can't backport OAR to DAR. That's not possible, it's a one way street. Or using the new allocator from EngineFixes. Or CommonLibNG, a new way to write SKSE plugins, where you'd move calculation intensive methods like the (un)equipping logic or device hider.

You now have to make sure that SE calls the plugin code, and LE remains on the Papyrus implementation. Sure that's doable, but it adds additional maintenance. You could also backport the plugin, but that would be a nightmare.

 

  

 

27 minutes ago, HexBolt8 said:

That many people should be able to come up with ways to add SE-specific enhancements to the common, maintained core that the LE version of DD would use.

Players are not modders, they usually have good ideas, but they would never be able to implement them. That means, just because SE has more players, doesn't automatically mean you have access to a wider pool of people who'd be willing to take up the torch.

 

 

 

 

27 minutes ago, krzp said:

I felt like the hopping animation can make use of it, for the staccato type move, to feel more like an actual "hop" instead of the... glide-ish way it's working right now ?

Ok, yeah, that one. That's a possible use-case.

 

Edited June 23, 2023 by GreatCroco

[Hex Bolt]

21 minutes ago, GreatCroco said:

You assume there'd be people wishing to take up that task.

It seems a good assumption.  Since there are so many SE players, some of whom seem pretty knowledgeable about SE-specific options, and insistent about changes they want, they can be the change and have what they want -- if they're willing to step up and put in the thought and effort to make it happen.  Over Skyrim's existence, we've seen amazing things accomplished.  SE players can get what they want without leaving LE players out of ongoing development & support of core Devious Devices.  We're talking about human beings, people who've been with us for many years in some cases, who have contributed both with mods that we've enjoyed, and with their wit, humor, and wisdom in topic discussions.  Let's not leave anyone out.

[zarantha]

2 hours ago, krzp said:

Speaking of "Mods being made on LE are easy to port to SE", I've got a casualty of that approach, Prison Overhauled - due to this mod's incompatibility with Papyrus Tweaks, I had to drop it from my load order with a heavy heart. I really liked that mod, and still haven't found a good replacement for it - but I can't play without Papyrus Tweaks, it's pure torture once you've tried it, there's no going back.

 

So it's not always that easy, apparently.

 

All you need to do is reset the mod from in it' MCM. I also reset SUM and DDe in their MCMs as they have the same initialization errors. It only needs to be done once, on a new game start or when the mods are first added. I've had it working just fine with tweaks installed.

[zarantha]

1 hour ago, GreatCroco said:

You assume there'd be people wishing to take up that task. As of now we have one person doing the conversion, and we don't know if they are willing to be the person responsible for a de-facto independent fork. And let's not forget: this also applies to DCL. Even if Kimy is willing to give up parts of DD's development because they themselves have take over at some point, I'm pretty sure the same does not hold true for DCL.

 

I wouldn't have an issue maintaining a fork, if that's all it was. My issue with this is a skill issue.

 

One - I'm not familiar with git enough to maintain a repo. (This can be easily corrected, true.)

Two - I lack coding skills. Scrab would probably help in her discord boot camp I'm sure, but at that point she might as well do it herself until i'm up to speed at some unknown date. Right now, I'm at the baby coder level and the most I can do is edit fragments and compile. That's not what is being discussed here though. 

 

So while i'd be willing, I'm currently not up to maintaining a full blown fork.

What I do have is a bunch of skills needed to maintain everything except the DLL and scripts. For DLL and scripts, I can compile and make small edits, but lack basic coding  understanding to do more. That makes me good at maintain the conversion, but bad for a fork.

[GreatCroco]

1 hour ago, HexBolt8 said:

SE players can get what they want without leaving LE players out of ongoing development & support of core Devious Devices. 

You fail top provide a reasonable path for that approach, when most SE improvements would include internal rewrites to make use of them. I have stated it multiple times: DD is already benefitting from some improvements that came with SE, but we can't get much more because frankly LE gets in the way. How do you want to keep a common core framework when SE needs to change the folder structure for animations (OAR) or when SE throws out the papyrus written code for native function calls in an SKSE plugin (CommonLibNG).  Want to leverage powerof3's PapyrusExtender Library, which has functions to deal with containers and arrays, (might be beneficial to the (un)equip logic), you can't. PapyrusExtender on LE is not even on the same planet compared to what the SE version offers.

 

At one point there has to be a decision: Switch to SE and gradually leave LE behind backporting bugfixes where possible, or stick to LE and risk people flat out removing the mod because it doesn't fit into their load order anymore. Most people are not willing to sink hours upon hours into creating a mod list, iron out the kinks and create merges and bashed patches. They want to play with as little fuss as possible, that's why Wabbajack and Nexus Mod lists exist and are popular.

So what's the realistic outcome for DD? People will install it, see that it doesn't work out of the box and then either flat out remove it or complain here or elsewhere. They won't take much time to search for patches. Remember: Most people are lurking, modders or people that participate in these threads are the minority of all players.

 

 

In the last two days people have failed to give me yet a good reason to keep LE alive, except "I like it more", but that's not a valid argument (nor is it, when people just argue that they like SE more), as that just gets into a counting game, which is seriously dumb.

The switch to SE/AE is not as hard as some people make it out to be, for modders, and especially for players. I'm repeating myself, but if a mod doesn't contain script extender files it's really just following the instructions to update the plugin to a new form version and then running tools to convert/optimize textures and models for SE. That takes time, sure, but it's not impossible.

On the player's side, I have yet to see a mod that is not compatible with SE and cannot be replaced by another mod. The only thing that comes remotely close is Jaxonz Positioner. It works, but only because the movement logic was written in papyrus and as an SKSE plugin. The latter doesn't work anymore, but the former does. It's not an ideal solution, however, as the performance without PapyrusTweaksNG is atrocious and I'd like another positioner, but moving stuff in your home by the millimetre, is pretty niche and no real replacement exists.

 

 

 

 

Let's, for the sake of argument, assume there'd be a group of people willing to take up the SE version and Kimy agrees and they themselves stick to LE. The group then proceeds to implement more and more of the SE-only improvements. This then results in a diverging feature set (because some new features are only possible with SE), widening the gap between the two versions. The LE version would then only get new models, animations (if there was an animator in the first place) and possibly quest (depending on the SE features used in it), with Kimy having to redo all the stuff again because you can't diff binaries.

 

How is that different to switching to "SE-First" and backporting everything possible?

 

Edited June 23, 2023 by GreatCroco

[Hex Bolt]

1 hour ago, GreatCroco said:

You fail top provide a reasonable path for that approach, when most SE improvements would include internal rewrites to make use of them.

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

 

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

 

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

Edited June 24, 2023 by HexBolt8

[krzp]

1 hour ago, zarantha said:

All you need to do is reset the mod from in it' MCM. I also reset SUM and DDe in their MCMs as they have the same initialization errors. It only needs to be done once, on a new game start or when the mods are first added. I've had it working just fine with tweaks installed.

Thank you for the tip, but I have a different problem with it - the failed initialization is fixed by doing what you've suggested (or just starting the new game without Papyrus Tweaks, letting POP initialize and turning them back on), that's one's not a big deal, but I CTD as soon as the pillory segment starts. I turn off Tweaks - it works well, I turn it back on - CTD as soon as the mod starts searching for actors or something like that. Plus, I sort of got the feeling that mod isn't working very well with Tweaks on in general - scripts bug out, actors get stuck, it forgets to unequip certain things, etc. Could be my particular combo of mods causing the, but turning off Tweaks fixes most of that. I've even tried it with the latest 4.1 version of tweaks, nope, still CTD's. ?

 

I might give it another chance when I finally upgrade to AE, maybe the newer PapyrusUtil fixes that.

Edited June 24, 2023 by krzp

[zarantha]

1 hour ago, krzp said:

Thank you for the tip, but I have a different problem with it - the failed initialization is fixed by doing what you've suggested (or just starting the new game without Papyrus Tweaks, letting POP initialize and turning them back on), that's one's not a big deal, but I CTD as soon as the pillory segment starts. I turn off Tweaks - it works well, I turn it back on - CTD as soon as the mod starts searching for actors or something like that. Plus, I sort of got the feeling that mod isn't working very well with Tweaks on in general - scripts bug out, actors get stuck, it forgets to unequip certain things, etc. Could be my particular combo of mods causing the, but turning off Tweaks fixes most of that. I've even tried it with the latest 4.1 version of tweaks, nope, still CTD's. ?

 

I might give it another chance when I finally upgrade to AE, maybe the newer PapyrusUtil fixes that.

 

That sucks, that's not been my experience at all, even with the pillory. I'm only not using it now because i hit the mcm limit and the full plugin limit, and I don't use those as much as other mods.

[zarantha]

Veladarius is back!

 

 

[krzp]

7 minutes ago, zarantha said:

Veladarius is back!

 

 

Blast from the past!!

 

Although, the "conflicts with other mods" section might have to be expanded... a little ?

[naaitsab]

6 hours ago, HexBolt8 said:

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

 

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

 

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

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

 

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

[Scrab]

1 hour ago, naaitsab said:

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

 

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

 

Maintaining this "core" isnt really an issue honestly

 

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

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

 

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

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

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

 

 

Edited June 24, 2023 by Scrab

[GreatCroco]

5 hours ago, Scrab said:

Maintaining this "core" isnt really an issue honestly

 

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

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

 

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

 

5 hours ago, Scrab said:

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

 

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

 

 

  

13 hours ago, HexBolt8 said:

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

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

 

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

 

6 hours ago, naaitsab said:

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

I'd like to know that, too.

Edited June 24, 2023 by GreatCroco

[naaitsab]

5 hours ago, Scrab said:

 

Maintaining this "core" isnt really an issue honestly

 

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

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

 

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

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

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

 

 

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

 

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

[Hex Bolt]

8 hours ago, naaitsab said:

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

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

 

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

 

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

 

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

Edited June 24, 2023 by HexBolt8