MapTool 1.3 Bugfix Build 77

[LaserWolf]

Is there any chance that it was user error? i.e. you thought you hit meta-c but missed? or didnt actually make contact? indication such as it being the LAST token you copied, instead of the new one?

Absolutely not a missed keypress, no. I tried a number of times, using both Ctrl-C and the Copy option from the token context menu. I tried on the same map, across different maps, and across different campaign files and it repeatedly failed. If it was a one-time thing I hardly would've noticed, let alone posted about it.

And yes, the majority of the attempts were made within the same instance of Maptool. I did try copying from a second instance once, just as a "maybe this will work." When I was referring to tabbing back and forth between applications, I was referring to switching between MapTool and Adobe Acrobat, from which I was repeatedly copying and pasting pieces of text at about the same time that I had the copying issue. I thought that maybe I had hit Ctrl-C/V in the wrong window or wrong pane while I was jumping back and forth and that maybe that created an issue with MT's internal clipboard. I know that the copy function was fixed to prevent overwriting with an empty selection. Anyway, sorry for that confusion.

Sorry I don't have any more info, you guys, but I wasn't able to reproduce the error either. I'll try pinging my player to see what he was doing when he had the issue in his campaign, and try and figure out what we were doing in common. I know that he was not switching between campaign files. I also know that in both cases we were resuming a campaign in the middle of a fight, so we had initiative up. We also both had text boxes on the map that were deleted at the beginning of the session. I don't know that any of that's relevant - just tossing things out.

[aliasmask]

@Az - Oh I would like to point out that the color "green" for the button isn't the correct html color, but is the same green as MT had before. You'll notice that lime is the same color for the button. The "green" font is correct. Is this something that'll you'll fix/change?

[Azhrei]

@Az - Oh I would like to point out that the color "green" for the button isn't the correct html color, but is the same green as MT had before. You'll notice that lime is the same color for the button. The "green" font is correct. Is this something that'll you'll fix/change?

Um, what? Without any context, I'm not sure what we're talking about?



Assuming that you're referring to the ability to type your own color into the Button Color field when editing a macro... Whatever the user types into the color field (or chooses from the dropdown list) is inserted into the CSS color field for the button. So if the CSS "green" isn't really green, it's probably not something we can fix.

Edit: Actually, I think I see what you're talking about. The "green" color comes from Java's built-in Color.GREEN which is rgb(0, 255, 0) in CSS parlance. The color "lime" is hard-coded to be rgb(0, 255, 0) as well, probably due to this reference. It appears that the actual color that should be associated with "lime" is a bit muddy. However, I've changed the code to use rgb(191, 255, 0) which will be the darker green color shown at the beginning of that web page.

[aliasmask]

I just compiled a color chart in case you're interested in the differences.

color chart.png (20.15 KiB) Viewed 2407 times

Notice some of the fonts don't translate. I also tried using #000000 syntax for the font which also doesn't work.

[Craig]

@Az - Oh I would like to point out that the color "green" for the button isn't the correct html color, but is the same green as MT had before. You'll notice that lime is the same color for the button. The "green" font is correct. Is this something that'll you'll fix/change?

Um, what? Without any context, I'm not sure what we're talking about?



Assuming that you're referring to the ability to type your own color into the Button Color field when editing a macro... Whatever the user types into the color field (or chooses from the dropdown list) is inserted into the CSS color field for the button. So if the CSS "green" isn't really green, it's probably not something we can fix.

Edit: Actually, I think I see what you're talking about. The "green" color comes from Java's built-in Color.GREEN which is rgb(0, 255, 0) in CSS parlance. The color "lime" is hard-coded to be rgb(0, 255, 0) as well, probably due to this reference. It appears that the actual color that should be associated with "lime" is a bit muddy. However, I've changed the code to use rgb(191, 255, 0) which will be the darker green color shown at the beginning of that web page.

Uhoh... I see people complaining that in the new build the green wasnt the green that they had before and now they can't read the text on them.

[Azhrei]

Heh, okay. So there are four additional instances where the Java built-in colors don't match the HTML colors. I've replaced the built-in values with the ones from the HTML standard.

Uhoh... I see people complaining that in the new build the green wasnt the green that they had before and now they can't read the text on them.

Oh well. It was a bug and now it's fixed. They can always export their macros and global-search-and-replace to change color values if they really want to.

[Amaril]

I haven't looked to see if this has been reported already, but I'm posting it anyway.

Just recently I had discovered an issue that changes one of my cone aura definitions to a circle after saving the campaign properties. I'm not sure if it's because the campaign file has been one I've been working on across different versions of 1.3 or if it's a bug with the current build.

[aliasmask]

@Az - I'm trying to come up with a conversion metric from pt to px which should be 12pt = 16px but you'll notice if you create 2 buttons with the same text and make one 12pt and the other 16px, the 16px is much larger. Actually, the 16px is correct but the 12pt is smaller than it should be. It's about 58% of the size it should be. I was wondering why the 8pt I was putting in there was barely legible.

Actually, I answered my own question. So, no need to tweak it, but my observation is valid.

[Azhrei]

I haven't looked to see if this has been reported already, but I'm posting it anyway.

Yes, it has. And it's been fixed already. But thank you for reporting it again -- better twice than never.

[Azhrei]

you'll notice if you create 2 buttons with the same text and make one 12pt and the other 16px, the 16px is much larger.

Well, you said you "answered your own question" so I presume you know why the 16px is larger than 12pt and I don't need to go into it.

And once people think about it enough they'll understand why using physical units (such as "px") is a Really Bad Idea. I wish I could beat that into the brains of web site designers though.

[aliasmask]

<FYI>
It's ugly, but here's my conversion formula to "guess" the total pixel width of the text of a macro.

Code: Select all

[H: str = arg(0)]
[H, if(argCount() >= 2): size = arg(1); size = "11pt"]
[H: value = replace(size,"[^0-9]","")]
[H: metric = replace(size,"[^a-z]","")]
[H: macroNamePx = am.test.mtVarPixelCount(str)]
[H, if(metric == "em"): macroNamePx = round(macroNamePx * pow(value,3))]
[H, if(metric == "" || metric = "pt"): macroNamePx = round(value * macroNamePx / 11)]
[H, if(metric == "px"): macroNamePx = round(value / 8.5067 * macroNamePx)]
[H: buttonRange = "200,147,94,40"]
[H: minWidth = ""]
[H, foreach(min,buttonRange), code: {
   [H, if(macroNamePx <= min): minWidth = min]
}]
[H: macro.return = minWidth]

Basically, it accepts a string, assigns a standardized pixel width to each character and sums up the string at 11pt. Does some conversions based on the metric then picks the best button width. "em" is cascading thus it does a pow to convert and pt is reduced to 58% in respects to px size (58% of 14.66 for 11pt). It's not exacting, but it gets within 4 pixels and usually over.
</FYI>

[JonathanTheBlack]

Personally, I absolutely loathe buttons of varying width. It's ugly and disorganized and looks like crap. It makes it much harder to find anything and honestly, that's why I started writing my own framework instead of using ones provided by others. I couldn't stand the layout of their macro buttons.

[aliasmask]

Personally, I absolutely loathe buttons of varying width. It's ugly and disorganized and looks like crap. It makes it much harder to find anything and honestly, that's why I started writing my own framework instead of using ones provided by others. I couldn't stand the layout of their macro buttons.

That's what the above code does. Makes the buttons look nice and symmetrical.

[aliasmask]

Edit: Actually, I think I see what you're talking about. The "green" color comes from Java's built-in Color.GREEN which is rgb(0, 255, 0) in CSS parlance. The color "lime" is hard-coded to be rgb(0, 255, 0) as well, probably due to this reference. It appears that the actual color that should be associated with "lime" is a bit muddy. However, I've changed the code to use rgb(191, 255, 0) which will be the darker green color shown at the beginning of that web page.

Not to beat a dead horse, but are you using X11 colors instead of HTML? I see that you changed lime, which was actually correct before. It's the green button color that is off. The green font color is correct and the value should be rgb(0,128,0) for green. Lime is rgb(0,255,0).

edit:

• Font Color - Since no other codes work for font color, no need for text list box or to append invalid values to the list. Just limit it to the colors in the list for the font. In my opinion, more font colors aren't really needed. Also, these colors don't work for fonts that are in the list: cyan, darkgray, lightgray, magenta, orange, pink or any color formats (#000000). I suggest below to remove magenta and cyan from both lists because of duplication. The other colors would need to be hard-coded and defined.
• Font Size - EM values are pretty much useless because of the cascading. Can you change the core list to pt values. I don't know what is involved, but I noticed the core list is the only thing listed in the dropdown and the current value, if not in the list, it gets listed in the text box area. So, that shouldn't effect current macros.
• Button Color - Other than the greens (green and lime described above) and the duplication of the cyan and aqua, fuchsia and magenta, it works well putting in custom color formats (#000000). I noticed things like "darkblue" aren't defined, but that's no big deal. I would recommend ditching cyan and magenta from the list because their font colors don't work anyway. We would need to test if the color name will still work for the button. I would guess so because they're already defined. Just no need to include them in the list.
  
  Also, it's weird how darkgray is lighter than gray in HTML color name colors. If we something equivalent to the older color, but to maintain HTML color names, dimgray is rgb(105,105,105).

[JonathanTheBlack]

I would like 100% control over the font and button colors via html/css. Limited lists are well, limiting.