OSex+ The Greatest Virtual Sex Ever

[Kinky]

 

In terms of height is that in relation to tiebreaker or are you noticing different height sometimes at start similar to what Migal has been looking into?

 

 

I dont think its about tiebreaker since it happens on both settings (1 and 2).

My Computer is probably slower then most others so i notice things lets say slow mo (even though it happens really fast. whole start takes about 3 seconds max).

From what ive seen is when 0sex starts sub gets about 3-4 inches higher before actors take their starting positions. Then on next try they are both proper height and are looking eye to eye.

Its no where near to what Migal had with his dwarf char but still noticable.

Anyway it happens at random and should be more failproof i think.

 

[CEO 0S]

No more sex sounds in D7. It looks like I'm supposed to pick a voice somehow, but there doesn't seem to be controls to change the character's profile.

 

Thanks and sorry for wasting time here, I made a packing mistake. Posting a new D7 now.

 

 

New Demo7 is up, very sorry for that, hopefully this works now.

 

The actra thing is a bug not going away related to my packing mistake. To confirm a random point: The actra magic effect naming jazz is there for now to confirm the spells exist and are being removed properly. I will be removing those entirely so they aren't clogging up menus once I feel OSA is totally stable. Helps for now to keep track on what's going on for errors.

[Kinky]

 

No more sex sounds in D7. It looks like I'm supposed to pick a voice somehow, but there doesn't seem to be controls to change the character's profile.

 

Thanks and sorry for wasting time here, I made a packing mistake. Posting a new D7 now.

 

 

Ehh and i just changed all xmls and inis Ok going to wait then. I didnt even notice sounds are missing.

 

 

Offtopic: while you wait people go grab Fix Lip Sync from nexus and pretty much all mods from that author. This guy is doing some Skyrim miracles for stability and other fixes.

 

[CEO 0S]

 

 

In terms of height is that in relation to tiebreaker or are you noticing different height sometimes at start similar to what Migal has been looking into?

 

 

I dont think its about tiebreaker since it happens on both settings (1 and 2).

My Computer is probably slower then most others so i notice things lets say slow mo (even though it happens really fast. whole start takes about 3 seconds max).

From what ive seen is when 0sex starts sub gets about 3-4 inches higher before actors take their starting positions. Then on next try they are both proper height and are looking eye to eye.

Its no where near to what Migal had with his dwarf char but still noticable.

Anyway it happens at random and should be more failproof i think.

 

 

 

Strange, to confirm there should be just one adjustment that occurs, they are just snapping to a different size at a maximum of once at start. Arrange will make them get resized again but if it just starts on it's own you're only seeing one click in the change of size? Does arranging set them to a proper height if you hit it twice (My guess is no)

 

It's mysterious Kinky. Something that might help figure this out is if you go to INFO > Actor > Natural Proportions and Current Proportions.

 

There's a field called oheight which is a number usually between 100-130. Natural is what the game measured them to originally be at, Current Proporitions is the oheight the scene forced them too.

 

I imagine if they are or are not scaled correctly the OHeight for "Current Proportions" will always output the same value 120~ish something.  My guess is that the natural Proportions oHeight will be different on times when it worked as opposed to times when it didn't. If it happens again can you see and compare the numbers from a properly scaled encounter to a non properly scaled encounter.

 

 

 

[Kinky]

 

 

My guess is that scalling gets interupted by positioning so end result isnt correct. (just feels like that)

I wil do tests you mentioned.

 

First look i see Rings still not in esg_english.ini this updated demo 7

 

Going to do testing in game.

 

[Kinky]

Ok here are the results:

 

1st sex start (player jessica is dom lydia is sub)

 

 

 

 

 

 

Actor:                                       Natural                                    Current

Jessica                                     114.216                                   123.834

Lydia                                        123.943                                   120.227

 

after arange once (roles changed):

 

 

 

 

 

 

Actor:                                       Natural                                     Current

Jessica                                     114.216                                   120.227

Lydia                                         123.943                                  123.834

 

i did lots of screenshots (did arange 2nd time, did another start where there was starting height issue) but here is already visible that something is wrong, and numbers even though they are perfect looking - they lie.

[zoneofdarkness]

The UI is trailing off the left side of the screen. Is there a setting for standard aspect ratio instead of widescreen?

[Kinky]

The UI is trailing off the left side of the screen. Is there a setting for standard aspect ratio instead of widescreen?

 

I have standard aspect ratio screen and you see what it looks like on image in my previous post.

What are your settings for resolution?

 

In skyrimprefs.ini i have this:

iSize H=768

iSize W=1024

 

[migal130]

 

 

Ok here are the results:

 

1st sex start (player jessica is dom lydia is sub)

 

 

 

 

 

 

Actor:                                       Natural                                    Current

Jessica                                     114.216                                   123.834

Lydia                                        123.943                                   120.227

 

after arange once (roles changed):

 

 

 

 

 

 

Actor:                                       Natural                                     Current

Jessica                                     114.216                                   120.227

Lydia                                         123.943                                  123.834

 

i did lots of screenshots (did arange 2nd time, did another start where there was starting height issue) but here is already visible that something is wrong, and numbers even though they are perfect looking - they lie.

This is precisely what I've been trying to explain. The actor is getting measured before the T-Pose is fully applied. Otherwise, this shouldn't be possible. It's lag of some kind, inside the animationevent catch. The measurement must be delayed, or actions taken upon the actor prior to measurement to guaranty proper measuring.

 

The screenshots I posted where my character appeared to be a dwarf compared to the target actor is not because my character shrank. It is because the target actor was sitting in a chair when I fired the scene. They were measured at half height, prior to the T-Pose being applied, and so the target actor doubled in size, becoming a giant. I tried it with a toon that was laying down, assuming it would cause more than a tripling (because we are only measuring on Z), but that just freezes 0S entirely. It's a significant issue.

 

Most of the time, if my character and the target actor are both standing when a scene is started, my results are exactly like what Kinky is showing here. I suspect this has to do with the target actor not being in a T-Pose during measurement and instead being on terrain where one foot is higher than the other. The skeleton Root is somewhere in between the two feet, higher than one foot but lower than the other (I realize the root is not physically connected to the feet, but it appears to respect terrain nonetheless). As a result, the character is measured a few game inches shorter than it really is.

 

I believe the measurement sometimes takes place prior to the T-Pose being applied to the actor, because of lag. It could be script lag, or simply the lag between the time the animation event is fired and the actor's skeleton completing the T-Pose positioning. If utility.wait(0.5) after the T-Pose animation event but before the measurement calculation fixes the issue, then it was the latter.

 

 

 

Looking at Kinky's numbers, it doesn't make sense. They suggest the measurements are performed consistently whether the scaling ends up correct or not. I'll do some more testing.

 

Edit: <snip useless exposition>

 

Edit2: CEO, check my reply to Kinky a few posts down. It includes screenshot support for my theory about the natural scale measurement failing because the T-Pose is not yet fully applied.

[TheNegativeMau]

Not working with modified apparence npcs and custom followers??

I' ve tried with many of then, but only work with uthgerd the unbroken (she's modified with Gce npcs Replacer), with clean and not clean save, on demo 6 and 7.

[migal130]

I get a different CTD on game load with this version. Not the same one I was getting sometimes in previous versions, which was related to dispelling.

 

[05/29/2016 - 08:38:07AM] WidgetError: [_oUI <0SA (08000D62)>]: WidgetLoadFailure

 

edit: Clean save upgrade. However, coc qasmoke works, so it's something about the save file. Didn't see any FNIS errors. I'll keep looking.

[Kinky]

I get a different CTD on game load with this version. Not the same one I was getting sometimes in previous versions, which was related to dispelling.

 

[05/29/2016 - 08:38:07AM] WidgetError: [_oUI <0SA (08000D62)>]: WidgetLoadFailure

 

edit: Clean save upgrade. However, coc qasmoke works, so it's something about the save file. Didn't see any FNIS errors. I'll keep looking.

 

I think you are getting famous FootIK error. Are you using Crash Fixes mod by meh321 from nexus?

 

Basicly no one knows why this error occurs coz it seems to be random. I also figured out that its something to do with saves. Seems like when you install lots of animations and then save the game that save has higher chance to get an error - this results in crash on load.

 

But what always works is if you first coc qasmoke and then load that save it will work fine.

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

 

CEO remember that collision issue and tcl that was always positioning actors correctly.

Yesterday i found this mod. Maybe it could help.

 

[migal130]

 

 

I get a different CTD on game load with this version. Not the same one I was getting sometimes in previous versions, which was related to dispelling.

 

[05/29/2016 - 08:38:07AM] WidgetError: [_oUI <0SA (08000D62)>]: WidgetLoadFailure

 

edit: Clean save upgrade. However, coc qasmoke works, so it's something about the save file. Didn't see any FNIS errors. I'll keep looking.

 

 

I think you are getting famous FootIK error. Are you using Crash Fixes mod by meh321 from nexus?

 

Basicly no one knows why this error occurs coz it seems to be random. I also figured out that its something to do with saves. Seems like when you install lots of animations and then save the game that save has higher chance to get an error - this results in crash.

 

But what always works is if you first coc qasmoke and then load that save it will work fine.

 

I uninstalled, new clean saved, FNIS'd, new saved, reinstalled, FNIS'd and now it works.

 

I'm pretty read up on meh321's foot IK error (aka the game load CTD I reported here last week). It also happens to SL users and there is a theory it has to do with dispelling on load, which would explain it also happening with 0S. It only happens once, though. It's like it has to fail the event register once and then it's okay. I don't get it, but that's why I was asking CEO about the requirement of dispelling on load instead of before the mod is closed.

 

Edit: CEO, if you're reading this, according to meh321, the Foot IK error is not actually caused by foot IK. That's just a message his crash fixes DLL throws when this particular type of load error occurs. There are theories as to the true cause. One is that it is an attempt to dispel a null. Another is that it has to do with re-registering animations. Still another is that it has to do with re-registering modevents. SL and 0S have the error in common.

 

*** Back to the scaling issue. I'm posting a couple screenshots to support my theory that the measurement sometimes takes place prior to the T-Pose being applied due to lag, even though the measurement comes after the T-Pose in the papyrus code. In these screenshots, the target actor was sitting, so 0S measured her natural size as 4' 3", when her actual height is 5' 10". In the left (Current Scale) image, note what 0S's scaling calculation did to her *body scale* to try to compensate.

[Kinky]

 

 

That little guy is straignt to the business

 

[migal130]

 

 

 

That little guy is straignt to the business

 

Inorite?

 

The thing is, he is normal scale. She is 1 and 1/3rd scale, because 0S thought her natural height was that of a child. The only explanation I can come up with is that she was measured while she was still sitting.

[Geist]

I've encountered an issue with the MFG Console when using this mod, or to be exact, the mouth does not move during activity. The expressions are still applied such as eyemovement and happy/sad, but the mouth does not move when making a sound or performing oral. I've uninstalled and reinstalled MFG Console and this mod and it still is not working.

 

Never mind, downloading the latest demo and overwritting when asked solved it.

[Kinky]

Looking at that screenshots i took. Seems like 1st time (sex start) Lydia was naturaly 1.83 meters tall (123,943 oheight), 2nd time her natural scale was 1.78m (120.341 oheight). Since its same actor its to expect same height values.

 

 

Developer demo looks interesting too:

 

 

 

 

 

[migal130]

Looking at that screenshots i took. Seems like 1st time (sex start) Lydia was naturaly 1.83 meters tall (123,943 oheight), 2nd time her natural scale was 1.78m (120.341 oheight). Since its same actor its to expect same height values.

Right, which proves the pre-scaling (natural height) measurement is not always the same, probably because the actor isn't in a T-Pose when measured. I suspect this slight variation may be due to terrain differences altering root to head measurement. If both feet are flat, on flat terrain, the mistake in measurement would be less severe (it would just be a miscalculation based on the standing idle pose the actor was using prior to attempting T-Pose; arched back, hip out, etc.). If the actor is standing on a terrain bump whereby one foot is lower than the root, the mistake would likely be more noticeable, depending on how radical the idle pose was. Although admittedly, the terrain may not come into play. Depending on the standing idle pack someone was using, the idles alone could be the entire problem – the standing version of the problem seen when starting with a sitting actor.

 

Try it on an actor sitting in a chair. You'll be delivering a giant's baby in no time.

[CEO 0S]

I notice the OSA basic module deomonstration got a bit of downloads if anyone is trying to make something and is stuck or whatever please just talk to me here before I have proper documentation. The questions would most likely help others and it would help me get the instructions organized in advance for documentation.

 

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

 

Thanks guys for all this help investigating this issue, and helping me gather data. I'm looking into it but still not much luck. I remembered one thing when reviewing my code which is that the oheight is only measured one time per session I believe, after that the game uses what it originally recorded. That could effect inaccurate numbers that seem correct but aren't for whatever is causing this.

 

Here' the actionscript part of the height measurement if it helps for reference:

 

var oheight (set when the actor sends their initial height data)

var modifiedOHeight

 

function snapOHeight(oheightValue){

modifiedOHeight = oheightValue

body.snapScale(calcOHeight(oheightValue, oheight))

actra.body.calculateWeight("current")

}

 

function calcOHeight(GoalOH:Number, NativeOH:Number){return ((GoalOH - NativeOH) / NativeOH) + 1.0}

 

function snapScale(scaleValue){

current = scaleValue

modified = true

skse.SendModEvent("0SAA"+actra.id+"_SnapSc", String(id), Number(scaleValue))

}

 

Not working with modified apparence npcs and custom followers??
I' ve tried with many of then, but only work with uthgerd the unbroken (she's modified with Gce npcs Replacer), with clean and not clean save, on demo 6 and 7.

What do you mean by not working? Nothing at all on key press?

[shadowuser0723]

i've been getting the same scale issues but they aren't as extreme as the ones mentioned above, the actors return to normal heigth after restarting the scene

[Kinky]

I had a situation where actor didnt revert to original scaling. Im going to test on sitting actor now to see if i can get extreme difference that migal was getting.

 

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

Sitting actors worked fine for me, sleeping one had some issues, first the scene wouldnt start then i presse e to talk with him and scene started but when i ended it my player was stuck in place, even tcl wouldnt move her.

 

Migal if im not mistaken this troubles started after the update where actor info (metric units and such) were introduced?

 

CEO can i disable sorttiebreaker and try to test with it set to 0?

[TheNegativeMau]

Yes, nothing happens. Press 0 on target, but don't iniciate the scene. 
[sorry my bad english XD]

[migal130]

Here' the actionscript part of the height measurement if it helps for reference:

 

 

 

var oheight (set when the actor sends their initial height data)

var modifiedOHeight

 

function snapOHeight(oheightValue){

modifiedOHeight = oheightValue

body.snapScale(calcOHeight(oheightValue, oheight))

actra.body.calculateWeight("current")

}

 

function calcOHeight(GoalOH:Number, NativeOH:Number){return ((GoalOH - NativeOH) / NativeOH) + 1.0}

 

function snapScale(scaleValue){

current = scaleValue

modified = true

skse.SendModEvent("0SAA"+actra.id+"_SnapSc", String(id), Number(scaleValue))

}

 

 

I have zero experience with Actionscript, but this still helps. It looks enough like other languages that I can understand what is happening and it confirms what I was thinking.

 

You are calculating a new height based on oheight, which is sent from Papyrus. It doesn't matter how well the Actionsript calculation works if oheight is wrong because the actor wasn't really in a T-Pose when it was measured.

 

It would be more certain to calculate the correct scale using Papyrus' GetScale() combined with each race's height. Unfortunately, it couldn't take into account custom races. AFAIK, there are no SKSE functions to query race form characteristics.

 

I would fix this if I could figure out how to compile your papyrus scripts, but I get all kinds of missing file errors. Not sure I understand that, because I have all the files required to run the mod. I need to get the scaling issue resolved in order to take advantage of the API. I'm also going to need to figure out how to avoid the freeze when 0S is started on an actor laying down.

[Kinky]

Did another test and i can confirm that player freezes if trying to start 0sex on sleeping actor. Similar to chicken issue.

Crosshair dissapears and nothing you can do except reload. Interesting thing is even after reload i didnt have my crosshair.

Guess i was just lucky in my previous test where it started after i pressed e to talk to person in bed.

Big question is when this troubles started or what was changed that made things not work? So far everything is pointing to height calculations (or order of things) so some changes there are probably what created this issues.

[migal130]

Big question is when this troubles started or what was changed that made things not work? So far everything is pointing to height calculations (or order of things) so some changes there are probably what created this issues.

If I remember correctly, 1.6 worked on a sleeping NPC. It may be more than just the scaling issue when it comes to sleeping toons. 1.6 may have done something else to the actor prior to the T-Pose spam, which would be similar to one of my posted fix suggestions. Assuming my theory about the T-Pose not being applied before measurement is true, if it just so happens that the actor's head and root nodes are equal on the Z-axis during sleep (a reasonable possibility), the current Actionscript calculation would produce a divide by zero error, which should crash or freeze the Actionscript program.