Replies: 17 (Who?), Viewed: 4874 times.
Alchemist
Original Poster
#1 Old 24th Jan 2019 at 9:38 AM
Default XML Injector
I've released a library mod, XML Injector, which creates a snippet class to allow modifications that are frequently handled via a script (e.g. modifying _super_affordances) without requiring mods to include their own script.

It's easy to code the snippet, and full documentation with examples is available on the download page. Hopefully this is just a start of what functionality can be added to it, I think it should be quite useful for the modding community in eliminating the need for modders to write, compile and maintain scripts in their own mods for simple modification needs.

https://modthesims.info/d/622928/xm...-version-1.html
Advertisement
Test Subject
#2 Old 30th Jan 2019 at 6:19 PM
I mentioned it on the download but I'll mention it here as well just in case. I have lots of mods that add loot_action or random_loot_action and if it's not too much work I'd be grateful if you added a snippet class for this as well. I'm new to all this so I haven't gotten very far trying to do it on my own. Thank you for the wonderful tool!
Alchemist
Original Poster
#3 Old 30th Jan 2019 at 7:24 PM
Quote:
Originally Posted by BrazenLotus
I mentioned it on the download but I'll mention it here as well just in case.

Actually this does seem like the most ideal forum to discuss technical details for modders -- especially discussion of where to take things from here as far as additional functionality. I'd suggest folks that are interested in this kind of thing maybe should subscribe to this thread (I am, of course, subscribed).

Quote:
Originally Posted by BrazenLotus
I have lots of mods that add loot_action or random_loot_action and if it's not too much work I'd be grateful if you added a snippet class for this as well. I'm new to all this so I haven't gotten very far trying to do it on my own.

Well, first I think this would be an excellent addition, but....

If you're talking about adding an item to a LootAction or RandomWeightedLoot XML action file, that should be fairly straightforward I think. Nowhere near as simple as just adding a reference to an interaction to _super_interactions, but I think it could probably be accomplished.

On the other hand, if you are talking about adding a reference to a LootAction within an interaction, the question becomes one of targeting. The list of possible loot_actions can occur in so many places and at different levels of the XML. Even just trying to add one to a list in a basic_content/looping_animation is full of possible confusion as the loot_actions lists occur in a conditional_actions list... so which conditional action should be modified? There's no names on a conditional action so we would need some way to identify WHICH conditional action needs items added to it's loot_actions.

Hopefully that makes sense. I think the next step would be for you to post a reference to an XML from the game and how you would like to modify it. Then once my PC is all rebuilt and stable and I'm able to be actively modding again I can take a look at the possibilities.
Test Subject
#4 Old 30th Jan 2019 at 11:43 PM
I think I sort of understand. One of the resources I'm currently overriding is an action tuning, so likely this is the straightforward example you mentioned. It's the randomWeightedLoot_Garden_SeedPacket_Fall (188583) and I'd like to add this section of code for each custom harvestable I make:
<U>
<V n="action" t="create_object">
<U n="create_object">
<V n="creation_data" t="definition">
<U n="definition">
<T n="definition">155181760<!--brazenlotus {S.Green Heirloom Pumpkin}{P.Green Heirloom Pumpkins}--></T>
</U>
</V>
<V n="location" t="inventory" />
<T n="quantity">2</T>
</U>
</V>
</U>

Now the other is a few layers deep and involves a loot list in the 'outcome' section of a Beebox mixer_BeeBox_CollectHoney (187593) interaction:

<V n="outcome" t="test_based">
<U n="test_based">
<L n="fallback_outcomes">
<U>
<U n="outcome">
<V n="animation_ref" t="enabled">
<U n="enabled">
<T n="factory">186171<!--BeeBox_CollectHoney--></T>
</U>
</V>
<L n="loot_list">
<T>186209<!--loot_BeeBox_CollectHoney--></T>
<T>186444<!--loot_BeeBox_CreateHoney--></T>
</L>
</U>
<U n="weight">
<T n="base_value">1</T>
</U>
</U>...

There is more to the xml but you can see the first loot_list I'd like to add to. I see that there are multiple loot_lists under the outcome section because it's test-based, is this what you're referring to when you say you need to identify which action gets items added? Let me know if you need a full copy of the xml and I can post it or a link to it.

Whenever you get a chance to check it out it would be greatly appreciated and good luck with the PC build.
Lab Assistant
#5 Old 31st Jan 2019 at 12:47 AM
If appending to an existing loot file is the much more doable operation, I would think in the second example you gave, BrazenLotus, you could have whatever it is you need to loot appended to one of the existing loot files in that list, rather than trying to append another loot reference inside of the loot_list parameter. Granted, this has its limitations... in cases where there is no existing loot_list, there would be no existing loot file to append to. And you might run into scenarios where the same loot file is called in different interactions for different reasons, so appending to it for the intent of one interaction would affect other interactions that call upon it as well.

♫ Improvising into a corner ♫
♫ No rhyme or rhythm in this verse cause I'm in a corner ♫
Alchemist
Original Poster
#6 Old 31st Jan 2019 at 8:04 AM
Quote:
Originally Posted by BrazenLotus
I think I sort of understand. One of the resources I'm currently overriding is an action tuning, so likely this is the straightforward example you mentioned. It's the randomWeightedLoot_Garden_SeedPacket_Fall (188583) and I'd like to add this section of code for each custom harvestable I make
<Snip>

Yup, I think something like that should be able to be implemented as it adds something to a precisely known list.

Quote:
Now the other is a few layers deep and involves a loot list in the 'outcome' section of a Beebox mixer_BeeBox_CollectHoney (187593) interaction:
<Snip>
There is more to the xml but you can see the first loot_list I'd like to add to. I see that there are multiple loot_lists under the outcome section because it's test-based, is this what you're referring to when you say you need to identify which action gets items added?

That's exactly what I was referring to, yes. The fact that there are three fallback_outcomes in that section makes it far more difficult and error prone to know which loot_list to add to.

And no, it's not impossible, just trickier. What would be needed is a precise set of tuning in the snippet to uniquely identify the target. In this example, it could look at which of those outcomes uses the animation_ref BeeBox_CollectHoney. That works for this specific interaction, but other interactions would not use an animation_ref at all, so just using that for targeting would not work in all cases. Possibly some other parameters could be used for targeting, using a system of variants. So, thinking in that manner, the tuning in the snippet might look something like (and I'm just kind of throwing this out, likely the coding would have to be more complex):
Code:
  <L n="add_loot_to_interaction">
    <T n="interaction">187593<!--MixerInteraction: mixer_BeeBox_CollectHoney--></T>
    <V n="targeting" t="fallback_outcome">
      <U n="fallback_outcome">
        <V n="outcome_selection" t="animation_ref_factory">
          <U n="animation_ref_factory">
            <T>186171<!--AnimationElement: BeeBox_CollectHoney--></T>
          </U>
        </V>
        <L n="add_loot">
          <T>12199153228112868850<!--BrazenLotus_loot_BeeBox_NewLootToBeAdded--></T>
        </L>
      </U>
    </V>
  </L&gt


Thoughts anyone?

I like Triplis's idea of adding the loot to one of the actual LootActions in the outcomes (much like your first example is doing), but it sounds like that in this case that wouldn't work as not only could that (to pick one of the two) loot_BeeBox_CreateHoney be used from multiple interactions (which it is), but in this particular case both of the possible existing loots are used from each of the outcomes within that interaction, so modifying the loot_BeeBox_CreateHoney would affect all outcomes and not just the first one.
Test Subject
#7 Old 31st Jan 2019 at 12:15 PM
I like the idea of appending to an existing loot file as it seems to be more precise.

It depends on how much stuff you can append to it, but if you can append buffs/statistics/etc as well as tests and you are appending to a loot that gets added from an interactions tested outcome you could always add in the same tests in the action loot that are present in the potential interaction outcome that you are trying to add stuff to.
Test Subject
#8 Old 31st Jan 2019 at 1:49 PM
I think in the majority of cases you could just add the loot directly to the action tuning. I like Basemental's suggestion to add tests to the tuning to limit the loot, if that's possible, it sounds like that would be the way to go.
Lab Assistant
#9 Old 31st Jan 2019 at 3:54 PM
Quote:
Originally Posted by scumbumbo
And no, it's not impossible, just trickier. What would be needed is a precise set of tuning in the snippet to uniquely identify the target. In this example, it could look at which of those outcomes uses the animation_ref BeeBox_CollectHoney. That works for this specific interaction, but other interactions would not use an animation_ref at all, so just using that for targeting would not work in all cases. Possibly some other parameters could be used for targeting, using a system of variants. So, thinking in that manner, the tuning in the snippet might look something like (and I'm just kind of throwing this out, likely the coding would have to be more complex):
Code:
  <L n="add_loot_to_interaction">
    <T n="interaction">187593<!--MixerInteraction: mixer_BeeBox_CollectHoney--></T>
    <V n="targeting" t="fallback_outcome">
      <U n="fallback_outcome">
        <V n="outcome_selection" t="animation_ref_factory">
          <U n="animation_ref_factory">
            <T>186171<!--AnimationElement: BeeBox_CollectHoney--></T>
          </U>
        </V>
        <L n="add_loot">
          <T>12199153228112868850<!--BrazenLotus_loot_BeeBox_NewLootToBeAdded--></T>
        </L>
      </U>
    </V>
  </L&gt


Thoughts anyone?

I didn't know it was possible to target that precisely. That's pretty cool. Would it be going for the same type of logic as the "hasattr" super_affordance python code? Something like (in pseudo):

for tunings in tuning_list
for fallback_outcomes in tuning
hasattr animation_ref

Well... leaving out "the rest of the fucking owl" where you have to somehow check / iterate through the number of found fallback_outcomes or something.

Or am I way off in general?

Quote:
Originally Posted by Basemental
I like the idea of appending to an existing loot file as it seems to be more precise.

It depends on how much stuff you can append to it, but if you can append buffs/statistics/etc as well as tests and you are appending to a loot that gets added from an interactions tested outcome you could always add in the same tests in the action loot that are present in the potential interaction outcome that you are trying to add stuff to.

I hadn't thought about tests. That would potentially resolve some of the issues with the bits of loot running in the wrong places, wouldn't it? Provided it's not super complex to append in a test, or tests, as well. If I remember right, test types are exactly the same no matter where you reference them, so you wouldn't have to worry about not having access to a particular test because it's in a loot file, rather than an interaction.

♫ Improvising into a corner ♫
♫ No rhyme or rhythm in this verse cause I'm in a corner ♫
Alchemist
Original Poster
#10 Old 31st Jan 2019 at 6:36 PM
Quote:
Originally Posted by Basemental
It depends on how much stuff you can append to it, but if you can append buffs/statistics/etc as well as tests and you are appending to a loot that gets added from an interactions tested outcome you could always add in the same tests in the action loot that are present in the potential interaction outcome that you are trying to add stuff to.

Yes, when adding to a LootAction itself then any tests that would normally be present in a LootActionVariant would be available, but there's no tests that can tell you that whatever is triggering the loot action is resulting from "fallback outcome 'n' of interaction 'x'". You'd only be able to run the standard tests that can normally be done within a LootActionVariant, and in the case of the mixer_BeeBox_CollectHoney interaction there are three fallback outcomes chosen from randomly. Some multipliers get applied to the choice due to some tests in the outcomes but it comes down to there's always a chance of success vs. failure and when the LootActionVariant is actually applied it has no idea which of those branches the mixer interaction itself headed down.

In short, adding a LootActionVariant to a LootAction or RandomWeightedLoot should be "simple" and I'm pretty sure that could be done -- but from within its standard test it won't be able to have any of the details of what random choices were made from within the interaction that is applying it.
Alchemist
Original Poster
#11 Old 31st Jan 2019 at 6:55 PM
Quote:
Originally Posted by Triplis
I didn't know it was possible to target that precisely. That's pretty cool. Would it be going for the same type of logic as the "hasattr" super_affordance python code? Something like (in pseudo):

for tunings in tuning_list
for fallback_outcomes in tuning
hasattr animation_ref

Apart from the "for tunings in tuning_list" and the rest of the owl details, similar yes. It would only look for one specific interaction to look at (referring back to the off the cuff XML snippet I typed above, the second line specifies "we're patching this particular interaction").

The first variant would result in that for fallback_outcomes in tuning, yes. Then the second variant would look to see if an animation_ref exists and if it does check the factory, and then only if that test succeeded proceed to add the loot reference to the loot_list for that outcome.

Other options will likely be desirable for both that first variant, to select which portion of the interaction itself we're targeting, as well as the second variant, to determine which outcome(s) within a list of possible outcomes we want to add the LootAction to.

One last thing (and this may be obvious) remember that we are patching the XML tuning here. None of these tests will be running after all the tunings are loaded into the game - we're just doing these tests to identify which part of the tuning instance we want to patch.
Alchemist
Original Poster
#12 Old 31st Jan 2019 at 7:06 PM Last edited by scumbumbo : 3rd Feb 2019 at 3:13 AM.
I went ahead and created a Discord server for discussion of this sort of thing, I think that could be useful.

https://discord.gg/wT5wcbJ
https://discord.gg/buFE355
Lab Assistant
#13 Old 3rd Feb 2019 at 1:40 AM
Quote:
Originally Posted by scumbumbo
I went ahead and created a Discord server for discussion of this sort of thing, I think that could be useful.

https://discord.gg/wT5wcbJ


The invitation is gone I want to be there because I need to use your XML Injector and thank you so much!
Alchemist
Original Poster
#14 Old 3rd Feb 2019 at 3:13 AM
Quote:
Originally Posted by Itsmysimmod
The invitation is gone I want to be there because I need to use your XML Injector and thank you so much!


Hmm, apparently an invite link marked "Never expire" still can expire. That or I did something wrong, lol

Here's a new link to that: https://discord.gg/buFE355
Test Subject
#15 Old 22nd Mar 2019 at 7:57 AM
so if I want to add the same interaction to multiple object via partial_name
how it should look like?

or this is right example?
Alchemist
Original Poster
#16 Old 25th Mar 2019 at 10:19 AM
@Illume -- You'll want to use the second version of the two. There may be some other methods for object selection in future versions (version 2 will add selection based on object tags, for instance) but for now #2 is the way to go.

ETA - Version 2 is due out soon, working on finalizing the documentation for it and then it should be ready to go out the door. If you're planning a mod for a release soon you may want to wait as there are some worthwhile changes to it even if you're only planning to use the super_affordance add features (notably version checking, and a method of prompting players if the XML Injector is not installed and your mod depends on it).
Test Subject
#17 Old 26th Mar 2019 at 11:29 AM
fine, will wait for ver.2
thx for another great mod\tool btw
Alchemist
Original Poster
#18 Old 26th Mar 2019 at 11:48 PM
Quote:
Originally Posted by Illume
fine, will wait for ver.2
thx for another great mod\tool btw

Not long to wait, posted the updated version today

Thanks for the thanks, I'm glad folks are getting good use out it!
Back to top