Jump to content

OSex+ The Greatest Virtual Sex Ever


Recommended Posts

I did unpack it, it has the hudmenu.gfx in it. Something tells me that Less intrusive hud will not work without it. 

So, any other mod that does the same things with less intrusive hud, or is there a way around this issue?

 

The author of lessIntrusiveHud could most likely fix it in a matter of 3 minutes but they have the source files. I'm not sure about other mods as I don't use many myself maybe someone else will know. You're right that it will not work without those files, it's either OSex or Less Intrusive Hud II.

Link to comment

 

Migal if you have a little time to help me to go over some results from the scale testing script

 

 

 
function testingOutput()
 
 
  actor tester = Game.GetCurrentCrosshairRef() as Actor
  if tester
 
        float desiredScale = 1.0
        float naturalScale = tester.getScale()
        debug.messagebox("Natural Scale: "+naturalScale)  
 
        
 
                 if naturalScale != desiredScale ; 1.03 could be a variable from config setting instead
                 float scaleMultiplier = (desiredScale / naturalScale)
 
                 tester.setScale(scaleMultiplier)
                 debug.messagebox("Modified Scale: "+tester.getScale())
 
                 EndIf
    EndIf
 
--------------------------------------------------
Results:
 
I placed an npc at me and console .setScale(2.0)
 

Natural Scale output: 2.06

Modified Scale output: .5

 

The NPC was half the intended size. 

 

When I run the math on paper:

 

Step1: 1.0 / 2.06  = .4854~

Step2: 2.06 * .4854 = .99999~ 

 

The math is right on paper but Skyrim is outputting half what the paper math shows. Any thoughts on correcting this? I'll continue to do studies this evening and see what I can find.

 

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

 

I'm also confused as scale for objectReference as it does seem like there is a second number at play and scale isn't just "Scale" for example if an actor is 1.03 and I set them to scale 1.0 they return a scale of 1.03 as opposed to a scale of 1.0 so there is a record of some scale setting that goes beyond what the game considers just their scale as an object reference (I think).

 

After the first scaling change wouldn't we lose their natural scale (1.03) in this case and be unable to size them correctly from that point on unless we stored the original scale value that their 1.0 scale = the first time we measured them only before ever adjusting them.

 

 

What I mean is scale 1.0 = 1.03 on a 1.03 starting scale actor where as scale 1.0 = 1.0 on a starting scale 1.0 actor, so if scale was just referencing the objectReference scale wouldn't 1.0 always = 1.0 scale since all npcs are based on the same skeleton?

 

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

 

Perhaps it's my use of console that is skewing the data since it's setting a natural 1.03 to a 2.0 adjusted by their 1.03 base causing results to be all wrong. In this case maybe setting an actor to scale 1.0 always before measuring would be best.

Link to comment

 

I did unpack it, it has the hudmenu.gfx in it. Something tells me that Less intrusive hud will not work without it. 

So, any other mod that does the same things with less intrusive hud, or is there a way around this issue?

 

 

I recommend this: http://www.nexusmods.com/skyrim/mods/3222/?

 

But I don't know what your specific needs or wants are. 

 

-C

 

 

I did just try Minimal Hud witch is close to the functionality of Less intrusive hud. Altough far more complicated to setup as you cannot see the HUD elements when you change their position...However I did run into a bizare problem.

 

The scene did start but the menu was mostly outside the screen, so I could not see it !!

Maybe I did not installed it correctly as I did not make a clean save when removing Less intrusive Hud.

Link to comment

Ok I managed to achieve...

 

(When I say "I managed to achieve" what I actually mean is I put in Migal's code and based the solution on all his hard work and studies that he's been working on for weeks to figure this out to achieve:

 

perfect scaling which I think will work. It's using just a scale method which means I can gut a large part of the script in no longer needing to time things around actionscript. In the past prior to oheight there were many occasions where I believed I got scaling accomplished by setScale working but wound up having nuances I couldn't fix like actors getting nudged up or down in scale everytime eventually growing huge or tiny after many sessions.

 

I did just limited testing now and it seems to work so hopefully this is it.

 

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

 

Since i'm removing and changing a significant amount of stuff in the script (to adapt and simplify  around no more height) I will need a demo here before going on nexus so testers please help. I will also need testing of Scorpion's DLL plugin to see if non-english characters can now fully work in OSA.

 

I'll have it up at some point tomorrow, or today thanks!

 

I'm unable to fix the crashes as it's related to behavior files and not something I can really influence besides hitting the generate FNIS button. I'll keep investigating this but I have no values I can tweak on my end to adjust to try to fix this, behavior file generation is a one click thing in FNIS. I also can't recreate it so even if I could do things to fix it I wouldn't be able to know if the fixes work. Regardless I'll keep working on it and hopefully figure out something. 

 

Outside of that there's a million different errors that can go wrong as seen on nexus, I find it surprising how different Skyrim can behave on different systems even though it's the same game. They are all random, with no minimal information on what happened, and I can't recreate them so I have no idea and will most likely just not worry about it. Assuming they are all caused by some mod conflict and by how much time the HudMenu.gfx is wasting both in detecting/solving but also troubleshooted I'm starting to give less fucks about anything that isn't an issue on my own Skyrim, unless I know for certain it's caused by me like the crash from behavior files related to the OSex files.

 

 

 

Link to comment
 

 

FootIk error is something that you probably wont be able to fix on your end.

Im tracking Crash Fixes mod and some guy said this:

 

"FookIk error just usualy happened with me when I forget that FNIS just can handle 537 alternative animation.

Below 537 alternative animations your are safe and the crash FooIk will not happen."

 

"FNIS count the valid animations, in the 02 end lines, when you use the program to generate the FNIS patch.

Just don't let pass 537."

 

Im not sure if this is true or not but if it is then since 0sex has over 1000 animations this error is going to happen.

 

 

But there is another issue on load or on start of 0sex that you can fix.  That bug that also randomly doesn't give personality to player character so no sounds and messed up esg slots are result of it.

 

I'm looking forward to testing next demo.

 

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

Off topic: Maybe Skyrim Remastered fixes some of those issues.

 

 

Link to comment

 

 

 

FootIk error is something that you probably wont be able to fix on your end.

Im tracking Crash Fixes mod and some guy said this:

 

"FookIk error just usualy happened with me when I forget that FNIS just can handle 537 alternative animation.

Below 537 alternative animations your are safe and the crash FooIk will not happen."

 

"FNIS count the valid animations, in the 02 end lines, when you use the program to generate the FNIS patch.

Just don't let pass 537."

 

Im not sure if this is true or not but if it is then since 0sex has over 1000 animations this error is going to happen.

 

 

But there is another issue on load or on start of 0sex that you can fix.  That bug that also randomly doesn't give personality to player character so no sounds and messed up esg slots are result of it.

 

I'm looking forward to testing next demo.

 

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

Off topic: Maybe Skyrim Remastered fixes some of those issues.

 

 

Thanks Kinky,

I've made a new thing in actioscript called "ready" where every system checks in one at a time from Papyrus when they are done and that makes the next system get booted up. I can time the start of everything now. I've changed a lot so I'm not quite sure if this will clear the problem up but if it's not fixed in the next version I can fix it for the one after that now that I have this system in place. (It's easy now to control the start order regardless of how papyrus handles it.

 

That quote you linked was really helpful actually. That's the reason I divided up the mod into 10 different behavior files but I was never able to get a difinitive answer on this until now. I noticed as soon as one of them went over 500~ that my game would no longer load. I struggled on that for hours but realized eventually if I just kept the number of HKX's being registered in a file under 500 that it would no longer mess up my game.

 

I couldn't find any official documentation on this and asked fores and he wasn't sure, and thought I needed a mem fix thing on my Skyrim to run more animations.

 

There is inconsistencies for that however because mods like sexlab and zaz etc. come with a single behavior with over 500 hkx's in them so I'm not sure what the difference is, maybe it's the flags that OSA needs to use to run. My theory on this is that SexLab might have 1000+ animations but a majority are sequential animations like a single animation with 4-5 stages it progresses through, so those might only count as a single entry for the pack.

 

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

 

The issue we face though is that I've already divided up all the packs to be sub 500 animations. FNIS doesn't care if the mod exists or not it patches the single behavior file with all the little behavior files regardless, so these small packs in terms of total impact are no different then having a few mods with 100 animations in it which should be fine.

 

Basically what I mean is as far as FNIS is concerned OSex is a few mods all with about 100-200 animations as opposed to 1000+. (Since they are in packs)

 

Since it's divided up already I don't know what we can do from here besides trying to divide them up even more.

 

 

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

 

Lastly while it sounds very accurate to what I have experienced. Alternate Animations are a type of flag to set on your animation and OSex doesn't use those so technically these aren't even alternate animations. Perhaps since that's just some short feedback in the quote that it isn't covering everything that could do this.

 

 

Link to comment
 

 

The way you describe system sounds really good. I dont know how exactly FNIS makes new animations possible and available in Skyrim, also not sure how some people do it without FNIS, but if there is a chance that skyrim reads this info on load and your actra, MCM registration or something else kicks in and messes this up this would explain why error happens at random.

 

So the ability to time things seems like great solution.

 

I noticed something weird with Go To Bed mod. Sometimes i get popup on start that it failed to do something (asign ability to player or something) and since 0sex also does on load things it could be that conflict happens. Anyway next demo could solve this. Migal mentioned he doesnt use it coz it conflicts with the mod he is developing, so its not real issue for 0sex. I hope there wont be any major conflicts between those 2 since its the best sleep mod.

 

Also Crash Fixes by meh321 is soon getting another update. So far i tested v11 demo 3 and its great and seems to be lowering chance of FootIk, then again maybe its just random.

 

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

 

PS: Could you explain to me what info is contained within FNIS_0Sex_EMF_A_Behavior.hkx?

Or to be more specific how many animations are in it? I ask coz i was getting FootIk error on this one and it seems tiny.

 

Link to comment

 

 

 

The way you describe system sounds really good. I dont know how exactly FNIS makes new animations possible and available in Skyrim, also not sure how some people do it without FNIS, but if there is a chance that skyrim reads this info on load and your actra, MCM registration or something else kicks in and messes this up this would explain why error happens at random.

 

So the ability to time things seems like great solution.

 

I noticed something weird with Go To Bed mod. Sometimes i get popup on start that it failed to do something (asign ability to player or something) and since 0sex also does on load things it could be that conflict happens. Anyway next demo could solve this. Migal mentioned he doesnt use it coz it conflicts with the mod he is developing, so its not real issue for 0sex. I hope there wont be any major conflicts between those 2 since its the best sleep mod.

 

Also Crash Fixes by meh321 is soon getting another update. So far i tested v11 demo 3 and its great and seems to be lowering chance of FootIk, then again maybe its just random.

 

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

 

PS: Could you explain to me what info is contained within FNIS_0Sex_EMF_A_Behavior.hkx?

Or to be more specific how many animations are in it? I ask coz i was getting FootIk error on this one and it seems tiny.

 

 

Hi Kinky,

I'll just explain the process of getting an animation into skyrim so it makes sense.If you go here in the zip file: Data\meshes\actors\character\animations  

 

These are text documents you have to make to add animations to Skyrim via FNIS. If you're a developer and want to add new animations to use you'd fill in these documents with each animation you are adding then run the blue FNIS for Modders on this text document, it then outputs a behavior file which goes into:

 

Data\meshes\actors\character\behaviors

 

after that (and running the orange FNIS for users) you can call the animations by the id you filled in, in, the text document from Skyrim.

 

my names are long winded but should be clear at least since I name the animations the same as the scenes in terms of what they do if you open up the text documents.

 

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

 

EMF_A has all the undressing scenes. 25~ total between male and female in the standing scene at the start and 1 from the laying down scene you can undress lowint from. I do notice one thing in that I left a vestige animation event in it from 1.07. It wouldn't matter being there since the event wouldn't harm anything (That I can see) but that's the only difference I see in that one. I'll take that out in the next, I doubt it will help but who knows. It's the .TOS_AMST/0.0 scenes used to be timed by this event but now the UI handles it.

Link to comment

If any of the Papyrus people know. Since I was reworking some things I thought this would simplify a lot but I was unable to get it to work. I was curious if any of my Papyrus people know this.

 

Is there anyway to call a function or get a setup property with get() from a script that extends activemagiceffect without events.

 

For example if I had a start() function in an activemagiceffect script is there any way I could call that for that specific instance of a magic effect directly. I had a bunch of tests today to see if I could make anything attached by a magic effect extend Actor so I could remove the factions entirely and have a script tied to that, I tried it in the squelch package also (all failed). The main goal would have been to remove the factions and consolidate the actra actraga actro into a single script but it seems like I can't make any of them extend actor nor can I trigger a function externally in an active magic effect.

 

It basically seems like once the magic effect is cast that I can't get a form or talk to it in anyway, maybe this is just a fact. Doesn't matter much as it works without this but would have made things a lot cleaner.

 

Example of what I'm looking to do outside of being able to trigger functions directly in a magic effect.

 

_oActraData ActorData = Actra as _oActraData 

 

ActorData.isActorInScene

 

but this would have to be applied with the spell cast or inside it, which doesn't seem to allow extending Actor even though activemagiceffect does extend actor.

Link to comment

 

 

function testingOutput()

 

 

  actor tester = Game.GetCurrentCrosshairRef() as Actor

  if tester

 

        float desiredScale = 1.0

        float naturalScale = tester.getScale()

        debug.messagebox("Natural Scale: "+naturalScale)  

 

        

 

                 if naturalScale != desiredScale ; 1.03 could be a variable from config setting instead

                 float scaleMultiplier = (desiredScale / naturalScale)

 

                 tester.setScale(scaleMultiplier)

                 debug.messagebox("Modified Scale: "+tester.getScale())

 

                 EndIf

    EndIf

 

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

 

 

A couple quick points:

 

1. I never tested anything using console commands. I have no idea if they work the same as the papyrus commands and I also don't know if papyrus getscale/setscale will recognize if console getscale/setscale commands have been used and vice versa.

 

2. During testing, it is a good idea to put a utility.wait(2.0) after each getscale command and before each MessageBox that displays getscale results. Lag in MessageBox can otherwise sometimes produce inaccurate numbers. The problem is with MessageBox, not the scaling commands themselves, so the utitlity.wait() delays can be removed in final code, along with the messageboxes.

 

Results:

 

I placed an npc at me and console .setScale(2.0)

 

Natural Scale output: 2.06

Modified Scale output: .5

 

The NPC was half the intended size. 

 

When I run the math on paper:

 

Step1: 1.0 / 2.06  = .4854~

Step2: 2.06 * .4854 = .99999~ 

 

The math is right on paper but Skyrim is outputting half what the paper math shows. Any thoughts on correcting this? I'll continue to do studies this evening and see what I can find.

The papyrus code looks right. It may be that console setscale and papyrus setscale work the same way and respect each other. In which case, you tried using setscale in a cumulative way (you tried to set scale based on the result of a previous setscale, which will not work).

 

Understand that setscale is not cumulative. Setscale always multiplies by the original object size, not the current object size. The first time you use setscale in a script, the original object size and the current object size are the same. But, after setscale has been used on an object, the original object size and the current object size are two different numbers (excluding actors who happen to naturally be the target size). That's why you always scale an actor back to its original height with setscale(1.0), which is the math equivalent of saying "be your original size times 1.0."

 

I'm also confused as scale for objectReference as it does seem like there is a second number at play and scale isn't just "Scale" for example if an actor is 1.03 and I set them to scale 1.0 they return a scale of 1.03 as opposed to a scale of 1.0 so there is a record of some scale setting that goes beyond what the game considers just their scale as an object reference (I think).

This is precisely as it should be. SetScale(1.0) on an actor that was originally 1.03 will always set the actor to 1.03, because the command is simply saying, "be your original scale times 1.0." Likewise, if an actor was originally 2.94, setscale(1.0) would set the actor to 2.94, because 2.94 was its original scale. This is true no matter how many times you have used setscale on an object, because setscale always operates on the object's original scale, ignoring the object's current scale.

 

After the first scaling change wouldn't we lose their natural scale (1.03) in this case and be unable to size them correctly from that point on unless we stored the original scale value that their 1.0 scale = the first time we measured them only before ever adjusting them.

Nope. The game remembers their original scale and that is what all setscale calculations are based upon. Imagine these four setscale commands happen one after another in your script:

 

- SetScale(2.0) applied to 1.03 actor = 2.06 ; 1.03 * 2.0 = 2.06

 

- SetScale(2.0) applied to the same actor again = 2.06 ; 1.03 * 2.0 = 2.06

 

- SetScale(1.5) applied to the same actor = 1.545 ; 1.03 * 1.5 = 1.545

 

- SetScale(1.0) applied to the same actor = 1.03 ; 1.03 * 1.0 = 1.03

 

Note that in none of the equations above do I use the result of a previous equation in a new equation. SetScale cannot do that, because it is not cumulative. Before setscale was ever used, the actor was 1.03. All setscale operations on that actor will be based on 1.03, no matter how many times you use setscale on that actor.

 

What I mean is scale 1.0 = 1.03 on a 1.03 starting scale actor where as scale 1.0 = 1.0 on a starting scale 1.0 actor, so if scale was just referencing the objectReference scale wouldn't 1.0 always = 1.0 scale since all npcs are based on the same skeleton?

It's probably best not to think of anything as a "starting" scale. Setscale always operates on the object's original scale. The first time you use GetScale to measure an object, you will be seeing that original scale. That same original scale is used in all subsequent setscale operations, which is why you don't need to use getscale to measure the actor again before setting the actor back to its original size. Setscale always knows the actor's original size and will multiple it by any number you put between the parentheses.

 

Setscale scales the entire actor, just as getscale measures the entire actor. The actual size of the skeleton in the nif file is irrelevant. The actor's race and sex are irrelevant. Getscale and setscale operate on the scale of the entire actor objectreference in game.

 

In this case maybe setting an actor to scale 1.0 always before measuring would be best.

100% unnecessary, and it wouldn't work anyway. You cannot set an actor's scale to a new scale and then use setscale as if were going to care about the new scale. It does not care about the object's current scale and it never will. It only cares about the scale the object was before you ever used setscale on the object.

 

If you use setscale on an actor 4 times with a different value each time (1.3, 5.9, 3000.42, 0.78), SetScale(1.0) will return the actor to the size it was before the first setscale command, because it can't consider a previous setscale result when doing calculations. It can only consider the size of the object before you ever used a setscale command.

 

Once you understand and accept that setscale only operates on the scale the actor was before setscale was ever used, everything will fall into place. Apparently, this may include setscale used in the console. However, I would not use setscale in the console because it is unnecessary and only complicates matters. You'll find that few NPCs in the game are naturally your desired target scale, so you should not need to play with setscale in the console for testing.

Link to comment

 

 

 

Migal thanks, 

Your solution appears to be working great, I've got it all hooked up.

 

I'll post this for you and Scorpion also to review the CPConvert changes:

 

 

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

 

string[] function sendActraDetails(actor actra, string FormID, actor PlayerRef, string sCodePage) global
 
If (!CPConvert.CPIsValid(sCodePage))
    Debug.Notification(sCodePage + " is not a valid codepage value!")
EndIf
 
actorBase ActB = actra.GetActorBase()
string[] details = new string[16]
details[0] = FormID
details[1] = CPConvert.CPConv(sCodePage, "UTF-8", ActB.GetName())
details[2] = ActB.GetSex()
if actra == PlayerRef
details[3] = "1"
details[10] = "PlayerDesig"
details[11] = "PC"
details[12] = "Player"
details[13] = "Player"
details[14] = "PC/default/"
Else
details[3] = "0"
 
 
details[10] = details[0] ; it is now already a string in hex
 
details[11] = Game.GetModName(ModNameHex10(details[10]))
details[10] = StringUtil.SubString(details[10], 2) ; last 6 of hex
details[12] = stringUtil.SubString(Details[11], 0, StringUtil.Find(details[11], ".es"))
details[13] = details[12]+details[10]
details[14] = "npc/"+details[12]+"/"+details[10]+"/"
EndIf
details[8] = ActB.GetWeight()
details[7] = ActB.GetVoiceType()
details[6] = CPConvert.CPConv(sCodePage, "UTF-8", ActB.GetRace().GetName())
actra.setScale(1.0)
details[5] = actra.getScale()
 
details[4] = "0"
 
details[9] = "0"
 
; debug.messagebox(miscutil.ScanCellActors(act, 0.0))
 
return details
endfunction
 
 
And Actraga got this:
 
Event OnBodyScale(string eventName, string zType, float zAmount, Form sender)
actra.setScale(zAmount)
EndEvent
 
 
 
 
------------
 
Near the bottom details[5] is storing the scale. calculations are all the same basically beyond that I  just replaced Oheight with scale in the module.xml and in using details[5] instead of a separate value for oheight.
 
I did start with the actra.setScale(1.0) in case they were modified by other mods I believe not having it start from their original scale would mess up the calculations ( to much or less would = desired scale multiplied by the amount their base scale is over or under 1.0)
Link to comment

 

Lastly while it sounds very accurate to what I have experienced. Alternate Animations are a type of flag to set on your animation and OSex doesn't use those so technically these aren't even alternate animations. Perhaps since that's just some short feedback in the quote that it isn't covering everything that could do this.

 

 

I wish my memory were better.  I remember Fore talking about this in his FNIS forum thread over at the Nexus.  As you know, animations can be declared differently in the behavior file.  Cyclic, acyclic, paired, object-including, alternative, etc.  FNIS can handle up to 8000 of each of those types except one, for which it can only handle 1000.  Fore admits this was a mistake and he intended to fix it so all animation types could reach 8000, but I'm not sure he ever got around to it (when I talked to him a couple weeks ago he had switched to a new machine and the new machine wasn't set up for FNIS development).

 

It should be noted that the problem exists when attempting to install a mod that would put the animation count over the limit.  For example, if you already have 6000 cyclic animations, adding 1900 cyclic animations would not put you over the limit, but adding 2100 would.

 

The problem is, I do not remember which animation type had a limit of only 1000.

Link to comment

 

 

Helpful thanks,

 

I use two flag set ups only:

 

b -a,Tn (Acyclic for transitions)

 

b -Tn  (cycle for loops)

 

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

 

In regards to Kinky's comment combined with what you said, it's likely this is what's happening. Other mods that are able to get a higher animation count into a single behavior are registering as Sequential usually putting about 3-5 animations most likely into 1 sequential entry and this most likely also effects the total count where you could put many animations into one sequential flagged animation but with the way OSA needs them to each be individual that cap gets raised faster.

 

8000 is a pretty high number though you'd be looking at about 500 from OSex in each of those flags most likely. Maybe 700 cyclic and 300 acyclic, around there.

Link to comment

 

 

 

 

Also migal I did see you mention it was not needed to set the scale to 1.0 before measuring but I did anyways. In my head it seems like it would make things incorrect if they got measured at (let's say furniture has scaled them to 1.5) as it would be doing the math as if their base scale was 1.5 and not 1.3. I'm not entirely sure though and will do whatever you think is best.

 

The setScale(1.0) pre measuring is turning into a disaster. The player is getting measured by actra at start and setting their scale to 1.0 (even though it doesn't change their scale) it is somehow throwing them through the floor like 50% of the time on game load lol. I really hope you're right and it's not needed so I can get an easy way out of that.

Link to comment

I did start with the actra.setScale(1.0) in case they were modified by other mods I believe not having it start from their original scale would mess up the calculations ( to much or less would = desired scale multiplied by the amount their base scale is over or under 1.0)

 

If you are using actra.setScale(1.0) prior to the first actra.GetScale() it is wasted code and it is doing nothing.

 

Remember:

 

actra.setScale(1.0) = (actra's original scale * 1.0)

 

Meaning, if you have not already used setscale to set an actor to a new scale, SetScale(1.0) does nothing.

 

Another, more blunt way of putting it.  Unless you have previously scaled an actor using SetScale, all SetScale(1.0) does is this:

 

"Be your normal size * 1."

 

Do not scale an actor to 1 times its normal size before first measurement.  Doing so won't break anything, because it is doing nothing.  But, it is unnecessary code.

 

Don't start worrying about the CK or other people's NPC mods.  It is completely irrelevant to scaling operations in the game and in papyrus.  We are dealing with the size of the egg here, not the size, sex, gene pool and breed of the chicken.

Link to comment

Also migal I did see you mention it was not needed to set the scale to 1.0 before measuring but I did anyways. In my head it seems like it would make things incorrect if they got measured at (let's say furniture has scaled them to 1.5) as it would be doing the math as if their base scale was 1.5 and not 1.3. I'm not entirely sure though and will do whatever you think is best.

 

The setScale(1.0) pre measuring is turning into a disaster. The player is getting measured by actra at start and setting their scale to 1.0 (even though it doesn't change their scale) it is somehow throwing them through the floor like 50% of the time on game load lol. I really hope you're right and it's not needed so I can get an easy way out of that.

 

During my testing I learned that furniture that scales NPCs (aka RaceToScale furniture) will effect GetScale results, which means it will effect SetScale results because GetScale is used to calculate the SetScale equation.  That's why I included code to get the npc out of the furniture before using GetScale().  I do not know that attempting to scale them to their true non-RaceToScale size with actra.setscale(1.0) will work while they are still in the furniture, because I never tested it.  It would require the papyrus setscale command to override the furniture's RaceToScale flag and I don't know if that's the case.  On very tall or very short actors, it should be possible to visually see if it works on them while they are still in the furniture.

 

If it does work, you still have the problem of sleeping NPCs freezing 0S.  My code that yanks the NPC out of the furniture resolves this, but there may be another way.

 

Edit:  SetScale(1.0) prior to using GetScale shouldn't cause actors to fall through the floor.  It should do nothing.  I wish I could see all your code.

 

SetScale is not throwing your actors through the floor.  Something else is doing it.  Also, what does SetScale have to do with game load?  Why would it be triggered then?

Link to comment

 

 

I see that makes sense in terms of furniture I don't have shields in place for those now but will put in your recommendation. Do you know what the cause of the sleeping NPC freeze is, it's a bit odd.

 

Actra gets applied to the Player when the UI turns on at which point it then sends the actraDetails for the player to the UI for the player, which triggers this when filling out the actraDetails[]

 

actra.setScale(1.0)

actra.getScale()

 

It's a problem I had before when I used scale that any adjustments to the player scale have a fairly high chance of sending them through the floor when done from Papyrus. i prevented it in the past by making sure they were set vehicle before scaling but it's a little harder to get OSA to do that now without some rework.

 

I'll post an alpha for 1.082 in about 30 minutes so you can see the code. I'm figuring out the new ratio to calculate metric weight and height and the rest is ready to go currently fione is weighing -50 pounds.

Link to comment

Do you know what the cause of the sleeping NPC freeze is, it's a bit odd.

No, I don't know. It's possible something about the old t-pose routine was causing it, in which case it might have been fixed when the t-pose went away. Although, it could also be something about the actor being in a sleeping state.

 

Actra gets applied to the Player when the UI turns on...

The UI gets turned on during game load?

Link to comment

 

 

 

Yea everytime you load the game it has to get started up from scratch.

 

 

Also Migal:

Is this all I need around the measuring script?

 

    if Actra != PlayerRef && ((Actra.GetSitState() > 2) || (Actra.GetSleepState() > 2))

        Actra.MoveTo(Game.GetPlayer(), (40 * Math.Sin(Game.GetPlayer().GetAngleZ())), (40 * Math.Cos(Game.GetPlayer().GetAngleZ())), 0.0, abMatchRotation = false)

    endif

 

 

I'm assuming that makes them skip the stand up animation and puts their scale to whatever it should naturally be?

Link to comment

Yea everytime you load the game it has to get started up from scratch.

 

 

I'm confused. I can understand getscale being necessary before the UI loads, because actor's scale has to be passed to the UI so the UI can display it. However, on game load, no actors have been selected for a scene, unless the game was saved during the middle of a scene. For games that were not saved in the middle of a scene, how does 0S know which actors need measuring with getscale when no actors have been selected for a scene yet?

 

Is this all I need around the measuring script?

 

    if Actra != PlayerRef && ((Actra.GetSitState() > 2) || (Actra.GetSleepState() > 2))

        Actra.MoveTo(Game.GetPlayer(), (40 * Math.Sin(Game.GetPlayer().GetAngleZ())), (40 * Math.Cos(Game.GetPlayer().GetAngleZ())), 0.0, abMatchRotation = false)

    endif

 

 

I'm assuming that makes them skip the stand up animation and puts their scale to whatever it should naturally be?

It gets them out of the furniture but I'm not sure you'll get the quick auto-scaling without playidle(resetroot).

Link to comment

 

 

The player is an exception in that they get actra at start, a special version that binds the generic UI keys. I could have made it happen in an alias but seemed more convenient to allow the keys to update in sync with the UI rebooting etc and I find quest scripts share keys sometimes amongst the quest, so I needed a way to isolate the actions bound from generic keys for navigation the UI. (When unregistering for all keys it would wipe the keys of any script associated with the quest.)

 

Thanks I got it, I'll try it like this then for now:

 

    if Actra != PlayerRef && ((Actra.GetSitState() > 2) || (Actra.GetSleepState() > 2))

      actra.playidle(resetroot)

        Actra.MoveTo(Game.GetPlayer(), (40 * Math.Sin(Game.GetPlayer().GetAngleZ())), (40 * Math.Cos(Game.GetPlayer().GetAngleZ())), 0.0, abMatchRotation = false)

    endif

Link to comment

The player is an exception in that they get actra at start...

You used to do measuring with a t-pose. The player's character gets measured during game load. Sometimes the player's character would be stuck in a t-pose when the game started. I'd be surprised if that was a coincidence.

 

I would consider not doing any actor measurement during game load. I'm not sure how reliable it is given the time it takes for the player character's objectreference to materialize in game could vary from one save to the next. Key bindings could be done in the MCM OnGameReload event. Measuring and scaling could be done for both the player and target NPC during a MagicEffect's OnEffectStart and setting scale back to normal could be done in OnEffectFinish. There are other advantages to using OnEffectStart and OnEffectFinish in that both events include the target actor as a parameter, which means you can place direct actor operations inside those events, such as, If akTarget.IsInFaction(MyFaction)...

 

I should be able to analyze it better after you post the next build.

Link to comment

Getting an error that's been recurring since the move to the new HUD. For some reason when I install (1.081) on a fresh save everything works fine, but if I make a save and then load that (with OSX now installed), it just doesn't function at all, regardless of whether I'm restarting the game or right after making the save. I've made doubly sure that there's no remnant files from previous versions, and it's all the way on the bottom of my MO mod list, so there's nothing that could be being overwritten. No idea what the problem could be.

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   1 member

×
×
  • 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