Operand Posted March 15, 2020 Share Posted March 15, 2020 Sex Appeal Framework View File A framework to diversify sex appeal and forget about shallow charisma measurements Disclaimer Spoiler Also, this is really my first mod I considered seriously. And it's built entirely via F4Edit mostly in F4Edit with some painful intervention in CK (god damn that thing). And I often have no clue about what I'm doing. And some stuff may not work. And if you are en experienced modder and the idea is interesting to you and you have some time to help me with my questions - please drop me a message. If you are a modder that is interested in integrating SAF - you have the support to the best of my abilities! What Is It Sexual Appeal Framework (SAF) is a resource that can be used to bring the "Sexual Appeal" term into the game. Key point is: it is a resource. By itself it will do almost nothing The idea is that by now almost every mod that deals with sexual appeal of a character at best implements its own way of addressing it or at worst just relies on the charisma S.P.E.C.I.A.L; It's about time that's changes Features SAF attempts to integrate into the game world and seemingly affect RP experience for the player. It is not a battle mod and I doubt I will ever make any sort of combat-related effects to it (though I'm open to suggestions, provided those are in line with the mod vision and are interesting enough). Currently, there are several following features: Game world SA effects Currently, only drugs effects are supported. Consuming drugs will penalize the SA values for quite some time. For the RP purpose the duration of these penalties are not tied to the duration of the original drug and are longer - you can expect that the appearance takes a much harder toll from drugs than the internal body health. This can be disabled in MCM. Tagging This allows to define your items SA effects. You can specify any SA attribute with a value and then equipping this item will grant the corresponding bonus to the specified attribute. You can rename an item normally on a workbench or use Rename Anything to do it on the fly. More about tagging feature you can read in a dedicated post. Persuasion effects Allows SAF to add a modifier to game internal values for persuasion success chances. The idea behind this is that Charisma still governs the base check but with SA it will have more (or less) "weight". For positive SA, easier speech checks are affected more and harder checks are affected less. For negative SA - in reverse, i.e. harder checks will be affected more and easier checks - less. Integration with other mods Some of the mods can be affected by SAF (or, in reverse, SA values can be influences by something in those mods). At the current version, v1.12-beta, Hardship and SA Attributes are supported, (see recommended mods section). The effects are: SA Attributes: Sexual wear will affect SA for certain body / face parts. Oral wear will affect lips / tongue SA; vaginal wear will affect vagina / belly SA; anal wear will affect butt / back SA. Half of oral wear SA modifier will be applied to face SA; quarter of vaginal & anal wear will be applied to body SA Hardship: crossing certain thresholds of total SA score will change the appearance. The scale is done by total SA as follows: -100..-50 ugly; -50 .. 50 plain; 50 .. 100 good looking Requirements Sex Appeal Framework (SAF) will need all DLCs installed F4SE - without that tagging feature will not work (and further updates will rely on F4SE) Installation Just install it with any mod manager If you see conflicting files for LL_Fourplay - it doesn't matter which to load first, the library should be identical (it is packed in SAF in case you don't have any other mods using it) Updating Please pay attention to the changelog. Depending on that: If nothing is mentioned about clean save, you can proceed with just installing the update as is If it is stated that clean save is required, then you will need*: Before updating, load your existing save with SAF and in the MCM chose "Uninstall" Wait till SAF is uninstalled and then save your game Uninstall SAF with your mod manager of choice. Load your game (ignore the prompt about missing file "SexAppealFramework.esp" ) and save it again Download the updated SAF version and install it with your mod manager of choice Load your game and wait till SAF installs itself. Check that the version corresponds to the updated one. Spoiler * Unfortunately, I'm not aware of a way to create easy in-game update tool (i.e. self-updating feature). SAF has many objects that are persistent and retain their state so simply restarting quests doesn't help. If you're a modder who knows how to solve this - I'd welcome your support. Important: the mod is in beta stage which means that errors and mishaps are to be expected. For that reason for all beta builds of the mod the debug level is set to the maximum by default. If you don't want that, you can use MCM page to change the debug level. It is recommended to keep it at least at level 40 because the mod is still in beta and if things go wrong it will not be possible to retrieve useful information from the log when debug level is low. Framework Module (SAF) Main requirement for anything else. Defines all attributes, dependencies between them, magic effect, object mods etc. What Is "Sexual Appeal" (SA) SAF defines SA as a multilayered set of actor values which can be used to describe the appeal of a certain part of the body or face. Multilayered idea means that there are several aggregating actor values which are inheriting the influencing values of the underlying actor values. At the moment, it is implemented as: Spoiler Total Sexual Appeal (AVIF XX000800) : A total score of the sexual appeal. Influenced by Body Sexual Appeal and Face Sexual Appeal Face Sexual Appeal (AVIF XX000801) : A total score of the face sexual appeal. It's comprised of the following actor values: Face Skin Sexual Appeal Eyes Sexual Appeal Eyelashes Sexual Appeal Brows Sexual Appeal Nose Sexual Appeal Lips Sexual Appeal Teeth Sexual Appeal Tongue Sexual Appeal Ears Sexual Appeal Chins Sexual Appeal Neck Sexual Appeal Hair Sexual Appeal Cheeks Sexual Appeal Body Sexual Appeal (AVIF XX000802) : A total score of the body sexual appeal. It's comprised of the following actor values: Body Skin Sexual Appeal Arms Sexual Appeal Palms Sexual Appeal Fingers Sexual Appeal Legs Sexual Appeal Hips Sexual Appeal Ankles Sexual Appeal Feet Sexual Appeal Butt Sexual Appeal Belly Sexual Appeal Back Sexual Appeal Crotch Sexual Appeal Breasts Sexual Appeal Nipples Sexual Appeal Shoulders Sexual Appeal Waist Sexual Appeal So there are 32 attributes in total of which 13 are underlying for the face and 16 are underlying for the body. On the mod start-up, the in-built way to enforce the dependency between the attributes will engage. It will enforce the following dependency table: Spoiler All face-related attributes will gradually add to the face SA All body-related attributes will gradually add to the body SA Face or body aggregating attributes will follow the table: +10 to total sex appeal for values 0..30 +20 to total sex appeal for values 30..55 +30 to total sex appeal for values 55..75 +40 to total sex appeal for values 75..90 +50 to total sex appeal for values 90..100+ This is mirrored for negative attribute values (i.e. the scale is the same from 0 to -100 and the influence is negative) Attributes Rules Accessibility: the attributes should only be manipulated via SAF API calls. If you attempt to do so otherwise, SAF will restore the values. For instance, calling Actor.SetValue() or using console equivalent will do nothing and the attribute value will be restored Dependencies: when modifying an underlying layer attributes, their influence will be cascaded up to the main SA attribute. SAF API calls will reflect that in the respective returned values. Boundaries: The attributes are bound to change between -100 and 100. If you will try to use SAF API to modify it beyond bound, it will truncate the value to the corresponding limit (100 for positive, -100 for negative values) How To Integrate SAF? This section is only meaningful for modders. Spoiler Overview Short story - you can read the API methods documentation in the SAF_Kernel script. A quick example: Quest SAF_QUST_Kernel = Game.GetFormFromFile(0x000014C0, "SexAppealFramework.esp") as quest ScriptObject SAF_Script = SAF_QUST_Kernel.CastAs("SAF:SAF_Kernel") if !SAF_Script ; API was not loaded - react on it somehow return endif Var[] updateArgs = new Var[3] updateArgs[0] = target updateArgs[1] = attribute updateArgs[2] = modifier float value = SAF_Script.callFunction("modifyAttributeValue", updateArgs) as float ; Do something with value / react on change / etc (This section of this post will be updated with more information) Supported API methods (v1.0.0-beta) float Function getAttributeValue(Actor target, ActorValue attribute, bool threadSafe = true, string callerId = "Default") Gets the value of attribute for target. float Function getSexAppealValue(Actor target, bool threadSafe = true, string callerId = "Default") Get the value of Total SA for the target float Function getSexAppealFaceValue(Actor target, bool threadSafe = true, string callerId = "Default") Gets the value of Face SA for the target float Function getSexAppealBodyValue(Actor target, bool threadSafe = true, string callerId = "Default") Gets the value of Body SA for the target float Function modifyAttributeValue(Actor target, ActorValue attribute, float value, bool threadSafe = true, string callerId = "Default") Modifies the attribute for target by value float Function setAttributeValue(Actor target, ActorValue attribute, float value, bool threadSafe = true, string callerId = "Default") Sets the attribute of target to value float Function getModifierValue(Actor target, ActorValue attribute, float modifier, bool threadSafe = true, string callerId = "Default") Gets the actual value of the modifier that will be applied if attempting to change the SA value by that modifier. Usage of this method is highly encouraged (or maybe it's even a necessity) to avoid bugs when modifying SA values with the intent to later revert those changes. Supported API events (v1.0.0-beta) OnAttributeUpdate Fired every time the attribute was changed. Will receive the following data: [target, attribute, oldValue, newValue, callerId] Target: the actor which has their SA attribute changed Attribute: the attribute of target that was changed oldValue: the value of attribute of target before change newValue: the value of attribute of target after change callerId: calling thread name Additional notes Notes on caller id: It will be transferred through all calls in SAF and used in debug tracing It will be used as an identifier for the thread that called the method in case thread safety is enabled Even for same callerId, calls are distinct: if there are several calls with the same callerId, their order is respected in the queue Notes on thread safety: Setting to true means all the calling threads will wait till existing update is done. Trade off - slower operations. Setting to false will generally work faster, but may lead to unpredictability. Not recommended in concurrent scenarios. Threads will be put into the queue which means the order of their calls will be respected Threads will wait for a maximum of 30 seconds seconds after which they will proceed even if the queue was not empty Threads queue is global for SAF, not for a method, meaning that other thread safe calls will wait in the same queue Limit for the queue size is 127, if it gets larger, new operations will be rejected As the thread is global for SAF, so is the limit, including core SAF stuff, meaning doing a loop with a thread-safe call is usually a bad idea Q&A Spoiler Q: What about UI, will you add some UI to SAF? A: I will .. eventually. If I will get support from people from mods like <Pipboy Tabs> or <Active Effects>. I recommend the latter for now if you want to use SAF and see your effects & SA values. Q: I want to integrate SAF into my mod A: Please drop me a message. I'm not a modder but I might be of some use to you. Q: I want that SAF is integrated with mod <insert name here> A: If you're not an author of this mod, please still let me know about what ideas you have in regards to what SAF can do for that mod. I might try to implement that. Q: Is SAF script-heavy? A: It is. Up to the point I had to implement thread safety and thread queuing. It does support an extensive debug options though so if you encounter a bug - chances are - you can do a bug-report that I will be able to understand and quickly fix it. Q: Is SAF safe to install mid-game? A: It should be. I'm unaware of why would it not be safe to do that Q: Is it safe to uninstall SAF mid-game? A: It should be, but I'm working on the ways for native uninstallation functionality. Q: Will you add more effects for SA? A: Eventually. Most likely via integrating with other mods which will provide a meaningful way for SAF to play into game world. By itself SAF was never designed to provide any "bonuses" - it's about SA (sex appeal), not super-powers that magically give PC some terminator-like abilities. So the SAF makes the more sense & presence the more "social" mods is it integrated with. Q: Why is it "beta", will it break my game? A: It can break your game. I can imagine it running into deadlocks at some point, but the damage should be limited to SAF functionality. Though on heavy scripted saves it can run into troubles. It is beta because it was not tested by enough people. When it will be and I have feedback from the esteemed modders here - I will make the adjustments so it's no longer in beta state. Recommended mods I am (trying to) working on some sort of UI integration for the SAF/SAFI because it's difficult to see the attributes and effects in-game without resorting to console commands. Until I figured out how to do that, I strongly recommend using UI mods, such as Active Effects - it might not be what I have in mind but it provides a good way to see the current state. Since version 1.6 SAF supports tagging which means that renaming items on the fly could come handy. I like Rename Anything for doing that. Mods which SAF is currently integrated with. None of these are mandatory, but if detected, SAF will gracefully attempt to integrate with them: Sex Attributes Hardship Future plans .. and limits of what sort of integration is possible from within SAF This section is mostly meaningful for modders. But if you have ideas - please share! Spoiler I am planning to gradually expand influence that SA attributes have. However, much unlike combat modes, it is not easy to do. SAF is intended to be social, meaning - it's not possible to just tweak some values / add perks and weapons here and there to have an impact. There have to be other mods which take advantage of what SAF has to offer. To have a good and consistent integration of SAF, there have to exist two things: Input integration. This means "game world" --> "SAF" sort of thing. Something in the game world that influences SA attributes / behavior. This is usually easy because I'm mostly limited to the ideas here regarding what can influence SA values / effects. Thankfully, in vanilla game there are a lot of triggers and events to chose from. And this is exactly why the tagging feature was created - to allow input integration with absolutely any armor mod one could imagine. Now, for the part where other mods can influence SAF - this is tricker. Because for that the mods should provide some sort of API, ideally a clean one, for me to attach to and react. Some mods do this very well, some don't. An example of a good one is Sex Attributes - it emits events that I can connect with. Output integration. This mean "SAF" --> "game world" sort of thing. Once the actor has some SA attributes defined (and maybe, in case of PC, worked hard to get those) - it is natural to expect that to have some visible effect on the game world. Obtaining SA for the sake of SA is pointless unless you're a hardcore RP person. This is where the biggest limitation I mentioned above comes - SAF needs other mods to enable this game world influence. This means I will need to integrate with those mods and this is the most challenging task if mods don't provide an API to do so. The core principle here is - to not break the external mod + not make it a hard dependency of SAF. So far, not many mods I found that I can do such integration on my own. And this is all on top of an elephant in the room - I also would need a permission from the mod author to proceed even if I have found a way to do it. An example of the mod I can do an output integration relatively fine is Hardship. That is because its appearance value is designed to be defined rarely (if not once) and it's a self-contained thing - it doesn't influence anything but dialogues there. Threrefore it's possible for me to write into it from SAF and it will not break scripts in Hardship / introduce any quirks in places like MCM. An example of the mod where I can't do similar to Hardship stuff is - FP Harassment. Much like Hardship it introduces a lot of global variables that I'm tempted to change from SAF, but that can potentially break the mod because those variables are also write-able by the mod itself (like gradual approach chances or MCM setup). This means that the clean way of integrating SAF with FP Harassment would be from within that mod itself - for instance introducing another factor for increasing/decreasing chances of approach depending on SA values. But this is not something I can do myself since I do not own that mod. This is where the limitation of what I can do from within SAF lies. Known Issues If trying to get SA values in a non thread safe ways, it is possible to catch SAF mid-update especially if several update processes were fired with no delay. It is not harmful, though, because eventually (1-2 seconds) those updates will always catch up because SAF ensures consistency via threads queue If trying to set SA values in a non thread safe ways, it can break things in theory (for now). I will work on eliminating ways to do it but I can't account for everything at once. SAF persuasion feature may conflict with mods changing persuasion mechanics, like Binary Speech Checks. In this case I recommend to disable the persuasion feature. Propagation delay. Yes, this is a thing, especially on a heavily modded games. Bad news are - your SA values are likely to arrive with a noticeable delay (sometimes in a measure of several seconds - enough for you to see it in your pip-boy or console if you closely track them). Good news are - it is consistent, meaning that whatever changes should happen - will happen. Read: if you think that SA change "didn't work" - wait a bit. It will arrive. Tested on my game with 300+ mods and every time that was the case. Additional note here: the consistency despite propagation delay is only true when SAF calls are made in a thread-safe way. By default, SAF itself does it this way, but if there will be future mods what integrate with SAF and won't opt in for thread-safety (since it's much slower) - all bets are off. (Console setav / getav and Co are non-thread safe ways to work with SA) Submitter Operand Submitted 03/15/2020 Category Modders Resources Requires F4SE, All DLCs Link to comment
Operand Posted March 15, 2020 Author Share Posted March 15, 2020 Please let me know if you have an idea of the mod that can be integrated with SAF! (I will try to do the integration patch so long as it's within my limits of knowledge to do so) Link to comment
Operand Posted March 15, 2020 Author Share Posted March 15, 2020 SAF Tagging Feature Starting from version 1.6 there is an option to integrate SAF with almost any armor mods without the need to edit those mods in any way. You can now simply tag the item that you want to modify your SA directly in-game and it will allow to influence your SA. Purpose & "Why" One of the few things that are problematic when introducing new actor values is to ensure integration with the game world. An easy approach is to just add some modifiers to existing game items, for instance, but that means those items need to be modified directly before the game loads. Therefore if we want to integrate with any potential armor mod, this is an impossible task. Another reason is that different people see different things as attractive and thus while one user will give a solid 10 on SA for those skimpy vault suits, another user will say "meh". Thus it is important that SA values are configurable, ideally in a dynamic way directly in-game. SAF allows attaching armor mods which affect SA to armor items, but that is static and the armor mod slots must be predefined making it impossible to go that route for an arbitrary installed outfit mods (well, that is - until F4SE will have a functionality for adding armor mod slots). And then there are replacers. Some users have a skimpy replacer installed while other users don't, meaning that even if SAF will try to predefine some SA modifiers on an item, there's no guarantee that same item will look the same for different users. SA is all about looks after all. Some context Sex Appeal Assembler: a new buildable item in your settlements in the "Crafting" category. This is designed to be a multi-purpose workbench related to SAF, but currently only tagging option is supported Tag: it is an addition to the name of an item. All tags follow a specific format (see below) and when added to the item name, allow to modify the specified SA attribute. Adding tags: adding a tag is simply renaming an item and placing the tag somewhere inside the item name. It doesn't matter where the tag is placed. There could be also multiple tags placed to the item. Renaming is possible regularly via armor workbench and via mods like Rename Anything. Tags Structure Tag must be in the following schema: [TagName +Value] or [TagName -Value] I.e.: TagName, followed by exactly one space, then by a sign (plus or minus), then numeric value; all enclosed by open tag '[' and closing tag ']'. All of this is mandatory. TagName is a name that specifies which SA attribute will be affected by the tag. The full list is: SA:All SA:Face SA:Body SA:Hair SA:FaceSkin SA:Eyes SA:Eyelashes SA:Brows SA:Nose SA:Lips SA:Teeth SA:Tongue SA:Ears SA:Chins SA:Cheeks SA:Neck SA:BodySkin SA:Arms SA:Palms SA:Fingers SA:Legs SA:Ankles SA:Feet SA:Hips SA:Butt SA:Waist SA:Pussy SA:Breasts SA:Nipples SA:Shoulders SA:Belly SA:Back Where the corresponding SA attribute is self-explanatory. You can add up to 8 tags into the name. Please note that this feature was never designed to be a perfect parser and therefore the assumption is that the usage of it is non-hostile. If you will try to break it - you can (things like unbalanced tags, wrong characters order etc is not accounted for). Numeric value can be float with the decimal point, but that will be truncated. SAF will try to keep the attribute bound to its range -100..100 after modification as usual, starting from version 1.7 the value itself is bound by the corresponding setting in the MCM (default 10, maximum 20). If the specified value exceeds the allowed maximum, the tag will be discarded completely. SAF will always try its best to gracefully handle edge cases, but it can fail. If, however, it was able to handle the case, it will just skip the malformed tag and do nothing about it. Examples Some names examples could be 'Sexy Outfit [SA:Arms +8][SA:Hips +5]' or 'It gives me [SA:Back +1] and [SA:Butt +3]' - hopefully, this illustrates the feature well enough. How To Use It In order to use this feature, you will need: Go to MCM and enable it (it is disabled by default) Go to one of your settlements and build a Sex Appeal Assembler there (category: Crafting) Activate the assembler and when prompted, select the option for tagging Place the item you want to enable tagging on into the assembler. Warning: the original is destroyed in the process; after you've placed the item the assembler will close the inventory menu after which your item will reappear in your inventory with its default form name. This item (and it only) will be eligible for tagging after that, other items of that form will be not, you will need to repeat the procedure if you want to get another item of that form. Rename your item as you see fit, adding tags as described above Limitations As it's already stated above, tagging is not a regular expression parsing and it will never be. I need to strike balance between performance, complexity and stability. Thus malformed tags can cause problems. Although it is possible to make this work on NPC (you will need to enable the corresponding MCM option), it is not recommended because that will make much more instances of persistent objects that will be handled by SAF. In short: performance may be at risk. 8 tags per item (though most likely the name length will allow for a most 3-4 tags) Scripted items may fail to work properly on assembler. For instance, some DD items may fail. I've checked that collars/cuffs work, though. Thread-safety. Tagging is implemented with concurrency in mind which means changes to SA attributes are propagated potentially with some delay. This means equipping/unequipping item in quick succession (10-20 times) can cause problems especially for the items with multiple tags. Yet again - don't do this, don't shoot yourself in the leg. Link to comment
NoJoker Posted March 16, 2020 Share Posted March 16, 2020 AWKCR requirement is actually BAD, hope you eliminate it in the future, it's outdated and pretty much no new armor mods requires AWKCR on Nexus and I play with Horizon, which directly conflicts with AWKCR too. 2 Link to comment
Operand Posted March 16, 2020 Author Share Posted March 16, 2020 9 hours ago, NoJoker said: AWKCR requirement is actually BAD, hope you eliminate it in the future, it's outdated and pretty much no new armor mods requires AWKCR on Nexus and I play with Horizon, which directly conflicts with AWKCR too. The requirement is only for the demo "integration" module though. Maybe those who have strong opinions on the topic can elaborate why? I'd like to hear someone with the expertise in regards to what's wrong with AWKCR - so I could at least avoid same issues in this mod. Link to comment
NoJoker Posted March 16, 2020 Share Posted March 16, 2020 6 hours ago, Operand said: The requirement is only for the demo "integration" module though. Maybe those who have strong opinions on the topic can elaborate why? I'd like to hear someone with the expertise in regards to what's wrong with AWKCR - so I could at least avoid same issues in this mod. It's very bloated, adding unneeded stuffs into the game, it was supposed to be a simple keyword framework ends up being a patch hell, armor mod authors supposed to use AWCKR as a base, but as of 2019 and 2020, not a single author that I know of has made AWKCR as a requirement, so people most like ditched the mod as well. By eliminating AWKCR as a requirement, you open up options for users to patch their mods without having to download another huge mod which causes another batch of conflicts. 2 Link to comment
Operand Posted March 16, 2020 Author Share Posted March 16, 2020 12 minutes ago, NoJoker said: It's very bloated, adding unneeded stuffs into the game, it was supposed to be a simple keyword framework ends up being a patch hell, armor mod authors supposed to use AWCKR as a base, but as of 2019 and 2020, not a single author that I know of has made AWKCR as a requirement, so people most like ditched the mod as well. By eliminating AWKCR as a requirement, you open up options for users to patch their mods without having to download another huge mod which causes another batch of conflicts. Could you explain more what means "bloated" ? I explored that mod quite thoroughly and I did not find a lot of things. All it does it .. well, what it is supposed to do - attaching keywords to armor items and extending the armor mods. But I'm not a modder in any capacity so I can't for sure what's wrong and what's not. 1 Link to comment
Nebuchadnezzer2 Posted March 17, 2020 Share Posted March 17, 2020 12 hours ago, Operand said: Could you explain more what means "bloated" ? I explored that mod quite thoroughly and I did not find a lot of things. All it does it .. well, what it is supposed to do - attaching keywords to armor items and extending the armor mods. But I'm not a modder in any capacity so I can't for sure what's wrong and what's not. I assume they refer to the 'paints' options, and workbenches. Much like yourself, I've been a little confused about people claiming it's 'bloated'. 1 Link to comment
afa Posted March 17, 2020 Share Posted March 17, 2020 First what alternatives we have besides AWKCR? I genuinely want to know, I don't really follow normal mods from nexus that closely, so not too up to date with the latest and greatest. Second AWKCR in my experiences is not bad, but do have some oddities. It took some liberty with assigning equipment slots, occasionally you will run into equipables taking up more slots than their original counterpart. The addition of the workbenches are slight annoyance in the beginning time, but minor in the long run. The paint and mesh variation is kind of a double edge sword, the good part is it let you customize details, but once you mess around with it you run into stacking/inventory management issues. Mostly minor annoyance, from what I have encountered. Third is it is still a requirement for Devious Device. I know DD isn't the most popular in Fallout, but quite a few mods do explicitly support it. Link to comment
NoJoker Posted March 17, 2020 Share Posted March 17, 2020 1 hour ago, afa said: First what alternatives we have besides AWKCR? I genuinely want to know, I don't really follow normal mods from nexus that closely, so not too up to date with the latest and greatest. Second AWKCR in my experiences is not bad, but do have some oddities. It took some liberty with assigning equipment slots, occasionally you will run into equipables taking up more slots than their original counterpart. The addition of the workbenches are slight annoyance in the beginning time, but minor in the long run. The paint and mesh variation is kind of a double edge sword, the good part is it let you customize details, but once you mess around with it you run into stacking/inventory management issues. Mostly minor annoyance, from what I have encountered. Third is it is still a requirement for Devious Device. I know DD isn't the most popular in Fallout, but quite a few mods do explicitly support it. There are several artificial requirements for Devious Device for some reason(Haven't updated for 2 years), so I managed to get rid of them from the mod in FO4Edit including AWKCR, the mod works fine without them. Link to comment
Operand Posted March 17, 2020 Author Share Posted March 17, 2020 To be honest I'd still like to hear what does it mean "bloated". Because if it's only about paint swaps .. then I'd say it's a stretch. AWKCR doesn't contain scripts, changes not a lot of things as I see it so I'm still curious as of why there is the strong negative feedback (which is what make this valuable for me) Link to comment
EgoBallistic Posted March 18, 2020 Share Posted March 18, 2020 On 3/17/2020 at 3:09 AM, afa said: First what alternatives we have besides AWKCR? I genuinely want to know, I don't really follow normal mods from nexus that closely, so not too up to date with the latest and greatest. The only useful feature AWKCR provides is the INN rules for item sorting, and there are much better solutions for that, like Rudy's Simple Sorter. It's an FO4Edit script that generates a patch based on all the mods in your load order, so it's automatically compatible with everything and doesn't need patches. Which is the exact opposite of AWKCR. On 3/17/2020 at 3:09 AM, afa said: Second AWKCR in my experiences is not bad, but do have some oddities. It took some liberty with assigning equipment slots, occasionally you will run into equipables taking up more slots than their original counterpart. The slot modifications are just completely broken. And it's useless. You can't get around the game limitations: there are only so many slots, and only one item can go into any one slot. On 3/17/2020 at 3:09 AM, afa said: Third is it is still a requirement for Devious Device. I know DD isn't the most popular in Fallout, but quite a few mods do explicitly support it. You can simply remove AWKCR as a master for DD in FO4Edit. AWKCR doesn't provide any useful functionality for it. Literally the only useful thing AWKCR does is the INN rules for mods that sort inventory items by name. Except the way it does it -- by modifying over half the armor and weapon records in the base game -- is just asinine. Everything else AWKCR does is pointless: the item slot/type keywords have no use, the slot modifications have no use, the paint and decal stuff is not just useless, it's game breakingly terrible and introduces tons of incompatibilities with other mods, and the workstations just add clutter when there are already perfectly good workstations that can be used without them. 5 Link to comment
Operand Posted March 18, 2020 Author Share Posted March 18, 2020 4 hours ago, EgoBallistic said: Everything else AWKCR does is pointless: the item slot/type keywords have no use, the slot modifications have no use, the paint and decal stuff is not just useless, it's game breakingly terrible and introduces tons of incompatibilities with other mods, and the workstations just add clutter when there are already perfectly good workstations that can be used without them. @EgoBallistic now that (and the rest) is a valuable piece of information. I think I'm convinced to create a non-AWKCR version of SAFI now, thank you! EDIT: Done in v0.0.9-alpha (SAFI v0.0.5-alpha) Link to comment
g0lden_sky Posted March 19, 2020 Share Posted March 19, 2020 On 3/17/2020 at 3:09 AM, afa said: First what alternatives we have besides AWKCR? From what I know, Crafting Framework coupled with Armor and Clothing Overhaul. I'm not aware of others though I'd be interested in them 1 Link to comment
Operand Posted April 2, 2020 Author Share Posted April 2, 2020 On 3/31/2020 at 11:21 PM, Sauron462 said: I turned the mod and all current addons into a fomod installer to make it easier for people to download. Sex Appeal Framework.7z 105.26 kB · 2 downloads This is a sound idea, though I am not sure how to manage it properly with all the modules (and now - versions). I'm still tempted to do a merge because spending so many ESP slots just for Sex Appeal doesn't looks like a great way of handling things. Link to comment
twistedtrebla Posted April 2, 2020 Share Posted April 2, 2020 Looks promising! I’d be interested in integrating this into attributes and harassment mod, so the player’s appeal can affect various chances. I see that youve done that with patches, and theres nothing wrong with that from my point of view. But it’ll add a lot of tech debt for you, as you’ll have to update your mod when any of the mod for which you have a patch gets updated. Its going to be a lot of work if you can provide examples and guidelines for what values to call, and what value means what, then that would be fantastic! Link to comment
Operand Posted April 2, 2020 Author Share Posted April 2, 2020 On 4/2/2020 at 10:48 PM, twistedtrebla said: Looks promising! I’d be interested in integrating this into attributes and harassment mod, so the player’s appeal can affect various chances. I see that youve done that with patches, and theres nothing wrong with that from my point of view. But it’ll add a lot of tech debt for you, as you’ll have to update your mod when any of the mod for which you have a patch gets updated. Its going to be a lot of work if you can provide examples and guidelines for what values to call, and what value means what, then that would be fantastic! Sure thing. Most of this is described in the main post, but I will try to elaborate more. The framework itself doesn't expect you to "call" anything. That is - it does not provide any API you would need to utilize in your scripts. At its core it simply adds an extended list of Sexual Appeal (SA) attributes. All the rest modules including the integration with vanilla game are only there to enable some ways of manipulating the SA values in a lore-friendly and accessible way. The mod adds 32 different attributes which are divided into 3 main groups: Total SA. This is only one attribute, XX000800. It is designed to aggregate everything else and serve as a total score of the sexual appeal of the character. That being said, it does not mean that it and it alone should play the role in assessing the sexual appeal. Whenever it makes sense - it is totally fine to refer to other attributes. Face SA & Body SA (XX000801 and XX000802 respectively). These are the appeal attributes which are designed to aggregate the SA of the corresponding face or body attributes. They are very similar by design with Total SA in a way that they are a level below it but again act as a total score of the sexual appeal for Face or Body Other SA attributes (XX000803 .. XX0080F for the Face parts / XX000810 .. XX00081F for the Body parts). These are direct values for every included body or face part. The design idea is that body parts SA attributes contribute to the total score of the body SA and face parts SA attributes contribute to the total score of the face SA. Then in turn both face SA and body SA then contribute to the total SA score. As you can see, it's a multi-layered system by design. Of course, you could "call" these attributes similar to the way you refer to your attributes mod from your harassment mod, it would be something like ;Refer to the Face Sex Appeal ActorValue SexAppealFaceAV = Game.GetFormFromFile(0x0200801, "SexAppealFramework.esp") float SexAppealFace = Game.GetPlayer().GetValue(SexAppealFaceAV) - though I'd say, just adding a master and referring it that way directly does the trick for me. But! It's important that nothing actually enforces you to use all of the attributes. If you don't like the complexity of it and think it's a bit much to integrate so many of these attributes into your mods somehow - you can just refer to whichever aggregating attribute you like. For example, using only Total SA. This will effectively leave all the care about attributes dependencies on the SAF side. I would not, however, recommend doing it - because if you just use Total SA then it's likely that you can use Charisma altogether as the sexual appeal measurement. Another option is to use Total SA, Face SA and Body SA. I would say it's a reasonable trade off between complexity and diversity. For the sake of integrity and simplicity, SAF will enforce the dependency table among the attributes to ensure that corresponding attributes properly contribute to their respective aggregating attributes. The table for that I also showed in the main post. Now, for what exactly do you want to use the attributes - it's up to you, really. I say - whenever there is a "situation" where sexual appeal comes into play - it's up to you to decide which attribute to use and how. Keep in mind though, that at least for now, all attributes were designed with the value range of -100 ... +100 in mind. Nothing will (hopefully) break if you would expect values out of these bounds, but natively there is no way to obtain even anything above 70 / below -70 I think. I can give some examples of how I use different attributes in different SAF modules to illustrate: Flirty Commonwealth: has some lines like "Damn, that @ss!" - which I changed so that this line will only appear if the "butt" SA attribute is above certain value XXX Mags: Has the magazine "Tits Today" among others. The bonus that I added to this mag is obviously a bonus to the "breasts" SA attribute. Vtaw utility pack: has clothes which reveal certain parts of the body or emphasize other parts of it. For example, the skimpy hotpants would give bonus to "hips" and "butt" sexual appeal. SAFI adds moddable SA on every vanilla clothing and even armor, but it does so with respect to what the piece of armor/clothing actually does. For example, glasses will allow to enhance eyes SA, left/right arms of the armor will allow to enhance arms sex appeal and so on. As you can see, the only recommendation here is common sense. SAF is a very simple thing and it doesn't offer much by itself. What can I think of for the Sexual Harassment / Sex Attributes? (Those are actually my plans for the future updates for those SAF modules): Replace the "clothed" meaning for the mod. I mean, there are armors out there that are making the characters almost as sexually aggressive as if she was walking around naked (or worse) - so it is only natural that replacing the "clothed" check with SA check would bring more immersion Adding SA penalties for intoxication Removing some dialogue choices according to high/low SA values Introduce temporary penalties to SA according to the level of trauma Introducing checks to the NPC flirting moves which refer to any of the body parts with the check against the corresponding SA attribute Please let me know if you have further questions regarding SAF or if you have ideas for utilizing it and then maybe I can help with suggesting something in that regard. Another thing to add is - since these are real attributes and not global values, all the NPC will have them, which means that in the future SAF might be expanded to allow for the sexual appeal of the NPC to come into play, for example: .. in sexual harassment, if the NPC has higher and higher sexual appeal, it will be progressively harder to resist the approach .. in mods where player themselves are a client for certain activities, they would must pay according to the sexual appeal of the target .. in mods which enable random sex scenes, the probability of an actor being engaged in that could be proportional to their sexual appeal and so on. But those are far-fetching plans because prior to that it's necessary to ensure NPCs can have some stable ways of obtaining their SA. EDIT (randomly found this reply): Quote The framework itself doesn't expect you to "call" anything. That is - it does not provide any API you would need to utilize in your scripts. At its core it simply adds an extended list of Sexual Appeal (SA) attributes is long due. There is a fully functioning API with proper support for both read and write. See the main post, it's documented rather elaborately. 2 Link to comment
twistedtrebla Posted April 3, 2020 Share Posted April 3, 2020 Thanks! I have some questions/comments 2 hours ago, Operand said: The mod adds 32 different attributes which are divided into 3 main groups: Total SA. This is only one attribute, XX000800. It is designed to aggregate everything else and serve as a total score of the sexual appeal of the character. That being said, it does not mean that it and it alone should play the role in assessing the sexual appeal. Whenever it makes sense - it is totally fine to refer to other attributes. Face SA & Body SA (XX000801 and XX000802 respectively). These are the appeal attributes which are designed to aggregate the SA of the corresponding face or body attributes. They are very similar by design with Total SA in a way that they are a level below it but again act as a total score of the sexual appeal for Face or Body Other SA attributes (XX000803 .. XX0080F for the Face parts / XX000810 .. XX00081F for the Body parts). These are direct values for every included body or face part. The design idea is that body parts SA attributes contribute to the total score of the body SA and face parts SA attributes contribute to the total score of the face SA. Then in turn both face SA and body SA then contribute to the total SA score. As you can see, it's a multi-layered system by design. Are the "Sex appeal", "Face Appeal", and "Body Appeal" mere aggregates? or are they "normalized" aggregates? As in, if the max value for FA is 70, and max value for BA is 70, would that make SA max value 140? or normalized to 70 (FA + BA / 2)? As a mod author wanting to use this, this is important. If it's not normalized, that means if you were to add another stat, the aggregated min/max range changes, and that may break things, as a mod may have been coded to expect a certain range. As for using each individual stat, I feel like that's too granular. I can see using FA and BA individually. Trying to think about this from how people normally "rate" others. People sometimes grade other's looks according to their body or face, but I've never heard anyone say "oh shes got a 10/10 ear" ?. It's usually "oh she's got a cute face. 10/10. But shes kind of chubby so her bodys a 6". something like that. When we treat someone nicely cus they have an attractive face, it's usually because of how we see the face as a whole, not each individual parts of the face. Just a thought. I can see a mod using FA to determine how nice/rude they'll act. And then BA to determine how sexually/suggestively someone will act. 2 hours ago, Operand said: Of course, you could "call" these attributes similar to the way you refer to your attributes mod from your harassment mod, it would be something like ;Refer to the Face Sex Appeal ActorValue SexAppealFaceAV = Game.GetFormFromFile(0x0200801, "SexAppealFramework.esp") float SexAppealFace = Game.GetPlayer().GetValue(SexAppealFaceAV) - though I'd say, just adding a master and referring it that way directly does the trick for me. This is what I was looking for ?. Sure, I could just add your mod as a master, but that will make your mod a hard dependency of my mod. When we can, we should make mods modular. With the script example above, mods can use values from your mod, but it'll be a soft dependency - as in it'll still work without your mod installed. So IMO I think thats the preferred way. Also, are you expecting these values to be read-only? Or do you allow or anticipate other mods to also modify these values? If the latter, you should provide an API (a function) to modify values, so that you can enforce a strict range. Otherwise, if Mod A increments a stat by 50, then Mod B increments it by another 50, then Mod C increments by 50 again, you now have a crazy unpredictable range that loses its meaning. With an API, you can enforce it in one place, and other mods dont have to worry about range going out of control, as long as they stick with the APIs Link to comment
Sauron462 Posted April 3, 2020 Share Posted April 3, 2020 9 hours ago, Operand said: This is a sound idea, though I am not sure how to manage it properly with all the modules (and now - versions). I'm still tempted to do a merge because spending so many ESP slots just for Sex Appeal doesn't looks like a great way of handling things. To make a merged ESP for SAF, it would be best to make a merge of ALL addons (up to you to decide to merge SAFI) so that the plugin would require all current mods that support SAF. Link to comment
yayuuuhhh Posted April 3, 2020 Share Posted April 3, 2020 Is there any console command(s) to manually modify the value(s) for BA and FA? I'm using modded armor and I'd like to manually adjust to my taste. Any help would be appreciated :3 Link to comment
Sauron462 Posted April 3, 2020 Share Posted April 3, 2020 3 hours ago, yayuuuhhh said: Is there any console command(s) to manually modify the value(s) for BA and FA? I'm using modded armor and I'd like to manually adjust to my taste. Any help would be appreciated :3 player.addperk xx000820 - xx00082F? Link to comment
Operand Posted April 3, 2020 Author Share Posted April 3, 2020 7 hours ago, twistedtrebla said: This is what I was looking for ?. Sure, I could just add your mod as a master, but that will make your mod a hard dependency of my mod. When we can, we should make mods modular. With the script example above, mods can use values from your mod, but it'll be a soft dependency - as in it'll still work without your mod installed. So IMO I think thats the preferred way. I mean, yes, but here is the good moment I would ask myself - "will my mod X ever be designed to work without mod Y" (as in - will Sex Harassment ever be designed to work without Sex Attributes). It's very, very likely that it won't and even if it will - that would be such a major change that it will require a release of a new major version which makes it so that backward compatibility is no longer our concern 7 hours ago, twistedtrebla said: Are the "Sex appeal", "Face Appeal", and "Body Appeal" mere aggregates? or are they "normalized" aggregates? As in, if the max value for FA is 70, and max value for BA is 70, would that make SA max value 140? or normalized to 70 (FA + BA / 2)? As a mod author wanting to use this, this is important. If it's not normalized, that means if you were to add another stat, the aggregated min/max range changes, and that may break things, as a mod may have been coded to expect a certain range. They aren't normalized. Contribution is done directly, although not on the scale as you have written. The reason they aren't normalized is to make it a bit more immersive (I give her boobs maybe 6/10, but man that ass is 10+! .. leading to overall score being good because one attribute compensates for another). Also, the max value is not 70, it's just with all the SAF modules installed and maxed out conditions (i.e. no radiation, with all the specific perks, chems, armor mods, magazines etc etc) - it is a soft cap. If more mods are integrated which add to opportunities of gaining SA - it will obviously increase. I would like to repeat the main post table here: All face-related attributes will add +1 to the face sex appeal for each 13 points starting from 10 to a maximum of +7 All body-related attributes will add +1 to the body sex appeal for each 16 points starting from 5 to a maximum of +6 Face or body aggregating attributes will follow the table: +10 to total sex appeal for values 0..30 +20 to total sex appeal for values 30..55 +30 to total sex appeal for values 55..75 +40 to total sex appeal for values 75..90 +50 to total sex appeal for values 90..100+ This is mirrored for negative attribute values (i.e. the scale is the same from 0 to -100 and the influence is negative) It total, this allows face sex appeal to be in range -91 .. +91; body sex appeal to be in range -96 .. +96 and total sex appeal to be in range -100 .. +100 So if the face-related SA (such as eyes or brows or lips etc) is within range, of 11 to 24, it will add +1 to the face SA. And then +1 for each additional 13 points. Up to a maximum contribution bonus of +7 (at the value of 91+) And if the body-related SA (such as butt or hips or arms etc) is within range, of 6 to 22, it will add +1 to the body SA. And then +1 for each additional 16 points. Up to a maximum contribution bonus of +6 (at the value of 96+) Finally, there is a contribution that the face and body SA do to the total SA. it's exactly as in in the table above. Example - if the face SA is 65 and body SA is 25, then the bonus from that will be 30 + 10 = 40 As you can see, to get to influence total SA it is first necessary to raise body / face SA which makes it very hard for an individual attribute to shift total SA in any noticeable way. 7 hours ago, twistedtrebla said: As for using each individual stat, I feel like that's too granular. I can see using FA and BA individually. Trying to think about this from how people normally "rate" others. People sometimes grade other's looks according to their body or face, but I've never heard anyone say "oh shes got a 10/10 ear" ?. It's usually "oh she's got a cute face. 10/10. But shes kind of chubby so her bodys a 6". something like that. When we treat someone nicely cus they have an attractive face, it's usually because of how we see the face as a whole, not each individual parts of the face. Just a thought. Yes, granularity is in-depth here. Idea, though - is not to make it "oh, she has great ears" - but to - first, let the negative values of this attributes mean something (what if one of the ears is missing?) and second - let it so that the appeal of it does what it do in real life - contribute to the overall perception of attractiveness. Perhaps it will indeed never be a situation that the appeal of the ear will mean anything (though, you know - I play an elf and maybe it will ? ) but that's not to say the same about other parts - such as eyes, lips, brows and so on. SAF doesn't require you to care about individual attributes though. As I mentioned, if you don't like individual parts, you can just limit yourself to working with face / body SA. Though I gave some examples above where referring to individual SA attributes makes great sense and immersion. 7 hours ago, twistedtrebla said: Also, are you expecting these values to be read-only? Or do you allow or anticipate other mods to also modify these values? If the latter, you should provide an API (a function) to modify values, so that you can enforce a strict range. Otherwise, if Mod A increments a stat by 50, then Mod B increments it by another 50, then Mod C increments by 50 again, you now have a crazy unpredictable range that loses its meaning. With an API, you can enforce it in one place, and other mods dont have to worry about range going out of control, as long as they stick with the APIs Other mods are so far free to do whatever they want to. It's a normal AVIF and there's no reason why wouldn't it not be modified. Idea is that if someone wants to shoot themselves in the leg - it's not my place to stop them (at least not yet) As for enforcing and writing API - I might .. if I would know how to create and API that other mods would use. So far I'm not even capable of recompiling scripts that are using external APIs like AAF (the compiler just breaks there - I used both CK and Caprica). Link to comment
Operand Posted April 3, 2020 Author Share Posted April 3, 2020 6 hours ago, yayuuuhhh said: Is there any console command(s) to manually modify the value(s) for BA and FA? I'm using modded armor and I'd like to manually adjust to my taste. Any help would be appreciated :3 Type in console: help SAF_ 4 AVIF It will show all the attributes available. See which HEX codes (will look like XX000800) are there and which you want to modify. Type in console: player.modav <attribute HEX code> <desired value> Link to comment
EgoBallistic Posted April 3, 2020 Share Posted April 3, 2020 1 hour ago, Operand said: I mean, yes, but here is the good moment I would ask myself - "will my mod X ever be designed to work without mod Y" (as in - will Sex Harassment ever be designed to work without Sex Attributes). It's very, very likely that it won't and even if it will - that would be such a major change that it will require a release of a new major version which makes it so that backward compatibility is no longer our concern That's fine if you are the author of both mods, like TwistedTrebla who is the author of both Sex Attributes and Sex Harassment. But as a mod author I don't want to make my mod require another mod for two reasons: users might not want to use the other mod, and if the other mod gets taken down or stops being updated it will cause me a lot of headaches. As an example, my mod AAF Violate interacts with nine other mods, not including animation packs or AAF itself. None of those other mods are hard requirements, and that's how I want to keep it. If you want your framework to be used by other modders, you need to design it so it can be used as a soft dependency. Sex Attributes is an excellent example of how to do this. Everything a third-party mod needs can be accessed via CallFunction() or GetFormFromFile(), so it can be used with no hard dependencies and be entirely optional. And I don't want to seem like I'm piling on, but your approach of making patches for other people's mods is probably going to cause problems at some point. Redistributing modified versions of other authors' plugins and scripts without permission is technically not allowed, although most mod authors on LL are pretty easy going about that kind of thing. More importantly, if one of your patches breaks someone else's mod, you're going to hear about it. 2 Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now