Jump to content

SexoutNG - need input

astymma

By astymma,
in Sexout

Recommended Posts

astymma

astymma

Posted
  • Author
Posted

Arg, I've documented it a few times but let me cut and paste one of my descriptive posts.

 

 


The methods are simple:

 

position

 

actor.NX_SetEVFl "Sexout:PosX" newPosX 0
actor.NX_SetEVFl "Sexout:PosY" newPosY 0
actor.NX_SetEVFl "Sexout:PosZ" newPosZ 0
actor.NX_SetEVFl "Sexout:PosChanged" 1.00 0
rotation

 

actor.NX_SetEVFl "Sexout:RotX" newRotX 0
actor.NX_SetEVFl "Sexout:RotY" newRotY 0
actor.NX_SetEVFl "Sexout:RotZ" newRotZ 0
actor.NX_SetEVFl "Sexout:RotChanged" 1.00 0
Sexout::PosChanged and Sexout::RotChanged MUST be set to 1.00 in the same frame that the PosX, PosY, and PosZ or RotX, RotY, and RotZ variables are set or the SexoutNGAnimPositionSCRIPTV2 script will overwrite your changes. The SexoutNGAnimPositionSCRIPTV2 script looks for those values and if they're set to 1.00 it updates itself to maintain the new position/rotation it has been given. If it's set to 0.00 it ignores any new values and continues maintaining its existing position/rotation.

 

The values need to be absolute values and not offsets. For example, if the anim starts at 100,200,300 in x,y,z coords and you need it to go up in z by 50 you need to set the value to 350 and not 50.

Link to comment

BruceWayne

BruceWayne

Posted
Posted

I don't really care where it would end up, all I'd like to see would be that all the information is in one place, be it physically or through links to the relevant posts. I'd even assist in putting something like that together, but I don't really know what the extender/sexout is capable of, beyond what is available in the existing API.

Link to comment
Halstrom

Halstrom

Posted
Posted

I don't really care where it would end up, all I'd like to see would be that all the information is in one place, be it physically or through links to the relevant posts. I'd even assist in putting something like that together, but I don't really know what the extender/sexout is capable of, beyond what is available in the existing API.

Physically? Might be a bit extreme having to order it by Snail Mail :) Maybe we could cram it into an item note for an API Bottlecap then hide it in a crate in one of the remotest parts of NV :)

Link to comment
BruceWayne

BruceWayne

Posted
Posted

 

I don't really care where it would end up, all I'd like to see would be that all the information is in one place, be it physically or through links to the relevant posts. I'd even assist in putting something like that together, but I don't really know what the extender/sexout is capable of, beyond what is available in the existing API.

Physically? Might be a bit extreme having to order it by Snail Mail :) Maybe we could cram it into an item note for an API Bottlecap then hide it in a crate in one of the remotest parts of NV :)

 

 

Lol, you know what I mean...   :lol:

 

English is my second language. 

Link to comment
Halstrom

Halstrom

Posted
Posted

 

 

I don't really care where it would end up, all I'd like to see would be that all the information is in one place, be it physically or through links to the relevant posts. I'd even assist in putting something like that together, but I don't really know what the extender/sexout is capable of, beyond what is available in the existing API.

Physically? Might be a bit extreme having to order it by Snail Mail :) Maybe we could cram it into an item note for an API Bottlecap then hide it in a crate in one of the remotest parts of NV :)

 

 

Lol, you know what I mean...   :lol:

 

English is my second language. 

 

No problems, many people with English as a first language would say that too. Either that or it's like when you spend too much time in Virtual worlds like Second Life and want to rez a 1m cube in the lounge room shape and texture it into a coffee table, or script a cup to refill itself :)

 

 

 

Link to comment
DoctaSax

DoctaSax

Posted
Posted

prideslayer, on 29 May 2013 - 02:11, said:

 

    Oh, there *may* be issues with other mods that add greeting dialog, I guess we'll see. SCR adds dialog to the doctors in greeting, and legion adds greetings in for marissa etc. If one or the other breaks, switch the SCR/Legion load order and see if the problem switches position.

 

    I am pretty sure dialog gets merged nicely by the engine, so no conflicts, but I may be mistaken.

 

All I've ever heard not to do with greeting topics is adding topics through the addtopics box with them, really. The oblivion cs wiki has a whole page about the addtopic bug, and I think it's still around in fallout too. I had got this curious dialog incompatibility with UndergroundHideOutNV, and the only thing I can see there was exactly that.

Luckily there's a nice little "top-level" checkbox to topics in the geck now, so the issue doesn't occur as much anymore, but it's also one of those things people are simply not told about anymore either, just for that reason. Used to be a big "don't" :/

   

BruceWayne, on 28 May 2013 - 20:18, said:

 

    Astymma, would it be possible to put these instructions into the API? I wasn't really aware that sexout itself supports this with inbuilt NX variables. I'd love to use beds or matresses in my scripts, instead of having to chase around to the nearest bed beforehand.

   

prideslayer, on 28 May 2013 - 22:28, said:

 

    DoctorSax wrote a tutorial here I believe it's up to date. I'll add a link to it from the API first post.

 

    Edit: Blah that one is for the old calling convention. Will need updated before I link it in the API thread.

Aw, that poor old tutorial isn't to blame for having been written at a time NX was nothing but a rumor about some voodoo you were brewing up to help with multiple scenes happening at the same time... :P

 

Looking at some of the fancier things it tried to do, I'm not sure, actually, if I have the confidence to turn those bits into nx right out of hand. I'm not getting cute here, or more than usual. I'm honestly not sure, for instance, if I could tell people to type something like this in a result script:

actorref.NX_SetEVFl "Sexout:Start::fSurfaceAngle" questID.fNewAngle

to replace

set SexoutNG.fSurfaceAngle to somecalculation

 

Astymma made sure I never declare variables in dialog result scripts, so going for a quest var as a placeholder is my standard way of thinking now, but I'm guessing it wouldn't take? Does it take a global maybe, I dunno. I'm sure someone already asked this, user29 maybe, but it's one of 'em things, you know you knew... :blush:

 

I'm sorry to say the main reason my tut needed updating is not that it uses the old/classic code. Even in that, people should no longer type it out as an offset. Worked literally hundreds of times like that in May last year, but appeared to have changed anywhere between then and earlier this year, when I found that every tweak was basically done twice now that way, and neglected to update  for it...

So, everything in it that says

   set SexoutNG.surfacevar to SexoutNG.surfacevar + somevalue/calculation

should now just neatly be

   set SexoutNG.surfacevar to somevalue/calculation

in the old version. For NX, that would be either

   actorref.NX_SetEVFl "Sexout:Start::surfacevar" somevalue

or

   set somenewvariable to somecalculation

and then

  actorref.NX_SetEVFl "Sexout:Start::surfacevar" thevariableyoudeclaredbackthere

 

I think.

(The variables are refSurface, fSurfaceX, fSurfaceY, fSurfaceZ, and fSurfaceAngle.)

 

That last bit is where the trouble lies for me, but shouldn't be of much importance if a modder already knows which bed reference it's placed on, in which case you don't need calculations based on angles etc. That trig should still be good, hopefully. (Bethesda has in fact already changed the conventions of math once, so no guarantees.)  But they're just there as a possible resource for a generic functionality, if anyone ever wanted to take a stab at that. I... don't, although I'm guessing it'd involve a refwalk, the SexoutSLFUrnBeds lists and nx_isinlist (which didn't exist yet & would probably be better than the regular), and the angle calculations for a basic starting position, and leaving the finetuning to users via some repositioning interface with those Pos calculations.

 

A quest modder like Bruce here, if he's looking to specify a starting position for sex on a specific bed reference is much better off looking in the cell to figure out the directions in relation to x & y, and just trying some values out. You'd probably make the bed a persistent ref, so you might as well give it a tick in the reference window to see which is which. Easiest way is do it for a bed that's placed at any of Zangles 0, 90, 180 or 270 (and most are).

For the distances, x & y move like you'd expect (game units), but as little as +8 or -5 fSurfaceZ can make a world of difference to start or stop clipping and floating. Especially for oral anims, most of which are a pain due to x/y clipping. The doggy, missionary, cowgirl ones aren't too difficult, and any tweaking I've done there myself was just for aesthetic effect. The same would probably go for other furniture like tables and couches maybe, although some anims are quite impossible with couches and those are the ones I must've tried at the time before I gave up & moved on. A lot has to do with there being enough free flat surface, as with floor sex.

Link to comment
astymma

astymma

Posted
  • Author
Posted

That's kind of why I added that NX functionality into the positioning script to begin with. With it, we don't need ANY surface code at all. We just need to know where to move the actors and what angles to rotate the actors to just make them look like they're on the furniture. We create animations that look like they're on furniture and then move/rotate the actors so they look like they're on furniture. One callback spell added to the Sexout list of spells to cast on start that positions/rotates them one time to center/rotate them for that piece of furniture with the animation # specified as one that works with that type of furniture.

 

So... basically...

 

Animators: make animations that look good on chairs, tables, couches, pooltables, wherever and determine what offsets/rotation are needed to make them "fit"

Coders: create a mod that calls these animations and applies the positions/rotations when the animation starts based on the type of furniture and animation number

Sexout: possibly create categories of animation number ranges based on furniture types

SCR: lists of furniture categories by z-angle rotation (so then all we need to know is x,y,z positioning offsets and we can auto-calculate rotation offsets)

 

Some of this has already been done to a certain degree... SCR has some bed lists by z-angle rotation, Sexout has some "open" animation ranges available we can use, animators have already made many animations that could be used as-is or with minor changes as "furniture animations" (i.e. nearly any animation works on a pool table and many work fine on a couch if position correctly).

Link to comment
astymma

astymma

Posted
  • Author
Posted

Actually, the more I think about it, we don't need to know the z-angle rotation for a furniture item UNLESS we use refSurface. If we just want to make it LOOK like they're on the furniture, we just need to know the current rotation of the furniture and the positioning offsets for the animations and we can do it without any lists needed in SCR at all. What's basically needed is one huge list of if furnitureREF = Blah then set offsets to blah for a bunch of furniture refs.

 

Though, it might be a good idea to have user editable lists in SCR that would represent saying "This chair in mod Y... it behaves the same as vanilla chair X... so treat it like it was chair X for position/rotation".

Link to comment
D_ManXX2

D_ManXX2

Posted
Posted

I hope you guys can eventually add new options like shuffling through animations. or add new slots where you can insert new scenes like foreplay, then the animation itself like you currently can with oblivion and different stages etc.. Ultimately cumming phase etc. like it shows under skyrim section.

 

for the cumming phase i will see if i can find some tutorials on how to use fluid under blender. If you turn fluid white you might the cum effects but i am no texturer.

Link to comment
BruceWayne

BruceWayne

Posted
Posted

 

 

A quest modder like Bruce here, if he's looking to specify a starting position for sex on a specific bed reference is much better off looking in the cell to figure out the directions in relation to x & y, and just trying some values out. You'd probably make the bed a persistent ref, so you might as well give it a tick in the reference window to see which is which. Easiest way is do it for a bed that's placed at any of Zangles 0, 90, 180 or 270 (and most are).

For the distances, x & y move like you'd expect (game units), but as little as +8 or -5 fSurfaceZ can make a world of difference to start or stop clipping and floating. Especially for oral anims, most of which are a pain due to x/y clipping. The doggy, missionary, cowgirl ones aren't too difficult, and any tweaking I've done there myself was just for aesthetic effect. The same would probably go for other furniture like tables and couches maybe, although some anims are quite impossible with couches and those are the ones I must've tried at the time before I gave up & moved on. A lot has to do with there being enough free flat surface, as with floor sex.

 

 

No problem, the bed is already a pers. ref for the AI packages and as a destination for my marker rat. While I technically don't need the rat, since I still have only one character (yeah, I'm slow :rolleyes: ), I planned on recycling the quest for different chars, as to not having to do the same stuff over and over again, only with a handful of different references. So the problem I see here is, that if I explicitly define the bed and all the angles, this script would become useless for other characters. While I'm not married to the method I used there, because of some other problems it introduces, I'd like to have versatile scripts and use them for different chars. I'm not sure if I still can, If I include specific "bed instructions".

 

 

Animators: make animations that look good on chairs, tables, couches, pooltables, wherever and determine what offsets/rotation are needed to make them "fit"

Coders: create a mod that calls these animations and applies the positions/rotations when the animation starts based on the type of furniture and animation number

Sexout: possibly create categories of animation number ranges based on furniture types

SCR: lists of furniture categories by z-angle rotation (so then all we need to know is x,y,z positioning offsets and we can auto-calculate rotation offsets)

 

Some of this has already been done to a certain degree... SCR has some bed lists by z-angle rotation, Sexout has some "open" animation ranges available we can use, animators have already made many animations that could be used as-is or with minor changes as "furniture animations" (i.e. nearly any animation works on a pool table and many work fine on a couch if position correctly).

 

Are you saying, that there is a chance that this can be transformed into something like LoversBed for Oblivion with the current NVSE/Extender? That mod basically hooked into every sex act, checked if a bed or something bed-like is in the near vicinity, asked if you want to use the bed in a popup window and than placed the actors automatically on that bed with all the right angles. 

Link to comment
prideslayer

prideslayer

Posted
Posted

I wouldn't say never do it, just follow the rules outlined. Specifically, if you need one there, do the init on it first. I didn't know about this myself; thread/discoveries came during my absence. Got some quests to run through and make sure their scripts are all 'ok' it seems.

Link to comment
DoctaSax

DoctaSax

Posted
Posted

That's kind of why I added that NX functionality into the positioning script to begin with. With it, we don't need ANY surface code at all. We just need to know where to move the actors and what angles to rotate the actors to just make them look like they're on the furniture. We create animations that look like they're on furniture and then move/rotate the actors so they look like they're on furniture.

Yes, but new anims... they trickle in a little, but that's about it.

So for 'big' furniture like beds & tables, the surface stuff is still pretty useful for the ones we have already, at least for a starting position. Smaller furniture like chairs, or even statics that are in more cramped spaces (kitchen counters or whatever) are the only thing that'd really need new anims for them + pos code, because I imagine those situations to be more finnicky.

 

Actually, the more I think about it, we don't need to know the z-angle rotation for a furniture item UNLESS we use refSurface. If we just want to make it LOOK like they're on the furniture, we just need to know the current rotation of the furniture and the positioning offsets for the animations and we can do it without any lists needed in SCR at all. What's basically needed is one huge list of if furnitureREF = Blah then set offsets to blah for a bunch of furniture refs.

 

Though, it might be a good idea to have user editable lists in SCR that would represent saying "This chair in mod Y... it behaves the same as vanilla chair X... so treat it like it was chair X for position/rotation".

Sure, *if* an automated system were to be worked into NG itself (no pressure in that statement, at all) or a separate plugin for the functionality, it shouldn't have to rely on  SSR/SCR lists, I think. I just asked Hal to park those lists for individual mods to use. But whether through lists or script, those beds need sorting out somehow because the Z-angle alone doesn't tell you how they look placed in the cell - the relation between the base object and its standard direction when dropped in a cell at z-angle 0 is all a bit haphazardly done in vanilla. Close to half pointing +Y, close to half -Y, the rest spread out over + & - X.

I don't know if those lists should be renamed a bit or not, "IsAngleZ90" etc could give people the wrong idea. I just thought that the ones that ended up with the headboard to the positive Y-axis (Z-angle 0) when dropped in the cell as is (at Z-angle 0), pretty much constitute those that "are" angleZ, and derived the rest from that. It seemed the sensible way to go about it.

(What little I remembered from math was that angles are usually represented as starting from X & going counterclockwise. Bit of a shock to learn that both are done completely differently in Beth games, just to mess with us probably! :D )

 

No problem, the bed is already a pers. ref for the AI packages and as a destination for my marker rat. While I technically don't need the rat, since I still have only one character (yeah, I'm slow :rolleyes: ), I planned on recycling the quest for different chars, as to not having to do the same stuff over and over again, only with a handful of different references. So the problem I see here is, that if I explicitly define the bed and all the angles, this script would become useless for other characters. While I'm not married to the method I used there, because of some other problems it introduces, I'd like to have versatile scripts and use them for different chars. I'm not sure if I still can, If I include specific "bed instructions".

 

If you use similar beds (same base z-angle & size, or just the same base form), you could use the angle stuff to transpose the tweaks you test on one to any others no matter their placement, although that's the bit I'd use a spell script to do if you write it in NX maybe.

You could also have an 'absolute' tweak in length and height for an anim, with a range of randomness in width, for instance. I'm not sure how to type all that out yet, but I figured I'd give you some pointers if you wanted to look into it all for Affairs anytime soon.

 

Also, all of that was done on the side when I tried out absolute values to use in sofo - bit of a diversion or mental flight of fancy. I don't have any notes left, and didn't spend more time testing on the relative headingangles & trig than seeing a handful of try-outs in old code conform to what I expected the result would be beforehand; that's all the guarantees I can really give.

Link to comment
prideslayer

prideslayer

Posted
Posted

The bare information sexout would need is:

 

- The Z offset for the surface above the ground.

- The rotation the animation should assume, along Z, relative to the object.

- X and Y offsets from object origin to center.

 

I don't see any use for formlists. The Z offsets are unlikely to be nice and uniform, just like the current animation offsets (on those that require them) are not uniform or in easy "steps." There will be a block of code that either checks each ref in a big if/else block like the current animations, or some 'loader' code that sets offset values once on all the base objects. Since that code has to be there regardless, it can hold the Z angles as well, and that's the only place where a list seems like it would have been useful to me.

Link to comment
prideslayer

prideslayer

Posted
Posted

That's my thought.

 

Someone goes through and gets the needed offsets and rotations for one instance of each bed and notes them down, and then in the sexout init I can NX stuff them all for later lookup with GBO on the refSurface during normal offset positioning. Thankfully script wise it's enough to GBO and preinit the existing offsets blind, since setting them to 0 if there's no NX value won't hurt anything. Won't increase script size nearly as much as having to handle each animation individually would.

 

You know..

 

I wouldn't actually have to preinit them in a script either. I could add some code to the extender to manually save/load a 'global' file that's loaded in the init block. Sexout could autoload it's own datafile, other mods could autoload or manually load theirs, and so on. This has some interesting applications, but the one I'm thinking of now is this:

 

Offsets could be stored there instead of in the script.. e.g. NX_GetConfigFloat "sexout:anim:239:H:A". This would not work exactly this way since there's no sprintf type thing I can do in a script (yet!) to build a string, but NVSE does support those poor-mans varargs functions, something that can require one string and then 10 more optional strings. NX could then combine them into a key itself, so it would be more like NX_GetConfigFloat "sexout" "anim" "239" "A" "H" to get the HOffsetA for 239 (which is 3, btw.. heh).

 

That would reduce all that offset BS in the positiong script to the NX load line plus 6 more lines.. getting the HOffset and VOffset for A, B, and C, and putting surfaces in there would be no more difficult.

Link to comment

Archived

This topic is now archived and is closed to further replies.

Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.

View Community Rules

Help Support LoversLab

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