OSex+ The Greatest Virtual Sex Ever

[pipdude]

Did I do this right?

 

ActionScript + Flash + Papyrus Scripts for the project. 

 

https://github.com/CE0/OSA-

 

Side note:

 

The way you are handling packages (directories of classes basically) isn't right.

 

In your Actionscript Settings, you really should only have two or three entries.

 

One for local scripts (ie scripts that are in the same directory as the fla).

One for the skyui folder.

And optionally one for your 0Sex scripts. These may be local to the fla already so this entry might not be needed.

 

Then, you should be putting the full path to each class in each class declaration.

 

So, instead of just:

class ActorBody
{
}

It should be:

class core.Actra.ActorBody
{
}

The folders (ie packages) should always be all lower case.

 

If you find that you are using a word repeatedly in a series of classes, it's a sign that they probably should be put into a new package. For example, instead of ActorXYZ.as and ActorABC.as you would make a folder called "actor" and put classes XYZ.as and ABC.as into it.

 

These are just best practices that help make things easier to follow and organize. But, adding a new actionscript setting for every new package you make is pretty unwieldy. Especially if you end up setting the environment up again somewhere.

[CEO 0S]

class core.Actra.ActorBody
{
}

 

Thanks I think I understand Pipdude,

 

the core.Actra.ActorBody is telling actionscript of a folder structure to find the files deeper in the core folder. In this case I'd only connect the publishing settings up to core and it would find the rest. Functionality would remain the same but I'd basically be simplifying the names so they are easier to identify?

 

That should be straight forward for me to adjust. Core could easily be shifted to a relative path to the directory since it represents the OMajor in code so that would be no problem if I'm understanding correctly.

 

Thanks for the headsup!

[Kinky]

Updated my previous post with results. As you can see its very random. Only issue being 0sex.

 

Hm. Unfortunately, I think that the next step is to clean up Skyrim itself to be sure that something isn't wrong with the install or errant files causing problems somewhere.

 

We have to get to a point where we have eliminated the possibilities of what is unique about your machine since it is apparently stable on the majority of installs.

 

 

If you mean cleaning masters then ive already done that and it crashes anyway. If you mean cleaning skyrim folder - Im using MO so its clean. Only thing that is new there are 2 reshade files and i already tried without them and crashed anyway.

 

What is unique about my machine comparing to for example CEO's is that i have papyrus logging enabled, but in those latest tests i used vanilla ini's where it is disabled. So even there there is no patern as to why it happens sometimes. So only thing that remains is my machine being weaker then most, but that doesnt explain why migal is getting same crashes on his machine that is lot stronger.

 

Also there are people popping up on nexus with same issues. What is common for all of us is this FootIk error that crash fixes mod catches.

[pipdude]

 

Hi Pip, 

 

NativeOHeight:

 

Actraga papyrus script gets the oheight's native value when it tposes them:

 

OHeight[1] = NetImmerse.GetRelativeNodePositionZ(Actra, "NPC Root [Root]", "NPC Head [Head]", false)

 

 

GoalOH:

 

the module.xml's modify value is the goalOheight and what the module developers wants the actors scale to be in scene. Example:

 

<modify cmd="oheight" actor="0" oheight="123.834412"/>

 

 

Output:

 

the math converts this into a proportionate scale for the root node bone of the actor:

 

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

 

(this is in core/actra/body/ActorScale.as)

 

As a simplified example if the actor's oheight = 100 and the module.xml wants it at 200.It will return 2.0 for the scale of the root bone and send that value to the snapSC function in actraga Papyrus to have the actor scaled up.

 

 

Thank you. That helps a lot.

 

(hate to be a nag about this again. But, this is an example where less creative and more boring descriptive variable names would make it easier for an outsider like me to understand without needing an explanation. ).

 

So, the goal of all of this is to A) get the size of the player character and size everyone else relative to that size based on a module's settings.

 

It looks like the formula to do that is right. So, in order to end up with results like Migal's screenshot, it seems like the GoalOH numbers would have to somehow be wrong. Either that, or the native number is changed at some point. But, my understanding is that the native number is only gathered once, correct?

 

I think I understand Pipdude,

the core.Actra.ActorBody is telling actionscript of a folder structure to find the files deeper in the core folder. In this case I'd only connect the publishing settings up to core and it would find the rest. Functionality would remain the same but I'd basically be simplifying the names so they are easier to identify?

 

 

Exactly.

 

There could be other benefits that I'm not thinking of. But, it's almost like having a breadcrumb menu so that a dev can understand better where they are at as they are digging through trying to find things.

[CEO 0S]

 

 

 

Thank you. That helps a lot.

 

(hate to be a nag about this again. But, this is an example where less creative and more boring descriptive variable names would make it easier for an outsider like me to understand without needing an explanation. ).

 

So, the goal of all of this is to A) get the size of the player character and size everyone else relative to that size based on a module's settings.

 

It looks like the formula to do that is right. So, in order to end up with results like Migal's screenshot, it seems like the GoalOH numbers would have to somehow be wrong. Either that, or the native number is changed at some point. But, my understanding is that the native number is only gathered once, correct?

 

 

Not relative to the pc, each actor is measured and scaled relative to their own native oheight and the modules desired oheight for the role they are assuming. As a bandaid now it's gathered everytime due to this bug we're facing ideally it should only be gathered once.

 

If their creation kit height (game scale) isn't 1.0 , for example .5 scale and they are visually appearing .5 then the first time they get measured the measurement is spot on for them telling them to be about twice as tall but it scales them to 4 times the amount. When the scene ends it sets them back to 1.0 but they are now visually appearing at 1 scale (when before they were visually at .5 scale) so from that point on the measurement works since I bandaided the script to measure everytime as opposed to just once to work around this.

 

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

 

Basically there's a point shortly after the scale adjustment occurs  (For an actor with a game scale of .5) that Papryus starts considering 1.0 scale a visual 1.0 as opposed to a visual .5

You can see a double snap in scale happening where the initial scale with the correct math by oheight sticks for a single frame, then creationkit scale gets disabled pushing them to twice their current size.

 

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

 

The issue is I can't proc this flatlining of scale before I do the measurement, but proof that it exists is the fact that setting an actor to 1.0 root bone scale before the scene does nothing but setting them to 1.0 root bone node at the end of the scene sets them to their value without considering creation kit height (in game scale)

 

a point .5 (game scale) actor is visually .5 scale before the scene at 1.0 root bone scale, but visually 1.0 scale after the scene at 1.0 root bone scale

[D_ManXX2]

 

Updated my previous post with results. As you can see its very random. Only issue being 0sex.

 

Hm. Unfortunately, I think that the next step is to clean up Skyrim itself to be sure that something isn't wrong with the install or errant files causing problems somewhere.

 

We have to get to a point where we have eliminated the possibilities of what is unique about your machine since it is apparently stable on the majority of installs.

 

 

If you mean cleaning masters then ive already done that and it crashes anyway. If you mean cleaning skyrim folder - Im using MO so its clean. Only thing that is new there are 2 reshade files and i already tried without them and crashed anyway.

 

What is unique about my machine comparing to for example CEO's is that i have papyrus logging enabled, but in those latest tests i used vanilla ini's where it is disabled. So even there there is no patern as to why it happens sometimes. So only thing that remains is my machine being weaker then most, but that doesnt explain why migal is getting same crashes on his machine that is lot stronger.

 

Also there are people popping up on nexus with same issues. What is common for all of us is this FootIk error that crash fixes mod catches.

 

 

I was wondering if you fixed the footIK problem ?? The only time i seem to be getting that bug is either when playing a female character or have female companion with me and have HDT loaded. if i disable the hdt dll file my save seem to be loading fine without the footIK ever happening. 

 

Are you using hdt by any chance ??

[pipdude]

 

If you mean cleaning masters then ive already done that and it crashes anyway. If you mean cleaning skyrim folder - Im using MO so its clean. Only thing that is new there are 2 reshade files and i already tried without them and crashed anyway.

 

What is unique about my machine comparing to for example CEO's is that i have papyrus logging enabled, but in those latest tests i used vanilla ini's where it is disabled. So even there there is no patern as to why it happens sometimes. So only thing that remains is my machine being weaker then most, but that doesnt explain why migal is getting same crashes on his machine that is lot stronger.

 

Also there are people popping up on nexus with same issues. What is common for all of us is this FootIk error that crash fixes mod catches.

 

 

There could be other areas that can be dirtied up in User folders, etc. See: http://wiki.step-project.com/Guide:Make_Skyrim_Vanilla_Again

 

Did this start happening after a specific update?

 

I'm not sure about FootIK. What is that? It seems like if that was the issue it would apply to myself, CE0 and others who are not getting the crash.

[CEO 0S]

 

 

 

I was wondering if you fixed the footIK problem ?? The only time i seem to be getting that bug is either when playing a female character or have female companion with me and have HDT loaded. if i disable the hdt dll file my save seem to be loading fine without the footIK ever happening. 

 

Are you using hdt by any chance ??

 

 

There's been a lot of comments relating to this being a female only skeleton thing, for example only female actors get tposed when the crash is about to occur. That's why I think it might be a netImmerse issue and if I manage to switch to Niovveride it might fix this. I know NiOverride has a flag for isFemale and I assume they have it there for a reason compared to the older netImmerse functions which did the same thing but didn't have that flag.

[pipdude]

 

If their creation kit height (game scale) isn't 1.0 , for example .5 scale and they are visually appearing .5 then the first time they get measured the measurement is spot on for them telling them to be about twice as tall but it scales them to 4 times the amount.

 

 

If the initial measurement of them is spot on, how can it result in scaling them incorrectly to 4 times the amount?

[CEO 0S]

 

 

 

I'm not sure about FootIK. What is that? It seems like if that was the issue it would apply to myself, CE0 and others who are not getting the crash.

 

 

It's not actually a FootIK think it's a crash report added in from meh32'sCrashFixes which is a pretty widely accepted dll for getting Skyrim to perform better. The crash occurs no matter if it's installed or not but if it is installed the FootIK error message shows up. Meh themselves said it has nothing to do with FootIK and they aren't sure what the cause is exactly but it's just classifying some kind of crash.

[pipdude]

 

There's been a lot of comments relating to this being a female only skeleton thing, for example only female actors get tposed when the crash is about to occur. That's why I think it might be a netImmerse issue and if I manage to switch to Niovveride it might fix this. I know NiOverride has a flag for isFemale and I assume they have it there for a reason compared to the older netImmerse functions which did the same thing but didn't have that flag.

 

 

I suspect that the isFemale flag is there more for performance reasons. NetImmerse probably checks for that itself every time.

 

That said, I think it would be very worthwhile (and shouldn't be too painful) to switch to NiOverride.

[Kinky]

 

I was wondering if you fixed the footIK problem ?? The only time i seem to be getting that bug is either when playing a female character or have female companion with me and have HDT loaded. if i disable the hdt dll file my save seem to be loading fine without the footIK ever happening. 

 

Are you using hdt by any chance ??

 

 

I am using HDT but even without HDT game still crashed for me. But i am playing female character and have female follower.

And thinking about that more when T-pose happens it only happens on female characters... this could be some lead.

 

 

There could be other areas that can be dirtied up in User folders, etc. See: http://wiki.step-project.com/Guide:Make_Skyrim_Vanilla_Again

 

Did this start happening after a specific update?

 

I'm not sure about FootIK. What is that? It seems like if that was the issue it would apply to myself, CE0 and others who are not getting the crash.

 

 

T-pose error started after demo 7. FootIk error was happening before but i cant really say at what point since i was mostly testing things on same save (dragonsreach entrance) and that save seems to be immune to FootIk error.

 

I cant really explain FootIk error, if i could it would be solved by now.

Its just a popup message that comes from mod "crash fixes" by meh321. Acording to meh321 its not really FootIk error but it shows there so he just made that popup to show when it happens instead of directly ctding the game.

I found a way to bypass it by going to coc qasmoke before loading my main save and that prevents it from happening.

 

I will check that link you posted.

[CEO 0S]

 

 

If their creation kit height (game scale) isn't 1.0 , for example .5 scale and they are visually appearing .5 then the first time they get measured the measurement is spot on for them telling them to be about twice as tall but it scales them to 4 times the amount.

 

 

If the initial measurement of them is spot on, how can it result in scaling them incorrectly to 4 times the amount?

 

 

That's the hearth of the problem that we're stuck on.

 

There is some magic in how the game gives priority to creation kit height scale. Migal found some documentation on it where it's only considered at first but eventually things happen where the actor gets a definitive scale (That was made partially as a result of their creation kit scale) which it uses from that point on in the session to calculate their scale based off a number of things. I believe it's some kind of bandaid beth did to address furniture scaling of actors to work around the race + height double scaling they use.

 

That's why I believe you see the double click and that's why I think 1.0 root bone outputs different results after the scene. There's something that happens shortly after I set the scale of the actors that disables this flag I mention above. So while they are correct for a frame which you can see once it does further calculations the flag gets turned off and their definitive scale is made which stops taking scaling into consideration. The oheight calculation would have asked to make a .5 scale actor 2x root bone scale so when they snap to 1 visual scale (They become 2x scale due to their scale flag being disabled doubling their size from .5) they still have a 2x root bone scale stuck to them and become 4x size. 

 

At conclusion their scale flag is disabled so setting their root bone to 1.0 makes them 1.0 visually and measurements can work from that point.

[pipdude]

 

 

 

 

If the initial measurement of them is spot on, how can it result in scaling them incorrectly to 4 times the amount?

 

 

That's the hearth of the problem that we're stuck on.

 

There is some magic in how the game gives priority to creation kit height scale. Migal found some documentation on it where it's only considered at first but eventually things happen where the actor gets a definitive scale (That was made partially as a result of their creation kit scale) which it uses from that point on in the session to calculate their scale based off a number of things. I believe it's some kind of bandaid beth did to address furniture scaling of actors to work around the race + height double scaling they use.

 

That's why I believe you see the double click and that's why I think 1.0 root bone outputs different results after the scene. There's something that happens shortly after I set the scale of the actors that disables this flag I mention above. So while they are correct for a frame which you can see once it does further calculations the flag gets turned off and their definitive scale is made which stops taking scaling into consideration. The oheight calculation would have asked to make a .5 scale actor 2x root bone scale so when they snap to 1 visual scale (They become 2x scale due to their scale flag being disabled doubling their size from .5) they still have a 2x root bone scale stuck to them and become 4x size. 

 

At conclusion their scale flag is disabled so setting their root bone to 1.0 makes them 1.0 visually and measurements can work from that point.

 

 

Have you tried replacing the setscale code to use the native SetScale instead of NetImmerse?

[CEO 0S]

 

 

 

Have you tried replacing the setscale code to use the native SetScale instead of NetImmerse?

 

 

It's in discussion, a lot of the preemptive OSex's prior to 1.07 were using just scale before i switched to Oheight and all of the solutions I came up with hit weird walls about scale. In most cases the actors would gets slightly taller everytime, it's due to the double values being used of race and height scales but only one is controllable in papyrus to affect both simultaneously.

 

An example is a 1.0 height 1.04 race character that you set to 1.05 scale becomes 1.05 (1.05) and they way the math works that's not the proportional increase you are looking for from papyrus. For me oheight came because I could never get scale to make the exact size actors I needed or I couldn't have it not do strange things post scene. Those values are saved with the game, so if root node leaves them slightly different size they will be reverted the next time the game loads them however in the scale case people's favorite OSex partners would slowly become larger and larger throughout the save.

 

This is just my impressions and Migal has done more studies on this and seems like he can get scale to reliably output but I'm still trying to figure it out.

 

I suspect that the isFemale flag is there more for performance reasons. NetImmerse probably checks for that itself every time.

 

Sounds like a good explanation but I think the fact that only females are tposed in the error reports is a hint still at the solution. The TPosing is somehow related to the crash or a harbringer at least that it's coming and while I have no idea how it could possible just effect females there might be some insight.

 

Maybe let's talk about XPMSE skeletons or the behavior files that come with them since no one knows what they do since Groovtama just yells at people about it without explaining what it might do. ("USE THESE FOR AN HDT BODY". WTF exactly is an hdt body any body will bounce with the bones it's weighted for if it's skinned to them). Those could very well be the cause. Variation in those seem likely to be related to causing the TPose since we can't single anything else out. I can't see any other place where the female vs male could have an error outside of those especially in the outcome of a Tpose. Perhaps FNIS settings also, some of the xtra check boxes could be what leads to this. I'm looking for something behavior.hkx related since the TPose generally relates to that.

 

I'm on an early modified XPMSE 2.0 skeleton, and have no FNIS checkboxes checked. Maybe people experiencing these issues try unchecking your checkbox and report your XPMSE skeleton and extra credit if you deleted the behaviors or not. Behaviors is the Skyrim thing that will crash sometimes but not everytime.

 

[pipdude]

 

 

 

 

Have you tried replacing the setscale code to use the native SetScale instead of NetImmerse?

 

 

It's in discussion, a lot of the preemptive OSex's prior to 1.07 were using just scale before i switched to Oheight and all of the solutions I came up with hit weird walls about scale. In most cases the actors would gets slightly taller everytime, it's due to the double values being used of race and height scales but only one is controllable in papyrus to affect both simultaneously.

 

An example is a 1.0 height 1.04 race character that you set to 1.05 scale becomes 1.05 (1.05) and they way the math works that's not the proportional increase you are looking for from papyrus. For me oheight came because I could never get scale to make the exact size actors I needed or I couldn't have it not do strange things post scene. Those values are saved with the game, so if root node leaves them slightly different size they will be reverted the next time the game loads them however in the scale case people's favorite OSex partners would slowly become larger and larger throughout the save.

 

This is just my impressions and Migal has done more studies on this and seems like he can get scale to reliably output but I'm still trying to figure it out.

 

I suspect that the isFemale flag is there more for performance reasons. NetImmerse probably checks for that itself every time.

 

Sounds like a good explanation but I think the fact that only females are tposed in the error reports is a hint still at the solution. The TPosing is somehow related to the crash or a harbringer at least that it's coming and while I have no idea how it could possible just effect females there might be some insight.

 

Maybe let's talk about XPMSE skeletons or the behavior files that come with them since no one knows what they do since Groovtama just yells at people about it without explaining what it might do. Those could very well be the cause. Variation in those seem likely to be related to causing the TPose since we can't single anything else out. I can't see any other place where the female vs male could have an error outside of those especially in the outcome of a Tpose. Perhaps FNIS settings also, some of the xtra check boxes could be what leads to this. I'm looking for something behavior.hkx related since the TPose generally relates to that.

 

I'm on an early modified XPMSE 2.0 skeleton, and have no FNIS checkboxes checked. Maybe people experiencing these issues try unchecking your checkbox and report your XPMSE skeleton and extra credit if it's with behaviors or not.

 

 

It seems like you could keep track of the relative change and reverse it at the end.

 

ie. Record the original scale. Apply the same formula you have. Calculate the percent change based on the new scale and original. Use that value to reverse.

 

--------

 

Hm. I'm using newest XPMSE and FNIS and check first two boxes and it's stable.

[CEO 0S]

 

 

 

It seems like you could keep track of the relative change and reverse it at the end.

 

ie. Record the original scale. Apply the same formula you have. Calculate the percent change based on the new scale and original. Use that value to reverse.

 

--------

 

Hm. I'm using newest XPMSE and FNIS and check first two boxes and it's stable.

 

 

There's the issue that you will not be able to achieve the same pairings of scales like this when you do it backwards:

 

Orc is 1.0 (1.04)  Math would have to make the value of 2 numbers multiplied by each other to equal the desired scale since setScale can only result in a pair of 2 of the same numbers. So something like (1.013) (1.013) would result as their desired scene scale. On reverting them back you could only set their pairings to double numbers again so if you stored their initial value as 1.04 on setting them back to 1.04 they would be 1.04 (1.04) as opposed to 1.0 (1.04).

 

I suppose math could be made to generate the two numbers multiplied by each other to reach the outcome, their scale would be natively changed after a session but I think still result in the proper visual size. The formula is beyond my suck math ability though and I'm not entirely sure it would work.

 

Migal I think is mentioning that in some cases these numbers might just be a facade and not the true value so maybe there's hope for it.

[CEO 0S]

 

 

SF is there anything we can do about the papyrus line that checks for genital base so it still works on a none xpms skeleton but gets the job done?

 

You could replace it with a check for keywords:

if(actra.HasKeywordString("ActorTypeNPC") && !actra.HasKeywordString("ActorTypeCreature") && !actra.HasKeywordString("ActorTypeAnimal") )

That should be mostly as comprehensive.

 

 

SF thanks by the way, this should and aid the trouble shooting a lot. I suppose there is most likely some custom follower out there where the creator deleted that keyword from it but that should be super uncommon. I'll remove xpmse skeleton as a requirement and switch to this, the bad news is that we'll still have to trouble shoot the curving anatomy issue since people could initiate with the SoS skeleton overwritting everything and the xpmse requirement stopped this but at least for most users they can get on with whatever they want and minimal hassle if they don't have experience modding Skyrim.

 

 

[pipdude]

 

There's the issue that you will not be able to achieve the same pairings of scales like this when you do it backwards:

 

Orc is 1.0 (1.04)  Math would have to make the value of 2 numbers multiplied by each other to equal the desired scale since setScale can only result in a pair of 2 of the same numbers. So something like (1.013) (1.013) would result as their desired scene scale. On reverting them back you could only set their pairings to double numbers again so if you stored their initial value as 1.04 on setting them back to 1.04 they would be 1.04 (1.04) as opposed to 1.0 (1.04).

 

I suppose math could be made to generate the two numbers multiplied by each other to reach the outcome, their scale would be natively changed after a session but I think still result in the proper visual size. The formula is beyond my suck math ability though and I'm not entirely sure it would work.

 

Migal I think is mentioning that in some cases these numbers might just be a facade and not the true value so maybe there's hope for it.

 

 

It sounds like what I was thinking earlier. One is relative and the other is more like a property. I think the approach I'm referring to would work either way as long as you know which you are dealing with / applying to.

 

I think that I could get this ironed out. But, the overall code is so much more involved now, I think I would need a set of simple demo files that reproduce the problem. Then I could adjust, add math, etc. to fix.

[Kinky]

After cleaning skyrim folder and reinstalling SKSE:

 

1. normal load

2. normal load

3. ctd

4. normal

5. normal

6. t - pose then ctd

7. T - pose then ctd

8. ctd

9. ctd

10. T - pose then ctd

 

This tests were performed on bare minimum of mods installed together with 0sex.

[CEO 0S]

 

 

 

Thanks Pip I'll see if I can get something set up like that for you.

[pipdude]

After cleaning skyrim folder and reinstalling SKSE:

 

1. normal load

2. normal load

3. ctd

4. normal

5. normal

6. t - pose then ctd

7. T - pose then ctd

8. ctd

9. ctd

10. T - pose then ctd

 

This tests were performed on bare minimum of mods installed together with 0sex.

 

Based on the potential gender lead:

 

These are all starting new game, creating female character?

 

If so, does it crash if you use male character instead?

[Kinky]

 

Based on the potential gender lead:

 

These are all starting new game, creating female character?

 

If so, does it crash if you use male character instead?

 

 

No this were all loading existing save that was cleaned to be ready to install new 0sex.

(again this save will never crash if i dont install 0sex).

 

Migal is playing male character so he could have better info on that.

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

I just remembered i also have one low lvl male character so ill test few times on that.

 

Also something i noticed. in my saves folder every ess save file has its counterpart .skse

 

Maybe information causing crashes is stored inside that?

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

 

Nevermind i cant find those saves on this huge list and im not in a mood to watch skyrim intro over and over again for testing.

 

 

CEO i noticed that guy on nexus mentioning SKYUI as issue. Could it be that your script that is registering MCM menu on load is whats causing the trouble? It could be something we are not expecting.

 

[CEO 0S]

 

 

 

Kinky are you going to be around tonight?

 

I want to kill this bug right now so let's do this if you are. I want to make a series of script changes, none of them will actually run OSex because of the changes I make but what they will do is disable portions of the boot up process. The goal of the test will be to find the part of the boot up process that is crashing you by playing hot and cold until you're able to start up Skyrim with OSex installed without crashing.

[pipdude]

 

No this were all loading existing save that was cleaned to be ready to install new 0sex.

(again this save will never crash if i dont install 0sex).

 

 

Does it ever crash if you start new game and then load the new game, male or female character?

 

 

Nevermind i cant find those saves on this huge list and im not in a mood to watch skyrim intro over and over again for testing. 

 

 

Alternate Start can be considered safe. I always have that installed for this same reason.