Jump to content

Devious Devices Framework Development/Beta


Recommended Posts

2 hours ago, Veladarius said:

That gets you the rendered device but there is no command to look up an inventory item using the rendered device. It is fine if you want to get the rendered device to look up keywords on it or other things but useless as a starting point to remove an item.

Looking at the code for it, it seems like it should be returning an inventory device as well...

 

Spoiler

; Finds device based on rendered device keywords (e.g. keyword zad_DeviousBelt also returns a harness)
; Useful for situation where you just want to get the device occupying a specific slot without further differentiation
Armor Function GetWornDeviceFuzzyMatch(Actor akActor, Keyword kw)
    Armor retval = none
    Int iFormIndex = akActor.GetNumItems()
    bool breakFlag = false
    While iFormIndex > 0 && !breakFlag
        iFormIndex -= 1
        Form kForm = akActor.GetNthForm(iFormIndex)
        If kForm.HasKeyword(zad_InventoryDevice) && (akActor.IsEquipped(kForm) || akActor != playerRef)
            ObjectReference tmpORef = akActor.placeAtMe(kForm, abInitiallyDisabled = true)
            zadEquipScript tmpZRef = tmpORef as zadEquipScript
            if tmpZRef != none && tmpZRef.deviceRendered.hasKeyword(kw) && akActor.GetItemCount(tmpZRef.deviceRendered) > 0
                retval = kForm as Armor
                breakFlag = true
            Endif
            tmpORef.delete()
        EndIf
    EndWhile
    return retval
EndFunction

 

 

Link to comment
2 hours ago, Veladarius said:

That gets you the rendered device but there is no command to look up an inventory item using the rendered device. It is fine if you want to get the rendered device to look up keywords on it or other things but useless as a starting point to remove an item.

 

If you want to remove any sort of device there are 4 steps to get all the info and remove it but it takes some work:

1 - WornHasKeyword(actor, keyword) - you look for a specific keyword on the player. Since the HeavyBondage items also have an identifier keyword as to what it is if you find the identifier keyword  then you know it uses HeavyBondage. Of course you can always just look for HeavyBondage and if it is there then you know their hands are bound.

2 - GetWornDevice(actor, keyword) - this gives the inventory item which you can then feed into...

3 - GetRenderedDevice(armor) - this will give you the rendered device.

4 - <rendered device>.haskeyword(questitem) to check if it is a quest item, if so you can stop the process or switch to the command to remove a quest item.

 

This is basically the process I use in my device removal function, I tell it the item keyword and actor and everything else gets looked up. I have one function for non quest items and one for quest items though it looks for my own custom quest item keywords as I have them for each device type. If the rendered item doesn't have it and is a quest item then it aborts the removal.

I am using these functions to remove devices but it was GetWornDevice that was choking on HeavyBondage items in my code. Using fuzzy match instead for the worn device seems to be working so far. Thanks.

Link to comment

    DDI 4 >> keys breaking, 2 hour wait after one try.. it is such BS... I like totally hate it.

 

   Why did you take out the ability to not have the breaking key's, and long wait.. That was so nice for personalizing my game play..


   ( I thought resources allowed the modder to make choices, but you are forcing many thing, becoming more of a mod than a Resource )

 

   Yes I can go to the remove all command in the MCM, but that removes everything, sometimes it is only one Item that is offending my game play, like say a gag, or arm binder, and I only want them removed.

 

  So I want to use a key, and get it done.. but NOOO! My Key broke, and now I have to find some way to fix it, or oops you failed to unlock it so now you have to wait 2 hours.. Crap-Ola!

 

   I normally go straight to the MCM, and remove all, but now any quest I actually might have wanted to continue is fucked...

 

   That is so ficking Bogus... :confounded:

 

   If some one can make a mod that fixes that.. Bravo,,, I think I may return to and older version of DDI, ( for awhile, frustration is way to High ) I mean every time I try to remove and Item with a key, its wait 2 hours or "Oh no! the key broke in the lock you will have to find some way to repair it... "

 

  I mean gosh Darn! in real life how many time have you ever had a key break off in a lock ? ( I have had it happen Once in my entire life ) :classic_unsure:

 

   Why is it I can kill a whole town, or dungeon, and never even breath hard, but I try to open one lock, and suddenly I am so weak i have to wait two hours... Geesh!

 

   Yes I am sorry about ranting, but this one is sooo! upsetting, and unneeded.  I know you all worked very hard on this, but I think you made a very poor choice in removing player ability to personalize there game play, and make it fun for them, I find no fun in waiting 2 hours or every other lock I try to open with a key breaking the key off in the lock.

 

I always though DDI was a resource, placing forced choice stuff like this in it makes it more of a mod, that forces your choices, or gives you no choice.

 

   Please put back the ability to personalize my game.

Link to comment
2 hours ago, LazyBoot said:

Looking at the code for it, it seems like it should be returning an inventory device as well...

 

  Hide contents


; Finds device based on rendered device keywords (e.g. keyword zad_DeviousBelt also returns a harness)
; Useful for situation where you just want to get the device occupying a specific slot without further differentiation
Armor Function GetWornDeviceFuzzyMatch(Actor akActor, Keyword kw)
    Armor retval = none
    Int iFormIndex = akActor.GetNumItems()
    bool breakFlag = false
    While iFormIndex > 0 && !breakFlag
        iFormIndex -= 1
        Form kForm = akActor.GetNthForm(iFormIndex)
        If kForm.HasKeyword(zad_InventoryDevice) && (akActor.IsEquipped(kForm) || akActor != playerRef)
            ObjectReference tmpORef = akActor.placeAtMe(kForm, abInitiallyDisabled = true)
            zadEquipScript tmpZRef = tmpORef as zadEquipScript
            if tmpZRef != none && tmpZRef.deviceRendered.hasKeyword(kw) && akActor.GetItemCount(tmpZRef.deviceRendered) > 0
                retval = kForm as Armor
                breakFlag = true
            Endif
            tmpORef.delete()
        EndIf
    EndWhile
    return retval
EndFunction

 

 

No, it is searching the player's inventory for DD inventory parts and then checking to see if it is equipped by checking for the rendered device, if it is it returns the rendered device. If you can get this function to return more than one item I would like to see how it is done. Also, unless the command has been changed according to the documentation it just returns the rendered device and nothing else.

Link to comment
4 minutes ago, Veladarius said:

No, it is searching the player's inventory for DD inventory parts and then checking to see if it is equipped by checking for the rendered device, if it is it returns the rendered device. If you can get this function to return more than one item I would like to see how it is done. Also, unless the command has been changed according to the documentation it just returns the rendered device and nothing else.

If you look at the code in zadLibs, you'll see that the only difference between GetWornDevice and GetWornDeviceFuzzyMatch is a single if statement.

 

You can test this yourself by exectuting this code while wearing an armbinder:

zadLibs DD = Game.GetFormFromFile(0x0000f624, "Devious Devices - Integration.esm") as zadLibs
Debug.Notification(DD.GetWornDeviceFuzzyMatch(PlayerREF, DD.zad_DeviousArmbinder).HasKeyword(DD.zad_InventoryDevice))

 

Link to comment
13 minutes ago, LazyBoot said:

If you look at the code in zadLibs, you'll see that the only difference between GetWornDevice and GetWornDeviceFuzzyMatch is a single if statement.

 

You can test this yourself by exectuting this code while wearing an armbinder:


zadLibs DD = Game.GetFormFromFile(0x0000f624, "Devious Devices - Integration.esm") as zadLibs
Debug.Notification(DD.GetWornDeviceFuzzyMatch(PlayerREF, DD.zad_DeviousArmbinder).HasKeyword(DD.zad_InventoryDevice))

 

GetWornDevice returns an Inventory Device, GetWornFuzzyMatch returns a Rendered Device which is the difference in the coding of the commands. My question was that using what is returned by GetWornFuzzyMatch how do you get the rest of the device information? You can't as there is no command to look up the inventory device using the rendered device itself. While GetWornFuzzyMatch is good for looking up a rendered device directly to get other keywords and such from it the GetRenderedDevice is much more precise as it returns the rendered device based on the inventory device provided. Just using the keywords can cause issues if the player has a number of similar items in their inventory as DD may end up returning one of the other devices and create broken items.

Link to comment
26 minutes ago, Veladarius said:

GetWornDevice returns an Inventory Device, GetWornFuzzyMatch returns a Rendered Device which is the difference in the coding of the commands. 

Seriously??

I didn't realize that. 

What is the point in having two similarly named commands return two very different results?

 

Back to the drawing board. It looks like I have a lot more testing to do to get HeavyBondage items to fit with my code in SD+

Link to comment
29 minutes ago, Veladarius said:

GetWornDevice returns an Inventory Device, GetWornFuzzyMatch returns a Rendered Device which is the difference in the coding of the commands. My question was that using what is returned by GetWornFuzzyMatch how do you get the rest of the device information? You can't as there is no command to look up the inventory device using the rendered device itself. While GetWornFuzzyMatch is good for looking up a rendered device directly to get other keywords and such from it the GetRenderedDevice is much more precise as it returns the rendered device based on the inventory device provided. Just using the keywords can cause issues if the player has a number of similar items in their inventory as DD may end up returning one of the other devices and create broken items.

Have you tested this yourself? Because when I tested it before posting my last comment, I got an inventory device returned from GetWornDeviceFuzzyMatch!

Link to comment
Just now, LazyBoot said:

Have you tested this yourself? Because when I tested it before posting my last comment, I got an inventory device returned from GetWornDeviceFuzzyMatch!

Yes.. are you sure about that?

 

I am looking at the source code and it looks like both methods are identical except on how they look for a device. 

They both return a form from the same list.

Link to comment

Unless everything I know about programming is wrong, the fact that I'm getting "TRUE" from this code means both give the same item.

zadLibs DD = Game.GetFormFromFile(0x0000f624, "Devious Devices - Integration.esm") as zadLibs
Debug.Notification(DD.GetWornDeviceFuzzyMatch(Game.GetPlayer(), DD.zad_DeviousHarness) == DD.GetWornDevice(Game.GetPlayer(), DD.zad_DeviousHarness))

 

Link to comment
3 minutes ago, Verstort said:

Double checking.

 

Internally DDi 3.3b is 6.0, and 4.0 is 8.0, correct?

This is the one I've got from ddi 4.

float Function GetVersion()
	return 8 ; build number increment to determine the newest version - does NOT correspond with the offical version name. Returns a float not to mess with existing implementations of this function.
EndFunction

String Function GetVersionString()
	return "4.0" ; string to be displayed in MCM etc.
EndFunction

 

Link to comment
1 minute ago, LazyBoot said:

This is the one I've got from ddi 4.


float Function GetVersion()
	return 8 ; build number increment to determine the newest version - does NOT correspond with the offical version name. Returns a float not to mess with existing implementations of this function.
EndFunction

String Function GetVersionString()
	return "4.0" ; string to be displayed in MCM etc.
EndFunction

 

I got those two values from 4.0 and 3.3b directly, same as you.

 

Its the missing version 7 I'm worried about... was it only used somewhere in the beta and is it irrelevant?

Link to comment
3 minutes ago, Verstort said:

I got those two values from 4.0 and 3.3b directly, same as you.

 

Its the missing version 7 I'm worried about... was it only used somewhere in the beta and is it irrelevant?

Looks like 7 was for 3.4 in april, so that was in the beta. Here's the relevant commit from github:

https://github.com/DeviousDevices/DDi/commit/f91ed31e648d052c07ff82eb49960e8d5c4cdbe2

Link to comment
On 1/4/2018 at 10:43 PM, galgat said:

DDI 4 >> keys breaking, 2 hour wait after one try.. it is such BS... I like totally hate it.

I have to join galgat here.

 

I don't have any mod that put keys into the world, so if I get an item on me that isn't part of a narrative I'm fucked. I don't have any mod that allow the removal of items or stuck items, so if I have one on me, I'm fucked. If I spawn a key and use it for the key to break, I'm fucked.

 

I fall back to the argument I gave way back here (on the annoying gag loop): don't keep me from playing my game. DDi is a framework, it's base behavior should have no impact on me. If you make it so that keys breaks by default, make it so that devious can be removed through the game (and not the MCM).

 

There are apparently mods that allow removal or that adds key into the world, I can't think of any right now. Well, except deviously cursed loot which I don't use. Captured dream shop still needs to be updated. And beyond that, what is there? Will I be forced to install a mod I don't want just to bypass the design flaw?

 

You see, the keys breaking isn't the issue. The issue is that there is by default no escape. If it weren't for the debug thingy, I would be reduced to reloading to an earlier save or simply savescumming the RNG until the key don't break. I like the devious items for the aesthetic, not so much for the inherent restrictions.

 

I remember naked dungeon to allow for prostitution against keys, but even then if the key breaks and jam the lock there is still no way to remove that item. I may be missing something though, because the changelog does state: "By default, keys do not break until the item creator sets this value to higher than zero.". Which is weird because I had a standard device on my character, and the key did break. Looking into xEdit, I realize that all vanilla items have a base chance of 25% to break the keys (for the items possessing a lock). So, which is it?

 

Would you be so kind to list the mods that implement the feature to remove devices from the player (jammed or not)?

Link to comment
34 minutes ago, bicobus said:

Would you be so kind to list the mods that implement the feature to remove devices from the player (jammed or not)?

DD for the masses https://www.loverslab.com/files/file/424-d comes to my mind. But unfortunately it is still for DD3 and not yet updated to cope with DD4 ... I can't comment on the impact of that old version on keys .. have not tested it in game yet.

Link to comment

I definitely agree that player control over device difficulty isn't ideal. There were, as I remember, going to be no difficulty options for the player at all at one point though, so having any control over it is better than none. But is there anything that states what each of the ranks actually mean? Things like key breaking. How much difference is there in the chances of that happening between the easiest rank and the hardest? And how much longer does each rank force you to wait due to exhaustion before trying again to turn a key in a lock?

 

As I don't currently use any other mods that drop keys or offer ways out of devices, and as DDi no longer offers the option to ask for help with an armbinder, I just select the easiest difficulty, manipulate every device before equipping them if I can, and get on with it. Though it is, to be fair, probably the only thing I don't like about the new versions. Everything else is fantastic!

Link to comment
47 minutes ago, SleepyJim said:

I definitely agree that player control over device difficulty isn't ideal. There were, as I remember, going to be no difficulty options for the player at all at one point though, so having any control over it is better than none. But is there anything that states what each of the ranks actually mean? Things like key breaking. How much difference is there in the chances of that happening between the easiest rank and the hardest? And how much longer does each rank force you to wait due to exhaustion before trying again to turn a key in a lock?

 

As I don't currently use any other mods that drop keys or offer ways out of devices, and as DDi no longer offers the option to ask for help with an armbinder, I just select the easiest difficulty, manipulate every device before equipping them if I can, and get on with it. Though it is, to be fair, probably the only thing I don't like about the new versions. Everything else is fantastic!

Based on posts in this thread from the devs, and comments in the scripts, it seems to change from -75% to +75% (with the default setting being 0%) based on the setting you choose. So on easiest it would almost double all the chances, and only have 25% of the wait. And the opposite for the hardest setting.

Link to comment
5 hours ago, bicobus said:

DDi is a framework, it's base behavior should have no impact on me. If you make it so that keys breaks by default, make it so that devious can be removed through the game (and not the MCM).

DDI by itself won't impact your game. Ever.

 

Yes, really!

 

Because DDI never equips one single item on you. Ever.

 

Content mods do that.

 

Why do you blame the framework instead of the mod that actually tied you up?

Link to comment

You put then the blame on third party mod, not handling the Devious Devices mechanic properly? Which is most of the mods out there. I have no idea which mod would remove a jammed item, I mean really. I know of some that adds keys, but by default keys can jam the device. So each single mod should create a feature to handle such situation, every single one of the mod posted on LL should implement that feature? With what you just told me DDi 4.0 is incompatible with nearly everything present on this website, because nearly nothing handles the jam mechanic. A mechanic that can be save scummed out of, so it's just there as an annoyance.

 

Devious devices cannot lock and jam themselves on the player by default, ever. That's an extra feature that should be handled by content mods, the same mods that would implement a way out of those devices too. The jam mechanic impede by default userland, and it shouldn't. Not without a way to counter that mechanic also present.

 

A way out of this mess could be the following:

  •  Create a global variable (boolean) that handle the lock and jam mechanics. Let's name them dkey_active and djam_active.
  •  Those variable are set to false by default.
  •  The framework won't penalize a player with a jammed lock (if djam_active is set to false) or prevent the player to remove devious items (if dkey_active is set to false)
  •  Any new mod implementing a mechanic to give keys to the user or a way out of a jammed item would turn those variable to true, thus enabling the framework features globally.

This would ensure that any older mod, or incomplete mod, wouldn't impede on the user experience.

 

As you said, content mods are responsible for dealing with the user. The framework should never, ever, have a default behavior that would interfere with the user without a mod telling it to. The default devious items have settings contrarian to that idea.

Link to comment
7 hours ago, bicobus said:
7 hours ago, Kimy said:

You can repair a jammed item using DDI mechanics.

Those are never advertised to the player. It is also something that should go into a content mod, not into a framework.

They are part of the device menu, not sure how better the mod could "advertise" them? As far as I remember, the "unjam lock" button is even there on the device menu when the lock is NOT jammed. You can click it any time, only when the lock isn't jammed, you'll get a message that tells you just that... that the lock isn't jammed. Also, at the easiest difficulty level (vanilla, IIRC), you'll need really quite a lot of bad luck to get a broken lock.

 

I know of two mods that deal with jammed locks in a "lore-friendly" way: in Cursed Loot, the dollmaker will unjam them for a hefty fee (not really that attractive if you can do it by yourself you in the device menu, unless on harder difficulty setting) -- and the Captured Dreams master will remove devices no matter if jammed or not when she's removing stuff from you, for a fee, of course.

Link to comment

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

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use