Inquiry: Autosave

Replies to This Discussion

Permalink Reply by taz on October 6, 2009 at 6:52pm

My $0.02...

Every X minutes would seem to be the most flexible as long as the user can specify the frequency and also choose to disable autosave.

Without undo, autosave might be troublesome in cases where major updates get made and the user would prefer to save a separate progress file (but forgets to do so in the beginning...). Then there's no going back.

-taz

Permalink Reply by David Rutten on October 6, 2009 at 7:09pm

Hi Taz,

The autosave feature is not supposed to be a backup feature. It is purely there so when the darn thing crashes you still have a fairly recent file. I can see that it might be annoying while undo is not available, but the proper solution to that would be to finally include undo (undo data will be saved in the file, so it would also be available in autosaved files).

Eventually I may have to expose specific autosave triggers (just like Rhino has specific commands that cause autosave to happen before they run).

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Dusan Bosnjak on October 6, 2009 at 7:14pm

How about saving into multiple files, like 3d studio max does? You specify an amount of save files, and it starts overwriting in loops.

Permalink Reply by taz on October 6, 2009 at 7:32pm

Understood. The undo feature costs extra so consider my $0.02 a down payment.

Could autosave instead (for now) create a separate crash file as Rhino does? I don't know what the relationship is between emergency save and autosave but I'm assuming there must be one...

Whatever it's called it would be my preference to have the option to not overwrite the original file. Towards the end of working on a definition (when I'm trying to make it look pretty...) accidentally aligning the components into a big clump (or some other such disaster) and then having autosave overwrite the file would be as bad as a crash.

Permalink Reply by taz on October 6, 2009 at 7:54pm

Or just add a flashing pop-up banner that says, "Save now, save often."

Permalink Reply by David Rutten on October 6, 2009 at 8:23pm

Don't worry, the scheme is as follows:

1. Autosave kicks in
2. If the current file has never been saved, autosave aborts
3. If there already is an autosave file next to the actual file, it gets renamed into a *.ghbak extension
4. The document is saved into an autosave file (same name but with "[autosave]" appended) next to the original file.
5. If autosave completes successfully, the old autosave (the one that got renamed in step 3) file is deleted.

When the document is unloaded from Grasshopper (either because you do so manually or because Grasshopper shuts down successfully), all autosave files are removed.

So, in short, while Grasshopper is running, you'll see a YourFile[autosave].ghx in Windows Explorer, but these files only remain on disk if Grasshopper (or Rhino) crashes.


I cannot participate during Emergency save as a plug-in. By the time emergency save kicks in we're already up sh*t creek without a paddle and we treat all plug-ins as suspicious. The only priority during emergency save is to secure the 3dm data, period. There might be a way around this somehow though, I'll ask around.

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by taz on October 7, 2009 at 7:51am

Cool beans...

Apologies for the sidebar since Step 1 is really the only thing you were asking for input on.

Just doing my due diligence (and being nosy).

-taz

Permalink Reply by Claudio on October 6, 2009 at 8:26pm

I'll say that an simple auto save et any X minutes is the way to go as long as you can tell GH where to save the file. Almost every software out there has an autosave feature. About the backup idea, what I do is I save incrementally all my definitions so I can keep a track on big modifications..very simple

thanks....

Permalink Reply by Damien Alomar on October 6, 2009 at 8:17pm

It may just be me, but since the ghx files are so light (at their biggest just a few megs) I wouldn't necessarily be opposed to the addition of a new component.

Permalink Reply by David Rutten on October 7, 2009 at 12:05am

Hi Damien,

I'm saving the autosave files as *.gh formats regardless of the flavour of the original file. So they are actually even smaller than usual.

I can definitely autosave on Component addition, perhaps I'll just have to expose a bunch of possible event triggers and we can see which ones are the most popular...

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Damien Alomar on October 7, 2009 at 8:01am

Even more true...I just save the largest GH file I had (3.6mgs as ghx) down to the binary format, and it got very small (630kb).

I guess, since its so light, having a bunch of triggers (which are all enabled by default) that save the file would be good. The effort to save these things will be practically nothing (fractions of a second with a 1 Gbit/s transfer rate), so I'm almost defining what wouldn't trigger an autosave rather than what would...here's my list of events that wouldn't trigger an autosave - moving components, adjusting sliders, adjusting graph points, changes to a panel component, baking geometry. So that would leave things like disconnecting/connecting wires, changes in equations for input nodes, changing the structure of an input (for the Fx(n) or scripting component), code changes from a scripting component as events that would trigger ones.