The shared build uses the new cling library, whereas the other one uses the tried and tested sbbi-upnp library, which we already know works well. In the interest of 1.4, please help in seeing if this new library holds up as a viable replacement. With 5 new dependencies minus 2 old ones, we need to verify if adding on 3 (adding 10 MB to MT's size) is worth it. Currently, I wrote it to take advantage of cling's aggressive traversal and mapping. What this means is that it will send out a call for UPnP capable devices, and map the port on all devices in the chain that respond. Cleanup is as thorough as well, at least from what I've seen (yes, I finally did get a router).
There's a few more, not the least of which, is Java 7 compatibility. Now, on the issue of testing. All I can safely say for my part is to test the stuff I made patches for, as I can answer immediately if something is found broken. Check out the testing section for details on what these are.
Do try and break UPnP; I coded most of it when I was blind without a router, so I might have missed something even when my new router now reports proper mapping.
Since Azhrei/Craig rolled back MT from b88 to b87, I'm not sure how much of this changelog (b88 section) applies. If anyone can verify that those are intact, we'll all be laughing.
Lastly, one of the patches applied here was to fix a rather significant bug regarding path computation. As part of the fix, I had to make some changes to the Token class. This, "unfortunately", will trigger version checking in other versions of MapTool, making anything saved using this build unusable in lower versions of MapTool. With that being said, make sure to have backups of anything important you plan to run with this (or don't run anything important on it all), else these'll be lost to older MapTools. You have been warned
What's good to know is that most, if not all, patches applied will likely make it into the next official build, so saves using this will be compatible with that future version (though maybe not that path fix, we'll see). If anyone was wondering, I cleared this with Azhrei and got the green light. Happy holidays!
Download latest version here.
[spoiler=Version 0.2 - 0.3]#Properly patched code for dragging a token.[/spoiler]
[spoiler=Version 0.3 - 0.4]# Patched the parser library and included it in this build. This was tiorthan's dollar character fix. If anyone has experience with the problem, now'd be a good time to test the fix
# Created a MapToolLauncher in jar form. I'm not sure if it's system agnostic since I used the resource that came with MapTool. Mac OS and Linux users, do try it out and see if it works
# UPnP discovery is now dynamic within a static window of 30 seconds; meaning if a device is found within the time frame, discovery will end and mapping will commence.[/spoiler]
[spoiler=Version 0.4 - 0.5]# Added handling for UPnP cleanup when unexpected shutdowns occur where the application preferences for the current session were not saved/corrected.
# Completed path computation fix; path computation for unsnapped tokens will now show "footprints". Note that this is an approximated path based on the reflection of a token's own derived cell path, so there will be incongruent points; all points, however, fall within intersection area of the moving token. Standalone patch uploaded to Testing
# Properly built the rplib and parser libraries after seeing no reports of errors. This drastically lowers the impact of their size to the overall package.[/spoiler]
[spoiler=Version 0.5 - 0.6]# hogtied the undo/redo process and placed a muddy boot on its head. Testing, with the intention of breaking it, required. Expected behavior is as follows:
- - undo/redo queue is per map.
- fixed undo/redo command availability behavior; meaning undo only when there is something to be undone and redo when there is something to be redone. clear all only works for (all) GMs and is only available when a drawn item is present on the undo/redo queue of any client.
- invoking a clearing clears all drawn items and suppresses everyone's undo/redo actions.
Test these expectations to see if they hold on your end.
# changed getImage to mirror requests discussed here
# MT window now in real maximized state. (a pet peeve of mine I fixed in my fork, might as well fix it here too)
# Applied a fix for tokens not appearing properly on campaign load, though fix is unverified since it's not happening to me anymore, even on official builds 87 and below. Do test it out and let me know if it works.[/spoiler]
[spoiler=Version 0.6 - 0.6.1]# reverted back to original parser library after errors were encountered with a patch[/spoiler]
[spoiler=Version 0.6.1 - 0.7]# implemented the apache commons net library for MT's FTP classees
# reverted to latest official rplib library as a recent patch caused a Java 7 dependency
# updated to latest changes in MT repo (12/19/2012)
# added simple version checking to know when to apply Java 7 compatibility settings
# these changes make this build compatible with Java 6 and 7[/spoiler]
[spoiler=Version 0.7 - 0.8]# FTP now fully functional. Fixed the bug with regard to how MT checks for the asset difference between locations. The current implementation, however, relies on a non-persistent source that had to be initially generated by doing a transfer. This means that even if copies of local assets already exist on the other side, MT will say that everything needs to be transferred in order to make this list. This happens on every new MT session whenever the FTP functionality is used.
So I did one further and created a comparison process between the local and remote location which, IMO, is the correct way. Note, this was only implemented for FTP. I didn't look into the other parts where MT manages asset differences between client and repository locations. Also note that this will only work with hosts that support FTP.
This function can be found under File -> Export -> Update Campaign Repository. This will open a window to connect to an FTP server. The field up top holds a list of repositories used by a campaign. Clicking on an entry here will auto-populate some of the fields below. Again, not all repository locations support FTP so be advised. The second field is optional. The 3rd field is the hostname/ip address of the ftp server. The login credential fields are self-explanatory, these values are what you use to authenticate with the FTP server. The check box for "Create subdir" tells the program whether or not image assets should be placed into their own directory (currently named as date stamp), or are placed in the server root.
The best way to use this currently is to install a local FTP server (e.g. FileZilla) and have it host/point to a public cloud service folder (e.g. DropBox, SugarSync, Google Drive). I would suggest to install on the computer you're doing MT designing itself. This means you can use localhost or the ip 127.0.0.1 as FTP server hostname/ip. Whether or not you choose to have the FTP server service start automatically after reboot etc. is up to you; just remember to turn the service on when you want to transfer else you'll encounter errors.
You will have to create an admin/user account in the server along with sharing the folder(s) you want to make accessible. For now, just share that one folder.
In FileZilla, you can do this by:
1. going to Edit -> Users -> General -> Add. Fill out the details. Don't forget to enable the account. Since you'll be working locally, you can opt to not use SSL. It's up to you.
2. Next would be to click on Shared folders to the left and add your cloud service folder. There's a checklist of permissions to the right. Allow read and write, at least, for "Files", and Create, List, +Subdirs, for "Directories".
3. Click Ok.
You can create an entry under Repositories in Campaign Properties for ftp://127.0.0.1/index.gz. Depending on whether or not you have an actual index file at that location, may cause a "quiet" error. Just ignore it. This will provide an entry in the FTP dialog to click on to save some time in the future.
That's it. You're set.
# Fixed the bug reported by DJuego. I missed a context on where to set a token's origin point, specifically when it is dropped into play from the library.
# I realized that I didn't transfer over code from my fork to the test build to properly return tokens to to their origin point when no movement was done by the key token. You can test for this bug by opening b87- or older dev builds, and using a mixed group (snapped and unsnapped to grid) of at least 2 tokens. Lead the group by an unsnapped token first. Once moved, click and hold in place a snapped-to-grid token. Move the mouse a fraction and drag images will immediately show an offset. Release the hold and you will observe that the unsnapped token will land at the offset point instead of its origin.
This has been corrected and the method has also been applied to movement denial where instead of querying a token's path and getting the first cell, it now uses the the origin point property I put in place; this should be marginally faster than what it is right now.[/spoiler]
[spoiler=Version 0.8 - 0.9]# Fixed footprint lighting after grid adjustment to correctly follow token; plus small changes to this aesthetic.
# Applied FoW lag fix. This will be discussed in more detail on posts coming during and after 1/18/2013
# Included is my modified MapTool launcher. It's the file named "Start-MapTool.jar". Due to the wildcard bug introduced in Java 7u10, the current method of running the MT executable is now broken. The launcher, therefore, requires the user to "register" the MapTool executable. You can do so using the button provided, you can't miss it. Once registered, this will hold the MT executable's name until otherwise set to another value.
There is also a new option to set the path to a preferred JVM to launch MapTools. This has value for both advanced and beginning users, the details of which can be easily found by going through the forums. Please note that this is optional, you DO NOT have to set this up as the launcher will utilize the system-registered JVM by default like it always has.
Users will notice the "Console" toggle. This simply switches whether MapTool launches with a java console or not (i.e. java or javaw). I made the changes and did some tests all in one sitting, so there may be small bugs I didn't catch. While I'm certain that this launcher is cross-platform, I never did get any feedback from users with other operating systems.[/spoiler]
[spoiler=Version 0.9 - 0.95]A relatively minor update, testers not concerned/interested with what's listed on this changelog need not update.
# MT launcher now displays console window properly when Console toggle is selected. The fix was to launch the MT application through the OS shell. However, running this on OS X and Linux is untested. Linux users should install the xdg-utils package for this to function. Please feel free to make any comments about the implementation.
# FoW fix fully implemented. Essentially, there are 2 contexts (day and night). Day employs minimal soft fog tracking as opposed to version 0.9 where it wasn't tracked at all. Night implements an alternate to path-oriented FoW exposure. It is still slow but not in the runaway manner seen in the reported bug.
Taken in small steps, the lag is not too tedious. Each step on a small path takes roughly 1500 to 2500ms to compute. Anything beyond 10 steps and things start to escalate.
Thus, performance can be toggled by switching between day and night views accordingly.[/spoiler]
the sun hasn't risen yet over here, so I'm not 100%. I was able to replicate, thanks. I did come across this while path fixing, and I'm sure I handled it. It's likely as I mentioned, something I forgot to extract. IIRC, it's a couple of lines, so combing through stuff would take some time.