Jump to content

Recommended Posts

Posted
3 hours ago, DocClox said:

Still getting that load screen issue. Latest occurrence went like this:

 

  • Leave Stillborn Cave (Bare escaped with my life! Falmer are bad enough, but with Forgotten Wenches to deal with ...)
  • Headed down the road to Fort Karstav.
  • Won the fight there and took two slaves using PAHE. PAHE is better for combat, because DoM abductees tend to fight on for a while afterwards. Maybe this is intentional?
  • Anyway stripped and tied captives and took them to the fire on the fort roof. Used Jaxonz Positioner to move them.
  • Converted first slave to DoM
  • Got as far as telling her she'd be bound and gagged
  • ... and the screen went black. Next thing you know I'm outside Stillborn Cave again.
  • Ran back again and got there just in time to administer some Sparks to a struggling necromancer.

 

Second captive didn't trigger the effect, for what little that may be worth.

I could make some tests if you are willing to send me a save in pm.

Posted
1 hour ago, TrollAutokill said:

I could make some tests if you are willing to send me a save in pm.

 

Done that.

Posted (edited)
7 hours ago, DocClox said:

Still getting that load screen issue. Latest occurrence went like this:

 

  • Leave Stillborn Cave (Bare escaped with my life! Falmer are bad enough, but with Forgotten Wenches to deal with ...)
  • Headed down the road to Fort Karstav.
  • Won the fight there and took two slaves using PAHE. PAHE is better for combat, because DoM abductees tend to fight on for a while afterwards. Maybe this is intentional?
  • Anyway stripped and tied captives and took them to the fire on the fort roof. Used Jaxonz Positioner to move them.
  • Converted first slave to DoM
  • Got as far as telling her she'd be bound and gagged
  • ... and the screen went black. Next thing you know I'm outside Stillborn Cave again.
  • Ran back again and got there just in time to administer some Sparks to a struggling necromancer.

 

Second captive didn't trigger the effect, for what little that may be worth.

@TrollAutokill

 

I have seen this before in AYGAS and @Musje actually fixed it pretty recently.

 

Basically, for whatever reason there is a bug that makes certain first person animations force the player to slingshot back to their most recently used load-door; I recall experiencing this regularly at AYGAS auctions. In that mod, pressing Enter to bid on a slave had your character play a little hand waving animation, that animation would shoot you back to the last door you used. This time, the tying animation seems to be the culprit, and the exact thing Doc just described happened in my game and that is definitely what this is. Doc, I would wager that Stillborn was the last load-door you used and that the slave you were capturing was outside the fort, rather than in an interior cell. 

 

Short-term fix: Only do the animations in third-person, this prevents the bug from happening in the first place.

 

Long-term fix: I don't know, Musje will have to share how that problem was solved in AYGAS.

Edited by InsanityFactor
Posted
6 hours ago, InsanityFactor said:

Doc, I would wager that Stillborn was the last load-door you used and that the slave you were capturing was outside the fort, rather than in an interior cell. 

 

Spot on. And the animation in question is the one where you tie a newly abducted slave.

 

It can happen indoors though: I just got teleported across Dimhollow Crypt, from the gate of the first chamber to just inside the entrance passage.

Posted (edited)
8 hours ago, InsanityFactor said:

@TrollAutokill

 

I have seen this before in AYGAS and @Musje actually fixed it pretty recently.

 

Basically, for whatever reason there is a bug that makes certain first person animations force the player to slingshot back to their most recently used load-door; I recall experiencing this regularly at AYGAS auctions. In that mod, pressing Enter to bid on a slave had your character play a little hand waving animation, that animation would shoot you back to the last door you used. This time, the tying animation seems to be the culprit, and the exact thing Doc just described happened in my game and that is definitely what this is. Doc, I would wager that Stillborn was the last load-door you used and that the slave you were capturing was outside the fort, rather than in an interior cell. 

 

Short-term fix: Only do the animations in third-person, this prevents the bug from happening in the first place.

 

Long-term fix: I don't know, Musje will have to share how that problem was solved in AYGAS.

 

1 hour ago, DocClox said:

 

Spot on. And the animation in question is the one where you tie a newly abducted slave.

 

It can happen indoors though: I just got teleported across Dimhollow Crypt, from the gate of the first chamber to just inside the entrance passage.

Great! A quick fix would be to put the player in 3rd person before playing an animation.

 

Better fix would be to identify the faulty marker and move it to the player beforehand.

 

It could also be that using debug.sendanimationevent instead of playidle is the problem.

Edited by TrollAutokill
Posted
3 hours ago, DocClox said:

 

Spot on. And the animation in question is the one where you tie a newly abducted slave.

 

It can happen indoors though: I just got teleported across Dimhollow Crypt, from the gate of the first chamber to just inside the entrance passage.

Yep, I did the same thing earlier, I tied a new capture in a dungeon and I got teleported back to the entrance. It's tied to load-doors, for whatever reason.

 

 

2 hours ago, TrollAutokill said:

 

Great! A quick fix would be to put the player in 3rd person before playing an animation.

 

Better fix would be to identify the faulty marker and move it to the player beforehand.

 

It could also be that using debug.sendanimationevent instead of playidle is the problem.

I'm not sure what could be really causing it, but third person will work until it can be tracked down. I notice that this problem never occurred before, even when using the same tie-up animation in DoM 3. Not sure where the bug got in, but it should be squashable.

Posted

So I am not sure why, but with the 4.1.0 (no animator replaced.) When indoor, the height of floating is low, like a height of high heel. And higher once outdoor.

The Elder Scrolls V  Skyrim Special Edition Screenshot 2023.01.29 - 23.23.18.28.png

The Elder Scrolls V  Skyrim Special Edition Screenshot 2023.01.29 - 23.31.29.17.png

The Elder Scrolls V  Skyrim Special Edition Screenshot 2023.01.29 - 23.31.29.17.png

Posted
29 minutes ago, ZZW said:

So I am not sure why, but with the 4.1.0 (no animator replaced.) When indoor, the height of floating is low, like a height of high heel. And higher once outdoor.

The Elder Scrolls V  Skyrim Special Edition Screenshot 2023.01.29 - 23.23.18.28.png

The Elder Scrolls V  Skyrim Special Edition Screenshot 2023.01.29 - 23.31.29.17.png

The Elder Scrolls V  Skyrim Special Edition Screenshot 2023.01.29 - 23.31.29.17.png

This is exactly the problem I am having.

Posted

I've been making efforts to try and find the root cause of the issue I have been seeing with the slaves getting stuck in the crouching/sneak posture and stuck unable to move forward and I am just about certain that it is a script loop but it isn't hitting the flag limit that would raise a warning in the monitoring mod.

I did find that when a slave gets stuck I can ready and stow my weapon and each time I do they will be able to move forward for a short distance then get stuck again until they get within a closer range and the glitch will clear for a random length of time. 

I am certain that the player entering combat is the trigger but it is so random to occur that I believe there must be another variable in play.

 

Also I am finding that new slaves are not having their behavior properly set so that they are still aggressive and will enter combat even before told to fight for their master. I have to set them to fight then set them to don't fight so they will lower their hands. but this is only temporary as they will return to an aggressive state after a short time. I have yet to find a possible cause for this. but I am leaning toward it being related with the couching/sneak issue.

 

The odd thing is that it will happen to both DoM and PaHE slaves, but only while DoM is installed.

Posted
5 hours ago, Ghostman7nz said:

I've been making efforts to try and find the root cause of the issue I have been seeing with the slaves getting stuck in the crouching/sneak posture and stuck unable to move forward and I am just about certain that it is a script loop but it isn't hitting the flag limit that would raise a warning in the monitoring mod.

I did find that when a slave gets stuck I can ready and stow my weapon and each time I do they will be able to move forward for a short distance then get stuck again until they get within a closer range and the glitch will clear for a random length of time. 

I am certain that the player entering combat is the trigger but it is so random to occur that I believe there must be another variable in play.

 

Also I am finding that new slaves are not having their behavior properly set so that they are still aggressive and will enter combat even before told to fight for their master. I have to set them to fight then set them to don't fight so they will lower their hands. but this is only temporary as they will return to an aggressive state after a short time. I have yet to find a possible cause for this. but I am leaning toward it being related with the couching/sneak issue.

 

The odd thing is that it will happen to both DoM and PaHE slaves, but only while DoM is installed.

Thanks for the in-depth testing. This is a major problem I'll been working on it as soon as I get some free time. I'm a bit busy with RL right now. So I don't have any other advice then to stick with version 3 and PAHE 8.1.6.

Posted
22 minutes ago, TrollAutokill said:

Thanks for the in-depth testing. This is a major problem I'll been working on it as soon as I get some free time. I'm a bit busy with RL right now. So I don't have any other advice then to stick with version 3 and PAHE 8.1.6.

 

If it helps, I've noticed that slaves that get stuck like this tend to cycle from Angry to Disrespectful and back to Angry again.

Posted
6 hours ago, Ghostman7nz said:

I've been making efforts to try and find the root cause of the issue I have been seeing with the slaves getting stuck in the crouching/sneak posture and stuck unable to move forward and I am just about certain that it is a script loop but it isn't hitting the flag limit that would raise a warning in the monitoring mod.

I did find that when a slave gets stuck I can ready and stow my weapon and each time I do they will be able to move forward for a short distance then get stuck again until they get within a closer range and the glitch will clear for a random length of time. 

I am certain that the player entering combat is the trigger but it is so random to occur that I believe there must be another variable in play.

 

Also I am finding that new slaves are not having their behavior properly set so that they are still aggressive and will enter combat even before told to fight for their master. I have to set them to fight then set them to don't fight so they will lower their hands. but this is only temporary as they will return to an aggressive state after a short time. I have yet to find a possible cause for this. but I am leaning toward it being related with the couching/sneak issue.

 

The odd thing is that it will happen to both DoM and PaHE slaves, but only while DoM is installed.

 

30 minutes ago, DocClox said:

 

If it helps, I've noticed that slaves that get stuck like this tend to cycle from Angry to Disrespectful and back to Angry again.

Main difference betweenPAHE and DoM4 is PAHE slaves have their own combat package allowing them to be combat disabled. I might have to add this package to DoM slaves too.

Posted (edited)

- abduction>" life naked" : produces "slave is already naked" (slave wasn't already naked)

- punish>public/chock : no animation ;  doesn't remove reason

   - wheel>public humilation : animated ; removed reason

- slave covered and cowered, no punishment reason generated

- slave was gagged but produced "is that your best" audio

- I don't see how to pose outside the group wheel, would be nice if added to one of the individual wheels

- pose>dance does not appear to generate dance animation

    - eventually one slave danced, if the slave's registration isn't enough the message should reflect that

- slave roster>occupation should be split into command and activity

     - activity: shows what the slave is actually doing (running away, dancing, following, etc, whatever you call the state)

     - command: shows the last command the slave the was given 

- slave on slave sex causes overlapping dialog text

- tie up>chain/wheel  on running slave, slave was chained/wheeled, but continued to run (which looked pretty silly) 

   - slave never stopped running, "occupation" displayed FOLLOWING

   - "running away" was not repeated, despite continued running

- slave roaster needs : debug stop what you are doing

- slave never got aroused, finally used lust spell to check if blushing just didn't work

   - not sure how long lust spell is suppose to last, but it wore off in less then a minute

- restrained , started whipping , slave escaped and posed submissive

- slaves that maintain a set distance from master for a set period of time should escape (disallowed in MCM)

- come here>loosen up : animation alignment needs work 

Edited by Good Provider
Posted
5 hours ago, Good Provider said:

- abduction>" life naked" : produces "slave is already naked" (slave wasn't already naked)

 

I think that happens when the stripping and redressing scrips are running very slowly. You can tell a slave to strip and she'll accept it, but she's only half way through dressing, so the script runs and finishes applying clothes. But the slave state still says she's naked.

 

Possibly not helped (in my case at least) by bikini armor and SPID, since something seems to be applying a scripted second outfit.

 

5 hours ago, Good Provider said:

- I don't see how to pose outside the group wheel, would be nice if added to one of the individual wheels

 

Try "Entertain Me" from top level dialogue.

 

5 hours ago, Good Provider said:

- slave on slave sex causes overlapping dialog text

 

How do you access that? And can you access MFF scenes? I've not been able to find them in 4.0

 

5 hours ago, Good Provider said:

- tie up>chain/wheel  on running slave, slave was chained/wheeled, but continued to run (which looked pretty silly) 

   - slave never stopped running, "occuptation" was set to FOLLOWING

   - "running away" was not repeated, despite continued running

 

They sometimes do the old scooting around on their knees thing as well. That's an old one from PAHE. I tend to write it off as engine limitations.

 

5 hours ago, Good Provider said:

- slave never got aroursed, finally used lust spell to check if blushing just didn't work

 

I've been struggling with this. They'll get there with repeated sex, but masturbation doesn't seem to do anything any more. Some of that might be SLSO, but I turned that off and it didn't seem to help much. But it wasn't exactly a rigorous test, so I may be getting a bit mixed up on this point.

 

SLSO still seems to report the slave's orgasm as the masters, further complicating things. The slaves don't orgasm at all. (Again, under SLSO).

 

 

Posted (edited)

Well I finally got around to doing a playthrough of DoM 4.x without the Sex/Love Slaves mod and I havent had any issue of DoM slaves losing their name (and I just did a test with yesterday with Sex/Love Slaves with the latest DoM 4.x and it still happened).

 

So its got to be it. So I guess copy and alter the patch from PAH's Fomod for Sex/Love Slaves to work for DoM's system?

Edited by McLovin3
Posted (edited)
4 hours ago, DocClox said:
10 hours ago, Good Provider said:

- tie up>chain/wheel  on running slave, slave was chained/wheeled, but continued to run (which looked pretty silly) 

   - slave never stopped running, "occuptation" was set to FOLLOWING

   - "running away" was not repeated, despite continued running

 

They sometimes do the old scooting around on their knees thing as well. That's an old one from PAHE. I tend to write it off as engine limitations.

 

This could also be caused by applying an animation/idle to the NPC but not applying a package that forces them to stay still (i.e. there is a bug somewhere in the mod where it forgets to apply the package, or a bug where the package is replaced with another one, or the package does not have sufficiently high priority and a package from another mod e.g. a follower framework takes effect instead).

In other words, not an engine limitation, just a bad combination: The NPC is still using a package that makes them walk or run, but the currently applied animation is a kneeling animation, causing the visual effect of the NPC sliding around on the ground.

Edited by Kharos
typo
Posted
59 minutes ago, Kharos said:

This could also be caused by applying an animation/idle to the NPC but not applying a package that forces them to stay still (i.e. there is a bug somewhere in the mod where it forgets to apply the package, or a bug where the package is replaced with another one, or the package does not have sufficiently high priority and a package from another mod e.g. a follower framework takes effect instead).

 

It could be a question of package priorities, certainly.

Posted
18 hours ago, TrollAutokill said:

Thanks for the in-depth testing. This is a major problem I'll been working on it as soon as I get some free time. I'm a bit busy with RL right now. So I don't have any other advice then to stick with version 3 and PAHE 8.1.6.

Oh I have my "normal" game with DoM3 working well. I was Testing DoM4 to help knock out all as many of the bugs as possible. I truely like the mod and want to see it polished and working smoothly. Anyway I'll just go back to playing my game and wait for the working release

Posted

Use 4.1.0
Issue with non-combat slaves getting stuck in crouching when entering combat

Taking loyalty idols too often + sometimes they don't release until they get close to the slave

I have not been able to playtest properly because of this problem... I keep avoiding enemies to avoid entering combat and rushing at slaves to unlock their loyalty idols...

Bug?
Sometimes taking clothes from a slave's inventory causes them to multiply, sometimes they don't, so the conditions are unknown.

The group command Wait is working, but the message on the left side of the screen does not seem to be displayed

Posted (edited)
14 hours ago, DocClox said:

How do you access that? And can you access MFF scenes? I've not been able to find them in 4.0

 

DOM doesn't support it. I use:

Pet Collar causes aroused allied NPCs, optionally your creatures, to use your collared slaves (optionally orgies)

Shadownman's sexparty allows you to ask your slaves to join in an orgy, only between consenting NPCs/player

SexLab tools allows you to force sex between NPCs, creatures, and the player via spell 

 

Pet Collar is nice, since it create spontaneous NPC interactions. It can get out of hand, at some point I had about 7 different slaves all going at it in different combinations and I needed to get some dungeon crawling done.  This is largely solved via SexLab Tools which will allow you to take over a sex animation, change the animation it is running, and speed the process through the stages.  While both Pet and Tools sex is captured by DOM as sex, neither can be refused so should be counted towards rape, which they are not. Sexparty is consensual so it makes sense that it would be recorded as just sex.

 

One possible solution would be if DOM checked the animation at or near the end, since I often change the animation with SexTools after it has started, then if an aggressive animation was used count it as sex for the First.Actor and sex/rape for the Second.Actor. Additional it should use the animations'  orifices to see which are trained (many animations include multiple). This would then cover both tools and pet collar animations, provided I set or selected aggressive animations. This would also reduce the need to add (vaginal,oral,anal) to punishment>reason>rape, since SexLab Tools would allow me to change it after it has begun to what I want to train.

 

At some far future point, direct support would be great, but the mountain of possible features is ever growing, and the above three tools are pretty functional as is. 

 

Edited by Good Provider
Posted (edited)

The covering self reason adds a "being punished" segment to the punsh wheel, but it's non-responsive. You can punish from dialogue, but not the wheel.

 

1 hour ago, Good Provider said:

Pet Collar causes aroused allied NPCs, optionally your creatures, to use your collared slaves (optionally orgies)

 

Ah, yes. I've used that one in the past. Might have to dig it out again.

Edited by DocClox
Posted (edited)

I think the thing which messes up the "follow command may be manually equipping them with gags and/or rope bindings. I had this khajiit that I wanted to wear that muzzle gag and follow with hands behind her back, but once I equippedthose items she stopped following and removing them didn't fix things.

 

[edit]

 

Not to worry - found something for her to do!

 

enb2023_1_30_21_30_38.png

Edited by DocClox

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
×
×
  • Create New...