- Site Map >
- Modding and Creation >
- Sims 3 Creation >
- Modding Discussion >
- Group conversation question
- Site Map >
- Modding and Creation >
- Sims 3 Creation >
- Modding Discussion >
- Group conversation question
Replies: 8 (Who?), Viewed: 582 times.
#1
31st Jul 2020 at 4:15 AM
Group conversation question
Does anyone know what causes the relationship penalty when sims do romantic socials while in a group conversation? I'm working on a mod for committed polyamory (I've talked to a couple people about it over on the NRaas forums, since I needed advice on making it work with Woohooer; I just have a different username there) and I'd like sims to not mind PDA in a group conversation if they're in polyamorous relationships with the sims involved. I've been looking, but I'm not sure what to edit/if it's possible to prevent this.
Advertisement
#2
31st Jul 2020 at 6:24 AM
And a related question since I've been scouring the forums for info on this for the last couple days and not found much - is Sims MX's answer here the most complete description there is of what the contents of the SocialData XML/the fields of a SocialData object are? It's definitely excellent and the only reason I was able to make my social interactions at all, but I'm trying to understand some things it doesn't cover.
#3
31st Jul 2020 at 10:58 AM
Okay, I realize these multiple posts may be annoying but I just found the answer to my own question (the second one, at least) again so here it is for future reference: The SocialManager under Sims3.Gameplay.Socializing contains the key to what appears to be all the XML tags. I know how to set jealousy levels for custom interactions now! And make their availability dependent on known traits without using the test function! I'm even slightly less baffled by LHS rules, it's amazing!
#4
31st Jul 2020 at 2:14 PM
Posts: 3,856
Thanks: 8449 in 67 Posts
Hey no problems about the double posting! Sharing your progress in searching for an answer is totally okay It would be different if you were bumping the thread with question marks that would be a whole different story :p
Regarding this though:
IIRC there was a way to reset this variable wise. Especially since Nraas also seems to have a boolean (I believe) that turns off the entirety of the jealousy stuff. So it must be possible somewhere :p I'll look into it a bit deeper for you as well in the meantime!
Regarding this though:
Quote:
I'd like sims to not mind PDA in a group conversation if they're in polyamorous relationships with the sims involved. |
#5
31st Jul 2020 at 2:54 PM
Quote: Originally posted by Lyralei
Sharing your progress in searching for an answer is totally okay |
Awesome, I want to leave some help behind for the next person searching the same keywords I tried to.
I actually have finally got the jealousy handled! Chain_Reaction suggested I stop Woohooer's jealousy code from running by just turning it off from the menu like you say, and then since Woohooer already shuts down EA's jealousy that leaves mine as the only jealousy-handling mechanism still standing.
It took some finagling, but as of last night everything to do with jealousy and establishing multi-partner committed relationships outside of EA's system seems to work! But the negative reactions I'm still getting are independent of jealousy - they're just a small relationship hit that happens if 3 sims are all talking to each other and 2 get romantic, because the third finds that rude If you don't make the flirters stop the PDA-disliking one will walk away in a mild huff, and it barely dings their relationship but it bothers me to see when they're supposed to all be together. I probably wouldn't even have noticed if I hadn't been testing my jealousy code the way I was (no autonomy, needs frozen, makes multi-sim conversations way more sustainable than normal).
From my trawling through the code since my first post, I think the answer might be something to do with ThirdPartyRespondToSocial or Conversation.IsSuitable or the LHS rules from the SocialData table, since those all deal with multi-sim interactions and how a third party feels about what the other two are doing; but I haven't gotten much farther than that.
#6
1st Aug 2020 at 9:24 PM
Last edited by lizcandor : 2nd Aug 2020 at 12:06 AM.
Okay, here's where I'm at on this - no success yet but maybe writing out what I've learned as I trace the calls will help me understand.
And I just realized this is getting long, sorry! Will break it up by finishing in a new post.
I think the method that makes sims in a group conversation who aren't part of whatever interaction was done react to it is SocialInteractionA.MakeThirdPartiesRespondToSocial. MakeThirdPartiesRespondToSocial is called on every loop (?) of the social interaction (as long as the interaction has a loop state that it hasn't been told to ignore), or on the actor exiting the interaction because it failed to execute. For each member of the conversation who isn't either the actor or the target of the calling interaction, MakeThirdPartiesRespondToSocial checks that they're not currently doing an interaction of their own and that their Sim object is one of the keys of the mEffects dictionary for that social interaction (meaning, they're not busy and the interaction indicates an effect for them).
If those conditions are all true, MakeThirdPartiesRespondToSocial gets the mEffects entry for the third party as a SocialRule object. Then it creates an instance of a ThirdPartyRespondToSocial object, links the SocialRule pulled out of mEffects for the third party to that object, and adds it to the third party's interaction queue. When ThirdPartyRespndToSocial runs, it makes the third party look at the sim whose interaction they're responding to, and then if the SocialRule.RHS for the interaction specifies a third party animation, it plays that animation and then sets the third party's end stance to be the same as the target's.
If those conditions are all true, MakeThirdPartiesRespondToSocial gets the mEffects entry for the third party as a SocialRule object. Then it creates an instance of a ThirdPartyRespondToSocial object, links the SocialRule pulled out of mEffects for the third party to that object, and adds it to the third party's interaction queue. When ThirdPartyRespndToSocial runs, it makes the third party look at the sim whose interaction they're responding to, and then if the SocialRule.RHS for the interaction specifies a third party animation, it plays that animation and then sets the third party's end stance to be the same as the target's.
mEffects for every SocialInteractionA contains Sim objects as keys and SocialRule objects as values. Its entries are set by the method Conversation.UpdateOnSelectingInteraction, which is called by SocialInteractionA.UpdateConversationWhenSocialStarts. For each member of the conversation (Conversation object instance) that called UpdateOnSelectingInteraction - except for the sim initiating the interaction - UpdateOnSelectingInteraction tries to find a SocialRule specifying how they should be affected. For sims other than the target (not going to describe how it handles the target sim since that's not what I'm trying to change), it does this by running Conversation.FindResponseForSim. FindResponseForSim calls FindMostSuitableRule to get a SocialRuleLHS object for the situation, and uses that and the name of the interaction in question to make a SocialRule object which it returns to UpdateOnSelectingInteraction. If that SocialRule's STEffectCommodity entry isn't 0 (CommodityTypes.Undefined), then FindResponseForSim sets ResultingResponsePositive for the SocialRule to be true if the STEffectCommodity is positive before returning the SocialRule to UpdateOnSelectingInteraction.
After getting social rules for everyone, UpdateOnSelectingInteraction then calls UpdateSimsAfterSelectingInteraction, and then UpdateConversation, and then returns the effect the interaction should have on its target (the SocialRule) to UpdateConversationWhenSocialStarts, where the rule is set as the value of mTargetEffect in the interaction's SocialInteractionA object.
UpdateSimsAfterSelectingInteraction adds the ActiveTopic "Attempted Humor" to all sims in the conversation if the IntendedCommodity associated with the SocialRule specifying the interaction's effect on its target was CommodityTypes.Funny, but otherwise only does anything to the actor and the target and not the third parties so I won't go into the rest.
UpdateConversation calls ProceduralEffectBeforeInteraction to run the procedural effect before update (pebu in the SocialData XML; peau must be after update) specified by the SocialRule for the interaction's effect on its target. Then for every member of the conversation UpdateConversation is updating (other than the one initiating the interaction), UpdateConversation runs UpdateSimBeforeInteraction using the initiating sim as the actor, the member as the target (even if they're not the target of the interaction the actor initiated, hope that's not a confusing way to put it), and the SocialRule for how the member is affected as the effect.
UpdateSimsAfterSelectingInteraction adds the ActiveTopic "Attempted Humor" to all sims in the conversation if the IntendedCommodity associated with the SocialRule specifying the interaction's effect on its target was CommodityTypes.Funny, but otherwise only does anything to the actor and the target and not the third parties so I won't go into the rest.
UpdateConversation calls ProceduralEffectBeforeInteraction to run the procedural effect before update (pebu in the SocialData XML; peau must be after update) specified by the SocialRule for the interaction's effect on its target. Then for every member of the conversation UpdateConversation is updating (other than the one initiating the interaction), UpdateConversation runs UpdateSimBeforeInteraction using the initiating sim as the actor, the member as the target (even if they're not the target of the interaction the actor initiated, hope that's not a confusing way to put it), and the SocialRule for how the member is affected as the effect.
From here on when I say "actor" and "target" I mean the sims considered actor and target by UpdateSimBeforeInteraction, not by the SocialInteractionA that triggered all this. There's a bunch of stuff that the beginning that I'll summarize by saying it updates the values of previous attributes of the actor and target's relationship (short term context, long term relationship points, long term relationship interaction bits, whether the previous social interaction was positive) with the current (at the time UpdateSimBeforeInteraction was called) values of those attributes. If the SocialRule passed to UpdateSimBeforeInteraction prescribes that the interaction be accepted, the actor gains charisma.
Then UpdateSimBeforeInteraction checks whether - according to methods of SocialRule.LHS - the action is intentionally positive (SocialRule.LHS.IntendedCommodity and SocialRuleLHSBase.STEffectCommodity are both positive), unintentionally negative (IntendedCommodity is positive but STEffectCommodity is not), or intentionally negative (both IntendedCommodity and STEffectCommodity are not positive).
Then UpdateSimBeforeInteraction checks whether - according to methods of SocialRule.LHS - the action is intentionally positive (SocialRule.LHS.IntendedCommodity and SocialRuleLHSBase.STEffectCommodity are both positive), unintentionally negative (IntendedCommodity is positive but STEffectCommodity is not), or intentionally negative (both IntendedCommodity and STEffectCommodity are not positive).
And I just realized this is getting long, sorry! Will break it up by finishing in a new post.
#7
2nd Aug 2020 at 12:02 AM
Continuing with what UpdateSimBeforeInteraction does.
If the action is intentionally positive, UpdateSimBeforeInteraction tries to increase fun for both the actor and the target. If it's unintentionally negative, UpdateSimBeforeInteraction tries to decrease fun for the actor only. And if it's intentionally negative, UpdateSimBeforeInteraction tries to decrease fun for the target only.
That's the end of UpdateSimBeforeInteraction, so from here on I'll switch back to using "actor" and "target" to refer to the actor and target of the SocialInteractionA at the beginning of all this. And UpdateSimBeforeInteraction is the end of UpdateConversation, which is the end of UpdateOnSelectingInteraction (unless UpdateOnSelectingSocialInteraction failed to find a SocialRule for the effect of the SocialInteractionA interaction on its target, in which case it looks like an error is generated?). So now we're back in SocialInteractionA.UpdateConversationWhenSocialStarts.
If the action is intentionally positive, UpdateSimBeforeInteraction tries to increase fun for both the actor and the target. If it's unintentionally negative, UpdateSimBeforeInteraction tries to decrease fun for the actor only. And if it's intentionally negative, UpdateSimBeforeInteraction tries to decrease fun for the target only.
That's the end of UpdateSimBeforeInteraction, so from here on I'll switch back to using "actor" and "target" to refer to the actor and target of the SocialInteractionA at the beginning of all this. And UpdateSimBeforeInteraction is the end of UpdateConversation, which is the end of UpdateOnSelectingInteraction (unless UpdateOnSelectingSocialInteraction failed to find a SocialRule for the effect of the SocialInteractionA interaction on its target, in which case it looks like an error is generated?). So now we're back in SocialInteractionA.UpdateConversationWhenSocialStarts.
After updating finishing UpdateOnSelectingInteraction, UpdateConversationWhenSocialStarts checks if the social in question was user-directed, and if so it sets the number of socials left in the conversation before sims will consider autonomously leaving (whatever value is in kNumExtraSocialsAddedByUserDirectedInteractionBeforeSimsConsiderLeaving; by default, that appears to be 3). Then it updates the SocialGroupDiscourageRegion footprint and members for the conversation; I don't understand this part and am not going to go down that rabbithole right at this moment, but I assume this is what triggers sims to move around if they feel they're not standing in the right positions to do whatever they're supposed to do. And that's the end of UpdateConversationWhenSocialStarts.
I still haven't seen any long term relationship points get added or removed, so maybe SocialInteractionA.UpdateConversationAfterSocialAnimationFinished is where that happens. Would make sense, let's check it out.
UpdateConversationAfterSocialAnimationFinished runs Conversation.UpdateConversationAfterInteraction on the conversation the actor of the social is having. UpdateConversationAfterInteraction applies trait reinforcement if the target was a pet, takes note of it if the social had an ActiveTopic (I assume from prevent sims from just talking about the same ActiveTopic again and again like it's not old news), takes note of the action having been performed (related to the number of times you can repeat a social, I imagine), adds or removes buffs from the actor and target as stipulated in the SocialRule.RHS associated with the interaction, and adds or removes active topics from the actor and target according to the SocialRule.RHS.
After finishing UpdateConversationAfterInteraction, UpdateConversationAfterSocialAnimationFinished goes through each member of the conversation and - if they're not the actor and they have an entry in the mEffects dictionary - gets the SocialRule for how they're affected and uses it to run SocialInteractionA.SetSocialFeedback on them. Unless they're a celebrity who's too good to socialize with the actor yet, in which case SetSocialFeedback doesn't run.
SocialComponent.SetSocialFeedback checks whether the interaction's HeadlineType is SimToSim, SimToPet, SimToBot, etc, and then runs SocialComponent.SetSocialFeedback using that and the SocialRule passed in from UpdateConversationAfterSocialAnimationFinished. SetSocialFeedback uses SocialRule.LHS.STEffectCommodity and SocialRule.LHS.LTROverride as the source of the CommodityType and ltrOverride value it uses. SetSocialFeedback decides which visual effect (the +/- icons over sims' heads, the selection of which appears to be based on the interaction's HeadlineType) to create based either on the LTRData between the sims in question (looks like that should never happen though, just from reading the if statement?) or on whether SocialRule.ResultingResponsePositive is true, whether the CommodityType it received as an input was Insulting or Steamed, and whether the ltrOverride it received was negative, zero, or positive. It causes the visual effect to display, and that's it for SocialComponent.SetSocialFeedback.
Back in SocialInteractionA.SetSocialFeedback after running through every member of the conversation, we update the actor's charisma stats if they told a joke, and then that method is done too and we return to UpdateConversationAfterSocialAnimationFinished to run SetSocialFeedBack on the actor. And then everything else UpdateConversationAfterSocialAnimationFinished does appears to be about the actor and the target, not the third parties, so no further answers there either.
UpdateConversationAfterSocialAnimationFinished runs Conversation.UpdateConversationAfterInteraction on the conversation the actor of the social is having. UpdateConversationAfterInteraction applies trait reinforcement if the target was a pet, takes note of it if the social had an ActiveTopic (I assume from prevent sims from just talking about the same ActiveTopic again and again like it's not old news), takes note of the action having been performed (related to the number of times you can repeat a social, I imagine), adds or removes buffs from the actor and target as stipulated in the SocialRule.RHS associated with the interaction, and adds or removes active topics from the actor and target according to the SocialRule.RHS.
After finishing UpdateConversationAfterInteraction, UpdateConversationAfterSocialAnimationFinished goes through each member of the conversation and - if they're not the actor and they have an entry in the mEffects dictionary - gets the SocialRule for how they're affected and uses it to run SocialInteractionA.SetSocialFeedback on them. Unless they're a celebrity who's too good to socialize with the actor yet, in which case SetSocialFeedback doesn't run.
SocialComponent.SetSocialFeedback checks whether the interaction's HeadlineType is SimToSim, SimToPet, SimToBot, etc, and then runs SocialComponent.SetSocialFeedback using that and the SocialRule passed in from UpdateConversationAfterSocialAnimationFinished. SetSocialFeedback uses SocialRule.LHS.STEffectCommodity and SocialRule.LHS.LTROverride as the source of the CommodityType and ltrOverride value it uses. SetSocialFeedback decides which visual effect (the +/- icons over sims' heads, the selection of which appears to be based on the interaction's HeadlineType) to create based either on the LTRData between the sims in question (looks like that should never happen though, just from reading the if statement?) or on whether SocialRule.ResultingResponsePositive is true, whether the CommodityType it received as an input was Insulting or Steamed, and whether the ltrOverride it received was negative, zero, or positive. It causes the visual effect to display, and that's it for SocialComponent.SetSocialFeedback.
Back in SocialInteractionA.SetSocialFeedback after running through every member of the conversation, we update the actor's charisma stats if they told a joke, and then that method is done too and we return to UpdateConversationAfterSocialAnimationFinished to run SetSocialFeedBack on the actor. And then everything else UpdateConversationAfterSocialAnimationFinished does appears to be about the actor and the target, not the third parties, so no further answers there either.
I guess my conclusion at this point is I need to make it so if the third party to a romantic social interaction is in a polyamorous relationship with the actor and the target, the SocialRule in the SocialInteractionA.mEffects dictionary has LHS.LTROverride non-negative, LHS.STEffectCommodity neutral or one of the positive ones, and ResultingResponsePositive true. Maybe I can add a new SocialRule with the necessary SocialRuleLHS and ResultingResponsePositive to every romantic interaction, with a script mod based on Woohooer's interaction replacements because XML coding is painful.
#8
2nd Aug 2020 at 7:19 PM
Still no luck on stopping sims' distaste for PDA, but I have managed to 1) accidentally discover how to prevent sims from getting their reputations lowered by being seen "cheating" by sims who shouldn't consider what they saw to be cheating (set the event listener I use to apply my custom jealousy standards not to run UpdateRomanceVisibilityForPdaIfNecessary - which doesn't call CheckCheating before pushing accusations and so wasn't affected by replacing CheckCheating - when I don't think it's necessary), and 2) insert a new SocialRule for every romantic social that uses a custom procedural precondition to ask if the third parties to the social are in a relationship with the actor and/or the target.
I can't tell if that rule is actually being used, though, although its procedural precondition function definitely runs and outputs the correct answer; and I don't really know that it would stop the PDA reaction if it did run, I'm just guessing based on what I figured out in my previous posts. I'm going to check out ReactToSocialParams and see if there's a reaction broadcaster that may be doing this instead, and also try to make the social rule I inject do really wild things just so I'll be able to tell if it was used or not.
I can't tell if that rule is actually being used, though, although its procedural precondition function definitely runs and outputs the correct answer; and I don't really know that it would stop the PDA reaction if it did run, I'm just guessing based on what I figured out in my previous posts. I'm going to check out ReactToSocialParams and see if there's a reaction broadcaster that may be doing this instead, and also try to make the social rule I inject do really wild things just so I'll be able to tell if it was used or not.
#9
2nd Aug 2020 at 11:36 PM
Changing the intended commodity types for all the romantic interactions from amorous to friendly stops them from triggering a relationship hit for the bystanders; but it also makes the targets just respond with a shrug, and no one's relationship changes for worse or for better, which isn't the goal. And even without the relationship hit, if I run an interaction that manages to get to the "amorous" short term context anyway the third parties still walk away, just without losing relationship points. Turns out that's because of a field of SocialInteractionA, mPairedSocial; if it's true, then when that interaction is used in a group conversation every sim but the actor and the target will see themselves out. So I made the procedural precondition for the LHS rule I've injected into the action data for every romantic interaction set mPairedSocial to false if the sims are polyamorous, and that stops sims from immediately ditching the conversation if their partners kiss in front of them, although they still take a relationship hit and will still walk away if two romantic socials in a row are done to someone other than them.
Who Posted
|