Jump to content

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


Recommended Posts

Posted (edited)
1 hour ago, FieryVortessence said:

I always use my ring finger on w, so trying to use q sounds awful! I never even considered that other people might do that differently, and I can see if you're using the ring finger on a normally, that e and r would feel awful! I dont know if that's what youre doing, but it's an interesting UX data point and I want to make sure this works for everyone. 


1. Ive added variable 'completion scores' that are required to finish the scene, so that means randomly some scenes will be shorter than others, but I've done it using a normal distribution so most scenes will be about the same. But it should mkae Shtick do what I want it to do, which is feel organic and natural... at least as much as it can for a silly 2 button minigame. (This is already integrated in 2.5, which, hopefully I bundled it together right, but it should be working in the version available now)
2. I just finished some 'solo scene' adjustments to make that a little more... interesting. The idea is self-release is going to require a little more effort. Required some conditional rewiring of some of the mechanics. But I think it'll be fun, hopefully. I havent tried it yet. I want to incentivize partnering up.
3. I just downloaded EAP, I need to figure out the EAP stage advancement hooks. I need to get it working in my mod stack, and then figure out the hooks to advance stages and, since the player advances it now, Im hoping this is EASY.... HOPE! If so, I think this would substantially increase the immersion and coolness of the minigame! I didnt even realize something like this was an option! 

Ring finger on W? That's exotic :)

Anyway R and E are ok for now and if they can be remapped in future that would be great.

Only one more suggestion, can You add "Resist (E)" and 'Enjoy (R)' descriptions on oscillator bar? That would clarify this for new players.

 

I hope You will manage to make Shtick progress through AAF scenes and finish with climax, that would really add to experience.

 

I will also test 2.5 version today.

Edited by riveth
Posted (edited)
7 hours ago, riveth said:

Ring finger on W? That's exotic :)

Anyway R and E are ok for now and if they can be remapped in future that would be great.

Only one more suggestion, can You add "Resist (E)" and 'Enjoy (R)' descriptions on oscillator bar? That would clarify this for new players.

 

I hope You will manage to make Shtick progress through AAF scenes and finish with climax, that would really add to experience.

 

I will also test 2.5 version today.


I spent a bunch of time tracing functions and getting frustrated, but I think I finally found a way to support trees.

I added a toggle in MCM in the new 3.1 version. Turn Tree Support on and just let me know if it works at all. In my testing, I know it worked... sometimes? There was also lots of weird behavior, and I'm new enough to EAP that I can't always tell what's normal EAP weirdness and what's Shtick breaking something. And there were some major logical gaps that I attempted to fix and... they may be, or they may be broken. It probably needs some more polish. If it hopelessly breaks everything, turn that tree support off. 
 

I tried to be more clever than smart with it. Maybe it works. Maybe it doesn't. Set your AAF mod scene lengths to [very long] when testing. If the scene never terminates and the meter just keeps resetting over and over, then my trick to prevent that didn't work and I need to go back to the drawing board.
 

My hope is that it kinda-sorta-mostly works in most cases. If it does, just let me know when you find weird edge cases and we can fix those as they come up. That would mean we've at least found a potentially useful control strategy.


I also added q and e as an alternate control scheme. I havent labeled the HUD yet, that's still on the list. Should be easy, just.... out of time to work on it. 

Let me know what you find, I'm eager to hear what your (And others') testing finds. From here if I can get hte HUD labeled, and trees mostly working, I can get back to trying to get it to work on NG. 

Edited by FieryVortessence
Posted
4 minutes ago, FieryVortessence said:


I spent a bunch of time tracing functions and getting frustrated. I think I finally found a way to support trees. I added a toggle in MCM in the new 3.1 version, turn trees on, and just let me know if it works at all. In my testing I know it worked... sometimes? Lots of weird behavior. I cant tell what exactly is normal since Im new to EAP. So I tried to be more clever than smart with it, so.... maybe it works? maybe it doesnt? Set your AAF mod scene lengths to [very long], and if the scene never terminates and the meter keeps resetting, then my trick to try to fix that didnt work and I need to go back to the drawing board.

I also added q and e as an alternate control scheme. I havent labeled the HUD yet, that's still on the list. Let me know what you find, I'm out of time to test it. My hope is that it kinda sorta mostly works in most cases, and then you can just let me know if you find any weird edge cases and we can fix that. If it's a total cluster#%( then I'll go back to the drawing board on it. 

I will gladly test it, but tomorow evening. Need top go to sleep :)

Posted

keeping an eye on this to see how it goes.......

7 minutes ago, riveth said:

I will gladly test it, but tomorow evening. Need top go to sleep :)

Wish i could sleep not had a decent night in over 30 years

Posted (edited)
44 minutes ago, judge007 said:

@FieryVortessence

 

 

 

Still no 1.11.240?

Shtick.jpg

 

So... for what it's worth, just a few minutes ago I tried one last little trick as a Hail Mary attempt to get the thing, as it currently exists, through the gate well enough for Runtime Database to do its job.
 

I originally compiled it using CommonLibF4 library, which makes it OG only. When you guys wanted AE/NG support, I found the CommonLibF4RD library which is specificalyl intended to sort of 'convert' these things to work on the newer versions. CommonLibF4RD + Runtime Database is specifically intended to let one DLL resolve the appropriate addresses across the different Fallout 4 runtimes instead of compiling completely separate versions for everything.
 

The thing I didnt know is that apparently there's also metadata compiled into an F4SE DLL that tells F4SE what runtime/layout families the plugin supports. Since I'm relatively new to this, I changed the library but didn't update that metadata when I originally made the cross-runtime build.
 

Just as an experiment, I recompiled it with the updated metadata so hopefully NG/AE won't immediately reject it before Runtime Database ever gets a chance to do anything.

I can't promise it won't make your computer explode and bring shame on your ancestors, though.
 

Also, before you launch the game, if you run that Collective Modding Toolkit against this DLL, I'd love to see what it says now. 

When you get the game loaded, done faff about trying to start an AAF scene. Just console -> cqf shtickaafquest debugstart  (and later cqf shtickaafquest debugstop ). If it doesn't show up there, it's not going to show up later either. I think you'll be surprised how simple and clean it is if it works. It should IMMEDIATELY pop up as soon as you exit console.


I do have a major request from you though...

Go to your Fallou4/data/f4se/plugins folder, and right click to create a text document. Name it "shticknative.trace", and windows will complain about it being an unstable filename and get mad at you. Ignore it. Say yes you want it to be named .trace. Whether it loads or doesnt load, attach and post that here.


That will tell me whether Runtime Database is able to properly see and parse the runtime addresses in it and convert them. I'd like to compare. This shoudlnt be a difficult to solve problem from what i understand, but if RD and my meta data fixes dont solve it, I'm probably just going to find modern AE/NG compilers and make different versions. It just means if there's an update, I have to do it again when more new versions come out, lol. 

 

Edited by FieryVortessence
Posted (edited)

That tool has saved me countless hours of agro trying to find out why a collection from nexus would not work... One of the reason i got rid of vortex and started to learn mo2 as for collections well the best ones are right here i think...

 

Edited by total newby
spelling
Posted
29 minutes ago, total newby said:

That tool has saved me countless hours of agro trying to find out why a collection from nexus would not work... One of the reason i got rid of vortex and started to learn mo2 as for collections well the best ones are right here i think...

 

I totally agree, but collections and wabbajack are recipes for disaster, with very little support when things go south.

Best to determine for yourself what mods to load together.

Posted

I came late to the PC world when i first saw one as a kid it took 3 people to wheel into the classroom on a trolly how times have changed. The upside is I have probably learnt more by reading and asking questions on this site than anywhere else.. Even though some questions maybe be simple daft ones ..

Posted

I have some news :)

Here's the combination that made it work for me: 

- Game version 1.11.221.0

- Runtime Database (latest Version)
- F4SE Menu Framework (1.53)
- SHtick 3.1

 

I'm now off to mash some buttons! 
:D

ItJustWorks.jpg

Posted

It looks as if also the experimental tree support is working. 
The screenshot shows one animation with several stages (5, I think) that I usually had to change using the arrow keys (left/right). 
With SHtick the stages now move forward automatically (and I can still go back one stage using an arrow key)

 

 

The Tree Just Works too.jpg

Posted (edited)
50 minutes ago, JonX67 said:

It looks as if also the experimental tree support is working. 
The screenshot shows one animation with several stages (5, I think) that I usually had to change using the arrow keys (left/right). 
With SHtick the stages now move forward automatically (and I can still go back one stage using an arrow key)

 

 

The Tree Just Works too.jpg

Does it holds (start and loop for some time) climax stage at the end ? 

For me AAF scene ends as soon as top bar reach left border, no orgasm loop.

 

Also tree progress is a bit hard to spot. Original EAP progress tree for me, leaving possible stage change via arrow keys.

 

Does shtick change them too, it is hard to say, but biggest difference would be climax stage on the end.

 

Does Q and E setup works for You? For me it was always E and R no matter what I set in MCM.

Edited by riveth
Posted
13 minutes ago, riveth said:

Does it holds (start and loop for some time) climax stage at the end ? 

 

For me AAF scene ends as soon as top bar reach left border, no orgasm loop.

 

Also tree progress is a bit hard to spot. Original EAP progress tree for me, leaving possible stage change via arrow keys.

 

Does shtick change them too, it is hard to say, but biggest difference would be climax stage on the end.

 

Does Q and E setup works for You? For me it was always E and R no matter what I set in MCM.

 

  • I had one animation that went until the climax stage and then ended as it should. (I think it was another one from BP70, but can't remember which one).
  • I haven't tested one of those animations where you have the Stages shown by AAF at the bottem left that you can then change with the arrows. I guess that's what EAP is supposed to do. 
  • I only tried E & R for now, as these buttons come naturally me. Will try the alternative next time I run the game. 
  • I also have to test masturbation scenes, as for now my poor survivor hasn't been able to climax being on her own during the maximum scene length of 120 second from Sex 'em Up (and 2 minutes feel like ages already.... ).

 

Posted (edited)

TREES

To @riveth, @JonX67, 

Regarding the EAP tree progression system.... I'm not very familiar with how EAP is supposed to progress through trees normally, or how the scenes from the various animation packs are intended to work.

The way I finally figured out how to do this, based on looking through various position-tree data, is basically to tell Shtick to press the Right Arrow key when its progress bar reaches the end. Shtick then waits for AAF to report an animation change. If AAF advances to another position, Shtick resets the progress bar and we do it again. If AAF doesn't advance, Shtick treats that as the end of the scene.

The tricky part is that some animation packs have special terminal/exit scenes. From looking through the EAP tree XML, some trees seem to simply end when the last normal stage is finished. But others have a special final stage—sometimes apparently using essentially the same position/animation as the previous stage—which is flagged by AAF as an "isExit scene". That's the part I'm still trying to figure out.

I need some reliable way to distinguish:
“We're finished; end the AAF scene now.”
from
“We've reached the final/climax stage; let this play for another X seconds before ending.”

AAF apparently already knows the distinction because the tree data has isExit information, but I haven't yet figured out a clean way for Papyrus/Shtick to interrogate that state and use it.

The current approach may still work surprisingly well because Shtick is basically operating the tree the same way a player would: it virtually presses Right when you fill the progress bar and watches what AAF does in response. So for those of you who have actually used EAP and tree'd animation packs for a while: how are these exit stages normally supposed to behave? Is letting certain final animations run for another ~15 seconds important enough that it's worth carving out special handling for them? And roughly how common are those trees?

When you get the final scene, how do you terminate the scene? Does AAF end it on its own after the 15s or whatever? Do you press right again to end it? I had a hell of a time trying to figure out what it's "supposed" to do there, so it's hard to make a shtick rule for it when Im not sure what it does when manually operated. I kept having final animations that would loop forever and shtick kept resetting the progress bar.... forever, until the AAF mod just reached its max scene length and terminated it.

Here's the root problem:
1. Shtick has to fill its progress bar to advance to the next tree position.
2. Eventually there isn't another ordinary position to advance to.
3. Shtick then has to distinguish “we're done” from “this is a special final/climax position that should play for a while.”
4. The current setup says "No animation change? Then we're done!" to prevent you being forced to watch the same loop forever.

If I can cleanly hook into the isExit information, I think I may have the answer. A lot of the exit stages I've looked at appear effectively instantaneous, while some seem intended to run for around 15 seconds. I haven't found a blanket rule I'm comfortable with yet. For now, if you find an animation where Shtick truncates the ending, please give me the exact animation/position name where it happens. I'll look at that tree specifically and see whether we can derive a general rule from it rather than just adding random exceptions, and it can confirm my suspicion that it's those special +15s animations that I need to build a rule for, or it could be way more general.

I am almost certain there's a way to handle this, I just need to know a little more about how to tell when to let a terminal loop play or when to terminate it.

OH! Last question for everyone: If I can confirm its the scenes with terminal 15s animations before wrapping up that shtick isnt handling correctly, and I can figure out how to make a special rule for those - Are these scenes where you should still need to play shtick? Or should we shut down the NPC progress bar altogether? 
 

In the EAP tree data there are:
1,317 active
isExit="true" branches 

973 have time="0"

272 have no time at all

70 have time="15"

2 have time="16.6"


There are a lot of weird wrinkles in this, too, I just have to find a rule that is reliable and works, and ideally figure out a way to call "isexittrue" and find the target duration of those exits, and I'm just not sure how to get there yet.

Wave Speed
A lot more of you all have played with this now, if the mechanic is vaguely suitable for you - what do you all think about the tempo of the 'waves'? I am pretty sure Im going to add a feature to adjust the pace of the direction changes. I ahve a giant ultra wide monitor, and I have a suspicion the way this is wired up, that it dramatically changes the perception of how fast the thing moves and makes it a little easier or harder to respond on time. I dont know for sure, but it's something that can be tuned. I am looking for feedback here - do you all think a global tempo modifier would be a good idea? Or is everything mostly pretty reasonable? Solo mode is supposed to be a little annoying, but not impossible. 


Control Configuration
Regarding the control schemes, I was worried that wasnt fully fixed. All of that seems wired in a ready to go, no idea why it's not working yet. I'll go back to the drawing board with it.

Edited by FieryVortessence
Posted (edited)
30 minutes ago, FieryVortessence said:

TAAF apparently already knows the distinction because the tree data has isExit information, but I haven't yet figured out a clean way for Papyrus/Shtick to interrogate that state and use it.



If you want to research in that direction, what I could advise you to experiment with is
- Test for the OnAnimationEnd event received
- Test for the AAF_Busy keyword on the player

If the OnAnimationEnd event was received , and yet the AAF_Busy keyword is still on the player/other actors in the Scene,  it means it is in that "Exiting" mode. 
Take all this with a grain of salt, it is just empirical observation.

 

Edited by MSM_Alice
Posted
43 minutes ago, FieryVortessence said:

make a special rule for those - Are these scenes where you should still need to play shtick? Or should we shut down the NPC progress bar altogether? 

I imagine when top bar reach the end, shtick stops anything and climax stage is played once, then AAF stops. If it need time restrictions like 10 sec. I recommend to make it adjustable via MCM.

 

I also don't understand Shtick progression. What bar did You meant saying it need to be filled to progress tree? Top one or the bottom?

Posted (edited)
12 minutes ago, riveth said:

I imagine when top bar reach the end, shtick stops anything and climax stage is played once, then AAF stops. If it need time restrictions like 10 sec. I recommend to make it adjustable via MCM.

 

I also don't understand Shtick progression. What bar did You meant saying it need to be filled to progress tree? Top one or the bottom?


Top bar is meant to represent "NPC arousal" in base shtick, but I suppose in tree form it is more blatantly an progress meter. Bottom bar is playable character arousal level, while the main avatar you're manipulating increases or decreases the arousal rate. 

Edited by FieryVortessence

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...