MapTool Dev Build (testing, version 0.95) - Jan. 28, 2012

[wolph42]

short test result:
- the 'invisible token' issue seems to be fixed. Im saying 'seems' cause its a bit hard to check as the the 'last saved position' feat is gone. (there where you saved you game and zoom level is where your game also starts). Its not a biggie as it didn't work properly anyway, cause as soon as peeps started to log in the start up screen could switch to any map. I did check it and I also used a feat of the bot to set a map and location on campaign load (just missing the zoom level) and all the tokens appeared at load.
- also the initialization of the special pads works again. (this was the reason for the last report about the $ issue) so that fixed as well.
did not check repos, not sure how to test that.

@azh: will or won't you be adding jamz VBL patch to the next release? I've spend a rather large amount of time testing and fine-tuning it (well the feedback part anyway) and it seems to work solidly. I've also spend a big part of my time in implementing useful feats into the bag of trikcs (of which i guess vbl on doors is no 1) and I have not found one single bug in it. Hence im rather curious whether you will allow it into the next build.

[Lee]

thanks wolph. it may be a by-product of the fix as I placed everything behind a background process before revealing the map at a set scale. While I found the last saved position helpful, it also is sometimes annoying when your last saved position had a zoom level of 200+%. I thought an "eagle's eye" view would be more helpful coming back to a game.

To everyone:
NVM on the repository test. It seems the FTP functions were meant to be used in a feature that I'm not sure was ever enabled, which was to update a repository that supports FTP. It's really helpful since it transfers assets directly into a repository archive, but only for those who are using FTP hosts, or are versed with setting one up. Sadly, cloud services like Dropbox, SugarSync, Google Drive, SpiderOak, Box et al. currently do not support FTP at this time.

If the devs allow the enabling of the FTP features, I'll be motivated to get it working properly for MT official. Once that's done, I'll probably try and write a tutorial on how to setup a local FTP server (e.g. FileZilla) for use with the MT FTP client service, which updates a repository file in a cloud service folder, which then gets uploaded by that cloud service of choice. If not, then it might be on my fork's todo list.

The current repository export already does this if one sets it to dump into a cloud service folder anyway, but there might those who prefer using FTP.

[Lee]

Details in the post above:

I had some free time and set up a local FTP server to do debugging etc. and I was able to fix the bugs concerning the repository updating through FTP, which I think have been there from the point it was introduced. Using the the original implementation in MT's source, the operation was conducted speedily and left assets in a more desirable state (i.e. things are already unzipped) than the current export repo option, which leaves the user with a zip file he/she needs to unzip for use.

So, 3 questions for the devs:

1. Is MT strict about the repo structure being the "assets" directory and the index.gz archive? Currently, the FTP processing creates a sub-directory using a timestamp as name, e.g. "12-21-2012" and the index.gz archive. Will this work or does it really have to be "assets"?
2. Would enabling this commented out feature and submitting the fix be against the feature freeze?
3. What about matching the current repo export to how the ftp repo update does it? It would take away most of the hassle described here if this were used in conjunction with services like Sugarsync etc. BTW, it'd be nice if the wiki article gets updated to detail the wonders of these auto-syncing cloud services.

I also tested the FTP fix submitted in Testing and found two things that needs fixing; that is if we're going to use it and if we're going the path of using Java 7 purely. First, it's really slow; either the transfer speed needs to be tweaked or things are being done repeatedly from the top (I didn't check). Checking the server stats, the transfer speed was about 8 KBps Secondly, it causes the following error during transfer (this happens for every asset):

Spoiler

sun.net.ftp.FtpProtocolException: MKD 2012-12-21:550 Directory already exists

at sun.net.ftp.impl.FtpClient.issueCommandCheck(FtpClient.java:541)
at sun.net.ftp.impl.FtpClient.makeDirectory(FtpClient.java:1412)
at net.rptools.maptool.client.ui.io.FTPClientConn$1.run(FTPClientConn.java:101)
at net.rptools.maptool.client.ui.io.FTPClientConn$FTPSingleFileCommand.execute(FTPClientConn.java:38)
at net.rptools.maptool.client.ui.io.FTPClientConn.mkdir(FTPClientConn.java:105)
at net.rptools.maptool.client.ui.io.FTPClient.prepareOutputStream(FTPClient.java:297)
at net.rptools.maptool.client.ui.io.FTPClient.doit(FTPClient.java:332)

The transfer doesn't suffer from this but, of course, it does point out to a part that only needs to be once.

These were all tests using the Sun Net libraries for J6 and 7. I opted to debug using something that (at least theoretically) works. Since, it looks sound, I'll do the Apache Commons Net library when I have the time, and only if we're not using the submitted FTP patch described above.

Update 2:

Apache net library implemented successfully. After conducting more tests, apparently, the speed issue has something to do with the old code and Java 7 itself since it's happening using either the sun or apache libraries. Updated the code and speed issue is now solved. The next test will be conducted on a remote server.

[Azhrei]

1. Is MT strict about the repo structure being the "assets" directory and the index.gz archive? Currently, the FTP processing creates a sub-directory using a timestamp as name, e.g. "12-21-2012" and the index.gz archive. Will this work or does it really have to be "assets"?

It does not have to be assets/ as long as the name in the index.gz references the correct subdirectory.

Part of the purpose of the FTP facility was to allow only new assets to be uploaded instead of re-uploading everything in the campaign. Hence the use of a timestamp for the directory...

2. Would enabling this commented out feature and submitting the fix be against the feature freeze?

I believe the code was originally commented out was because people started using DropBox,SugarSync,whatever and FTP wasn't really needed any more.

Although it would still be nice to have it for those folks who run their games on an internal LAN without 'net connectivity.

I would consider looking at and testing the patch and then including it in the next build.

3. What about matching the current repo export to how the ftp repo update does it? It would take away most of the hassle described here if this were used in conjunction with services like Sugarsync etc. BTW, it'd be nice if the wiki article gets updated to detail the wonders of these auto-syncing cloud services.

Hm. Now I have to re-think my above statement! The purpose of the feature freeze is to not introduce new code that needs to go through a build-release-test-fix-buildagain sequence. We want to have just One More Build (tm).

So I'm going to retract my previous statement. If code is being added that needs to go through public testing, then it's going to add substantially to the release cycle (especially given Craig and my current schedule!).

I also tested the FTP fix submitted in Testing and found two things that needs fixing; that is if we're going to use it and if we're going the path of using Java 7 purely. First, it's really slow; either the transfer speed needs to be tweaked or things are being done repeatedly from the top (I didn't check). Checking the server stats, the transfer speed was about 8 KBps Secondly, it causes the following error during transfer (this happens for every asset):
sun.net.ftp.FtpProtocolException: MKD 2012-12-21:550 Directory already exists

Sounds like the mkdir() method doesn't track that the directory is already there! Probably the calling routine doesn't cache the return value so it tries to create the directory every time, or the mkdir() isn't returning a valid status so the caller thinks it's failing.

Got lots of errands to run this weekend but I'm hoping to get the rest of the patches committed!

[wolph42]

@az: i left a remark for you a few posts up. Could you answer that one as well

[JamzTheMan]

short test result:
@azh: will or won't you be adding jamz VBL patch to the next release? I've spend a rather large amount of time testing and fine-tuning it (well the feedback part anyway) and it seems to work solidly. I've also spend a big part of my time in implementing useful feats into the bag of trikcs (of which i guess vbl on doors is no 1) and I have not found one single bug in it. Hence im rather curious whether you will allow it into the next build.

Inquiring minds want to know! I've been lurking (holidays are crazy busy time!) but still around and would be around in the unlikely event that the VBL code goes live and needs a fix. I say unlikely only because Wolf and I (and a few others) have been running the code for a while without issue. I put it through real world use 6-8 hours every Sunday

Hopefully this will pass the Az build once (skipping release-fix-release phase) test as hopefully all of Lee's work as well. These dev builds are awesome!

[Lee]

It does not have to be assets/ as long as the name in the index.gz references the correct subdirectory.

Ah, good. No worries then.

I believe the code was originally commented out was because people started using DropBox,SugarSync,whatever and FTP wasn't really needed any more.
Although it would still be nice to have it for those folks who run their games on an internal LAN without 'net connectivity.

I would consider looking at and testing the patch and then including it in the next build.

Hm. Now I have to re-think my above statement! The purpose of the feature freeze is to not introduce new code that needs to go through a build-release-test-fix-buildagain sequence. We want to have just One More Build (tm).

So I'm going to retract my previous statement. If code is being added that needs to go through public testing, then it's going to add substantially to the release cycle (especially given Craig and my current schedule!).

Point well taken. One more build is definitely the goal. So no matching of the repo export to the FTP method of preparing files. No problem. If people find the update method employed by FTP attractive, I think I can write a tutorial about setting up a local FTP server hosting a cloud service folder.

Sounds like the mkdir() method doesn't track that the directory is already there! Probably the calling routine doesn't cache the return value so it tries to create the directory every time, or the mkdir() isn't returning a valid status so the caller thinks it's failing.

I just did those tests just in case tiorthan wanted to redo things. The furthest I got today was to setup a remote server and test the code. Unfortunately, the speed issue has returned, though it may be for different reasons altogether. I'll have to reset to Java 6 to see if it is yet another J7 issue. If not, it's back to the drawing board. Originally, I've tried buffered and byte-per-byte, to letting the library handle things internally (the latter worked for the local hosted server), but I have yet to use the 1st 2 approaches for the remote tests.

Thanks for the input

Edit: I forgot to mention that I won't be able to do this for the next few days. Maybe sometime after Christmas. Anyway, happy holidays everyone!

[Azhrei]

I replied to wolph's question in the other thread.

[Lee]

FTP issues are fixed. There really was an underlying bug on the Java 7 end, idk if we'll be seeing an official fix from Oracle anytime soon. Everything looks to be stable, though I won't be uploading the test build today. There seems to be an unrelated problem with how MT checks for differences between local and remote asset repositories, so I'll look into that first before the next update. Currently, even after making a call to the handler, everything still gets sent down the wire even when copies exist on the remote end.

@Azhrei: I haven't really looked, but clients pull assets from repositories through http, correct? At least it's not using FTP from what I can tell.

[DJuego]

Hi! Merry RPG Christmas!

I am testing the Maptool Dev Build (version 0.7). (Thank you Lee for the revival) and i have a recurrent bug. Too serious, so the problem must be my (very specific) configuration In any case, i want to 'register' it.

Windows 7 74 bits 8,00 GB i7CPU 960 3,07GHz 3,07GHz
I use Java Portable (from portableApps) . My launch file is:

Code: Select all

@echo off
REM set RUTA=m:/Maptool/maptool-dev/Java64_7_Update_7/bin
set RUTA=m:/Maptool/maptool-dev/jPortable_7_Update_10/bin
REM set RUTA=m:/Maptool/maptool-dev/jPortable_6_Update_31/bin

%RUTA%/java -Xms64M -Xmx1024M -Xss4M -jar -Duser.language=EN -Duser.region=US -DMAPTOOL_DATADIR=M:\.Maptool maptool_dev.jar run
pause

1) I drag a image (any image) from my library to Object layer.
2) I move this image

Code: Select all

java.lang.NullPointerException
	at net.rptools.maptool.model.SquareGrid.convert(SquareGrid.java:234)
	at net.rptools.maptool.model.Path.derive(Path.java:188)
	at net.rptools.maptool.model.Token.applyMove(Token.java:822)
	at net.rptools.maptool.client.ui.zone.ZoneRenderer.commitMoveSelectionSet(ZoneRenderer.java:426)
	at net.rptools.maptool.client.tool.StampTool.stopTokenDrag(StampTool.java:173)
	at net.rptools.maptool.client.tool.StampTool.mouseReleased(StampTool.java:418)
	at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
	at java.awt.Component.processMouseEvent(Unknown Source)
	at javax.swing.JComponent.processMouseEvent(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$200(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$1.doIntersectionPrivilege(Unknown Source)
	at java.security.ProtectionDomain$1.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$1.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at net.rptools.maptool.client.swing.MapToolEventQueue.dispatchEvent(MapToolEventQueue.java:38)
	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)

1)The bug is 'recoverable' (Maptool does not crash).

2)There are no problems with the background layer.

3)The problem happens with Java64_7_Update_7,jPortable_7_Update_10 and jPortable_6_Update_31.

DJuego

[Lee]

Thanks DJuego. While I was aware that MapTool (oddly?) has 2 branches handling stamps and tokens, I put off reflecting the changes I've made with the pointer tool into the tool handling stamps, since the code itself made mention of consolidating the stamp tool with the one for tokens. I kept forgetting to ask the devs about it but, for now, I'll make the reflection to address this.

Do check back for 0.8 for the fix. Thanks again.

Edit: what you can do right now is to place your intended stamps on the token layer, move them where you like, then set their layer to OBJECT after. Just a thought.

[Lee]

0.8 is now live. Please check the changelog for details. If there're any questions, don't hesitate to ask.

Thanks and a happy new year to all.

[DJuego]

I want to confirm in public that the problem that I reported has been resolved in 0.8. Thanks Lee!

P.S: Only I miss an (more or less) exhaustive changelog in relation to the 1.3b87 version. Ooops! My fault! I find it!

More P.S: The strike tag seems not to work in the forum. I miss it!

DJuego

[Bone White]

0.8 is now live. Please check the changelog for details. If there're any questions, don't hesitate to ask.

Thanks and a happy new year to all.

Perhaps this is worthy of a news article on the main site to show that we are still active, and adding it to the main site download section?

[DJuego]

0.8 is now live. Please check the changelog for details. If there're any questions, don't hesitate to ask.

Thanks and a happy new year to all.

Perhaps this is worthy of a news article on the main site to show that we are still active, and adding it to the main site download section?

I agree. On the other hand, Is there any plan or ETA for official release? I think a public TODO list with check marks would be psychologically cool.

DJuego