I already posted a topic on this subject already, but this one is not to complain. This is suggesting ways to make it less painful.

1. Ability to turn it off.
And there is that topic. Please return here when you're done.
Honestly, some of us would rather not have it, and if it's on by default, new Scratchers still wouldn't lose work. It just needs to remember to stay off if you turn it off.

2. Give it a little logic.
How about, instead of making it wait x minutes and then autosave, make it wait x minutes from the last change. Saving the project would count as a change as well. That way, autosave does it a little smarter. I hate it when I spend a while editing a costume and it does a belly flop trying to autosave WHILE I'm still laying down graphics.
Suggested by another Scratcher: Ability to toggle what “x” is.

3. Instead of saving right before you leave, ask to save, like in 1.4.
The title almost has it all. In 1.4, it asked you if you wanted to save before leaving. That way, you won't forget and lose progress, and you also don't have stray tests that you have to chase down.
Another problem I've found is it doesn't want to let you leave until it's saved, and sometimes the saving lags. Quite annoying.
And I personally don't mind that one extra click at all.

One thing, some people don't support because there is a painstaking workaround. As I posted earlier,

Failord wrote:

AUTOSAVE IS NOT A SCRIPT BLOCK!

My point here is, it's not about overcomplicating the script block area(or, rather, oversimplifying), it's about making Autosave more convenient for everybody.

Are these good ideas, ST? Please let me know, and please add support or good reasons against it, regardless of ST status.

SUPPORT

Yeah I don't like auto save because sometimes I accidentally move a part of a script somewhere but don't know where to place it. I leave the game immediately to avoid auto save, but it beats me

Support!

they should turn off the autosave when you are changing tyour project description too - accidently deleted all content and it auto saved…

See all this support, ST? It might just be my bulging, overinflated ego, but I might actually be on to something.

Failord wrote:

See all this support, ST? It might just be my bulging, overinflated ego, but I might actually be on to something.

There's a workaround… No support.

ProdigyZeta7 wrote:

Failord wrote:

See all this support, ST? It might just be my bulging, overinflated ego, but I might actually be on to something.

There's a workaround… No support.

I don't mind your opinions but the problem with the workaround is it is very very very long! An option for turning off autosave would be 9000% faster!

KrIsMa wrote:

ProdigyZeta7 wrote:

Failord wrote:

See all this support, ST? It might just be my bulging, overinflated ego, but I might actually be on to something.

There's a workaround… No support.

I don't mind your opinions but the problem with the workaround is it is very very very long! An option for turning off autosave would be 9000% faster!

Well, let's see about that…
Logging off = 5 seconds
Going to profile = 10 seconds
Going to project = 10 seconds
Opening editor = 7 seconds
Changing project = excluded
Downloading = 3 seconds
Exiting editor = 5 seconds
Logging in = 15 seconds
Going back to profile = 5 seconds
Going back to project = 10 seconds
Opening editor = 7 seconds
Uploading new version of project = 3 seconds
Waiting for it to save = 10 seconds
Total time = ~1:30

Time to switch autosave on/off = 1 second

1:30 = 90 seconds
90/1 = 90 * 100% =
9000%
ಠ_ಠ

ProdigyZeta7 wrote:

Well, let's see about that…
Logging off = 5 seconds
Going to profile = 10 seconds
Going to project = 10 seconds
Opening editor = 7 seconds
Changing project = excluded
Downloading = 3 seconds
Exiting editor = 5 seconds
Logging in = 15 seconds
Going back to profile = 5 seconds
Going back to project = 10 seconds
Opening editor = 7 seconds
Uploading new version of project = 3 seconds
Waiting for it to save = 10 seconds
Total time = ~1:30

Time to switch autosave on/off = 1 second

1:30 = 90 seconds
90/1 = 90 * 100% =
9000%
ಠ_ಠ

Did you say something about no support? BURN THE WITCH!

just kidding.

I have no doubt there's a workaround, I've seen it before. The thing is, who wants to do all that stuff just to get around it? Only the most devoted haters of Autosave. Again, saves everyone, including the Scratch Team, a major headache to add turning it off.

Bump! Just had a realization.

Long workarounds for blocks are okay, because you can use custom blocks to simplify your scripting.

AUTOSAVE IS NOT A SCRIPT BLOCK!

So therefore, we need to make it more convenient. Right now it's a pretty big inconvenience.

Failord wrote:

2. Give it a little logic.
How about, instead of making it wait x minutes and then autosave, make it wait x minutes from the last change. Saving the project would count as a change as well. That way, autosave does it a little smarter. I hate it when I spend a while editing a costume and it does a belly flop trying to autosave WHILE I'm still laying down graphics.

How about an option to save every 2, 3, 5, etc. minutes after the last change? This would make it work for everyone.

Failord wrote:

AUTOSAVE IS NOT A SCRIPT BLOCK!

No, it isn't. Plus, some of the blocks we already have have easy workarounds. For example, the “change variable by _” is the same thing as “set variable to (variable) + _” and (_) * (_) is just “repeat (_) times || change variable by (_)”.

Support.

mitchboy wrote:

Failord wrote:

How about, instead of making it wait x minutes and then autosave, make it wait x minutes from the last change. Saving the project would count as a change as well…

How about an option to save every 2, 3, 5, etc. minutes after the last change? This would make it work for everyone.

Failord wrote:

AUTOSAVE IS NOT A SCRIPT BLOCK!

No, it isn't. Plus, some of the blocks we already have have easy workarounds. For example, the “change variable by _” is the same thing as “set variable to (variable) + _” and (_) * (_) is just “repeat (_) times || change variable by (_)”.

Support.

Thank you! Someone is finally being constructive!

And also thanks for seeing my point.

On a side point, “multiply variable by ( )” in one block is: "set variable [whatever] to ( (whatever) * ( ) ). More simple than making it repeat, in my opinion, but repeating might be easier to understand… Still, it eliminates the need for a custom block without screen refresh to make it all in one refresh…

^Wow. I'M getting off-topic. Let's talk about autosave. Silly me.

Ya'know, just now my player crashed, and if it weren't for autosave, my project would have to be redone from the beginning.

I support toggling autosave, though…

ProdigyZeta7 wrote:

Ya'know, just now my player crashed, and if it weren't for autosave, my project would have to be redone from the beginning.

I support toggling autosave, though…

That's why I'm saying it needs the ability to be turned off, but not removed completely.

Actually, I might not turn it off if they gave it logic like I'm proposing…

ProdigyZeta7 wrote:

Ya'know, just now my player crashed, and if it weren't for autosave, my project would have to be redone from the beginning.

I support toggling autosave, though…

Youch - it shouldn't do that - but yes, autosave does protect against that sort of thing.

Rather than allowing Scratchers to turn off autosave, what about giving a “version” history that they can use to revert to previous versions.

Autosave is simpler (and becoming the standard for web apps these days), especially for new users. I think it's better to have autosave - working all the time - but which allows you to cancel / revert the save anytime you want. So if you try something with your project, and then decide you no longer want to try that direction, you open up the version dialog box, something like this:

Timestamp: Notes:
04:36:16 7/5/13 Autosave
04:34:16 7/5/13 revert to this version Clicked save
04:32:16 7/5/13 revert to this version Autosave
04:30:16 7/5/13 revert to this version Opened project

Since you want to throw away the stuff you did after you first opened the project, you click revert on the 4:30:16 save. Now your project looks like it did when you first opened it that day. If you open the version list again, it looks like this.

Timestamp: Notes:
04:36:47 7/5/13 revert to this version Reverted to 04:30:16 7/5/13 save
04:36:16 7/5/13 revert to this version Autosave
04:34:16 7/5/13 revert to this version Clicked save
04:32:16 7/5/13 revert to this version Autosave
04:30:16 7/5/13 revert to this version Opened project

So if you want to revert your reversion, just click revert on the second item on the list. That brings you back to where you were before your reverted.

This is still rough and conceptual (is this the info we want to present? Should we emphasize explicit saves over autosaves with the user interface?), I can imagine a lot of ways to improve it and I bet you guys have ideas (and we'd love to hear them / see mock-ups!) But generally, I think providing the ability to revert an autosave is a better solution than turning it off.

Lightnin wrote:

Rather than allowing Scratchers to turn off autosave, what about giving a “version” history that they can use to revert to previous versions.

Autosave is simpler (and becoming the standard for web apps these days), especially for new users. I think it's better to have autosave - working all the time - but which allows you to cancel / revert the save anytime you want. So if you try something with your project, and then decide you no longer want to try that direction, you open up the version dialog box, something like this:

Timestamp: Notes:
04:36:16 7/5/13 Autosave
04:34:16 7/5/13 revert to this version Clicked save
04:32:16 7/5/13 revert to this version Autosave
04:30:16 7/5/13 revert to this version Opened project

Since you want to throw away the stuff you did after you first opened the project, you click revert on the 4:30:16 save. Now your project looks like it did when you first opened it that day. If you open the version list again, it looks like this.

Timestamp: Notes:
04:36:47 7/5/13 revert to this version Reverted to 04:30:16 7/5/13 save
04:36:16 7/5/13 revert to this version Autosave
04:34:16 7/5/13 revert to this version Clicked save
04:32:16 7/5/13 revert to this version Autosave
04:30:16 7/5/13 revert to this version Opened project

So if you want to revert your reversion, just click revert on the second item on the list. That brings you back to where you were before your reverted.

This is still rough and conceptual (is this the info we want to present? Should we emphasize explicit saves over autosaves with the user interface?), I can imagine a lot of ways to improve it and I bet you guys have ideas (and we'd love to hear them / see mock-ups!) But generally, I think providing the ability to revert an autosave is a better solution than turning it off.

Hmm… I like this idea. Although it would be a little redundant to note the revert to a previous version.
Also, would that be saved on the server or as cookies on a computer?

Lightnin wrote:

ProdigyZeta7 wrote:

Ya'know, just now my player crashed, and if it weren't for autosave, my project would have to be redone from the beginning.

I support toggling autosave, though…

Youch - it shouldn't do that - but yes, autosave does protect against that sort of thing.

Rather than allowing Scratchers to turn off autosave, what about giving a “version” history that they can use to revert to previous versions.

Autosave is simpler (and becoming the standard for web apps these days), especially for new users. I think it's better to have autosave - working all the time - but which allows you to cancel / revert the save anytime you want. So if you try something with your project, and then decide you no longer want to try that direction, you open up the version dialog box, something like this:

Timestamp: Notes:
04:36:16 7/5/13 Autosave
04:34:16 7/5/13 revert to this version Clicked save
04:32:16 7/5/13 revert to this version Autosave
04:30:16 7/5/13 revert to this version Opened project

Since you want to throw away the stuff you did after you first opened the project, you click revert on the 4:30:16 save. Now your project looks like it did when you first opened it that day. If you open the version list again, it looks like this.

Timestamp: Notes:
04:36:47 7/5/13 revert to this version Reverted to 04:30:16 7/5/13 save
04:36:16 7/5/13 revert to this version Autosave
04:34:16 7/5/13 revert to this version Clicked save
04:32:16 7/5/13 revert to this version Autosave
04:30:16 7/5/13 revert to this version Opened project

So if you want to revert your reversion, just click revert on the second item on the list. That brings you back to where you were before your reverted.

This is still rough and conceptual (is this the info we want to present? Should we emphasize explicit saves over autosaves with the user interface?), I can imagine a lot of ways to improve it and I bet you guys have ideas (and we'd love to hear them / see mock-ups!) But generally, I think providing the ability to revert an autosave is a better solution than turning it off.

Wouldn't reverting hold a lot of data in the servers? Anyways, here's what I think should happen.

Every time a new costume is made or sound imported, definately save like now. The problem is blocks, and also editing costumes. Every time you add a block or manipulate a script, it triggers autosaved. I think blocks should have a point system. Every time a block is dragged in, the points change by 2, and every time a script is manipulated, the points change by 1. Once the points reach 15, the project autosaves and the points reset to “0”. As for costume editing, instead of saving during every change, make it wait until you exit the paint editor or switch to another costume to save.

ProdigyZeta7 wrote:

Hmm… I like this idea. Although it would be a little redundant to note the revert to a previous version.
Also, would that be saved on the server or as cookies on a computer?

On the server. The Json files are actually very very small - just little tiny text files. So they don't really take up a much space. We're already saving some extra (That's how we're able to make the revert function work, and to restore projects that got blanked out.)

Lightnin wrote:

ProdigyZeta7 wrote:

Ya'know, just now my player crashed, and if it weren't for autosave, my project would have to be redone from the beginning.

I support toggling autosave, though…

Youch - it shouldn't do that - but yes, autosave does protect against that sort of thing.

That happens to me all the time when I'm doing heavy pixel art.

Lightnin wrote:

Rather than allowing Scratchers to turn off autosave, what about giving a “version” history that they can use to revert to previous versions.

Autosave is simpler (and becoming the standard for web apps these days), especially for new users. I think it's better to have autosave - working all the time - but which allows you to cancel / revert the save anytime you want. So if you try something with your project, and then decide you no longer want to try that direction, you open up the version dialog box, something like this:

Timestamp: Notes:
04:36:16 7/5/13 Autosave
04:34:16 7/5/13 revert to this version Clicked save
04:32:16 7/5/13 revert to this version Autosave
04:30:16 7/5/13 revert to this version Opened project

Since you want to throw away the stuff you did after you first opened the project, you click revert on the 4:30:16 save. Now your project looks like it did when you first opened it that day. If you open the version list again, it looks like this.

Timestamp: Notes:
04:36:47 7/5/13 revert to this version Reverted to 04:30:16 7/5/13 save
04:36:16 7/5/13 revert to this version Autosave
04:34:16 7/5/13 revert to this version Clicked save
04:32:16 7/5/13 revert to this version Autosave
04:30:16 7/5/13 revert to this version Opened project

So if you want to revert your reversion, just click revert on the second item on the list. That brings you back to where you were before your reverted.

This is still rough and conceptual (is this the info we want to present? Should we emphasize explicit saves over autosaves with the user interface?), I can imagine a lot of ways to improve it and I bet you guys have ideas (and we'd love to hear them / see mock-ups!) But generally, I think providing the ability to revert an autosave is a better solution than turning it off.

Sounds good. I don't know why you'd want to revert your reversion, though.