RPTools.net

Discussion and Support

Skip to content

It is currently Wed Nov 22, 2017 5:25 pm 






Reply to topic  [ 191 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13  Next

Previous topic | Next topic 

  Print view

Author Message
 Offline
Dragon
 
Joined: Mon Mar 23, 2009 3:48 pm
Posts: 326
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.1.7
PostPosted: Tue Aug 22, 2017 11:07 am 
Azhrei wrote:
paulstrait wrote:
[...] since it seems like it is still the case that regular periodic autosaving is broken).

I've been thinking about this. We should probably be keeping multiple autosaves and rotating between them. For example, we should create Autosave.cmpgn, renaming the existing file to Autosave-1.cmpgn, and doing that for 2-3 saves by default. Having a single autosave seems to mess people up sometimes when they accidentally do something and then an autosave triggers too soon for them to recover the existing autosave file. :(

I'll look into this; it shouldn't be too tough as it's just renaming existing files if they're already there. We can implement a spinner in the Preferences to control how many there are and default it to three...


That would be very nice -- or even just not allowing the autosave to be deleted until a new one is made. But the problem is a bit bigger than this: As far as I understand, maptool will only do one autosave per save. That is, the regular interval autosave function doesn't work (and hasn't worked for a while).


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12103
Location: Tampa, FL
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.1.7
PostPosted: Tue Aug 22, 2017 2:50 pm 
paulstrait wrote:
[...] maptool will only do one autosave per save. That is, the regular interval autosave function doesn't work (and hasn't worked for a while).

Hm. I'll add a entry for this to the issue tracker. Thanks.

PS: For completeness in the issue report, would you copy/paste the contents of your GatherDebugInfo panel to a post here? That'll give me version and platform information (among other things) that might be useful to tracking it down. Thanks. :)


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Mon May 10, 2010 11:59 am
Posts: 1706
Location: Chicagoland
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.1.7
PostPosted: Tue Aug 22, 2017 5:28 pm 
paulstrait wrote:
Ah, I see. I've read about that before, I guess I've been initiated in that club. Managed to use maptool nearly 10 years before triggering it somehow. Anyway, the other issue of token's movement being reverted sometimes when using ctrl-I to reveal vision for them seems like it has to relate to the things that were changed in this version. It happened when I used a macro to teleport a single token (didn't seem to happen when I moved more than one token at once) into a fog of war concealed area.

I don't know what was going on with my log file or with my autosave (though I suspect that even if the autosave had loaded, it would probably have been just the first autosave since the last save since it seems like it is still the case that regular periodic autosaving is broken).


Another Alt-F-Space-Space winner! :) That program feature for ultra-fast-campaign-reset has been there since 1.3! Thanks Az for fixing it though, I'll pull it into my fork as well for the next build.

As for reverting to 1.4.3.19, it's not going to help you with tokens. I didn't make any token changes or anything else that should affect that. Lets see, I changed a macro, fixed GUID, changed campaign saves, added a preference exposed Box2d test (code has been in for a few versions)...Nope, nothing that should affect you in that way.

Now, from time to time I will see tokens "snap back" and this is an issue going back farther than 1.4.0.0. From my testing, it seems to be more of a network/server issue and happens when a "token" gets very large "data" wise. In other words, if you store a LOT of data on it, you can have issues. Everytime you "change" or move a token, it transmits the whole token class (all it's data) over the network.

Also, if you have Indiviual FoW on, that can accumulate data.

Also, if you drag a token into VBL as a player, like into a wall, it may revert it's movement back, ie cancelling it's movement. Are you using the BoT?


Bottom line, I highly highly doubt 1.4.3.20 is causing your issues. :mrgreen:

_________________
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
More information here: MapTool Nerps! Fork | TokenTool Nerps! Fork
Custom TokenTool (version 1.0b33): TokenTool.exe


Top
 Profile  
 
User avatar  Offline
Demigod
 
Joined: Sun Feb 25, 2007 11:53 am
Posts: 3774
Location: MD
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.1.7
PostPosted: Tue Aug 22, 2017 9:26 pm 
JamzTheMan wrote:
Another Alt-F-Space-Space winner!

Shoot... if it had required "Alt-F" it would not have happened as much as it has... but it just requires "Alt-Space-Space-Space". Which if you're lazy with your left thumb and catch the Alt key next to the space bar when "pointing" for your players, you could easily sweep through the cycle without having any idea what just happened.

Thanks for the fix Az... now to get it pushed out in an "official" release so more people start benefiting from it!

_________________
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."


Last edited by Full Bleed on Wed Aug 23, 2017 1:26 am, edited 1 time in total.

Top
 Profile  
 
User avatar  Offline
Demigod
 
Joined: Sun Feb 25, 2007 11:53 am
Posts: 3774
Location: MD
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.1.7
PostPosted: Tue Aug 22, 2017 9:32 pm 
Azhrei wrote:
Hm. I'll add a entry for this to the issue tracker. Thanks.

PS: For completeness in the issue report, would you copy/paste the contents of your GatherDebugInfo panel to a post here? That'll give me version and platform information (among other things) that might be useful to tracking it down. Thanks. :)

Autosave has, apparently, been busted for a long time: viewtopic.php?f=3&t=27240&hilit=autosave

I think this has got to be the worst bug in MT right now. I already dislike the way it is *supposed* to work... and the way it's *actually* working right now is pretty useless. ;)

I hope you follow through with your multiple-saves option. Anything is better than what's there right now. Keep in mind that, even when working, "autosave" is really just a crash recovery save... since it deletes the autosave when the program is closed.

_________________
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12103
Location: Tampa, FL
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.1.7
PostPosted: Tue Aug 22, 2017 11:47 pm 
Full Bleed wrote:
I already dislike the way it is *supposed* to work... and the way it's *actually* working right now is pretty useless. ;)

Well, now you've opened a can of worms. How do you propose it should work? We'll see how close we can get to your ideal solution. :)


Top
 Profile  
 
User avatar  Offline
Demigod
 
Joined: Sun Feb 25, 2007 11:53 am
Posts: 3774
Location: MD
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.1.7
PostPosted: Wed Aug 23, 2017 12:47 am 
Azhrei wrote:
Full Bleed wrote:
I already dislike the way it is *supposed* to work... and the way it's *actually* working right now is pretty useless. ;)

Well, now you've opened a can of worms. How do you propose it should work? We'll see how close we can get to your ideal solution. :)

I'd like to see granular control of the "Backup" feature in MT. That is, allow users to 1) set how often and 2) how many backups of their campaigns are made. Right now, the "Backup" feature in MT is voodoo magic (and not in a good way.) No one has any control over it, and when tragedy strikes, they just hope something useful might be in that directory when they go desperately looking to see if MT has been backing up their work.

As for "Auto Save", I think it needs to be renamed to what it is: "Crash Recovery"

Once you make "Backups" function like people expect backups to function, then they won't expect "Auto Save" (aka "Crash Recovery") to do something it was not designed to do.

Then link the two by only having two settings in MT:

A) How often do you want to make a Campaign Backup?
B) How many Campaign Backups do you want to keep?

Require at least 1 Backup file (default to or suggest a higher number).
When a backup is written, a tiny "Crash Recovery File" would be created with the backup's name in it.
When MT is closed properly, the Crash Recovery File flag would be deleted.
If MT loads and sees a crash recovery flag, it will ask if the user wants to load the backup file associated with it (basically, the way it looks for Autosave files now.) However, if it doesn't see the flag, that means MT closed properly and there is no need for "Crash Recovery".

_________________
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12103
Location: Tampa, FL
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.1.7
PostPosted: Wed Aug 23, 2017 12:54 am 
Thanks, I'll start thinking about the design and implementation. :D


Top
 Profile  
 
 Offline
Dragon
 
Joined: Mon Mar 23, 2009 3:48 pm
Posts: 326
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.1.7
PostPosted: Wed Aug 23, 2017 10:10 am 
JamzTheMan wrote:
paulstrait wrote:
Ah, I see. I've read about that before, I guess I've been initiated in that club. Managed to use maptool nearly 10 years before triggering it somehow. Anyway, the other issue of token's movement being reverted sometimes when using ctrl-I to reveal vision for them seems like it has to relate to the things that were changed in this version. It happened when I used a macro to teleport a single token (didn't seem to happen when I moved more than one token at once) into a fog of war concealed area.

I don't know what was going on with my log file or with my autosave (though I suspect that even if the autosave had loaded, it would probably have been just the first autosave since the last save since it seems like it is still the case that regular periodic autosaving is broken).


Another Alt-F-Space-Space winner! :) That program feature for ultra-fast-campaign-reset has been there since 1.3! Thanks Az for fixing it though, I'll pull it into my fork as well for the next build.

As for reverting to 1.4.3.19, it's not going to help you with tokens. I didn't make any token changes or anything else that should affect that. Lets see, I changed a macro, fixed GUID, changed campaign saves, added a preference exposed Box2d test (code has been in for a few versions)...Nope, nothing that should affect you in that way.

Now, from time to time I will see tokens "snap back" and this is an issue going back farther than 1.4.0.0. From my testing, it seems to be more of a network/server issue and happens when a "token" gets very large "data" wise. In other words, if you store a LOT of data on it, you can have issues. Everytime you "change" or move a token, it transmits the whole token class (all it's data) over the network.

Also, if you have Indiviual FoW on, that can accumulate data.

Also, if you drag a token into VBL as a player, like into a wall, it may revert it's movement back, ie cancelling it's movement. Are you using the BoT?


Bottom line, I highly highly doubt 1.4.3.20 is causing your issues. :mrgreen:


Yeah, I certainly haven't looked at it scientifically or figured out to replicate all the specific problems we were having (except the big keystroke one that obviously isn't a 1.4.3.20 issue). I'm sure you are right, but after so many basically flawless sessions with 1.4.3.19, and after a single 1.4.3.20 session in which wonky things were happening constantly throughout the evening, my players would mutiny if we didn't revert. Despite a few of them being engineers, they are kind of superstitious like that. Skepticism about upgrades combined with confirmation bias, focalism, etc.

We are using BoT, I'm familiar with the effect you are talking about, but this was different as it didn't happen upon movement, but rather upon revealing vision. It was a very distinctive phenomenon that happened several times that I've never seen before. I'm sure it has something to do with individual fog of war--I probably should just unselect that next time but I'm kind of curious to see if I can make the same thing happen in 1.4.3.19 keeping every other variable constant. Classic GM vs scientist identity conflict.


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Mon May 10, 2010 11:59 am
Posts: 1706
Location: Chicagoland
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.1.7
PostPosted: Wed Aug 23, 2017 5:28 pm 
Oh sure, i get it. And by all means, try 1.4.3.19 and see if you replicates again. Although, if it doesn't, that's not solid proof either... Only if you go to 1.4.3.20 and it happens again after not happening in 1.4.3.19 would it seem to prove something.

Keep me updated if you find something. I'm sure the "loose everything" moment overshadowed any other issue...

_________________
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
More information here: MapTool Nerps! Fork | TokenTool Nerps! Fork
Custom TokenTool (version 1.0b33): TokenTool.exe


Top
 Profile  
 
 Offline
Kobold
 
Joined: Mon Oct 02, 2017 10:21 pm
Posts: 2
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.3.+
PostPosted: Mon Oct 02, 2017 10:50 pm 
JamzTheMan wrote:
Thanks for the feedback!

BTW, I forgot, <SPACE> pauses the action. (So, more MT like :) )

As far as getting it into MT, still lots of work. Have to get the ortho camera to pan/zoom, iterate through objects and place them, get everything in MT to translate to the "pixel per meters" system in libgdx, and of course, mouse actions. Although, I did set it up like this it could progress in chunks. And if it shows what you want, you "could" still use it in place/over the normal MT window. I'll look into getting it into the same frame/space as the current map space (with a toggle) (unless people like the floating view, possibly a 3rd option)

The only thing I don't like is It doesn't seem to be a away to adjust the light drop off. In other words, the light may illuminate out 30 meters but it gets pretty dark that last 10-15 meters. I'd like control so only the outside "square" was shadowed/dim. (although it may look more realistic now). Once I get tokens and drop light DnD light sources down, we'll see what a dungeon looks like...


First of all, great work on this! Our group is looking for a VTT other than Roll20 and we keep coming back to MapTool. I came across this fork while browsing here. So far, it looks a lot better than the "standard" Maptool.

But I signed up to make some comments and questions about some of discussion said here. I am an Android developer with a background in Java, and I'm familiar with libgdx as a toolkit. To my knowledge, there is no way you can accomplish what you are stating you can do here. MapTool looks like any old Java app made with Swing. LibGdx uses OpenGL with its own native windowing system. They just don't match. Unless there's some sort of interface now that allows you to embed a libgdx canvas into Swing? The rendering cycle alone between the 2 are completely different. Libgdx uses one that is compatible with how mobile devices refresh their views. Swing is well...Swing. I'm curious about how you're going tackle this and the other challenges I suspect exist. You may end up finding out that you'll need to write a completely new app :lol:

I apologize for the comments. I don't mean to be so negative, but I was quite excited when I read the part about "realistic lighting" but then saw "libgdx". I thought to myself right away that the idea just won't work and people should not get their hopes up needlessly. There are gaps too great to cross tech-wise.

It's not really my problem. I just felt you and others should know what you're getting into. For my group, MapTool is looking quite solid, especially Nerps. Thanks for all the effort on this!


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12103
Location: Tampa, FL
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.1.7
PostPosted: Tue Oct 03, 2017 7:45 am 
TL;DR, but Jamz has been working on integrating JavaFX into RPTools code. There may be something in JFX that will render the canvas properly for inclusion in a Swing app.

We have plans to replace Swing with JavaFX, but as you said, it's basically a rewrite of the entire GUI layer so that's a long-term plan.

Thanks for joining us at RPTools! :)


Top
 Profile  
 
User avatar  Offline
TheBard
 
Joined: Tue Mar 21, 2006 7:26 pm
Posts: 3483
Location: Austin, Tx
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.1.7
PostPosted: Tue Oct 03, 2017 8:06 am 
Hal,

Thanks for the input. Feel free to dive in a code a bit for MapTool. We're community driven so things don't improve without community developers helping. Let us know if you are interested.

_________________
ImageImage ImageImageImageImage
Support RPTools by shopping
Image
Image


Top
 Profile  
 
User avatar  Offline
Great Wyrm
 
Joined: Mon May 10, 2010 11:59 am
Posts: 1706
Location: Chicagoland
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.3.+
PostPosted: Tue Oct 03, 2017 8:51 am 
Hal wrote:
JamzTheMan wrote:
Thanks for the feedback!

BTW, I forgot, <SPACE> pauses the action. (So, more MT like :) )

As far as getting it into MT, still lots of work. Have to get the ortho camera to pan/zoom, iterate through objects and place them, get everything in MT to translate to the "pixel per meters" system in libgdx, and of course, mouse actions. Although, I did set it up like this it could progress in chunks. And if it shows what you want, you "could" still use it in place/over the normal MT window. I'll look into getting it into the same frame/space as the current map space (with a toggle) (unless people like the floating view, possibly a 3rd option)

The only thing I don't like is It doesn't seem to be a away to adjust the light drop off. In other words, the light may illuminate out 30 meters but it gets pretty dark that last 10-15 meters. I'd like control so only the outside "square" was shadowed/dim. (although it may look more realistic now). Once I get tokens and drop light DnD light sources down, we'll see what a dungeon looks like...


First of all, great work on this! Our group is looking for a VTT other than Roll20 and we keep coming back to MapTool. I came across this fork while browsing here. So far, it looks a lot better than the "standard" Maptool.

But I signed up to make some comments and questions about some of discussion said here. I am an Android developer with a background in Java, and I'm familiar with libgdx as a toolkit. To my knowledge, there is no way you can accomplish what you are stating you can do here. MapTool looks like any old Java app made with Swing. LibGdx uses OpenGL with its own native windowing system. They just don't match. Unless there's some sort of interface now that allows you to embed a libgdx canvas into Swing? The rendering cycle alone between the 2 are completely different. Libgdx uses one that is compatible with how mobile devices refresh their views. Swing is well...Swing. I'm curious about how you're going tackle this and the other challenges I suspect exist. You may end up finding out that you'll need to write a completely new app :lol:

I apologize for the comments. I don't mean to be so negative, but I was quite excited when I read the part about "realistic lighting" but then saw "libgdx". I thought to myself right away that the idea just won't work and people should not get their hopes up needlessly. There are gaps too great to cross tech-wise.

It's not really my problem. I just felt you and others should know what you're getting into. For my group, MapTool is looking quite solid, especially Nerps. Thanks for all the effort on this!


Hi. Well, feel free to download my fork, go to the help menu, and click on the test menu option to launch a working LibGDX POC ;)

1. Yes, there is a hook to bring the libgdx canvas into a swing frame.
2. Ultimately, I plan to move from Swing to JavaFX (which btw, you can embed FX -> Swing or Swing -> FX)
3. If you end up Picking MT as your VTT and plan to stick around and want to contribute some source code, hit us up!

_________________
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
More information here: MapTool Nerps! Fork | TokenTool Nerps! Fork
Custom TokenTool (version 1.0b33): TokenTool.exe


Top
 Profile  
 
 Offline
Kobold
 
Joined: Mon Oct 02, 2017 10:21 pm
Posts: 2
 Post subject: Re: [Nerps!] MapTool Fork based on 1.4.1.7
PostPosted: Wed Oct 04, 2017 1:03 am 
Thanks for the warm welcome. I'm starting to feel that this will be a great place to stay :)

I can't promise help yet, but maybe in the future? We're in the middle of a very active campaign, and I work full time plus I'm GM :lol:

Jamztheman, yes, I did check out the demo the first time I saw it mentioned here. It's very pretty and fast, as expected of libgdx. Did you use box2d and box2d lights?

It's great that there are more solutions to embed libgdx now. It was not so great before.

Back when in my old job, we were looking at libgdx. We wanted both a solid UI builder and OpenGL at the same time and it looked like libgdx and Swing were the ones for us. But we couldn't get the two to work at everything we wanted out of the box. Simple things worked okay, but anything more complex either did not draw or killed performance. In the end, we had to drop both it and Java and use Unity instead

When I followed the instructions for the demo, I did see FPS drop after 50+ objects. This is on a libgdx canvas and window, yes? No Swing? I think the difficulty will start when you embed. If I remember what we experienced before, either some limit needed to be placed on the frame rate or Swing limited things itself. FPS will drop for sure, at least that's what happened in our trials. And for us, it dropped by HALF, even with nothing drawn yet. Remembering this, I felt I had to bring the experience we had before for you all to think about. I suggest that you should at least try testing embedding now while it's early so you know the issues right away.

I hope there's improvement since then. A production-ready component for embedding will solve many problems indeed. Best of luck with that :)

But I think what is important is that there is someone who is willing to do the hard work on this. I see a lot of work to be done, to be honest :lol: and without effort, nothing will get solved. So, thank you for tackling this! :D


Top
 Profile  
 
Display posts from previous:  Sort by  
Reply to topic  [ 191 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13  Next

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:

Who is online

In total there is 1 user online :: 0 registered, 0 hidden and 1 guest (based on users active over the past 5 minutes)
Most users ever online was 243 on Sun Nov 04, 2012 6:14 am

Users browsing this forum: No registered users and 1 guest





Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

Style based on Andreas08 by Andreas Viklund

Style by Elizabeth Shulman