Iterative save... Please?

This forum is currently in read-only mode.
  • Besides I wasn't entirely serious about "creative process", hence the quote marks.

    deadeye is right on - it's just a quick function, it doesn't take anything away from those who don't use it and is great for those who do.

  • FL Studio has a save new version keyboard shortcut and menu item.

    it's a ridiculous workflow enhancement, and feels more like a permanent undo point than a save. I save new versions much more often than I take the time to click in the menu and save as and type a new name. it results in a much more fluid creative process. I don't see why anyone wouldn't want to streamline the process for such a common function.

  • Maybe not totally necessary, but then again neither are shortcut keys when you think about it. But they do help with work flow.

    Yay!

    At least Deadeye and Lucid see the point of the request.

    It's amazing how many people seem to argue against having it, even though it wouldn't affect them at all.

    The keyboard shortcuts are a perfect example.

    Krush.

  • At least Deadeye and Lucid see the point of the request.

    And you Already makes four people in favor of such an idea.

    Let's make things easier by giving an implementation example (this is how I did it in a macro for a graphics program):

    <img src="http://i244.photobucket.com/albums/gg36/some9000/DocDock.png">

    Next to the usual save icon there's a +1 icon - pretty clear right away what it does.

    Under the hood it just checks the filename for an iteration number like _XXX (if not it just starts at 1) to see if there's a free one after it (maybe you went back to a previous iteration so, say, if you went back to _005 from _008 you'd make _009 instead of overwriting _006) and just saves the file as filename_XXX. So when you first save like this it makes _001, next time _002, etc.

    Pretty simple (no need for cycling - leave the space concerns to the user), pretty handy. Convinced yet?

  • OK, so why not enable autobackup with 999 backups or something? Or I suppose you'd prefer the kind of workflow where you edit your application saving normally, and at the end before closing save a new version?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Or I suppose you'd prefer the kind of workflow where you edit your application saving normally, and at the end before closing save a new version?

    Not before closing - right in the middle of it! If you have 999 auto-backups - do you remember in which one you changed what? Not likely. But if you were working on, say, _003, saved it, then started working on something else, which was saved as _004 you'd remember that _003 had THAT THING which you deleted in _004 or _005 or whatever and really need now.

    In a way with iterative saving each previous version is like a template for your current version - a stable undo, a place of safe return. Sure, you can do it using Save As, but when it's quick and easy you do it more often, experiment more = better results.

  • OK, so why not enable autobackup with 999 backups or something? Or I suppose you'd prefer the kind of workflow where you edit your application saving normally, and at the end before closing save a new version?

    I'm not a fan of autosave/autobackup, and I usually disable it in anything I use.

    No reason why it can't be left in there for those that like it though.

    My reason for wanting iterative save would be control.

    Lucid hit upon what I mean when he said it's like a permanent undo point.

    I like to save a new version when I've made enough progress to warrant it, like fixing a certain bug, or adding a certain amount of features, so I can always go back to that point if need be.

    Krush.

  • Here's my argument for a manual iterative backup feature like the one Somebody is suggesting:

    1. It gives you more control over when and why a backup is made. Backups aren't decided by an arbitrary means (in this case, time). This means that you don't have to wait for Construct to decide it's backup time, you can just hit a key and go.

    2. It solves the problem of sifting through several .bak#.cap files to find the one you need if you want to revert to a previous version.

    I think also that the backup numbering needs an upgrade. Currently it saves as bak1, back2, etc. But when listing these by name in Windows you get this:

    bak1

    bak10

    bak11

    bak2

    bak3

    ...

    bak9

    I propose that the numbering scheme pads the number with extra 0s, such as bak001, bak002, so that they are listed in the proper order. Perhaps the number of zeros could be taken from the "Number of backups" field in the preferences.

    The shortcut key Ctrl-B currently does nothing in Construct, this could create a manual backup. Also, you should be able to create a manual backup without having to turn on the Auto-backup feature.

  • OK. I guess it would also be handy to specify a different backup folder, eg. to a thumb drive or other folder, so you don't get your working directory cluttered with backup files. However this will probably (like all other features) be postponed to post-1.0 or Construct 2 because we're really trying to focus on simply stabilising what we've got towards 1.0. It's unlikely we'll add any new features before then.

  • Fair enough

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)