dkatryl

Since I'm blowing everything else up anyways, I'm gonna be nice to everyone that is afraid to donate to the Hungry Bandit Funds when they lose. I'm going to change the single toggle to a slider with a few levels: Doesn't steal any gear. Caps the amount of gold stolen to 100 + Lvl^2 (The original Bounty turn in reward! So at level 25, it would cap the amount to 725g) Doesn't steal any gear. No cap on gold, so they will take all that is currently on the Player (And followers, if applicable) Steals all gear and gold. I'm not going to make it so *nothing* is stolen, because that's just silly. Besides, you can always just kill the bastard and get your gear/gold back!

1.1.5c - (08OCT26) Updated Russian translation for MCM/Strings provided by BF3000.

The scenario you are asking about has no bearing on the Follower limitations. Right now, it will cycle through all available enemies, and do 3-ways back to back, until everyone has gone and has the 'Sated' Faction applied. So in that regard, gangbang already exists. There is a gameplay sample video on the main page that has the Player surrounded by 6 Bandits, and they run a train of 3x 3-ways on my poor test character. If by gangbang, you mean exclusively 4 or 5 Actor scenes, those have been capped to 3-ways by default because I didn't want to get bogged down with feedback that scenes never played because they didn't have animations to support them installed, etc, because it's not like I'm doing "valid animations exist" checks before setting up the scene. Since that potential problem would still exist, and is independent of the Follower support I'm talking about, I'm not sure on the 4 or 5 scenes. I could see adding an MCM slider option that lets the player determine how many possible Actors are in a scene (2-5), and then leave it up to them to limit the group size to whatever their installed animations can support. However, there is something I will need to address for when it's more than just the Player to consider, because the problem is compounded once you add in Followers. Player vs 4 NPC? okay, pretty straight forward. You could theoretically let em all go wild in a 5-way scene and call it a day. Player, 2 Followers, 4 NPCs? Well, that gets a bit trickier. Can't just have all 5 go on the Player now, so I guess 2 for the Player, 1 for Follower #1, 1 for Follower #2. Player, 3 Followers, 4 NPCs? Same as before, but now 1 for the Player, 1 for Follower #1, 1 for Follower #2, 1 for Follower #3. Player, 4 Followers, 4 NPCs? Well, now we got more Player+Teammate than NPCs! Do I just have some repeat themselves? Ignore leftover Followers? Parsing out the available enemy NPCs between the Player and varying quantities of Followers is technical hurdle that I know I will need to solve, but that will be after I rewrite all of the underlying Functions to facilitate the scenes independently of the Player vs Follower triggering them.

Well, some potentially exciting news, I think I figured out how to conquer my modding nerd white whale for Submit, which was multiple follower support. Currently, all of the sex scenes, no matter if they are consensual or non-con, Player as Victor or Victim, etc, they all make use of Hooks, specifically the AnimationEnd version. As such, the make use of Events, and passing the Actors[] from the scene forward has always been a challenge, forcing me to make heavy use of Aliases, populating them within the scene, then redefining Victor/Victim/etc on the backend functions to handle the post scene stuff. But Aliases had one very limiting factors, which was that given each one could only hold 1 actor at a time, if I wanted to support mods that allow for multiple followers, I would need to create more than the single Follower Alias. And even more than that, since the *Player* was the one that initiated all of the scenes, again because of how the Hooks were set up, every scene had to have an overly complex check for how many actors were in it, and if there was a follower or not. For instance, here's the 'basic' one for the Player as Victim: First part is checking >= 2 hostile NPC + Player + Follower? Then split them off into pairs. Second part is >= 2 hostile NPC + Player + No Follower? Then 3-way on Player Third part is 1 hostile NPC + Player? 2-way. I just needed to be able to decouple the Player from the Followers and get rid of the need for Aliases to pass the Actors on after the scene ends. Which meant getting away from using Hooks and the post scene Events, instead making those into Functions. So I had a thought last night, and realized, all I needed to do was build in the functionality of the HookAnimationEnd within the main function that calls for everything. Like this: _SLSexScene.RapePlayer(activeActors) SexlabThread Thread = SexLab.GetThreadByActor(Victim) Int i2 = 0 While (i2 <= 10) && (Thread != None && Thread.GetState() != "Animating") WRT(1.0) i2 += 1 EndWhile WRT(0.1) While (Thread != None && Thread.GetState() == "Animating") WRT(0.1) EndWhile PostPlayerRapeTest(Victim,Victor) And, it did exactly what I was hoping for. In game, I couldn't even tell that the old Hook wasn't actually there, other than that last line currently has a debug.notification line to confirm *that* is the one that is firing. What this means is many fold: I no longer have to initiate everything directly from the Player, either as Victor or Victim. So now, after the Player runs their own script, instead of it having to have contingencies for a possible Follower, I can just let each Follower run their own script, just staggered by a second or two so that the available NPCs get claimed from the pool before the next one fires and tries to claim the same one. In the event that an animation doesn't play, previously, the Hook is what defined and fired the Event that would play on AnimationEnd. However, if the animation never played... the Event didn't either, resulting in well, typically nothing. So now, even if the animation doesn't play for whatever reason, after ~10sec, it should move on to whatever the post scene Function should be. This *ALSO* means I will be able to make more robust options for when scenes happen, including if only male or female Players/Followers are Victors or Victims. Anyways, this will be a bit of an undertaking, as I have to deconstruct a *LOT* of Functions and such within a handful of scripts, get it to work, and then test the hell out of everything. So don't expect this in a week or two! But hopefully before 2027! lol TL:DR Multi-Follower Support is in Development

Thanks! I'll update shortly.

1.1.5b - (06OCT26) Updated German translation for MCM/Strings provided by CGi.

It's been like that for over a decade. But if you wanted to change it yourself, open up _SLSubmitScene.psc: Function PlayerRob() Int i = 0 While (i <= 2) && !PlayerRef.IsInCombat() && !ActorBully.GetActorRef().IsDead() If i == 0 Gold = PlayerRef.GetGoldAmount() If (!_SLQuest.IsNonHumanoid(ActorBully.GetActorRef())) Actor Robber = ActorBully.GetActorRef() Robber.MoveTo(PlayerRef, 60.0 * Math.Sin(PlayerRef.GetAngleZ()), 60.0 * Math.Cos(PlayerRef.GetAngleZ())) float zOffsetRob = Robber.GetHeadingAngle(PlayerRef) Robber.SetAngle(Robber.GetAngleX(), Robber.GetAngleY(), Robber.GetAngleZ() + zOffsetRob) WRT(1.0) PlayerRef.RemoveItem(Gold001, Gold, false, ActorBully.GetActorRef()) EndIf ElseIf i == 1 If (_SLConfig.StealActive && !_SLQuest.IsNonHumanoid(ActorBully.GetActorRef())) PlayerRef.RemoveAllItems(ActorBully.GetActorRef(),false,false) EndIf ElseIf i == 2 If (!_SLQuest.IsNonHumanoid(ActorBully.GetActorRef())) If (_SLConfig.StealActive) If (_SLConfig.debugActive) _SLSubmitScene15.Show() WRT(0.1) EndIf Else If (_SLConfig.debugActive) _SLSubmitScene14.Show() WRT(0.1) EndIf EndIf EndIf EndIf i += 1 EndWhile EndFunction Take the line: PlayerRef.RemoveItem(Gold001, Gold, false, ActorBully.GetActorRef()) and either delete it if you never want to have your gold stolen (It will be on the NPC that robbed you), or just move it into the If check to see if the MCM StealActive option is on: If (_SLConfig.StealActive && !_SLQuest.IsNonHumanoid(ActorBully.GetActorRef())) PlayerRef.RemoveAllItems(ActorBully.GetActorRef(),false,false) EndIf Compile, and done.

v1.1.5a - (05OCT26) Fixed - NPC Bounty Wristcuffs should no longer interfere with animations for various interactions. Fixed - In the process of testing all of the functions, discovered BeastSex() in SLP+ version had references to Futa, which are invalid for Creatures. Corrected to Male. Updated Chinese translation for MCM/Strings provided by zhenmika.

Awesome. I'll include both when I update later tonight to fix the wristcuff issue.

Good news, I think I took care of all of the various "NPC Bounty with wrists tied up" scenarios that were interfering with the various functions (Dialog initiated sex, Ambush sex, Subdue/Shout/NPC auto, etc) that I discovered while playing earlier today. Bad news, I ran out of time to get things localized and ready for updating. So it will be tomorrow at the earliest.

Given I have no idea what that is, probably not? lol After a quick google search, assuming it's this, or similar: Then no, definitely not. I added the Bounty system as a quick little means to get some starting gold and do something besides just outright killing them when you were done. That said, if someone wanted to, then I expect they could go add that to the .ESM/ESP dependencies, and then add another dialog option to the Bounty turn in to go sell them off:

Thanks! Dunno if you saw, but the MCM has also been updated, with several lines fully removed, but one line in particular reworded and moved to the end of an existing entry. If you want to update that, I'll add it to the Strings. (Either way, I will probably wait and include those in the upcoming 1.5.1 fix to the Bounty Wrist interference. SexLab Submit SE_CHINESE.TXT

I have never used Defeat, so this is my understanding from what other users have said: There are a lot of similarities in concept (Player as Victim and Player as Victor), but differences in execution. While there is no outright conflict of files being overwritten, there is redundancy in function, so it is best to turn off whichever feature of mod A and let mod B handle that, and mix and match to your taste. But yes, other users would have to go into more detail on the differences. I believe there was some comparisons made earlier in this thread. Currently, only 1 follower will be triggered as well if you are using a follower mod that allows more than 1. (When this was originally made for LE 12+ years ago, there weren't as many follower mods, so I only did things with 1 follower in mind.) I have held off updating that for a few reasons: Would have to completely rewrite all of the Player as Victim ActorAssign functions in multiple scripts to make sure they get properly paired off. What do you do with extreme cases where, with mods, you have more followers than you have available bandits? lol I don't even use the Player as Victim half of the mod, as I play a male character. This would be another significant time investment of my free time for something I don't use. *IF* I did invest the time, however, the obvious benefit is then there would be no limit to how many followers would be supported. Each one would trigger their own scene so long as there are available NPCs to draw from. I will admit, the nerd in me is intrigued by the challenge of doing it. But the gamer in me is also saying "SHUT UP NERD!". So no promises.

Noticed if you want to take another turn with an active Bounty NPC, the wrist binds interfere with the animations. Will post a fix for that soon.

Do you mean for Player as Victor, and you are going to turn in the NPC for a Bounty? At the moment, they get Prisoner Rags & Prisoner Cuffs, basically what you are wearing during the standard prisoner cart opening. For the Player as Victim, I know currently it is: Function ZazPack() int Mods = Game.GetModCount() int i While i < Mods string Modname = Game.GetModName(i) If !ZazPack && Modname == "ZaZAnimationPack.esm" ZazPack = True EndIf i += 1 EndWhile EndFunction To define if reference even exists, then when the player is bound, at the end, it has: If (_SLQuest.ZazPack) Debug.SendAnimationEvent(Target, "ZaZAPCAO055") If (ActorFollower.GetActorRef() != none) Debug.SendAnimationEvent(ActorFollower.GetActorRef(), "ZaZAPCAO055") EndIf EndIf So you could basically take a page out of this and add in DD mod checks to prove they are valid and exist, then modify the _slsubmitbountystart script to have them use that instead of the Prisoner Rags, etc. I don't know if *I* will do that, because I don't use DD, so I'm not familiar with what it has. And then that's also a slippery slope to "Hey, add X, Y, Z mod support!" and at this point, I'm not looking for *more* reasons to keep working on this indefinitely.