Is there a script to load mule type characters?

So I have seen it mentioned a few times before that one of the drawbacks of mule type characters is that Roll20 made some changes to not load all characters for faster loading times. This can cause macros calling abilities on mule characters to fail until you open the mule character in the game. I was wondering if there was already a way or an API script available that would warm the cache for a list of mule characters? I was thinking it would be handy to have the API script warm the cache for a list of mule characters on sandbox start so they are ready and its one less manual step for folks to forget about until they run into that error.

Hi Joshua! I have never had a mule character fail while the sandbox was active. I go through entire sessions without once opening them. One of them probably has more than 200 abilities on it, some that even call other mule characters. Can you post a link to these places that cite such a problem? Or have you, yourself run into such an issue?

Hi Keith, Here is one  post in which it was reported . The next post mentions discussion in the ScriptCards discord relating to this issue. I think I remember seeing other references to this as well but I cannot seem to find them right now. Kurt J and others in the discord did mention that mule characters suffered from this bug and it was talked about like it was a known thing, which is I mentioned it like I did initially. I myself have run into this recently where a ScriptCard will list buttons in chat to abilities on a mule character and that will work fine but loading that game fresh will throw an error like it cannot find the character or the ability on the character until you open the mule's character sheet just once and then everything works. The sandbox is already running fine because the ScriptCard portion processed everything. It's the %{~CharacterName|AbilityName} portion that fails initially.

Hi Joshua Do you have sheetbutton rather than button (my final post in the link you supplied)?  I know you were helping me with this initially, but I don't know whether you caught the outcome ie a re-write of the part of the script that was causing problems.  I have played several sessions since and all work fine.  Today I set up a new game, transmogrified all my favourite macros and the 3 mules from my other game and it all worked straight off the bat

Hmm. I can't address any ScriptCard code because I don't use it. I do know that in a regular macro, %{~CharacterName|AbilityName} should always fail. AFAIK, you can't mix % and ~ in the same call. But maybe that's a ScriptCard thing. Does the failure happen when ScriptCards constructs the button, or when that button is pressed? And is it possible to tell if the button being created has the proper code? You should be able to tell this (in the case where the button is formed but doesn't fail until pressed), by pressing the button to verify failure, opening the sheet, and then pressing the same button again (not a freshly generated instance of it). Finally, is ScriptCards the only time this fails? Do you access your mule in other ways (ex: a macro button)? It just occurred to me while typing that it is possible that my mule is being loaded because 90% of my macro bar is made up of mule buttons. Maybe the sheet is being loaded whrn the bar is constructed at start time? If your mule has no abilities that are set as macrobar buttons, try setting one as such. Then see if you have the loading issue. Yoou may need to hold shift down while loading the game to clear the cache and ensure an accurate test.

Thanks Simon but this just happened to me right now just logging fresh into a game. That Use an Object button is produced from: --&msg|+[td][button][&pcaDisplayName(replaceall,-, )]::~[&pcaSource]|[&pcaTid][/button][/td] So it's a button call that does that. The re-entry buttons work fine. I have re-entry buttons that open up a submenu for Attacks and then call the repeating_attack on the character's sheet and that works. It's the normal ScriptCard buttons that fail to call the abilities I store on a mule character until I open it. Then once I have opened that mule character and closed it, everything works as expected for that session. No more errors about not finding the ability.

Keith, as usual, I think you might be on to something. I just tested and the ScriptCard button using character_id|ability_id failed. Then I did a chat menu button like in the  macros wiki about ability command buttons  and that worked straight away. It also allowed the ScriptCard to immediately work after without even opening the mule's sheet. All the buttons calling the mule's abilities work after that one chat button. I don't have any of its abilities in my macro bar since they were always meant to be called from a ScriptCard prompt. Let me do some more testing and see if simply having a macro will work cause it's odd that the chat menu button loaded everything.

Having one of the mule's abilities in the macro bar does indeed load everything up fine. Removing the mule's ability from the macro bar and I do indeed get the same behavior returning. I wonder why Simon was able to use button's with mule characters and I cannot. I will keep testing since maybe it's how I'm constructing the buttons using the IDs instead of names? But as of now I can reliably reproduce it at least which is a good first step. I think I would still rather have a script load this than have to have one of these abilities in a macro bar that I will never call directly but at least that's a possible workaround. Thanks for the replies so far both of you.

Ahh I figured out why the difference in behavior. Also I forgot I made a change, when I only had abilities coming from the mule character, I referenced by name and it all worked. Buttons referencing the character sheet, which I have abilities with token actions and the like work fine when referencing by character_id but apparently mule's without macro bar abilities do not function that way. So moving back to referencing the mule by name instead of ID and things are working. Anyway, as always, it's when I refactor things to add a feature that I break everything and then try to solve that breakage with additional automation. Story of my whole career really. Thanks Keith and Simon.

Name is probably safer than ID anyway, since that ID can change depending on how the sheet is moved to a new campaign. For example, Token Action Maker has an option to generate Abilities by ID if the character is going to always be in the same game (this means you can change the name any time), or by name if you plan on Transmogrifying/Vaulting, as the sheet will get a new ID. Although in the latter case, changing the name is problematical.

The ID is fetched from the object in-game. It's not hardcoded so it would be portable except for this loading issue. The mule character name is in a variable but I still need to fetch its character id so that I can fetch the abilities on the sheet. That's how ScriptCards fetches objects from the API. Portability isn't really an issue in this case but I take your point.