GM notes - Aaugh... I don't want to use them for API information.

GM notes - Aaugh... I don't want to use them for API information. But running out of options. This has been buggy in the past, is it all better? And any best practices worth considering? Using it to store URL information... and few more bits of information.

How about a handout? Peer at Powercards and how it uses a handout to store pre-defined formats, and see if that meets your needs?

Dealing with callbacks is a pain though, you'll have build a little data structure to handle all those async callbacks.

It seems like this is exactly what state is for. If you want to store per-token information, just put a token-ID-keyed dictionary somewhere in state (state.foo={}; state.foo[token_id]=bar).

Trying to survive the transmogrifier. Map making APIs (scripts, token actions, macros) in one campaign... export to active player campaign (door/torch toggle scripts, token actions etc.. designed for game play.) You can't let the door DL paths and door image link get broken... and the id's change. Hate the GM notes because people use them in API for this, that, the other thing... etc. For the path you can tuck the door image ID in the "controlledby" property. But that is the "created id" that will be different on the other side of the transmogrifier. Going to use the name property of the graphic (pipe delimited): someVariable | someOtherVariable |createID The door path will always belong to that graphic because the "created id" wont change in its "controlledby" property, and the third argument in the image name property will be the same "created id."

I'm not seeing the benefit of stuffing things in the 'controlledby' property. Just stuff it in the gmnotes and endure the parsing. If you're trying to preserve player IDs, go for universal roll20 user ids instead if you can capture them, else just rely on display name which is pretty bad, but all you have. Edit: you can also just stuff them in attributes if value-key is your thing. :)

Path has no GM notes

Given that you're wanting to preserve links between objects across ID changes, it might be better to implement your own save/load functionality: gather all the properties of the objects you care about (e.g. a list of all the paths and the doors to which they link) into some data structure, dump it out as JSON (e.g. into a handout), then use that to regenerate all the objects on the other side. In other words, instead of trying to send the objects themselves over (and dealing with ID changes, etc. in the process), just send over the instructions for how to set the objects up.