Jump to content

Devious Devices Framework Development/Beta


Kimy

Recommended Posts

Posted
41 minutes ago, supergodman55 said:

going to ask a dumb question... I was able to find the 5.2-6 patch but not the original 5.2 beta, can anyone direct me to the right post?

You don't need the older patches. They are delta patches from 5.1 to 5.2 beta x. Just grab the newest.

Posted
On 10/25/2021 at 1:50 PM, Kimy said:

All right, let's get the DD 5.2 party started. For those brave souls willing to beta test unproven software, here is the first beta of DD 5.2. The focus of this version was to rebase the Bodyslide models on the (most welcome) clean-up work done by UnevenSteven. Also, 5.2 features optimized textures that will save a few hundred MB worth of hard-drive space, which might be welcome news for some! They also should perform better!

 

Here is the changelog:

 

Devious Devices 5.2


- Added: Cleaned Bodyslide files by UnevenSteven
- Added: Box armbinder by Kziid. DD adaption by UnevenSteven.
- Added: Box armbinder outfit mashup by Raccoonity.
- Added: Bodyslide-able armbinder for CBBE, by NIND.
- Changed: Optimizations for the FOMOD installer by CG!.
- Changed: Extracted Beast Race Refit BSA to avoid stability issues.
- Changed: Optimized textures. All textures now use 2K resolution.
- Changed: Added German (by CG!) and Russian (by stas2503) MCM localization.
- Fixed: Iteration bug in DDI_DebugFixDevices() that prevented it from removing some devices.
- Fixed: Faulty comparison instead of assignment in several piercings scripts.
- Fixed: Misleading log message in zadBQ00.StoreGags() that suggested belts were stored instead of gags.

 

As usual, the DD beta is for Skyrim LE only. That being said, if players decide to port it to SE on their own, I will gladly listen to SE specific bug reports, as long as I can fix the issues in the LE code. Whatever I can fix in the LE codebase, the poor SE porters won't have to do later! :)

 

I still have some contributions in need of getting merged. If you sent me files for DD and miss them in the Beta 1 version: Don't panic! They will go in! :)

 

Install instructions:

 

1. UNINSTALL any prior version of DD. Do NOT just overwrite an older version of DD with 5.2!!!

2. Install DD 5.2 using your favorite mod manager.

3. Have fun bug hunting!

 

Technically, a new game shouldn't be needed if upgrading from DD5.x, but I'd still appreciate if people would test DD 5.2 on a new and clean savegame, just to make sure.

 

Download link:

 

https://mega.nz/file/CF9A0ZrK#0Ug3jK4SrvyXbdgpLGRTpQ2X8cxgJiWhGCCr86FpwX8

 

41 minutes ago, supergodman55 said:

going to ask a dumb question... I was able to find the 5.2-6 patch but not the original 5.2 beta, can anyone direct me to the right post?

Here, page 165 of this whole topic, october 25th, 2021

Posted (edited)
On 5/17/2022 at 9:35 AM, naaitsab said:

So commenting the  following lines on the zadDevicesUnderneathScript just outright breaks it, with or without the NoHide keyword :P

HideEquipment(32, 58) ; When slot 32 is equipped, hide slot 58 (Corsets).
HideEquipment(32, 49) ; When slot 32 is equipped, hide slot 49 (Belts).

 

So my theory to let the equip portion handle the show/hide is flawed. Also forcing a unequip parameter when the NoHide is detected to function call of UpdateSlotmask also does not work.

 

@Kimy did you design the system or was it done by Min? Can't really figure out the logic behind it so can't fix the bug

What exactly are you trying to do? Been ages since I looked at that code, but I can probably help you figure it out.

 

On 5/17/2022 at 10:43 AM, Kimy said:

This is one of the last features in DD written by Min I really never touched.

Glad to see this project is still getting some love and attention! I see the github's been abandoned for a long time. Where are you hosting the code these days? Was thinking about submitting a very small PR that changes a few log lines to support another project I'm working on, if you're open to contributions.

Edited by Min
Posted
2 hours ago, Min said:

What exactly are you trying to do? Been ages since I looked at that code, but I can probably help you figure it out.

I have it outlined a bit here with a picture. Think it's better to show it :P To summarize, if a specific item has a keyword it should not hide it when the device hider kicks in. In this case of the screenshot the corset and belt are tagged so they should not hidden by the catsuit. I took a look at the code and there seem to be a "Zad_NoHide" present in DD but from my tests it's not working. It get's picked up by the check but it still get's hidden.

https://www.loverslab.com/topic/69936-devious-devices-framework-developmentbeta/page/176/#comment-3696096

 

2 hours ago, Min said:

Glad to see this project is still getting some love and attention! I see the github's been abandoned for a long time. Where are you hosting the code these days? Was thinking about submitting a very small PR that changes a few log lines to support another project I'm working on, if you're open to contributions.

 

Git would be easier to keep tabs on all changes and input. If I recall it was no longer used due to the file size limit and account requirement which is publicly viewable. Also you can't really share the ESP/ESM as it's a precompiled file without change monitoring. At the moment new things, bugreports and changes are posted here and compiled by Kimy. Not the best for keeping tabs but opening separate threads for content and bugs is also a bit much. Perhaps starting a DD Club on LL would be better? Then we can just make threads for specific things and not clutter the regular forums.

 

Posted

I think that the armbinder & yoke sex animatons made by @AndrewLRG in this blog post could be a worthy addition to DD's bound animation collection, possibly even replacing some of the earlier, less refined animations carried over from ZAP.

In the comments, the author expressed interest in having their animations added to DD as well.

 

Also from the same author, there are some new restraint variations as well, which look fitting to be included in DD, provided permissions allow it. I'm partial to these two especially, (though they may need UUNP bodyslides):

Posted (edited)
8 hours ago, naaitsab said:

I have it outlined a bit here with a picture. Think it's better to show it :P To summarize, if a specific item has a keyword it should not hide it when the device hider kicks in. In this case of the screenshot the corset and belt are tagged so they should not hidden by the catsuit. I took a look at the code and there seem to be a "Zad_NoHide" present in DD but from my tests it's not working. It get's picked up by the check but it still get's hidden.

https://www.loverslab.com/topic/69936-devious-devices-framework-developmentbeta/page/176/#comment-3696096

 

So, Skyrim can only render one slot on a given actor at a time. The slots which are rendered on the character are controlled by the ArmorAddon (AA) record for a given piece of armor. The device hider works by dynamically updating the AA on an invisible piece of armor so that it selectively blocks the rendering of whatever piece of gear, without actually unequipping it. AA records can/do block multiple slots. A given slot has a bitmask value that it corresponds to, for instance slot 30 is 0x00000001, and slot 40 is 0x00000400. By combining the two of these together with a boolean Or operation, we build a mask which blocks both slot 30, and 40. The slot mask is updated whenever equipment state changes to change what we're rendering.

 

You referenced this code:

	HideEquipment(32, 58) ; When slot 32 is equipped, hide slot 58 (Corsets).
	HideEquipment(32, 49) ; When slot 32 is equipped, hide slot 49 (Belts).

This code does nothing except set the default values for the device hider configuration. You can achieve the same effect of removing these lines by configuring slot 32 (The body slot) in the MCM.

 

My first suggestion would be to try removing those values one at a time in the MCM, and seeing which one is causing your device to be hidden. Second suggestion would be to ensure that the AA on your models do not conflict with eachother. If reconfiguring this in the MCM does not solve the problem, it is likely that some of the AA's you're attempting to apply conflict, are resulting in this behavior. If you completely disable the device hider (By setting the slot in the MCM), does it render correctly?

 

Edited by Min
Posted
32 minutes ago, Min said:

So, Skyrim can only render one slot on a given actor at a time. The slots which are rendered on the character are controlled by the ArmorAddon (AA) record for a given piece of armor. The device hider works by dynamically updating the AA on an invisible piece of armor so that it selectively blocks the rendering of whatever piece of gear, without actually unequipping it. AA records can/do block multiple slots. A given slot has a bitmask value that it corresponds to, for instance slot 30 is 0x00000001, and slot 40 is 0x00000400. By combining the two of these together with a boolean Or operation, we build a mask which blocks both slot 30, and 40. The slot mask is updated whenever equipment state changes to change what we're rendering.

 

You referenced this code:

	HideEquipment(32, 58) ; When slot 32 is equipped, hide slot 58 (Corsets).
	HideEquipment(32, 49) ; When slot 32 is equipped, hide slot 49 (Belts).

This code does nothing except set the default values for the device hider configuration. You can achieve the same effect of removing these lines by configuring slot 32 (The body slot) in the MCM.

 

My first suggestion would be to try removing those values one at a time in the MCM, and seeing which one is causing your device to be hidden. Second suggestion would be to ensure that the AA on your models do not conflict with eachother. If reconfiguring this in the MCM does not solve the problem, it is likely that some of the AA's you're attempting to apply conflict, are resulting in this behavior. If you completely disable the device hider (By setting the slot in the MCM), does it render correctly?

 

Yes if I disable the hider it works as intended. Well as it can now be used is a better description. It looks the same ingame as the screenshot from Bodyside. So the AA themselves seem to be compatible. It's "just" the hider not respecting the nohide keyword if it's attached to a device.

Posted

Hello everyone, would like to suggest new devices or more like new color variants for large ball gag, not an expert but i guess that would be easy to do :) large ball gag seems like most used one in mods so a lot of people would be probably interested. And maybe large ring gag? Thanks!

Posted
17 minutes ago, naaitsab said:

Yes if I disable the hider it works as intended. Well as it can now be used is a better description. It looks the same ingame as the screenshot from Bodyside. So the AA themselves seem to be compatible. It's "just" the hider not respecting the nohide keyword if it's attached to a device.

 

Deleted my previous reply, was less confident in it after actually going to look at the code. So, we have this function:

 

Function RebuildSlotmask(actor akActor)
	libs.Log("RebuildSlotmask()")
	int i = 0
	while i < 128
		SlotMaskUsage[i] = 0
		i += 1
	EndWhile
	SlotMask = 0
 	i = 0	
 	while i <= 30
 		Armor x = akActor.GetWornForm(ShiftCache[i]) as Armor
		if x != None && !FormHasKeywordString(x as Form, "NoHide")
			int sm = x.GetSlotMask()
			int j = 0
			While j <= 30
				int slot = ShiftCache[j]
				if Math.LogicalAnd(sm, slot)										
					UpdateSlotmask(j, slot, true)					
				EndIf
				j += 1
			EndWhile
		EndIf
 		i += 1
 	EndWhile
	ApplySlotMask()
EndFunction

 

It looks like we loop through all available slots on the actor, checking to see if they're wearing it, and making sure that the armor we've retrieved does not contain any keyword containing the string "NoHide". That should include "zad_NoHide". If it's a valid piece of armor and does not contain a keyword with that string, attempt to update the slotmask for all combinations of armors that are configured to be hidden for that slot.

 

I think this should be working? Can you share a test-case that I can play with that demonstrates the issue?

Posted
34 minutes ago, Min said:

 

Deleted my previous reply, was less confident in it after actually going to look at the code. So, we have this function:

 

Function RebuildSlotmask(actor akActor)
	libs.Log("RebuildSlotmask()")
	int i = 0
	while i < 128
		SlotMaskUsage[i] = 0
		i += 1
	EndWhile
	SlotMask = 0
 	i = 0	
 	while i <= 30
 		Armor x = akActor.GetWornForm(ShiftCache[i]) as Armor
		if x != None && !FormHasKeywordString(x as Form, "NoHide")
			int sm = x.GetSlotMask()
			int j = 0
			While j <= 30
				int slot = ShiftCache[j]
				if Math.LogicalAnd(sm, slot)										
					UpdateSlotmask(j, slot, true)					
				EndIf
				j += 1
			EndWhile
		EndIf
 		i += 1
 	EndWhile
	ApplySlotMask()
EndFunction

 

It looks like we loop through all available slots on the actor, checking to see if they're wearing it, and making sure that the armor we've retrieved does not contain any keyword containing the string "NoHide". That should include "zad_NoHide". If it's a valid piece of armor and does not contain a keyword with that string, attempt to update the slotmask for all combinations of armors that are configured to be hidden for that slot.

 

I think this should be working? Can you share a test-case that I can play with that demonstrates the issue?

If you are running the latest beta and build the bodyslide files you can replicate it as follows.

-Create a new restrictive/Koffi corset (or corset with belt) with the rendered item having 'zad_NoHide' attached to it. Or just add the keyword to the default corset for testing of course.

-Equip a catsuit

-Equip the corset

-See the corset still getting hidden

-Disable the hider or remove the affected slots from the hider MCM -> Corset appears again with the catsuit underneath.

 

I modified the code to give a notification to check if "FormHasKeywordString" does what it's name implies. And it does. It sees a device with the nohide keyword was equiped. So that part is working. Perhaps at the keyword check stage when it is present it needs to refresh the AA? Now it just does nothing as it only contains code on the If part of the loop.

Posted (edited)
41 minutes ago, naaitsab said:

If you are running the latest beta and build the bodyslide files you can replicate it as follows.

-Create a new restrictive/Koffi corset (or corset with belt) with the rendered item having 'zad_NoHide' attached to it. Or just add the keyword to the default corset for testing of course.

-Equip a catsuit

-Equip the corset

-See the corset still getting hidden

-Disable the hider or remove the affected slots from the hider MCM -> Corset appears again with the catsuit underneath.

 

I modified the code to give a notification to check if "FormHasKeywordString" does what it's name implies. And it does. It sees a device with the nohide keyword was equiped. So that part is working. Perhaps at the keyword check stage when it is present it needs to refresh the AA? Now it just does nothing as it only contains code on the If part of the loop.

Hey, a point of clarification here... You're putting the keyword on the catsuit, not the corset / belt. Right? The keyword needs to be on the item that is triggering the hiding, not on the one being hidden. The keyword indicates "This item is revealing and should not block the rendering of other items".

 

This keyword is poorly named, and is ambiguous as to which item it should be on. Sorry about that. It would be more accurate to call it something like "zad_NoHideOtherItems".

Edited by Min
Posted (edited)
49 minutes ago, Min said:

Hey, a point of clarification here... You're putting the keyword on the catsuit, not the corset / belt. Right? The keyword needs to be on the item that is triggering the hiding, not on the one being hidden. The keyword indicates "This item is revealing and should not block the rendering of other items".

 

This keyword is poorly named, and is ambiguous as to which item it should be on. Sorry about that. It would be more accurate to call it something like "zad_NoHideOtherItems".

Hmm, guess your right about the naming. I thought items with the keyword don't get hidden e.g. ignored by the hider. But the other way around would pose issues. As the catsuit would clip with things like piercings and bras as those are no longer hidden (which is desired). That would be messy. Could it be reversed so it does it like I thought it would work?

Edited by naaitsab
Posted
4 hours ago, Taki17 said:

Also from the same author, there are some new restraint variations as well, which look fitting to be included in DD, provided permissions allow it. I'm partial to these two especially, (though they may need UUNP bodyslides):

 

oohhhh, I really like that tight armbinder. I'm always for the possibility of harder to escape from devices, and that looks very nice.

 

Posted (edited)
22 minutes ago, naaitsab said:

Hmm, guess your right about the naming. I thought items with the keyword don't get hidden e.g. ignored by the hider. But the other way around would pose issues. As the catsuit would clip with things like piercings and bras. That would be messy. Could it be reversed so it does it like I thought it would work?

 

It certainly could be, but there are valid use-cases for both. Plus, I think you would conditionally want corsets / belts to not be hidden (Such as when you're wearing a catsuit), not always (Like if you're wearing normal armor). Right?

 

If you wanted to add a new keyword which contained that behavior, you would need to update this function:

Function UpdateSlotmask(int index, int slot, bool equipOrUnequip)
	; libs.Log("UpdateSlotMask("+(index+30)+").")
	index *= 4
	if index >= 124
		libs.Error("UpdateSlotmask received out of bound index: "+index)
	else
		int i = 0
		while i < 4
		; libs.Log("Checking "+SlotMask +" vs "+SlotMaskFilters[index+i])
			if SlotMaskFilters[index+i] != 0
				; libs.Log("Match.")
				if equipOrUnequip
					SlotMask = Math.LogicalOr(SlotMask, SlotMaskFilters[index+i])
					SlotMaskUsage[index+i] = SlotMaskUsage[index+i] + 1
				Else
					SlotMaskUsage[index+i] = SlotMaskUsage[index+i] - 1
					; if SlotMaskUsage[index+i] <= 1
					; 	SlotMaskUsage[index+i] = 0
					SlotMask = SlotMask - SlotMaskFilters[index+i]
					; EndIf
				EndIf
			EndIf
			i += 1
		EndWhile
		; libs.Log("End UpdateSlotMask: "+SlotMask)
	EndIf
EndFunction

 

 

Something like this (Untested, I don't have the CK setup) would probably work:

Function UpdateSlotmask(int index, int slot, bool equipOrUnequip)
	; libs.Log("UpdateSlotMask("+(index+30)+").")
	index *= 4
	if index >= 124
		libs.Error("UpdateSlotmask received out of bound index: "+index)
	else
		int i = 0
		while i < 4
		; libs.Log("Checking "+SlotMask +" vs "+SlotMaskFilters[index+i])
			if SlotMaskFilters[index+i] != 0
				; libs.Log("Match.")
				if equipOrUnequip
					; CHANGES HERE:
					Armor x = akActor.GetWornForm(SlotMaskFilters[index+i]) as Armor
					 if x != None && !FormHasKeywordString(x as Form, "NewKeywordForHidingAnItem")
						SlotMask = Math.LogicalOr(SlotMask, SlotMaskFilters[index+i])
						SlotMaskUsage[index+i] = SlotMaskUsage[index+i] + 1
					EndIf
					; END CHANGES
				Else
					SlotMaskUsage[index+i] = SlotMaskUsage[index+i] - 1
					; if SlotMaskUsage[index+i] <= 1
					; 	SlotMaskUsage[index+i] = 0
					SlotMask = SlotMask - SlotMaskFilters[index+i]
					; EndIf
				EndIf
			EndIf
			i += 1
		EndWhile
		; libs.Log("End UpdateSlotMask: "+SlotMask)
	EndIf
EndFunction

 

 

Though, this would cause anything tagged with "NewKeywordForHidingAnItem" to be shown through armor / other undesirable things. You could work around this by checking to see if you're wearing a catsuit, or other device that should function this way in whatever the current way of doing this in the framework is.

 

EDIT: Actually, come to think of it, you would want to put the new logic before the "if equipOrUnequip" line, so that it covered both use-cases, in order to avoid corrupting the slotmask.

Edited by Min
Posted
46 minutes ago, Min said:

 

It certainly could be, but there are valid use-cases for both. Plus, I think you would conditionally want corsets / belts to not be hidden (Such as when you're wearing a catsuit), not always (Like if you're wearing normal armor). Right?


If you wanted to add a new keyword which contained that behavior, you would need to update this function:

 

Though, this would cause anything tagged with "NewKeywordForHidingAnItem" to be shown through armor / other undesirable things. You could work around this by checking to see if you're wearing a catsuit, or other device that should function this way in whatever the current way of doing this in the framework is.

 

EDIT: Actually, come to think of it, you would want to put the new logic before the "if equipOrUnequip" line, so that it covered both use-cases, in order to avoid corrupting the slotmask.

 

Yeah I think the if-else will be better than going into the if loop and selecting there. But keeping it from interfering with regular armor is something I haven't thought about. In this usecase it would only include a set of 3 devices. Catsuit, Corset and Belt. So I guess we have to filter for those keywords to stay safe right?

Posted (edited)

 

41 minutes ago, naaitsab said:

 

Yeah I think the if-else will be better than going into the if loop and selecting there. But keeping it from interfering with regular armor is something I haven't thought about. In this usecase it would only include a set of 3 devices. Catsuit, Corset and Belt. So I guess we have to filter for those keywords to stay safe right?

It does need to be done in the loop, since it iterates over the 4 available mask entries for the given slot you're manipulating. You would want to account for all of them. Each slot that Skyrim supports has 4 entries in the device hider (Stored in the SlotMaskFilters and SlotMaskUsage arrays). Slot 30 (The first slot) is stored in elements 0..3. Slot 31 is stored in 4..7, and so forth. Each one of these entries can contain a different item type that you want to hide.

 

It should still cover both equip / unequip use-cases though, as if you were to somehow subtract say, 0x00000400 from it several times, it would be corrupted / have an invalid value.

 

And yeah, you would need to make sure as well that your condition (Wearing a catsuit, or other device which should not hide belts/corsets) was met. You could either hardcode the catsuit keyword, or do that via a more generic keyword pair.  Or, if you just wanted to do something for this specific usecase, you could just add a targeted condition for this usecase....

 

Or... I did make the device hider to be programmatically manipulable. You could build into your catsuit calls to HideEquipment / ShowEquipment to dynamically reconfigure the device hider.

 

 

 

EDIT: Oh, also! Is the beta backwards compatible with the previously released version? I'm not on the beta at the moment.

Edited by Min
Posted
3 hours ago, Min said:

EDIT: Oh, also! Is the beta backwards compatible with the previously released version? I'm not on the beta at the moment.

Can't speak to existing saves, but there haven't been any breaking changes between 5.1 and the 5.2 betas.

Posted (edited)
3 hours ago, chaimhewast said:

Can't speak to existing saves, but there haven't been any breaking changes between 5.1 and the 5.2 betas.

Yeah, I'm somewhat invested in my current character and not looking to restart right now. I wouldn't mind running the beta / helping out though if it's backwards compatible!

Edited by Min
Posted
9 hours ago, Min said:

  

It does need to be done in the loop, since it iterates over the 4 available mask entries for the given slot you're manipulating. You would want to account for all of them. Each slot that Skyrim supports has 4 entries in the device hider (Stored in the SlotMaskFilters and SlotMaskUsage arrays). Slot 30 (The first slot) is stored in elements 0..3. Slot 31 is stored in 4..7, and so forth. Each one of these entries can contain a different item type that you want to hide.

 

It should still cover both equip / unequip use-cases though, as if you were to somehow subtract say, 0x00000400 from it several times, it would be corrupted / have an invalid value.

 

And yeah, you would need to make sure as well that your condition (Wearing a catsuit, or other device which should not hide belts/corsets) was met. You could either hardcode the catsuit keyword, or do that via a more generic keyword pair.  Or, if you just wanted to do something for this specific usecase, you could just add a targeted condition for this usecase....

 

Or... I did make the device hider to be programmatically manipulable. You could build into your catsuit calls to HideEquipment / ShowEquipment to dynamically reconfigure the device hider.

 

 

 

EDIT: Oh, also! Is the beta backwards compatible with the previously released version? I'm not on the beta at the moment.

Still can't really make heads or tails from it :P So if you are willing to spend some time with it that would be great.

 

SE seems to be a bit more forgiving if scripts attached to active objects (quests+aliasses) are changed. On LE I would not recommend it. But for quite a couple of runs now we did not have to do a rollback so I would suggest just running the latest one. It are mainly tweaks here and there and some new devices. Keep in mind they are LE releases so you need to convert them to SE or wait for someone to upload it here.

Posted

One thing I've noticed in the DD MCM is that upon pressing the key to reset the difficulty modifiers to the default, the script sets them to one level below the default (to "Questioning" instead of "Kinky [Default]"). I believe this is caused by the default setting being the 5th element of the difficulty level string, whereas it should be 4th.

 

	EsccapeDifficultyList[4] = "Kinky [Default]"
	EsccapeDifficultyList[5] = "Questioning"

	ElseIf option == EscapeDifficultyOID
		SetMenuDialogOptions(EsccapeDifficultyList)
		SetMenuDialogStartIndex(EscapeDifficulty)
		SetMenuDialogDefaultIndex(5)
	ElseIf option == CooldownDifficultyOID
		SetMenuDialogOptions(EsccapeDifficultyList)
		SetMenuDialogStartIndex(CooldownDifficulty)
		SetMenuDialogDefaultIndex(5)
	ElseIf option == KeyDifficultyOID
		SetMenuDialogOptions(EsccapeDifficultyList)
		SetMenuDialogStartIndex(KeyDifficulty)
		SetMenuDialogDefaultIndex(5)	

 

Posted (edited)
6 hours ago, naaitsab said:

Still can't really make heads or tails from it :P So if you are willing to spend some time with it that would be great.

 

SE seems to be a bit more forgiving if scripts attached to active objects (quests+aliasses) are changed. On LE I would not recommend it. But for quite a couple of runs now we did not have to do a rollback so I would suggest just running the latest one. It are mainly tweaks here and there and some new devices. Keep in mind they are LE releases so you need to convert them to SE or wait for someone to upload it here.

Sure, I don't mind doing that. How do I contribute? Just upload a patch to this thread?

 

And yeah, I'm on SE. Is this the latest build?

 

Edited by Min
Posted
8 minutes ago, Min said:

Sure, I don't mind doing that. How do I contribute? Just upload a patch to this thread?

Yeah with most additions and fixes we just upload the code and/or files here. So A people can chip in and B we can discuss any possible issues or points of improvements with it. I think it's a lot better than some closed PM situation.

 

One of the main hard requirements is it should not outright break older mods (due to quite a lot of mods being abandoned) and it requires either written permission for usage in DD or have it clearly listed as being free to use.

Posted
3 hours ago, naaitsab said:

Yeah with most additions and fixes we just upload the code and/or files here. So A people can chip in and B we can discuss any possible issues or points of improvements with it. I think it's a lot better than some closed PM situation.

 

One of the main hard requirements is it should not outright break older mods (due to quite a lot of mods being abandoned) and it requires either written permission for usage in DD or have it clearly listed as being free to use.

Yeah, makes sense - This seems much nicer than the old message groups we used to maintain. I'll set up my CK this week when I have time, and see about contributing a patch that adds the functionality you are looking for. Let's talk implementation.

 

How would you folks prefer this works? Using specific device keywords (Like catsuit) seems bad, because it doesn't work for future devices (I think @Kimy has been moving the framework away from this sort of brittle design). We could make a "PartiallyRevealing" keyword to put on the catsuits, and a "PartiallyExposed" keyword to put on the corsets / belts. The script would then selectively reveal devices depending on what was equipped. This seems like a reasonable solution, though of course comes with the downside that existing devices would need this keyword if you wanted them to be supported.

 

Another way of doing it would be to hook into the equip / unequip events for catsuits, and manipulate the device hider's configuration accordingly. This would be an easy implementation (I think? I remember seeing something about us moving away from the object oriented model I had originally set up. Can we still add specific logic for categories of devices?).

 

@Kimy What do you think? Do you have a preference for implementation? Do you mind if I add the functionality @naaitsab is looking for?

Posted
2 hours ago, Min said:

Yeah, makes sense - This seems much nicer than the old message groups we used to maintain. I'll set up my CK this week when I have time, and see about contributing a patch that adds the functionality you are looking for. Let's talk implementation.

 

How would you folks prefer this works? Using specific device keywords (Like catsuit) seems bad, because it doesn't work for future devices (I think @Kimy has been moving the framework away from this sort of brittle design). We could make a "PartiallyRevealing" keyword to put on the catsuits, and a "PartiallyExposed" keyword to put on the corsets / belts. The script would then selectively reveal devices depending on what was equipped. This seems like a reasonable solution, though of course comes with the downside that existing devices would need this keyword if you wanted them to be supported.

 

Another way of doing it would be to hook into the equip / unequip events for catsuits, and manipulate the device hider's configuration accordingly. This would be an easy implementation (I think? I remember seeing something about us moving away from the object oriented model I had originally set up. Can we still add specific logic for categories of devices?).

 

@Kimy What do you think? Do you have a preference for implementation? Do you mind if I add the functionality @naaitsab is looking for?

I like the implantation of the keywords as they are designed to trigger when both keywords are present on the the actor right? This allows modders to allow specific devices to be worn on top or beneath. For example you could do a escape game with a catsuit with a corset and belt on top with another suit on top. When the top suit is removed the "on remove" event can equip the catsuit below the corset. This is quite a extreme usecase but it would be possible with that implantation. My preference would be to also add the keywords on current DD items. As the current bodyslider set supports it and wearing a corset underneath a catsuit seems a bit daft. The belt is a bit mixed of course.

 

Currently we mostly are running a single equip script across the devices. With Extends it can be called from a custom script but the less custom device scripts the better imho.

 

Like to know how others look on the matter is.

 

BTW I also want to refresh the old Devious Deviants part of DD with the way faster equips from DD5. Would you mind if I uploaded that as a Redux/Revival mod or would you like to do that yourself? The scripts are still within DD (which we can also cleanup when we know what scripts are used by the Deviants ESP, there should be ways to check this). and the ESP is still on a GIT commit somewhere but I can also send it. Might be a good startup to check all the new things in DD since you left ;) My OSD get's triggered everytime I open the script folder of DD with all those unused scripts ?

 

 

Posted
1 hour ago, naaitsab said:

I like the implantation of the keywords as they are designed to trigger when both keywords are present on the the actor right? This allows modders to allow specific devices to be worn on top or beneath. For example you could do a escape game with a catsuit with a corset and belt on top with another suit on top. When the top suit is removed the "on remove" event can equip the catsuit below the corset. This is quite a extreme usecase but it would be possible with that implantation. My preference would be to also add the keywords on current DD items. As the current bodyslider set supports it and wearing a corset underneath a catsuit seems a bit daft. The belt is a bit mixed of course.

 

Currently we mostly are running a single equip script across the devices. With Extends it can be called from a custom script but the less custom device scripts the better imho.

 

Like to know how others look on the matter is.

 

BTW I also want to refresh the old Devious Deviants part of DD with the way faster equips from DD5. Would you mind if I uploaded that as a Redux/Revival mod or would you like to do that yourself? The scripts are still within DD (which we can also cleanup when we know what scripts are used by the Deviants ESP, there should be ways to check this). and the ESP is still on a GIT commit somewhere but I can also send it. Might be a good startup to check all the new things in DD since you left ;) My OSD get's triggered everytime I open the script folder of DD with all those unused scripts ?

 

 

 

Another way that I could see doing it would be having keywords like "zad_ShowSlot32" that you could put on devices to override the device hider's behavior for it.

 

By all means, feel free! I'd enjoy seeing those old quests come back to life. The Sergius questline always felt a bit awkwardly implemented, but some of the others were pretty fun I think. The only quests I've ever written, heh. :D

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   0 members

    • No registered users viewing this page.
×
×
  • Create New...