Jump to content

General Idea - Skyrims Loverslab API


Recommended Posts

Hello Readers and following Modders

 

I wanted to gather some general feedback of a crazy idea i had.

 

For some days i drafted around an Architecture and i had some ideas regarding maybe a General Loverslab Mods API. I realized it because i wanted to add a crawl feature and I found out... I have like 5 mods which have the same feature, but implemented on their own, and I created the same feature again to not have mod bindings for an animation.

 

Let's face it. The Current Mod Environment here is basically a mess. I don't want to be mean here, but some mods are simply not following the rules or, as I mentioned before, reimplementing it again. Inventory is checked by several mods, Several mods are scanning for NPCs around me to maybe trigger an event etc.

 

Currently, in a common mod load order of a LL Quest user, there are many calls for actor Scanning, Equipping Devices, Calling Sex, Follower Handling, Inventory Handling etc.

This often leads to fighting mods: One Mod forces you to crawl, another makes you wear an Armbinder. Some others want to use sexlab and DD, others want to use Toys.

Why should you as a mod author care about if the user is having Sexlab, Toys or OSex installed, as long as a corresponding sex scene is started, and you get the results back. (As long as you really don't need one specific Mod Feature ofc. )

 

This is where the idea comes in.

We could create a common API for common tasks, and polish them to make them efficient and less conflicting as possible.

I already started with my own Follower Framework Bindings.

 

What could be the Content:

 

Instead, that everyone scans for NPCs, we have 1 common scan and all mods can access the list of existing NPCs or request a fresh scan besides the common last one.

Instead of Equipping devices over DD framework directly, you call it over the API and the API keeps track for you of the devices and selects on player, npc preferences the devices if possible. If the player is already wearing an Armbinder, the Yoke will not be equiped, but the call will return true (except let's say the modder really wants that yoke for a reason). If DD is not installed, how about a Toys Restraint. You get the idea.

Instead of calling Sexlab.AnimationEventbyTags how about calling a Function Blowjob(Player, Partner, Rape=False, Submissive=True) i think the idea is clear.

Or just common things like a crawling event, or walking a player to a target, everything could be very generic implemented.

 

But what about compiling? If you compiled a mod with this framework (even with good soft references) it would require everything in the worst case. The Dev Setup would be horrible.

 

I did some measurements. ModEvents and StoryEvents are not that slow.

I fully agree, a direct linkage is faster in every way. But if we define one common interface you can use to call for example a sexlab Animation without having sexlab in the compile chain, we could produce a big common interface for common things.

 

Example:

 

Function Blowjob(Actor Active, Actor Passive)

 SendModEvent(....)

EndFunction

 

Usage: SexInterface.Blowjob()

 

 

Overall i identified 7 Big Blocks which are copied and used wild everywhere:

 

  • Sexcalls,
  • Restraints,
  • Furniture handling,
  • Outfit and Inventory Management,
  • Common Tasks like some Animations and or Actions (whipping etc)
  • NPC Scanning / Arousal Scanning
  • Follower Handling

 

Many APIs could be simplified because most of them are only for the Player anyway in 90% of the use cases.

 

What would be the benefits

  • Common interfaces for common things
  • New Modders could start easy with some new Mods without a big Effort to code everything from scratch
  • I would say overall Performance Increase
  • Hopefully, less conflicting mods
  • Development of your mod can focus on your Main Content, not what everyone else has already developed
  • Users can decide what they want to use, and have one place for a lot of preferences (no need to implement again your preferred DD material or what Collar to use)

 

Downsides:

  • Development effort is for the start big
  • Loss of Freedom for some mods, sometime you just have to commit to the rules for basic things.
    • This you have anyway else it always results into a buggy mess
  • Rework of mods is needed step by step

 

I do not have any code besides some play tests I have done during my dev time. I also do not want to just do something because in the end it would be just a hub for several mods to link in and get integrated.

Edited by coffeeink
Link to comment

Always thought there was space for something like this. But it's developer would need to be extremely active, capable, willing to entertain requests for tweaks/refinements etc and be ready to spend vast amounts of time to answer questions on the forum. Perhaps it could be handled by a team rather than one person. Each person responsible for the different aspects. 

 

You could probably add outfit description via a common keywords system (how many of these are there?) and a cell change and combat start/end events to the list too. 

 

On the contrary, I kind of feel that it's too late for this. It would need to have been available in like the first month the CK was released. So many modders are inactive now and would not be willing to update their mods to cooperate with a framework like this. 

Link to comment

Your big problem is going to be adoption. It's not enough to have a good idea, you need one that's good enough to inspire seasoned modders to rewrite working code to work with your interface. And you need a way to make new modders aware of the API when they're still scrabbling around to find out the CK works and to understand the internals of the engine.

 

It's not a bad idea, but it's not a new one either. I do like the idea of using modevents to decouple backends, but if you write it, will they come?

Link to comment
16 minutes ago, Monoman1 said:

On the contrary, I kind of feel that it's too late for this. It would need to have been available in like the first month the CK was released

 

It might be worth revisiting the idea when the Starfield CK drops. Get something working for a fresh modding scene, and it might stand a chance.

Link to comment
1 hour ago, DocClox said:

 

It might be worth revisiting the idea when the Starfield CK drops. Get something working for a fresh modding scene, and it might stand a chance.

Yea. That's what I was thinking. Even though I don't seem interested in starfield personally tbh. 

 

Also if said framework had some kind of force greet traffic lighting/queuing system it could help a lot. 

Edited by Monoman1
Link to comment

yes that big effort is right. we would have to start with smaller things also to verify that the concept is really working on real setups.

 

I realized how complex the LL Mod world is compared to "normal" modding by explaining to someone how to set up the compile chain. CK is complex enough on its own. And we add here like 10 different layers of complexity on what we want to do.

 

But yes, with the too late, I also fear. Just as a simple example, we can have a look at Slaverun.

A huge mod, but the development is basically dead. Without additional files from the community, it does not even start and still has major issues with DD handling.

 

 

The decoupling with mod events works at least on my setup and i tried it with a very heavy modded setup. I never had a loss. But i really just made some small tests.

I made basically a somehow "TCP" ACK  method for the examples. Mainly to get a procedural flow running.

 

You register for a specific answer / id right before you send your request, and you wait for this id on an answer. => This leads that you get the callback parameters and or just void for being finished.

We could introduce an ack event for i received it.

 

I tried this approach for my lola addon where i wanted to have 1 common interface to use for DM3, ZAZ and DDC Furniture and i offer the basically same interface to every furniture now.

You call BindActor(Actor, Furniture) and it handles for you the specific API calls for you. And DM3, DDC and ZAZ are working entirely different

 

In the End, i removed the mod event calling it for this Extension because yeah It was an additional effort to define the modevents. But it worked so far.

 

Bringing this World to new Modders would be more simple than teach them how to use Toys or DD interfaces, i guess.

 

But i have to say i'm far away from beeing a CK Expert. I learn everyday something new by looking on how mods solving problems.

 

Oh yeah Generic Forcegreets would be good saving.

I also had something in place...

Because calling the FG and select can be easily done by forcing a ref and setting a global var. Worked quite decent.

Having only 2 Blocking Branches fighting is inconsistent.

 

Regrading star field.

I 'm not so sure that we will see the same modding world in starfield that we see here. We saw regular attempts to Cash in on mods. They were not fully successful because the Mod Communities were established before. They could easily create a signed packed only architecture over their Beteshda net backend and modding community is dead as we know it.

 

Edited by coffeeink
Link to comment

I'm going to be that guy and pour a proverbial bucket of cold water over your head.

 

The idea is sound on paper, but modding ain't exactly an industry. You can't implement standards and regulations, especially because how fragmented it is now. When it comes to the game you have: LE, SE, AE, then for modding you have Nexus, LL, Steam Workshop, whatever Bethesda.net is nowadays (if it even still exists after MS takeover) and that's on the general "western" (EU &US) side of modding. And the whole Korean, Chinese and Japanese environments, which are completely different things altogether and do their own stuff, not to mention there used to be (fuck knows what's going on there these days) a totally separate Russian and Russophone scene. You're basically asking to create something akin to industry standard across a medium that's totally a hobbyist affair and where people do whatever they want anyway. I'm not saying its impossible, but personally I can't see that ever happening.

 

And I haven't even touched the fact that you want to do it for a very niche, adult-themed parts of that fragmented modding scene. Sex while popular in general is kinda borderline in mainstream, however straight porn mods ain't exactly that appealing to "normies". Especially the kind of porn mods that are popular here. We are a niche of a niche.

 

I'm sorry if that sounds rough, it is not my intention to get you down, I'm just trying to see it from a more realistic (and very pessimistic, I'll admit) perspective. I am going to wish you good luck though.

Edited by belegost
Link to comment

1. way too late

2. modders are going to mod precise thing they want with context preapplied, because fetish modding presupposes fetishes, expecting anyone else to fall in line is herding cats at best

3. Baka and clonereal will have your shit stolen and making money off it before your initial link is even posted and they won't be taking it down ever, which means anyone else using your "unified framework" will have their shit stolen as soon as it's published. Good luck with that.

Edited by 27X
Link to comment

Looking at this from a newcomer's perspective, I wonder how much the lack of new, solid mods is a symptom of Skyrim being "past its prime" versus the level of complexity you're describing barring potential authors from making stuff.

 

Maybe an API like this is exactly what's needed to encourage people to create new mods. You could make a separate post asking non-authors why they've never built something. I assume most of the responses (implicitly) will be a lack of time/interest/laziness but you might get some replies that validate this hypothesis. I strongly doubt existing mods will be reworked by their authors to accommodate this API. Most creators are hobbyists who want to get something they want to see into the game as quickly as possible and are nice enough to share. Getting them to comply with some kind of universal standard is unlikely to end well.

 

And this hobbyist thing is probably the reason no one has tried this before. Would you rather spend days of your life building an API or just adding whatever content you wanted to see in the first place? From a financial perspective i.e. Patreon this makes even less sense. People are not going to pay you to make an abstract piece of software, they want to see something.

 

Documentation is also a point of concern. That's the thing just about everyone who writes code hates doing and whoever is in charge of this would need to do a very good job keeping it up to date, comprehensive, and beginner friendly. Mods with easy to understand docs like Public Whore and Devious Devices Equip are the exception in this regard.

 

There's also a wave of newer mods taking a modular, decoupled approach somewhat similar to what you're describing e.g. Pama's Prison Alternative, Scrab's Acheron/Yamete Kudasai, and Suzutsuki's Battlefuck which provide relatively simple interfaces for people to extend the individual experiences they're altering (prison and defeat respectively). And shameless plug, I'm working on a framework to let other mod authors extend player slavery mods (like DFC, SLTR, SD+) sans conflict.

 

 

7 hours ago, coffeeink said:

But yes, with the too late, I also fear. Just as a simple example, we can have a look at Slaverun.

A huge mod, but the development is basically dead. Without additional files from the community, it does not even start and still has major issues with DD handling.

 

If you haven't seen it already, Kaxat is continuing work on parts of Slaverun.

 

EDIT: Relevant xkcd
 

Standards

Edited by ponzipyramid
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