OStim Defeat Bridge - Lightweight Human & Creature Defeat Scenes

[cashboxs]

7 hours ago, erza20 said:

Is female aggressor/male victim planned in future? Also I was wondering if it can hook into acheron defeat state (so I can run this for followers and acheron for PC so I can use the integrated outcomes). 

In the current version, you can uncheck human events so Acheron handles human events and DB handles creature events.

[chrystelle]

For modders who want to create outcome scenarios, could you create an additional event hook just before the start of the ostim thread?  For instance, to have the player consume an item or something like that?  This would require determining before the thread starts what outcome it would be assigned to, I imagine.

[chrystelle]

Update:

I read through the quest script, and it seems like I could do what I'm looking to try by hooking into the ostim_thread_start event and checking first to see if the Ostim threadId is 0 (player-reserved thread) and then then checking this prop:

GlobalVariable Property TMS_DBEventRunningGV Auto

to see if the currently running thread is a defeat/surrender thread.  Does that logic track to you?  I'm going to try it out.

Side note: Could you post the source to GitHub?  It's difficult to recommend to people to download a closed-source dll that they can't build themselves from source and compare, for security reasons.

Edited August 13 by chrystelle

[cashboxs]

2 hours ago, chrystelle said:

Update:

I read through the quest script, and it seems like I could do what I'm looking to try by hooking into the ostim_thread_start event and checking first to see if the Ostim threadId is 0 (player-reserved thread) and then then checking this prop:

GlobalVariable Property TMS_DBEventRunningGV Auto

to see if the currently running thread is a defeat/surrender thread.  Does that logic track to you?  I'm going to try it out.

Side note: Could you post the source to GitHub?  It's difficult to recommend to people to download a closed-source dll that they can't build themselves from source and compare, for security reasons.

First of all, I really appreciate the work you've done with Ocreature. DefeatBridge relies on Ocreature for its creature scene support, so your work is genuinely important to what DB can do on that side. I also appreciate you taking the time to read through the quest script and think about integration from the technical side.

 

If you're listening for ostim_thread_start, checking that it's the player reserved thread and then checking whether DefeatBridge is active should let you identify a DefeatBridge defeat or surrender scene after the OStim thread has started.

 

I would recommend using the public TMS_DefeatBridgeNative.IsDBSceneActive() API rather than reading TMS_DBEventRunningGV directly. I added that specifically so third party mods do not need to depend on internal globals. I have also updated the third party integration template to document it.

 

As for a hook before the OStim thread starts, I considered this previously, but third party event handling at that point can interfere with DefeatBridge's own startup flow. Because of that, I decided to keep third party outcome integration after the OStim or Ocreature thread has finished instead.

 

Regarding GitHub, I understand the concern, but I do not currently plan to open source the native DLL. A large part of DefeatBridge's implementation and stability work is in the native layer, and I would prefer to keep that core closed for now. What I can do is keep the public integration surface documented, including the scene state API, Outcome API, YAML schema, and example integration template, so other mods can integrate without depending on internal implementation details.

TMS_DefeatBridge_ThirdPartyIntegrationTemplate 2.3.zip

Edited August 13 by cashboxs

[chrystelle]

I did some testing with it for a bit.

 

Firstly, I think this is the right general approach.  The trickiest part with OStim is handling the combat state of all actors.  As you stated above, an actor returning to alert of combat state is instant CTD with Ostim, 100% of the time.  Lots of mods are being released for OStim right now, which is great, but some of it is clearly AI-generated slop, like another one released here today that goes on and on about OStim crashing if no scene is found.  That is AI hallucination and misinformation.  OStim handles not finding a scene perfectly well, no crashes.  I don't have any issue with devs using AI tools any more than I have an issue with devs using IDEs, which is not at all.  But you can easily tell the difference between slop and someone who knows what they're doing.

 

Anyway... I think it takes some experience with hands-on Skyrim modding to find the right approach to implement something, and I think a lightweight native bridge to handle the really sensitive part of shutting down combat and seeing if scenes exist is the right approach for OStim defeat.  I really like the idea, and your handling of combat states from my little bit of testing looks very solid.  So that is the hardest part done.  I think it would be great to have a common foundation for mods of this type for OStim to build on.

 

With that said, here is some feedback on things I think would make it a lot easier for modders to make integrations if that's the direction you're looking to go:

 

The easy part:
- It was very easy to see the state of the mod using the GV.  On a thread start, a listening mod can know right away whether or not it is a defeat thread.  I'm sure I could also GetFormFromFile the quest itself to get the aliases, and that could open up even more options. So that part is already great for integrations.

 

Possible blockers:

- No matter what I did, I could not get the excitement bars to show.  You seem to have hard disabled them.  Same with any sort of imod.  None had any effect. 

- The thread started with just the idle animation even if auto was enabled in the OStim settings.  You seem to have disabled that, as well. 

- While auto-mode is probably the best default for defeat scenes, an alternative would be to pull those reference aliases like I mentioned above and tried to set the OStim scene via script.  But given that I couldn't get the bars back via script, I suspect starting a scene via script might also fail.  (To be clear, I don't know this for sure, plan to test it later.)

 

My feedback:
- Loosen control of the thread.  Don't disable the bars in a way that a user or an integrating mod can't get them back. 

- Respect the auto setting in the OStim settings.  If it is set to true, pick a random starting scene from the available sets.

- Don't make the player manually add actors at the beginning of a thread.  Your code already knows the nearby actors, and since you are doing it natively, you can quickly try different combos to see what is available, starting with the max number of actors in the settings, and dropping farthest actors (osanative has a function to sort by distance) until a scene can be found, finally releasing if even a 2-person scene is not found.

- Open the source, just like OStim itself, Pandora, Community Shaders, Acheron...  If you want people to build on it, which essentially means recommending other people download it, it needs to be open so that people have a chance to know what is running on their computers.  Supply chain risk and all that.  EDIT: I was typing this out and didn't see your reply above until after I hit post.  That's really too bad.  I think it will hurt any chance this will see wide adoption.

 

TLDR, love this idea, lightweight native bridge that does the heavier lifting of handling combat/alert states and finding the most suitable scene according to the user's settings, things native is much better at than Papyrus.  But stepping back to keep users and integrating mods in control during the thread, taking control again at thread end to do the handoff.

 

Edited August 13 by chrystelle

[cashboxs]

About the excitement bars, that one is fair feedback. Hiding the HUD was partly a personal preference of mine because I preferred a cleaner presentation during defeat scenes. I can make that optional instead of forcing it, so users who want the normal OStim excitement bars can keep them visible.

 

The behavior around OStim Auto Mode is more intentional. For a defeat event, I found it awkward to have the normal actor or furniture selection UI appear at the beginning of the scene. DefeatBridge already knows which actors are involved, so I wanted that transition to happen without asking the player to manually assemble the scene.

 

I also chose not to rely on OStim's normal Auto Mode for controlling the defeat scene itself because Auto Mode can continue changing animations after the scene starts. For defeat threads I prefer deterministic scene progression, which is why I use Stage Flow to control that part instead.

 

So I agree with loosening some of DefeatBridge's presentation choices, especially the excitement bars. but I would still like DefeatBridge to establish the actors automatically and keep the defeat scene progression controlled rather than handing that part back to normal Auto Mode.

 

On the actor selection part, DefeatBridge is actually already doing almost exactly what you described. It collects the valid nearby aggressors, orders them by distance, starts from the maximum actor count allowed by the user's settings, and automatically drops actors one at a time if no matching scene can be started. It continues down to a two actor scene, and if even that fails, DB releases the event.

 

So there is no need for the player to manually add actors during this process. Any notification about not finding a matching animation and reducing the actor count is only reporting DefeatBridge's automatic fallback process.

 

The Auto Mode behavior is intentional. I originally disabled OStim Auto Mode for defeat scenes because I personally use Stage Flow to control scene progression. However, I agree that this should be a user choice rather than something DefeatBridge forces. I can add an option to restore OStim Auto Mode for defeat scenes.

Edited August 13 by cashboxs

[cashboxs]

1 hour ago, chrystelle said:

I did some testing with it for a bit.

 

Firstly, I think this is the right general approach.  The trickiest part with OStim is handling the combat state of all actors.  As you stated above, an actor returning to alert of combat state is instant CTD with Ostim, 100% of the time.  Lots of mods are being released for OStim right now, which is great, but some of it is clearly AI-generated slop, like another one released here today that goes on and on about OStim crashing if no scene is found.  That is AI hallucination and misinformation.  OStim handles not finding a scene perfectly well, no crashes.  I don't have any issue with devs using AI tools any more than I have an issue with devs using IDEs, which is not at all.  But you can easily tell the difference between slop and someone who knows what they're doing.

 

Anyway... I think it takes some experience with hands-on Skyrim modding to find the right approach to implement something, and I think a lightweight native bridge to handle the really sensitive part of shutting down combat and seeing if scenes exist is the right approach for OStim defeat.  I really like the idea, and your handling of combat states from my little bit of testing looks very solid.  So that is the hardest part done.  I think it would be great to have a common foundation for mods of this type for OStim to build on.

 

With that said, here is some feedback on things I think would make it a lot easier for modders to make integrations if that's the direction you're looking to go:

 

The easy part:
- It was very easy to see the state of the mod using the GV.  On a thread start, a listening mod can know right away whether or not it is a defeat thread.  I'm sure I could also GetFormFromFile the quest itself to get the aliases, and that could open up even more options. So that part is already great for integrations.

 

Possible blockers:

- No matter what I did, I could not get the excitement bars to show.  You seem to have hard disabled them.  Same with any sort of imod.  None had any effect. 

- The thread started with just the idle animation even if auto was enabled in the OStim settings.  You seem to have disabled that, as well. 

- While auto-mode is probably the best default for defeat scenes, an alternative would be to pull those reference aliases like I mentioned above and tried to set the OStim scene via script.  But given that I couldn't get the bars back via script, I suspect starting a scene via script might also fail.  (To be clear, I don't know this for sure, plan to test it later.)

 

My feedback:
- Loosen control of the thread.  Don't disable the bars in a way that a user or an integrating mod can't get them back. 

- Respect the auto setting in the OStim settings.  If it is set to true, pick a random starting scene from the available sets.

- Don't make the player manually add actors at the beginning of a thread.  Your code already knows the nearby actors, and since you are doing it natively, you can quickly try different combos to see what is available, starting with the max number of actors in the settings, and dropping farthest actors (osanative has a function to sort by distance) until a scene can be found, finally releasing if even a 2-person scene is not found.

- Open the source, just like OStim itself, Pandora, Community Shaders, Acheron...  If you want people to build on it, which essentially means recommending other people download it, it needs to be open so that people have a chance to know what is running on their computers.  Supply chain risk and all that.  EDIT: I was typing this out and didn't see your reply above until after I hit post.  That's really too bad.  I think it will hurt any chance this will see wide adoption.

 

TLDR, love this idea, lightweight native bridge that does the heavier lifting of handling combat/alert states and finding the most suitable scene according to the user's settings, things native is much better at than Papyrus.  But stepping back to keep users and integrating mods in control during the thread, taking control again at thread end to do the handoff.

 

I’ve updated DefeatBridge to version 2.4 based on your DefeatBridge to version 2.4 based on your feedback.

 

I added an option that lets users choose whether DefeatBridge should hide the OStim UI during player defeat scenes, and another option to restore OStim’s native Auto Mode for defeat scenes.

 

Thanks again for taking the time to test it and point these things out. I think giving users the choice here is better than forcing my own preferred setup.

 

Also, I realized that in a previous update I forgot to include the updated script source files in the archive. They have been synchronized and updated in this release as well.

Edited August 13 by cashboxs

[chrystelle]

If the intention for the mod is to have it as a standalone defeat setup or in conjunction with Stage Flow, that's totally valid.  Everyone's time is limited, and we only feel motivation to make the mods we want to make.  But if the intention is for it to be the base every OStim defeat mod is built on, which it could be, it would need more adjustments.  (1) It would have to be open, and (2) it would have to give integrating mods more control over scene selection.  Consider that mods like Acheron hand off before starting a SL or OStim scene, and that is why other mods build on it.  Acheron has it's own problems, though.  It's not easy to build on it optionally as opposed to a hard dependency.  This mod could be that literal bridge that passes player defeat off safely, but to be that it needs to step back more in some ways and step up in the scene selection logic.  Respecting auto mode is good, frameworks should not override user settings whereas a gameplay mod might, depending on the nature of the mod.  But auto mode alone is not sufficient for this.  Integrating mods will have different tags they want in different scenarios.  This is the control Acheron gives.  It passes off the metadata so you can do the rest.  This mod could leapfrog it for this particular purpose, because being more focused means it can be smaller footprint but also do more of the actual heavy work in setting up the ostim thread for the integrating mod. 

It's a matter of whether you want the mod to be a framework mod (no opinions, very extensible) or a gameplay mod (that really needs your other mod as its second half).  Either is obviously fine. 

[cashboxs]

I think I understand the difference in how we are looking at the role of the bridge now.

 

If DefeatBridge only handled the downed state and then handed everything over before scene creation, Acheron would actually be the more mature and reliable choice for that purpose. It already does that job very well, and I don't think there is much value in creating another framework that only duplicates the same role.

 

The part I specifically wanted DefeatBridge to solve is the middle layer between defeat and a running OStim or OCr thread. In my experience, the most difficult part is not only making the actor fall down, but safely handling the logic afterwards. Combat state, actor ownership, scene startup, fallback handling, repeated defeat, and cleanup are where many defeat setups can become unstable.

 

For example, I previously used a defeat mod that was one of the lightest and most convenient solutions for my own setup. However, if the player was defeated again immediately after the first scene ended, it could enter an infinite script loop. The player would remain downed, unable to start another event and unable to recover normally. The Papyrus log would continuously fill with errors. I tested it once and reached around 200 MB of log output in about one minute.

 

Experiences like that are also why I am cautious about allowing third party logic into the process before the OStim or OCr thread is safely established. I would rather keep that sensitive part controlled by DB, and expose integration further downstream after the main thread has finished.

 

I do agree that DB should avoid unnecessary opinions once the thread is running, which is why I changed the HUD behavior and OStim Auto Mode to user options in 2.4 instead of forcing my own preferences.

 

Put simply, I think DefeatBridge should probably be considered a standalone defeat mod rather than a general purpose framework. Maintaining a framework is a much larger commitment, and in my experience the most time consuming part is not writing the code itself, but testing all of the logic and edge cases around it.

 

You managed to bring creature support into OStim, so I can only imagine how much testing and iteration it took before OCr reached the point where the rest of us could reliably build on it. DefeatBridge itself benefits directly from that work, so I genuinely want to thank you for it. I hope that also helps explain why I am a little conservative about where I draw the integration boundary for DB.

[chrystelle]

6 hours ago, cashboxs said:

I think I understand the difference in how we are looking at the role of the bridge now.

 

If DefeatBridge only handled the downed state and then handed everything over before scene creation, Acheron would actually be the more mature and reliable choice for that purpose. It already does that job very well, and I don't think there is much value in creating another framework that only duplicates the same role.

 

The part I specifically wanted DefeatBridge to solve is the middle layer between defeat and a running OStim or OCr thread. In my experience, the most difficult part is not only making the actor fall down, but safely handling the logic afterwards. Combat state, actor ownership, scene startup, fallback handling, repeated defeat, and cleanup are where many defeat setups can become unstable.

 

For example, I previously used a defeat mod that was one of the lightest and most convenient solutions for my own setup. However, if the player was defeated again immediately after the first scene ended, it could enter an infinite script loop. The player would remain downed, unable to start another event and unable to recover normally. The Papyrus log would continuously fill with errors. I tested it once and reached around 200 MB of log output in about one minute.

 

Experiences like that are also why I am cautious about allowing third party logic into the process before the OStim or OCr thread is safely established. I would rather keep that sensitive part controlled by DB, and expose integration further downstream after the main thread has finished.

 

I do agree that DB should avoid unnecessary opinions once the thread is running, which is why I changed the HUD behavior and OStim Auto Mode to user options in 2.4 instead of forcing my own preferences.

 

Put simply, I think DefeatBridge should probably be considered a standalone defeat mod rather than a general purpose framework. Maintaining a framework is a much larger commitment, and in my experience the most time consuming part is not writing the code itself, but testing all of the logic and edge cases around it.

 

You managed to bring creature support into OStim, so I can only imagine how much testing and iteration it took before OCr reached the point where the rest of us could reliably build on it. DefeatBridge itself benefits directly from that work, so I genuinely want to thank you for it. I hope that also helps explain why I am a little conservative about where I draw the integration boundary for DB.

 

I understand and I get where you're coming.  I mistook the intent of the mod.

 

Also, just to avoid taking credit for someone else's work, I wasn't the person who developed OCreatures originally.  That person decided to step back from it to focus on other things.  I just changed it up a bit to drop the SL-related dependencies.  I have more changes in the works, but it's not in a releasable state at the moment.

[shadowknyght]

Hi
Just wanted to say thank you for the mod and wanted to know if anyone else is having an issue where you have to be knocked down multiple times for a creature to engage you.  Sometimes it's twice, sometimes it takes three or four times.  I am really thankful for this mod though.  It is the only way I have my defeat for both humans and creatures.

 

[cashboxs]

38 minutes ago, shadowknyght said:

Hi
Just wanted to say thank you for the mod and wanted to know if anyone else is having an issue where you have to be knocked down multiple times for a creature to engage you.  Sometimes it's twice, sometimes it takes three or four times.  I am really thankful for this mod though.  It is the only way I have my defeat for both humans and creatures.

 

This might have to do with hidden logic. The logic restriction is that after you fall, the current enemy can't be in combat with other units. For example, if you're fighting near a village, and guards/civilians are still fighting your enemy after you go down, it's normal that the enemy ignores you. As for followers being suppressed when you fall, that's purely for gameplay reasons.  
Next time this happens, you can send me the SKSE log/script log. You'll need to turn on logging in the SKSE menu first. if you're not sure how, you can ask an AI.