I'd like the user to be able to visit the Help menu and see two links, one for a general README file that pertains to the version they're running, and also a Release Notes file for their particular version. My main concern is that people download the latest MapTool and then don't know what's new/changed and perhaps they don't know about the forum...

I believe the simplest way to do this is to open a URL based on the version of MapTool. So MT v1.4.1.7 would open the URL http://www.rptools.net/maptool/README_v1.4.1.7 and ditto for the Release Notes.

When the build file is uploaded to rptools.net, we'll have a server-side process that extracts the README and Release Notes and renames them to the proper name. However, if they are the same as the previous versions then delete the files and use hard links to the previous ones. So if the README hasn't changed, README_v1.4.1.7 would simply point to README_v1.4.1.6. I had consider symbolic links, but some OSes have a limit on how many symlinks can point to symlinks before they throw an error, so hard links would eliminate that problem.

I would want these to be Markdown files, but I'm not sure they will be converted to HTML automatically by the HostGator web server, so I might need to convert them. That's on my todo list to investigate.

I cannot check out the current branch (1.4.1-dev) because of the folder "C:.net.rptools\AppUtilTest" in maptool.
The issue is that Windows 7 does not allow ":" and "" in folder names.

Looks to me like it doesn't like the version of spotless it gets on a clean build attempt. Let me know if you need it run with debug options, but those seemed to produce more clutter without supplying anything helpful.

$ ./gradlew build 

FAILURE: Build failed with an exception.

* Where:
Build file '/home/laurence/build/maptool/maptool/build.gradle' line: 91

* What went wrong:
A problem occurred evaluating root project 'MapTool'.
> com/diffplug/gradle/spotless/SpotlessPlugin : Unsupported major.minor version 52.0

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Before releasing 1.4 for day to day use the build needs to create everything required for WebsStart launch.

I tried the 1.4.1.0 build on your server. It brought up the launcher, but wouldn't launch the MapTool-1.4.1.0-fat.jar even after I selected it.

I'm on Windows 10 64bit.

Of note, it works now that I installed Java. I didn't have it installed to begin with. This is supposed to be the self-installer though, correct?

The 1.4.0.3 build works fine (with Java installed).

1. Fix the console problem with spaces being in the java path
2. add macro function to write data to log file - something along the lines of log(String text, bool debug) when the debug flag is on, only write to the log.txt when macro logging is turn on.
3. add a feature to dump text to a file in the .maptool directory so GMs and write data from MapTool for use while offline (like character data and game stats).

A user reports here http://forums.rptools.net/viewtopic.php?f=60&t=23681&p=267496#p267496 that the autosave feature only works one time after a manual campaign save is performed.

Occurred while loading a campaign.

The current map was refreshed and being displayed but MT was not yet responsive. This exception occurred (see stack trace, below). This is while loading a trimmed version of @JamzTheMan's Nerps campaign (so it's possible that an OnCampaignLoad macro is involved, since I had deleted a possibly key map).

java.util.ConcurrentModificationException
    at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:966)
    at java.util.LinkedList$ListItr.next(LinkedList.java:888)
    at net.rptools.maptool.model.Zone.getTokensFiltered(Zone.java:1303)
    at net.rptools.maptool.model.Zone.getBackgroundStamps(Zone.java:1375)
    at net.rptools.maptool.client.ui.zone.ZoneRenderer.renderZone(ZoneRenderer.java:1097)
    at net.rptools.maptool.client.ui.zone.ZoneRenderer.paintComponent(ZoneRenderer.java:770)
    at javax.swing.JComponent.paint(JComponent.java:1056)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JLayeredPane.paint(JLayeredPane.java:586)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintToOffscreen(JComponent.java:5210)
    at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1579)
    at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1502)
    at javax.swing.RepaintManager.paint(RepaintManager.java:1272)
    at javax.swing.JComponent._paintImmediately(JComponent.java:5158)
    at javax.swing.JComponent.paintImmediately(JComponent.java:4969)
    at javax.swing.RepaintManager$4.run(RepaintManager.java:831)
    at javax.swing.RepaintManager$4.run(RepaintManager.java:814)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
    at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:814)
    at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:789)
    at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:738)
    at javax.swing.RepaintManager.access$1200(RepaintManager.java:64)
    at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1732)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
    at java.awt.EventQueue.access$500(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:709)
    at java.awt.EventQueue$3.run(EventQueue.java:703)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
    at net.rptools.maptool.client.swing.MapToolEventQueue.dispatchEvent(MapToolEventQueue.java:36)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

An option added to the Token popup menu to restore default size and orientation to a MapTool token or stamp along with a MTScript function to do the same.

The MTscript function getName() produced this error:

Function "setName" requires at least 1 parameters; 0 were provided.

The message is wrong because it says "setName". Not a big deal, just a typo to fix the next time the code is being edited... :)

Currently, if a client drops its connection to the server, the player must manually reconnect. The client should auto-reconnect instead.

It would be nice if the client didn't have to reload the campaign resources, but this may not be easy. The existing logic connects and the campaign is transferred as part of the connection attempt. There would need to be some way to check whether the client already had the campaign and now we get into issues with the client's campaign being out of date with respect to the server. We don't currently have anyway to determine which resources might have changed so we have no way to only send those resources to the client and no others.

However, a quick and easy reconnect should still be implemented.

Is the version number required in settings.gradle as we already have it in the version.txt (which is checked into git )

title says most. When the selection panel is open AND/OR the impersonation panel is open (with one token impersonated) then deleting e.g. 500+ tokens takes significant time (minutes). In some rare cases it can even halt the system or become so bad that even deleting 10 tokens grinds the system down. (This usually happens after an hour of intensive development).

Add a database to MapTool, initially to provide enhanced Table functionality as well as MapTool internal data.

I'm sure this has been asked before, but I don't see it listed in the GitHub issues and I had trouble finding a forum post that mentions that undo/redo doesn't work for token operations.

So, I would like to request Undo/Redo support for token operations.

Use cases where it could really help:

• Move token twice.... eh what was the original position of the token. I can only "Revert Last Move".
• Delete a token... eh sorry token is gone and you can't have it back.
• Move multiple tokens, set orientation, resize token.
• Edit Token Properties... oh I removed the whole inventory.
• User complains that Roll20 has it... ah yeah it's only for drawable in MapTools Sorry.

I had a look at the Java code and there's no undo support in Zone.putToken() like there is for Zone.addDrawable().

It would be nice if tokens could at least store a stack of their last positions if persisting/marshalling whole tokens multiple times is problematic.
Also, linking "Revert Last Move" to undo could be a good start.

I don't think the undo needs to be global and server side. It would be ok if each client had its separated undo stack.

I'm also interested in knowing about good practices for token management that don't require changing the code.

• Keep a copy of the PC tokens exported in seperated files.
• Instead of deleting tokens, move them to a Trash map using a macro.
• Use the Revert Last Move from the token right mouse menu.
• Is there a macro library that could help?

Thank you.
Guillaume

Currently macros can only nest braces 2 levels deep. There are some clever hacks to work around this, using extra single-quotes to make the regex match, but that causes other issues. If anyone is interested, I hacked in a fix in MapToolLineParser.java that checks if match just doesn't consume the entire roll string. If that is the case, it checks if it is missing any braces, and if so, increases the matched portion until it finds the missing braces. If that makes it consume the entire string, it counts it as a match and doesn't raise an exception. It seems to work, but is not a clean implementation. If anyone is interested in using it, or in re-implementing it cleanly, it's commit perkinslr/maptool@a459bab

I did not bother to patch switches, since I've never needed to nest more than 1 level inside any given case. Doing so would not be too difficult though.

Currently, the images are not saved as part of the chat log export. It show's a broken image link.

Create rplib repository

Whilst playing a game, I attempted to use a GIF in a macro by using the tag. Upon running the macro, everyone playing the game crashed, with MapTool giving a stack overflow error. This occured in MapTool v1.4.0.5.

Several dependencies need to be updated so we can use the jars in the normal nevertheless repositories instead of the temporary one.

The ability to load external JS files into MapTool into a system global area rather than attached to a token.

Apparently an old bug had reared its head again. When using strPropFromVars a redundant ; is added at the end, which (for example) results in an empty key value pair when you transform that to a json object. Other issues as well as the stray simply adds an extra empty value. The fix is to remove the ; when using strPropFromVars

test code:
[h:var1=12][h:var2=13][r:strPropFromVars("var1,var2","UNSUFFIXED")]

and for a deities sake, make the 'UNSUFFIXED' part optional please!!. (Where it defaults to 'UNSUFFIXED'). The other way round it's optional as well, so it makes little sense why its not for this function.

I'm using maptools on a server where it runs 24/7. The only problems are the connection losses to the maptools registry webservice.
It would be really nice, if it simply tries to reconnect instead of crashing. This also causes the changes to the current loaded campaign to be completely lost.
Below you can find the error/exception message that I receive.

Exception in thread "Thread-7" com.caucho.hessian.client.HessianConnectionException: 500: java.io.IOException: Server returned HTTP response code: 500 for URL: http://services.rptools.net/maptool_registry-1_3.php
        at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:197)
        at com.sun.proxy.$Proxy0.heartBeat(Unknown Source)
        at net.rptools.maptool.client.MapToolRegistry.heartBeat(MapToolRegistry.java:65)
        at net.rptools.maptool.server.MapToolServer$HeartbeatThread.run(MapToolServer.java:192)
Caused by: java.io.IOException: Server returned HTTP response code: 500 for URL: http://services.rptools.net/maptool_registry-1_3.php
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
        at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1677)
        at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1675)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1673)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1246)
        at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:179)
        ... 3 more
Caused by: java.io.IOException: Server returned HTTP response code: 500 for URL: http://services.rptools.net/maptool_registry-1_3.php
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1628)
        at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468)
        at com.caucho.hessian.client.HessianProxy.invoke(HessianProxy.java:168)
        ... 3 more

A function to return the native height and width of a token or stamp.

The launcher looks for the mt.cfg and translations in current directory, this will not work for .app (and possibly wrapped windows exe) as the current directory will not be the directory where these programs exist but rather an application support directory.

Need to add logic to the gradle build to create normal maptool distribution and Mac OSX app/dmg

Forum request: Decimal digits in map properties (distance per cell)

It would be great if you could use decimal digits (like 3.5 or 4.7) at "Distance per cell" in the map properties. It would make MapTool more international. A little example:

In Pathfinder one cell on the map is 5 foot. 5 foot are 1.5 metres in the metric system, which is used all over the world outside the USA (and so in the rpg rulebooks of course).

Not a big thing, but it's implemented in other virtual tabletops like Roll20, and it would make things just a little bit easier and more compfortable for non-americans.

Should be doable, duplicates another forum request.

In short, when you switch between the token selection tool and another tool (e.g. VBL) then the token tool always snaps back to the TOKEN layer. (which is annoying if your working on e.g. the background layer).

GM PC is running v1.4.0.5 with several downloaded token sets automatically added through the add resource library menu. GM PC loads campaign. Campaign is 77 MB and has 8 maps. Some have VBL, others do not. Some maps have Bag of Tricks InterPads and some do not. GM PC starts server as LAN. Second PC loads v1.4.0.5 (same version), connects to LAN server as 'Player'. This Player PC displays a default world map. On Player PC I click full screen. On GM PC I click "center players on current view continuous". Two maps will not display on the Player PC. One says "Loading Map 'map1' - 3/5 Loaded 3/5 Cached" and the other says "Loading Map 'map1' - 13/15 Loaded 13/15 Cached". After waiting over 10 minutes, still no map shows on Player PC. One of the two maps that fail to display use tokens from Bag of Tricks, one does not. All the maps that display correctly have a single background image. Both the maps that do not display correctly use two images in the background, one that is "Visible to Players" and one above it that is NOT visible to players. Both PC's are running Windows 10 Pro 1607. GM PC is running Java 1.8.0_66. Player PC in running Java 1.8.0_31.

Hopefully that's enough information to identify the problem.

Some benefits include
Ability to store database files
Ability to work on macros (both JS and MTScript outside MapTool

Reporting a new bug to squash.

For windows (and possibly other systems), on a fresh install, config sub directory under .maptool is not properly created causing launcher to fail as it can not create the default launch.properties file.

Moving this from the forums to GitHub Issues seems like the right thing to do (easier for me to track at least). Let me know if I'm wrong. I still don't have a good handle on how you all like to operate.

Ok, I've done a few documentation pull requests (based on existing info from the forums) and the one on UPnP discoveryTimeout. Now I'd like to tackle the hopefully easy "Did You Know" popup box (issue 34 in the Google Spreadsheet).

I used Abeille for the UPnP UI, but that was because the Setting UI already existed. Going forward, how should I create the UI for this Did You Know feature? I see open issues for an HTML and/or JavaFX based UI? I also see Swing is being phased out. Can I get some guidance?

Thanks!

I haven't worked on MT in a LONG time. Should I have merge authority over my own stuff? I started this issue to provoke discussion...

This would mean Craig merges stuff I submit and I merge stuff he submits. This puts at least one other set of eyeballs on the stuff he and I do ourselves. Or we simply allow anyone with merge authority to merge anything.

If we go with the one's-code-can-only-be-merged-by-someone-else approach, there should probably be another person added to the pool of those with merge authority, simply because I don't hang out here after enough.

Perhaps this isn't necessary. I know in my own private repo where my brother and nephew also have write authority, we have agreed that only my brother can merge to master as the project is really his baby, not ours. But we've also been kicking around the idea of merges being done by someone other than the creator, just as a double-check on making stupid mistakes. :)

jwrapper.xml contains hard coded paths and MapTool jar file names (with version number).
This should be generated from the values in gradle properties rather than needing to update the paths in two places and the jar file for each version.

From discussion with Dorpond's observations of a new MapTool GM.
"He didn't know his maps were player visible and didn't even have FOW turned on. He was a bit bummed that we suddenly saw his stuff. Again, this might just be learning curve stuff, but I can't help but try thinking of how we can make it better."

Possible solution
Place option on Start Server dialog to enable FoW on all Maps.

There are questions as to whether it should be turned off again when in non-server mode.

As discussed. Token id's that consists purely out of numbers get truncated and thus blow up macros in the process of addressing those tokens. E.g. 000000012345600000 is truncated to 123456000000. A short term solution is adding a letter to the ID.

When you open the token editor (double click on token), and go to the properties tab and then (accidentily) hover/move mouse over a property that has a really big value (e.g. long json array), MT shows a tooltip with the entire value. However if that value is REALLY big it effectively crashes and you have to terminate MT the hard way.

This depends on bringing TokenTool into MapTool to edit token images. This particular request is to allow a transparency percentage to be set on a token or stamp to allow for things like transparent roofs and tree canopies as well as the depiction of creatures that can become ethereal or astral.

Included in this request are new macro functions to set the transparency on tokens and stamps as well.

This would require a new Token property for each of the settables.

It may require a new window outside the token editor dialog.

I would like a command which can destroy all of the map objects on the current map and reload them from the server.

Currently on a stack trace, MapTool reports it in a window with instructions to report it to the MapTool developers. The requested functionality is to automate sending of the stack trace to a location for review by the Dev team, including OS and Java Version, machine state (CPU, mem, disk space, etc.) and MapTool log files.

The functionality would need to include the ability to prevent spamming (see Az).

When you turn on macro logging it works, however the next time you run it , it doesn't work anymore.
It turns out that it works as long as you make a change in the 'advanced' tab of the launcher. If I keep turning on/off/on etc e.g. 'general debugging' then 'macro handling' remains active. If however i dont make a change then the macro handling logger doesn't work.
Note I only checked the workings with the console, didn't check the actual log file (under the assumptions that they're showing the same).

So it's already possible on most laptops to plug in an external projector to the laptop's HDMI port and extend the desktop to it. A second copy of RPTools would be shown on this second display as a player copy. However, for table top gaming, the projector should be above the table facing down onto it, making the cabling awkward at best. WiFi would be a better choice.

So the projector would need to support WiDi, WiFi Direct, MiraCast, AirCast, or PlayTo media server technology. The old Western Digital TV Live Streaming Media Player is a good example of this.

but a lower cost solution is possible. I have already built a simple app for the Raspberry Pi 2 and Windows 10 IoT Core that receives and displays a PlayTo cast media stream wirelessly. The only thing is that RPTools is unable to create a media stream of its window to cast to the receiver.

Alternatively to PlayTo media streaming, the other technologies such as the open standard MiraCast is supported by Windows 8.1 or later. If RPTools is run on Windows 8+ then its possible to extend the desktop to a WiFi projector, TV or monitor. There are a number of Miracast receivers on the market ranging from $15 to $50 that can turn a non-WiFi capable projector, TV or monitor into a casting receiver. I have not tried any of them. The Microsoft Wireless Display Adapter seems to be the best rated for use with Windows. But it also seems that these are for very high bandwidth full HDMI movie quality. The bandwidth usage of these devices is very high. And the host computer requires Wireless N and in order to use an older laptop or computer host you would have to buy a new WiFi dongle such as TL-WN725N that supports WiFi Direct (a prerequisite for Miracast). While they are not expensive, it's yet another thing to plug in to get it to work.

If RPTools were able to capture and cast a media stream of it's own window to a PlayTo media player, this would be great! This would work on computers without WiFi Direct capability (older computers, slower WiFi). The receiver could be a cheap Raspberry Pi 2 & Windows 10 IoT (and possibly even cheaper RPi 0 with Linux).

Reported by @dorpond: Forum link

When I right click -> Auto Resize -> And then hold the right mouse down on the map and drag, instead of the left button.

java.lang.NullPointerException
at net.rptools.maptool.client.tool.StampTool.mouseDragged(StampTool.java:547)
at java.awt.AWTEventMulticaster.mouseDragged(Unknown Source)
at java.awt.Component.processMouseMotionEvent(Unknown Source)
at javax.swing.JComponent.processMouseMotionEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$500(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at net.rptools.maptool.client.swing.MapToolEventQueue.dispatchEvent(MapToolEventQueue.java:36)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

This is a weird one. Only way I found to close it was to right-click the titlebar and choose close. Working in a VM I couldn't figure out the Fn keystroke to close the window (Maybe Ctrl-F4?)

Probably need to change the planet to have an explicit close that will work on all platforms. And we need a loading screen anyway, since it can take a few seconds to run the cmd lines needed and to scan for IGDs when there aren't any, meaning the panel takes 8s-10s to populate and display.

Package TokenTool as a virtual application into the JWrapper installer for MapTool.

User issue from Dorpond working with a new MapTool GM
"When he loaded up his campaign, we connected as players and arrived in a map he wasn't expecting us to be on. My thoughts went back to our past discussions of having a landing page, where all players connected arrive at. This could be as simple as a set (default) map, or be as elaborate as having a non-map, full text/writing capable (recapping last sessions, listing current quests, etc) landing page."

After discussion, the thoughts are to allow the GM to set a landing page for the campaign or default the players to the GMs current map when they connect to a server.

Possible solutions include

1. Flagging a map as a landing page on the MapTool Map menu. Rules around this include only having one landing page per campaign and the map must be player visible. If the map is set to non-visible, the flag is removed.
2. Force the players to the current GM map (by default). Again, the map would need to be player visible.
3. Consistently force the players to the first visible map in the Map List.

These are likely in precedent-order. If a Landing Page is set then go there. If there is no Landing Page then go to the GM's map. If the GM map isn't player-visible, go to the first visible map in the list.

The generated install dmg/exe/tar file needs to contain the version number.

1. The following looks like it needs to be filled out: https://github.com/RPTools/maptool/blob/master/doc/LICENSE#L30
2. The LICENSE talks about using the GPL moving forward (along with the LGPL), but shows the AGPL. If we are using the AGPL, we should probably fix the references to the GPL (for example: https://github.com/RPTools/maptool/blob/master/doc/LICENSE#L7 )