From one running program to another (maptools of course)

[aliasmask]

Well, there's nothing really stopping you from copying all the parts of a token to your db and back again. The only realistic thing you can't do is token image offsets but that should be an exception rather than the rule anyway. You mentioned order of operation and you're right, some things you just can't realistically do to a token after the copy so it needs to be done before and those things are the ones that force a token redraw. Since the most recent update, setting an image (and size?) was taken care of, so that was the only major issue in my mind. I think draw order would be another thing, but since a copied token is always on top, not much you can do about that. I took care of states with my createToken function and it does update the blank token states copies, then clears them which is relatively easy to do.

Now other core properties that require a function to change like setNotes or setGMNotes would be another thing that I didn't include in my createToken function that may require an order of operation, but I haven't tested it. The one problem with the order of operation is that your blank token may not be on the current map and things like setNotes will not work on it. The other problem drawing from a blank token is that multiple players will be accessing and updating it, sooo... we need unique blank tokens first. We can solve both problems by first copying the blank token to current map with a player unique name like blank_[playerName].

It would be nice to copy it, do your stuff, and delete it but we run in to the order of operation problem again and modifying a token during the same macro chain, or even slightly deferred is problematic because of timing issues. So leaving a copy of a blank token for each player on each map would be the most useful, but IMO is kind of like leaving trash around and will require a separate process to complete. It could be a dedicated macro or a part of another automated process. If you're going to have players with a frame that handles event handlers that would make things easy, otherwise you could integrate it with moveTokenToMap/moveTokenFromMap where you make your checks and possible copy a blank player token for that map. I have another project in mind that I actually will keep track of players and which map they currently are on and this will be a similar process.

Code: Select all

[H: '<!-- List of Arguments Possible createToken(updates): id
      name - Name of token
      owner - json array of owner ("" or name begins with "lib:" set to no owner, no default owner)
      map - map name to move token to 
      target - name of token on current map OR x,y coords
      offset - x,y coord offset (always relative to target, uses useDistance metric)
      useDistance - 0 (grid x,y), 1 (gridless x,y)
      props - json of props to be set on token created
      states - json array of states to be set on token created
      layer - layer for token to be created on
      facing - facing of token
      size - size of token
      label - label of token
      gmName - gm name of token
      tokenImage, portraitImage, handoutImage - token images
   -->'] 

[wolph42]

I can see what you mean there, about databases, but it runs contrary to the overall.. objective (I suppose might be the word) of what I'm trying to do.

It's about customization, and creating an individual token. It becomes it's own creature, and the story moves with it. If you call it up later, it still has it's old wounds, the story you put in the gm notes.. even the arrows that got plunked into it.

If I could manage that with a table, I suppose I would. But it seems to me that I'd have to add a myriad of updates to each monster or char after generating it from the table, so I might as well just make the whole thing into a handheld token.

whether you create one big set of token properties and apply them to seperate tokens
or
you create one big set of json object fields and store them all into one big table
really does not make that much difference from a coding perspective and, depending on wishes for implementation, for the GUI as well.
Personally I would go for the AM version as its much more mobile then a big bunch of seperate tokens. If you still want to work with tokens then you can also consider (as I mentioned earlier) that you run 2 clients connected to the same server. This way a player can fiddle on one map with his goodies and have the battle on the other map. (you have to take care of ownerships and the lot, but thats doable). It *will* however have an impact on the traffic speed!

edit: missed AMs post so I possible ninja...

[Archeic]

Yes, I'm starting to see the value here of AM's method. As for the blank token though.. well, things get tricky there because of the offset. I can't have just 1 per player. I need 40 total (1 for each offset size). This is pivotal to my coding, because it allows for an amazing thing to happen. It lets me use an object of the exact size that I want. No empty space. so, a head on a body is not a full token with empty space; it's just got a smaller offset and tied to the rest of the tokens. I can rotate the group flawlessly (not just in snap to grid, but however I like, and at literally any angle)

To keep this functionality, I have to write over the blank token of the appropriate offset. Thankfully, ownership really isn't an issue here. It's because the master token is the only one that needs to be owned. It delegates to the rest, so that's a happy coincidence.

I think I'll give this a look and see what I can do with it, since it seems the most practical approach.

But, there is one hiccup I know I'm going to run into. That's the setting of properties. I can't seem to set properties very well. I attempted to add an "if/then" snippet that checks to see if the property was empty, and then to reset the property.. It works with mixed results, usually breaking for no apparent reason. The issue is that I want the default values to be in there, as if the fields were "NULL", but instead, my fixes set it to blank; "", or simply.. don't work. You can see this on my "++sizing up! +" macro in my campaign file. the if/then is the cause of that error, and I know I'm going to have to fix it to do anything... but.. *shrugs* I spend a day on the issue and only seemed to make it worse.

[aliasmask]

But, there is one hiccup I know I'm going to run into. That's the setting of properties. I can't seem to set properties very well. I attempted to add an "if/then" snippet that checks to see if the property was empty, and then to reset the property.. It works with mixed results, usually breaking for no apparent reason. The issue is that I want the default values to be in there, as if the fields were "NULL", but instead, my fixes set it to blank; "", or simply.. don't work. You can see this on my "++sizing up! +" macro in my campaign file. the if/then is the cause of that error, and I know I'm going to have to fix it to do anything... but.. *shrugs* I spend a day on the issue and only seemed to make it worse.

I'm not sure how dynamic you are making your token types, but just having a list of the property names that are always NULL should do the trick. So, when assigning values to props on new token you'll have your list of prop keys, do a json.difference of the null keys and rebuild the json or use json.intersection and do a loop to json.remove those keys.

Oh, and about the token size offsets and blanks in general, you could just have a second instance who is considered the server (first instance actually). That way, all the hinky stuff I suggested can be avoided if all the processes were sent to the server only to execute. The server will be spammed with executable links from all the players but executed in order as to not conflict with anything. Also, a bunch of map flipping to make sure things were being done on the correct screen. The maps don't usually load, just a screen flicker, but since it's not a player it wouldn't be too much of an annoyance. Just a thought.

I was thinking of doing this myself. Also, after the players sign on they get a splash to log in and retrieve their character stuff. That way they won't necessarily have to log on as the same person each time. I would like to keep all the token info on lib tokens and they would have a character sheet interface to manipulate their tokens. The actual image would have no character data. I was thinking of doing this to put player tokens on the image layer and having a blank control token hover over their picture for movement. I was thinking of doing this mostly for an iso environment, because of vbl issues and big or oddly sized tokens. I may never get around to doing it, but I have given it some thought on how to do it.