MT 1.3b50 progress

[Veggiesama]

With the new EXE, are there any ways to assign the command-line memory and stack sizes? Looks like the OSX shortcut does 768M / 2M by default.

I have been running a 2M stack size for a while now with no problems, but I also have a beefy machine. I am wary about telling others to do the same, but I haven't heard problems from anyone else either.

[Azhrei]

With the new EXE, are there any ways to assign the command-line memory and stack sizes? Looks like the OSX shortcut does 768M / 2M by default.

Yeah, that was just a guess on my part. Any Mac in the last 5 years (?) has had at least 1G of RAM, so I figured 768MB was safe. Ditto for the 2MB stack size; not a huge amount of waste but very useful.

[Phergus]

Configuring Shortcuts for the MapToolLauncher

The MapToolLauncher program must be located in the same folder as the MapTool jar file (e.g. maptool-1.3.b50.jar) but you can create shortcuts to it that can sit on your desktop or the QuickLaunch panel in the Windows Taskbar. You can also add optional arguments in the shortcuts to increase the allocated memory size and enable the the command prompt window to see any error outputs.

Creating a Shortcut on the Desktop

There are several methods to create shortcuts to programs in Windows. One way is to hold down the Alt key and then right-click-drag from the MapToolLauncher icon to your desktop. This will create a shortcut that looks like Screenshot 1. Once placed on the desktop the shortcut can be renamed in the normal manner.

LauncherShortcut.png (11.35 KiB) Viewed 1378 times

Increasing Memory Allocation in the Shortcut

Right-click on the shortcut and select Properties from the pop-up menu that appears. The Properties dialog will open with the Shortcut tab active as shown in Screenshot 2. To start MapTool with 1024 MB for the Java Virtual Machine (JVM), locate the target text field in the Properties dialog then add a space and 1024M to the end of the line. If there are quotes around the target path be sure to put the memory option after the quote marks. Don't forget the space. This can also be seen in Screenshot 2. The memory argument takes the same form as is used by the -Xmx Java command line argument.

ShortcutProps2.png (23.73 KiB) Viewed 1378 times

Enabling Debug Output

Enabling debug output is done in the same manner. Simply add a space and the word debug to the end of the Target line. Note that you must have both a memory allocation size and the word debug for this to work.

Requirements

The MapToolLauncher relies upon a correct and working Java installation. This means that the Java executables must be in the System path. The launcher works in the same manner as the batch files included in the MapTool zip files. If those work then the launcher will work.

Not Supported
This was originally coded long before the discussion about stack size came about and so there are no options to change that. I'll redo the options so that it is more flexible and allow you to put in additional JVM options.

[Azhrei]

When you finish the stack size update (and maybe Minimum Memory, since I've seen you mention that in your troubleshooting posts), if you'll send me an HTML version of this last post I'll see that it's added to the new web site, probably in the MapTool FAQ section.

If I had a clone or two, those other sections of the main site would be populated by now.

[Phergus]

Will do.

If I had a clone or two, those other sections of the main site would be populated by now.

Coming to you soon from RPTools, it's CloneTool! When you just can't get it all done by yourself.

[Craig]

Will do.

If I had a clone or two, those other sections of the main site would be populated by now.

Coming to you soon from RPTools, it's CloneTool! When you just can't get it all done by yourself.

Sign me up! Now if I can just clone myself 9 times and only work 1 day every 2 weeks...

[Phergus]

When you finish the stack size update (and maybe Minimum Memory, since I've seen you mention that in your troubleshooting posts),...

Need some thoughts/feedback on this.

I originally went with the simplistic approach as I wanted it to be relatively simple for the non-geek to be able to add the memory option to a shortcut.

But if I'm going to allow for additional JVM options then my first thought is just to accept the standard command line switches and pass through any that are supplied unmodified. However now it is starting to get on the edge of too complex for the user this is really targeted at.

Alternatively I could pick out a limited subset (-Xmx, -Xms, & -Xss) and be a bit more picky about what options and how they are provided. I could accept options like: max=768m, min=768m, stack=1024k. This is a bit more friendly to the non-techie but perhaps overkill.

Lastly are the two options I originally rejected. First I could prompt the user on first run for these values and save them in the registry (painful for the user to find/remove) or save them to config file in the same directory (messy). Subsequent startups would then read the registry or config file and use those values.

Second rejected thought was to make the launch a two-step process where it presents a dialog with options to change those values with an Launch button to go ahead and start MT. Wasn't real keen on the whole 2 step idea.

[jfrazierjr]

When you finish the stack size update (and maybe Minimum Memory, since I've seen you mention that in your troubleshooting posts),...

Need some thoughts/feedback on this.

I originally went with the simplistic approach as I wanted it to be relatively simple for the non-geek to be able to add the memory option to a shortcut.

But if I'm going to allow for additional JVM options then my first thought is just to accept the standard command line switches and pass through any that are supplied unmodified. However now it is starting to get on the edge of too complex for the user this is really targeted at.

Alternatively I could pick out a limited subset (-Xmx, -Xms, & -Xss) and be a bit more picky about what options and how they are provided. I could accept options like: max=768m, min=768m, stack=1024k. This is a bit more friendly to the non-techie but perhaps overkill.

Lastly are the two options I originally rejected. First I could prompt the user on first run for these values and save them in the registry (painful for the user to find/remove) or save them to config file in the same directory (messy). Subsequent startups would then read the registry or config file and use those values.

Second rejected thought was to make the launch a two-step process where it presents a dialog with options to change those values with an Launch button to go ahead and start MT. Wasn't real keen on the whole 2 step idea.

One thing to think about is any options such as how system properties are passed in to a standard java app, so you might want to think about that also if you go the limited parameters route...

[Azhrei]

Alternatively I could pick out a limited subset (-Xmx, -Xms, & -Xss) and be a bit more picky about what options and how they are provided. I could accept options like: max=768m, min=768m, stack=1024k. This is a bit more friendly to the non-techie but perhaps overkill.

I like this idea best.

I would suggest that the ZIP have only a single batch file in it that executes your launcher. If the launcher is invoked with no parameters, it prompts for values for all three using reasonable defaults. After the user answers these questions, the application writes a new batch file to the directory where the name of the file represents the parameters chosen and puts those parameters into the batch file itself.

The next time the users wants to run MapTool they can use the original batch file (and get the prompts again) or they can use the newly created batch file.

The advantage to this scheme is that the new batch file can be emailed to other users in your gaming group, if necessary.

How does that sound?

[Veggiesama]

I would like a two-step option on the first run. First check if there's a config file. If not, a dialog asks the user to enter the command-line arguments in textboxes, which are filled in with reasonable defaults. Then it writes a config file and runs MapTool. On subsequent runs, it should follow the config file and ignore the start-up dialog. To get back the dialog, delete the config file (or just edit it manually for changes).

Anything's better than telling players to edit their bat files and insert obscure command line arguments, though. I also think editing a windows shortcut is almost as confusing. Telling them to delete a file and type in info when a dialog appears works for me though.

[Phergus]

I would suggest that the ZIP have only a single batch file in it that executes your launcher. If the launcher is invoked with no parameters, it prompts for values for all three using reasonable defaults. After the user answers these questions, the application writes a new batch file to the directory where the name of the file represents the parameters chosen and puts those parameters into the batch file itself.

The next time the users wants to run MapTool they can use the original batch file (and get the prompts again) or they can use the newly created batch file.

The advantage to this scheme is that the new batch file can be emailed to other users in your gaming group, if necessary.

How does that sound?

The point of all this was to not require batch files any longer. The launcher executable in effect replaces the batch file(s). If it were to save options to a file then I would go with the third option I mentioned which is what Verggiesma has suggested.

This would share the same advantage as your suggestion in that a small text file can be emailed to others to share the launch parameters.

I worried that editing shortcuts was too confusing as well but figured I'd wait to see how much pushback there was on that.

[Lindharin]

Just as a point of interest, I believe from a PM conversation with Trevor that he is considering assigning a default stack size in the batch files. You might want to touch bases with him about this since it sounds like your changes might make his unnecessary.

[Veggiesama]

a default stack size in the batch files.

2M! 2M! 2M!

[Full Bleed]

Is there a way to make the windows.exe look at the system memory and default to assigning half of it to Maptool automatically?

That's usually a safe point for people to game with.

[Phergus]

Is there a way to make the windows.exe look at the system memory and default to assigning half of it to Maptool automatically?

Yes and it could be made the default behavior allowing for that to be overridden by one of the other options for setting the JVM configuration.