Jump to content

Devious Devices Framework Development/Beta


Recommended Posts

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?

Link to comment
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 by Scrab
Link to comment
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.)

Link to comment
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 :P 

 

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.

Link to comment
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 by Scrab
Link to comment
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 by GreatCroco
Link to comment

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 by krzp
Link to comment
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.

Link to comment
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 by naaitsab
Link to comment
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.

Link to comment
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 ?

Link to comment

 

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 by HexBolt8
Link to comment
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.

Link to comment

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 by GreatCroco
Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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 by GreatCroco
Link to comment
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 by HexBolt8
Link to comment
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 by krzp
Link to comment
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.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use