RPTools.net

Discussion and Support

Skip to content

It is currently Tue Oct 17, 2017 8:21 am 




Forum rules


Posting now open to all registered forum users.



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

Previous topic | Next topic 

  Print view

Author Message
 Offline
Giant
 
Joined: Mon Aug 03, 2015 5:30 pm
Posts: 202
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Mon Sep 11, 2017 11:11 pm 
Full Bleed wrote:
taustinoc wrote:
Full Bleed wrote:
How is an imperfect expiration system somehow *worse* than no backup redundancy at all?


That depends on how much hard drive space you have (granted, most people have a lot, but not everybody), and whether or not you have the expertise to figure out why you've run out (and most people do not have that).

Kind of a soft concern. There are so many ways to address this... and most wouldn't even be that hard.


Absolutely. But it does have to be considered from as many angles as possible.

Full Bleed wrote:
But no reason to spend any more time on it... it looks like the "redesign" is going to just be a fix. Which, as mentioned, is fine by me. I think it's an important fix and am glad someone (Az!) has taken the time to do it.


I really do think an auto-save system should be a separate system from crash recovery, and of the two, crash recovery is the more important (and it's already mostly done).


Top
 Profile  
 
 Offline
Kobold
 
Joined: Tue Apr 29, 2014 1:13 pm
Posts: 10
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Tue Sep 12, 2017 9:57 pm 
I can happily get by with a batch file to watch a directory and clone the files in it when they change.
But then I'm used to stuff like that. Your average user isn't.

Doing it in a few stages makes sense.
Make it actually work.
Make it respect campaign names.
Those are the two big ones.
After that, fluffier stuff like multiple copies, deleting old copies when a storage threshold is reached, and similar options can be lower priority.


Top
 Profile  
 
 Offline
Giant
 
Joined: Mon Aug 03, 2015 5:30 pm
Posts: 202
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Tue Sep 12, 2017 10:46 pm 
Elkad wrote:
After that, fluffier stuff like multiple copies, deleting old copies when a storage threshold is reached, and similar options can be lower priority.


I disagree. Those are fundamental requirements for it to be functional, because those are the things that will cause serious problems that the average user has no chance of figuring out on their own.

For an auto-backup system, all the features have to be working at rollout.


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 12:26 am 
Elkad wrote:
Doing it in a few stages makes sense.
Make it actually work.
Make it respect campaign names.
Those are the two big ones.

Yes, the crash recovery process will do those things in the next release.

Quote:
After that, fluffier stuff like multiple copies, deleting old copies when a storage threshold is reached, and similar options can be lower priority.

Yeah, we'll come back to autosave/autobackup/autowhatever after the next release. In the meantime, we can be thinking some more about how it should work in all of the different situations. :)


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Fri Mar 20, 2009 4:40 am
Posts: 9410
Location: Netherlands
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Wed Sep 13, 2017 1:06 am 
concerning the two instances. Good that only 'server' saves. There is however still a potential issue: during development its not unheard of two have two instances running of mt on one client (NOT connected) so they will both autosave over the other instance. Granted its more obscure, but I for one, when working on my FW I rather often also make changes to the BoT at the same time.

_________________
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
Demigod
 
Joined: Sun Feb 25, 2007 11:53 am
Posts: 3726
Location: MD
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Wed Sep 13, 2017 2:02 am 
wolph42 wrote:
There is however still a potential issue: during development its not unheard of two have two instances running of mt on one client (NOT connected) so they will both autosave over the other instance. Granted its more obscure, but I for one, when working on my FW I rather often also make changes to the BoT at the same time.

I mentioned this earlier:

Full Bleed wrote:
As for concurrency issues between two MT instances, with the same file name open... I guess you could create a "file open flag" in the autosave directory... and if the second instance sees it, have it disable autosave (and make note of it on the status bar.)

_________________
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: 9410
Location: Netherlands
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Wed Sep 13, 2017 2:18 am 
Full Bleed wrote:
As for concurrency issues between two MT instances, with the same file name open... I guess you could create a "file open flag" in the autosave directory... and if the second instance sees it, have it disable autosave (and make note of it on the status bar.)


ah sry, was a bit behind on reading so must have overlooked that.

Note that your suggestion won't work, cause that particular 'flag' file will remain there forever after MT crashes...defeating the entire purpose.

As far as I can see, the only way to circumvent this issue is when one instance of MT can directly (so no 'flag files') detect the presence of another instance running and then act accordingly, e.g. [the usual autosave name]_2.cmpgn

_________________
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
Deity
 
Joined: Tue Nov 10, 2009 6:11 pm
Posts: 7882
Location: Bay Area
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Wed Sep 13, 2017 3:13 am 
My thought is only 1 instance will be a server, so no need to save non server crashes.

_________________
Downloads:


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Fri Mar 20, 2009 4:40 am
Posts: 9410
Location: Netherlands
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Wed Sep 13, 2017 3:15 am 
aliasmask wrote:
My thought is only 1 instance will be a server, so no need to save non server crashes.


...and if you have two instances running (not connected) how do you decide which one will be 'running the server' ?? Cause the point I'm trying to make is that I often have both BoT and FW campaign open and developing both the same time. If one of the two crashes, what will be the autosave when I start MT again?

_________________
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
Demigod
 
Joined: Sun Feb 25, 2007 11:53 am
Posts: 3726
Location: MD
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Wed Sep 13, 2017 4:26 am 
wolph42 wrote:
Note that your suggestion won't work, cause that particular 'flag' file will remain there forever after MT crashes...defeating the entire purpose.

I think there is some logic that can work around that... but it was originally part of some other logic that won't be in there.


However, I think that there is a simpler method when you've only got ONE autosave file called "AutoSave.cmpgn" (which is what I think we're getting.)

When an AutoSave is written have it record the Date Modified. When it attempts to create another AutoSave have it looks at the Date Modified. If it matches the date it recorded last time it can AutoSave. Otherwise it skips the AutoSave knowing that something else created the save. This can be noted int he Status bar.

The first AutoSave won't have a Date Modified field to look at. But if there is already an AutoSave it knows it didn't create it. So it skips the AutoSave.

_________________
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: 9410
Location: Netherlands
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Wed Sep 13, 2017 10:35 am 
Full Bleed wrote:
When an AutoSave is written have it record the Date Modified. When it attempts to create another AutoSave have it looks at the Date Modified. If it matches the date it recorded last time it can AutoSave. Otherwise it skips the AutoSave knowing that something else created the save. This can be noted int he Status bar.

The first AutoSave won't have a Date Modified field to look at. But if there is already an AutoSave it knows it didn't create it. So it skips the AutoSave.


I think that there are some pitfall in that method, but apart from that: it would mean only one instance of MT will be 'autosaved' the other not, again not the most preferable outcome.

_________________
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: Wed Sep 13, 2017 11:06 am 
The crash recovery process will handle having two unrelated MT server instances running. It won't use timestamps.

Each program that is running, whether on Windows or Unix, will have a unique ID number assigned to it. On Windows it's called the task ID and on Unix it's called the process ID.

This unique ID number can be part of the filename, thus ensuring that both instances can create recovery files without any conflicts.

When MT closes down cleanly, it'll delete it's recovery file.

When MT crashes, the recovery file will still be. So at startup, if there are any recovery files, the user gets a popup dialog that shows what the names are and will be asked if any of them should be loaded. (There could be more than one, because multiple instances of MT could all crash simultaneously.) Any recovery file that is loaded is renamed to use the ID of the new MT instance that just loaded the file.


Top
 Profile  
 
User avatar  Offline
Deity
 
Joined: Fri Mar 20, 2009 4:40 am
Posts: 9410
Location: Netherlands
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Wed Sep 13, 2017 12:27 pm 
sounds good! What happens when you want to save both autosaves? Or better put: what does a user need to do to save both? (assuming that after choosing one, the directory will be cleaned up. ).
This also thus means that if you start a second instance (after a while) you will get a 'previous crash report' (same as it is now) as an active MT autosave is detected (of the first running instance). I guess that autoave will be deleted when you start the 2nd instance, but any saves after that will remain. Am I correct in that?

_________________
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  
 
 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 1:24 pm 
What happens if there's an instance of MT running, with a recovery autosave, and a second instance sees that, asks if you want to recover it, and you say yes? Does the second instance rename it to match it's (the second instance) unique ID number? What, then, does the first instance do?

And what happens if that second instance tries to recover the file while the first instance is writing to it?

Is there a way for MT to detect if other instances are running and recover their unique ID number so that it knows an existing file isn't from a crash?


Top
 Profile  
 
User avatar  Offline
Demigod
 
Joined: Sun Feb 25, 2007 11:53 am
Posts: 3726
Location: MD
 Post subject: Re: Redesign for autosaving campaigns (WIP)
PostPosted: Wed Sep 13, 2017 3:07 pm 
wolph42 wrote:
Full Bleed wrote:
When an AutoSave is written have it record the Date Modified. When it attempts to create another AutoSave have it looks at the Date Modified. If it matches the date it recorded last time it can AutoSave. Otherwise it skips the AutoSave knowing that something else created the save. This can be noted int he Status bar.

The first AutoSave won't have a Date Modified field to look at. But if there is already an AutoSave it knows it didn't create it. So it skips the AutoSave.


I think that there are some pitfall in that method

Not sure what they are.

Quote:
but apart from that: it would mean only one instance of MT will be 'autosaved' the other not, again not the most preferable outcome.

Yes, it means that there would be only 1 autosave (like we have now). But that's what it seemed like we were getting because all methods to create multiple autosaves was taken off the table.

I think the date modified method should work to create 1 autosave tagged to the first instance of MT running.

*If* we used campaign file names in the autosave file, the main issues would be the corner cases of:

A) Changing the file name during play or development.
Solution: A static backup/recovery/autosave name per campaign file that doesn't change with a changing file name.

B) Running two instances of the same file name.
Solution: I'd suggest a user create a separate data directory to manage their separate instances of the SAME file. Using the Date-Modified method, the user would be notified (via the Status Bar) that their second instance wasn't autosaving and could take steps to create a second data directory to rectify the issue.

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Reply to topic  [ 55 posts ]  Go to page Previous  1, 2, 3, 4  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 are 0 users online :: 0 registered, 0 hidden and 0 guests (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 0 guests





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

Style based on Andreas08 by Andreas Viklund

Style by Elizabeth Shulman