[WIP] Furniture Interaction Framework - for NPCs and Player

[Roggvir]

I'm guessing, using your framework, it would be possible for things to happen like a rapist slamming you over a table and having his way with you, rather than just doing it on the floor (given, of course, that the requisite animations exist, and that whichever rape-mod references them). Right?

 

I mean it can happen "accidentally" anyway (i.e. my post here, serendipitous positioning in FNV), but were it actually intentional... that'd be super-hot.

 

Using the situation from your scrrenshot as an example - Curently it is implemented in a way that would require such victim to be already leaning over that fence and the mutant to find her like that to "detect an opportunity" causing him to start AI package "fenceFuck" which makes him walk over there and do the deed.

But, with some changes to the code, it should be possible - i will keep that on my mind, whip up some working example later, and we'll see how it goes.

There will be a problem with how it might look, how to get the victim in that position - it would seem strange if she'd just willingly walk to nearest fence, bend over it, and wait for the other actor to walk over there to have his way.

But it will have to do, unless there would be some paired animations made for such purpose.

 

 

Also, do walls count as furniture? Because fucked against a wall = also super-hot.

 

Theoretically it should work, but without trying it first, there is no way to tell.

I am using SKSE function GetNumRefs() to find objects in the scene, so if it can also return walls, and i can then get some required info like position and rotation, then it should be perfectly doable.

I will test it soon, as this is something i have been thinking about already.

[iron_jack]

Awesome dude. Thanks for the response. I'm actually really excited about your work. Best of luck!

 

 

Oh, and regarding the move-to-object thing, honestly as long as the bounds are fairly low, a small "jump"/warp from both actors to get into position is generally acceptable, imo. Something like "if actorA detects <object> within x units, and detects actorB within y units, move actorA and actorB to <object> and start <animation>" sorta thing. Pardon the crappy not-even-pseudocode.

 

 

But anyway that's entirely yo bidness. I'm stoked either way. :3

[Roggvir]

Awesome dude. Thanks for the response. I'm actually really excited about your work. Best of luck!

 

 

Oh, and regarding the move-to-object thing, honestly as long as the bounds are fairly low, a small "jump"/warp from both actors to get into position is generally acceptable, imo. Something like "if actorA detects <object> within x units, and detects actorB within y units, move actorA and actorB to <object> and start <animation>" sorta thing. Pardon the crappy not-even-pseudocode.

 

 

But anyway that's entirely yo bidness. I'm stoked either way. :3

 

Yep, i guess it will have to be that way.

OR, maybe with using black overlay, or some extreme blur effect on the screen, then make the actors to "jump" into the required positions, and then remove the screen effect.

[Roggvir]

Progress report...

 

Having problems with package procedure UseMagic.

I want to use it to make the NPC cast appropriate interaction spell - problem is, i can't find a way how to assign appropriate spell into this procedure's SPELL parameter in realtime.

 

I could make that part completely scripted, but i was hoping i could avoid that and rather use as much of the game's native code as possible.

The horrid rigidness of this game systems never cease to amaze me, sorry for raging like this, but OMG WTF! GRRRS#a/ertoihe alitc3u4t 84ui^hdtdj dg 

[Copper27]

Been looking for something like this, hope you make it!

[Roggvir]

Been looking for something like this, hope you make it!

 

Thanks.

Well, lately i am starting to feel confident that the question isn't IF, but rather HOW.

Even if i wouldn't find a way to implement everything we want, it should still be pretty useful mod.

Even with only what was implemented so far, it could already be a nice addition to anyone's game.

...that being said, i am not planing to give up any time soon, there will be more.

[carnifex]

This looks promising! Eagerly awaiting effects

[Roggvir]

Progress report...

 

• Some more code cleanup
   
• UseMagic procedure now casts interaction spells selected in real-time
  Took quite some time until it hit me, and its so obvious! - you can't select spells for UseMagic procedure in realtime, to start particular interaction in activeMagicEffect script, but you can let the UseMagic procedure cast "hardwired" spell and inside its activeMagicEffect script you find which interaction spell we assigned to this caster, and cast it.
  One thing i hate about this - UseMagic makes the actor to perform the casting animation, which looks horrible, so instead i will probably try to use Activate procedure on the furniture object and cast that interaction spell from its OnActivate event handler.
  ^{(except that wont work for walls, so i'll have to come up with something else ...can an actor be activated maybe? have to try)}
   
• Minor bug fixes
  I say minor, but i actually spend several hours fixing broken activeMagicEffect script, and even though it works again, i have no clue what was wrong.
  It was a place where i ask thread manager to find thread by actor so i can get the assigned interaction spell from one of his properties - the call bubbled up all the way through some global function to its destination in thread manager quest script, the thread was found, but the return value got somehow lost on the way "back".
  The following code is exactly what i had in that magic effect script:
  

  RoggFF_Thread t = RoggLib.GetThreadByActor(actorB)
  Debug.Trace("MagicFX: Interaction - found thread: "+t)
  if !t
      Debug.Trace("MagicFX: Interaction - aborted, thread not found by actor: "+ RoggLib.GetActorIdString(actorB))
      return
  endif
  

  And guess what happened:
  ...trace calls in GetThreadByActor() showed a thread was found, then the first trace call in the code above didn't generate any output, but the second trace call did print its message (the one with "aborted").
  Now i THINK it had something to do with passing actorB into GetThreadByActor() - at first i had this function to accept input both as type actor and objectReference, using named optional parameters.
  Then i removed the objectReference optional parameter from function declaration, and i think after that it started to work - but how would that be related in any way to not returning result from that function, while the whole function code run without error and even its debug messages confirmed a result variable was set (but lost on the return)?
  Anyone experienced anything like this?

[Roggvir]

Progress report...

 

Just one thing, but it is something that bothered me a great deal, and finally its properly solved:
 

NPC interaction package using Activate instead of UseMagic
The interactions are still started by spells cast from a script, but no more need to make the NPC cast a special interaction-package-hardwired-spell first, whose activeMagicEffect script finds which interaction the actor wanted and finally casts the real interaction spell.
Instead, the NPC simply goes to the other actor, activates him/her/it, and the interaction is cast from its OnActivation block.
Not only it removes the ugly casting animation, but we got rid of one more magic effect and spell, and it also needs a bit less code and overall it feels much neater.

 

 

Currently stuck on...

Searching for a way to identify which of the Furniture Framework threads has been involved in the interaction that just ended, because i need to run some interaction-specific cleanup on that thread and its actors.

I cannot simply set the callback to a function of the appropriate thread, because the callback might be part of a "custom furniture library" added by some other mod (extending my default furniture library), so the callback has to be set to a function of such library (no one else would know how to handle cleanups after interactions it provides), but then it doens't have any connection to the FF Thread involved.

Unfortunately i cannot rely on SexLab's animation end hooks alone, because sometimes their callbacks are run too late - when the animation already ended and SexThread released all, or some of the actors involved.

Without actor info from SexThread, i have no reliable way to identify my FF Thread by its actors.

I also tried saving ID of the SexThread into a property of the FF Thread the interaction is run on, and use this property later to find this FF Thread by the SexThread ID i receive in animation callback, but that is also unreliable, because if some other interaction started in meantime, it could reuse the same SexThread, thus saving same SexThread ID to property of another FF Thread.

 

EDIT: Solved, thanks to Ashal

[Nueko]

How does this thread isn't crowded by perverts sexlab enthusiasm? Imagine banging on the glass wall with the boob pressed on it... /gasm

 

Anyway, wish i could help but i get dizzy just seeing your progress report. Don't give up on this tho me and my "bro" will be cheering for you!

 

 

Come on peeps! Get this thread the attention its deserve, make it crowded so he'll feel guilty to stop or abandon this /joke

[Roggvir]

How does this thread isn't crowded by perverts sexlab enthusiasm? Imagine banging on the glass wall with the boob pressed on it... /gasm

 

Anyway, wish i could help but i get dizzy just seeing your progress report. Don't give up on this tho me and my "bro" will be cheering for you!

 

Come on peeps! Get this thread the attention its deserve, make it crowded so he'll feel guilty to stop or abandon this /joke

 

Noted

I'll try my best not to abandon this, but i dont think there is such a danger now, i feel quite optimistic.

[Roggvir]

First post updated with more accurate information,

i recommend everyone to read it so you can share your opinions and ideas, or feature requests - do not be shy.

[Roggvir]

Added a little tweak to support HdtHighHeels (like these beauties).

Before it caused problems with some types of furniture where the actor is still standing, like in pillory (the real world object was fine, but the one bound to the actor via animation, got moved up off the ground and started clipping with the real object) .

 

Now, every furniture has a flag to disable HdtHighHeels while in it - the actor can still wear those nice shiny shoes, but they wont be moving him up like described above.

There is just a very tiny sideffect to it, at least in pillory, where actor's toes slightly clip with the ground, but its not too much noticeable, and there wont be many furniture animations where something like this would happen.

 

In case someone would come up with a better implementation, here is how i do it:

When actor activates the furniture, it checks if the furniture has the DisableHdtHighHeels flag set, and if actor HasMagicEffect() of certain type (0x00000800 in "hdtHighHeel.esm"),

and if yes, then it iterates over all spells the actor has, and dispels those having the mentioned magic effect, while saving them into an array so they can be added back to the actor when he is released from the furniture.

Works perefect, but of course some "officially" supported solution by creator of HdtHighHeels would be probably better, but until then...

 

 

EDIT:

Actually, i just realized this is a HORRIBLE solution.

Because its not handling (un)equiping, so if player adds or switches actor's shoes to another HdtHighHeels supported, while already in pillory, the effect wont be removed!

So, i'll have to fix this.

[43deadwood]

Really looking forward to seeing how this works out - please keep going!!

[razzor69]

Furniture interaction, best future SL mod ever made, keep up the good work dude

[Roggvir]

Progress report...

 

In case anyone was wondering why i stopped spamming the thread with my progress reports,

i was waiting whether some animation related issue gets solved or not, because in either case

i would have to decide my next steps, so i put the development on hold for the time being.

 

Good news is, that ZaZ and Xaz found solution quite quickly, so now i know what to do next and will get back to work.

 

Still, i wasn't completely slacking off - rewrote actor alias scripts, and moving into them all that the furniture alias script was doing.

In case you dont know what i am talking about, just know that it means one less script the game has to run (actually "1 times number of threads" less),

and several other scripts now run better and smoother than before.

A small downside... aparently i introduced some stupid bug, so i have to fix it now.

[Slammer64]

Keep it up Roggvir, hopefully you'll get everything solved and we can have some kitchen-table fun soon.

[Roggvir]

Progress report...

 

Fixed that bug i introduced when rewriting actor alias script.
Everything is in working condition yet again, but still needs to be cleaned a bit.

 

But currently i have much more pressing issue.

I am revisiting an old problem i thought i solved already, but i was mistaken.

I need to be able to call after-interaction cleanup functions when interaction ends - whether they ended on their own, or because of being interrupted by player.

I also need to pass in some data, to identify the furniture thread those interactions were run on - that alone makes using animation hooks impossible, because you cant "inject" your own data into them (i tried using received SexThread id to find sexthread and its actors, and use those actors to find which furniture thread is using them - that doesnt always work, because you can receive these events after actors were already removed from the SexThread).

Using SexLab.TrackFaction() seemed to be a good workaround at first, but not so much now - it sends all registered events related to the tracked faction, regardless of in what SexThread they were registered (obviously, but i didn't thought about it ...obviously ).

Bad for me, because once i register any callback, i cannot simply unregister them, because i could break it for other interactions of same type possibly running in parallel, resulting in a LOT of callback functions being triggered for no reason when tracked faction is detected.

This alone is bad design on my part, but so far i couldnt find any better way, but i must.

 

I need a way to call my callback functions from particular SexThread when certain event happens on that particular SexThread,

in other words, something like "When this thread stops animating, call that function and pass in these data (or a list of all actor refs involved)".

I am afraid this won't be possible without implementing support for that into SexLab, but maybe i am wrong, we'll see...

On the other hand, even current animation hooks would be perfectly enough, IF there would be one that passes into the eventhandler an array/list of actor references involved in the animation (so even if the event gets delayed and SexThread is gone and its actor aliases/properties reset, i would still receive a list of correct actor references).

 

...and i thought i have it all figured out, silly me.

[xTrogdorx]

I don't know shit about scripting, so I can't really help you as far as that goes. But this is exactly the kind of thing I was thinking of when I proposed my 'haunted house' idea a month or two back.

[Pestilencius]

It sounds real promise. Thank you for putting time and effort into this.

[Roggvir]

Tonight, in approx. 5 hours from now, i will upload a short video, showing how it works.

[Slammer64]

Excellent!

[Roggvir]

I was delayed with some RL things, so i got to it just now and i still need to add one small thing.

Should be really quick, but there will be some delay before i can upload that vid, an hour maybe two, sorry for that.

 

EDIT: I broke everything during my last edits, working on a fix.

[Roggvir]

Almost done fixing the whole thing.

I messed up when renumbering FormIDs in Tes5Edit.

Then i thought my furniture scanner doesn't work anymore, so i spent some time with that, but of course it was not broken. I only didnt realized, that the new test area with furniture objects is in another exterior cell and the script is simply scanning for furniture in same cell where player is - no wonder it couldnt find anything - one more reason to ditch that old script already and implement it properly..

Another issue i am currently having, is that the animations suddenly do not line up correctly (not always, its quite random), and some items from Zaz Anim Pack stopped working (actors refuse to equip given items).

 

...so, no video tonight, sorry, dont want to show how broken it is now

[Roggvir]

Progress report...

 

Everything was fixed, but i decided not using SexLab for animating the characters, and implement that part of the code myself.

Not because SexLab would be bad, NO WAY, but because i would need it to do several things a bit differently, and it came to a point where i would need to override too much of its original code, risking i would break it for other mods, not mentioning i didn't asked for a permission as i thought i wouldn't need to make such changes - and even if such permission would be granted, i feel it would complicate things too much to be worth it (since i can avoid any problems by implementing the needed functionality myself).

That being said, the mod will still remain SexLab dependant, as i hope i could still use some of its features.

 

This may sound like a bad thing, but i already made some tests and even though it does add significant amount of work on top of what i still have to do, it also simplifes a lot of other things.

Also, most of the work is already done (for example, SexLab animation threads - i already had something similar, i just needed to add some code to play character anims instead of having SexLab to do that for me), i can use a LOT of what i already did, so you don't need to be afraid it will take weeks before its finished.

 

So, here is my current TODO list:

• Animation threads
  Basic functionality already implemented, need to do some code cleaning and polishing.
  Maybe later add support for fuild transitions between different animation sets having more than 2 actors, allowing actors to join/leave such interactions while keeping the rest of other actors engaged without breaking their poses, etc.
   
• Rework old interactions
  Make neccessary changes to already existing interactions, to reflect the new system using my own animation threads.
  Mostly this means only a rewrite of interaction settings, and related activeMagicEffect scripts used to start them (still using those, to ensure desired modularity - allowing to add new interactions defined by some other mod).
  As i wrote, lots of things are now easier, because i dont need to "bend" SexLab to do what it wasn't made to do, so it shouldn't be much of work.
   
• Implement some unusual kinds of interaction
  What i mean are interactions that are not based solely on animations, but require some other functionality.
  Whipping (or caning) could be one example, i actually decided on not using SexLab also while trying to implement this, because i wanted to utilize the vanilla attack animation which makes wounds to appear on victim's body ("whip marks", if using cane from Zaz Anim Pack, which i intend to), and it was too much of a hassle because SexLab was overriding my package, causing the NPCs to sheat the weapon (cane).
   
• Add support for some SexLab features
  Make my interactions to alter some statistics as SexLab normally does, and see if i can somehow utilize various actor's sexual preferences, and other settings.
  This is at the bottom of the list though, after the more important things are done.

 

Sorry if you were expecting to see some real results, instead of reading about reasons for another delay, but this is a good thing, believe me.