Autosaving in Grasshopper 2.0

Sorry for the delay

Thanks for the info on .scripts

No I only had an old version.
Like I say Im pretty sure I kept saving the latest version but I cant be 100%. :slight_smile:

So I rely on Autosaves heavily as I am very distracted person. And with Grasshopper Im always unlucky. Ill give you a suggestion of something that can be very helpful and has saved me many times with other softwares.
It would be perfect if there is a setting on how many back up files to be automatically saved and at what interval of time. It makes it better for the user if the back up files are stored into a back up folder next to the orginial file.The current methods have never helped me lose data, as there are so many ways to lose data and this only covers you if you forget to hit the save button and close the definition.

I agree with @Dani_Abalde,
I would much prefer that they were moved to the trash than deleted. I just had the unfortunate situation that the power went out while I was saving and the file is now corrupted :frowning: no autosave.
Also, I wouldn’t mind seeing a bunch of backups of older autosaves, in the occasion I need to dig out an older version.

Yes about that, the more data you internalize, the more unusable your files become.
I produce a lot of overshadowing analysis and often I compare the impact of several options. internalizing that data creates a massive lag with any operation, even just adding a disconnected component to the canvas.
the addition in rhino7 of data input/output really saved my day. it would be great to develop these further, I have a feeling @DavidRutten won’t like this suggestion but I would love to be able to attach a value list to the data input component and switch ghdata files without having to re-browse for them.
Internalising is really great for sharing files. not much more.

Ideally GH should not make dangerous changes and should always be stable and responsive and allow us to (stop the solver) cancel a long computation without crashing? Maybe even show which component is taking longer and stop it automatically after user set time? Otherwise I prefer autosave to work in a similar fashion to Revit autosave with incremental limited copies or as a git repository managed by GH to show differences as @stevebaer mentioned. Internalised data should not be saved unless it is modified to speed up saves.

Hello David, thank you for being open to suggestions.
I would love to propose a feature that can be called “design options” in upcoming GH2.0 . It is not directly related with autosaving, but it is can be! It is more like giving the user a way to save multiple modifications based on the same script. And it is depended on the user at the end to choose which “option” to go or further being developed. It can be autosaved too! once a new option is created, all changes can be automatically documented like a GitHub branch. At the end, if you are happy to go with one branch, you can merge it into the main script.
The reason I am proposing is as we all know, there can be multiple ways in GH to achieve the same result. To test out all potentials, copying and pasting script to a newly created file is okay but not quite user-friendly, especially if you want to create a well-organized file system.
Thank you!
Ruxin

I feel like a lot of this could be solved by allowing nested files. So just like in any other software programming environment you split things into different files. Imagine if any cluster could just be another Grasshopper file. Then especially for large files you would have your main file and in there are clusters for all the major parts. Each cluster is its own Grasshopper file that can be edited separately.

THEN having a system like GIT would make sense.

You would never put all your code in one javascript file or python file or whatever once it get’s over a certain size, but in Grasshopper you basically have to have everything in one file. It’s just a bit baffling to me that we get all these things like Hops and Clusters and User Objects and everything, but not the most basic of things: take a Grasshopper file and place it in another like a cluster.

Clusters are files. They are embedded when you make a new cluster, but you can totally use an existing file elsewhere and reference it as a cluster. Or turn an embedded cluster into a referenced file…Am I confused? I feel confused.

No, you’re right. But I mean without having different file formats. Sure I can create .ghcluster files and then put them in a file, but I want to just take a normal .gh file and put it in another .gh file. So in the end I have one main file that contains many smaller parts. But each of the smaller parts I can just open as a normal Grasshopper file or someone else can open it, improve it and then it’s updated.

I feel like this concept of having all these different file formats, adds unnecessary complexity.

What is the reason clusters have to have a special format?

oh and of course it needs some smart way of executing the contents of the embedded .gh files. Clusters are a bit dumb in that sense that they have to be completely re-evaluated every time. Or at least it used to be like that. So that is I would assume the hard part of it all.

Hi Armin -

That’s what the Hops component does, isn’t it?
-wim

I see. Yes, that would be lovely, and it is something I’m planning sooner rather than later.

3 Likes

It would be sooo nice if untitled files got saved to the autosave folder as a timestamp as a special condition of autosave. I lose so many little scripts that just start to be interesting because I don’t save them (not really worth it yet), then get really into it, do a bunch of clever things, and then graft something i shouldn’t have, they freeze beyond saving for one reason or another. if it just autosaved the untitled, they’re usually small at that point, so you could save all of them and still not take up much room. just a thought.