Actually, that sounds like a pretty major change in functionality. A check should be able to be put in to detect the OS if the centering is only needed for Macs.Omethiklan wrote:I mean that is a minor inconvenience all in all, but an inconvenience nonetheless as one was accustomed to not have this issue...
MapTool 1.3 Final, patch06 (build 89)
Moderators: dorpond, trevor, Azhrei, Craig
- Full Bleed
- Demigod
- Posts: 4736
- Joined: Sun Feb 25, 2007 11:53 am
- Location: FL
Re: MapTool 1.3 Final, patch05 (build 89)
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."
Re: MapTool 1.3 Final, patch05 (build 89)
+1Full Bleed wrote:Actually, that sounds like a pretty major change in functionality. A check should be able to be put in to detect the OS if the centering is only needed for Macs.
Re: MapTool 1.3 Final, patch05 (build 89)
Yeah, it sounds like the fix was added to the wrong place. It should only apply to the first opening of a frame. There's a hash table that keeps track of which frames already exist so this patch was probably put above that check instead of below it. Oops.aliasmask wrote:It was a problem for Mac users that frames showed up in upper left corner where the border was outside of where it could be grabbed and moved. I think the fix was to simple rest frames and center (although, I'm not a fan of the frame reset once defined). I did find a work around to the Mac issue by using Wiki: resetFrame() which I think is how the fix was applied, but I don't know for sure.
I'll take a look at that patch and see about moving it.
Thanks for finding it!
Re: MapTool 1.3 Final, patch05 (build 89)
We've said lots of thanks to the folks bending code - and that is very much deserved.
I'd like to take a second and thank all the folks downloading and testing the new build. Your efforts make our (meaning the community our) product better for everyone else. You guys rock.
Thanks!
I'd like to take a second and thank all the folks downloading and testing the new build. Your efforts make our (meaning the community our) product better for everyone else. You guys rock.
Thanks!
Re: MapTool 1.3 Final, patch05 (build 89)
So, does the latest download include the ability to use the MapToolLauncher.exe with the latest version of java 7? Or is the wildcard problem still an issue?
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: MapTool 1.3 Final, patch05 (build 89)
Still an issue. Get lee's launcher or use the .bat.aliasmask wrote:So, does the latest download include the ability to use the MapToolLauncher.exe with the latest version of java 7? Or is the wildcard problem still an issue?
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
-
- Kobold
- Posts: 17
- Joined: Mon Jan 26, 2009 3:58 am
Re: MapTool 1.3 Final, patch05 (build 89)
There seems to be an issue with multiple dice rolls surrounded by whitespace in the same evaluated string. I've managed to reduce it to these test strings:
a [1] b [1] produces a 1 bb 1
this compounds as you add more rolls:
a [1] b [1] c [1] produces a 1 b 1 cb 1 cc 1
but there must be at least two rolls with whitespace on both sides to trigger it:
a[1] b [1] c[1] produces the expected a1 b 1 c1
using [r:1] eliminates the issue:
a [r:1] b [r:1] c [r:1] produces the expected a 1 b 1 c 1
Tested with Java 6_43 and 7_17, on Mac OS 10.6 and 10.8 and Windows XP SP3 in a new blank campaign file just after launch. Expanded rolls exhibit the same behavior. I don't see this in b87 for any Java or OS version I have to hand. (edit: I also don't see this in b88)
Happy to test in Linux and Win 7 if that would help, I'll just need to set up VMs.
a [1] b [1] produces a 1 bb 1
more test cases
a [1]<br>b [1] produces
a 1
bb 1
a [1]b [1] produces the expected a 1b 1
a[1] b [1] produces the expected a1 b 1
a [1] b[1] produces the expected a 1 b1
[1] a [1] produces the expected 1 a 1
a [1] [1] produces the expected a 1 1
a 1
bb 1
a [1]b [1] produces the expected a 1b 1
a[1] b [1] produces the expected a1 b 1
a [1] b[1] produces the expected a 1 b1
[1] a [1] produces the expected 1 a 1
a [1] [1] produces the expected a 1 1
a [1] b [1] c [1] produces a 1 b 1 cb 1 cc 1
but there must be at least two rolls with whitespace on both sides to trigger it:
a[1] b [1] c[1] produces the expected a1 b 1 c1
using [r:1] eliminates the issue:
a [r:1] b [r:1] c [r:1] produces the expected a 1 b 1 c 1
Tested with Java 6_43 and 7_17, on Mac OS 10.6 and 10.8 and Windows XP SP3 in a new blank campaign file just after launch. Expanded rolls exhibit the same behavior. I don't see this in b87 for any Java or OS version I have to hand. (edit: I also don't see this in b88)
Happy to test in Linux and Win 7 if that would help, I'll just need to set up VMs.
Re: MapTool 1.3 Final, patch05 (build 89)
That's strange. I remember this being mentioned in another thread a few weeks ago. If it was in Lee's test build, maybe the problem is the patch that tries to be more intelligent about replacing smileys by only running a regex against the text produced in chat and nothing else. I'll check that patch and see if it could be having an effect here. If it was in the mainline b87 then it couldn't be that patch.
Has anyone seen this behavior in the stock b87 (or b88 for that matter)?
Has anyone seen this behavior in the stock b87 (or b88 for that matter)?
-
- Kobold
- Posts: 17
- Joined: Mon Jan 26, 2009 3:58 am
Re: MapTool 1.3 Final, patch05 (build 89)
Just tested, and this issue also appears in Lee's dev build. Same test cases, same results for me, at least for Mac 10.8/Java 6_43
Re: MapTool 1.3 Final, patch05 (build 89)
@wolph Sorry about that. There may be underlying references that a simple library swap can't overcome.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Re: MapTool 1.3 Final, patch05 (build 89)
I added a new thread in the Testers forum for folks who want to help with the UPNP router issue.
What is the most stripped down version of code that will reproduce the problem? I'll set a breakpoint in that routine and see what's going on.
Edit: Ah, nevermind. I just read back through the thread and found this:
I'm looking at the code (for those with source code, it's HTMLFrame.showFrame()) and the first thing it does is check to see if the frame already exists and if so, it doesn't call center() to reposition it.Azhrei wrote:Yeah, it sounds like the fix was added to the wrong place. It should only apply to the first opening of a frame. There's a hash table that keeps track of which frames already exist so this patch was probably put above that check instead of below it. Oops.aliasmask wrote:It was a problem for Mac users that frames showed up in upper left corner where the border was outside of where it could be grabbed and moved. I think the fix was to simple rest frames and center (although, I'm not a fan of the frame reset once defined). I did find a work around to the Mac issue by using Wiki: resetFrame() which I think is how the fix was applied, but I don't know for sure.
I'll take a look at that patch and see about moving it.
What is the most stripped down version of code that will reproduce the problem? I'll set a breakpoint in that routine and see what's going on.
Edit: Ah, nevermind. I just read back through the thread and found this:
Which means it's more likely related to the saving/loading of the docked panels and not the normal operation of the frames. It's probably because the structure which keeps track of which frames are open will start out empty and thus the frame is considered "new" and is centered. I'll dig a little deeper.Frames always re-open on the middle of the screen, undocked after restarting MT and reopening the FW.
Re: MapTool 1.3 Final, patch05 (build 89)
Build 89 still does not properly support Java 7 on OS X 10.7+. While it may run on Java 7, I believe it is not bundled properly to use Oracle's version of Java. Here is a post regarding how to do this. I discovered this by trying to run 89 on Mountain Lion (fully patched, Gatekeeper off) with only Java 7 installed; it will prompt you to install Apple's Java 6 JRE.Azhrei wrote:I also spent some time documenting what my build process is in regards to the OS X disk image. I'm using some scripts that probably only work for me but I'll be moving them into the SVN tree somewhere so others will be able to access them. I'd like to move them all the way to the ANT build.xml file, but that likely won't happen...
Now to re-bundle my Java apps at home to use Oracle's version of Java...
Re: MapTool 1.3 Final, patch05 (build 89)
Nope. I still get a double row even with [r,e:wolph42 wrote:Try [r,e:
Re: MapTool 1.3 Final, patch05 (build 89)
Maptool keep on!
My humble congratulations to the whole Maptool community (developers, testers, documentation supporters, GMs, players, users, trolls... ).
I feel very happy. I have to recognize that I am worried about the future (1.4 or so)... But now it is a moment of joy...
DJuego
My humble congratulations to the whole Maptool community (developers, testers, documentation supporters, GMs, players, users, trolls... ).
I feel very happy. I have to recognize that I am worried about the future (1.4 or so)... But now it is a moment of joy...
DJuego
Re: MapTool 1.3 Final, patch05 (build 89)
Wow, excellent information! Thank you!Highmeh wrote:Build 89 still does not properly support Java 7 on OS X 10.7+. While it may run on Java 7, I believe it is not bundled properly to use Oracle's version of Java. Here is a post regarding how to do this. I discovered this by trying to run 89 on Mountain Lion (fully patched, Gatekeeper off) with only Java 7 installed; it will prompt you to install Apple's Java 6 JRE.
That page has some good information, including how to bundle the JRE with MapTool as part of the .app. It claims that this is necessary if you want to distribute the application via the Mac App Store. And that would be very cool if MapTool qualified for it. (I guess I'd have to buy the developer license for it though. Oh well, it's a business expense. )
One thing I found interesting about this... Perhaps OSX applications could then be built on non-OSX systems. That would make the build process much more portable. It still doesn't help with the .dmg files, but I think someone else has posted that there's a Linux tool for creating those. I'll get to the point of integrating those at some point. Maybe. We plan to switch to Maven for 1.4/2.0.