Full Bleed wrote:
1) Under Edit>Preferences>Interactions several of the drop down selections don't show all of the text of the selection.
I'll add a tracker
Full Bleed wrote:
2) Shouldn't the black "string" line that shows the path you're dragging an image render from the center of the image?
Good catch. Yes, it should. I made a fundamental change with this release, tokens are rendered anchored from their center instead of the top left, which means I had to shift everything to the left and up by half the token, but missed the non snap-to-grid path. This is fixed for build 10
Full Bleed wrote:
4) I tried setting up an image of a large token in the token>config>layout box and found that there was a limit to the size I could blow the image up to properly fit in the base-box size I choose (large.) I think we need to be able to make it even larger than the current implementation allows.
I did put in a limit. I figured that to make them bigger you would use the Sizes in the token right click menu. I wanted to keep the relative size roughly close to the specified size. I could increase the cap slightly though if you feel strongly about it.
Full Bleed wrote:
it's great to see you tackling this feature. This was always one of my concerns with MT's token usage.
All of those Macro suggestions are great. I'm really eager to be able to edit them in a text format as discussed in that thread and I'm really eager to have multiple submenus for less-often used macros but ones you still would be interested in.
One thing to consider, especially if you implement the above, is that we're all probably starting to use the token macros more and with the new cool cell bleeding features the need for a .token format to import/export will start jumping ahead of other features in our minds.
All of this is good discussion... what a great job we all do fine tuning the features
2. Character sheet. This is lovely, but it would be even better if we could minimise it.
Where should it minimize to ?
Bottom or side for preference. Isn't the eventual plan to have a semi-permanent character sheet window? In which case it would be dockable like the chat, macro and image explorer windows? It just seems like such a useful feature that you'd want it around all the time.
8. Wouldn't it be more useful to have the /tmacro target the impersonated token rather than the selected token? If I have to click on a token before running this command, then I might as well right-click to get the macro.
I believe hawke also suggested this. I could have it start by looking at the currently impersonated token, and if it's not found then use the selected token ?
That sounds good to me.
9. When using /tmacro it doesn't seem to run quite the same command as running the macro from the token menu. When you look at the previously run command it gives /im C10058(.......):
This is expected, the long number is the token ID to make it possible to directly indicate which token instead of relying on name resolution. It's mostly hidden and can only be retrieved by using your chat history. I'm not terribly worried about it. But if it's a strong concern we can look at doing something different
No, it's fine as is. I just came across it when trying to figure out how it assigned a target for /tmacro and it looked wierd so I thought I'd ask.
I'm right behind Hawke on the idea of a .token format. With all the fun new features popping up around tokens, exporting and importing them is starting to become quite important.
torstan wrote:Bottom or side for preference. Isn't the eventual plan to have a semi-permanent character sheet window? In which case it would be dockable like the chat, macro and image explorer windows? It just seems like such a useful feature that you'd want it around all the time.
From my experience with other VTTs I can say that 'most' people do not keep them up all the time, so the ability to dock it is not that important to me, and I rather like how it is now, just a pop-up we can get to when we want. We DO need a keyboard shortcut though, that would top it off and make it perfect.
torstan wrote:I'm right behind Hawke on the idea of a .token format. With all the fun new features popping up around tokens, exporting and importing them is starting to become quite important.
I fully agree, we need to work towards being able to export tokens with properties, character sheets, etc intact. As we start moving along you are going to see more and more people building large libraries of tokens and they are not going to want to have to rebuild these all the time.
dorpond wrote:
1. Spacing/Movement path seems broken. I used this image (great to test with)
Notice how when I move the medium sized token, it is showing as taking more than one cell space.
Interesting. And it's not set as something other than medium ? I'll play with it.
I'm seeing that same bug in hexes, with the movement path being one hex offset (rather than highlighting two hexes)
Full Bleed wrote:
4) I tried setting up an image of a large token in the token>config>layout box and found that there was a limit to the size I could blow the image up to properly fit in the base-box size I choose (large.) I think we need to be able to make it even larger than the current implementation allows.
I did put in a limit. I figured that to make them bigger you would use the Sizes in the token right click menu. I wanted to keep the relative size roughly close to the specified size. I could increase the cap slightly though if you feel strongly about it.
Well, I don't know how strongly I feel about it so much as the first token I tried to use it with wouldn't quite work without me setting the creature to a size that didn't reflect the size category that it actually is.
A horse with a rider on back and a lance or sword hanging out of the base-box is doable... but a Pegasus with a large wingspan isn't. If you look at the griffin image I posted, you'll actually see that the wingspan is collapsed in a U shape... if the image was rendered in a full span gliding pose the problem would be even worse. I'd have to set a "large" creature to a size category 2 or 3 sizes bigger than it should be set at to get an accurate representation. And I suspect that some Dragon poses will run into the same problem... (or anything with significant out-of-cell image data.)
Full Bleed wrote:
Well, I don't know how strongly I feel about it so much as the first token I tried to use it with wouldn't quite work without me setting the creature to a size that didn't reflect the size category that it actually is.
This is a good case. I've increased the cap for build 10
wrathchild wrote:Also, the Sizes are very much a d20 thing.
While the semantics may be based on a d20 standard, as far as I'm concerned it's really most useful in having some kind of system that defines relation of proximity and size for every token on a grid or hex table-top.
If I can't easily define my Griffon's "body" as being basically twice the side of a human, and the computer can't recognize exactly how that takes up space in relation to other tokens (i.e. knowing what's adjacent to what), then there are significant problems with achieving any kind of top-down accuracy (regardless of the system being used.)
Full Bleed wrote:
While the semantics may be based on a d20 standard, as far as I'm concerned it's really most useful in having some kind of system that defines relation of proximity and size for every token on a grid or hex table-top.
Additionally, it helps to determine base size (although it could be argued that a more generic system could be used here instead)
dorpond wrote:
2. Overlaping tokens. Notice in this capture that the cells are not even close to each other but yet it is showing that they are overlapping.
OK, for 1.3b10 I've updated the logic to only show the stack icon if one token totally covers another token, which drastically reduces the number of stack icons. Try out the new version and we'll see if we need to further tweak it
