Shtick - A New AAF Participation Minigame BETA WIP!!!

[FieryVortessence]

3 hours ago, JonX67 said:

V 0.5.6 is working quite nicely!
It may not yet grab all stages of all animations, but as they can still be moved manually it's still an improvement to the game without your mod. 

 

Not sure, though, how it would be in a play where you have lots of AAF scenes, because the overall scene duration increases quite drastically. 
But for the occational "cut-scene" it's perfect!

 

Yeah Ive been brain storming some kind of work around for that for a while. Ideally I'd ahve an MCM switch to turn Shtick off, and it would revert the scene lengths to normal. And I can make a switch, but since it's external json files, papyrus cant rewrite those. It also can flip a switch for what hte game references, but as I understand it, youd have to restart the game anyway. Im asking dagoba on the AAF discord to see if there may be some kind of function we can eventually call in the next version of AAF, but then that creates a hard AAF requirement for hte super duper most recent version of that.

But for now, even if I put a switch in MCM to disable Shtick, it cant change the .jsons with tree scene lengths in game, you'd have to exit and restart the game, and I just decided if you have to do that, it's easier to just disable in vortex so what's the point?

It's a real problem, I dont have an answer yet beyond that you just have to pick, and I dont really think that's acceptable. I'm going to give it some time and see if any ideas come to me.


The tree support is still spotty, but I'm getting really close I think to having all of the main ones I have incorporated. The big gap is the Sam Enhanced animation set doesnt have EAP trees, they're just loose files, and right now im referencing EAP's tree system. 

As part of a potential solution, I thoguht about just having a lookup table in Shtick of all the scene sets of loose scenes, and you could just disable EAP and shtick would do it on its own without needing EAP, but it would still mean Shtick and EAP cant both be installed at the same time, because EAP and the default tree lengths will just end the scene before shtick gives you a chance to. I have to think about it a while longer. 

 

53 minutes ago, JohnyBurner said:

 

Can these keys be assignable in MCM? I currently use Numpad 0 for Beggar Whore mode toggle, for instance.

 

Also, full disclosure, I still haven't tried this, I've been modding stuff myself these days with very little free time, but I'm very keen to try it out! It's a great idea!

Is there an established key for this sort of thing? I can use any key without having to 'claim' the key for shtick exclusively. But I have no idea what hte best one is. And because Shtick is a DLL that is checking what keys youre pressing I'm intentionally trying to keep the number of keys it can see very, very small for privacy reasons. Right now it can only see 4 keys, Q, E, R, and 0. 

Edited Friday at 04:17 PM by FieryVortessence

[JohnyBurner]

@FieryVortessence, I really don't think there's a convention for this, but I use the Numpad 0 because it wasn't being used by any of my mods. So if there are concerns regarding key listening, it is indeed a good choice. I can always make a different choice for the other mod, so it's not a big deal.

[FieryVortessence]

38 minutes ago, JohnyBurner said:

@FieryVortessence, I really don't think there's a convention for this, but I use the Numpad 0 because it wasn't being used by any of my mods. So if there are concerns regarding key listening, it is indeed a good choice. I can always make a different choice for the other mod, so it's not a big deal.

I feel like I remember Harassment or Hardship giving you keys 0-9 to activate for options - for that reason I've moved it to U. I dont think there's any good reason to press u during an aaf scene, and it's meant to signify User-interface. 

I made some final updates. I think Shtick is now in a 'feature-complete' state, but not a bug-free state. Everything I wanted to integrate into it is now integrated. We iterate to V1.0.0 based on bugs and problems everyone finds and my attempts to get rid of it. 

It would be nice to have voice feedback during scenes, but custom dialogue during AAF scenes seems difficult to execute well, but it's an awesome idea.

Edited Friday at 08:13 PM by FieryVortessence

[riveth]

23 minutes ago, FieryVortessence said:

I feel like I remember Harassment or Hardship giving you keys 0-9 to activate for options - for that reason I've moved it to U. I dont think there's any good reason to press u during an aaf scene, and it's meant to signify User-interface. 

I made some final updates. I think Shtick is now in a 'feature-complete' state, but not a bug-free state. Everything I wanted to integrate into it is now integrated. We iterate to V1.0.0 based on bugs and problems everyone finds and my attempts to get rid of it. 

It would be nice to have voice feedback during scenes, but custom dialogue during AAF scenes seems difficult to execute well, but it's an awesome idea.

is it possible to make txt config file where ppl could set keys? Shtick could read this config and everyone could easly change key mapping as they see fit?

- I tried latest version and indeed most scenes progress through Shtick - very nice!
- sometimes animations stops even when top bar was not full - are those "dissapointingly short" situations You mentioned about? If so, it would be cool to have some debug message, that your partner ended early or something.

- XP bonus info shows for a split second then is refreshed and I never have a chance to actually see what kind of xp amount I earned.
Maybe You could add utility.wait(10) to make them appear 10 seconds later?
- is it possible to make Shtick "tell" player what kind of scene it is? I mean sometimes IDK if I should resist or enjoy. I could use some info, for instance oscilator bar could be red on rape, or word "rape" visible somewhere?

[FieryVortessence]

31 minutes ago, riveth said:

- sometimes animations stops even when top bar was not full - are those "dissapointingly short" situations You mentioned about? If so, it would be cool to have some debug message, that your partner ended early or something.

- XP bonus info shows for a split second then is refreshed and I never have a chance to actually see what kind of xp amount I earned.
Maybe You could add utility.wait(10) to make them appear 10 seconds later?
- is it possible to make Shtick "tell" player what kind of scene it is? I mean sometimes IDK if I should resist or enjoy. I could use some info, for instance oscilator bar could be red on rape, or word "rape" visible somewhere?

Is it possible to make txt config file where ppl could set keys? Shtick could read this config and everyone could easly change key mapping as they see fit? - Not really, that part of it has to be set in the .dll itself. I have to change it and then recompile it. Im not averse to adding a third control config if you want, though. But three might be the limit, just want to figure out which limited batch makes the most people happy. It may be a foolish to not just open it up. One idea I had was to open the whole top row of the keyboard. 

1. Sometimes animations stops even when top bar was not full - are those "dissapointingly short" situations You mentioned about? - Absolutely not. The duration indicated on the progress bar is what determines when Shtick is willing to end the scene. If it's terminating before hte red bar is full, the AAF scene initiator is terminating the scene.  (If this is trees, did you get the EAP overrides loaded in after EAP? ) AAF doesnt have a universal command to "delay terminating scene", so this extra book keeping for you until I can figure out a way to bypass AAF's scene ending command. 

2. XP bonus info shows for a split second then is refreshed and I never have a chance to actually see what kind of xp amount I earned. - That's interesting, are you running more than 60 FPS? Less? I can just make them last longer but they're there for about a second for me. I just didnt want them intrusive but I can make them hang around longer, that's not a problem, Im just worried the timing is different on your setup than mine.

3. Is it possible to make Shtick "tell" player what kind of scene it is? I mean sometimes IDK if I should resist or enjoy. I could use some info, for instance oscilator bar could be red on rape, or word "rape" visible somewhere? - That's actually a really good idea....  It'd need to be something unintrusive but clear. But I can totally do something like that. 

Edited Friday at 09:16 PM by FieryVortessence

[riveth]

1 hour ago, FieryVortessence said:

Absolutely not. The duration indicated on the progress bar is what determines when Shtick is willing to end the scene. If it's terminating before hte red bar is full, the AAF scene initiator is terminating the scene.  (If this is trees, did you get the EAP overrides loaded in after EAP? ) AAF doesnt have a universal command to "delay terminating scene", so this extra book keeping for you until I can figure out a way to bypass AAF's scene ending command. 

Lookslike one of staged animations is broken, it stops aaf as soon as it reach first scene marker (point on top bar where scene should change to next one.) I forgot to write it down, but I will let You know next time I spot that problem. The thing is, when bug occurs it is already too late to write anything down

As for XP, I run 40fps due to DLSS5 mod. 

Anyway, mod feels really fun to play right now, thnx!

[FieryVortessence]

3 hours ago, riveth said:

Lookslike one of staged animations is broken, it stops aaf as soon as it reach first scene marker (point on top bar where scene should change to next one.) I forgot to write it down, but I will let You know next time I spot that problem. The thing is, when bug occurs it is already too late to write anything down

As for XP, I run 40fps due to DLSS5 mod. 

Anyway, mod feels really fun to play right now, thnx!

I had today off and spent all day trying to refine the tree recognition system, there were a lot of holes. The data was there, but not everything was able to check back to its original root position. At this point, I think every single tree that's in EAP SHOULD be mapped into Shtick. There were about 400/900 that werent 12 hours ago. 

But if this happens again, grab your papyrus log for me and I'll see if I can figure out why that tree isnt traversing correctly. Just make absolutely sure your AAF Scene initiator isnt terminating the scene early. I've found that if Shtick can see all the stages, and you can see the checkpoints on the top bar, it should play the whole thing out unless AAF terminates it first, or unless there's something weird about the way that one is logged in my lookup table. Now, I have to caveat that by saying there's a list of handshakes that have to happen in sequence for the scene to change without issue, so there's a lot of weird specific issues that can crop up in that chain, but I've had a ton of tables that wont load, and a lot of other weird issues during testing, but I never saw one terminate early before the red bar filled, so hopefully what you saw is really isolated. But its hard to keep track of all the weird edge cases that can pop up in this thing. At this point it's really all based on just knowing what scenes are in what trees, and where the trees start, and that's based on EAP data which had to be extracted and converted and transformed. So a lot of transformations, filters, and maps to make all of it track correctly. 

Also thanks for the feedback, I'm really glad you're enjoying it. It's a pretty crazy idea and I put a lot of work into it already, way more than really makes sense. It means a lot that people are getting some enjoyment out of it. 

Edited Saturday at 02:40 AM by FieryVortessence

[FieryVortessence]

14 hours ago, riveth said:

Lookslike one of staged animations is broken, it stops aaf as soon as it reach first scene marker (point on top bar where scene should change to next one.) I forgot to write it down, but I will let You know next time I spot that problem. The thing is, when bug occurs it is already too late to write anything down

As for XP, I run 40fps due to DLSS5 mod. 

Anyway, mod feels really fun to play right now, thnx!

I havent tested yet, but I made a small change to make the wave-indicator blocks red during non-consensual scenes. It fits the native UI logic for Fallout in a sense. And it's fairly unintrusive but obvious at the same time. XP notifications are now larger and take longer to fade out. This is 0.8.2. 

Also, remember, there are weird states that can cause scenes that SHOULD be nonconsensual to be consensual due to itneresting situations that Sex Attributes intentionally wires in. perks and debuff states. Its not always super obvious what condition you're in, so as an additional little bonus you can actually visually see whether your AAF mod is tagging the scene as NC or not. 

Edited Saturday at 01:27 PM by FieryVortessence

[riveth]

testing latest version and I found that bugged scene:
FM_SC - FloorBlowjob S1 Tease

as soon as NPC arousal reach point to change stage to S2, progress bar stopps, no matter what I do.
I see transition to next stage. but then animation quits AAF. 

Tested same animation triggered by Violate and via AAF menu, results are the same.


 

[JonX67]

9 hours ago, riveth said:

testing latest version and I found that bugged scene:
FM_SC - FloorBlowjob S1 Tease

as soon as NPC arousal reach point to change stage to S2, progress bar stopps, no matter what I do.
I see transition to next stage. but then animation quits AAF. 

Tested same animation triggered by Violate and via AAF menu, results are the same.
 

 

Yep,
had the same but during another staged animation. 
I didn't have the AAF HUD open, so I can't say which animation it was. 

But it was definitely a different one. 

 

This was with version 0.8.5

[FieryVortessence]

Thanks for the reports! 

The really important thing is that we know which scenes this happens on. If I can figure out which scene is broken, I can trace the logic through the chain and figure out why. my hope is that I can over time eliminate all the edge cases. 

 

	<tree id="FM_SC_FloorBlowjob_Tree" strictExiting="true">
		<branch id="Tease" positionID="FM_SC - FloorBlowjob S1 Tease" forceComplete="true" time="20">
		<!-- <branch id="Start" positionID="FM_SC - FloorBlowjob S2 Start" time="20"> -->
		<branch id="S3 Blowjob" positionID="FM_SC - FloorBlowjob S3" time="25">
		<branch id="S4 Blowjob" positionID="FM_SC - FloorBlowjob S4" time="20">
		<branch id="S5 Facefuck" positionID="FM_SC - FloorBlowjob S5 Facefuck" time="20">
		<branch id="S6 Facefuck" positionID="FM_SC - FloorBlowjob S6 Facefuck" time="20">
		<branch id="Climax" positionID="FM_SC - FloorBlowjob S7 ClimaxLoop" time="20">
		<branch id="Finish" positionID="FM_SC - FloorBlowjob S8 Finish" time="0" isExit="true">
		</branch>
		</branch>
		</branch>
		</branch>
		</branch>
		</branch>
		<!-- </branch> -->
		</branch>

This is from the EAP Tree data.... I think that "forcecomplete=true" may be the wrinkle. I've never used EAP until it was suggested here, now I see why everyone likes it. But that means I havent seen these in their native environment very often. Any idea what "forcecomplete=true" means? According to the spreadsheet I just made, ~40% of SC's animations ahve that tag. So if that's what the issue is, it affects 40% of them. But at this point I hope it is, because that means we can make a fix for it. 

Also, far more alarmingly, the SC xml file says above one of these:

"    <!-- Do not reduce the "Tease" stage time. This breaks the sequence of playback of stages --> " 

That warning isnt really very well documented as applying to ALL of these, it appears to only flag either a specific one, or the 6 that are below it depending on interpretation. 

I think we might have just found the problem, though. My hunch is all those "force complete=true" scenes need to be exempted from my time overrides, and I'll probably let it time out as normal - total arousal score required will stay the same to complete the full tree, but completion will not override the length of those particular scenes. That's where I'm leaning now. It opens up some problematic wrinkles I'll have to iron out, but .... it's solvable, and it's signficant. 


Edit: I was wrong, this is absolutely about forcecomplete, but it's requiring a bit of a rethink. I'll keep you posted. I think it's solvable. 

Edited 15 hours ago by FieryVortessence

[FieryVortessence]

On 10/10/2026 at 4:39 PM, riveth said:

testing latest version and I found that bugged scene:
FM_SC - FloorBlowjob S1 Tease

as soon as NPC arousal reach point to change stage to S2, progress bar stopps, no matter what I do.
I see transition to next stage. but then animation quits AAF. 

Tested same animation triggered by Violate and via AAF menu, results are the same.


 

 

 

 

I think I cracked it. Force complete scenes progress on an arrow press like any other scene, and shtick literally just virtually presses right arrow. Such amazing, So advanced! I know. 😆

But, what happened is I had to ship an EAP positiontree.xml override patch to make sure AAF didnt progress scenes before Shtick did. 
I also applied a little failsafe that if no new scene was selected, it would auotmatically time out. This was essentially meant to be kind of an emergency scene terminator. I had originally planned to block access to the arrow keys and AAF HUD, but I decided we all need console access, so we all need access to the AAF hud/controls in case of emergency. The block and the timeout to help get around it - It's just not useful, not needed, and it's causing problems, so it's gone. I then had to make major adjustments to my override table to make room for Force complete scenes in trees. 

So basically, before:

1. Shtick says "Scene complete! Right arrow!"
2. AAF said "I hear you, but we have to wait because it's tagged to have to complete before progressing, it has [very long] seconds left!"
3. Shtick says "No scene change in 8s? ERROR DETECTED! Stop current scene, select new one!". 

I have painstakingly identified every force complete scene, and then restored them to their authored durations, so what happens NOW is
 

Now:

1. Shtick says "Scene complete! Right arrow!"
2. AAF said "I hear you, but we have to wait because it's tagged to have to complete before progressing, it has [whatever] seconds left!"
3. Shtick says "okay! waiting on you!" but progress is held until then
4. Since the default length is restored and there is no error detection reset, you wont ahe to wait long for the scene to shift, but Shtick has to finish AND AAF has to finish the scene before it can progress (This is my understanding of how it works, so this is my intent of how it should work, if it doesn't I need to go back to the drawing board)
5. Shtick SHOULD lock progress if you 'beat' AAF's timer, it will continue once you get to the next scene

 

 

Let me know if terminal scenes now dont end. I think they will? But there may be special case finales that dont end, let me know if that happens. 

 

I havent tested enough to know (is there even a way to force start a specific scene? I have no idea how, would make this a LOT easier) if this is going to work as smoothly as I hope it does, but I am optimistic we're getting closer to something reliable. Based on my spreadsheet, we may have fixed an issue on something like 20% of all the trees included with EAP. I know specifically the Savage Cabbage that contained the scene riveth found, 40% of that set had force complete tags that would have forced shtick to abort the tree. So you may have just helped me fix a HUGE blindspot in my code and scripting logic!

In summary, potential new failure states of this update: 

1. Shtick 'completes' a scene, and the scene goes on way too long.
2. Shtick completes a full tree and it never terminates (HUD will say "Position Exiting", tehse are hte ones Im most worried about)

Pull up the hud, tell me the scene that does it, and I'll fix it in my table or figure out how to apply special rules to ending scenes. 
 

 

Edited 12 hours ago by FieryVortessence