Jump to content

Recommended Posts

 

I was sitting trying to figure out what HFB is, then it clicked, fighter body. I personally use the normal body e cup. I'm sure the users of HFB would b appreciate it though.

HFB is not fighter type. The F stands for Fantasy, not Fighter. The whole point of HFB pregnant bodies is that it is a better pregnant variant (than HGECP bodies) for general HGEC compatible bodies. Basically, HFB is a somewhat skinnier version of HGEC, so 'pregnant' HFB kind of loses its point, in a manner of speaking. But on the other hand, this makes HFBPs a better alternative for many people including those do not have particular interests in HFB itself.

 

 

Well, i just would say the three trimesters are better spaced, with many of the alternatives already HUGE at first trimester. And as you said, it is pretty much compatible with HGEC E (and LL bottom, although the arse is a little bigger, which is fine during pregnancy ;) Considering first trimester is almost never visible, that is quite realistic. 

 

I am not good (yet) creating bodies from scratch, but if we had a good medium between the HGECPreg and HFB, i would be all for that. 

Link to comment
  • 4 weeks later...

I'm not aware of an existing blockhead TamagoSetbodyReboot conversion, so I started project page for one. There is a working proof-of-concept of TSR using shadeMe's Blockhead beta.  To demonstrate the priority system it has, there is also a converted PlayerClothingReplacer as well. You can play with the priority variables in the ini files to have either the player show pregnant or player-only meshes when a conflict occurs.
The main conversion being the dropping of the action queue in favor of blockhead overriding the model on a per-npc basis.  It definitely needs some testing and will probably have issues being a straight conversion.  That, and I don't know what 85% of TSR is doing.
 
Mesh Extended Swap System (MESS)
 
This also cleans up that silly pregnant meshes on non-preggos issue that kept bothering me.  As side note, the actual reason for trying this was to have TamagoSetbodyReboot and PlayerClothingReplacer play together.  That way when the player character is pregnant it shows, but otherwise shows custom meshes when available.

Link to comment

RE: tsbrFnOnLoadGameCleanUp

I was attempting to do a test in the MESS version to see if something like this function needed to be done.  Making sure the beta blockhead does what it's supposed to.  I ran into what could be bug in the original TSBR.  During the first load, the MESS version of arEventRegistered gets set as a stringmap with key=svkey (string) and value=iHandlerID (int).  Printing out shows everything to be as it should.  However, on second load without restart, tsbrFnOnLoadGameCleanUp is triggered and arEventRegistered is the existing array from the save file: an array with key=index (int) and value=rCurrActor (ref).  Is this right?  From what you told me, my understanding is this function is trying to unregister load #1 events using arEventRegistered.  I've semi-verified this with the original as well by inserting PlayerRef right after initialization.  It doesn't show up on the cleanup loop.  I did not verify it's registration status, however.  I believe there are quite a few checks so if an errant actor gets triggered it gets caught and unregistered.

 

Edit:

In the ForceEquip script, I don't get why the armors need to be destroyed then recreated.  What are the side effects if I just unequip->equip in one frame to trigger the OnActorEquip event?  The comments really didn't mention the reason for it.

 

Sorry for having so many questions. 

Link to comment

>> I've semi-verified this with the original as well by inserting PlayerRef right after initialization. It doesn't show up on the cleanup loop.

 

I thought it's running fine, but it could be my delusion. Are you certain the cleaner script actually runs after load? If you're ok, would you try the same with different code? With Get/SetModLocalData stringmap instead of an array (so the formor array must be removed). This might have been my ovesight.

Well.... what's the point of OnLoadGame event if it runs after loaded...

 

>> I don't get why the armors need to be destroyed then recreated.

 

Armors have own health value and they can stack. You can have multiple pieces of the same armor yet they're all different. You never know which one that equipItem will choose. That's why you need to specify inventory reference.

As to why it had to be "destroyed and recreated" instead of just remember the stats and discover it again in the next frame... probably because it worked better. Invref functions are very unreliable and lie all the time. But I guess you could try improving it if you feel lucky. I think I remember it went south when I tried that, but it was long, very long time ago even before tamago setbody reboot.

Link to comment

Testing these things was a pain after my Oblivion install became unstable and was resulting in inconsistent behavior.  After some hair-pulling and trying a bunch of things, I almost called it quits with this game (again).  Decided to go back to a much earlier backup, and it's all better now.  I did do some better testing and have some results:
Loaded save with pregnant NPCs (#1).  Knocked up a different NPC and had a couple births, then saved(#2).  Restarted.  Loaded save #2 followed by save #1.  The new NPC from #2 was NOT unregistered with OBSE AND was still triggering TSBR events even though she was not pregnant in save #1.
Added Get/SetModLocalData along side the existing arEventRegistered array.  Printing out both does show the ModLocalData method having the desired results and existing does not.  The NPCs that are in play are unregistered and no longer triggering events after loading another save.
My current version only adds the ModLocalData commands without messing with the arEventRegistered array.  It adds an iterator variable to the cleanup function.  Would these modifications prevent the necessity of a clean save?  Even if we had to clean save, what would be lost? the SpermOverrides?

 

I think the cs wiki hints that GetGameRestarted is the time to use the GetModLocalData function to undo OBSE changes from the previous instance.  So I imagine the LoadGame event is similar: serves as opportunity to use these functions to facilitate unregistering events. :s

 

>>;Ok, this is truly a fine piece of crap. Armors should be handled a bit differently.

OOHHHHHHHHH...This comment makes so much more sense now.  Well, I'm leaning towards taking a shortcut since I did proclaim "no more action-queue".  I don't want that to be some campaign promise.  What do you think the chances are of re-equipping an already equipped item that it stays the same AND will trigger an OnActorEquip event.  That's all I need: the OnActorEquip event (or least the blockhead equivalent, anyway).

 

>>you could try improving it if you feel lucky

I'm nowhere close to improving this thing. In fact, I'm still trying to figure out how it works.

 

 

Link to comment

Looks like I have to update Tamago setbody very soon. Thanks for reporting and testing. I had something else to fix as well, I just forgot to do it.

 

I think GetGameRestarted is where you do not need to use GetSetModLocalData functions. Because you're supposed to have restarted the game and thusly there's no local data at that point... And if OnLoadGame will fire after the save game is loaded, why not just make the code run just along with any other initialization codes in the main quest? Seems like this OnLoadGame event is redundant and only have very specific and limited uses. Such as... when you don't want to have a quest running at all but want to initialize the mod on load anyway. Though I don't see any point in doing that.

 

Anyways,  I guess you can forget about the local data functions and cleaning up... I told you that you can also remove the arEventRegistered array entirely from your fork, but I see that you're using that array for a different purpose (to store Blockhead event ID).

Link to comment

I think it was in the OBSE doc that I saw it. It was getgamerestarted==0 (i.e. a previous save was loaded) then use the getmodlocaldata.  Something like that.

I did want to verify the tests since I did float the possibility but didn't have confirmation for sure.  I needed a basis to compare to the blockhead version.  I forgot to mention that it does do as advertised and event registration does not persist between saves.  It was a non-MESS version I was referring to in my previous post.  I did delete the function completely from the MESS version.  I really do have too many versions of mods going on right now...

Link to comment
  • 4 weeks later...
  • 2 weeks later...
  • 3 weeks later...

I have a question, and maybe this will be a dead end. While the autosetbody.ini allows you to assign different body styles per race, it does not appear to change that of the player, which would be appreciated. Allow me to explain.

 

I went into the Setbody.ini file and under the General settings, and enabled the AutoSetBody system to function by setting its bEnableAutoSetBody to 1

 

After that, I went into the AutoSetBody.ini and went straight down to the Custom Races portion of the file.

 

The first line for race 00, I set to Orc as a test, using this:

set aaaAutoSetBodyQuest.Race00 to sv_Construct "Orc"

 

And then I went to the Race 00 Body Styles portion, and altered the top and bottom sv_Construct lines to read like this:

set aaaAutoSetBodyIni.iBody1 to sv_Construct "HGECBUEF"

set aaaAutoSetBodyIni.iBody2 to sv_Construct "HGECBF"

 

 

All the orc females had the same figure but mine. But, it might have been just me not seeing it, so I changed the upper body section to this:

set aaaAutoSetBodyIni.iBody1 to sv_Construct "HGECEXC6"

 

That's a fun one. I use that for Khajiits so they are more feline with 6 breasts. But with that, I get bouncy 6-breasted orc women, except the one I tried playing with. Yes, my orc was stuck with two stock-form breasts while the others had half a dozen each.

 

Now it was suggested that the SetBodySelf skill would be satisfactory enough. But no. NPCs under the influence of the AutoSetBody function returned to the body style I defined in the .ini after their pregnancy. But if any actor was given a body via a spell (SetBody / SetBodySelf), their body would revert to the stock body and not the body previously defined by the spelll.

 

So, I am inquiring if there is a way to make a player subject to the body style defined in the autosetbody.ini?

Link to comment
  • 3 weeks later...

set tsbrMain.iState to 110
set tsbrMain.svBody to sv_Construct "HPREG3E"
SetStage tsbrMain 10

set tsbrMain.iState to 120
set tsbrMain.svBody to sv_Construct "PBodyX2"
SetStage tsbrMain 10

set tsbrMain.iState to 130
set tsbrMain.svBody to sv_Construct "THPREG3"
SetStage tsbrMain 10

set tsbrMain.iState to 140
set tsbrMain.svBody to sv_Construct "THPREG3"
SetStage tsbrMain 10

set tsbrMain.iState to 150  ;150 and 151 are equally treated.
set tsbrMain.svBody to sv_Construct "CC"
SetStage tsbrMain 10

These setting allow for setting custom prego mesh? What type of body should I use to be in match DMRA? First trimester body HPREG3E don't match DMRA it makes look player boddy shrinked minus the belly bump.

Link to comment

There is no DMRA preg-body in set body reloaded

 

The body codes, see the Tamago Set body: Body_Style_Code.txt  and Body_Style_Code.txt

HPREG3E : Pregnant E-Cup (HGEC)

 

PBodyX2 : Pregnant 2nd Trimester

 

THPREG3 : Pregnant 3 (THEC)

 

CC : Curvaceous Chubby

 

All pregnant meshes are in Characters\Bomshell\HGEC\Pregnant

 

The best for DMRA are the THEC ( H cup with Round ass )

THPREG1 : Pregnant 1 (THEC)
THPREG2 : Pregnant 2 (THEC)
THPREG3 : Pregnant 3 (THEC)

 

All in the Body_Style_Code.txt

;Pregnant
PBodyX1 : Pregnant 1st Trimester
PBodyX2 : Pregnant 2nd Trimester
PBodyX3 : Pregnant 3rd Trimester
HPREG : Pregnant (HGEC)
HPREG2D : Pregnant D-Cup (HGEC)
HPREG3E : Pregnant E-Cup (HGEC)
THPREG1 : Pregnant 1 (THEC)
THPREG2 : Pregnant 2 (THEC)
THPREG3 : Pregnant 3 (THEC)
HFBPE1 : Pregnant 1 E-Cup (HFB)
HFBPH1 : Pregnant 1 H-Cup (HFB)
|HFBPL1 : Pregnant 1 Lowerbody (HFB)

...................................................................................

So the tamago set body ini should be

 

set tsbrMain.iState to 110
set tsbrMain.svBody to sv_Construct "THPREG1"
SetStage tsbrMain 10

set tsbrMain.iState to 120
set tsbrMain.svBody to sv_Construct "THPREG2"
SetStage tsbrMain 10

set tsbrMain.iState to 130
set tsbrMain.svBody to sv_Construct "THPREG3"
SetStage tsbrMain 10

set tsbrMain.iState to 140
set tsbrMain.svBody to sv_Construct "THPREG3"
SetStage tsbrMain 10

set tsbrMain.iState to 150 ;150 and 151 are equally treated.
set tsbrMain.svBody to sv_Construct "CC"     !!! here I would add the normal DMRA body. But I don't know how to add upper AND lower body!!!
SetStage tsbrMain 10

..........................................................

The DMRA body codes. But there are upper and lower body codes. I don't know how to add it in the Tamago set body  ini .

 

;DMRA Upper Body
|DMRABU : DMRA Original
|DMRABU3M : Triple Melons
|DMRABUBDM : Hirdamanapulus BDM
|DMRABUGUTS : DMRA GUTS
|DMRABUMANGA : Manga
|DMRABUMANGAK : Manga K-Cup    
|DMRABUHUGEDM : Huge Double-Melons    
|DMRABUMEGADM : Mega Double-Melons
|DMRABUCLS14 : Claudia's Little Secret 14
|DMRABUCLS17 : Claudia's Little Secret 17
|DMRABUNATURAL : Natural
|DMRABURAK : K-Cup Round Ass
|DMRABURAH : H-Cup Round Ass
|DMRABUSPB15 : Speedbuster 15 (Muki Muki)
|DMRABUSPB28A : Speedbuster 28 A (Double Melons)
|DMRABUSPB28B : Speedbuster 28 B (Double Melons)
|DMRABUTUNED : Tuned
;DMRA Lower Body
DMRAB : DMRA Original
DMRABTM : Triple Melons
DMRABGUTS : DMRA GUTS
DMRABMANGA : Manga
DMRABMANGAW : Manga Wide Hips
DMRABMEGADM : Mega Double-Melons
DMRABCLS14 : Claudia's Little Secret 14
DMRABSPB15 : Speedbuster 15 (Muki Muki)
DMRABSPB28 : Speedbuster 28 (Double Melons)

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

 

!!! I don't use SetBody reloaded... All I said is just guessed.

Link to comment
  • 4 weeks later...

i keep getting this in my obse log does anyone know why

 

Error in script 2a000801
Operator <- failed to evaluate to a valid result
    File: TamagoSetBody.esp Offset: 0x0087 Command: <unknown>

 

i keep getting this in my obse log does anyone know why

 

Error in script 2a000801
Operator <- failed to evaluate to a valid result
    File: TamagoSetBody.esp Offset: 0x0087 Command: <unknown>

 

 

i can change my body with the in game settings just fine 

Link to comment
  • 1 month later...

Basically.... BUMPING the inquiry.

 

I have a question, and maybe this will be a dead end. While the autosetbody.ini allows you to assign different body styles per race, it does not appear to change that of the player, which would be appreciated. Allow me to explain.

I went into the Setbody.ini file and under the General settings, and enabled the AutoSetBody system to function by setting its bEnableAutoSetBody to 1

After that, I went into the AutoSetBody.ini and went straight down to the Custom Races portion of the file.

The first line for race 00, I set to Orc as a test, using this:
set aaaAutoSetBodyQuest.Race00 to sv_Construct "Orc"

And then I went to the Race 00 Body Styles portion, and altered the top and bottom sv_Construct lines to read like this:
set aaaAutoSetBodyIni.iBody1 to sv_Construct "HGECBUEF"
set aaaAutoSetBodyIni.iBody2 to sv_Construct "HGECBF"


All the orc females had the same figure but mine. But, it might have been just me not seeing it, so I changed the upper body section to this:
set aaaAutoSetBodyIni.iBody1 to sv_Construct "HGECEXC6"

That's a fun one. I use that for Khajiits so they are more feline with 6 breasts. But with that, I get bouncy 6-breasted orc women, except the one I tried playing with. Yes, my orc was stuck with two stock-form breasts while the others had half a dozen each.

Now it was suggested that the SetBodySelf skill would be satisfactory enough. But no. NPCs under the influence of the AutoSetBody function returned to the body style I defined in the .ini after their pregnancy. But if any actor was given a body via a spell (SetBody / SetBodySelf), their body would revert to the stock body and not the body previously defined by the spelll.

So, I am inquiring if there is a way to make a player subject to the body style defined in the autosetbody.ini?

 

Link to comment
  • 1 month later...

When pregnant, you receive a replacement mesh when naked.   The nekkid pregnancy meshes will be within the.....

Data\Meshes\Characters\Bombshell\HGEC\Pregnant

.....folder.

 

I forgot where they store meshes for pregnancy clothing.... though there are pregnancy clothing mods out there

 

BUT, if you wish smaller or less noticeable pregnancy appearances, it is all in the meshes themselves.   The _1 _2 and _3 indicates the Trimester stages for each set.  It would be entertaining if someone knew how to 'edit' the meshes.  My Khajiits have multiple breasts and THAT would be a blast to see done right.

Link to comment
  • 2 weeks later...

 

ANY SETTINGS for this in game Oo? or is it just plug in an play (pun intended)

Not in game, but there's a pretty extensive ini that you can configure.

 

 

thats awesome :o btw question LOL how do i get the animations to line up correctly :o i installed everything you listed. but sometimes the monsters would

 

inetiate sex but then warp back a few steps and warp back in doing the animations or if im knocked down. would dry hump the air instead of MC

 

Link to comment

 

 

ANY SETTINGS for this in game Oo? or is it just plug in an play (pun intended)

Not in game, but there's a pretty extensive ini that you can configure.

 

 

thats awesome :o btw question LOL how do i get the animations to line up correctly :o i installed everything you listed. but sometimes the monsters would

 

inetiate sex but then warp back a few steps and warp back in doing the animations or if im knocked down. would dry hump the air instead of MC

 

 

From the LAPF thread:

 

http://www.loverslab.com/topic/21241-lapf/

 

Question: Help! Why don't my animations line up?

A) If you are on uneven ground, too close to another object (walls, stairs, chair and so on) it can screw up the alignment. If none of those are the issue then just hit the 1-4 or 9, 0 keys at the top of your keyboard to adjust the alignment while your PC is having sex. Any changes you make will be saved in your saved game. If you start a new game however, those changes are lost and you will have to adjust them again.

NOTE: You can only have one adjustment per animation. If you play with races that are taller or shorter than the default imperial race then animations could be off a bit.

 

If that doesn't help, many answers can be found here:

 

http://www.loverslab.com/forum/31-technical-support-lovers-with-pk/

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