HoneyBadger
said:
Riley D.
said:
You can also store information on specific objects, for example by doing state[obj.id] = {moved: true}
Does this mean I can store attribute like values on tokens instead of journals for my monsters? For example, I'm adding !+thp and !-thp chat commands to my 4e toolbox and it would make using temp hp powers on monsters easier to use if this is true.
I'm not sure I totally understand the question. But, to hopefully help clarify, the state object is a totally separate object from anything else. However, every ID in the system (e.g. the ID of a token, the ID of a character, etc.) is globally unique. So what you can do is store information about a token, for example the number of temp HP remaining, in the state object at state[obj.id]. The state object is saved between sessions now, so when you next play it will still have that value.
So that begs the question -- what should I store in the state object, and what should I store on the token itself? Basically, you should store values on the token that match token properties and you want players to have access to change So if you want to track TempHP in Bar2 so that players can change it as well, store it there. If you don't want the players to have access to change the TempHP directly, only through chat commands, store it in the state object, since only the API can change those values. You wouldn't want to, for example, store the number of steps a patrolling token has taken in Bar3, as that has nothing to do with what the players want to edit in-game.
Especially this should cause you to not store things like JSON strings in the Notes or GM Notes fields, as again those aren't intended for that and I can't guarantee something I do in the future wouldn't break your ability to store things there.
Hope that helps, let me know if it didn't :-)
