[Idea] Coordination Framework for SexLab mods

[lordescobar666]

I was just doing the Captured Dream quest in the Thalmer when suddenly the device comments from Cursed Loots kicked in and my PC got an additional item equipped (restrictive gloves which did not break the scene or immersion). This was not the first time that Cursed Loots interfered in a scene and sometimes it does break the scene, quest or immersion (I am looking at you, sex attacks).

 

Also Deviously Helpless is a notorious candidate for breaking stuff if you forgot to disable it. Later it got a programmatic toggle so that other mods could disable it for their scenes. But providing APIs for other mods is only a suboptimal solution to the problem of several mods interfering with each other as it has a complexity of O(n^2). Also you have to know which mods may interfere with your mods. And older mods need to get updated to work with newer mods, which will only be done if the author is still active.

 

The better solution would be to implement a framework that provides some means to stop mods interfering with each other. By using an intermediary the complexity gets reduced to O(n). You only need to integrate this intermediary framework into your mod and do not need to care about other mods, as long as they also use the framework. And new mods using the framework will automatically be compatible to your mod.

 

I envision some sort of named mutexe (e.g. "devious player interaction", "sexlab scene", etc), faction (e.g. "is in scene do not touch"), keywords, etc that can be used by mods to signal to other mods, that they might interfere with some other mod. The actual names and their semantics need to be agreed upon within the mod community to establish a common base covering as much situations where interference can happen as possible.

 

I think for Skyrim mods it is too late to get widespread adoption of such a framework. I am writing this down in anticipation of Fallout 4 (something tells me that a ecosystem similar to what we have know with SexLab in Skyrim is also about to happen there), so that this idea will be implemented there a soon as we have a working "whatever SexLab will be called in Fallout 4" to achieve widespread adoption. I would like to have to reload less in Fallout 4 because some mod decided to interfere with some other mod.

 

Feel free to share your opinion or to call me an idiot.

[RitualClarity]

Sounds great.. lead the way..

 

Get started on the new framework.. flesh it out ..

 

I am sure other mod authors would like the fact that their mods can work in piece and not have someone report a bug that has nothing to do with their mod because another one interfered with it and the user assumed it was his / her mod.

 

[Kimy]

Cursed Loot reacts to SendModEvent("dhlp-Suspend"), so in a a way DH and Cursed Loot are using the same framework already. Cursed Loot even auto-disables if it detects the player being enslaved by SD+ or Maria Eden. The problem is that even with reduced complexity, mods running scenes still have to trigger the necessary calls to signal DH or Cursed Loot that they are running scenes, and a lot of them just don't and never will.

[GSBmodders]

additional frameworks are and have been needed for sometime now, in looking at the slavery mods alone i am left wondering wtf happened. there is an army of slavers with zero compatibility. It would be a blessing to have a framework esm for mod authors to use in there creation to help aid stability and compatibility. as it stands now creativity is being stifled by this issue as I know from my own past experiences that few downloads = zero interest in continuing development which leads to break through's never being discovered that may very well have aided the entire community.

[lordescobar666]

Cursed Loot reacts to SendModEvent("dhlp-Suspend"), so in a a way DH and Cursed Loot are using the same framework already. Cursed Loot even auto-disables if it detects the player being enslaved by SD+ or Maria Eden. The problem is that even with reduced complexity, mods running scenes still have to trigger the necessary calls to signal DH or Cursed Loot that they are running scenes, and a lot of them just don't and never will.

 

SendModEvent is not a framework but a message transport, neither are events that are mod specific. A framework would introduce standardized events with well defined meanings that can be used by a broad range of mods.

 

The point of a framework is that you don't need to care about other mods but only about the framework. With the current situation, when mod A gets released you have to explicitly add support for A, then B gets releases and you again have to explicitly add support for B, and so on. With a framework you just implement support for the framework once and that's it.

 

With Skyrim mods, I also think that such a framework will come way to late, and will not be widely adopted. I may implement a prototype just to see how such a framework would work. But I am mainly proposing this idea so that it may get remembered when Fallout 4 finally has arrived. If such a framework is available right from the beginning then I think we could reach sufficient adoption for the framework to be useful.

 

[merryMalfunctioning]

It would be easier to do this kind of thing if more modders uploaded the source files for their scripts. The open-source model is a good one for making diverse software get along. Documentation about how the mods work internally would be even better, but not many modders have the time and dedication for that. Only the most hardcore modders document their API.

[lordescobar666]

It would be easier to do this kind of thing if more modders uploaded the source files for their scripts. The open-source model is a good one for making diverse software get along. Documentation about how the mods work internally would be even better, but not many modders have the time and dedication for that. Only the most hardcore modders document their API.

 

True, the open source model is one of the best development models for software. And here on loverslab it's standard procedure to upload the sources (I don't know of any mod hosted here that doesn't provide sources). It's those nasty Nexus people who do not like to share their sources.

[Kimy]

 

Cursed Loot reacts to SendModEvent("dhlp-Suspend"), so in a a way DH and Cursed Loot are using the same framework already. Cursed Loot even auto-disables if it detects the player being enslaved by SD+ or Maria Eden. The problem is that even with reduced complexity, mods running scenes still have to trigger the necessary calls to signal DH or Cursed Loot that they are running scenes, and a lot of them just don't and never will.

 

SendModEvent is not a framework but a message transport, neither are events that are mod specific. A framework would introduce standardized events with well defined meanings that can be used by a broad range of mods.

 

The point of a framework is that you don't need to care about other mods but only about the framework. With the current situation, when mod A gets released you have to explicitly add support for A, then B gets releases and you again have to explicitly add support for B, and so on. With a framework you just implement support for the framework once and that's it.

 

With Skyrim mods, I also think that such a framework will come way to late, and will not be widely adopted. I may implement a prototype just to see how such a framework would work. But I am mainly proposing this idea so that it may get remembered when Fallout 4 finally has arrived. If such a framework is available right from the beginning then I think we could reach sufficient adoption for the framework to be useful.

 

 

 

Technicalities about what and what doesn't constitute a framework aside, you are probably right in that developing a "LL Scene Framework" will come too late at this point. That and I am not sure how a framework controlling events would meet all scene running mods' needs to a satisfying enough degree to convince ALL relevant mods to use it. I think if you'd try to put too much functionality into this framework, it might easily end up becoming too limiting for many use cases.

 

I think what's really worth a shot is defining a lightweight event messenging API that can signal other mods that your mod is claiming temporary exclusivity on the game to run a scene. Like a token-ring or something like that. Which is pretty much what DHLP-Suspend already does, if all modders would just add a few lines of code to make use of it, we'd be largely rid of the problem already.