RPTools.net

Discussion and Support

Skip to content

It is currently Wed Oct 18, 2017 6:44 pm 




Forum rules


Posting now open to all registered forum users.



Reply to topic  [ 55 posts ]  Go to page Previous  1, 2, 3, 4

Previous topic | Next topic 

  Print view

Author Message
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12101
Location: Tampa, FL
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Wed Sep 13, 2017 6:31 pm 
If you start MT and there's a crash recovery file (I'm not calling them autosaves anymore, since we'll tackle that separately!), you get the option of loading it.

If you say "Yes", it gets renamed to be the ID of the current MT.

If you say "No", they don't get recovered. Which means you'll get the prompt again next time; the files won't be removed or renamed. If you don't want the recovery file anymore, it's up to you to remove it.

Most operating systems, and I believe this includes Windows but I'll need to check, provide a way to check whether a program with the given ID is running. MT can check for that. That's how it will know that a recovery file belongs to an instance that is still running. Obviously, recovery files that belong to running instances will not trigger the recovery mechanism.


Top
 Profile  
 
User avatar  Offline
Demigod
 
Joined: Sun Feb 25, 2007 11:53 am
Posts: 3728
Location: MD
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Wed Sep 13, 2017 7:25 pm 
Azhrei wrote:
If you start MT and there's a crash recovery file (I'm not calling them autosaves anymore, since we'll tackle that separately!)

Whew! It was getting complicated trying to make sure people were talking about the same thing. ;)

Quote:
you get the option of loading it.

If you say "Yes", it gets renamed to be the ID of the current MT.

If you say "No", they don't get recovered. Which means you'll get the prompt again next time; the files won't be removed or renamed. If you don't want the recovery file anymore, it's up to you to remove it.

That sounds pretty good.

Quote:
Most operating systems, and I believe this includes Windows but I'll need to check, provide a way to check whether a program with the given ID is running. MT can check for that. That's how it will know that a recovery file belongs to an instance that is still running. Obviously, recovery files that belong to running instances will not trigger the recovery mechanism.

This would make this *much* more intuitive from the user's perspective (i.e. not getting polled unnecessarily to open a recovery file from the first instance when you open a second instance.)

_________________
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: 12101
Location: Tampa, FL
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Wed Sep 13, 2017 7:42 pm 
Well, it appears that there may not be a portable way to obtain these ID numbers.

Java 9 will include the java.lang.ProcessHandle interface and that will be able to provide the proper information, but prior to Java 9 the approach is to run a command line utility and scrape the output. Ugh.

We might be able to use this approach, but the docs indicate the number embedded inside it can't be relied upon to be a process/task ID.

It looks like the only 100% safe way to do this would be to cross-reference that returned string to a recovery filename by using an auxiliary filename or a Preferences entry. Double-ugh. This is getting to be a pain. I'll keep looking for a simpler solution...

"Nothing's ever easy."


Top
 Profile  
 
 Offline
Giant
 
Joined: Mon Aug 03, 2015 5:30 pm
Posts: 202
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Wed Sep 13, 2017 8:19 pm 
Maybe including in the recovery file a port number that MT will respond to (even if it's not running a server, obviously), but only locally, with its ID number? (Or just hard code a port for that specific purpose.) If there's a recovery file, ping that port, and compare the ID number. If it's different, it's a crash recovery file, if it's the same, it's not.


Top
 Profile  
 
User avatar  Offline
Demigod
 
Joined: Sun Feb 25, 2007 11:53 am
Posts: 3728
Location: MD
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Thu Sep 14, 2017 12:57 am 
Azhrei wrote:
Consider what happens if I have a large campaign, then use "Save As..." to give it a new name. A lot more autosaves are created and the whole pruning problem comes back.

FYI, this doesn't have to be a problem.

Code:
[r: json.get(getInfo("campaign"), "id")]

_________________
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
Deity
 
Joined: Fri Mar 20, 2009 4:40 am
Posts: 9411
Location: Netherlands
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Thu Sep 14, 2017 2:14 am 
sounds good. I would extend 'do you want to recover yes/no' to 'do you want to recover yes/no/delete recovery file(s)'.

_________________
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC

My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent and
DPI.
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


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12101
Location: Tampa, FL
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Thu Sep 14, 2017 11:05 am 
wolph42 wrote:
sounds good. I would extend 'do you want to recover yes/no' to 'do you want to recover yes/no/delete recovery file(s)'.

Yes, I thought about that. When I get the new popup built, I'll look at this option. I don't want it to be something that a user would click without thinking about it, and if there are multiple recovery files they may not completely realize what's happening...


Top
 Profile  
 
User avatar  Offline
Site Admin
 
Joined: Mon Jun 12, 2006 12:20 pm
Posts: 12101
Location: Tampa, FL
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Thu Sep 14, 2017 11:11 am 
Full Bleed wrote:
FYI, this doesn't have to be a problem.

Code:
[r: json.get(getInfo("campaign"), "id")]

The ID of the campaign object doesn't need to be unique except within the loaded server instance. In other words, this won't work as a unique ID for external resources.

Nice try, though. ;)

(In fact, it appears that these GUIDs change when campaigns are loaded while a server is running. We're looking into that now, as we believe it's a bug. It might've been a 'feature" in the early days, but now...)


Last edited by Azhrei on Thu Sep 14, 2017 5:17 pm, edited 1 time in total.
removed a double-negative :)


Top
 Profile  
 
User avatar  Offline
Demigod
 
Joined: Sun Feb 25, 2007 11:53 am
Posts: 3728
Location: MD
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Thu Sep 14, 2017 3:52 pm 
Azhrei wrote:
The ID of the campaign object doesn't not need to be unique except within the loaded server instance. In other words, this won't work as a unique ID for external resources.

I'm not following.

I was responding to the fact that when we were talking about attaching a campaign name to the crashing recovery file name (and having multiple backups) that you eliminated putting the name of the campaign into the name of the save because the name could change and then (potentially) multiple new saves would be produced eating up space. If the Campaign ID doesn't change (which it appears it does, see below) then *that* would no longer be a concern.

Later I suggested creating a static backup/crash recovery name/id to combat this... but the discussion had moved back to the old method at that point.

That is, it was something that was taken off the table for a reason that doesn't exist because nothing would have had to be done to use a unique, campaign specific, ID that won't be affected by the actual name of the campaign.

The point being that it appeared to be one of the reasons that backed you into the old system and now we're seeing that it's not a no-brainer being back there.

Quote:
(In fact, it appears that these GUIDs change when campaigns are loaded while a server is running. We're looking into that now, as we believe it's a bug. It might've been a 'feature" in the early days, but now...)

I knew this happens with tokens... and I did a quick check of a couple recent campaign saves and didn't see a change... but then I went back and checked it against some older ones and you're right. The ID does change. But, how hard will it be to fix that versus some of the things being discussed to make the old crash recovery/autosave method work with multiple instances of MT? Or to even create a new static field in the same location?

_________________
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: 12101
Location: Tampa, FL
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Thu Sep 14, 2017 5:16 pm 
Full Bleed wrote:
But, how hard will it be to fix that [...]

That's why I said "we're looking into that now"; we don't know how hard it will be.

The fix itself is very easy. It's possible that making the change might break something somewhere else, though. So we plan to implement the fix, try it out for a while (I think Jamz may already be doing that), and if no problems surface we'll make the change in a public build. But I wanted to make sure the disclaimer was in there that "this might work, it might not".

However...

Even if the campaign IDs don't get reset when a campaign is loaded while a server is running, it's still not guaranteed unique. Those numbers are based on a PRNG (pseudo-random number generator) and while the latest PRNG in Java is pretty good, is it possible that two numbers could be the same? Yes.

That makes it infeasible to use for external resources. (Seems like I said this already.)

Those unique ID numbers (GUID is the term we use), is only unique within a campaign, not outside of it. So within a campaign, no two GUIDs will ever be the same. But those GUIDs are not guaranteed to be unique throughout the universe. Murphy's Law says that if you assume they are "close enough", it'll come back to bite you. :D

So... The operating system will have a unique identifier that it guarantees will be unique at any given instant. That means the ID numbers I referred to can be reused by programs running on the system over time. But that's not a problem for us -- if my MT gets ID number 56 and crashes, and then another MT comes along and gets ID number 56, the new one will know that any recovery file with "56" in its name must be a crash recovery file because the new MT instance has just started up and hasn't created one of its own yet. (As an aside, it would have to rename that file or it's own crash recovery files would overwrite it. That will be factored in the recovery process.)


Top
 Profile  
 
Display posts from previous:  Sort by  
Reply to topic  [ 55 posts ]  Go to page Previous  1, 2, 3, 4

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