Jump to content

Recommended Posts

Posted (edited)

I hit a snag in creating a compatibility layer for old mods.

 

I re-implemented many of the old magic magic effects by changing the conditions to use globals and effects from SLSF-Reloaded and SexLab instead of using stuff internal to the old SLSF.  For development purposes, I just used overrides.

 

When I went to create a replacement stub version of "SexLab - Sexual Fame [SLSF].esm", I realized there's an issue.  Since this is an ESM, it cannot make reference to any records in an ESP.   I see three solutions. .  One is to have the new SLSF-Reloaded globals (but probably no other records) also be in an esm.   A second solution is to abandon having magic effects that work off of engine conditionals and instead have all the effects applied and removed via scripting.   A third solution is to not provide a "SexLab - Sexual Fame [SLSF].esm" and instead require all old mods to be ported.  We'd need to have an xedit script to make that feasible.

 

EDIT: I might be able to do the xEdit script.

Edited by Arcane Wanderer
Posted
53 minutes ago, Arcane Wanderer said:

One is to have the new SLSF-Reloaded globals (but probably no other records) also be in an esm.

OOC, do you mean a separate .esm? Sorry, I am a regular user of SLSF-FC and have been following this discussion with a great deal of interest. Why not just copy the globals you need from Reloaded into the .esm you created for backwards compatibility with older mods (many of which I have used)?

I'm not a modder, so maybe there's a reason for it, but I'm thinking that one plugin is better than two.

I like the idea about a script. If it's available on the downloads tab as a 'modder's resource', then mod authors or even mod users can port for themselves. Could even offer both options. If people aren't worried about plugin limits then the new plugin would be an easy solution. Otherwise, they can use the script. Or stick with the original SLSF. Their setup, their choice, and imho no more can be reasonably expected from this mod in terms of backwards compatibility.

My 2 cents, fwiw.

Posted
6 hours ago, Seeker999 said:

Why not just copy the globals you need from Reloaded into the .esm you created for backwards compatibility with older mods (many of which I have used)?

 

Because SLSF Reloaded was not designed to use/need another plugin, and as Arcane Wanderer stated, ESMs cannot reference ESPs, so there's no way for the plugins to properly communicate without basically starting over.

 

@Arcane Wanderer Honestly I think trying to make any kind of backwards compatibility (aside from capturing the old Mod Events) is too much of a mess at this point. Mod authors will simply have to update to the Reloaded system. It's become very clear to me that the old SLSF is a headache at every corner.

 

I've been getting extremely anxious and stressed whenever I think about making backwards compatibility for SLSF over the past week, so for the sake of my mental and physical health I'm indefinitely putting that concept on the shelf. I have no idea where to start, what all is actually needed, how to make the plugins communicate properly, how to implement what you made because I haven't seen it yet, and so on.

 

It's all too much for me to handle, so I'm just not doing it.

 

Yes, this decision is likely going to cause a bit of a split in the user base, but I'm confident that this system will "win-out" in the end. At this point all I can hope is that mod authors update ASAP to use Reloaded.

Posted

Totally understand and respect your decision.

  • You looked into backwards compatibility and you tried. As far as I'm concerned, that's good enough.
  • You realized it's not something you are able/willing to do, at least at this time. Again, good enough for me. Nobody has the right to expect you to stress yourself out over this. Your mod, your decision.
  • If somebody wants to make a patch for compatibility, then that's their decision and they can host it on a separate mod page with its own support thread. IMO a win-win; for you since you don't have the headache and responsibility and for users of those other mods (don't know how active those mod authors are) since they can take advantage of your version.

Anyway, thanks for your work on this mod, now and in the future. 😎

Posted

Hi! Since this is in development, would you discourage Wabbajack list authors from using it until the public beta is done? WJ requires exact matches for files, if list A is using 0.5 and you update to 0.6 that would render the list uninstallable (unless you keep old files up). Just checking in how frequent updates will be in the near future.

So far this looks rather promising and I'm excited to see further development!

Posted (edited)
21 minutes ago, Miss Corruption said:

Hi! Since this is in development, would you discourage Wabbajack list authors from using it until the public beta is done? WJ requires exact matches for files, if list A is using 0.5 and you update to 0.6 that would render the list uninstallable (unless you keep old files up). Just checking in how frequent updates will be in the near future.

So far this looks rather promising and I'm excited to see further development!

 

I would definitely discourage that currently, yes.

 

I've been trying to update the mod with the functions necessary for Fame Comments to update as soon as possible, so I've been updating rather frequently. The updates will likely slow down at this point, depending on what else may be needed for Fame Comments.

 

At this point I really need good feedback on the stability of the current version. IE: Do all of the features work? Are there errors popping up? Does the mod suddenly stop working altogether after something happens? and so on. So far I have only seen people reporting the Fame Error spam from versions prior to 0.4, so if I don't find or get reports of any other bugs in a couple of weeks then I'll assume this is effectively 1.0 ready.

 

----------------------------------------------------------------------

 

As a side note, I'm personally in the camp of not using things such as Wabbajack and Nexus Collections. I will also admit I've never used them, so I'm not sure how involved that is or isn't. Just personally I believe everyone should be fully aware of each mod they download and what its doing, though I also understand the appeal of the convenience.

 

Maybe I'll add this to the description as well, but I will not be responding/helping anyone that claims SLSF Reloaded is causing problems if they use Wabbajack or the like. If they can provide hard evidence that SLSF Reloaded is the problem (such as one of my built-in error messages) that's one thing, but many collection users tend to have 0 clue what's actually happening in their game and just blame the mod that isn't doing what they want.

Edited by NymphoElf
Posted (edited)

I think we can make porting easy!

 

It turns out that Mator's "Automation Tools for TES5Edit" will almost do what we want.  He has a script that will go through a plugin and change specified references from one thing to another.   The only issue was that the script would not actually run.   However, he has an updated version on github that does work.  I've uploaded an easily installed version of his github files to my patches page.

 

For testing, I used Mator's script to edit SLSFFameComments,esp to change all of the SLSFEquipStatus_Sur_9 references from "SexLab - Sexual Fame [SLSF].esm" to instead use SLSFxEquipStatus_Sur_9 from a "SLSF-compat-testing.esp" I've been working on.

 

It works.  Mator's script prompts for record names, so you'd have to run it many times for each mod to be converted - once for every record in the old SLSF.   I can write a version that won't need prompts but will instead have all of the old and new records hard-coded.

 

TL;DR - We can get to a point where porting a plugin is push-a-button.   However, unless somebody wants to do some interesting work, a limitation will be that the record types need to be the same.  So, no going from a a MGEF in the old version to a Global in the new version.   Mator's script will allow such things, but you'd end up with a converted plugin that would try and fail to do things like call GetGlobalValue() on a magic effect when that function only allows globals.

Edited by Arcane Wanderer
Posted

I've updated my earlier post to note which mods have plugins that actually reference Versh's plugin.

I didn't check the sources (yet) to see which mods contain source files that reference Versh's stuff.

Posted
14 hours ago, Arcane Wanderer said:

I hit a snag in creating a compatibility layer for old mods.

 

I re-implemented many of the old magic magic effects by changing the conditions to use globals and effects from SLSF-Reloaded and SexLab instead of using stuff internal to the old SLSF.  For development purposes, I just used overrides.

 

When I went to create a replacement stub version of "SexLab - Sexual Fame [SLSF].esm", I realized there's an issue.  Since this is an ESM, it cannot make reference to any records in an ESP.   I see three solutions. .  One is to have the new SLSF-Reloaded globals (but probably no other records) also be in an esm.   A second solution is to abandon having magic effects that work off of engine conditionals and instead have all the effects applied and removed via scripting.   A third solution is to not provide a "SexLab - Sexual Fame [SLSF].esm" and instead require all old mods to be ported.  We'd need to have an xedit script to make that feasible.

 

EDIT: I might be able to do the xEdit script.

 

 

There could be another solution; instead of making the ESM reference the esp directly, ESM stub could fetch the records from the ESP on initialization using Game.GetFormFromFile?

Posted
13 minutes ago, DayTri said:

 

 

There could be another solution; instead of making the ESM reference the esp directly, ESM stub could fetch the records from the ESP on initialization using Game.GetFormFromFile?

 

That would be via script rather than within the ESM itself. You're half-correct. If I understand correctly he's trying to find a script-less way to grab/pass information, but that simply might not be possible.

 

1 hour ago, blahity said:

Honestly, I only use Gristle's mods and Radiant Prostitution - RMCW Edition. So as long as those get updated to work with this new framework I'll be a happy guy.

 

I looked at that mod. From what I could tell that one uses ModEvents to edit fame values, so that one should be very easy to update. I have ModEvents that do the same or similar things, plus making new ones would be very easy for me to implement if the existing ones don't quite do what the author wants. Perhaps see if they're willing to update.

Posted (edited)
18 minutes ago, NymphoElf said:

 

That would be via script rather than within the ESM itself. You're half-correct. If I understand correctly he's trying to find a script-less way to grab/pass information, but that simply might not be possible.

 

 

I looked at that mod. From what I could tell that one uses ModEvents to edit fame values, so that one should be very easy to update. I have ModEvents that do the same or similar things, plus making new ones would be very easy for me to implement if the existing ones don't quite do what the author wants. Perhaps see if they're willing to update.

 

Actually, I was at least half wrong.   Which is sad because I'd already solved it in my testing.   You can have an ESP that contains overrides of the old ESM's MGEF.   That new ESP could either be the SLSF-Reloaded ESP or a new esp that would be placed after SLSF-Reloaded to leverage SLS-Reloaded's features.

 

You'd still need an ESM with the same name as Versh's but it would not have quests and other active stuff.  That would be stripped out leaving only magic effects, globals, and perhaps some formlists and factions maybe.

 

Keeping a very stripped down version of the old ESM alive would probably allow a few mods to work without any porting.  However, it definitely would *not* cover all mods.   And, an xEdit script can make it trivial to port anything that a stripped-down ESM would have been sufficient for.   So, a quick solution, but maybe not worth it.

Edited by Arcane Wanderer
Posted
18 hours ago, NymphoElf said:

@Hex Bolt - To clarify a little further, the mod uses certain SKSE functions/code that I think might not be available in the LE versions of SKSE, so that may be the root cause of this not being LE compatible. It shouldn't be difficult to make things work on LE. I simply don't play on LE anymore, and only have the SE version installed, so I'd rather not install the game again and whatnot simply to convert it to LE. Plus, if my theory is correct about SKSE, it would be a bit of a hassle for me to manage two separate versions of the code.

Thanks, that's good to know.  Since the mod doesn't add any native functions, it's just a matter of identifying SE-specific function calls and handling what they're used for in a different way.  When the pace of updates decreases, I might look at doing a conversion for LE (not making promises, so if someone else would like to tackle that first, please do).

Posted (edited)

@Hex Bolt If/when you start on that, I'd definitely just try to compile what's there to see how far you get. I would also double-check the script properties to ensure those are filled with the proper values/objects. If it's not an SKSE issue, then the only thing I can think of is that somehow the script properties are wiped or otherwise invalid on LE. The errors that were being reported were as if the arrays were not properly initialized or had no values, and I honestly have no clue why that would have happened.

 

Either way, once that's sorted out you should be 99% of the way there, if not done by that point. Any remaining code incompatibilities should be rather few.

 

I don't blame you for wanting to wait until the mod is more or less finished though. And like I said earlier, it's practically finished as-is so long as there are no more bugs. There's a little more MCM polishing I could do, but that's all I can actively think of at the moment.

Edited by NymphoElf
Posted
14 minutes ago, NymphoElf said:

If/when you start on that, I'd definitely just try to compile what's there to see how far you get.

I'm naively hopeful that the compiler will find all the incompatibilities, so then it's "just" a matter of implementing workarounds.  (That kind of optimism is valuable; otherwise, we'd never start half the projects that we find ourselves doing.)

 

18 minutes ago, NymphoElf said:

I would also double-check the script properties to ensure those are filled with the proper values/objects. If it's not an SKSE issue, then the only thing I can think of is that somehow the script properties are wiped or otherwise invalid on LE. The errors that were being reported were as if the arrays were not properly initialized or had no values, and I honestly have no clue why that would have happened.

Okay, thanks for the warning.  I'm not aware of that kind of incompatibility (I use several SE mods without having to touch them), but it's a good place to look if others hit a snag there.

Posted (edited)
13 hours ago, Hex Bolt said:

I'm naively hopeful that the compiler will find all the incompatibilities

 

Lol. I don't think it's entirely naïve in this case, but I understand what you mean and I hope it works out well.

Edited by NymphoElf
Posted

@Gristle, @NymphoElf

 

Here's some stuff for testing.

 

This is probably not of interest to anyone else -- and if you use it on a game you care about, you'll have to remove it later via a clean save.

 

SLSF-Reloaded-Versh-Compat.7z consists of only an ESL-flagged "SLSF-Reloaded-Versh-compat.esp".  It provides all of the magic effects that "SLSF Fame Comments" uses.   The cum related and dirt related effects are working, but the DD effects only partially work.   For the dirt related magic effects to work you also need the second file.

 

DirtTracker.7z contains an ESP and a script.  It provides globals to track the status of dirt levels for the three most popular bathing mods.   Global DirtTracker_Dirt_Level is the variable you want.   Values range from 0 to 3 to match the clean/not-dirty/dirty/filthy levels that most bathing mods use.   There is support for additional detail.  One of the bathing mods, "Dirt & Blood" tracks whether you're dirty due to dirt or due to blood.  Two other variables, DirtTracker_DirtOnly_Level and DirtTracker_BloodOnly_Level do what they sound like.

 

The SLSF-Reloaded-Versh-compat.esp is a temporary solution.  It still requires a "SexLab - Sexual Fame [SLSF].esm"  - either Versh's or a lobotomized one.  It should provide drop-in compatibility for the magic effects with no porting or editing.  @NymphoElf, if you want to support the old magic effects, you'll have to decide whether to keep something like my esp as a shim, or move those overrides to your esp, or change those overrides to new records in your esp.   The first two approaches will require some version of a lobotomized "SexLab - Sexual Fame [SLSF].esm" to exist (but allow some level of drop-in compatibility).   The third approach requires pre-existing mods to be converted.

 

I initially created DirtTracker with the expectation that it was going to be a small script and that you would probably want to add it to SLSF-Reloaded.  That's fine if you want to use it that way.   I'm thinking of also releasing it as a modders resource on nexus too.   Thoughts?

 

A quick comment on the old design:  Personally, using magic effects is OK, but I don't like the design of the old effects.  Having SLSF_EquipStatus_Body_Sur_2_Sight_light being defined as "visible cum, but not heavy cum" seems odd.  I think SexLab had it right with keyword CumOralStacked always meaning that CumOral would be true too.   So, for any new efforts, people should be encouraged to use some combination of the new SLSF_Reloaded_OralCumVisible global, the SexLab OralCum magic keyword, and the SexLab OralCumStacked magic keyword.

 

P.S.  Why can't include files in private messages?  Grumble...

SLSF-Reloaded-Versh-Compat.7z DirtTracker.7z

Posted (edited)

@Arcane Wanderer I'll see what I can do with these and get back to you.

 

Just based on everything you described, I think the Dirt Tracker will probably be fine to add to the main mod. If you also want to release it as a modder's resource then that's up to you. You made it.

 

As far as the Magic Effects, I have no doubt you've done good work with that. However, a I stated previously, I'm still worried about trying to add compatibility with the old Magic Effects possibly getting messy to deal with. I also really don't like the idea of possibly needing an extra plugin with this mod, and I've already made a strong effort to make updating easy for mod authors via my ModEventListerner script. I would rather mod authors update to the new system and abandon the old one.

 

I will still look at it, but I'm not making any promises.

Edited by NymphoElf
Posted

I'm uncertain if this is a known issue, but the MCM has been very unreliable for me.  For starters, it takes significantly longer to load than most other menus I've used, which is a bit annoying, but manageable.  What is not manageable is the way that it seems to just... stop working after an hour or two of gameplay.  I'm not sure if its the data stored there bloating as fame gets updated, but now whenever I try to open it it just appears empty for a very long time.  I'm not actually certain if its still loading, and is just taking forever, or if its broken completely - but the point is somewhat moot as I'd never be willing to wait multiple minutes to check my fame when I'd rather be playing the game.  

 

That said, in the brief period of time that the MCM is accessible I've found this to be greatly preferable to the old SLSF, so I hope you can iron out all the bugs.  

 

Side note - the slave tats integration and specific gains menu is awesome, but the fact that its currently limited to managing just 6 body entries is a major downside considering that I've increased the amount of body overlays I have access to.  Not sure if this is something you're capable of changing/fixing, but I thought it was worth mentioning.  

Load order attached, in case that's of any use to you.

loadorder.txt

Posted (edited)
1 hour ago, ARTistness said:

I'm uncertain if this is a known issue, but the MCM has been very unreliable for me.  For starters, it takes significantly longer to load than most other menus I've used, which is a bit annoying, but manageable.  What is not manageable is the way that it seems to just... stop working after an hour or two of gameplay.  I'm not sure if its the data stored there bloating as fame gets updated, but now whenever I try to open it it just appears empty for a very long time.  I'm not actually certain if its still loading, and is just taking forever, or if its broken completely - but the point is somewhat moot as I'd never be willing to wait multiple minutes to check my fame when I'd rather be playing the game.  

 

That said, in the brief period of time that the MCM is accessible I've found this to be greatly preferable to the old SLSF, so I hope you can iron out all the bugs.  

 

Side note - the slave tats integration and specific gains menu is awesome, but the fact that its currently limited to managing just 6 body entries is a major downside considering that I've increased the amount of body overlays I have access to.  Not sure if this is something you're capable of changing/fixing, but I thought it was worth mentioning.  

Load order attached, in case that's of any use to you.

loadorder.txt 10.66 kB · 0 downloads

 

The MCM not loading is likely a hidden bug. Unfortunately Load Order is not particularly useful. I need a papyrus log to see where the MCM is getting hung up. This has happened before with the MCM in my personal testing, but I thought I fixed it for good. Seems not.

 

Please Set "bEnableLogging" and "bEnableTrace" to 1 in your Skyrim.ini (default is 0). If you can, please try to reproduce the issue and send me the Papyrus log afterwards. This will give me the information I need to find the bug.

 

Also, just to make sure, which version of the mod are you using? And did you make sure to clean your save (or start a new game) when updating? This is rather important to do since I've been making numerous changes to the mod.

 

Thank you for reporting this.

 

As for the Tattoo Slots, I'm not sure if SlaveTats recognizes more than 6 slots? Can you explain more about how you extended the slot limit? If it's something SlaveTats recognizes, then adding an option to extend the slots will be fairly easy. If it's something else, that's a different story.

 

Also, thank you for the kind words. I'm glad you enjoy the mod! Sorry that it's still a bit buggy. As you can imagine, this is extremely difficult to test by myself, so having people like you be able to report these things is ultra-valuable. :heart:

Edited by NymphoElf
Posted
7 hours ago, NymphoElf said:

As for the Tattoo Slots, I'm not sure if SlaveTats recognizes more than 6 slots? Can you explain more about how you extended the slot limit? If it's something SlaveTats recognizes, then adding an option to extend the slots will be fairly easy. If it's something else, that's a different story.

If a user wants more tattoo slots they just have edit their skee64.ini (from Racemenu) [Overlays] section.

For example, I changed body slots from 6 to 38:

 

[Overlays/Body] ; "Body [Ovl#]" and "Body [SOvl#]"
; Determines how many body overlays there should be
iNumOverlays=38 ; Default[6]
iSpellOverlays=1 ; Default[1]

 

All 38 slots show up in the slavetats menu.

 

Hope this helps.

Posted
3 hours ago, Seeker999 said:

All 38 slots show up in the slavetats menu.

 

Is there a limit to how many there can be? If not I'll have to set an arbitrary limit because the MCM would be absolutely gigantic otherwise, and that will only make loading it worse to deal with 

Posted

I stumbled across a post about someone modifying a personal copy of the old SLSF so that searches from SexLab Body Search would not increase fame.

 

Probably worth tracking as an ultra-low priority to followup on at some point.   I'm guessing the OP was talking about nudity fame (because I'm guessing both the old and new SLSF catch StartSex() calls instead of keying off animations.)  The biggest reason I mention this post is because I wonder if there's other stuff that could get inappropriately caught.  Which leads me to wonder if someone has a white list of tags or somesuch.

 

Posted
18 minutes ago, Arcane Wanderer said:

I stumbled across a post about someone modifying a personal copy of the old SLSF so that searches from SexLab Body Search would not increase fame.

 

Probably worth tracking as an ultra-low priority to followup on at some point.   I'm guessing the OP was talking about nudity fame (because I'm guessing both the old and new SLSF catch StartSex() calls instead of keying off animations.)  The biggest reason I mention this post is because I wonder if there's other stuff that could get inappropriately caught.  Which leads me to wonder if someone has a white list of tags or somesuch.

 

 

The body search animations seem to have a unique tag that can be searched for, so that's an easy add.

Posted
1 hour ago, NymphoElf said:

Is there a limit to how many there can be?


I believe the hard limit is 128, but that is 128 for body, 128 for hands, etc.

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