Detecting transmogrification

Hey all, Was wondering if any of the API gurus out there had any insight into detecting when a new character is coming from the transmogrifier, and when it's being created manually. In my companion script for the shaped sheet, I have an option to auto-configure new characters with sensible defaults, since the character sheet can't store global state. This works by hooking into the new character event, and so far it's been working great. The trouble comes when someone imports something via the transmogrifier, because this also generates a new character event - at which point I populate a whole bunch of attributes that shortly afterwards become undesirable duplicates. I guess the crude solution would be to introduce a delay of some sort to check if the transmogrifier was working, but I really hate doing stuff like that because (a) it makes the script less responsive in the 99% case and (b) it's extremely unreliable given the variability in people's machines and connections. Is there anything else I can do? Any other markers that might help me detect that a character is coming from the transmogrifier rather than being manually created? Cheers,

Could you use debounce to call your defaults function on attribute and character creations. And then it would call only once when all the creation events have fired could maybe do some logic so it only fired if there is a character creation at the same time?

Scott C. said: Could you use debounce to call your defaults function on attribute and character creations. And then it would call only once when all the creation events have fired could maybe do some logic so it only fired if there is a character creation at the same time? Hey Scott, The trouble is that I'm actually responding to the add:character event. In a manual creation case, this is all that will happen - a new character was created, end of. At that point I want to step in and populate some default attributes.  In the transmogrification case, what I *think* is happening (I admit I haven't probed that deeply yet) is that the character gets created (empty) -> add:character event fired, and then a whole bunch of attributes get added afterwards. Based on what I know of other parts of Roll20, I'd hazard a guess that all of this gets driven by the client, and to all intents and purposes it looks to the rest of the system like a user is doing a bunch of stuff real quickly. So, as mentioned in my previous post, I could in theory trap the add:character, wait for a certain amount of time to see if a bunch of attributes get created for that new character, and if they do, assume it's a transmogrification case. But if the user is on a slow or loaded machine, or there's a dodgy connection, those attributes might be created slower than normal, or with more delay. If I set the wait time long enough, I'll probably catch most cases, but then the normal behaviour of the script will be super slow + I run the risk of not setting the defaults on manual creation if the user is particularly swift about opening their new character! Really what I'm looking for is if there's some reliable marker of a new character being a transmogrification - either a pattern of activity that's conclusive, or, better yet, some property that makes it clear; and I'd like it to be something I can detect in a clearly defined period of time without having to introduce wait times that are dependent on unpredictable things like client loading and connection speed...

... sorry, to address more directly your suggestion - I actually don't want to run the defaults thing for transmogrified characters (they already have their own settings). I probably wouldn't want to use debounce anyway since I do a bunch of other stuff on attribute creation independently, so it would wind up making things more complicated rather than less. But all of that is academic, because even with debounce, I still have to decide on a wait time, and that's precisely what I want to avoid - it's messy and unreliable, and slows down the normal operation of the script to avoid a case that 99% of users will never encounter. I've seen variances of at least 1000% in the speed at which stuff happens on Roll20, depending on server load, connection quality and computer speed - it's really not credible to try and work around that with a single wait value :-(

Ah, true.

In the past, I've had to work around similar issues with created tokens not properly being setup when the add:graphic event occurred. I handled that by adding the id to a registry, then waiting 50ms and doing a getObj() on it then to have a fully formed object.  In your case, you could add the created character id to a registry and wait 50ms, then check to see if there are any attributes for it.  If there aren't, you can assume it's a new character.  If there are, it's transmogrified.   Some wiggling might be necessary to get the timing right, but that ought to handle detection.

Having caught up on the wall of text, I see you already have that solution in mind. =D You might be able tell based on some clever interpretation of the current state of certain properties.  If avatar ,  _defaulttoken  , and controlledby are all blank, you might be reasonably certain it's a new character.

You could also take a different tack, and place some marker to let you know beyond a doubt that the character is not new, that it was seen by your script in another game.  That would only work if it HAD been seen in that game, of course.

Something I just thought of as an alternate is that you could add a command to the script like !transmogrifying that would suspend the script's typical actions until you entered the command again. Similar to the /talktomyself chat command. Also, does this trigger when something is imported via a player's character vault as well?

Good question!  I bet Vault presents the same to the API. You could flip the other way and not do the defaults automatically, but instead prompt in the chat for: [Apply Defaults](!shaped-apply-defaults -J1z123f34as) or similar.

The Aaron said: Good question!  I bet Vault presents the same to the API. You could flip the other way and not do the defaults automatically, but instead prompt in the chat for: [Apply Defaults](!shaped-apply-defaults -J1z123f34as) or similar. Interesting. Might think about that option, although both the vault and the transmogrifier are substantially less common use cases than just creating a character manually, so perhaps the "turn on transmogrifier mode" is a better approach. I like the idea of checking for defaulttoken, avatar, and controlledby - whatever else I do that's probably worth including as a guard.

Could check the bio and gm notes as well.  Basically, I can't imagine anyone transmogrifying over a character that didn't have at least one of those things changed.  Conversely, if they did, I can't imagine that running the defaults on it would then be a problem. =D

Really, any of the properties except name (as it gets default filled when created through the UI).

The Aaron said: Really, any of the properties except name (as it gets default filled when created through the UI) Perhaps I need to do an analysis of the name and see if it matches the Roll20 name generation algorithm :-)

I have to assume there is at least one person that doesn't immediately change the name, so that's got to be a loosing option. =D

Macro.... !newCharacter... use it fire an API to create new characters.... any chracter not created in that manner is transmogrification or some other process. 

Stephen S. said: Macro.... !newCharacter... use it fire an API to create new characters.... any chracter not created in that manner is transmogrification or some other process.  Yeah. That's probably the right option - I think I'll change it to that to avoid confusion.