Deviously Helpless

[DocClox]

I don't have the CK here, so I can't check the package conditions, but I'm guessing they are supposed to apply in order.

 

I wonder if that would work better as one package with a repeating stack branch.

[Slorm]

Hope this may be of help.

 

I’m working from memory as I don’t have my beta test notes, but the following conditions apply to the main part of the mod. I'll use bandits as a generic term for all attackers.

 

There are three parts to it:

 

1/ Pacification

2/ Cloak to draw bandits/creature to pc

3/ LOS if the pc is concealed/sneaking

 

The conditions are as follows

 

Assuming the pc is fitted with a devious device:

 

If the pc is armed the cloak is off

 

If the pc is sneaking then only LOS test will be working until detection (cloak off)

 

If the pc isn’t sneaking or sneak is detected by LOS then the cloak will kick in and draw all enemies to the pc regardless of LOS (it works through walls) and pacify all in range.

 

If the pc flees the bandits will chase the pc until a cell change point is reached. If the bandit reaches the player the SL routine kicks in as normal, if the player escapes into the next cell the bandit becomes hostile. From memory we settled on bandit speed at around 125% of pc, so that the pc needs to use sprint a lot to get away (it's hard but can be done)

 

From tests using Fort Greymoor as an example we know that the pacification works, the pc can happily wander round without being attacked but has to move very close to a bandit and a single SL scene will then fire.

 

The problem lies with the cloak which is no longer drawing the NPC’s to the pc, so the pc has to be directly next to an NPC for a SL event to fire (as mentioned above).

 

 

 

[DocClox]

It's not the cloak that's the problem

 

I just tried setting all the package overrides to the same priority. Teleported to Fort Greymoor and the bandit on watch cam shooting down to intercept. I know the code's supposed to boost their speed but I don't recall them being that fast before.

 

Anyway, bandit then proceeds to have her way with my toon. Then follows her everywhere.

 

Walking further into the fort, four other bandits turn up. Two of them try and start a scene at the same time. Then the computer hardlocks and I have to reboot. The hardlock isn't necessarily down to Skyrim however.

 

So: clearly that isn't going to work by itself. Whatever is supposed to set satisfied bandits back to their sandboxing isn't working now. I think I need to look at the conditions.

 

Is there some sort of etiquette around adopting an abandoned mod?

 

[edit]

 

OK: the packages are all conditioned on globals set in the script. Part of me really wants to rip all that out use a proper quest & scene combo. Have it repeat until all the participants have their arousal drop below a certain threshold. On the other hand, a minimal fix would probably be better unless I really do want to adopt this sucker.

[Min]

Just message one of the mods about it, shouldn't be a problem.

[DocClox]

I PM'd Srende as a courtesy. If he is lurking, or looks in from time to time, I wouldn't want him to think that no one made the effort to contact him.

[Slorm]

Anyway, bandit then proceeds to have her way with my toon. Then follows her everywhere.

 

 

The last bandit following the pc tends to happen now I always thought of it as a "feature". The bandit stops following once the pc has moved a short distance and stopped.

 

That's using SL1.59c it sounds like its broken in SL1.60 from what you're saying

 

[DocClox]

If the last bandit following is a feature then it may be that setting all the override priorities the same is the fix.

 

But yeah, it's definitely broken as it is right now.

 

[edit]

 

Corrected the worst of the phone-speak

[DocClox]

OK gang - try this:

 

If it looks even remotely like it works, I'll see about getting posting rights to the DH project. Or start Deviously Helpless Again or something.

Deviously Helpless 1.16a.7z

[Slorm]

OK gang - try this:

 

If it looks even remotely like it works, I'll see about getting posting rights to the DH project. Or start Deviously Helpless Again or something.

 

Tested on a new game at Fort Greymoor:

 

First the good news, all the bandits are drawn to the pc correctly and the first sex animation starts

 

Now for the bad, while the animation is playing the bandits then all wander off back to their places.

 

Once the scene finishes devices are fitted properly but a couple of the bandits keep following the pc. The trick of stopping no longer works the bandits keep bumping the pc.

 

One other thing I noticed which only happens in SL1.60 is the pc's weapon is not unequipped when stripped though this is cosmetic.

 

If the changes you made are just to the first part of attracting the bandits then you're spot on.

 

EDIT:

 

Forgot to mention, it behaves correctly if the pc is armed (no cloak) and the same if sneaking until discovered, so those parts are fine. I haven't tested anything else

 

[DocClox]

OK, cool. All I did was set the package overrides to the same priority.

 

All of the packages are conditioned on globals set in the scripts, and I got a bit lost trying to unravel them all. I think I need to take some time and go though systematically.

 

Did anyone have an issue with multiple sex acts occurring at the same time? I think they're supposed to queue and I don't think they are. Which is probably the other half of the problem. If they're powering through the logic too fast for some reason, globals are probably being set before they should.

[Reesewow]

OK gang - try this:

 

If it looks even remotely like it works, I'll see about getting posting rights to the DH project. Or start Deviously Helpless Again or something.

 

Gave it a shot, similar results to Slorm.  The initial aggro seems to work fine, including the weapons equipped/sheated toggles and staying in stealth.  You do seem to instant-aggro anything in range if not already sneaking on entering a cell, but I believe the old version of helpless worked this way as well.  Follower getting involved and items being equipped after also seemed to work fine.

 

What didn't work well is that even if a large group had been aggroed, at max 2 would get involved, and that may have been linked to the fact the bandit animating with the follower would swap to the PC (altho this could be a welcome feature as a toggle to avoid a 15 minute loss of player control per engagement if you are trying to get out of a dungeon).  After an event, the bandits would start walking back to their sandboxing, but once their closing dialogue finished one or more would run up and follow closely.

 

Would definitely welcome someone releasing updates to this mod going forward, since its is IMO a fairly important companion mod to making the more debilitating devious devices playable in regular Skyrim gameplay

[Slorm]

One further update. Tested the Draugr again with DD development mods rather than the released ones and the rusted chastity belt is working (thanks Min).

[DocClox]

OK. So it's better than what we had, at least.

 

If the queuing mechanism is broken, that might explain the limited number of actors as well as multiple concurrent acts. I'll take a look when I'm more awake.

[Ashal]

That's certainly consistent with what I've been seeing.

 

Hmmm...

        AddPackageOverride(akActor, attackChasePackage, 97)
        AddPackageOverride(akActor, approachPackage, 98)
        AddPackageOverride(akActor, gatherPackage, 99)
        AddPackageOverride(akActor, sandboxPackage, 100)

With priority 100, isn't that saying that the sandbox package should overrule the attack/chase and approach packages? That too would be consistent with what I've seen.

 

Could this be a case where the code only worked because of an unnoticed bug - in ActorUtil in this case? Then Ashal fixes the bug and the code stops working?

 

 

Priorities are largely ignored in the current versions of PapyrusUtil. It instead just simply defaults to the most recent package in the actors stack that was added. It's been that way for a little while though, mostly due to laziness on my part, and was more specifically like that in 1.59c.

EDIT: After reviewing the code some more, never mind the above part actually. I apparently have actually added priority support with packages in newer versions. In older versions like the one that was included with 1.59c however, priority support was not yet present.

 

 

 

The only thing that's changed in the PapyrusUtil versions in 1.59c and 1.60, as far as I can remember anyway:

1. Added back in the overrides being saved between loads, instead of discarding them (after the saving was removed in a previous version).
2. Fixed a CTD caused by removing a package override and that after removal would result in the package override mapping to be completely empty.

Nothing else about them changed, I don't think. Will have to browse my commit history in Git later to double check.

[Eaglelight]

would be amazing if you caould add an option in mcm that would let you use More Nasty Critters to be used also if that is posible

[DocClox]

EDIT: After reviewing the code some more, never mind the above part actually. I apparently have actually added priority support with packages in newer versions. In older versions like the one that was included with 1.59c however, priority support was not yet present.

Looks like my guess was right then; it was only working because priorities weren't supported.

 

I'll take another look at the queueing problem over the weekend.

would be amazing if you caould add an option in mcm that would let you use More Nasty Critters to be used also if that is posible

Let me get it working with bandits first

[Ashal]

 

EDIT: After reviewing the code some more, never mind the above part actually. I apparently have actually added priority support with packages in newer versions. In older versions like the one that was included with 1.59c however, priority support was not yet present.

Looks like my guess was right then; it was only working because priorities weren't supported.

 

I'll take another look at the queueing problem over the weekend.

 

Previously before priority support was added back in, the package last added automatically had priority. So in this case, Deviously Helpless adds the sandbox package last with a priority of 100. Which means it should be acting similarly between versions with or without priority support. In the old version it would pick sandboxPackage because it was the last one added, in newer versions it would pick sandboxPackage because it has a priority of 100.

 

It sounds like the most probable candidate. On a more basic programming level though it sounds like it has nothing to do with it either. 

 

I'd suggest narrowing down what specifically isn't working as expected, and what each of the packages DH adds is meant to do. If the the problem becomes clearly within the package overrides and the problem isn't simply that priorities are working now, I'll look further into fixing it on my end. 

[DocClox]

Well ... all the packages are toggled by globals. All potential attackers go into a formlist and get popped out in turn to have a go and when everyone is done the package clocks on/

 

I think that, for whatever reason, the mod is running through those stages too soon, which meant that it was setting the enable flag for the Sandbox package before anyone had a chance to engage. Beyond that, I need to do some instrumenting and see what else is happening.

 

I didn't think it was anything from Sexlab to blame,. The packages are just working as sepecified, and from what you say about the previous behavior the fix probably wasn't the cause anyway. I suppose it's possible that there's something else in PapyrusUtil that changed its behavior, but I have no evidence of that at all.

 

I should get a chance to look at it this weekend, RL and Sheogorath allowing.. I'll post my findings

[Slorm]

@DocClox

 

One other small item it would be handy to clean up if possible which is nothing to do with SL. A bit of history, some time back when ZAP was updated (from memory) to 6.04 it broke the bindings at the end when the pc escapes, so that the pc's arms were free although the binds were fitted to the wrists and as the release timer didn't kick in so the console was needed to remove them.

 

After some poking around and discussions Xaz made a patch for DH (see page 41 of this thread) to fix this which was later incorporated into ZAP, but we did miss one thing in the testing as the incidence of it's happening is very low and rarely happens, (in other words I forgot about it).

 

There is a small chance that after a Draugr attack that a rusty belt is not fitted. I can't remember the percentage chance but it's quite low but the upshot is that when it happens the binds are broken.

 

Xaz is on hiatus I gather so a quick fix would be to either:

 

Increase the chance or the belt to 100% - or:

Always equip an armbinder rather than binds at the end of a Draugr scene (regardless of whether a belt is fitted).

 

Sorry to have rambled and it's no big deal as it's a rare event but would be nice to tidy it up if possible.

[Mahalance]

quick question, does this work for followers? my followers kill all of bandits with DDs

[RockMic]

quick question, does this work for followers? my followers kill all of bandits with DDs

It also works with this fellow.

Consider that the mod and was recently brought to version 1.16a which and in testing.

you can download the latest version of the page 47.

[Mahalance]

 

quick question, does this work for followers? my followers kill all of bandits with DDs

It also works with this fellow.

Consider that the mod and was recently brought to version 1.16a which and in testing.

you can download the latest version of the page 47.

 

ok thanks for quickly reply, i'll try

[Mahalance]

it's still fail, if i dont wear any DDs, enemies will just focus on me.

[RockMic]

it's still fail, if i dont wear any DDs, enemies will just focus on me.

And you must have elements DD upward, and you can configure the menu mcm quell that interest you, but you must have roofs lean against them.

[Mahalance]

 

it's still fail, if i dont wear any DDs, enemies will just focus on me.

And you must have elements DD upward, and you can configure the menu mcm quell that interest you, but you must have roofs lean against them.

 

hmm...enemies still focus on me if i wear DDs , i just want to see if enemies  ignore me and rape my followers, is it possible?