Redesign for autosaving campaigns (WIP)

Developer discussion regarding MapTool 1.4

Moderators: dorpond, trevor, Azhrei

Forum rules
Posting now open to all registered forum users.
User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Redesign for autosaving campaigns (WIP)

Post by Azhrei »

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.

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: Redesign for autosaving campaigns (WIP)

Post by Full Bleed »

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. ;)
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.
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."

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

Re: Redesign for autosaving campaigns (WIP)

Post by Azhrei »

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."

taustinoc
Dragon
Posts: 516
Joined: Mon Aug 03, 2015 6:30 pm

Re: Redesign for autosaving campaigns (WIP)

Post by taustinoc »

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.

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: Redesign for autosaving campaigns (WIP)

Post by Full Bleed »

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: Select all

[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."


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

Re: Redesign for autosaving campaigns (WIP)

Post by Azhrei »

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...

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

Re: Redesign for autosaving campaigns (WIP)

Post by Azhrei »

Full Bleed wrote:FYI, this doesn't have to be a problem.

Code: Select all

[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 6:17 pm, edited 1 time in total.
Reason: removed a double-negative :)

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: Redesign for autosaving campaigns (WIP)

Post by Full Bleed »

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.
(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."

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

Re: Redesign for autosaving campaigns (WIP)

Post by Azhrei »

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.)

Post Reply

Return to “MapTool 1.4”