Devious Devices Framework Development/Beta

[MellowDrama]

is there a SE conversion of the DD 5 beta?

 

[Taki17]

Could the "manipulate device" toggle be expanded the cover the availability of the feature for DDc items as well?

[Mister X]

25 minutes ago, lucakro said:

is there a SE conversion of the DD 5 beta?

 

Short answer: No, it isn't.

 

Longer: You probably can do it easily by yourself, just use Cathedral and replace the SKSE plugin of the DD beta with the one of the v4.x conversion. There were no changes in the plugin, as stated by Kimy, so you'r good to go. For some other potential porting problems, Kimmy added some code snippets by request, so the scripts should also be robust enough.

TBH, I already use the latest beta as base for my new mod for SE, DMC, where the most potential will unfold with DDv5 ^^

[Kimy]

9 hours ago, YojimboRatchet said:

you know, thanks for this. at least someone did get what i was trying to do. this is helpful.

 

as for the other 2 replies. i also worked IT, i was a QA Lead and a System Analyst. and what i did was do an "application impact" assessment. which is a common and thorough process to assess the impact of changes. the fact that the responses were not objective, and more defensive than anything, tells me more than i needed to know. i obviously wasted my time doing this, i expected better.

 

i am glad though that someone actually got what i was trying to get at, and went further than i expected. so at least i am appreciative of that. thank you hungvipbcsok

It's hilarious how you complain about the replies you're getting not being super objective, when you started your own post by indicating that I am just out to build a monopoly, and apparently everyone BUT me is a shining hero of modding whose work I set out to destroy. And then providing a list of seemingly random mods you accuse me to break, without providing ANY evidence to back up your claim.

 

Did you REALLY expect an objective response to that?

 

If you're a QA person, you could have went over that list of yours and determined within seconds that DD5 has absolutely no chance to break about half of all mods on your list, for starters because they're not even using the DD framework. You could also have wondered how an edge case like VirginMarie's mod should somehow be symptomatic for literally every other mod out there, when both she and I agree that the problem her mod has is highly specific to hers.

 

Furthermore, you could have refrained from trying to make me look even more evil by bloating your list with some mods that are KNOWN to be broken and obsolete even now and have been for years. Like... Captured Dreams? The mod that got pulled by its own author and isn't even available anymore? Seriously?

 

And last, but not least, can the QA professional explain to me why except SLAV, not a SINGLE other DD mod has been reported here to be problematic, despite the DD5 beta version got downloaded by a fairly large number of testers, and the beta phase has been going on for a month now? When according to your post, DD5 is apparently wrecking the better part of all BDSM mods on LL? Are you assuming that none of them has any DD mods other than DCL installed?

 

You also seemingly missed the entire point of beta testing, which IS to figure out if there are issues in DD5, including compatibility issues. If I am oh-so evil, why oh why, am I even doing this when I could have just as easily published the thing and be done with it?

 

I will be open here: In all these years I have been maintaining DD, I barely ever made a change that broke anything in existing mods. That's how evil I am! The biggest one I can think of was in DD4, when the various keywords for wrist restraints got merged into one, to allow for a much cleaner implementation of wrist restraints, indirectly leading DD to now offering a much greater variety of them.

I really value backwards-compatibility. But if I really, really feel that a change potentially causing issues with existing mods is warranted, I will make this change. As DD developer, my obligation is to make DD the best framework it can be, not freezing the status quo forever, just so that some outdated relic mod can continue to run. It is still my belief that if a legacy mod is sufficiently popular, somebody will eventually update it. Or write a new version of that mod (I did that when Deviously Helpless broke, which was a mod I really loved, so I implemented most of its functionality in DCL to keep the idea alive). If a broken mod is remaining broken for years, chances are that it's not THAT important, quite honestly. All software eventually breaks. It's just the nature of things. And it has nothing to do with anyone being malicious or trying to build a monopoly.

[Mister X]

@YojimboRatchet Two small questions:

 

One, isn't it the purpose of a framework to be kind of a monopol? So, widespread and often used? I mean, you've got SL and FlowerGirls, but how many mods rely on those two? Same goes for DD and ZAP. Or take XPMS(S)E, that doesn't even have an alternative. You have monoplistic framework mods with many, many addons. 

Two, for your list of "breaking" mods: did you take the date of the last mod update and/or the date of a loadorder post into account?

 

Oh and besides, in my eyes it's funny how you thank hungvipbcsok for a post, where he basically states that you're wrong 

[Kimy]

@VirginMarie:

 

I had a look at the filter code, and believe that I can solve the issue with "magic devices" without a new keyword, even. I made the following changes to the filter code:

 

; Returns true if anal sex on this actor is blocked.
;
Bool Function IsBlockedAnal(Actor akActor)
    Return (akActor.WornHasKeyword(libs.zad_DeviousBelt) && !akActor.WornHasKeyword(libs.zad_PermitAnal)) || (akActor.WornHasKeyword(libs.zad_DeviousPlugAnal) && !akActor.WornHasKeyword(libs.zad_PermitAnal)) || (akActor.WornHasKeyword(libs.zad_DeviousHobbleSkirt) && !akActor.WornHasKeyword(libs.zad_PermitAnal))
EndFunction

; Returns true if vaginal sex on/by this actor is blocked.
;
Bool Function IsBlockedVaginal(Actor akActor)
    Return (akActor.WornHasKeyword(libs.zad_DeviousBelt) && !akActor.WornHasKeyword(libs.zad_PermitVaginal)) || (akActor.WornHasKeyword(libs.zad_DeviousPlugVaginal) && !akActor.WornHasKeyword(libs.zad_PermitVaginal)) || (akActor.WornHasKeyword(libs.zad_DeviousHobbleSkirt) && !akActor.WornHasKeyword(libs.zad_PermitVaginal))
EndFunction

 

So if you'd tag your belt, suit and plug devices with the existing keywords zad_PermitAnal or zad_PermitVaginal, the filter should ignore them.

 

Can you let me know if that solution is satisfactory?

[DeWired]

10 minutes ago, Kimy said:

@VirginMarie:

 

I had a look at the filter code, and believe that I can solve the issue with "magic devices" without a new keyword, even. I made the following changes to the filter code:

 

; Returns true if anal sex on this actor is blocked.
;
Bool Function IsBlockedAnal(Actor akActor)
    Return (akActor.WornHasKeyword(libs.zad_DeviousBelt) && !akActor.WornHasKeyword(libs.zad_PermitAnal)) || (akActor.WornHasKeyword(libs.zad_DeviousPlugAnal) && !akActor.WornHasKeyword(libs.zad_PermitAnal)) || (akActor.WornHasKeyword(libs.zad_DeviousHobbleSkirt) && !akActor.WornHasKeyword(libs.zad_PermitAnal))
EndFunction

; Returns true if vaginal sex on/by this actor is blocked.
;
Bool Function IsBlockedVaginal(Actor akActor)
    Return (akActor.WornHasKeyword(libs.zad_DeviousBelt) && !akActor.WornHasKeyword(libs.zad_PermitVaginal)) || (akActor.WornHasKeyword(libs.zad_DeviousPlugVaginal) && !akActor.WornHasKeyword(libs.zad_PermitVaginal)) || (akActor.WornHasKeyword(libs.zad_DeviousHobbleSkirt) && !akActor.WornHasKeyword(libs.zad_PermitVaginal))
EndFunction

 

So if you'd tag your belt, suit and plug devices with the existing keywords zad_PermitAnal or zad_PermitVaginal, the filter should ignore them.

 

Can you let me know if that solution is satisfactory?

Hm. So, wearing plug would block access, but equipping open belt over it will permit it? It looks... iffy.

Problem is, I see only those solutions:

0. Leave as is - so putting on belt suddenly allows sex.

1. If Permit keyword is detected, and wearing plug - plug is extracted at start and put back on end. Mechanics of such manipulation aren't exactly clear...

2. Examine actual weared devices for keywords - if permit is on plug or on belt, and device accordingly. Requires more deep inspection - and rises complexity of checks.

3. Introduce new permit keywords specifically for plugs - will require many ESP changes.

I honestly don't know, what is less wrong... ?

[DeWired]

Also, @Kimy - another suggestion. Sometimes, things happen and devices got broken. Right now, the only easy option to restore order is to use Terminate option in MCM - but it unequips everythings and breaks quests. So - I have a suggestion of adding another function - which try to do a soft cleaning. I made a version of it, that requires a FormList (FormList Property zadTemporaryDeviceStorage Auto), is meant to be called same way as Terminate, and works very slow - but it actually doesn't unequip anything that is equipped and work.

Spoiler

; Remove broken DD items from the player. 
Function DDI_DebugClear()
	Armor idevice = None
	Armor rdevice = None
	Form kForm = None
	Int RemovedItems = 0
	zadTemporaryDeviceStorage.Revert()
	Int i = PlayerRef.GetNumItems()
	bool clearAll = True
	While i > 0			
		i -= 1
		kForm = PlayerRef.GetNthForm(i)	
		If (kForm As Armor)
			if kForm.HasKeyword(zad_InventoryDevice) && PlayerRef.IsEquipped(kForm)
				idevice = kForm As Armor
				if idevice
					ObjectReference tmpORef = PlayerRef.placeAtMe(kForm, abInitiallyDisabled = true)
					zadEquipScript tmpZRef = tmpORef as zadEquipScript
					if tmpZRef != none && PlayerRef.GetItemCount(tmpZRef.deviceRendered) > 0
						rdevice = tmpZRef.deviceRendered as Armor
						zadTemporaryDeviceStorage.AddForm(rdevice)
						clearAll = False
					Endif
					tmpORef.delete()
				Endif
			Endif
		Endif
	EndWhile
	i = PlayerRef.GetNumItems()
	While i > 0			
		i -= 1
		kForm = PlayerRef.GetNthForm(i)
		if (kForm As Armor)
			if kForm.HasKeyword(zad_Lockable) && !kForm.HasKeyword(zad_InventoryDevice)
				Int c = PlayerRef.GetItemCount(kForm)
				if clearAll
					PlayerRef.RemoveItem(kForm,c,true)
				else
					Int j = zadTemporaryDeviceStorage.GetSize()
					bool removeRendered = True
					while j > 0
						j -= 1
						rdevice = zadTemporaryDeviceStorage.GetAt(i) as Armor
						if rdevice == kForm
							removeRendered = False
						EndIf
					EndWhile
					if removeRendered
						PlayerRef.RemoveItem(kForm,c,true)
						RemovedItems += c
					elseif c > 1
						c = c - 1
						PlayerRef.RemoveItem(kForm,c,true)
						RemovedItems += c
					Endif
				Endif
			Endif
		Endif
	EndWhile
	Notify("DDI Debug broken item removal completed, " + RemovedItems + " items removed.", MessageBox = False)
	zadTemporaryDeviceStorage.Revert()
	;Utility.Wait(1)
EndFunction

 

I didn't test it extensively, but - it worked for me, it didn't delete anything that was actually equipped (shown in inventory), and it deleted some items that were present only as rendered items.

[Kimy]

4 minutes ago, DeWired said:

Hm. So, wearing plug would block access, but equipping open belt over it will permit it? It looks... iffy.

Problem is, I see only those solutions:

0. Leave as is - so putting on belt suddenly allows sex.

1. If Permit keyword is detected, and wearing plug - plug is extracted at start and put back on end. Mechanics of such manipulation aren't exactly clear...

2. Examine actual weared devices for keywords - if permit is on plug or on belt, and device accordingly. Requires more deep inspection - and rises complexity of checks.

3. Introduce new permit keywords specifically for plugs - will require many ESP changes.

I honestly don't know, what is less wrong... ?

Ugh, you're right. I need to check for that keyword on the device itself, not if it's worn anywhere on the actor.

[Kimy]

4 minutes ago, DeWired said:

Also, @Kimy - another suggestion. Sometimes, things happen and devices got broken. Right now, the only easy option to restore order is to use Terminate option in MCM - but it unequips everythings and breaks quests. So - I have a suggestion of adding another function - which try to do a soft cleaning. I made a version of it, that requires a FormList (FormList Property zadTemporaryDeviceStorage Auto), is meant to be called same way as Terminate, and works very slow - but it actually doesn't unequip anything that is equipped and work.

  Hide contents

; Remove broken DD items from the player. 
Function DDI_DebugClear()
	Armor idevice = None
	Armor rdevice = None
	Form kForm = None
	Int RemovedItems = 0
	zadTemporaryDeviceStorage.Revert()
	Int i = PlayerRef.GetNumItems()
	bool clearAll = True
	While i > 0			
		i -= 1
		kForm = PlayerRef.GetNthForm(i)	
		If (kForm As Armor)
			if kForm.HasKeyword(zad_InventoryDevice) && PlayerRef.IsEquipped(kForm)
				idevice = kForm As Armor
				if idevice
					ObjectReference tmpORef = PlayerRef.placeAtMe(kForm, abInitiallyDisabled = true)
					zadEquipScript tmpZRef = tmpORef as zadEquipScript
					if tmpZRef != none && PlayerRef.GetItemCount(tmpZRef.deviceRendered) > 0
						rdevice = tmpZRef.deviceRendered as Armor
						zadTemporaryDeviceStorage.AddForm(rdevice)
						clearAll = False
					Endif
					tmpORef.delete()
				Endif
			Endif
		Endif
	EndWhile
	i = PlayerRef.GetNumItems()
	While i > 0			
		i -= 1
		kForm = PlayerRef.GetNthForm(i)
		if (kForm As Armor)
			if kForm.HasKeyword(zad_Lockable) && !kForm.HasKeyword(zad_InventoryDevice)
				Int c = PlayerRef.GetItemCount(kForm)
				if clearAll
					PlayerRef.RemoveItem(kForm,c,true)
				else
					Int j = zadTemporaryDeviceStorage.GetSize()
					bool removeRendered = True
					while j > 0
						j -= 1
						rdevice = zadTemporaryDeviceStorage.GetAt(i) as Armor
						if rdevice == kForm
							removeRendered = False
						EndIf
					EndWhile
					if removeRendered
						PlayerRef.RemoveItem(kForm,c,true)
						RemovedItems += c
					elseif c > 1
						c = c - 1
						PlayerRef.RemoveItem(kForm,c,true)
						RemovedItems += c
					Endif
				Endif
			Endif
		Endif
	EndWhile
	Notify("DDI Debug broken item removal completed, " + RemovedItems + " items removed.", MessageBox = False)
	zadTemporaryDeviceStorage.Revert()
	;Utility.Wait(1)
EndFunction

 

I didn't test it extensively, but - it worked for me, it didn't delete anything that was actually equipped (shown in inventory), and it deleted some items that were present only as rendered items.

Oh, that's nice! I will add that! It's a good solution because it fixes broken things while not providing a lame way to get rid of unwanted devices.

[Rogwar002]

Spoiler

2 hours ago, Kimy said:

It's hilarious how you complain about the replies you're getting not being super objective, when you started your own post by indicating that I am just out to build a monopoly, and apparently everyone BUT me is a shining hero of modding whose work I set out to destroy. And then providing a list of seemingly random mods you accuse me to break, without providing ANY evidence to back up your claim.

 

Did you REALLY expect an objective response to that?

 

If you're a QA person, you could have went over that list of yours and determined within seconds that DD5 has absolutely no chance to break about half of all mods on your list, for starters because they're not even using the DD framework. You could also have wondered how an edge case like VirginMarie's mod should somehow be symptomatic for literally every other mod out there, when both she and I agree that the problem her mod has is highly specific to hers.

 

Furthermore, you could have refrained from trying to make me look even more evil by bloating your list with some mods that are KNOWN to be broken and obsolete even now and have been for years. Like... Captured Dreams? The mod that got pulled by its own author and isn't even available anymore? Seriously?

 

And last, but not least, can the QA professional explain to me why except SLAV, not a SINGLE other DD mod has been reported here to be problematic, despite the DD5 beta version got downloaded by a fairly large number of testers, and the beta phase has been going on for a month now? When according to your post, DD5 is apparently wrecking the better part of all BDSM mods on LL? Are you assuming that none of them has any DD mods other than DCL installed?

 

You also seemingly missed the entire point of beta testing, which IS to figure out if there are issues in DD5, including compatibility issues. If I am oh-so evil, why oh why, am I even doing this when I could have just as easily published the thing and be done with it?

 

I will be open here: In all these years I have been maintaining DD, I barely ever made a change that broke anything in existing mods. That's how evil I am! The biggest one I can think of was in DD4, when the various keywords for wrist restraints got merged into one, to allow for a much cleaner implementation of wrist restraints, indirectly leading DD to now offering a much greater variety of them.

I really value backwards-compatibility. But if I really, really feel that a change potentially causing issues with existing mods is warranted, I will make this change. As DD developer, my obligation is to make DD the best framework it can be, not freezing the status quo forever, just so that some outdated relic mod can continue to run. It is still my belief that if a legacy mod is sufficiently popular, somebody will eventually update it. Or write a new version of that mod (I did that when Deviously Helpless broke, which was a mod I really loved, so I implemented most of its functionality in DCL to keep the idea alive). If a broken mod is remaining broken for years, chances are that it's not THAT important, quite honestly. All software eventually breaks. It's just the nature of things. And it has nothing to do with anyone being malicious or trying to build a monopoly.

 

 

Kimy, don´t let them get you. You know, there are still some people out there playing Last Ninja on a C64 emulator...

There is an absoulte need to go on. We all have to learn from our mistakes or in terms of a Skyrim from what is possible and proofed to be good or was / is a failure. You made it already absolutly clear: The DD equipment system was good in the past, but still there are hard coded limits nobody can deny, because nobody thought of them in the past. To prevent the DD framework getting stuck as it is, you had to make some creative inventions to the equipping system.

At all trolls: this is called evolution. If someone can do better, give us a proof and stop trolling around! You don´t like a feature given for free: Make your own! [insert curse here]

I still think some people in this network are really ungrateful. A pity.

[Shion11]

8 hours ago, Shion11 said:

i know it's 4 versions back, but there's a compadability issue with the rigid corset from DCL not showing up even if the bodyslide is run.

i have the log and a pic of the script not working, and another issue is chastity belts not appearing with the corset similar to 3.4. the corset i used is the same model as the rigid corset

Papyrus.0.log

[Kimy]

@VirginMarie:

 

Disregard the code above, and have a look at this instead. It should actually work.
 

; Returns true if anal sex on this actor is blocked.
;
Bool Function IsBlockedAnal(Actor akActor)
    If akActor.WornHasKeyword(libs.zad_DeviousBelt)
        Armor belt = libs.GetWornRenderedDeviceByKeyword(akActor, libs.zad_DeviousBelt)
        if !belt.HasKeyword(libs.zad_PermitAnal)
            return true
        EndIf
    EndIf
    If akActor.WornHasKeyword(libs.zad_DeviousSuit)
        Armor suit = libs.GetWornRenderedDeviceByKeyword(akActor, libs.zad_DeviousSuit)
        if !suit.HasKeyword(libs.zad_PermitAnal)
            return true
        EndIf
    EndIf
    If akActor.WornHasKeyword(libs.zad_DeviousPlugAnal)
        Armor plug = libs.GetWornRenderedDeviceByKeyword(akActor, libs.zad_DeviousPlugAnal)
        if !plug.HasKeyword(libs.zad_PermitAnal)
            return true
        EndIf
    EndIf    
    Return False
EndFunction

; Returns true if vaginal sex on/by this actor is blocked.
;
Bool Function IsBlockedVaginal(Actor akActor)
    If akActor.WornHasKeyword(libs.zad_DeviousBelt)
        Armor belt = libs.GetWornRenderedDeviceByKeyword(akActor, libs.zad_DeviousBelt)
        if !belt.HasKeyword(libs.zad_PermitVaginal)
            return true
        EndIf
    EndIf
    If akActor.WornHasKeyword(libs.zad_DeviousSuit)
        Armor suit = libs.GetWornRenderedDeviceByKeyword(akActor, libs.zad_DeviousSuit)
        if !suit.HasKeyword(libs.zad_PermitVaginal)
            return true
        EndIf
    EndIf
    If akActor.WornHasKeyword(libs.zad_DeviousPlugVaginal)
        Armor plug = libs.GetWornRenderedDeviceByKeyword(akActor, libs.zad_DeviousPlugVaginal)
        if !plug.HasKeyword(libs.zad_PermitVaginal)
            return true
        EndIf
    EndIf    
    Return False
EndFunction

 

[Kimy]

The DCL corset is expected to be broken for DD5, due to the changes to the corset implementation. Custom corsets need to be updated for DD5. It's one of the few things that aren't expected to be backwards-compatible.

[VirginMarie]

1 hour ago, Kimy said:

So if you'd tag your belt, suit and plug devices with the existing keywords zad_PermitAnal or zad_PermitVaginal, the filter should ignore them.

 

Can you let me know if that solution is satisfactory?

 

It's a great solution. Will work for me I'm sure. I will start testing with the beta once you've released.

 

It's an improvement since users do not need to change any DD setting for SLaV (or other mods that use it) to work as intended, nor make compromises for other mods running. I would use it even if the animation filter remained optional. Regarding that, in my opinion, your direction makes sense and I feel neutral on the issue, since now a mod can make the choice at an individual device basis. Much better! You can have chastity devices that protect only one of the holes, which is realistic in real life, and must be why the keywords already exist.

1. Is it backwards compatible? What impact do zad_PermitAnal and zad_PermitVaginal have on current release (if you know without having to trace code like crazy)? 
2. Using both zad_PermitAnal and zad_PermitVaginal on the same device is valid?
3. Gags? Are they not considered by the animation filter? I had thought so but looks like the code says otherwise. No zad_PermitOral needed? 
4. Preserve Scene Aggressiveness... What exactly does this do? What determines if it's aggressive?
5. Use Bound Animations... I tended to think about this as animations for heavy bondage. If this is "off" you "hide" wrist restraints and play normal animations, otherwise you pick only from the special bound animations? But what is a "wrist restraint"? Just the heavy bondage devices yoke, armbinder, prisoner chains? And what is "hide"? Do you remove and then replace (which could trigger events)? Trying to understand this better as this definitely does have bearing with SLaV. Not saying we need a zad_PermitRemoveHeavyBondage or something you can do to control behavior at a device level, but I'm pondering it.

[Kimy]

1 hour ago, VirginMarie said:

 

It's a great solution. Will work for me I'm sure. I will start testing with the beta once you've released.

 

It's an improvement since users do not need to change any DD setting for SLaV (or other mods that use it) to work as intended, nor make compromises for other mods running. I would use it even if the animation filter remained optional. Regarding that, in my opinion, your direction makes sense and I feel neutral on the issue, since now a mod can make the choice at an individual device basis. Much better! You can have chastity devices that protect only one of the holes, which is realistic in real life, and must be why the keywords already exist.

1. Is it backwards compatible? What impact do zad_PermitAnal and zad_PermitVaginal have on current release (if you know without having to trace code like crazy)? 

Yes, and it shouldn't be a problem for any other mod.

1 hour ago, VirginMarie said:

1. Using both zad_PermitAnal and zad_PermitVaginal on the same device is valid?

Yes.

1 hour ago, VirginMarie said:

1. Gags? Are they not considered by the animation filter? I had thought so but looks like the code says otherwise. No zad_PermitOral needed? 

Gags can be tagged with zad_permitOral already. It also will make the filter ignore it.

1 hour ago, VirginMarie said:

1. Preserve Scene Aggressiveness... What exactly does this do? What determines if it's aggressive?

It makes the filter attempting to replace aggressive (=rape) animations with other rape animations if at all possible.

1 hour ago, VirginMarie said:

1. Use Bound Animations... I tended to think about this as animations for heavy bondage. If this is "off" you "hide" wrist restraints and play normal animations, otherwise you pick only from the special bound animations?

That's correct.

1 hour ago, VirginMarie said:

1. But what is a "wrist restraint"? Just the heavy bondage devices yoke, armbinder, prisoner chains? And what is "hide"? Do you remove and then replace (which could trigger events)?

Wrist restraints are all heavy bondage devices. And nope, it's completely quest/event safe. I just make them invisible.

 

[Kharos]

1 hour ago, Kimy said:

Quote

1. Use Bound Animations... I tended to think about this as animations for heavy bondage. If this is "off" you "hide" wrist restraints and play normal animations, otherwise you pick only from the special bound animations?

That's correct.

 

This might not be what you want @Kimy... but reading the thread I get the feeling that some people would prefer to have three choices instead of the two that you provide:

1. Enable the DD animation filter
2. Disable the DD animation filter and temporarily remove restraints for sex scenes
3. Disable the DD animation filter completely, do not remove any devices

While option 3 on its own will result in a bad experience ("wrong" animations playing for the equipped devices), it would leave the door open for somebody else to implement an alternative animation filter (*). The people using that mod could then just turn your filter off. 

(*): I was under the impression that SexLab Utility Plus is an example of such a mod, though I have no idea whether it works correctly or not.

 

[Edit]
I might also misunderstand that because I was just following the last pages cursorily, but is it true that you provided (1) and (2) in DD 4.x and are changing your implementation to (1) and (3) now? If so I can understand how some people are concerned about backwards compatibility. Though to be honest if you are going to provide two options and not three, (2) is probably better than (3). It works better in most cases.

[VirginMarie]

@Kimy

 

Use Bondage Animations

When I think through this, with SLaV in mind, and other mods, I think the ideal wrist restrained/heavy bondage loving behavior is...

• If 1 actor... play normal valid animations, letting Sexlab pick, and hide the device (unless there are already several bound DD animations for solo?)
• If 2 actors... play bound animations, no hiding
• If > 2 actors... play normal valid animations, letting Sexlab pick, and hide
• If Creature (any # of actors)... always play normal and hide

Use Bound Animations ON = do the behavior above

Use Bound Animations OFF = always hide and let Sexlab do it's thing

 

Maybe this is already how it works lol, but if not, its an idea. If working this way, then, for SLaV, any combination of the Aggressive and Bound settings will work fine. I'd personally keep them both ON. SLaV will also be fine with the Animation Filter no longer disable-able as we already established.

 

Is "Use Bondage Animations" working fine in current DD release? I want to test with it (just preliminary test). Has it changed for beta?

It's odd that I feel as though I've not ever seen the hiding, but maybe I've not watched closely enough. I usually test with Use Bound Animations set off. I had assumed I don't see hiding because SLaV devices are mostly tagged with QuestItemblock_Generic.

 

[EDIT: I forgot... SLaV only uses block_Generic, I can't remember why I opted not to use QuestItem. Maybe because I decided that situations like your DCL prison, are fine to be removed and replaced]

 

 

Regarding Creature loving :

(Not my favorite topic, or thing to test. My husband made me put the support in SLaV, I swear!)

 

In my testing with DD current release 4.3a (I've got all the latest of all dependencies, latest FNIS, Skeleton, etc.)...

• When I test Animation Filter ON, Aggressive OFF, Bound OFF.... creatures flip flop around a bit, start off not aligned, may flip into aligned and back, and spin around the Z axis. Sometimes all 4 of these, sometimes 1 or 2, but almost always at least 1 of these. It can be subtle sometimes, and other times just very wacked
• When I test with all filters OFF...  creatures behave normally

So the Animation Filter appears to have some impact on creatures in prior release. Wondering if anyone seeing this in DD5? I will eventually test in DD5 too.

 

 

FNIS update may have impacted entry animations

I upgraded from v7.2 to 7.6. Some SLaV furniture items aligned with actor fine with 7.2. With 7.6 I've been having to compensate. Seems like something changed after 7.2 to cause this. They are old original ZAP items that I integrated. The effected animations are the ones that trigger when you activate the furniture with Activate(ObjectReference) and I'm having to remove use of Activate, and align with TranslateTo instead. I thought it might be worth mentioning in case anybody else is having trouble. Anybody? Makes me wonder if there is any other impact from FNIS. 

 

 

[VirginMarie]

44 minutes ago, Kharos said:

I was under the impression that SexLab Utility Plus is an example of such a mod

IMO this is an example of a mod author doing something out of best intentions I'm sure, but doing something that should NOT be done. It's one thing to offer a patch for an abandoned content mod, with author permission. But you do this with a framework mod that users then unwittingly use, not knowing they break mods, the user often then assuming the problem is the fault of the breaking mod, when it's this untested "patch" that is at fault. LL moderation should not allow this imo.

 

Example: SexLab Separate Orgasm breaks SLaV because it changes the code in Sexlab. SLaV stops detecting loss of virginity, breaking quests. SexLab Separate Orgasm author suggests ways to make SLaV compatible but those methods wont work. Now SexLab Separate Orgasm has been made part of SexLab Utility Plus, thus I have yet another framework patch that quietly breaks SLaV without users understanding what's going on. #5#5^&# !!! Sorry just venting here, off topic mostly, but I can understand Kimy's frustration in the similar impacts to DD.

[Kharos]

58 minutes ago, VirginMarie said:

Sorry just venting here, off topic mostly, but I can understand Kimy's frustration in the similar impacts to DD.

I didn't know anything of the technical background about SL Utility Plus, so I don't feel bothered by your venting. I just remembered reading something about a filter there while reading the discussion about filters here and it seemed somehow related.

I agree that overriding parts of existing frameworks is dangerous, and great care must be taken to do it in a way that does not break other mods that depend on it. It's one of the reasons that I always argue to have more options built in into the framework, as this allows other mods to work with these options instead of creating workarounds or even patches. On the other hand there is also a "too much options", so the framework author (Kimy in this case) has to decide what they believe to be the right amount of options ?.

[Kimy]

7 hours ago, Kharos said:

 

This might not be what you want @Kimy... but reading the thread I get the feeling that some people would prefer to have three choices instead of the two that you provide:

1. Enable the DD animation filter
2. Disable the DD animation filter and temporarily remove restraints for sex scenes
3. Disable the DD animation filter completely, do not remove any devices

While option 3 on its own will result in a bad experience ("wrong" animations playing for the equipped devices), it would leave the door open for somebody else to implement an alternative animation filter (*). The people using that mod could then just turn your filter off. 

(*): I was under the impression that SexLab Utility Plus is an example of such a mod, though I have no idea whether it works correctly or not.

 

[Edit]
I might also misunderstand that because I was just following the last pages cursorily, but is it true that you provided (1) and (2) in DD 4.x and are changing your implementation to (1) and (3) now? If so I can understand how some people are concerned about backwards compatibility. Though to be honest if you are going to provide two options and not three, (2) is probably better than (3). It works better in most cases.

Prior to DD5, all three named variants were an option. DD5 cut off #3 and it will not be back, ever. Thing is that according to what I got reported, DD just didn't behave right when the filter was completely switched off. People expected chastity belts to still prevent intercourse, but without the filter, animations were played regardless of the belt. And bras. And gags. Etc. Which is wrong. DD is about making restraints as realistic as possible, but without the filter, a big part of that is just not there.

 

In the end, allowing people to switch off the filter is akin to giving them a toggle to make characters not to put their arms in an armbinder when one is equipped.

 

It's just silly. The filter is an integral part of DD. It's really that. In hindsight, I don't know why there ever was a toggle for switching it off. In the end, I am just correcting a mistake here.

 

News of some 3rd party mods overriding the DD filter and doing so in a way that I was getting bug reports for it, didn't help. Really not. Honestly, I don't know. But I never made a secret of the circumstance that I am not a fan of 3rd party mods making arbitrary changes to the behavior of my mods. It's a total support nightmare, for starters. Because if they mess up my stuff, it's not THEM getting the bug reports. It's ME. Because everyone thinks it's MY mod malfunctioning. When it's not. People don't care. The modding scene is apparently the Wild West, and I find that off-putting, even after all these years. Some parts of the community act like as if every Tom, Dick and Harry had the natural right to patch every mod of their choosing to their liking if they don't agree with the way it's implemented. Perhaps I am not a modder at heart. I am a software engineer who happens to create mods. And in my world, if you want to change somebody's stuff you either convince them to, and/or contribute code for them to pull in the original project. And you accept no for a no, if they don't like the idea. You don't butcher their stuff with unsanctioned forks or rouge patches, unless in extreme circumstances (yes, OpenOffice probably warranted it).

 

Here? That's apparently normal. And I don't like it.

 

In short, I don't feel any obligation to keep unsanctioned patches against any of my mods working. Including any alternative implementations of the DD filter. If people did not feel the need to talk to me prior to publishing their patches, they can't seriously expect me to care about whether or not I break their stuff with my own updates, incidentally or on purpose.

[Shion11]

13 hours ago, Kimy said:

The DCL corset is expected to be broken for DD5, due to the changes to the corset implementation. Custom corsets need to be updated for DD5. It's one of the few things that aren't expected to be backwards-compatible.

is dcl going to be updated for DD5?

[Kharos]

2 hours ago, Kimy said:

The modding scene is apparently the Wild West, and I find that off-putting, even after all these years. Some parts of the community act like as if every Tom, Dick and Harry had the natural right to patch every mod of their choosing to their liking if they don't agree with the way it's implemented. Perhaps I am not a modder at heart. I am a software engineer who happens to create mods.

As a software engineer myself I can fully understand where you are coming from here ?. Also don't say you are not a modder. You are maintaining a mod that is used by a ton of people. And it is a framework mod that is used by a lot of other modders who build their own stuff on top, and you are actively helping them by providing mod events, functions and properties that they can override, etc.

 

2 hours ago, Kimy said:

In short, I don't feel any obligation to keep unsanctioned patches against any of my mods working. Including any alternative implementations of the DD filter. If people did not feel the need to talk to me prior to publishing their patches, they can't seriously expect me to care about whether or not I break their stuff with my own updates, incidentally or on purpose.

As a mod author myself I can fully understand that stance. Thanks for the additional background!

[Kimy]

6 hours ago, Shion11 said:

is dcl going to be updated for DD5?

Not only that, but DCL will have its own major release coming up, with a -ton- of new features!

[OsmelMC]

Ok I have to explain few things about "SexLab Utility Plus" because the discussion here is going for the wrong way and apparently the users in general misunderstood the way it works.

 

1. The SexLab Utility Plus don't interfere with the DDi Animation system. In fact was made to work together and indirectly speed up the DDi process by filtering the Animations before DDi intervene.

 

2. The SexLab Utility Plus just modify the "SexLab Framework" files. And the main idea is fix few issues on the SexLab scripts. The filters are there because is faster filter the Animations before the Animation Start then change the Animation once started and also many of those filters are things users are asking for since many years back

 

3. The only thing at my side that is one issue is the "SL Animation Load" file released apart to make the Devious Devices Animations visible on the SexLab and is the only one I responsible for. But is not the the only SLAL package with "Bound" Animations you can find because also FB, Billyys, ZaZ and few other author's have Bound Animations on his SLAL files. So the issue with the bound animations played without bound actors will be there without the "SexLab Utility Plus" or the DeviousDevice SLAL file. One of the intentions of the Utility filter is prevent that issue be filtering out the Bound related Animations before the Animation begin if none of the actors are bound but is also true that was not working as intended on some previous versions and that's another story.

 

 

 

Any way to properly test the DD I also think that the users should disable or remove the DeviousDevices SLAL file and use the "Clean System" option on the SexLab MCM. And probably remove the SexLab Utility Plus too just to be in peace.

I'm also fan of the Devious Devices and as programmer I know the hard it is try to fix something when some other programs/mod can be interfering with my work even if is not true but just the chance of interface is enough to make the development harder.

 

About the capacity of toggle the Animation Filter option on Devious Devices MCM like I explained on my first point "really don't matter" because SexLab Utility Plus is not a patch for DD and can work even better if the Animation Filter of the DD is enabled because the ActorChange function always used on the DD solve some issues related to the lack of animations I can't solve right now.

 

I hope and probably @Kimy too. This be the last time SexLab Utility Plus be referred on this topic. Because this is the Devious Devices Framework Development topic and the SexLab Utility Plus have his own topic were talk about.