Cannot click/self-interact with sim
Whenever I’m playing a family there is always a sim I cannot self-interact with (to change outfits, go jogging etc) I’ve tried to repair my game but wanted to know if anybody has had a similar experience. After the recent update it has broken many things for me relating to interacting. This seems to happen with my sims who are above the age of a child.Interaction-Triggered Drama Nodes
I'm creating a mod that allows me to organise individual lighting objects into any of 1-10 groups ('presets') by adding statistics, then allowing me to select eg. 'turn on preset 1' and all lights on the lot under preset 1 turn on etc. I have finished this part of the mod - the manual part - and all lights can be grouped, and groups turned on/off. I now want to make it possible to set a time for certain groups to automatically turn on/off. I wanted to create an interaction on lighting objects where you can select to 'automate turn on time' for a specific preset, which then triggers a multi-response dialog drama node where you can choose from several possible times. These would then set all lot objects in a given preset to a specific statistic value (corresponding to that time). I want to later add other drama nodes for each time of day to trigger an on/off loot on all lights that have that time's corresponding stat value, however, I'm stuck at the setting automated time part. I mostly understand how to create drama nodes, and have tried to schedule the below drama node in a loot action triggered by an immediate interaction (ie. 'set automated turn on time for preset 1'). This interaction does show up in game but the drama node is not triggered. I have tried a number of variations ie. changing 'dialog_style' to chance card/adding a title/adding age test under sim info, and it won't work, please help!! Drama node xml: <?xml version="1.0" encoding="utf-8"?> <I c="DialogDramaNode" i="drama_node" m="drama_scheduler.dialog_drama_node" n="CustomLightPresets_DramaNode_SetAutoTurnOn_Preset1" s="11188765727022981497"> <V n="cooldown_data" t="node_cooldown"> <U n="node_cooldown" /> </V> <V n="dialog_and_loot" t="dialog_multi_response"> <U n="dialog_multi_response"> <U n="dialog"> <E n="dialog_style">DEFAULT</E> <V n="icon" t="disabled" /> <V n="text" t="single"> <T n="single">0x6510D966<!--What time (daily) should lights under preset 1 turn on automatically?--></T> </V> </U> <L n="possible_responses"> <U> <U n="item"> <L n="loot"> <T>14784211707288741193<!--CustomLightPresets_SetAutoOn_Preset1_7am--></T> </L> <T n="text">0x41C6AFB6<!--7am--></T> </U> </U> <U> <U n="item"> <L n="loot"> <T>9996971579461026540<!--CustomLightPresets_SetAutoOn_Preset1_12pm--></T> </L> <T n="text">0xBEEE8B05<!--12pm--></T> </U> </U> <U> <U n="item"> <L n="loot"> <T>14783097902009552531<!--CustomLightPresets_SetAutoOn_Preset1_6pm--></T> </L> <T n="text">0x36CA704C<!--6pm--></T> </U> </U> <U> <U n="item"> <T n="text">0x45B22E22<!--Cancel--></T> </U> </U> </L> </U> </V> <E n="receiver_sim">Actor</E> <V n="sender_sim_info" t="no_participant"> <U n="no_participant" /> </V> <V n="time_option" t="schedule"> <U n="schedule"> <L n="valid_times"> <U> <U n="days_available"> <T n="0 SUNDAY">True</T> <T n="1 MONDAY">True</T> <T n="2 TUESDAY">True</T> <T n="3 WEDNESDAY">True</T> <T n="4 THURSDAY">True</T> <T n="5 FRIDAY">True</T> <T n="6 SATURDAY">True</T> </U> </U> </L> </U> </V> </I> The loot to schedule this drama node is referenced under 'outcome'->'single'->'loot_list', in the immediate interaction.1020 Alto Apartment appearing on Willow Creek Map (Glitch)
I currently have this issue in my save where 1020 alto apartment appears ontop of my willow creek map. I tried to bulldoze the 1020 apartment lot but my game crashes everytime i try to load into it. Anyone have a fix? Alot of my builds are bugged in this save, some keep disappearing & appearing where they aren't meant to.Mixerinteraction names
Hey, I’m trying to figure something out. When the interaction ’Shower_TakeShower’ runs on a shower it runs the mixer interaction ’Shower_TakeShower_Passive’ That puts the sim in the shower pose next to the shower so the sim can continue to run the Shower_Wash_wash animation. But if I change the name of the mixer to something else, just adding or removing a char. The interaction fails… so for some reason the name of the mixer is important… I really want to know why and how that is connected.Tdesc file structure as compared to tuning files? (and some thoughts on error checking)
So as a little side project for attempting to make it easier to spot errors in mods in need of fixing when updates happen, I was looking at the idea of using the TDESC file structure compared to the format of code in a tuning file and compare the two to see if anything is awry. I got a little tripped up in the details though and figured I'd ask around if anyone knows more about the TDESC file structure, or some perspective I hadn't thought of that might lead to a solution. So far, I worked out that for tuning files: I = Instance ("instance_type") L = Tunable List U = Tunable Tuple V = Tunable Variant E = Tunable Enum T = Tunable Type And that 't' and 'n' in the tuning files are short for 'type' and 'name' in the TDESC files. But it seems to get increasingly complicated from there, rife with exceptions to the rule. Where some branches of commands will follow a structure identical (or near) identical to its sister tree in the TDESC file, some others most definitely don't. For example, for some branches you can't just translate it like: Actor To something like: And looking for a branching setup like that in the Interaction.tdesc file as it just wouldn't exist in that format. If I remember correctly for this specific case, the TunableVariant part at the top is instead decided on from a series of different types and is, by default, none. In theory, exceptions like these could be hard-coded for, but it's hard to tell just how many of them there are and to what extent they would result in false positives when testing for tuning code with errors. I remember trying to resolve the one as in the example above and running into more confusing exceptions to the rule, or I misunderstood what I had thought was a rule that wasn't, or something like that. However, I know folks like Zerbu have created tools that can generate certain code. I'm not sure if those tools are based off of the tdesc files or copies of tuning files, but presumably the TDESC files could be interpreted from somehow. The other approach I had considered was testing bits of code (ex: the VFX segment above) against the most up-to-date tuning files and simply seeing if it matches any of the existing code. This would probably work for a lot of things, but runs the risk of false positives if someone has utilized a combination of tuning possibilities that simply hasn't been used in the actual game. It also risks being performance-heavy to analyze, as there's no way of knowing for sure how many files would need to be searched through and compared against. In the case of an error, you'd have to assume it analyzes at least every single game file of a certain type (ex: Interaction) until it finds that there is no code like the sample checked for. Best case scenario for performance would be that it locates an existing example quickly and returns with no error. So I'm at a bit of a standstill at the moment, in terms of tackling the problem. I think interpretation of the TDESC files and comparing that to tuning files is a realistic possibility. It's just proven to be more convoluted that I thought it would be and I'm not sure if that's because of how the TDESC files are structured, or if I'm just not understanding them well enough.Error in 1.44.77 Tdesc Version History ?
@SimGuruModSquad - The latest Tdesc files were throwing an exception in my Tdesc Browser which I needed to resolve whenever the Interaction class was browsed. In Interaction.tdesc there are two items in the rename history which both indicate a new_muid of 917EA0F99E2E532E (the pie menu "key" tuning). The first (line 99171) points to an old_muid of 1718F539A92F1C7C while the second (line 99909) points to an old_muid of 6C89C799F0E098A6. I've patched around the exception itself, however, it brings up a few questions. Where is the muid 6C89C799F0E098A6? Presumably an unreleased internal version of the Tdescs? At least, it does not appear anywhere in my Tdesc archives. The first old/new_muid combination points to a valid muid in the previous released version of Tdescs (1.39.74, pie_menu_icon), so I am simply throwing away the second rename from the version history as it seems invalid. Should it even be possible for a rename to a new_muid to occur twice? If so, then I'd like to code in my browser to do the best case scenario for any future duplicate new_muid rename history combinations.