Jump to content

Welcome to LoversLab
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. If you already have an account, login here - otherwise create an account for free today!
Photo

Devious Devices Framework Development/Beta


  • Please log in to reply
735 replies to this topic

#41
Verstort

Verstort

    Mega Poster

  • Members
  • PipPipPipPipPip
  • 1,457 posts

Top of the page hijack:

I made a change to the armbinder NPC animation test mod to make it UFO friendly: http://www.loverslab...beta/?p=1749741

 

So you added ?

IdleDrunkStop [IDLE:000CEFD1]

IdleStop_Loose [IDLE:0010D9EE]

And ciceroHappy, and one other animation that was in that list he posted

I think it was just 4, the only in his list that still isn't in the test mod is the squat animation, so far I haven't seen that one used ever, much less in an armbinder.

 

I am still not sure if animations like IdleCiceroHappy need to be blogged at all because no npc would trigger that one randomly. In the CK animations window you can do rightclick>UseInfo and see which references use this animation. If it isn't used in any sandbox/master package or in an idlemarker no npc should play it while walking around skyrim. At the moment I don't see any problems with blocking these animations either, just saying we should decide which animations we really want to have blocked when this gets integrated.

 

I made a version without he CiceroHappy animation condition and it was firing on the NPC, then I tried manually testing that animation on the player with playidle and it was the exact same idle the NPC was using that I couldn't find earlier. If you still have that short video I posted earlier that showed the two animations I couldn't account for, the one where he looks like he's trying to hurry the player along, that's the happy animation.

 

Doesn't look "happy" to me, but then cicero was deranged...

 

Yes adding the heavybondage condition to the animations was all I did, I was a bit surprised too that the solution might be this easy and apparantly no one already did this.

That's also why I suspected to encounter problems like packages or scenes getting stuck. Has anyone of you encountered any issues yet ?

 

I haven't, but then I haven't played but with very few mods where this is likely to show up. Pretty sure we're worried about edge case conflicts here, hard to find.

 

I mean, the situation has to match: 1) NPC or follower can find themselves in an armbinder or a DD based item that has the keyword, 2) needs to use one of those animations you blocked to do something.

 

I don't think it's actually going to cause issues to other mods because that's pretty special breaking case. If one of the animations breaks it's probably going to be one where the NPC is inspecting something, or reading something in a scene, but the armbinder shouldn't be there in any vanilla/dlc case, exception: mod that adds random DD to various NPCs in the world, and I don't think any of them do that with armbinder/yoke anymore (FTM/DCL are fine I think)

 

I'm more concerned about problems the other way, ergo some other mod changes the same animations and now we have a conflict that causes these animations to work on NPCs again, but that sounds like a far smaller issue. It'll be a bigger issue if we merge these changes into DD proper because we can't move DDi in the load order very easily because its master file, but the test mod is a bit more flexible in load order position.


  • 0

AdBot

AdBot
  • Advert

#42
Hæretic

Hæretic

    Senior Member

  • Members
  • PipPipPipPip
  • 361 posts

I am much more concerned about vanilla quests getting stuck because of this than any quest mods. That's why I asked to play quests with this enabled.

 

About conflicts with other mods, I don't think this is a big issue at all. First of all, only very few mods alter anything about the animations, second even if another mod adds another condition to any animation this wouldn't remove our condition. As far as I know there is absolutely no problem with multiple mods adding conditions to the same animation.

 

 


  • 0

#43
Veladarius

Veladarius

    Mega Poster

  • Contributor
  • PipPipPipPipPip
  • 7,627 posts

 

 

 

I'm making a mod that uses several devious devices, but I have different textures in mind than the vanilla ones. Currently what I've done is copied the meshes into a separate folder and then applied my own modified textures, but this was back when DD was for UNP. Now that it's gone bodyslide, my meshes will be out of date on many (most?) users bodies.

 

Rather than make multiple copies of the mesh to include in my mod, would it be better that I upload my textures and have them as part of the base DD items? If it's not too gauche a request? Or is there a better way to do this?

 

You don't need to include any meshes to retexture items. You can just make new texturesets in the creation kit and new ArmorAddon entries, change the textures in the window where you choose the nif for the armor addon.

 

I've used this. Sometimes I find a texture will work that way and not work when done in the Mesh. 

 

But I avoid using this method if it works directly in he mesh. This is because I find (and others have reported), that it will sometimes glitch out causing the item to revert to whatever's in the nif. This glitch will go away when you reload a save, or sometimes you have to restart the game.

You're kidding. I thought I had to change the entries in the NiTriShape/BSLightingShaderProperty/BSShaderTextureSet block!

 

 

All of the custom Captured Dreams devices use this method to change the textures.


  • 0

#44
Verstort

Verstort

    Mega Poster

  • Members
  • PipPipPipPipPip
  • 1,457 posts

I am much more concerned about vanilla quests getting stuck because of this than any quest mods. That's why I asked to play quests with this enabled.

 

About conflicts with other mods, I don't think this is a big issue at all. First of all, only very few mods alter anything about the animations, second even if another mod adds another condition to any animation this wouldn't remove our condition. As far as I know there is absolutely no problem with multiple mods adding conditions to the same animation.

 

I thought if two mods modified the same vanilla object then the one lower in load order would overwrite the changes from the first.

 

I thought the same would happen to conditions, but that makes sense for them to merge.

 


  • 0

#45
wubwubwub

wubwubwub

    Member

  • Members
  • PipPipPip
  • 58 posts

More testing, not on quests with idles yet (sorry, haven't had much playtime today).

 

Couldn't get Verstort's modded .esm to stop UFO from playing idles (even on a fresh character), so I edited UFO itself to remove them. Everyone is now staying happily bound when standing still.

 

Odd behavior with dialogue:

On dialogue enter or exit, followers (and non-follower NPCs) seem to like playing an idle animation that breaks the armbinder animation until the NPC moves. The fix for this is to gag and ungag the character. They then stop playing that animation with dialogue and stay bound (or rather they stop period, also when not bound). Happens on a fresh character started with the esm active, as well as the save I had before installing. I'm guessing there's something baked in to the NPCs to play the idle, but it gets stripped when gagged because of changes (from whichever mod changes audio to the ZaZ female gag talk sounds) the gag makes to dialogue. Once gagged the fix seems pretty permanent. NPCs didn't start breaking the armbinder animation on dialogue again even after zoning or a save & reload. Also not a huge problem, any NPC that finds themselves with tied hands will probably also get a gag

 

Should have some more intensive testing of the actual idles in quests tomorrow, and possibly narrowing down of the dialogue + gag oddities. I can say that nothing broke so far while wreaking havoc in whiterun.


  • 0

#46
Hæretic

Hæretic

    Senior Member

  • Members
  • PipPipPipPip
  • 361 posts

 

I thought if two mods modified the same vanilla object then the one lower in load order would overwrite the changes from the first.

 

I thought the same would happen to conditions, but that makes sense for them to merge.

 

 

Correction, other mods do overwrite the animation conditions, I am pretty sure I saw this working in TESVEdit but maybe I just remember bullshit.

But how this works might be a little different than you assume, If another mod adds a custom condition to an animation the last one in the list gets overwritten not the entire list. This means if I put the same condition 3 times in there, as long as no other mod adds his own 3 custom conditions only 1 or 2 will get overwritten the others stay intact. 

 

So this indeed is a problem because like you already mentioned DD is a master and is always low in the load priority. Almost every other mod will overwrite the conditions if it adds its own.

 

For the Dialogue tree I already found a solution by adding a custom DD dialogue tree with a higher priority. I did this because I wanted to add emotion dialogue animations like in the vanilla tree but customized for yokes/armbinders. This has the lucky side effect that this tree will get triggered before the vanilla tree if the conditions are met, so we don't need to add any custom conditions to other trees in the same branch as long as our custom trees have a higher priority.

But of course, this doesn't work for loose animations because they get triggered directly by an object, not by an animation variable. They don't have any hierarchical structure like everything else.

 

I see some ways to workaround this issue but most of them are kind of dirty solutions.

1. We could add the same conditions multiple times to assure no other mod overwrites them all, this might work without any problem but it's kind of an ugly way to do solve this.

2. We could add child animations to every loose animation we want to block, these play the actual animation and we add our condition to the child. This way other mods could still add their conditions to loose animations, it would check those conditions go to our child tree and check our conditions and then plays the animation. Also, an ugly solution plus I could see how this might cause other issues so I would not try this first.

3. We could proceed with just adding one condition per animation, and hope no other mods touches the loose animations. It's also not hard to find out if any mod changes animations DD has already modified. If another mod uses DD as a master our conditions will be shown and they could add their own so in this case there isn't any problem.


  • 0

#47
ssonly

ssonly

    Member

  • Members
  • PipPipPip
  • 83 posts

NPC animation block does not work in taverns. Outside tavern works.


  • 0

#48
Verstort

Verstort

    Mega Poster

  • Members
  • PipPipPipPipPip
  • 1,457 posts

NPC animation block does not work in taverns. Outside tavern works.

 

Can you specify which inn, which armbinder if not the standard DDi armbinder, and which NPC you saw it on if the NPC was not from the base game?

 

Mod load order might be important, papyrus might have something useful.

 

I only saw the animation break once for me, it was a male NPC follower and would only break on COC into inn, not regular door use. Not sure what to make of it, but since it only happens on COC I doubt it's the same bug you have, since adding regular armbinder to NPC and follower in nightgale and banneredmare worked fine.

 

 


  • 0

#49
pincopallino

pincopallino

    Perverse Idiot

  • Members
  • PipPipPip
  • 180 posts

still WIP but doing textures, after that sknning, uunp, bodyslides etc

Attached Files


  • 12

#50
ssonly

ssonly

    Member

  • Members
  • PipPipPip
  • 83 posts

 

NPC animation block does not work in taverns. Outside tavern works.

 

Can you specify which inn, which armbinder if not the standard DDi armbinder, and which NPC you saw it on if the NPC was not from the base game?

 

Mod load order might be important, papyrus might have something useful.

 

I only saw the animation break once for me, it was a male NPC follower and would only break on COC into inn, not regular door use. Not sure what to make of it, but since it only happens on COC I doubt it's the same bug you have, since adding regular armbinder to NPC and follower in nightgale and banneredmare worked fine.

 

Solitude, The Winking Skeever, NPC Lisette, Erdi and other visitors. I used "Black Armbinder" and "Yoke (iron)" from DDi (not in one time). Also I tried "Touch of control" spell from DCL.

Same thing in Bannered Mare in Whiterun.

All bound NPC use furniture, sits, cooks etc.


  • 0

#51
Verstort

Verstort

    Mega Poster

  • Members
  • PipPipPipPipPip
  • 1,457 posts

NPC animation block does not work in taverns. Outside tavern works.

 

Can you specify which inn, which armbinder if not the standard DDi armbinder, and which NPC you saw it on if the NPC was not from the base game?

 

Mod load order might be important, papyrus might have something useful.

 

I only saw the animation break once for me, it was a male NPC follower and would only break on COC into inn, not regular door use. Not sure what to make of it, but since it only happens on COC I doubt it's the same bug you have, since adding regular armbinder to NPC and follower in nightgale and banneredmare worked fine.

Solitude, The Winking Skeever, NPC Lisette, Erdi and other visitors. I used "Black Armbinder" and "Yoke (iron)" from DDi (not in one time). Also I tried "Touch of control" spell from DCL.

Same thing in Bannered Mare in Whiterun.

All bound NPC use furniture, sits, cooks etc.

 

It seems I missed this in previous tests because, if you dismiss a follower in some indoor regions where they did not originate then they don't revert to AI, they just stand there, sometimes watching you. I'm pretty sure this is a bug on my end.

 

But yes, I get the same bug where NPCs can sit down at chair/bench, and they can sweep the floor in armbinder, cooking, eating bread.

 

Maybe add the same conditions for those too? They're cosmetic animations so they shouldn't have a larger impact than the current animations we block. The only one I'm worried about is sitting, and I'm curious if we could get around it by just creating an armbinder friendly sitting animation, so that their arms stay in that position while they sit. Not a big deal for benches, chairs are more annoying, but not sure what to do there.

 

I wonder if we should block eating animations while in a gag, in the same vein?

 

@Kimy, thanks for implementing the plug/piercing on NPC fix!
 


  • 0

#52
unmog

unmog

    Senior Member

  • Members
  • PipPipPipPip
  • 441 posts

still WIP but doing textures, after that sknning, uunp, bodyslides etc

Woot :)

I much prefer that to the current hobble dresses.


  • 0

#53
Verstort

Verstort

    Mega Poster

  • Members
  • PipPipPipPipPip
  • 1,457 posts

I thought I could stop NPCs from sitting down and eating/drinking with the same animation block, but it didn't work. Not sure if there's a batch of animations hidden in the tree I didn't see or what the deal is...


  • 0

#54
TecQueen

TecQueen

    Member

  • Members
  • PipPipPip
  • 84 posts

So what is the difference between framework and the zip? Still little new in all this. Is it all the DD in one pack sorta speak?


  • 0

#55
Kimy

Kimy

    Mega Poster

  • Contributor
  • PipPipPipPipPip
  • 2,862 posts

 

@Kimy, thanks for implementing the plug/piercing on NPC fix!
 

 

Yay, somebody noticed!!!  \o/
 


  • 0

#56
Nergui

Nergui

    Negative Poster

  • Members
  • PipPipPipPip
  • 612 posts

Suggestion (assuming this isn't already planned/implemented) for DD MCM menu. Include the "Lock Shield" option to become inaccessable like "Escape Options" if wearing restraints.


  • 0

#57
Kimy

Kimy

    Mega Poster

  • Contributor
  • PipPipPipPipPip
  • 2,862 posts

Suggestion (assuming this isn't already planned/implemented) for DD MCM menu. Include the "Lock Shield" option to become inaccessable like "Escape Options" if wearing restraints.

 

It's actually meant to be, but I will check the code.


  • 0

#58
Veladarius

Veladarius

    Mega Poster

  • Contributor
  • PipPipPipPipPip
  • 7,627 posts

Some questions and such on the zad_questitem keyword and the removal command:

 

- Question - From the looks of the command, the keyword used for the removal token in the command can be any keyword, correct?

 

- Question - There is only a removal command for this and no equip command, correct?

 

- Suggestion for Modders - If you are using this you should define your own keyword and continue to use zad_blockgeneric to ID quest items or any mod using the questitem keyword can remove your devices.

 

- Suggestion to dev team - add a true/false condition to devices (false as base) to identify quest items and what the keyword is to remove them which would also need to be on the scriptinstance item. This would allow modders to easily make quest devices without the hassle of modifying the item's script unless they want additional effects for trying to remove the device or such.


  • 0

#59
Kimy

Kimy

    Mega Poster

  • Contributor
  • PipPipPipPipPip
  • 2,862 posts

Some questions and such on the zad_questitem keyword and the removal command:

 

- Question - From the looks of the command, the keyword used for the removal token in the command can be any keyword, correct?

 

It can not be one of DDI's standard keywords that are expected to be on any DD item anyway. It needs to be a custom keyword.

 

- Question - There is only a removal command for this and no equip command, correct?

 

Correct.

 

- Suggestion for Modders - If you are using this you should define your own keyword and continue to use zad_blockgeneric to ID quest items or any mod using the questitem keyword can remove your devices.

 

I added awareness of zad_QuestItem to the generic framework functions. They will not try to remove this items (nor could they)

 

- Suggestion to dev team - add a true/false condition to devices (false as base) to identify quest items and what the keyword is to remove them which would also need to be on the scriptinstance item. This would allow modders to easily make quest devices without the hassle of modifying the item's script unless they want additional effects for trying to remove the device or such.

 

You do not need to modify the item's script in any shape or fashion. You just put the zad_QuestItem keyword and your "key keyword" on the item.

 


  • 0

#60
Veladarius

Veladarius

    Mega Poster

  • Contributor
  • PipPipPipPipPip
  • 7,627 posts

 

Some questions and such on the zad_questitem keyword and the removal command:

 

- Question - From the looks of the command, the keyword used for the removal token in the command can be any keyword, correct?

 

It can not be one of DDI's standard keywords that are expected to be on any DD item anyway. It needs to be a custom keyword.

 

- Suggestion for Modders - If you are using this you should define your own keyword and continue to use zad_blockgeneric to ID quest items or any mod using the questitem keyword can remove your devices.

 

I added awareness of zad_QuestItem to the generic framework functions. They will not try to remove this items (nor could they)

 

- Suggestion to dev team - add a true/false condition to devices (false as base) to identify quest items and what the keyword is to remove them which would also need to be on the scriptinstance item. This would allow modders to easily make quest devices without the hassle of modifying the item's script unless they want additional effects for trying to remove the device or such.

 

You do not need to modify the item's script in any shape or fashion. You just put the zad_QuestItem keyword and your "key keyword" on the item.

 

 

 

So in the function

 

Function RemoveQuestDevice(actor akActor, armor deviceInventory, armor deviceRendered, keyword zad_DeviousDevice, keyword RemovalToken, bool destroyDevice=false, bool skipMutex=false)

 

Does the keyword for RemovalToken need to be zad_questitem or something else?


  • 0