Devious Devices Framework Development/Beta

[krzp]

Anybody play with GoToBed or something of the sort? (what I mean, is do you have some way of seeing your character actually use the bed and see those animations)

 

Armed with the new-found Blender knowledge, I've made a few new animations to make the experience a little better.

For armbinder-type devices only, but if there is interest, I could probably try expand it at to a few other devices that can work with that.

 

Packed for the SE's OAR conversion, if you're on DAR - rename the folders accordingly, if you're still on FNIS - stop using FNIS, lol ?

DD_armbinder_bed_enter_exit_sleep_animations.7z

[Guest]

On 7/27/2023 at 1:07 PM, dieer said:

 

 Thanks for the testing, and you are right $ is neccessary in the json files.

I've added them, and is going to test everything now that i can.

 

Damn it, it still crashes when opening the menu.

 

Found the error, gonna update the files soon.

 

New file is up.

 

 

Just tested the v4 file in my setup and no crashes or freezing this time!  It works for me.   Using the Simple Item Spawner mod I opened up the DD - Expansion.esm and was able to see the icons for all of the items.  They look good!  I think it probably was related to the .swf file because when I made the changes to the jsons I had, it still would freeze up.  Glad you were able to resolve it!

[krzp]

Trying to learn how to Blender properly (... see you all in ten years... ), I've made this.

 

You know how when your character equips a blindfold, they suddenly develop super powers of magic sonar abilities, and just stroll around as normal, like they know where to go?

Was it just me who were annoyed by that?

 

*yes it was, 0 downloads, ok* ?

 

So, anyway, this is a walk and run animation with the condition to play whenever a zad_deviousBlindfold is equipped.
 

Spoiler

 

 

I've no clue on how should the backwards walk animation look, though, so at the moment this has front/left/right.

I'll try to make an the idle for this set next, as soon as I understand what looks good and makes sense. ✌️ 

 

Feedback is appreciated!

 

P.S. Packed, as usual, for the SE's OAR conversion, if you're with SE's DAR - rename the folders, these are the conditions:

Spoiler

IsFemale() AND
NOT IsChild() AND
NOT IsWornHasKeyword("Devious Devices - Integration.esm" | 0x062539) AND
NOT IsWornHasKeyword("Devious Devices - Integration.esm" | 0x060A46) AND
NOT IsWornHasKeyword("Devious Devices - Integration.esm" | 0x0866B8) AND
NOT IsWornHasKeyword("Devious Devices - Integration.esm" | 0x05F4BA) AND
NOT IsWornHasKeyword("Devious Devices - Integration.esm" | 0x08A76C) AND
NOT IsWornHasKeyword("Devious Devices - Integration.esm" | 0x063AD9) AND
NOT IsWornHasKeyword("Devious Devices - Assets.esm" | 0x02C531) AND
NOT IsWornHasKeyword("Devious Devices - Assets.esm" | 0x00CA3A) AND
IsWornHasKeyword("Devious Devices - Assets.esm" | 0x011B1A)

P.P.S Credits for the animations I've edited: running - regular Skyrim, walking - Victoria HH walk

 

 

edit: grab the updated version about 4 posts down from here ?

 

 

 

Edited August 2, 2023 by krzp

[naaitsab]

7 hours ago, krzp said:

 

I've no clue on how should the backwards walk animation look, though, so at the moment this has front/left/right.

I'll try to make an the idle for this set next, as soon as I understand what looks good and makes sense. ✌️ 

 

 

That's also the issue I'm facing with animating. The procedure itself is not that hard, just slow and annoying. But getting it look natural is a whole other business. ? 

For backwards you could try a more sliding motion. That puts a focus on careful moving.

[krzp]

I guess my question is "WHO THE HECK RUNS BACKWARDS WITH A BLINDFOLD ON AND HOW IS IT SUPPOSED TO LOOK" ?

 

23 minutes ago, naaitsab said:

For backwards you could try a more sliding motion. That puts a focus on careful moving.

This marvellous idea outclasses my talent level by a couple of very important levels, but I'll try! ?

I also thought of maybe turning the char's head sideways, making the elbows more rigid so they sorta act as safety dampers.

 

If that fails to look good, I have a semi cop-out idea of just turning the character around and having them face the camera, like most of the 360 mods do - I think DD also does that with the hobbled anims, if i remember correctly...

[Guest]

18 hours ago, krzp said:

Feedback is appreciated!

Tried it out, looks like you forgot to use the OpenAnimationReplacer folder in your folder structure.  I wondered why it wasn't showing up when viewing in the in-game editor for OAR until I checked and realized it was missing that folder.

[krzp]

2 hours ago, DonTheDime said:

looks like you forgot to use the OpenAnimationReplacer

Thank you very much, now that was a dumb screw up on my part ?

 

I also noticed that I've named the left and right animations incorrectly, it's not supposed to be "walkforwardleft", it's just "walkleft" & "runleft".

Apparently, I was a little low on coffee when assembling this yesterday.

 

I've re-attached the fixed file.

 

Edited July 31, 2023 by krzp

[krzp]

Ok, I've tried my hand at the backward blindfolded animations, and also made an idle.

 

Feedback is appreciated, hopefully I didn't mix up the directories this time ?

(this archive the contains previous ones too)

 

Spoiler

 

 

 

DD_OAR_blindfold_walk_run_v2.7z

Edited August 1, 2023 by krzp

[krzp]

So I've Blendered yet another thing for myself (hey, this actually turned out to be a fun endeavour) .

 

I remember playing the Cursed Loot mod, and at the inn thingie, half of the Contraption devices there were missing their struggle animations. Which is kinda boring and unfinished, right?

 

Made a Pole - front Facing, Pole - back facing, Restraint Post*, and and X-cross struggles.

Now, X-Cross did have a struggle idle before, but I kinda thought it wasn't... struggle-y enough, so I've edited it a bit to be more pronounced. ?  Thinking of doing an OAR randomizer of the OG struggle and my edited version, that should be cool, if anyone's interested - i can share the config later.

 

 

Spoiler

 

 

 

 

 

I don't know about their quality, but to me this sure beats having no animations at all. ?

 

Feedback is always appreciated.

 

edit: check out the v2 version down below!

 

Edited August 3, 2023 by krzp

[Frayed]

@krzp Oh, these are great. I was hoping someone would tackle the missing DDC struggle animations. The X-cross and front-facing pole ones look great, no issues. But the back-facing one makes my character grow an extra elbow near her shoulder:

Spoiler

(Ouch!)

 

Might be due to differences in weight paints between my player model and whatever you used to make the animations - the shoulders tend to look pretty bad for me whenever the arms are raised above the head, not just for this animation. But I think it's also visible in your screenshot, just less dramatic due to lighting/normal/specular differences.

 

I couldn't get the restraints pole animation to work, even after updating the FNIS_DDC_List.txt file and re-running FNIS (or Nemesis). Is there another file that needs to be edited, maybe?

 

I think it's also possible to add the X-cross struggle as a separate animation without OAR. The furniture scripts support picking from multiple. But that would require some more setup with the animation files and some CK work to add new packages and such. It's probably more sensible to ship a single base animation for every device, then handle any possible alternate animations people make via something like OAR. Much more modular and easy that way.

 

The blindfold walking animations are pretty great, too, by the way ?

[krzp]

31 minutes ago, Frayed said:

@krzp Oh, these are great.

Yay, feedback, thank you  ?

 

31 minutes ago, Frayed said:

(Ouch!)

Totally agree, that's an ouchie right there - it looks similar to how it looked in my Blender, but it did look better in-game for me. I'll try to tweak the shoulder position and arm rotation for the next revision, so it's less extreme!

 

31 minutes ago, Frayed said:

I couldn't get the restraints pole animation to work, even after updating the FNIS_DDC_List.txt file and re-running FNIS (or Nemesis). Is there another file that needs to be edited, maybe?

Hmm, to be honest, i've replaced the already registered restraintpole_idle.hkx to test, but I assumed if DD actually bothered to register a separate _Struggle for it (even if it registered the same idle twice under different names in utter contempt of FNIS animation slots, lol), it would be calling for it as well - but maybe it forgot to do that in the scripts? I'll get back to you when I check the script for contraptions, maybe something is there.

 

While I do that, you can check it out by temporarily replacing the existing restraintpole_idle, but the side effect would be that the character would start twitching as soon as they get in the device ?

 

31 minutes ago, Frayed said:

It's probably more sensible to ship a single base animation for every device, then handle any possible alternate animations people make via something like OAR.

That's my plan after I finish with the Blender shenanigans, I wanna try to cut down on DD filtering it's animations thru scripts and keywords, and let OAR handle that.

 

Maybe, at some point, we can even aim at the holy grail of complaints - the animation filter? What if DD's animation filter actual didn't filter, but let OAR replace the SL animations with their bound versions or something like that? Idk if that's even possible, but the possibility is intriguing to at least try ?

Edited August 2, 2023 by krzp

[Frayed]

Right, good idea. I just renamed the restraint post animation to _idle for now to check it out: I like it, but it has some quirks. First one is that the chains don't move. I get why, it's probably a lot more work to get that to look right, so I think that's fine for now. Second one is that as the feet move, the ankle bands move with them. But the bands are supposed to be attached to the metal bar. They even detach completely for a few frames:

 

Spoiler

 

I assume the ankle bands are attached to the player model, not animated separately or attached to the pole? There's two solutions I can see:

• Simple: just decrease the feet movement a little bit so that the bands do not detach completely. It'd still be a little illogical, but it would be far less apparent.
• More complex: attach the bands to the pole model, redo the feet part of the animation to accommodate.

I do like the feet movement here, so I would be hesitant to remove it entirely. In general, I like all of these animations! They're nicely enthusiastic.

[Gameplayer]

So recently, I have added DAR Devious Devices animations for MCO compatibility from over here, https://www.loverslab.com/topic/99700-devious-devices-se/page/110/#comment-3077930

 

I have been using, Dynamic Random Female Idles V2 mod.

Heavily modified the conditions text, but have not been able to restrict certain animations to only play with chastity belt.

I've managed to get aroused conditions to work though with my idle's so that the females in game gradually go from unconfident to confident to sexually frustrated and the selection of idle animations sort of pulls that off.

 

What I would like to see is that Devious Devices which has a lot of frozen in place idle animations, that freezes the player in place for duration of the animation might well select some animations and not have them freeze the player.  So with DAR\OAR idle's we can have a whole selection of conditional idles that play under the correct circumstances.

An example would be chastity belt struggle, why freeze the player in place?  When that animation could be showing up in the sequence reminding the player the character is belted.

Much of the animations dont have to be a pick this one or that one anymore, even idles that do not always require sound can be relegated to a dynamic idle system, giving the player more freedom which I know I know might not be the point of DDI, but it would make for sequential playthroughs a bit less tedious., at least with lighter DD mod loads.

 

I've been playing modded Skyrim and have assisted even the DDI team with work, for many years.  Back then we did not have something like DAR/OAR or all these really interesting combat mods that allow for new behaviors.  

 

Well anyway, I hope to see more from Devious Devices and its mod authors in time and want to encourage compatibility with these new systems.

 

[krzp]

@Frayed using your feedback, much thanks, I've re-adjusted those.

 

The restraint post one, I've moved a feet dynamically a little bit to sort of align with the metal bar. The metal cuffs still move, but hopefully staying within the dimensions of the bar itself - I didn't realize they moved so much when I first did it. I don't think I can make the cuffs stay completely in one place, otherwise I must keep the legs in rigid and that basically kills the lower half of the animation ?

 

Regarding the moving chains - I'm afraid that's might be waaaaaaay above my "I've been using Blender for a week" level. ? Mostly in a technical sense, though - I can probably make them move with the character, that sound doable with enough tinkering and patience - but I've absolutely no clue how to make them actually a part of the animation, as, i think, right now they are just a static RestraintPostChainsAO.nif, and I only know how to export human skeletons and movements... So, if anyone with more animating chops than me can take a stab at it, I'll gladly share my .blend file with the animation itself. Or if anyone has a good blender to Skyrim tutorial on dealing with animobjects, that'll work too. ?

 

Renamed it to restraintpole_idle.hkx in the archive, so it can be tested more easily, 'till I figure out why the struggle doesn't work.

(I saw a separate struggle entry in the Contraptions.esm with my xEdit, so I'm a bit lost at the moment and open to suggestions)

This will replace the idle one, be aware of that, whoever tries them ?

 

The back-facing one - that one is completely on me, I was trying to cut the corner a little bit and rotated the first one I've created by 180*, and in doing so, inadvertently twisted the skeleton in some weird way completely beyond repair. ? Soooo... had to re-do it from scratch. The new one's a little different, I've fixed the arms position to conform with the idle better too.

 

I've also created 2 new ones, the Pole - high, and the Pole - on the knees one.

 

Spoiler

 

 

 

 

 

That leaves one more, the Pole - Sitting one, I'll do it as soon as I figure out how do I want it to look.

 

Feedback, as usual, is extremely appreciated. ?

 

edit: v3 is a few posts down from here

 

Edited August 4, 2023 by krzp

[krzp]

6 hours ago, Gameplayer said:

Heavily modified the conditions text, but have not been able to restrict certain animations to only play with chastity belt.

Try the IsWornHasKeyword -> zad_DeviousBelt

 

Should look something like this in your json:

 {
            "condition": "IsWornHasKeyword",
            "requiredVersion": "1.0.0.0",
            "Keyword": {
                "form": {
                    "pluginName": "Devious Devices - Assets.esm",
                    "formID": "3330"
}

 

6 hours ago, Gameplayer said:

Well anyway, I hope to see more from Devious Devices and its mod authors in time and want to encourage compatibility with these new systems.

As the resident "PLEASE STOP USING FNIS AA FOR MOVEMENT IN 2023 FOR THE LOVE OF ALL THAT'S HOLY" crier, I wholeheartedly support this message! ? ?

Edited August 3, 2023 by krzp

[Frayed]

17 hours ago, krzp said:

[snip]

Feedback, as usual, is extremely appreciated. ?

 

Then I will again provide!

 

Restraint post: good fix, that works! Getting the chains to move is probably not easy. You'd probably have to rig them to their own nodes/skeleton, then animate them. Could be an interesting learning exercise, but certainly not needed for now - the animation looks great as it is.

Front-facing pole: I didn't notice before, but there's a few frames where both feet leave the ground, but there's no apparent gravity visible in the animation. Given the speed of the animation, you probably intend it to be more "alternating standing on different feet" than hopping, so there should probably be at least one foot touching the ground at all times.

Back-facing pole: my PC's arms thank you ?

Kneeling pole: Looks good, no comments. I could nitpick about shoulder warping again, but that's really Skyrim's problem, not yours.

Pole - high: great animation! But I do have two comments: 1) the elbow pop when the arms go from full extension to flexed and back seems slightly off. I think it's two things: they move maybe a bit too much, and the timing is slightly off - they don't pop at maximum extension, but before. 2) In this one the PC essentially falls/slides for a bit, but it happens it a way that feels a little too slow/smooth for what visually looks like an uncontrolled fall/slide. This is also something for the front and back-facing pole: you can probably make the parts of the animation where gravity acts a bit more snappy.

 

That's it - great work! I'm very happy with these, and with your timing - I was hoping to use one or more of these contraptions in Trappings soon, and them having struggle animations makes it so much better.

[Guest]

The basic equip and unequip functions work and I'm currently working on equipping rendered devices. There's two approaches I've been mulling over:

1. Precompute a JSON/YAML file that maps each inventory device to a rendered device. Load this into a hashmap on game startup and we have really fast lookup times to get the device on without needing to worry about script property access time. This file would need to be updated any time new devices are added or the rendered device changes.
2. Ditch the double device system entirely. We can now intercept equip/unequip attempts and do what we need to which effectively eliminates the need for the original implementation. This would be a cleaner system but I'm certain this would create incompatibilities with older mods (which may still be tracking rendered items) for not that much of a performance boost. Practically, this could be an ESL that adds the ARMA records to the inventory devices. The ESL could probably be generated using a zEdit patcher.

Any thoughts?

Edited August 3, 2023 by ponzipyramid

[krzp]

8 hours ago, Frayed said:

Then I will again provide!

Thank you, this is grand!! I always get a little too caught up in the "woo hoo it actually moves" excitement, so this greatly helps to notice the parts that I've overlooked ?

 

Front-facing pole you're absolutely correct on the intention - I've went back to it and adjusted it a little, plus animated the other bones some more, so it should be a bit livelier now. The gravity effect still isn't exactly how I've wanted it to be, I might return to it once I get more experience, but at least there are no sudden levitation powers ?

 

Pole - high: 1) I've tried raising the character a tiny bit, so the arms don't lock in the max extension at the start, hopefully that looks more realistic - kept it one time mid-animation to emphasize the slide down, but I'm open to "this still looks unnatural" 2) Ah, this was sort of intentional, the idea was that the char tries to do this sort of a push up to try wiggling the hands out free, but fails to hold position and disappointingly slides back down, hence the "cat slowly going down the curtains" move   ? I thought of trying to do the "throw the body down to break out", but I liked how this one looked a bit more. Still, though, I've tried tweaking the movement graphs a little off your suggestion, so it's just a little faster - plus, fixed the feet clipping issue in a couple of frames.

 

And I've made the final Pole - Sitting one! This one, I think, is better suited to the "Break Device" name rather than the "Struggle".

 

Spoiler

 

So, with that done, that should be all for the missing struggles in Contraptions. Open to feedback and more tweaking, as always!

 

please make more mods with Contraptions, they are horribly underutilized  ?

DD_Contraptions_struggles_v3.7z

[Bane Master]

13 hours ago, ponzipyramid said:

Precompute a JSON/YAML file that maps each inventory device to a rendered device. Load this into a hashmap on game startup and we have really fast lookup times to get the device on without needing to worry about script property access time. This file would need to be updated any time new devices are added or the rendered device changes.

An excellent idea - FSM already caches this information in memory for the (small number of)  dDs it uses. Can I suggest you consider storing the device key and number of keys required also, as these use similar functions/resources to access properties via the framework at present.

[GreatCroco]

21 hours ago, ponzipyramid said:

The basic equip and unequip functions work and I'm currently working on equipping rendered devices. There's two approaches I've been mulling over:

1. Precompute a JSON/YAML file that maps each inventory device to a rendered device. Load this into a hashmap on game startup and we have really fast lookup times to get the device on without needing to worry about script property access time. This file would need to be updated any time new devices are added or the rendered device changes.
2. Ditch the double device system entirely. We can now intercept equip/unequip attempts and do what we need to which effectively eliminates the need for the original implementation. This would be a cleaner system but I'm certain this would create incompatibilities with older mods (which may still be tracking rendered items) for not that much of a performance boost. Practically, this could be an ESL that adds the ARMA records to the inventory devices. The ESL could probably be generated using a zEdit patcher.

Any thoughts?

Not a fan of precomputing a hashmap, as it creates the need for possibly another external file to keep track and in sync. If we want to go that route it'd probably be a better choice to make sure that rendered devices always have a fixed offset from their non-rendered counterparts, assuming a 1:1 relation between those two and compute "base_id + offset = display_id".

There's another problem: load orders. Since the six character long hex id is not guaranteed to be unique, the load order position also needs to be included as well. This MUST be done on the user's side, making them run an external tool. Not the best UX, imo.

 

If this isn't a breaking change and not the system already in use, it'd probably be better to have a property on the devices where you set the record of the rendered device. This indirection is decently fast and you avoid possible I/O bottlenecks if the mappings isn't cached on startup/load.

 

 

The second system is probably the better choice, as it still depends on an external tool (assuming we'd go the ESL route), but this only needs to be done once by the developer.

 

 

[Guest]

I went ahead with the first approach since it was straightforward and from some preliminary testing it seems to work well. I didn't perceive any additional latency on startup (though this is somewhat hardware-dependent) and there was a small improvement in responsiveness when equipping through the inventory. Here's the zEdit patcher I made to generate the JSON file: DDGen.zip and here's the final generated JSON file for Integration and Expansion: devices.json. Not particularly useful on its own but if you're interested there it is ;).

 

1 hour ago, GreatCroco said:

Not a fan of precomputing a hashmap, as it creates the need for possibly another external file to keep track and in sync.

 

We're always going to have an extra file to maintain whether that be the ESL that patches the armor records or this JSON file.

 

1 hour ago, GreatCroco said:

There's another problem: load orders. Since the six character long hex id is not guaranteed to be unique, the load order position also needs to be included as well. This MUST be done on the user's side, making them run an external tool. Not the best UX, imo.

 

Form lookup is done using the function TESDataHandler::LookupForm(FormID a_localFormID, std::string_view a_modName) so getting the devices is load order independent as long as the mod name is known. This patcher only needs to be run by maintainers if there are armor record changes.

 

EDIT: Rough benchmark yields a startup latency of about 44ms.

Edited August 4, 2023 by ponzipyramid

[Kimy]

On 7/23/2023 at 4:22 AM, johntrine said:

hey. sorry to take the space and your guy's time.... but ok. so here is the thing.

back in the day, there used to be a mod called city bondage (would get some info here.

what it basically did was equipped dd devices when your character reached a city and remove it when you left said city. it was a neat mod but since the dev stopped updating it and it was outdated, he deleted it.

till recently, he had allowed people to mess with his mod but recently he said this

 

 

Convert: allowed

Share: not allowed

 

Though I might be open to granting permissions to someone if they're willing to convert the LE version to DD 5.x as well as a fully-supported SE/AE version...

 

proof here.

i was curious if someone here had the time and talent to do that?

 

I can add a similar feature to DCL. It might take a while before I get to it, though!

[Kimy]

On 8/3/2023 at 11:45 PM, krzp said:

Thank you, this is grand!! I always get a little too caught up in the "woo hoo it actually moves" excitement, so this greatly helps to notice the parts that I've overlooked ?

 

Front-facing pole you're absolutely correct on the intention - I've went back to it and adjusted it a little, plus animated the other bones some more, so it should be a bit livelier now. The gravity effect still isn't exactly how I've wanted it to be, I might return to it once I get more experience, but at least there are no sudden levitation powers ?

 

Pole - high: 1) I've tried raising the character a tiny bit, so the arms don't lock in the max extension at the start, hopefully that looks more realistic - kept it one time mid-animation to emphasize the slide down, but I'm open to "this still looks unnatural" 2) Ah, this was sort of intentional, the idea was that the char tries to do this sort of a push up to try wiggling the hands out free, but fails to hold position and disappointingly slides back down, hence the "cat slowly going down the curtains" move   ? I thought of trying to do the "throw the body down to break out", but I liked how this one looked a bit more. Still, though, I've tried tweaking the movement graphs a little off your suggestion, so it's just a little faster - plus, fixed the feet clipping issue in a couple of frames.

 

And I've made the final Pole - Sitting one! This one, I think, is better suited to the "Break Device" name rather than the "Struggle".

 

  Reveal hidden contents

 

So, with that done, that should be all for the missing struggles in Contraptions. Open to feedback and more tweaking, as always!

 

please make more mods with Contraptions, they are horribly underutilized  ?

DD_Contraptions_struggles_v3.7z 50.13 kB · 31 downloads

 

Silly question, but is this for LE or SE?

[Kimy]

On 7/21/2023 at 11:29 AM, krzp said:

Let's give it a little jump start ?

 

I've tried to collect all the tweaks to 5.2 that I have and remember where I got them:

1. Bodyslide bone fixes for 3ba by ihatemykite
2. New animations by iivanvv (+ some of them in form of a DAR patch)
3. DAR/OAR SE, LE version
4. New movement script for OAR/DAR
5. Small fixes by Taki17
6. Swimming animations by iivanv
7. CommonLibNG DLL by ponzipyramid
8. HDT chains fix by PredatorRJ
9. Stagger fix SE
10. Gag fix by ihatemykite
11. SKSE expressions performance increase SE by ihatemykite

I think all of those combined might be worthy of a start of a discussion for the 5.3 beta at this point?

And I didn't even collect the proposed code changes, this is only ready to be merged stuff.

 

And a lot of those are SE-specific, so this is a good time to renew that discussion too... ?

 

If I have forgotten anything, please post them too ?

 

Thanks for that list! Like every year, I am currently spending some time in The Big Room (we got a really nice summer here), but I will soon start to merge these and release the first 5.3 Beta!

[krzp]

18 minutes ago, Kimy said:

Silly question, but is this for LE or SE?

Ah, those are SE, but I can make you an LE version later today, I've worked out a way to convert SE animations back to LE ?

 

On a semi-related note, I've sent you a dm about a certain dev-related question