[AAF] Bound In Public (8/31/2023)

[sen4mi]

11 hours ago, izzyknows said:

Did you take into account the energy used and when it regained enough to struggle again? If you struggle every time you'll run out of energy and have to suffer through a couple scenes to regain enough to try again.

 

I had 0 energy and 78-ish willpower after my first three struggles. If 1 willpower represents 10 energy, I should have effectively had well over 700 energy.

 

I went through a couple raider scenarios and a couple settler scenarios before I decided that I did not have the patience to try any further.

[sen4mi]

5 hours ago, rubber_duck said:

My biggest annoyance is with dialogues - I don't mind them, but they are pretty long. It wouldn't be an annoyance if they were skippable, but they're not. It's fun the first time, but it feels like every time a new NPC duo has their own introduction and a little chat. Is there a chance to make the dialogues skippable? I'm using F4Z RO D-OH.

 

I think it would make sense to have a full dialogue on the first scenario and bridge dialogues on later scenarios (or else it would make sense to have the PC recover somewhat between scenarios, but that gets into survival/advanced needs issues).

[IBAGadget]

I think I'm going to skip upgrading to the newest version for now - with four companions, only two of which can be dismissed via dialogue, I'd rather not risk breaking things and torching my game.

 

Granted, as it is a Bethesda game, I save often, but still......

[valcon767]

@twistedtrebla @IBAGadget

 

usage report for 1.2.4 

 

had 3 followers during testing

used MCM to start, wound up at the Fens location

Hancock - was dismissed to Sanctuary, able to recruit as usual afterwards

Ivy - dismissed to Sanctuary (standard dismiss dialogue), able to recruit as normal more or less

        fast travel to Sanctuary and she was there, if i used her teleport item she came to me, or if i fast traveled to somewhere else she showed up after a couple minutes.

Ack-Ack (enslaved through Just Business so was a slave follower) - was not affected at all (she was totally ignored), but did sit on the "missing" chair at the Fens location.

               not a big deal as a slave would not care, and might actually enjoy watching the person who enslaved them get abused anyway.  

 

scenes, and struggle, and gaze mechanics worked properly as far as i could tell.

 

2 issues

 

1 - camera issue = in 1st person mode was normal, but switching to 3rd person mode camera was oddly placed (right on ground) and i could not see my character

     despite moving it as much as it would let me.  if i used TFC (free camera) my character was invisible.  this happened when AAF was not running a scene,

     initial placement, between scenes, and after struggling free.  camera worked fine during AAF scenes.  normal free camera movement and scene was fully

     visible - NPCs and character.

 

edit 2 

camera issue not present in version 1.1.1

camera issue present in 1.2.0, 1.2.3, and 1.2.4

camera issue not present at all if already in 3rd person camera mode for all versions.

possible fix would be for the mod to switch camera modes before it moves the character (don't know how hard that would be to do or if you want to).

end edit 2

 

2 - stuck character =  after struggling free character was stuck in place.  i could look around a bit (not turn a full circle) in 1st person mode, but the camera was oddly 

      placed in 3rd person mode (see issue 1), could not draw weapon, could not move, HUD was missing, and could not talk to Ack-Ack when she passed right in front

      of me.  however after fast traveling elsewhere all controls were normal again and camera issue was gone.

edidt

was able to access Pip-Boy and equip items in it and fast travel

end edit

 

 

i do use Enhanced 3rd Person Camera mod.  this probably is why i had camera issue, but figured to report what i saw/discovered.

 

thanks for the mod, it is very good work.

Edited April 18, 2023 by valcon767

[Waity6taity]

I have a suggestion to exclude locations around institute blast site after we blow it up, because radiaton levels are so high that character cant even live until the first encounter

[izzyknows]

@twistedtrebla
The hood needs to be added to the AAF protected equipment I'm guessing. It gets stripped during each scene, it also isn't removed upon quest end.

I can also verify that being in 1st person will lock the player in place when being released. At least with the hydro pillory.. so far. And like @valcon767 has stated, you have full access to the Pip-Boy & fast travel clears the issue.

 

Followers: Commonwealth Captives are ignored during the dismissal stage.

[Slorm]

Bug Report - Possibly Major

 

The debug options are not working again after the first use.

 

For background, I am manually using debug to start the quest after Violate has finished with me. The first time worked perfectly. Just had another run in with some raiders and lost and after Violate had finished tried to start the quest and nothing happens. Tried abort a number of times and it still wouldn't start. Went back to a save before the second Violate and again it wouldn't start.

 

I've attached a log in case it's of some help

 

 

Papyrus.0.log

 

EDIT:

 

Only workaround (rather stinky) seems to be to uninstall BiP load and make a new save and then reinstall. It works but I'm not sure how safe it is or if it might corrupt the save

Edited April 18, 2023 by Slorm

[KalBreen]

Personally, I'm not a fan of fast travel, so having the option to not dismiss companions would be good.

[izzyknows]

19 minutes ago, KalBreen said:

Personally, I'm not a fan of fast travel, so having the option to not dismiss companions would be good.

Just have them locked in/on whatever device and either watch or be abused along with the PC. That would be a perfect continuation of Violate.

[vaultbait]

8 minutes ago, KalBreen said:

Personally, I'm not a fan of fast travel, so having the option to not dismiss companions would be good.

 

Out of curiosity (person in the street straw poll), how do you feel about equipment removal from followers? I'm working on a new captive scenario mod, and the current design sends your companions along to the captive location with you but strips them and puts all their equipment in a container (along with yours) for safekeeping. Is that alternative also problematic?

[izzyknows]

2 minutes ago, vaultbait said:

Out of curiosity (person in the street straw poll), how do you feel about equipment removal from followers?

Make it an MCM option.  Hoard or Destroy.

Keeping the items a container is a good option for hoarders.

Destroying them is for those that want a little bit more "plausible" route.

[vaultbait]

3 minutes ago, izzyknows said:

Make it an MCM option.  Hoard or Destroy.

Keeping the items a container is a good option for hoarders.

Destroying them is for those that want a little bit more "plausible" route.

 

For convenience, the teleport trap activator which starts the captive scenario masquerades as a conspicuously tempting loot container, so it seemed only natural to have it swapped for an identical-looking actual container with all the player's original belongings (as well as those of any companions transported with them) stored inside. They still have to cross about half of the map and return to that location (near the vault 111 entrance) to reclaim them. Since it's mainly intended as an alt-start scenario to explain and kick off some of the new gameplay mechanics, most players won't have much on them or any companions anyway, I just wanted to cut down on complaints. ?

[twistedtrebla]

5 hours ago, Slorm said:

Bug Report - Possibly Major

 

The debug options are not working again after the first use.

 

For background, I am manually using debug to start the quest after Violate has finished with me. The first time worked perfectly. Just had another run in with some raiders and lost and after Violate had finished tried to start the quest and nothing happens. Tried abort a number of times and it still wouldn't start. Went back to a save before the second Violate and again it wouldn't start.

 

I've attached a log in case it's of some help

 

 

Papyrus.0.log 12.19 kB · 1 download

 

EDIT:

 

Only workaround (rather stinky) seems to be to uninstall BiP load and make a new save and then reinstall. It works but I'm not sure how safe it is or if it might corrupt the save

 

No idea why thats happening to you. Logs don't show anything. Could be script lag. How many script intensive mods do you have installed?

 

For my next version I'll add some logging so if it happens again theres more info.

[valcon767]

9 hours ago, vaultbait said:

 

Out of curiosity (person in the street straw poll), how do you feel about equipment removal from followers?

the MCM option mentioned by izzyknows is a good idea if it is not to much trouble.

generally speaking i have no problem with stripping follower and player, providing quest items don't get stripped (depending on the individual

quest item it can break quests).  also be aware vanilla fallout mechanics may put some items back into follower inventory.

last game i tried an experiment with Ivy, sometimes (and no i did not figure out the trigger) the game would have her dressed in her default items again. the items i gave her (that she was wearing) would end up in inventory and she would be wearing her Synth Dress again, even though i had removed it from her inventory (yes i wound up with 13 copies of her dress sitting in a chest).

[NotKinkyEnough]

The main problem(s) I've seen with a lot of aspects of defeat and capture mods - 

there are quests which ought to formally lock the player in to a location, but at the time they were written the author had no idea another mod would violate the existing protections. We would benefit from some effort to identify these quests or stages, vanilla and addons for mods, which adds a flag or one of a series of control flags. Like "prevent exit", "prevent additional NPC spawns", "limit npcs spawns to one type or list", (for when the location is sealed and nothing should get in from outside), "prevent companion departure", "prevent companion access", for when companions are trapped too or should not be allowed to join remotely. 

 

Then we could check for "prevent exit" flags to stop being removed from a locked quest area, stop inappropriate npcs from intruding into areas it does not make sense.

 

Items need a flag like "Meta-Item", where the item slot is being used to affect gameplay but it it not really an "item" and should genuinely not be removed other than by its own script. In cases where we have an item which hypothetically could be removed but doing so would break a quest, that quest author would be responsible for deciding whether to treat the item as a Meta-Item , which could be a lazy way if it would be more interesting to allow other ways to resolve the quest, in addon mods... or whether to listen for removal and handle it even with a "are you sure you want to remove this? It will end this situation and erminate the quest." dialog which allows "Yes, remove it" or "No, put it back on" as options.

 

 

Thing is this would be quite a big effort, but useful to a lot of mods, giving information to help make loads of things run smooth.

[Slorm]

18 hours ago, twistedtrebla said:

 

No idea why thats happening to you. Logs don't show anything. Could be script lag. How many script intensive mods do you have installed?

 

For my next version I'll add some logging so if it happens again theres more info.

 

I was wondering about scripts lag, I would imagine SH and SA are continuously running as well as PVPK. I have most of Ego's mods running (such as Violate and Commonwealth Captives) but the majority of my mods are animations (per the AAF Fucking Guide) and clothing outfits with adjusted slots (which have no scripts). There's also Hardship but that's usually switched off.

 

I did play around with it a bit further and found that spamming the Start button would sometimes work to get it going. From memory, if the routine starts and I abort then it usually will start normally again (I'll need to recheck as that was on an old version).

 

I see that PVPK has added BiP support so I'll see if it affects the in-game routine or just the Debug

 

What is odd is that it always works perfectly the first time, it's only subsequent attempts that cause a problem.

 

Is it safe to remove, save and reinstall or is that likely to cause further problems. Although a kludgy fix it it will always start that way.

 

EDIT 1:

 

I'm making some diagnostic progress. I cleaned a save, used debug to start and after getting the first screen message aborted which worked perfectly. Started and aborted again and then a third time which worked 100% so I'm guessing atm it's some sort issue with it not ending correctly and causing a queuing problem or not closing the quest cleanly. I'll test further letting it play out and then again but aborting near the end.

 

At least it's a fun mod to test

 

EDIT 2:

 

Some real progress though it's thrown up some issues.

 

1/ After using the clean save the debug start and abort work flawlessly together, so that issue looks like some residual crap from previous versions. That's the good news

 

2/ I then went on to test both PVPK Easy Prey (which calls BiP) as well as SH Fan bad drink and both displayed some similar problems. One the first activation they work perfectly but on the second they both fail the PVPK teleport just leaves the pc in place and with SH the BiP quest does not appear to start. However in both cases the quest has started (as you get the message saying it has if you use debug start) interestingly if you hit abort the pc is transported and appears on the Torture Furniture but nothing more happens so the pc is stuck.

 

If you then use debug to start the quest it does, and the quest works normally with no problems.

 

It's teatime now but afterwards I'll pull a much old game off the backup drive which has never had BiP and double check

 

EDIT 3:

 

Sorry for the magnum opus but here's the last part of my testing

 

Testing was done a save dating 23/03/2023 before BiP was published.

 

As before debug start/abort routine worked perfectly just by themselves

 

Results were the same as the cleaned game, though I only tested using @spicydoritos PVPK Easy Prey but based on the previous results SH will behave the same.

 

As before the routine works perfectly first time, on second drink there's a fade out/in but the pc is in the same location. If you go to BiP debug and click Start it reports the quest is already running, clicking Abort then transports the pc into a Torture device but nothing further happens (no doubt as the quest has aborted). Then going to BiP debug click Start the pc is transported to a new location and the BiP quest plays out perfectly.

 

I've attached a log of the complete process, not sure if it'll help any

 

It would be helpful if someone else repeated these steps to ensure that it is not something in my setup

 

Papyrus.0.log

Edited April 19, 2023 by Slorm

[vaultbait]

7 hours ago, NotKinkyEnough said:

The main problem(s) I've seen with a lot of aspects of defeat and capture mods - 

there are quests which ought to formally lock the player in to a location, but at the time they were written the author had no idea another mod would violate the existing protections. We would benefit from some effort to identify these quests or stages, vanilla and addons for mods, which adds a flag or one of a series of control flags. Like "prevent exit", "prevent additional NPC spawns", "limit npcs spawns to one type or list", (for when the location is sealed and nothing should get in from outside), "prevent companion departure", "prevent companion access", for when companions are trapped too or should not be allowed to join remotely. 

 

Then we could check for "prevent exit" flags to stop being removed from a locked quest area, stop inappropriate npcs from intruding into areas it does not make sense.

 

Items need a flag like "Meta-Item", where the item slot is being used to affect gameplay but it it not really an "item" and should genuinely not be removed other than by its own script. In cases where we have an item which hypothetically could be removed but doing so would break a quest, that quest author would be responsible for deciding whether to treat the item as a Meta-Item , which could be a lazy way if it would be more interesting to allow other ways to resolve the quest, in addon mods... or whether to listen for removal and handle it even with a "are you sure you want to remove this? It will end this situation and erminate the quest." dialog which allows "Yes, remove it" or "No, put it back on" as options.

 

 

Thing is this would be quite a big effort, but useful to a lot of mods, giving information to help make loads of things run smooth.

 

SAKR added a control keyword which mods can attach to their worn quest items signalling to other mods that they shouldn't be stripped.

[valcon767]

7 hours ago, vaultbait said:

 

SAKR added a control keyword which mods can attach to their worn quest items signalling to other mods that they shouldn't be stripped.

oh dang i knew i was missing a mod i meant to put in this game but missed.  it will have to wait for next new game as i don't want to mess up a mod

that is currently running for me (BDH to be exact) and it would have to load before that one (as i use MO2 i will load it but not activate it in either pane).

 

thanks for the reminder.

 

[spicydoritos]

8 hours ago, Slorm said:

 

I was wondering about scripts lag, I would imagine SH and SA are continuously running as well as PVPK. I have most of Ego's mods running (such as Violate and Commonwealth Captives) but the majority of my mods are animations (per the AAF Fucking Guide) and clothing outfits with adjusted slots (which have no scripts). There's also Hardship but that's usually switched off.

 

I did play around with it a bit further and found that spamming the Start button would sometimes work to get it going. From memory, if the routine starts and I abort then it usually will start normally again (I'll need to recheck as that was on an old version).

 

I see that PVPK has added BiP support so I'll see if it affects the in-game routine or just the Debug

 

What is odd is that it always works perfectly the first time, it's only subsequent attempts that cause a problem.

 

Is it safe to remove, save and reinstall or is that likely to cause further problems. Although a kludgy fix it it will always start that way.

 

EDIT 1:

 

I'm making some diagnostic progress. I cleaned a save, used debug to start and after getting the first screen message aborted which worked perfectly. Started and aborted again and then a third time which worked 100% so I'm guessing atm it's some sort issue with it not ending correctly and causing a queuing problem or not closing the quest cleanly. I'll test further letting it play out and then again but aborting near the end.

 

At least it's a fun mod to test

 

EDIT 2:

 

Some real progress though it's thrown up some issues.

 

1/ After using the clean save the debug start and abort work flawlessly together, so that issue looks like some residual crap from previous versions. That's the good news

 

2/ I then went on to test both PVPK Easy Prey (which calls BiP) as well as SH Fan bad drink and both displayed some similar problems. One the first activation they work perfectly but on the second they both fail the PVPK teleport just leaves the pc in place and with SH the BiP quest does not appear to start. However in both cases the quest has started (as you get the message saying it has if you use debug start) interestingly if you hit abort the pc is transported and appears on the Torture Furniture but nothing more happens so the pc is stuck.

 

If you then use debug to start the quest it does, and the quest works normally with no problems.

 

It's teatime now but afterwards I'll pull a much old game off the backup drive which has never had BiP and double check

 

EDIT 3:

 

Sorry for the magnum opus but here's the last part of my testing

 

Testing was done a save dating 23/03/2023 before BiP was published.

 

As before debug start/abort routine worked perfectly just by themselves

 

Results were the same as the cleaned game, though I only tested using @spicydoritos PVPK Easy Prey but based on the previous results SH will behave the same.

 

As before the routine works perfectly first time, on second drink there's a fade out/in but the pc is in the same location. If you go to BiP debug and click Start it reports the quest is already running, clicking Abort then transports the pc into a Torture device but nothing further happens (no doubt as the quest has aborted). Then going to BiP debug click Start the pc is transported to a new location and the BiP quest plays out perfectly.

 

I've attached a log of the complete process, not sure if it'll help any

 

It would be helpful if someone else repeated these steps to ensure that it is not something in my setup

 

Papyrus.0.log 47.54 kB · 0 downloads

 

This all reads like the main quest is being stopped by that debug command, but not by the regular scenario cleanup.  And in fact I cannot find another instance of "BIP_BoundQuest.stop()" outside of those debug commands.  Perhaps that's deliberate.  However, I also found this orphan stop() command in the setPlayerFree function.  Maybe that was intended to stop the main quest?

 

Spoiler

 

[twistedtrebla]

I found an infinite loop in the "stopAllScenarios()" function. Which.. probably screws things up big time. lol. Let me try to fix it.

 

Im surprised some things even worked at all with this bug. Weird

Edited April 19, 2023 by twistedtrebla

[twistedtrebla]

v1.2.5

• Fixed infinite loop bug that could cause the quest to not stop & start correctly. All previous versions are considered unstable
• Changed diamond city spawn location from near the sewer to the statue in front of the gate, for better traffic
• Rag hood no longer gets unequipped during AAF animation

[jbezorg]

On 4/18/2023 at 7:24 PM, vaultbait said:

 

For convenience, the teleport trap activator which starts the captive scenario masquerades as a conspicuously tempting loot container, so it seemed only natural to have it swapped for an identical-looking actual container with all the player's original belongings (as well as those of any companions transported with them) stored inside. They still have to cross about half of the map and return to that location (near the vault 111 entrance) to reclaim them. Since it's mainly intended as an alt-start scenario to explain and kick off some of the new gameplay mechanics, most players won't have much on them or any companions anyway, I just wanted to cut down on complaints. ?

 

Guess it's not compatible with Start-me-up.

It could work with settlement containers excluding the workbench. If one of the settlers begins to hate the player, via SH perhaps, then the player is knocked out and the settler disappears with the loot and joins some riders. Settler end up dead or in a cage à la Hitting the Books.

Edited April 20, 2023 by jbezorg

[Dlinny_Lag]

hi @twistedtrebla

Could you add dedicated keywords for your armor pieces to have a chance to differentiate equipment by keyword?

[Oldwolf58]

10 hours ago, twistedtrebla said:

v1.2.5

• Fixed infinite loop bug that could cause the quest to not stop & start correctly. All previous versions are considered unstable
• Changed diamond city spawn location from near the sewer to the statue in front of the gate, for better traffic
• Rag hood no longer gets unequipped during AAF animation

Works good except 2 things. Was put in stocks at Polymer labs and the stocks moved toward the street after each sex encounter until my character and the stocks were in the middle of the street about 3 feet off the ground, the second problem is that what ever sandbox or wander idle the molesters have seems to keep starting during the sex act making them try to walk away so that you have to pull up the aaf menu and page up/down to get them back to sex then setangle z to match your character to get them back aligned correctly. Maybe look into them having a standing in place idle facing the device while they have their discussion then they could be seen to watch each other having sex when there is more than one molester.

[Slorm]

13 hours ago, twistedtrebla said:

v1.2.5

• Fixed infinite loop bug that could cause the quest to not stop & start correctly. All previous versions are considered unstable
• Changed diamond city spawn location from near the sewer to the statue in front of the gate, for better traffic
• Rag hood no longer gets unequipped during AAF animation

 

@twistedtrebla@spicydoritos

 

I just ran through another cycle of testing using the old game before BiP was published

 

Test 1 - Debug. Tested 4 times sequentially

 

start/abort, start/struggle, start/Samaritan, start/abort

 

Everything worked correctly

 

Test 2 - PVPK Easy Prey. Tested 4 times sequentially

 

booze/sex/BiP/abort, booze/sex/struggle, booze/sex/Samaritan, booze/sex/abort

 

Everything worked correctly

 

I haven't tested SH bad fan drink as it's awkward to test but as it displayed the same behaviour as PVPK in earlier tests, I can think of no reason why the fixes wouldn't work for that as well

 

On a side note 10 pints of "Bobrov's Best" keeps the bowels regular