Turn Based H-Combat (Mod Development)

[fingerscrossed]

48 minutes ago, Corsayr said:

You might be taking it too literally

 

I was just making potential examples. (I do not know the exact conditions of stun or knocked out in this scenario, stun is used to represent a condition that prevents action of the person the condition is on but is not permanent)

 

The crux is I think if everyone on one team is in a condition that prevents action (in this case offensive and defensive action) even if that condition is self removing, or can be removed by the player. That team should lose.

 

Ultimately the idea I am putting forward is that the "all down" condition should not need to be all permanently down. 

 

That make sense? 

Ahh, okay.  Yes, that makes sense.  I suppose that comes from some being too much in the reeds.

 

I agree, though, that if the entire team has conditions that, essentially:
- Make them unable to take action

- Make them unable to defend themselves (i.e. all actions against them succeed)

 

That would definitely be a good situation for ending combat.  Probably a more restrictive list than just "disabled" but less restrictive than "Incapacitated/Dead".  Which could also play well into adding additional/other effects as alternate ways to effectively "down" enemies.

 

Assuming I'm not missing the point again, which I may be.

[fingerscrossed]

Today's update:

 

Changed:

- Different actions now have their own separate base success chances (That are set up in a way so they can be configured/changed in game)

- Positioning, Quest fill, etc.  This was a really large change, so see the section below

 

Added:

- New Buff Effect: Stealthed (Currently provides +40% to hit, -20% to be hit, and applies sneak attack damage on next attack)

- Some gear sets that I'd at least partially previously made that I intend to use (see gear section)

 

Quest Fill and Placement Change:

I took a good bit of time today to make some changes and move things around in order to make things more "radiant".  In terms of player experience, this won't really mean much, but in terms of modding, current and future it has a big implication.  The main change I made is adding several quest Alias that fill using conditions at the start of combat/quest start with minimal inputs needed.

 

If you're wondering what this means in laymens terms, constructing a new battle zone/area should be as simple as:

1) Create a new location

2) Copy a set of core items (position markers) from a test cell to your new location

3) Copy/Add whatever furniture/bondage gear you are looking to add.

4) Decorate your location

 

And, with that location selected in the quest, it should run as a battle zone.  I'll need to set up some way to register battlezones with the mod, but I hope that shouldn't be too difficult, and it'll let anyone in the future be able to design a new area for aesthetics, or maybe with their favorite pieces of bondage furniture. This is one of those changes I'm glad to have gotten done, but it took some time and was really tedious.

 

Position Changes:

Instead of each side being 5x3 (Actors X rank) each side is now 4x2 and actors can get slotted and move around to open slots.  I'm looking into, in the future, providing some kind importance to this, where rank affects hit, who you can attack, etc.  With the upgrade to the way I was handling positioning, movement, etc, above I wanted to go ahead and get this upgrade/change in place.

 

Gear:

These aren't necessarily complete, but were something I had made previously for my own mod/use.  I'm planning to include them in the TBC mod for use in certain situations.  There are 3 sets I'll show an initial version of today (note that these are re-textured/re-skinned from ZaZ):

 

Magic:

Have you ever thought to yourself: I can conjure an axe.  I can conjure a bow.  I can conjure a daedric lord.  Why can't I conjure up some restraints for this pesky slave?  

 

Well, maybe you haven't, but I have.

 

Spoiler

 

Frost/Icy:

Need someone to just chill out for a bit?  Do you want to be cool or something?  ... Ok, I'll stop with the puns.

 

 

Spoiler

 

 

Spider:

Have you ever wondered what would make spiders worse?  Depending on your interpretation of worse, web based bondage could be an answer.  I'm still on the fence.

 

Spoiler

 

Closer up (where it looks a bit more "webby" on some of the pieces:

 

 

 

The retextures still need some work (and I'll need to figure out at some point how to properly put them in Body Slide if I want to distribute them) but I thought people might appreciate seeing it.  I'm looking into a fire retextured set as well.

 

CTD:

I'm still getting a really odd Crash to Desktop.  The crash occurs when hitting escape or opening menu.  It doesn't start at the start of combat, and I haven't been able to trace it back to any set of actions that start it, and it doesn't seem to just be time based either.  It's kind of a major bug, so it needs to be addressed, but I really have no idea what's causing it, or if it's got something to do with the rest of my install being unstable.

[afa]

I sort of toss out the 3 to 4 party member as a random case since typically I have PC + 2 followers or PC+ 3 followers in game, and was just wondering how that will translate in this system. It's nothing scientific nor must have.

 

This might sound silly, but what's wrong with combat ending when all member of one side are incapacitated? I was under the impression that actors can be incapacitated by either depletion of health or stamina, so either fight or sex. It seems like as good as any system why the extra thought and conditions on determining ability to act or not?

I could kind of see fleshing out sex attacks, struggle/resist, and how it plays with stamina however.

[fingerscrossed]

Today's update:

 

Relatively minor, didn't have much time today.

 

Began working on spell casting implementation, making spells for use in the mod.  

 

Fixed a few more things to help with the ability for making zones dynamic.

 

I think my plan is to get the basics of spell casting implemented, then start working on classes.

[fingerscrossed]

Things have been really busy for me lately, so I haven't a had to work on this much.  But, here's a small update:

 

Added:

- Some initial spells, spell casting options

 

And that's pretty much it for current updates.  The spells that are in cast and show the animations for casting but don't deal damage/start combat, so making pretty good progress.  I'm looking to get the spells set out and sorted, and then I think I am going to start working on the class system.  I have an idea how I am going to implement this.

[fingerscrossed]

Quick update:

 

Poll:

See the poll added to provide some feedback for mod direction.  I am currently starting to look into working on and developing the class system, and I am working on determining how much I should try and include the base game stats in the mod.  This ties into things like looking at a characters equipped weapon, searching for in game perks, maybe trying to take into account their training in various skills (1 hand, destruction, etc).  There are currently 3 options:

 

1) As much of this as reasonably possible should be used: Skills should be pulled and factored in, traits should have some kind of similar effect, and so forth.  This is the option that would have the non-turn based combat stats affecting this mod the most, but it would also be the most complicated both from a modding perspective and from a user interaction perspective.

2) Simple or straightforward things should transfer: This is essentially things like weapons, armor values, etc (but very likely not enchantments due to the great complication that would have on implementation).  This is kind of a middle ground of still being able to improve your character for TBC outside of leveling up without having to likely guess at how something is going to affect the end result.

3) Keep everything separate: Add tiered weapons/armor/etc for the mod.  Maybe specific TBC weapons that you can get upgraded through some in mod means rather than try and use weapons from the base game.  

 

My feelings are a bit back and forth.  Option #1 would be the most work, and I don't think I like it as much.  It seems like it would quickly get messy and potentially not feel as good/balanced.  Option #3 is interesting and would likely be significantly easier to balance since everything would be "in mod", but that would also mean needing to actually add weapons/items to the mod for each class to balance around.  Additionally ways of improving those items so that you would be able to feel your own improvement.

 

I'm leaning mostly towards option #2, because it reduces the necessary game information to try and pull in from Option #1 and reduces the workload from Option #3 while still letting you have an affect on your character's ability with items, armors, etc.  But, I'm still working on some of the design aspects, so I wanted to see what the communities opinions were.

[fingerscrossed]

Today's Update:

 

Little actually got done/changed in the mod.  Instead, today I've been focusing on the class system and class design.  This is both for trying to figure out exactly how classes should operate, and what additional subsystems I will need for the classes to operate.  I'm still on very much of a first draft, but the classes and how they work are starting to take a bit of shape in my notes.  It is looking like it's going to be a fairly major overhaul of what I already have, but it looks like it will be better.  There's some scripting challenges, though, from my ideal implementation that I have yet to figure out.

 

As things get a bit more concrete, I might look to make a longer post (maybe this weekend) with some more info on classes and how they work.

[Visio Diaboli]

IMO it's a perfect system if everything carries over one-to-one from the natural progress tree, that is, everything that would affect your stats in vanilla combat would apply an equivalent effect in turn-based, the gear would be handled, and each perk would be given an equivalent in the turn-based system. After combat you could calculate xp and where to allocate it, that way you can pretty much use the combat system Bethesda already built, but without the 'direct combat' - just taking values from that system and using them in the combat arranged by your system.

 

Granted that's a lot of shit to do, and I'm not suggesting you ought to - probably just the simple/straightforward system would be fine and that could be a project to be done gradually if ever.

 

As for implementing the vanilla equipment, I don't know how this meshes with what you have now, but perhaps the getters and setters in these could be helpful?

https://www.creationkit.com/index.php?title=Weapon_Script

https://www.creationkit.com/index.php?title=Armor_Script

 

Particularly GetBaseDamage(), GetSpeed(), and GetStagger() for some form of 'inherent stun ability'?

 

That way you could even create weapon/armor property arrays that hold all of the vanilla 'tiers', and have some function, for example, that takes a weapon and its wielder as an argument, and using the getters above and actor values pulled from the wielder, returns an 'attack value' specifically tailored to your mod. There's probably a better or more mod-specific way to do that but that's just a suggestion based on how I'd probably look at doing it.

[fingerscrossed]

On 9/22/2020 at 5:24 PM, Visio Diaboli said:

IMO it's a perfect system if everything carries over one-to-one from the natural progress tree, that is, everything that would affect your stats in vanilla combat would apply an equivalent effect in turn-based, the gear would be handled, and each perk would be given an equivalent in the turn-based system. After combat you could calculate xp and where to allocate it, that way you can pretty much use the combat system Bethesda already built, but without the 'direct combat' - just taking values from that system and using them in the combat arranged by your system.

 

Granted that's a lot of shit to do, and I'm not suggesting you ought to - probably just the simple/straightforward system would be fine and that could be a project to be done gradually if ever.

 

As for implementing the vanilla equipment, I don't know how this meshes with what you have now, but perhaps the getters and setters in these could be helpful?

https://www.creationkit.com/index.php?title=Weapon_Script

https://www.creationkit.com/index.php?title=Armor_Script

 

Particularly GetBaseDamage(), GetSpeed(), and GetStagger() for some form of 'inherent stun ability'?

 

That way you could even create weapon/armor property arrays that hold all of the vanilla 'tiers', and have some function, for example, that takes a weapon and its wielder as an argument, and using the getters above and actor values pulled from the wielder, returns an 'attack value' specifically tailored to your mod. There's probably a better or more mod-specific way to do that but that's just a suggestion based on how I'd probably look at doing it.

 

I agree with a lot of what you said, and I've looked into a lot of those properties.  I haven't had any time to work on this (life has been an absolute bitch the past few weeks), but I'm looking to try and put in a bit of time this weekend.  To address a few specific things:

In an ideal world, everything would carry over, but it's sadly just not quite the way Bethesda has certain things outlined and set up.  Some information is harder to pull, and the exponential growth of choice makes certain things less ideal.  I'm more cemented now that I've looked into it into using a class system, if for nothing else than simplifying AI and choices.  I'm sure there will be some people who will get annoyed because "I'm the dragonborn, I've maxed all my skills, I can do anything!" but that starts getting into something that is .... kind of a mess. Lots of menus, etc.

 

Vanilla equipment implementation definitely seems like a good way to go and what I'm looking at.  The biggest potential problem is damage scaling and "lol uber weapons" vs magic damage scaling (in terms of balance) but it's something solvable.  I didn't think of using GetSpeed or GetStagger, but that's actually a good call.  GetSpeed could, for example, modify how I was calculating multistrike chance and certain abilities with the chance to stun could use GetStagger.

 

Equipment and Breaking Equipment

 

One of the other things I ran into was changing/modifying some scripts and how things were done.  As an example of this, for some of my own mods, I had spells/abilities that would, essentially, wear down (and eventually destroy) armor as it was being damaged.  However, for a mod like this, if equipment was being damaged it would need to be able to be repaired.  There are already some mods that have this type of functionality, but I'd rather not have to integrate and make any of them a master of this mod, so I've been looking for a simple solution.

 

My current idea is that, when an equipment becomes "broken" it's removed from the actors inventory and placed inside of a specific chest.  You would be able to talk to like Blacksmiths or similar merchant NPCs to get an option to repair all of the broken equipment for some percentage of the value of the equipment.  It, of course, has some issues (inability to easily choose what to repair, how to handle the PC wanting to repair the equipment themselves, etc.) but for kind of a simple system I think it would work.  

 

Scripting Classes

 

Part of the issue I've run into at the moment is I was trying to kind of "future-proof" the mod.  I'm looking to run each classes AI on it's own script to reduce the processing burden, simplify processing, etc.  Ideally, I originally wanted to do this by having a separate quest and function for each class, with an array of functions that could be called on.  As an example, you'd have something like:

ClassControllers[0] = AssassinClassController

 

And so be able to call them by their index numbers, and still have separate controllers for each.  The issue I've run into is that I can't find a way of doing this, I could make an array of a single script, with each one tied to a different quest, but not an array of different scripts (which makes some sense with the way that Python operates).  Now, this has, of course, got me thinking if I can't still make it work.  And I think I may, but the implementation will be a bit more difficult.

 

The end result would be creating a single script, say TBCClassController.  Inside the script are a set of properties, decisions, and weights that cover various actions.  How it would work is that each class would still have it's own quest. So, using the Assassin class as an example, you would have the TBCClassController script on the TBCAssassinQuest quest.  You would then add any needed information for the class (Scenes for performing the various attacks, etc), and then go into the properties and set them depending on how you want the class to work.

 

Because of this, there would be limits to the number of actions available to each class (which is somewhat intended), but I think it could still end up making it relatively easy for someone to add a class to the system.  There would likely be a large amount of properties that would need to be filled.  Some simple examples being:

HPScalingFactor (An Integer)
ClassName (A String)
AttackType1 (A String)
AttackScene1 (A Scene)
etc.

And some more complex factors such as:
UseAttackCondition1 (A bool)
AttackCondition1 (A spell/effect the actor needs to have to execute)
Attack1TargetAllies (A bool, where for true it targets allies and false enemies)

And so on.

 

It would limit some complexity on what you could do with the various classes because you'd need to be somewhat formulaic for simplicity, but it would likely still work well enough.  It would be easier if there were a way to create a proper index of disparate functions, but I haven't seen or thought of any good way of doing it.

 

I may also split the Class Controllers into broad categories (Physical Classes, Magic Classes, Sex-based Classes, Creature Classes) with separate controllers so that the controllers themselves could reflect that a bit better, so that's also something to consider.  

 

A Non-H Implementation

The other thing I've been thinking about is whether or not I want to include/create a Non-H implementation for the mod.  It was always the idea that there would be a toggle for it, but I've been wondering/thinking whether or not it's worth to make a version without Sexlab/Zaz dependencies, how much extra work it would be, and if it would be worth the extra work.  I'm currently leaning towards "probably not worth the extra work" but try to decide before I get too deep into class development, because how I decide on that will probably impact how I implement the classes.
 

 

 

 

[Visio Diaboli]

Curse Creation Kit and it's lack of user defined types xd

 

All looks good though, no pressure to get stuff done if you don't have time.

 

I wouldn't personally mind if it released without a non-H version, although my opinion is subjective since I don't generally play turn-based games unless they're hentai games.

 

Edit: not sure if it's intentional but the poll is currently closed

[fingerscrossed]

Another brief update

 

Poll Results from the First Poll

 

Everyone either voted to pull as much as possible, or to just pull simple forms from the base game.  It was fairly close at the end of voting, with pulling as much as possible pulling ahead slightly.  I'm planning to move forward with this in mind, trying to see what all can be reliably/easily pulled from the base game to make a good 1-1, but not focusing too heavily on trying to map or use base game assets.

 

Second Poll

 

Second poll is up, and now is the time to throw in your opinions:  Should the mod have a base implementation that includes no H/Adult content/action?  I've realized that, after giving it some consideration, it may be simpler to do than I originally thought.  What would likely happen is:
 

1) There would be a basic "TurnBasedCombat" mod, with scripts and functionality for simply turning Skyrim combat into your more standard RPG combat.

2) There would be a second mod (Available on LL) that would update the scripts from the above mod to include Adult functionality.  

 

One of the goals would be to design the Adult versions so that they would be compatible with Non-H versions.  As an example, this would mean that someone could create a class for the Non-H version, and it would work in the H-version, just potentially be unable to perform (or receive) and H-attacks.  Classes wouldn't, however, be backwards compatible (Classes made with Adult version being usable in Non-adult).

 

Since I've thought of what seems like a decent way of doing it, now I'm curious to see what the community thinks.  

 

Issues:  There would be two versions of scripts, so version control could get messy.  It would definitely extend development time.  I'd have to redo some work I've already done (though some of that work may need to be redone anyways).

[fingerscrossed]

3 minutes ago, Visio Diaboli said:

Curse Creation Kit and it's lack of user defined types xd

 

All looks good though, no pressure to get stuff done if you don't have time.

 

I wouldn't personally mind if it released without a non-H version, although my opinion is subjective since I don't generally play turn-based games unless they're hentai games.

 

Edit: not sure if it's intentional but the poll is currently closed

 

Yeah, unless Creation Kit has some functionality there that I'm missing (Which is possible, but I did look a bit!) it does make certain things a bit more complicated.

 

You caught me right between closing the poll and making a post about switching what the poll was about, nice timing!  And that's pretty much exactly what the poll is on.  The poll itself is, of course, likely to be swayed/subjective because of where I'm hosting it, but I'm curious to get some feedback and see if there is community interest in a non-H version.  If there's a good amount of interest, it may be worth looking into it (assuming my method for doing it would work as well as I think), but there does start becoming additional design considerations.  

There's definitely some consideration for "An MCM option to toggle it off is enough, even if you need the dependencies", but it would limit some potential distribution/user base.  If I was going to do that, I'd probably host the base version on Nexus and the Adult version on LL.  

But, at the end of the day, it comes down to whether or not the extra effort is actually worth it.

[fingerscrossed]

First real update in a while

 

In Progress

 

Work has begun on making the generic class controller script I mentioned before.  I'm working towards making it generic enough, but with enough conditionals and weighting you can change, that any class could run off of it.  This does mean, though, that certain things may not be doable.  Here's a breakdown of how it's shaping up:

 

Each class can have:

Up to 5 attacks
Up to 3 other Special Abilities
Up to 3 Class Specific Buffs

Up to 6 Perks

An attack that strips
An Attack that Binds

(Potentially) An Ability that Places Furniture
(Potentially) An Ability to put an actor in Furniture
An Attack that starts sex
 

Attacks, Special Abilities, and Perks will have a level tied to them that they are "unlocked" at for that class.

 

Class specific buffs can effect ONLY the class.  This would be something like stealth.  There will be a set of general effects that can be put on allies/enemies, but these are specific class ability buffs that might have an impact on behavior or special effects.

 

The AI runs through to check what you can, or can't, do and then starts generating your probability matrix for what an actor is going to do depending on the situation.

 

Perks Vs Buffs

 

The difference between perks and buffs is perks are always active and buffs are temporary.  As an example, Stealth would be a buff, but "Dagger Mastery" would be a perk.  The idea behind this being primarily to give classes special passive bonuses through perks.  However, this has an issue: Due to the nature of how the mod is looking to be set up, the things that a perk could do would have to be somewhat limited since they'd need to one of a set of predefined options.  Also, even being limited, it would result in a lot of properties (and there are already going to be a lot of properties).  

 

Because of this, perks may end up getting removed from design. It'll probably depend on whether or not I can find a good way of doing them.  They worked a lot better when there was a class specific script, so that you could easily modify depending on what the perks did.

 

Weights

 

So, how does the script iterate options.  Well, it does it through weights, both base and personality bonuses.  So, how does that work?  Let's look at a very simple example.

 

An action will have a base weight that can be either used at its base value in the script or set in properties.  For a female character who is currently getting Sexed, she has three options:
 

1) She can struggle to try and break free
2) She can Advance the stage, trying to end it sooner
3) She can pass, letting her aggressors continue having their way with her unabated

 

For base chances (without any modification) these are 7, 2, and 1 respectively, meaning that 70% of the time she will try and struggle out.  If you are adding a class, you can modify these values for the class, changing the base behavior.

 

In addition, every weight can have up to 3 personalities attached to it.  Each of these three personalities would then be assigned a weight.  Let's stick with the original base chance of 7 for struggle.  Now, let's say that you want to make sure that if your girl is Resistive, she's going to try and struggle more.  So you set the 1st personality to Resistive and set the Weight to 10, to really up the odds there.  Then you decide that, well, if that's the case the opposite should be true, so if she's submissive she should be unlikely to resist.  So, you set the second personalty as submissive and set the weight to -5 to really tone down the odds on resisting.  Your happy with this, so you leave the third personality blank and it's weight at 0.

 

And that's pretty much it.  It's less for the sex part of things in a lot of ways and more for the regular attacks.  Since the script doesn't really know what any given attack does, it doesn't know what personalities would be more likely to make that kind of attack.  Alternatively, you can make the class not care about personalities by just not including them.

 

Battle Field Smartness

 

This is something that is significantly harder in a generalized script.  Determining what parts of the battlefield the actor cares about and how they care for a generalized script is going to likely be pretty non-existent.  At best, it might be possible to make a few general battlefield checks, but even if we make the checks knowing whether or not to apply them and how to apply them becomes tricky, since you would essentially have to have a check for each attack to see if it A) Cares about a battlefield condition and B) The state of that condition.  This runs into a similar issue as the perks where it becomes very limited by the generalized form.

 

How smart do they NEED to be?

 

At the end of the day, some of the above comes back to the idea of how smart enemies actually need to be.  It's an RPG, not a game of chess and so maybe a lot of things aren't as necessary as really the solution just needs to be "good enough".  In some ways, it might even be better, since a less smart AI that relies more on chance to do things is probably more likely to produce varied battle results.  The better the AI, the more likely it would be to do the same things every time, which is probably less interesting.

 

Next Up
 

Continuing work on the generalized Control Script.  Once the Generalized control script is in place, I'll create the first few classes and start running some tests to see how it works. Hopefully well.  This will probably take a little while.

 

Feedback
 

Should the simplest/simpler paths forward be pursued so that an earlier release is more likely, or should extra effort be expended to try and make things as robust and inclusive as possible?  Tying into this, for something like Perks where it would require working into the back end how to deal with it, if they missed the initial release, I'd be pretty unlikely to want to go back later and make large changes to get them included, so it has a lot of "now or never" feeling.

[Visio Diaboli]

Maybe you could assign a 'favorite' attack or action to each npc, based on their personality, and then pretty much roll their actions completely randomly but weight the favorite more heavily. So then essentially every turn you could first pick a target, then check like one basic condition for each attack (i.e. if the target is stunned or sufficiently restrained then the npc isn't going to try to inflict any of those statuses, or if the npc is stealthed then they aren't going to stealth twice in a row), then roll between the remaining options (where attacks target the target, and things like self-buffing and team-buffing ignore the target)? There's probably some unoptimized aspects of that but I don't think the performance impact would be too perceptible.

 

Events could possibly be helpful for perks, but it'd mean sending events whenever most things happen in your mod. I don't use them a whole lot so I'm not the best with them but I conjecture that you could theoretically keep a string array of the perks a currently-in-combat actor has (although I'm not sure how you'd want to store them, I think every CK script needs to be attached to something so a cloak spell could possibly be best, or a separate value storing quest that creates an artificial 2D array with up to like 128 recent actors and their specific info), and then send a mod event, for example, when an actor makes an attack, that passes their list of perks and class to an attack event. Then you could have a script for each class that's registered for all of the events you need to track perks for, that catches it, checks if the class passed is the one the script is for, and then sorts through the perks, modifying values on, or sending events back to, the main controller script in accordance with how the perks need to be activated. 

 

I don't know if that provides any new ideas or not so apologies if it doesn't. This mod seems pretty engaging to script so I occasionally get carried away thinking about how I'd approach it.

[fingerscrossed]

2 hours ago, Visio Diaboli said:

Maybe you could assign a 'favorite' attack or action to each npc, based on their personality, and then pretty much roll their actions completely randomly but weight the favorite more heavily. So then essentially every turn you could first pick a target, then check like one basic condition for each attack (i.e. if the target is stunned or sufficiently restrained then the npc isn't going to try to inflict any of those statuses, or if the npc is stealthed then they aren't going to stealth twice in a row), then roll between the remaining options (where attacks target the target, and things like self-buffing and team-buffing ignore the target)? There's probably some unoptimized aspects of that but I don't think the performance impact would be too perceptible.

 

Events could possibly be helpful for perks, but it'd mean sending events whenever most things happen in your mod. I don't use them a whole lot so I'm not the best with them but I conjecture that you could theoretically keep a string array of the perks a currently-in-combat actor has (although I'm not sure how you'd want to store them, I think every CK script needs to be attached to something so a cloak spell could possibly be best, or a separate value storing quest that creates an artificial 2D array with up to like 128 recent actors and their specific info), and then send a mod event, for example, when an actor makes an attack, that passes their list of perks and class to an attack event. Then you could have a script for each class that's registered for all of the events you need to track perks for, that catches it, checks if the class passed is the one the script is for, and then sorts through the perks, modifying values on, or sending events back to, the main controller script in accordance with how the perks need to be activated. 

 

I don't know if that provides any new ideas or not so apologies if it doesn't. This mod seems pretty engaging to script so I occasionally get carried away thinking about how I'd approach it.

 

The first thing you bring up is something that is, in my opinion, pretty interesting to discuss, so I'll write about it a bit below.

 

Actions vs Actors

 

I actually currently approach some of this from the opposite direction.  At the start of a NPCs turn, it runs a basic check to gather some statistics to see what is a "doable" action. So, for example, it reports the number allies/enemies, number of them that are incapacitated, naked, bound, having sex, etc.  That kind of baselines what actions can be taken(For Example, The mod assumes that if you are trying to sex enemies, you have to go Naked -> Bound -> Sex (Currently, might change in the future).  Since it's a progression, you can check to see if there's any Naked actors who aren't bound to see if there's anyone to bind.  Similarly, a check is run to compare the number of Female Enemies to the number of Naked enemies to see if there is an enemy you can strip).  There's a couple of priority checks that get run at this stage.  Once an action is selected, it goes to target selection.  From here, it runs through finding who all of the valid targets are, if there are any priority targets, and then selects a random viable target.

 

Running Actions before choosing targets and vice versa comes to a design choice of whether you are more interested in controlling the occurrence of certain actions or controlling the occurrence of particular actors being targeted.  We can look at it from two simple examples, using random probabilities with no advanced weighting (which I can get into below):

 

Situation 1:  The enemy has 4 Female Actors and 1 Male Actor
Selecting Action First: We have our "attack" weighting at 3, and our strip weighting at 7, since we're really interested in seeing some titties (ignoring all other actions).  We roll actions, and 70% of the time we will choose to strip one of the female actors, the other 30% of the time we will choose to attack one of the actors.

70% to Strip
30% to Attack

Selecting Actor First:  We first select what actor we are targeting, so there is an 80% it's female and a 20% chance it's male.  If it's male, we will always attack it since we can't strip it.  If it's female, there's a 70% chance we strip them and a 30% chance we attack.

56% to Strip

44% to Attack

 

Situation 2: There is 1 Female Actor and 4 Male Actors

Using the same numbers from above, we get:
Selecting Action First:

70% chance to Strip

30% to Attack

Selecting Actor First:

14% Chance to Strip

86% Chance to Attack

 

Both methods have merit, but I think that selecting the action first would work better for this situation.  This also isn't accounting for any of the potentially more advanced scaling/weighting you could do (i.e. weighting the option to bind enemies higher the more enemies you have that could be bound).

 

Perks

 

So, I think I didn't actually explain the issue with perks too well in my previous post.  Storing the perks, what they are, and who has them isn't a huge deal overall.  The issue comes into how those perks interact with the main controller.  I'll give an example here of where the issue creeps in:
 

Originally, I was thinking I would have a class that gets a perk that lets them act almost normally while fully bound (i.e. can attack, or cast spells, etc).  As an idea, this is good.  With the current implementation, however, it becomes an issue of how to include this in the code.  Say you have 6 perk slots, and it could be any of the 6.  You'd also need to have some way of knowing that that, specifically, is what that perk does in the AI controller.  Being bound is a separate AI loop from acting normally, so you'd need to have an exception in the "being bound" loop to check for "See if the actor has Perks 1-6, then see if any of those perks enable them to act normally while bound".  For a class specific script, this would be very simple, because we would know what the perk is and is doing and could hard code it in.  But, for the generalized script, it starts getting messy.  Even for simple things, say a Perk that would decrease the overall damage you take, it would need to somehow be incorporated into the script with properties you could toggle for each of the potential 6 perk slots it could go in. Extrapolating out, you'd need a toggle for essentially every perk slot for every possible condition/scaling item it could effect, giving you essentially a number of properties equal to (#Perk Slots)*(#Possible Effects).

 

And even then, for the things where the perks would be more interesting/useful (the things like the above, where it modifies your classes game play) that possible interaction would need to be hardcoded into the script in a way that it could be taken advantage of.

 

Writing this out, however, a thought has crossed my mind on how I might be able to approach this.  Rather than, say, each class getting some arrangement of 6 perks, make it so that each class can have a set number of a certain type of perk.  For example, you could have two "offensive" perks that increase/modify/whatever your damage, and two "defensive" perks that either modify evasion, or damage reduction, or struggle, etc.  Similarly, a "start of battle" perk that could be for things like "At the start of battle, a higher level assassin starts in stealth" or "A high level conjurer starts with a pet summoned" sort of thing.  

 

By limiting where each perk could be used, it would greatly cut down on the number and places that a perk would need to be checked for, so less processing, and decrease the amount of properties required for each perk (since each perk wouldn't need all of the properties).  I'll have to give it some more thought, but this might actually be a pretty good solution.

 

Alternatively, Perks may just not really need to be a thing, I'm not entirely certain yet, but I'll give it some more thought.

 

On Feedback

 

Also, I appreciate the feedback.  For a lot of things, even if I don't end up using something recommended, it's usually good to get additional opinions and new thoughts.  For example, until I read through and started responding to your comment, I hadn't considered the above on perks and how I might be able to simplify implementation.  Feedback can have a lot of good impacts even outside of the direct topic.  It's helpful also just having people to engage and discuss with, especially since the mod is so heavily scripted and trying to get everything laid out is a pretty extensive task.

[Visio Diaboli]

Any success yet by chance? Not trying to rush you by any means just checking how it's going.

[fingerscrossed]

22 hours ago, Visio Diaboli said:

Any success yet by chance? Not trying to rush you by any means just checking how it's going.

 

Sadly, I haven't had any time in the past week to work on this.  A lot going on atm.  Hoping to plug away on the code a bit more this weekend, but will depend on whether or not I have time between some other engagements.

[fingerscrossed]

It's been a while, in part because it's been a rough last few months.  I'm currently back to working on this a bit here and there when I can spare some time, so wanted to give an update (And hopefully I'll get really back into the swing of things, with real updates soon):

 

I've been working on the generalized form for the class action controller.  There's some decisions I'm currently deliberating that I'll likely include in the poll, but I've been trying to work on this rather than the other parts of the mod to get it down (it's mostly just a lot to update/make.  Hopefully, though, once it's actually created it should simplify future prospects).

 

I'm posting a poll to get some community feedback on something I've been considering:

 

What actions should every class have access to.  Some of the options I am considering:

 

1) Struggle - Everyone, every class should have this.  Whether this is struggle off an attacker, struggle out of furniture/bindings.  

2) Hamper - Hamper is essentially just a debuff, flat penalty.

3) Help - The opposite of hamper, helping an ally

4) Defend - Apply a defensive buff to self

5) Spawn Furniture - Spawn a piece of furniture that essentially functions as a more powerful restraint

6) Lock Actor in Furniture - Place an actor into a piece of locked furniture

7) Free - This might be the same as help, but might be separate action for essentially attempting to free an ally from restraint, attacker, furniture, etc.\

8 ) Seduce - An ability for female characters to start a sex action (Some classes would have this, but not sure if all classes should)

 

Every class will have attack, binding ability, sex, etc., and class abilities but part of it is deciding whether or not there should be a good amount of general abilities like the above.  There are pros and cons to both approaches, where one of the pros is, especially for lower level characters, having access to more possible actions.  A con, however, is that class specific abilities would potentially be less impactful and not show up as often (Since there's a wider pool of choices).  Also, certain things being readily available (such as hamper) does change design space for classes that are based around debuffs.

 

Currently, I'm leaning towards only the necessary base abilities are available (Struggle and Free) and the rest, or versions of the rest, are class specific abilities.

 

As always, let me know what your thoughts are.

[Visio Diaboli]

Psyched to see this resume development. I'd think spawn furniture could be a conjuration ability or something just since that's one I have a hard time visualizing otherwise XD. Defend might be fine as a default action, most archetypes have some way of going fully on the defensive, though depending how difficult it is you could look at making some classes a lot better at it.

[fingerscrossed]

40 minutes ago, Visio Diaboli said:

Psyched to see this resume development. I'd think spawn furniture could be a conjuration ability or something just since that's one I have a hard time visualizing otherwise XD. Defend might be fine as a default action, most archetypes have some way of going fully on the defensive, though depending how difficult it is you could look at making some classes a lot better at it.

 

So, I was looking at potentially a few different cases for spawning furniture (and maybe some options for furniture already being spawned).  Defensive I was back and forth on, because for defensive it feels like there would be different ways different classes should be defensive.

 

On a somewhat related note, I finally realized that I have been making things harder on myself than they need to be, and there is actually a simpler and smarter way of doing classes (Thank goodness!).

 

I had been trying to create a generic "class controller" that would essentially function for any class with appropriate inputs.  Now, that being said, that leads to some issues such as needing to have some generic that can handle every situation, which as you can imagine gets pretty gross pretty quickly.  However, for making each class have it's own script, I would need some way of having those scripts be centrally recognized.

 

I just realized that instead what I can do is make each script class unique (though likely a lot of overlap and copy and paste I can do) and then just have a given quest stage that get's called in its accompanying quest to run whatever functions on the script, so they are set in the quest rather than needing to mess with them in the script. 

 

The main reason for this is future proofing so that people could add/create their own classes with abilities and controllers.  Now I think this will be much simpler than the "general case" script (which while I'd been developing a methodology for it, was really clunky and a lot of typing/considerations).

 

On another note, I'm currently working on DLing and setting up a clean Skyrim install/folder for testing, so that I can actually tell if crashes are what this mod is doing or what one of the plethora of other mods are doing.  Once I have that I should hopefully be able to debug easier and quicker, though as always "clean" installs are a pain and time consuming to set up.

[Boredomisgone]

Neat idea, just the long winded description makes my head hurt. Have this been out for testing yet? 

[fingerscrossed]

On 2/27/2021 at 9:43 PM, Boredomisgone said:

Neat idea, just the long winded description makes my head hurt. Have this been out for testing yet? 

 

This hasn't come out for testing yet.  I have had a lot of things going on that has slowed down progress on working on this mod and I ran into a complication last time I was working on it (I created a new, clean installation of Skyrim with only the basics for testing so that I could determine whether bugs were from the mod itself and not other installed mods).

 

As far as the long winded description, I would say that a large portion of that is because of the above - there isn't a playable version of the mod out for testing/etc., so for those interested in updates I have been trying to give updates as I have them.  Also, I will likely not post a public test version, since the test version would likely not be a full release and require knowledge/reading/understanding to use.  

As a general update, as per my first line for anyone wondering, after getting the new installation up and working I found that I was having a an issue in compiling the scripts.  I think I know how I can fix it, but haven't had time to get around to it.  

On a better note, though, the mod did not appear to be experiencing any of the CTDs I had previously observed on the clean save, so that's something!

[Skyrim4Waifu]

Off topic. 

 

Someone make the development for cyberpunk 2077 sexual mod? Cause this game is massive but empty. 

[Visio Diaboli]

Just curious, do you think you'll get back to this at some point?

 

No worries if not, it just looked pretty interesting.

[fingerscrossed]

On 12/25/2021 at 11:38 AM, Visio Diaboli said:

Just curious, do you think you'll get back to this at some point?

 

No worries if not, it just looked pretty interesting.

 

The short answer is .. Maybe!  

 

The longer answer is that I did something that I know always gets me in trouble:

I got overly ambitious.

I have, or at least had, a more or less working beta version where you could play out a combat.  It needed some tweaking, still, because numbers.  I got ambitious and decided I'd add the ability to have classes with different abilities, and controllers and worked on getting some of them up and running, but that turned out to be a lot more work than I was anticipating.  I had, at least when I was working on it (and would need to check my notes on how I was handling it) figured out how to do what I wanted (Create an amount of custom classes, i.e., Assassin, Warrior, Conjurer, etc., have each of them have their own unique skills and abilities, and have a way for people to add their own custom classes to the framework).  As I started creating the custom classes, this turned into a lot of work on the scripting end, particularly for NPC controllers (the scripts used to determine what an NPC does).

 

Knowing what goes into making a "class" in this context (Script, scenes, spells, etc.), it's a lot of kind of boring rote work I'm not really interested in.

 

I have considered going back and cleaning up the first crack at H-Combat, where the "classes" are essentially: Male, Female, and Creature.  I'd need to take this, remove some hooks, add a few other hooks and functionality in (Right now I just had it set up for using essentially console commands to start combats/etc.), and then maybe release it.  I liked the concept and, honestly, even with just the kind of base functionality it was pretty fun, so I think at least some people will enjoy it.

 

When that will/may happen ... I don't know.  At least one of my personal mods is acting up and I'm trying to get it troubleshot in-between being slammed at work.

 

If there's a lot of interest in this, I might be able to put it on the chopping block.