[WIP] Furniture Interaction Framework - for NPCs and Player

[Roggvir]

 

Done testing the beds, and as i thought - no problems.

 

I tested it with Arrok Doggy Style animation, and both actors stay exactly where i put them (i didnt set the offsets correctly yet, so they were both "inside" the bed, but that proves even more their imunity to collision problems).

So, yep, works.

Good to know, keep up the great work!

 

I noticed some issues with bedrolls myself, namely that participants will hover as if there was a bed beneath them when selecting to use the nearby bed. Do you think your tempering will also fix that?

 

 

Yes, these problems do not exist in my mod.

 

All actors are firmly fixed on their dynamically placed markers (thanks to ZaZ who made them), and those markers are positioned depending on the furniture in use - if its bedroll, their Z position will be properly offset to make the actors appear lying on the bedroll and NOT flying above it, if its a bed then they will be again in appropriate height.

 

The interactions are always started within specific furniture context, or empty one (if no furniture is needed or the action is supposed to happen on ground).

Either way, the system always knows which offset values to use for the given context (specific furniture, or nothing).

[Musje]

Now, i dont like this, because it seems too complicated for what it does, so i would like to make it less complicated.

Maybe i misunderstood some things about the package procedures i am using, and so i am doing things thay may not be neccessary.

But most importantly, it is flawed, rarely causing the NPCs to get stuck when they were operating in a detached cell - once player returns, he can sometimes see such NPC to just idling, standing still.

Usually it helps to just bump into such NPC, to "wake him up", then he resumes the pickup process, picks up his sword or whatever, the pickup process finishes and the NPC then goes about his business.

Sometimes it takes a very looooong time until such NPC "wakes up", and even the bumping doesnt help.

I dont know what is causing this, but it must have something to do with the poor design of this pickup process, so i welcome any ideas on how to properly redesign it, to make it 100% reliable.

 

I'm not sure how you could make the pickup process simpler, but isn't the problem with the fact that the actor is in a detached cell?  I recall noticing some oddness trying to manipulate the inventory of an Actor in a detached cell before.

 

[Roggvir]

 

Now, i dont like this, because it seems too complicated for what it does, so i would like to make it less complicated.

Maybe i misunderstood some things about the package procedures i am using, and so i am doing things thay may not be neccessary.

But most importantly, it is flawed, rarely causing the NPCs to get stuck when they were operating in a detached cell - once player returns, he can sometimes see such NPC to just idling, standing still.

Usually it helps to just bump into such NPC, to "wake him up", then he resumes the pickup process, picks up his sword or whatever, the pickup process finishes and the NPC then goes about his business.

Sometimes it takes a very looooong time until such NPC "wakes up", and even the bumping doesnt help.

I dont know what is causing this, but it must have something to do with the poor design of this pickup process, so i welcome any ideas on how to properly redesign it, to make it 100% reliable.

 

I'm not sure how you could make the pickup process simpler, but isn't the problem with the fact that the actor is in a detached cell?  I recall noticing some oddness trying to manipulate the inventory of an Actor in a detached cell before.

Yeah, i guess that has definitely something to do with the problem, but it happens only sometimes, which makes me think that i am missing some rare circumstance for which i need to check and somehow handle.

 

The package procedure alone shouldn't have problems with detached cells - from my experience, various other procedures are working ok even in detached cells, which i'd say is kind of their point - to drive the NPCs even if player isn't around, thats why some things may happen "in the meantime" and not only when player is present in given cell (typical example would be the travel procedure).

 

But i dont know enough about how these procedures really work, especially under these circumstances, when a cell is detached.

Otherwise, i am not really doing anything with NPCs inventory - at least right now - for testing, i removed the part where it adds the item to NPC inventory if the cell is detached, so now it is supposed to try the next item in queue (which it skips too, and so on).

So, after it processes the whole queue, all the items should stay lying around, but the script and package should finish, and the NPC should be free to go about his business - but sometimes it doesn't happen, which makes me think that the check for Is3dLoaded() fails, sometimes returning true even if the cell is detached, making the queue stuck, because the package is trying to use Acquire procedure (which maybe cannot work in detached cell).

 

...i will test with the Is3dLoaded replaced by parentCell.IsAttached() to see whether that's the problem.

I am using Is3dLoaded primarilly to check whether someone else picked up that item, and thought it will also work as a check for if the cell got detached - but maybe it doesn't work for that, or not reliably.

[Roggvir]

btw. this is the actorAlias script:

scriptname RoggFF_AliasActorP extends ReferenceAlias
{FurnitureFramework alias script for pickup items procedure}

#ifdef DEBUG
#define	LOG(MSG)	Debug.Trace(__BASE_FILE__ +"("+ __LINE__ +"): "+ pickupQuest +" - "+ MSG)
#endif

quest property pickupQuest auto hidden
objectReference[] property itemRefs auto hidden
int property itemIndex auto hidden
objectReference property itemRef auto hidden
referenceAlias property itemAlias auto hidden

event OnItemAdded(form item, int count, objectReference ref, objectReference srcContainer)
	LOG("OnItemAdded - item: " + item)
	LOG("OnItemAdded - ref: " + ref)
	LOG("OnItemAdded - src: " + srcContainer)
	if ref == itemRef
		self.GetActorReference().EquipItem(item, false, true)
		AssignNextItem()
	endif
endEvent

function AssignNextItem()
	while itemIndex
		itemIndex -= 1
		itemRef = itemRefs[itemIndex]
		LOG("fetched item at index " + itemIndex + ": " + itemRef)
		if itemRef
			LOG("item " + itemIndex + " owner is " + itemRef.GetActorOwner())
			itemAlias.ForceRefTo(itemRef)
			RegisterForSingleUpdate(1)
			return
		endif
	endWhile
	LOG("All items picked up, switching state to empty.")
	GotoState("")
endFunction

state RUNNING
	event OnBeginState()
		pickupQuest = self.GetOwningQuest()
		LOG("state entered")
		itemAlias = pickupQuest.getAliasByName("aliasItem") as referenceAlias
		itemIndex = itemRefs.length
		itemRef = none
		LOG("Actor: " + RoggLib.GetActorIdString(self.GetActorReference()) + ", ITEMS: " + itemRefs)
		AssignNextItem()
	endEvent
	event OnUpdate()
		if !itemRef || !itemRef.Is3DLoaded()
			AssignNextItem()
		else
			RegisterForSingleUpdate(1)
		endif
	endEvent
	event OnEndState()
		itemRefs = new objectReference[1]
		LOG("Clearing aliases...")
		itemAlias.Clear()
		self.Clear()
		LOG("leaving state")
	endEvent
endState

[zax]

Stage 3

Various "action" animations for both actors (those we already have).

Do we really have any furniture based scene with multiple furniture markers being used (like vanilla HeadChopBlock)?

 

Everything I have seen so far is one actor actually "sitting" and the other being moved by SexLab playing normal idle.

[Roggvir]

 

Stage 3

Various "action" animations for both actors (those we already have).

Do we really have any furniture based scene with multiple furniture markers being used (like vanilla HeadChopBlock)?

 

Everything I have seen so far is one actor actually "sitting" and the other being moved by SexLab playing normal idle.

 

Umm, sorry but i do not understand your question, or point in general.

Could you rephrase it please?

[zax]

^not sure if serious, but I will explain anyway.

 

Each furniture can have multiple markers (chair has one, but bench is usually 2 or 3). They usually trigger same "sitting" idle, but there are exceptions. ExecutionerChoppingBlock is one of these vanilla exceptions where different idles are triggered on different furniture markers (executioner, ececutionee etc).

 

You mentioned that we have many of those, so it made me wonder which ones you had in mind? Because I have yet to see player made furniture with multiple markers and different animations for each of them. Usually they were semi-furniture animation scenes with one actor actually sitting and the other being controlled by SexLab (playing non-furniture idle in sync with the first actor).

[Roggvir]

^not sure if serious, but I will explain anyway.

 

Each furniture can have multiple markers (chair has one, but bench is usually 2 or 3). They usually trigger same "sitting" idle, but there are exceptions. ExecutionerChoppingBlock is one of these vanilla exceptions where different idles are triggered on different furniture markers (executioner, ececutionee etc).

 

You mentioned that we have many of those, so it made me wonder which ones you had in mind? Because I have yet to see player made furniture with multiple markers and different animations for each of them. Usually they were semi-furniture animation scenes with one actor actually sitting and the other being controlled by SexLab (playing non-furniture idle in sync with the first actor).

 

Ahaaa :-D

 

You completely misunderstood what i tried to say there (my bad).

I was talking about animations, in general, nothing to do with real furniture markers (i am used to call a "furniture marker" those dynamic objects i am placing and locking the actors to, i should stop doing that because ppl confuse it with the real furniture 'sit' markers defined in furniture NIFs).

 

I was talking about things like "ZazAPPillSXHip01A" and corresponding "ZazAPPillSXHip01B", etc. - i call these "action" animations, as in "that sex thing is going on right now" - those we already have plenty, but what we do not have (or only for very few types of "action" anims) are the pre/post action animations, that would make actors to properly stand up, etc.

 

Let me use a different example: Arrok Doggystyle

They come with sexlab - Arrok_Doggystyle_A1_S1/2/3/4 and Arrok_Doggystyle_A2_S1/2/3/4

And there are no "pose transition" animations - nothing to make the actor to get on her knees from a standing pose, and vice versa.

 

That's what i meant we dont have - for example, i make the actor walk to a bed and sit on its ledge to wait for another actor to arrive so they can start sexing, all nicely fluid and animated, but then i have no transition from that sitting pose (or whatever the pose would be) to that animation pose, the actor will just do that strange interpolated bone transition movement dance - better than nothing, yes, but... actor was sitting, and suddenly BANG! and he is on his four in the middle of the bed - must be some magic ;-)

[Roggvir]

Progress update...

 

Minor, but important redesign of actor control scripts

Changing how the actor offset settings are defined and how they work, to allow specifying different offsets for when walking to a furniture/marker, then for an idle pose, and then for actual interaction when the actors are being actively animated.

I was already using different offsets for "idle" and "action" positions, but it was kind of half-assed implementation, so i am making it proper now.

 

It will allow me to place markers at different position when actor is walking to the furniture, completely removing the "moon walk" dance that sometimes happens when the marker is placed inside the furniture and actor is trying to walk to it but the furniture collision doesnt let him, and so he walks on spot for a short time before the game realizes he's as close as he can ever get.

It will then allow me to move the marker to the spcified "idle" offset position, so i can make the NPC sit on the ledge of a bed, instead of having him standing in front of it, or on top in middle of it.

And again moving the marker to the "action" offset (which depends on selected interaction), ie. in the middle and on top of the bed, etc.

 

Sorry for introducing another delay before releasing the mod, it must look like i am bullshitting you or teasing everytime i promise that release is comming and then i delay it once more

But i can't help it, when i see something that bothers me, i just have to address it, fix it, or improve it.

[Arhon]

Bah teasing is fine, just release it when you think its ready to be tested/broken/killed/destroyed alot before it's reborn like a phoenix into the perfect form.

[Roggvir]

Somehow i got sick, looks like a flu or the like, so i didn't actually do anything during last few days, and also probably wont do anything for next few days (unless the headache stops, can't think because of it).

[equarent]

Hi Roggvir, are there any news? I sure many people waiting this release...

[karlpaws]

Losing a month due to sickness... must have been some flu.

 

I had an idea that came up while playing around, moving an animation that started the right one, in the right location, in the right position.

 

There are standing idle locations in some places, so the NPC can stand against a tree in a bandit camp, wall in town, post or pillar in a variety of places, and it seems these would be fitting for a lot of the standing sex animations, where either one lifts the other or they just stand and french/grope/have sex standing up.

 

Any chance some of those could be used for "standing" animations? It might take something extra from the SL framework, but I thought you'd mentioned using "real" chairs in place instead of spawning ones into random locations, so it might be similar to that.

[Roggvir]

Hi Roggvir, are there any news? I sure many people waiting this release...

 

Sorry, i didn't made any progress since the last time.

I was too busy with some real life crap, and also became quite annoyed with Papyrus and lost the neccessary enthusiasm (it happens periodically - as a perfectionist, i become frustrated, being unable to do things the perfect way because of game/papyrus limitations).

Now i am about to resume working on it, but i need to take a step back to take a look at what i have and redefine my goals a bit (some things proved impossible to implement, so i need to filter those out and focus on the rest).

I expect to post a more detailed progress report in next few days.

[Roggvir]

Losing a month due to sickness... must have been some flu.

 

I had an idea that came up while playing around, moving an animation that started the right one, in the right location, in the right position.

 

There are standing idle locations in some places, so the NPC can stand against a tree in a bandit camp, wall in town, post or pillar in a variety of places, and it seems these would be fitting for a lot of the standing sex animations, where either one lifts the other or they just stand and french/grope/have sex standing up.

 

Any chance some of those could be used for "standing" animations? It might take something extra from the SL framework, but I thought you'd mentioned using "real" chairs in place instead of spawning ones into random locations, so it might be similar to that.

 

Probably not, because if i remember correctly, i have no way to detect these idle markers and get their position or rotation.

Same problem concerns walls, fences, etc. ...well, at least i dont know about a way to detect these objects, so unless someone else finds a way. its a no go.

This is an example of those "impossible to implement" features i mentioned in my previous reply

[Musje]

Nice to hear that you are picking this up again.    Eagerly awaiting the first beta.

[Roggvir]

So, i finally made that video i promised a looong time ago.

Its nothing fancy, it just shows that technically it kind of works.

...still a lot of visual glitches (scaling up/down when starting interactions - most of which i can get rid of, so it shouldnt be that bad in the end), and the NPC voices doesnt really fit the animations much, or the situations sometimes, but the dialog is mostly just a placeholder to show how it should work.

 

http://www.naughtymachinima.com/video/15084/skyrim-furniture-interaction-framework-test

[Kircheis-]

This is some amazing stuff!

[iron_jack]

That looks amazing, for real, dude.

[Boss Ninjato]

Congrats for this progress so far ! Amazing Work!

[Roggvir]

Thank you all, glad you like it.

It helps to boost my enthusiasm a bit

 

I may later post some more videos showing how certain things work in more detail (how it works when player is involved, the MCM menu with threads and furniture library, difference in flow of certain different types of interaction).

 

Now about the plan for nearest future...

There are two things i want to implement or change right now:

1. Chaining different interactions
   I want it to be possible to progress through several interactions without releasing the actor.
   Right now, if you/NPC initiates lets say oral sex, and you'd want to switch to vaginal sex after a moment, the script need to "release" the actors from the thread after finishing with the oral, and then start the thread again for the fucking.
   I want to make changes that allows to switch between different types of interactions seamlesly (scripting-wise, not animation-wise - that would be possible only if there are transitional animations between given poses).
   Another example: i want to be able to start pillory whipping where the ActorB is standing farther away from ActorA, and then switch to pillory fucking, having ActorB to just walk one or two steps closer to where he needs to be for that kind of interaction, and without releasing the ActorB (which currently needs to be done at the end of each interaction) and reassigning ActorB again into same thread but now for a different interaction.
    
2. Make it purely standalone (even ZAP will be optional)
   Right now, the plugin depends on you having also the Zaz Animation Pack installed - the ZaZAnimationPack.esm is set as a master.
   Even though my primary focus was on making it work with ZAP furniture, i do realize that not everyone wants or needs that, so even though it will be still supported by default, i want to make it optional like everything else.
   It will also serve me as sort of an "exercise" to test if the optional functionality works as intended.
   So, by default, the framework will only recognize vanilla furniture, and anything else will be supported via optional furniture and interaction libraries in separate ESPs (yes, it adds yet another plugin ESPs to your load order, but you can always merge the plugins, or maybe i will provide merged versions for the most common combinations later).

After this is done, i might feel like releasing the first alpha (yeah, i know what you think... promisses... again ).

 

[wickedcandle3]

This looks really good! Can't wait for your first release!

[43deadwood]

This looks absolutely incredible - can't wait to see how it develops.

[Puupsfred]

looking forward to this. Keep up the good work!

[Leito86]

Sounds promising!