MapTool 1.3 Final, patch04 (build 87)

New build announcements plus site news and changes.

Moderators: dorpond, trevor, Azhrei, Craig

Post Reply
User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: MapTool 1.3 Final, patch04 (build 87)

Post by Full Bleed »

Azhrei wrote:Are you saying that the two are different? I've never noticed.

I thought I had added a single ColorNames table somewhere and had changed all the references to use that table. (You caught one mistake with Grean => Lime.) So if Dark Gray doesn't mean the same thing in both places, it should and that's a bug to be fixed.
The "Dark Gray" in the Halo picker is very Dark Gray. The Dark Gray web standard isn't. So, I suppose you could "fix" it, but you'd be making it less sensible and may as well just go with Gray if you must (which would still be significantly lighter than what's in the picker right now.)

Edit: FYI, what's in the halo picker right now is 82% Gray, whereas the html Dark Gray is about 40% Gray.

However, it makes sense that the HTML frames use the same color set as the W3C standards. And it makes very little sense for the macro buttons themselves (which, incidentally, are colored by using HTML attributes) to use a different set.
Spoken like a true code monkey. ;)

But I'm going to disagree. Programatically you're right. But from a UI standpoint it makes very little sense for a typical user to assume that "Dark Gray" would be lighter than "Gray" when they are picking colors for buttons from a text drop down (unless they are familiar with the anomaly in the web standards... an unfriendly assumption, imo.) And even if you put in a color picker with a text name overlay (as in the halos), you're going to end up with a lot of users going, "Looks like they switched up Dark Gray with Gray."

I expect MT's macro script to adhere to the webstandards when using html color codes, I don't expect an interface like that to do so.

If you can't bring yourself to have it make sense from a layman's perspective why not do what many graphical programs do and call the grays something like "25% Gray", "50% Gray", and "75% Gray." That would be more accurately descriptive for more users.
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Final, patch04 (build 87)

Post by Azhrei »

Full Bleed wrote:[...] why not do what many graphical programs do and call the grays something like "25% Gray", "50% Gray", and "75% Gray." That would be more accurately descriptive for more users.
Heh, that makes sense. I'm not sure they can start with a digit (never checked that), but they can certainly be called Gray25, Gray50, and Gray75. :)

I think if the user enters a custom value and that value happens to match an existing entry in the ColorNames array, it'll be changed to use the name. So using these 25/50/75% values seems reasonable. I'll take a look at this.

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.3 Final, patch04 (build 87)

Post by Lee »

Azhrei wrote:"Soon, grasshopper. Soon."

I've only got two bugs left to fix but one of them is kind of a stinker. :|

I'm planning to work on MT tomorrow 'cuz I have some time in the afternoon, so there could be a new build by the end of the week. I've been posting in the Testing subforum but haven't gotten any bug reports on those patches yet. I'm not going to do a b89 so "speak now or forever hold your peace". 8)

(The two bugs on are the square/hex movement, and two HTML frame issues with title= and temporary=.)
Hi Azhrei,

I just wanted to ask if this bug has been rendered officially dead :D I've tried going through some of the changelogs per SVN but I really have no time these days. Thanks!

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Final, patch04 (build 87)

Post by Azhrei »

Lee, I have it marked as "fixed" in my list and a quick test showed that closing the window doesn't cause an exception. Anyone with SVN access please verify my findings? Thanks. :)

Alias, regarding the temporary attribute of HTML frames... It appears that the wiki is wrong. There is no temporary attribute for frames. Here's the code that actually creates the frame or the dialog:

Code: Select all

if (isFrame) {
    HTMLFrame.showFrame(name, title, width, height, html);
} else {
    HTMLDialog.showDialog(name, title, width, height, hasFrame, input, temporary, closeButton, html);
} 
As you can see, the temporary value is never given to the code that creates the HTMLFrame object. That means the only way to cause a frame to "forget" about it's previous size/position is to use Wiki: resetFrame() or Wiki: closeFrame() on it.

The problem with the title not updating was a missing function call. I've added that and this will be part of b88. Anyone using source code, please verify SVN 5838. Thanks everyone! We're making progress!

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: MapTool 1.3 Final, patch04 (build 87)

Post by aliasmask »

Azhrei wrote:Lee, I have it marked as "fixed" in my list and a quick test showed that closing the window doesn't cause an exception. Anyone with SVN access please verify my findings? Thanks. :)

Alias, regarding the temporary attribute of HTML frames... It appears that the wiki is wrong. There is no temporary attribute for frames. Here's the code that actually creates the frame or the dialog:

Code: Select all

if (isFrame) {
    HTMLFrame.showFrame(name, title, width, height, html);
} else {
    HTMLDialog.showDialog(name, title, width, height, hasFrame, input, temporary, closeButton, html);
} 
As you can see, the temporary value is never given to the code that creates the HTMLFrame object. That means the only way to cause a frame to "forget" about it's previous size/position is to use Wiki: resetFrame() or Wiki: closeFrame() on it.

The problem with the title not updating was a missing function call. I've added that and this will be part of b88. Anyone using source code, please verify SVN 5838. Thanks everyone! We're making progress!
Okay, if Wiki: resetFrame() worked that way, that would be fine too. If I create a frame and move it to a new location, then close it. resetFrame will have it reappear at the last saved position. It doesn't reset the size or position. Also, the new frames upper left corner appears in the upper left corner. Is there a way to have it appear centered like the dialog? But that only needs to be done if the user can make it forget the frame's size and position. Currently, there is no way to do that.

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: MapTool 1.3 Final, patch04 (build 87)

Post by aliasmask »

Also, as a last request. Can you have the Wiki: getImage() and getTokenImage return blank if the image name or impersonated token is invalid. Now it just aborts execution and sends a message to chat. Putting a try/catch around this would be super simple I believe. Returning blank is much more useful than dropping out of execution.

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Final, patch04 (build 87)

Post by Azhrei »

aliasmask wrote:If I create a frame and move it to a new location, then close it. resetFrame will have it reappear at the last saved position.
Hm. The HTMLFactory class keeps track of which frames and dialogs have been created (using the name as the key field). I would have thought that closing them would cause that entry to be deleted. Since your frame comes back at the same place that apparently isn't happening. That's probably a bug.

I'll check the code. If the frame/dialog is removed from that list it would need to be recreated again when it was reopened. This is what the "temporary" flag does on dialogs -- it causes the entry to go away when the dialog is closed. The frame is probably missing similar code. This should be easy to fix if that's all it is.
aliasmask wrote:Can you have the Wiki: getImage() and Wiki: getTokenImage() return blank if the image name or impersonated token is invalid. Now it just aborts execution and sends a message to chat.
Yeah, throwing an exception is probably the wrong way to handle it (duh!) since there's no way to catch that in MTscript.

I suppose you could check first to determine if the token id exists (using Wiki: getTokens(), for example). And if you're going to need to check for the empty string return value anyway, maybe the pre-check is the better way to go. Comments?

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: MapTool 1.3 Final, patch04 (build 87)

Post by aliasmask »

Precheck works okay with getTokenImage since the check is for current map, but not so much for image token. It's not very viable if I have to check each map for image:tokenName. Now if getInfo returned image token names too, then that would be a way to check it. I would need to set up my own db for the image tokens. But I think it's much easier if the getImage just returns blank than doing that.

Code: Select all

[H: imageId = getImage(userImage)]
[H, if(isEmpty(imageId)): imageId = getImage(defaultImage)]

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: MapTool 1.3 Final, patch04 (build 87)

Post by aliasmask »

Ack! Can't load a campaign. here is the error:
Could not load campaign.
java.io.IOException: Map failed
The only thing I can think of that might have caused this is I moved a resource library. I have a library called images which pointed to a folder on one drive. Storage was getting low there, so I moved it to another drive and re installed resource pointing to new drive. But this is the only campaign that I've had a problem with.

Looking at the log file:
2011-12-03 13:58:37,421 [client.MapTool:291] ERROR - msg.error.failedLoadCampaign
java.io.IOException: Map failed
at sun.nio.ch.FileChannelImpl.map(Unknown Source)
at sun.nio.ch.FileChannelImpl.transferFromFileChannel(Unknown Source)
at sun.nio.ch.FileChannelImpl.transferFrom(Unknown Source)
at org.apache.commons.io.FileUtils.doCopyFile(FileUtils.java:813)
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:783)
at net.rptools.lib.FileUtil.copyFile(FileUtil.java:344)
at net.rptools.lib.BackupManager.backup(BackupManager.java:72)
at net.rptools.maptool.client.AppActions$72.run(AppActions.java:1975)
Caused by: java.lang.OutOfMemoryError: Map failed
at sun.nio.ch.FileChannelImpl.map0(Native Method)
... 8 more
Okay, after looking at that I closed some of the pdf documents and other programs running and the campaign loaded. It's odd though, because I have another campaign that worked fine that was virtually the same except for a couple of macros.

False alarm. Fixed the problem when writing my post, but could be useful to post in case it happens to someone else.
Last edited by Azhrei on Sun Dec 04, 2011 6:39 pm, edited 1 time in total.
Reason: highlighted the root cause

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.3 Final, patch04 (build 87)

Post by Lee »

Azhrei wrote:Lee, I have it marked as "fixed" in my list and a quick test showed that closing the window doesn't cause an exception. Anyone with SVN access please verify my findings? Thanks. :)
!
Confirmed Azhrei, and it works as it should; returning 0 when a user uses the "X" to close the input window. Sorry for the late reply, I had to setup my Eclipse environment to check it out. Thank you for this :)
Last edited by Lee on Sun Dec 04, 2011 11:13 pm, edited 1 time in total.

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: MapTool 1.3 Final, patch04 (build 87)

Post by aliasmask »

Related to the frame issue. One of my players on a MAC kept having his new windows appear in the upper left corner, but the top bar was above the screen. So he couldn't move it or close it. I'm not a Mac person so I couldn't give him advice on this, but having new frames appear centered the first time like dialogs would resolve that in any case.

Anyone have any advice on how to get past this on the mac?

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.3 Final, patch04 (build 87)

Post by Lee »

Sorry to add to your list Azhrei, but I caught another input related "error" on the latest build. If a Check option is the first item on an input's string parameters, it defaults focus on itself rather on the the 'Ok' button. 1.3b86 has "proper" behavior and defaults on the' Ok' button :)

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MapTool 1.3 Final, patch04 (build 87)

Post by Azhrei »

aliasmask wrote:Related to the frame issue. One of my players on a MAC kept having his new windows appear in the upper left corner, but the top bar was above the screen. So he couldn't move it or close it. I'm not a Mac person so I couldn't give him advice on this, but having new frames appear centered the first time like dialogs would resolve that in any case.

Anyone have any advice on how to get past this on the mac?
I haven't seen that. I have had frames appear in the upper left but the title bar on the window was always accessible so it could be dragged into place. And all frames should be appearing centered over the MapTool window in b88+ (already in SVN). In addition, dorpond found a problem with the token editor dialog popping up off the top of the screen when the MapTool window was tiny and up at the top -- the function for centering the dialog wasn't taking into account a negative (x,y) coordinate (it does now).
Lee wrote:Sorry to add to your list Azhrei, but I caught another input related "error" on the latest build. If a Check option is the first item on an input's string parameters, it defaults focus on itself rather on the the 'Ok' button. 1.3b86 has "proper" behavior and defaults on the' Ok' button :)
That's interesting. I know there's special code handling checkboxes in the input function. The comments say that focus handling wasn't working in HTML so there was a hack added to make it function properly. Maybe I screwed something up when I changed it so the window would always scroll to the top instead of the bottom... Thanks, I'll take a look.

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: MapTool 1.3 Final, patch04 (build 87)

Post by aliasmask »

Azhrei wrote:And all frames should be appearing centered over the MapTool window in b88+ (already in SVN). In addition, dorpond found a problem with the token editor dialog popping up off the top of the screen when the MapTool window was tiny and up at the top -- the function for centering the dialog wasn't taking into account a negative (x,y) coordinate (it does now).
(Grabs Az's nerd dictionary from the 80s) Cool beans, thx. Looking forward to this next and potentially final release (crosses fingers and hopes nothing horrific happens).

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: MapTool 1.3 Final, patch04 (build 87)

Post by Lee »

Azhrei wrote:
Lee wrote:Sorry to add to your list Azhrei, but I caught another input related "error" on the latest build. If a Check option is the first item on an input's string parameters, it defaults focus on itself rather on the the 'Ok' button. 1.3b86 has "proper" behavior and defaults on the' Ok' button :)
That's interesting. I know there's special code handling checkboxes in the input function. The comments say that focus handling wasn't working in HTML so there was a hack added to make it function properly. Maybe I screwed something up when I changed it so the window would always scroll to the top instead of the bottom... Thanks, I'll take a look.
Hmm, it seems it goes beyond just checkboxes. Radio button behavior is affected as well. When a radio item is selected, it keeps focus when the Enter key is hit as opposed to transferring it to the 'Ok' button in the past. Conversely, when nothing is selected, hitting 'Enter' works just fine :)

Post Reply

Return to “Announcements”