Future of MapTool?
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.
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.
Re: Future of MapTool?
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?
Re: Future of MapTool?
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.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?
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
- jfrazierjr
- Deity
- Posts: 5176
- Joined: Tue Sep 11, 2007 7:31 pm
Re: Future of MapTool?
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.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.
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..
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..
Re: Future of MapTool?
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:
While you're here, the Ftp classes are a mess 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
@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.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..
While you're here, the Ftp classes are a mess 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
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.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?
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: Future of MapTool?
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...
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
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: Future of MapTool?
what he said. (scarily close to what I wanted to write)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.
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
- Sol Invictus
- Cave Troll
- Posts: 95
- Joined: Fri Oct 21, 2011 12:48 pm
- Location: Jena/Thuringia/Germany
Re: Future of MapTool?
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.
Re: Future of MapTool?
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.
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.
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
Re: Future of MapTool?
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.
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.
- jfrazierjr
- Deity
- Posts: 5176
- Joined: Tue Sep 11, 2007 7:31 pm
Re: Future of MapTool?
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)...tiorthan wrote: Besides, Azh is a Mac user, right? So 1.7 for packaging should be more convinient anyway.
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..
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..
Re: Future of MapTool?
@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.
@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.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: Future of MapTool?
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
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: Future of MapTool?
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.
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.
Re: Future of MapTool?
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.
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
Re: Future of MapTool?
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 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.
@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 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.
My stuff for the community:
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in
Donate to the Mote Project
The Mote Project's G+ community
Mote on Facebook
Fully Customizable Calendar Drop-in