Future of MapTool?

Thoughts, Help, Feature Requests, Bug Reports, Developing code for...

Moderators: dorpond, trevor, Azhrei

Forum rules
PLEASE don't post images of your entire desktop, attach entire campaign files when only a single file is needed, or generally act in some other anti-social behavior. :)
tiorthan
Cave Troll
Posts: 84
Joined: Fri Aug 24, 2012 8:56 am
Location: Germany
Contact:

Re: Future of MapTool?

Post by tiorthan »

I haven't been following this for the last few days (due to some unexpected real life issues), so besides testing, is there anything I can help with?

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: Future of MapTool?

Post by wolph42 »

tiorthan wrote:I haven't been following this for the last few days (due to some unexpected real life issues), so besides testing, is there anything I can help with?
well than you didn't miss much as the test file was uploaded about 8 hours ago. What you can try to do is put up the big puppy eyes and ask Lee whether he's willing to create a build with all (available) patches. Beside that, I guess testing is the main thing to do here.

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Future of MapTool?

Post by jfrazierjr »

wolph42 wrote:Hi Lee,

The good news: did a first test run and checked the most critical failures in J7: no issues !! (didnt test upnpn as promised)
The annoying news: I noticed that you did not included ALL patches (where you could lay your hands on) like your own input() patch and jamz' vbl patch. And if I'm to conduct a more thorough test I'd like to test ALL changes, so I do not have to check twice and mayhep encounter cross issues when other patches are applied later.
Honestly, I would say we should NOT be doing things this way. The only changes people should testing(out side of those which they apply directly to source and build their own jar for their own use) are those that are checked into the source control. We have a testers forum where users who wish to test changes are taught how to set up the development environment and test against the code which has been checked in(and thus WILL make it into a build...barring critical issues that would require removing it from the source repository). As well, we can show those who want to help how to apply patches so that they can be tested prior to being checked in AS WELL AS how to revert the changes from those patches to ensure that the stay with the current code versions.

IMHO, you are wasting your time by testing a jar some random person built unless it is base-lined from the source code ONLY since there is no guaranteed that it will ever get into the source code. To make matters worse, if you say it's fixed, and then an official jar is built a month later without that patch, your protestations that it was fixed could then send Azhrei, Craig, and/or others on a wild goose chase trying to find out what happened to the fixed and why it's suddenly not there anymore.

Just as importantly, this thread is open to the world which means any random Tom, Dick, or Harry could come in here, grab the built jar, EASILY get confused that they have a custom jar file(as above). However, the Testers forum is isolated( can only see by invite) and thus much more limited in scope. As well. we don't build jars for people in the Testers forum, so again, it's always going to be directly running source code they are testing with no chance of mixing up which jar file is which and contains what, etc...

Anyway, that's just my option.
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: Future of MapTool?

Post by Lee »

I'm afraid I have to agree with JFJ. Here's a reply I was about to send last night but was too groggy to proofread properly:
Um, I thought that was the purpose of doing something as close to vanilla as possible? To test what the devs left as the official build material in order to to help them whisk out MT 1.3 Final at the soonest they can make it?

With the exception of what I did to get over the Java 7 and rplib errors, this was what Craig left last August. Like what A.M. and several others said, all the new stuff can be piled on top of the final build once it comes out, so that was the line of thought I had when I built that; the line of thought being: To catch any existing bugs that have not been introduced by new code such as tiorhan's and my patches, and new functionality such as my input extensions and Jamz' VBL.

It's especially true for the last 2 items. I touched the critical JSON class (along with 1 or 2 others) to make my input patch work. I imagine Jamz did the same for his work too. The JSON class itself uses sorting heavily and no testing has been done on the untouched official code to see if Java 7 has any adverse effects to it. I think we'll best serve Azhrei/Craig/JFJ if we can help iron out the kinks, such as the ones you and A.M have reported (e.g. getMoveCount, getLastPath). Finding such things are what you guys do very well; and tiorthan and I will do what we can till the big guns come back.

As for UPnP, even when I said that the libraries for that seem unchanged, do try to test it out. When I say unchanged, I mean that they are exactly the same as what were in b88, and people using it said UPnP worked fine. Plus, every indication on Azhrei's and Craig's posts says that they've addressed the problem, and only the breaking of b88 got in the way of ascertaining if this was true.

I just want to reiterate that FTP functionality is broken, only because I commented the errors out instead of addressing them right now. The FtpClient class now demands the implementation of several methods and several method calls in the MT code are now unrecognized. I will eventually come around to either writing what is needed for those classes or finding a library that fits the need. However, there's another large part of the code I'm embroiled in right now, so it'll have to wait, or someone else can work on it instead..
@JFJ I think the file I shared is a middle ground of sorts. It's directly what's on the trunk, but changed only to get over the hump of the Java 7 errors, and patches that were not applied (but with prior approval from Azhrei, like the PaintChooser fix). I feel that it's something to run with in finding out more bugs in the official code. Perhaps, this thread should be moved to the Testing section? No one, other than devs and the most technical of MT users, are interested in the recent line of discussion anyway.

While you're here, the Ftp classes are a mess :lol: It seems in 7 they split the class in 2, opting for impl instead of what was directly offered on versions up to 1.6. Funny that documentation of the changes is hard to come by. IDK which route to go with really, writing the necessary code or looking for an alternate library. It's something you guys are needed to decide on.

Edit: missed your post tiorthan
tiorthan wrote:I haven't been following this for the last few days (due to some unexpected real life issues), so besides testing, is there anything I can help with?
Are you setup on 1.7 in your IDE? You could tackle the Java 7 impact on the FtpClient and FTPCommand classes, if you're interested.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: Future of MapTool?

Post by JamzTheMan »

Ah the joys of open source code, opinions all over the place :)

I fall into the middle ground here. Given there are a few active people like
Lee and Wolf that are simply trying to move the product along in what has been a very slow year, I would rather see suggestions on how to move forward in SOME way. If it is moving to the testers section, so be it.

But honestly, I highly doubt we have to worry about someone reading through these posts and picking up a random jar that then coming to the forums needing help. If that were the case, we should roll back to a public version that works on java 1.7 because I see posts on that every week.

Personally, at this point I just want to figure out what patches I need to add or remove to get this to work on 1.7 before 1.8 comes out for my own use, and if it helps the community out, cool.

If we just want to keep the general public out, then let's move to some other thread that is appropriate so Lee can keep trucking along :) I do like hearing about his findings in any case.

Edited for grammar because typing on a Xoom autocowrecks...
Last edited by JamzTheMan on Mon Nov 05, 2012 6:56 pm, edited 3 times in total.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: Future of MapTool?

Post by wolph42 »

JamzTheMan wrote:Ah the joys of open source code, opinions ask over the place :)

I fall into the middle ground here. Given there are a few active people like
Lee and Wolf that are simply trying to move the product along inn what has been a very slow year, I would rather see suggestions on how to move forward in SOME way. If it is moving to the testers section, so be it.

But honestly, i highly doubt we have to worry about someone reading through these posts and picking up a random jar that then boring up the forums needing help. If that were the case, we should roll back to a public version that works on java 1.7 because i see posts on that every week.

Personally, at this point I just want to figure out what patches I need to add our remove to get this to work on 1.7 before 1.8 comes out for my own use, and if it helps the community out, cool.

If we just want to keep the general public out, then let's move to some other thread that is appropriate so Lee can keep trucking along :) I do like hearing about his findings in any case.
what he said. (scarily close to what I wanted to write)

User avatar
Sol Invictus
Cave Troll
Posts: 95
Joined: Fri Oct 21, 2011 12:48 pm
Location: Jena/Thuringia/Germany

Re: Future of MapTool?

Post by Sol Invictus »

Yeah. No one would expect a version from the Testing Forum to work or any support for it, but many (me e.g.) would only be able to help with the testing if there was an .exe or .jar to run. Providing feedback on a persistent bug is one thing - but compiling a program is absolutely impossible for me.

User avatar
wolph42
Winter Wolph
Posts: 9999
Joined: Fri Mar 20, 2009 5:40 am
Location: Netherlands
Contact:

Re: Future of MapTool?

Post by wolph42 »

yes, to elaborate a bit on my short answer: I did use to use eclipse but it failed on me a couple of times and form a certain point onwards it failed completely and I could not get a mt session running from it, that was when I stopped, a .jar file 'fixes' this as the difficulty and effort level to test is a LOT lower. Finally I run face to face games so I'm willing to take a bit of a gamble and use beta versions to run my games on, there are nearly no better ways to test beta versions then using it in RL (strange line for an rpg game but ok). That can only be topped by thorough testing protocols and I think you have to look very hard for someone willing to write or use those.

Also I think that the community is declining (fast?) cause of this major bug, keep in mind that maybe 10% of all users will actually go trough the trouble of going to the forum and reporting their issue and by now EVERY new user WILL encounter the j7 bug, which means that 90% of them is lost before they get a chance to know the program and the other 10% will also not remain complete.

Then there's the point that Craig, Trevor and Azhrei are AFAIK on a very low burn rate when it comes to v 1.3 so *when* they have time to get in I'd prefer they use that time to compile v89 which by then should be already tested for at least any critical bugs.

In short ANYONE willing to test this is most welcome, I find it highly unlikely that a stray new user finds her way here and then also accidentally installs this beta test version and then also 'forgets' that its actually a test version and then also gets frustrated and leaves when encountering issues (where I have to note that I did not find any issues so far).

But ok to give you (JFJ) the benefit of the doubt I'll start a new topic asking who is currently testing MT using eclipse.

tiorthan
Cave Troll
Posts: 84
Joined: Fri Aug 24, 2012 8:56 am
Location: Germany
Contact:

Re: Future of MapTool?

Post by tiorthan »

The Java devs discourage using the sun packages precisely because they are not part of the official SDK and may not be stable between releases. Therefore I would switch to something else like for example org.apache.commons.net.ftp.FTP

Edit:
Ah, on a different note, it's not worth the trouble to include a new dependency, I'm just going to rewrite it to use the JDK 7 sun package. Azh will have to use 1.7 to compile the stuff, it should still run with jre6 though.
Besides, Azh is a Mac user, right? So 1.7 for packaging should be more convinient anyway.

Edit 2:
Patch is going to be up tomorrow.

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Future of MapTool?

Post by jfrazierjr »

tiorthan wrote: Besides, Azh is a Mac user, right? So 1.7 for packaging should be more convinient anyway.
Don't make any assumptions about build environment! Apple has this annoying habit of screwing users that are not using the latest version of their OS by not allowing them to get updated versions of Java. I can't say for sure, but if Azhrei is on an older Mac, he may very will not be able to use Java 1.7 at all(but I am fairly sure he does have a recent version of MacOS though)...

What exactly is the problem with the the FTP stuff? Is if a critical item to fix or ????
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: Future of MapTool?

Post by Lee »

@tiorthan thanks for taking this on

@jfrazierjr it needed some rewriting, I'm afraid. As tiorthan mentioned, the sun library in 1.7 was changed with regards to FTP (I'm sure some of the other net classes were as well). Basically, our 2 classes for client and command related stuff needed a simple required implementation of the "new" methods and the more tedious task of refactoring methods that worked for MT that stopped working in 1.7 (e.g. issueCommand). For example, they also integrated a change in the login procedure asking for character arrays in place of strings; which I think is a good thing security-wise.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: Future of MapTool?

Post by JamzTheMan »

I wondered why my initial environment was blowing up on the FTP commands, thought I had messed my environment up or something :) But I needed to go back to the stable version anyway to properly code my patch :)
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork

tiorthan
Cave Troll
Posts: 84
Joined: Fri Aug 24, 2012 8:56 am
Location: Germany
Contact:

Re: Future of MapTool?

Post by tiorthan »

Indeed, the sun.net package was changed massively, to a point where the original FTPClientCommand would not compile. Also the internal structure was changed so that just implementing the missing methods would not have helped.

I've already written a patch which compiles but that does not mean it works. I'm unfamiliar with how the FTP stuff is even used in MapTool. It would help me, if any of you, from the top of their head, could tell me when directories are created on an ftp server and when files are deleted? Otherwise I will have to find out tomorrow.

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Future of MapTool?

Post by Azhrei »

Sorry guys. Long time, no write. Life has been wicked lately (I got stuck in NYC during Sandy and I certainly have sympathy for those who are still stuck there without power or other basic necessities!)

To help prevent people from taking my name in vain too loudly, I've attached the fixed UPNP library source code (two JARs are inside, a "debug" and "nondebug" version).

I'm teaching a class this week and writing new lectures in the hotel each evening as I go along (this group of students is much more advanced than expected!) so no time this week. I'll try to allocate some time on Friday and/or this weekend to look into things and get some code committed. :|
Attachments
sbbi_upnplib_src_1_0_5.tgz
UPNP library source code
(2.23 MiB) Downloaded 39 times

Lee
Dragon
Posts: 958
Joined: Wed Oct 19, 2011 2:07 am

Re: Future of MapTool?

Post by Lee »

Yay for Azhrei! I'll check on these libs right away.

@tiorthan Sorry mate if you had to rewrite a lot of stuff. I...um...sort of looked into it myself out of curiosity, and...ah...I think I found that only one class needed fixing instead of the 2, and wrote a fix as well XD. It was a lot shorter than I expected so I'm pretty sure you tackled stuff more comprehensively than I did. Let's compare patches tomorrow.

To my knowledge, the FTP functions are used for fetching stuff from the online library through the "Add Resource to Library" option in the file menu. I tested what I wrote and got the files from there without something exploding, so that's a positive. I also think this is the method by which clients send/receive asset information from the server. I'll have to test with multiple instances to confirm this.

Edit:
@Azhrei hmm these seem to be the same as what was committed. I guess this really implies that UPnP should already be working in what was shared above.
@tiorthan nope, nix some of what I mentioned. It's still 2 classes. I got cross-eyed and ended up looking at the actual sun FtpClient class :lol: sigh.

Edit # 2: @tiorthan I traced its usage to repository updating. Also, adding a library resource uses another method of getting files, so no impact there.

Edit # 3: Can anyone test UPnP using what I shared above? Also, as it might be related, can you also post MT debug info? I'm curious if it still detects IGDs but fails to do so when attempting UPnP when starting a server, or is blind altogether.

Post Reply

Return to “MapTool”