[Abandoned] BFrame:Belly Node Manager Mod (Outdated due to NiOverride)

[4onen]

For non-modders:
This isn't out yet. Nothing changes.

For modders:
This isn't out yet, and I'm not sure whether I'm releasing as .esp (meaning access through specially crafted events, harder on you guys) or an .esm (meaning access through functions -- easy on you guys -- but I don't know how to make an esm)

Minimum Release Features:
§ .esp (Event) access to mod functionality. Mod fires event, my framework adjusts target actor.
§ Simple belly node scaling. Mod provides value, framework updates.
§ Animated simple node scaling. Mod provides increment, framework increases scale by increment until it hits new target, every tenth of a second.
§ Actor releasing. The script needs to dump actors if no mods are acting on that actor.
§ 10 actor slots
§ 5 mod slots per actor

Planned Features:
§ Separate vaginal/anal scaling, they get added anyway but I thought it might help with the next planned feature:
§ Solid vs liquid support! Solid things usually aren’t taking up quite the volume they occupy, or at least have the ability to saturate with some of the liquids, so telling the difference gives more realism.
§ Reduced scaling as volume increases, basically more realistic volume. (Like SGO)
§ Information output: Send events when you bump into the user-defined scaling limit, (or its multiples) and have mods do something about it! (Or hurt you inside, if that’s your thing.)

The future plans are ambitious, but something that just does the arithmetic for a few mods shouldn’t be more than I can handle.

If anyone knows how to .esm a mod, please let me know! Save me some trouble in explaining to other people how to send a mod event to bframe. Also saves me figuring out how to send actors in a mod event.


You've done a lot for me LL, and I'd like to return the favor.

EDIT: Oh crap, I cut the information I listed off before the feature list, then shut down the computer. Damnit.
Any questions, just ask. That info was important but I can't re!ember what it is. Or why.

Oh! Right! Project status. I'd say 33% to initial release. Esp mod, currently. I have mod identification, mod access (With events, which doesn't work because actors can't go through SKSE sendmodevent, so someone help me ESM this file or I'll force devs to use strings to transfer actor refs) No scaling though, because that's easy, and all these bottom layers are built to hold it up. Also, aliases are giving me trouble (but I'm replicating the Hentai Pregnancy system, so I could just need an update.) Also, basic MCM is working. Advantage to HPreg aliases is listing inflated actors in the mcm, for debug. Also fewer scripts (because no magic effect).
Yeah, that about covers it.

[arkanae]

Really cool! We need a framework like this!

Imagine a Skyrim where sex, pregnancy and slavery could be handled through easy-to-use frameworks... The first one exists thanks to Ashal, the last one might come out of Heromaster's work on APPS, and... you are building the second!

 

I suppose that your objective, ideally, would be to have all the pregnancy / infkation mods (FHU, BF, EC, SGO...) to use this framework?

If this is your intention, make sure you ask both Srende and Milzschnitte access to their sources for FHU and BF. That will help you figure out what they are doing, how they are doing it, and the best way to ensure compatibility.

Even though I haven't done much Skyrim modding, I think I can help with the scripting if you are willing to put up with my inexperience...

[4onen]

I don't know if I broke something, but the .psc files for their scripts were already included in the downloads for HPreg, SGO and FHU. I've been referring to all three while building my stuff, but HPreg is the easiest for me because almost a year back I tried writing a cum-inflation mod based on it. Failed, but that's not the point.

As for compatibility, theoretically I'm going for simple plug in for people who have existing mods, and the advanced features for those who write in the future. Basically, it won't be backwards compatible (because that would require overwriting NiNode scaling scripts and... ew.) but it will be easy to implement into existing things, and I'll make patches for things that don't have an updater anymore.

Patching should be easy, assuming I finish the framework in the first place.

tl;dr: The source is already there. I'm making it as easy for modders as possible (provide actor, provide amount to add to actor, provide increment if you want gradual filling.)

 

And ESMs! Need to make one, for the ease of compatibility I'm talking about.

 

EDIT: Ofc I didn't break something, the file was a part of the archive.

[fredricton]

I'm using Hookmmerse http://www.nexusmods.com/skyrim/mods/55869/? to handle stuff. Yes it does overwrite all the scripts, but it works rather well and does not need any handling on the side of other modders. Just waiting on a version to work with latest JContainers.

 

What your are attempting is the ideal solution, it needs all the other mod authors to be on board. Idealy I'd like to see something like this placed into Racemenu. It's something alot of people use so it's not another esp people have to load. Also it's racemenu that seems to be one of the worst offenders for hogging control of nodes so it would be nice if it would just play nice and have some kind of API function for modders to control that stuff.

[4onen]

I would disagree that it's ideal (it is, after all, being written by a first-point-two time modder.) It's just better than what we have now, and that's my goal. It's the Hentai Pregnancy to the Faites Des Baibes (or however that's spelled.)

If I can improve on what we have, make a solid wide®-support base on which to build higher, my job is done.

 

It would be nice if everything could work together, but Skyrim wasn't built with modding as the primary goal, so the engine can't support this behavior on its own.

(Also wasn't built with any internal organs other than the circulatory system, or external orifices except the mouth and nostrils. We fixed that. )

 

EDIT: Also, just to mention, I've been working on it about a week and a half, so that should give you a due date estimate.

[WaxenFigure]

TESVEdit is used to ESMify a mod. Open the mod in TESVEdit and expand the mod (left pane) so you can see and select the "File Header". In the right pane you'll see a "Record Header" object with a "Record Flags" entry under it (probably empty), select that "Record Flags" entry and right click on the blank data area then select "Edit" from the popup menu.

 

You will probably get a warning about editing a mod at that point, and yes you do want to do it.

 

Then you will see a list of flags you can check or uncheck, check the "ESM" flag, exit TESVEdit saving the changes and you're done (except of course renaming the .ESP file to .ESM).

[4onen]

So I do have to get TESVEdit setup. Okay, I'll do that, ESMify it and swap over to function inputs sometime this weekend.

 

Also, messed up aliases somewhere, so I'm probably going to have to take apart the main thread quest and put it back together. +4 days on development time, give or take.

 

Thanks Waxen!

 

EDIT: Aliases reassembled, they're now properly filling into the property slots on both the quest and the script. Also managed to combine the MCM menu quest into the main one, for efficiency's sake. Moving back onto the initial release feature track.

[FeebleFlies]

The new version of Racemenu might be interesting.

You can find there in the changelog:

 

Added extensive node transformation framework to NiOverride

 

http://www.nexusmods.com/skyrim/mods/29624/?tab=12&navtag=http%3A%2F%2Fwww.nexusmods.com%2Fskyrim%2Fajax%2Fmodchangelog%2F%3Fid%3D29624%26v%3D&pUp=1

 

All Problems solved?

[4onen]

The new version of Racemenu might be interesting.

You can find there in the changelog:

 

Added extensive node transformation framework to NiOverride

 

http://www.nexusmods.com/skyrim/mods/29624/?tab=12&navtag=http%3A%2F%2Fwww.nexusmods.com%2Fskyrim%2Fajax%2Fmodchangelog%2F%3Fid%3D29624%26v%3D&pUp=1

 

All Problems solved?

I can see that in the changelog for Racemenu and NiOverride, but I can't find any documentation on what it is.

If it's what it sounds like, then yes. Otherwise, I'll still be plugging away at my little thing.

(Also, just broke MCM menus. Damnit. Starting this just before midterm study week was a bad idea, now I'm jittery and can't Skyrim straight.)

 

If anyone wants the mod in its current (completely nonfunctional and really won't do anything at all except maybe crash) state, I'm happy to PM it to them. 

[4onen]

Mod is not dead! I've made a lot of progress, and I'm still looking at a November/December initial release. Apart from male/female checks and options, I'll be spending that time essentially making a "matchmaker"esque debug tool: a couple spells for just applying simple inflation to and removing it from npcs.

Also the gradual inflation/deflation is a bit finicky. Need the debug tool done to really test that.

[4onen]

Finally got a testing spell set working, and discovered that the mod doesn't save actor references properly.

Or cause inflation, for that matter.

Or compare actor references with any value but false.

F***ing papyrus.

 

This is going to be a significant delay. Hopefully I can figure this all out.

Failing that, I can give this mostly completed code to some more competent mod author who can find my little mistakes.

Anyway, back to work.

 

 

Best part of Skyrim though? You don't have to rebuild ESMs for updates to .pex files.

[4onen]

I've done it: The base mod can now set and remove inflation managed by up to five mods (per actor, not in general!) on up to twenty actors.

And remove said inflation.

And generally fuck around.

I can even dump an actor mid-inflation (during the gradual-animation thing that worked out terribly) without the system breaking.

 

However, it has no events. It can't tell mods when the inflation reaches the user set limit, or any other insanity levels.

Or tell mods when they're forcibly removed by an actor dump (in the case of one of my testing spells)

 

My question is this: Mod Authors, do you want to use it in this state or wait until I have events (*cough* and better threading for the filling animation *cough*) working?

It's actually surprisingly fast as it is, so you authors could use it as a compatibility layer with your existing code (just a new dependency and a new function instead of the NiNode script).

Or you could be waiting for something that alerts you when actor node inflation goes over thirty, in which case go ahead and say "Fuck you, I need XYZ feature"

 

So: modders, request away.

[dweezer]

I have to ask: are you going to also include support for other nodes like breasts, butt, and penis? It'd be nice to unify the various systems together. My other question is, when I do a another rewrite for the Macromancy spells (which will be a complete cut-over to Body Scale Randomizer and expand on that), do I need to include your variable names when reading/writing/modifying values?

[4onen]

I have to ask: are you going to also include support for other nodes like breasts, butt, and penis? It'd be nice to unify the various systems together. My other question is, when I do a another rewrite for the Macromancy spells (which will be a complete cut-over to Body Scale Randomizer and expand on that), do I need to include your variable names when reading/writing/modifying values?

For the way my setup is designed right now, adding new nodes would just be a change to the alias script and an addition of a new access function to the main script. To unify ALL node modifications isn't possible with the thing I built, the way I built it, unless I add a function for every node.

As for the Macromancy spells (which I just browsed through quickly) I think the only node that would actually require changing to grow/shrink an entire actor would be the root npc node (correct me if I'm wrong) which I don't touch.

As for randomization of nodes, if you're randomizing every node then my framework will just bulldoze over the randomly set belly size on every new game session, but reloading a save with the random belly size previously set won't reload that actor's 3D (necessarily) and will leave the node unchanged, which makes for interesting inconsistencies between saving/loading.

 

I actually don't have a single variable for you to include on an actor when reading/writing/modifying values, so to affect that node permanently, you'd have to go through my framework, which would slow you down a lot (and wouldn't necessarily be compatible with all things) so it's best at the moment to ignore my (shit) framework and just bulldoze in your values.

(Especially considering nobody supports my framework anyway)

 

Important note to everyone! My framework uses the Hentai Pregnancy actor storage system (yeah, I know, I'm behind the fucking times.) so it only supports 20 different actors with 5 mods per managed actor. In shorter terms, that means changing the size of everyone you bump into on the street is better left to manually changing the node, then giving up and letting my (awful) framework bulldoze it.

 

 

TL;DR: My framework is shit. I'm going to rewrite it next year. But I'll also release this thing for you modders to toy with.

So, modders, I don't have time to write documentation so I'm throwing this out for you to look through the scripts of. If I wrote it well at all, the things you modders actually access should be at the bottom of BFrameMainThread.psc:

 

int function fillSimple(Actor ac, string modIdent, float amount, float increment) ;Function to use with an actor that needs a bigger paunch. Returns an ID number (Array index) for referencing the actor in the framework.

int function fillSimpleByID(int ID, string modIdent, float amount, float increment) ;Works, is faster, but doesn't check if the ID is still valid. Whoops.

int function releaseActor(Actor ac, string modIdent) ;Function to release an actor from your mod in the framework. Also dumps the actor from the framework if it's the last mod acting on it.

function releaseActorByID(int ID, string modIdent) ;Outdated but working and theoretically faster. Causes problems if the ID is invalid, and also doesn't print to log because outdatedness.

 

There are only three scripts in the actual framework, so should be simple-ish to figure out. Passing an empty string as modident won't work for inflation, and will remove from ALL mods for release. If you want an actor to change size, just run fillSimple again with a new value.

Also, sorry, the framework currently steals your script's thread for its processing, and won't return it until after inflation animations complete. Soz.

 

Anyway, the mod, in all its glory: Attached

And the testing thing, in all its mismatched bad aim: Attached

 

Another note: In the framework there is a o4_bframe.esp and a o4_bframeESM.esm. I figured the esp would be useful if someone better and faster wanted to take over the framework. For writing your mods, though, master the esm.

Framework.7z

Spells.7z

[Trykz]

You don't need anything to convert an esp to an esm.

 

After you create the esp in the CK (or whatever you used to create it), just change the file extension from .esp to .esm, then load it into the CK as an active plugin and save it. Done.

 

Trykz

[4onen]

Really? That would make things easier. I'll have to try it.

[kepler78]

For the one who talk about Slavery... I found this mod very cool ! http://www.loverslab.com/topic/37048-wip-paradise-halls-sexlab-extension-v01f-141006/

 

APP is compatible ?

[4onen]

By APP I assume you mean either Aggressive Player Prostitution or the APPS framework for mod install/initialization/uninstall.

Bframe should be compatible with both of those, but doesn't make use of either's features. (Which may change, I dunno. I need to do more research into APPS.)

[Groovtama]

Function SetNodeScaleEX(Actor akActor, bool isFemale, string nodeName, float value, string modkey)
If value != 1.0
NiOverride.AddNodeTransformScale(akActor, false, isFemale, nodeName, modkey, value)
NiOverride.AddNodeTransformScale(akActor, true, isFemale, nodeName, modkey, value)
Else
NiOverride.RemoveNodeTransformScale(akActor, false, isFemale, nodeName, modkey)
NiOverride.RemoveNodeTransformScale(akActor, true, isFemale, nodeName, modkey)
Endif
NiOverride.UpdateNodeTransform(akActor, false, isFemale, nodeName)
NiOverride.UpdateNodeTransform(akActor, true, isFemale, nodeName)
EndFunction

Here that is the whole deal with NiOverride, you scale\remove something you update, everything is managed per keys, you just use a key that is unique. You don't need to load or save scales because they are presisent in the savegame and autoload and non overwriting, when you remove one key with the rest the new value will be build pretty simple.

 

(See the racemenuplugin or my scripts in the skeleton files for further references)

(Documentation of NiOverride is in the nioverride.psc)

[4onen]

Function SetNodeScaleEX(Actor akActor, bool isFemale, string nodeName, float value, string modkey)
If value != 1.0
NiOverride.AddNodeTransformScale(akActor, false, isFemale, nodeName, modkey, value)
NiOverride.AddNodeTransformScale(akActor, true, isFemale, nodeName, modkey, value)
Else
NiOverride.RemoveNodeTransformScale(akActor, false, isFemale, nodeName, modkey)
NiOverride.RemoveNodeTransformScale(akActor, true, isFemale, nodeName, modkey)
Endif
NiOverride.UpdateNodeTransform(akActor, false, isFemale, nodeName)
NiOverride.UpdateNodeTransform(akActor, true, isFemale, nodeName)
EndFunction

Here that is the whole deal with NiOverride, you scale\remove something you update, everything is managed per keys, you just use a key that is unique. You don't need to load or save scales because they are presisent in the savegame and autoload and non overwriting, when you remove one key with the rest the new value will be build pretty simple.

 

(See the racemenuplugin or my scripts in the skeleton files for further references)

(Documentation of NiOverride is in the nioverride.psc)

 

*drools*

Okay, that solves everything. My plugin is hereby really outdated. Everybody go use Groovtama's.

Seriously, don't touch my oudated crap. That stuff Groovtama has is amazing right there.

I'll have to look over his mod's documentation and code, but it sounds like he has everything I did but better. A lot better.

So yeah, use his stuff. Bye!

 

P.S. I'm not upset that someone did it better, more a bit relieved (because now the project is off my shoulders)

LL, keep doing all the awesome stuff you do. I'll just fade back into the lurkground. Ta!

[Groovtama]

That is expired's nioverride stuff, I just annoyed him to make it. That is also only a basic function without any logic.

Nioverride is just something that is easier for these task then netimmerse, a abstraction framework for all the scale\preg mods would still be necessary.

[4onen]

That is expired's nioverride stuff, I just annoyed him to make it. That is also only a basic function without any logic.

Nioverride is just something that is easier for these task then netimmerse, a abstraction framework for all the scale\preg mods would still be necessary.

The thing I was making was an abstraction layer over the NetImmerse script in SKSE, which is exactly what you built. I wasn't writing a preggers or FHU style mod.

And your/expired's framework does everything better... I think.

You guys sum the values, right? Or do some combination between the different mod keys... Or am I wrong?

If I am, I could either pick my project back up or try to make an add on for yours.

Either way, I can't tell what you do with the values, so you'll have to tell me just how out of my depth my mod is.

(And what I can do to help out)

 

tl;dr: Groovtama, does NiOverride sum the node transformations between different mod keys? If it doesn't, I'll try to write an add on for that. If it does, my little mod project is outdated.

 

Thanks!

[Groovtama]

Scales are multipled like the behaviour is exactly the same as you would add a bone to the skeleton and scale through it.

 

Skeleton scale = 1.1

Transform scale 1 = 2

Transform scale 2 = 4

Resulting scale after update for that bone would be 8.8

 

Summing would be, read the transform value from a key, add to the value, right the value back with the same key.

[Earen]

@4onen NiOverride doesn't animates node scale changes, so .. 

[Groovtama]

@4onen NiOverride doesn't animates node scale changes, so .. 

NetImmerse also doesn't do that.

 

But Nioverride is quicker in displaying new values.