Re: [Stepmania-devs] Re: Detail: RageFile

[Xaroth 8. <xar...@bo...>]

I'll just chime in with my $0.02 US.

It seems to me that by adding this extra step, you'll just be breaking the
thing you were trying to fix in the first place, namely compatibility with
the XBox FS.  For those editing on the XBox, they'll open up a file with a
long name, make changes to it, and then find themselves unable to save it
correctly if it doesn't default to going back where it came from.

To think of a "stepmania file" conceptually as a SMZIP isn't that much of
a leap, really.  If I edit the steps in a "stepmania file", the details of
the lower level bits (that it's a text file compressed in a smzip) should
probably be abstracted away.  If I change "mysong.smzip", I shouldn't have
to go looking for random files being changed in random places--the only
file that, to me the user, should appear to have changed is
"mysong.smzip".

In the event of a read-only file, it should probably spit up an error
saying "cannot write to myfile.smzip", and then offer an alternative place
to save myfile.smzip, rather than breaking it down into its component
pieces across varied mounts.  Sure, if they don't get it they can
read the docs, faqs, forums, email lists, and source to try and puzzle out
what could've possibly happened to their file, OR the program could handle
it in a way that no such confusion is possible.

Saving a backup copy of the smzip also eliminates the need for a rollback
system as described - just rename it to mysong.smzip.old,
mysong.smzip.001, etc., and *poof*: an intuitive rollback system that
behaves more-or-less like the current rollback system.

Adding extra icons to indicate things like "your file is about to be saved
somewhere you didn't expect" will just cause users to say "what does that
little icon mean?" rather than "Oh, my file is now in location x:/y/z."

--Geoff Benson

On 23 Dec 2003, Matt Denham wrote:

> On Tue, 2003-12-23 at 15:09, Aaron Christopher Vonderhaar wrote:
> > Chris Danford writes: 
> > 
> > > I'd prefer just showing an error: "Song is read-only.  You may only save
> > > changes to a memory card.". 
> > > 
> > 
> > I'm not sure exactly what you mean by "memory card", but I find it useful to 
> > save to the next best mount -- especially in linux, especially when I want 
> > to mount songs from a CD. 
> 
> "memory card" - you know, those little rectangular things you plug into
> a Playstation to save data onto? :-) (A similar mechanism was
> implemented recently into Stepmania - heh.)
> 
> > 
> > > This conflict resolution works well for Quake-style patching, but it's
> > > very unintuitive for the typical person who wants to edit a song.  If a
> > > song was loaded from an SMZip, the user is going to expect that saving
> > > changes to that song will update the SMZip.  This will result in: 
> > > 
> > > "I saved changes to my song, but when I sent the SMZip to a friend, my
> > > changes were erased.  Help!" 
> > > 
> > 
> > What about a warning when you start editing that song, saying that because 
> > this song is read-only, any changes you make will be written elsewhere, see 
> > README for more info, or a clear message when the song is saved "changes 
> > saved to Stepmania/Songs/..." 
> 
> The best method is to integrate the "Export To Package" function
> directly into Stepmania rather than (or in addition to - it doesn't
> matter that much) leaving it in SMPackage.  This way, we have a clear
> sign that the data is not normally being saved to the SMZip (and we can
> explain *why* we're doing this elsewhere), but we also have a simple
> mechanism for making the SMZip have the same data as the song
> directory.  (If we ever implement Paint Mode, as in 3rdCS, this becomes
> an even more useful way of doing things - but that's besides the point
> of this discussion right now.)
> 
> > 
> > > Also, imagine that someone accidentally saves bad changes to their song
> > > file.  The most intuitive action here is to delete the SMZip file that
> > > contains the song.  The user will do that, then re-download the SMZip
> > > (which, of course, is identical to the one they just deleted), then find
> > > that the song still has goofed up data. 
> > > 
> > 
> > Have some icon that appears when a song has changes from an alternate 
> > mountpoint, and add some command to delete local changes. 
> 
> Yeah, like the memory-card icon :-)
> 
> If we switch to a binary step format (again, beyond the scope of this
> particular discussion), we could theoretically start a "rollback to
> revision X" system - and then use the current (text) .sm format for
> storing temporary/local/edit data.  (I'm not saying this is a GOOD way
> to do things, just pointing this out for future reference.)
> 
> > 
> > 
> > > I'd prefer just showing an error: "Song is read-only.  You may only save
> > > changes to a memory card.". 
> > > 
> > > 
> > > -Chris
> 
> I'll be a little picky on the wording and say it should be "'<song
> name>' is currently read-only, and the new data will be saved to
> <path>." so that people know (1) why their data is showing up somewhere
> else; (2) where it's showing up; and (3) what they can do about it.
> 
> >  
> > 
> > Just a few alternate suggestions to consider. 
> > 
> > Thanks,
> > Aaron VonderHaar
> > (von...@ms...) 
> > 
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Stepmania-devs mailing list
> > Ste...@li...
> > https://lists.sourceforge.net/lists/listinfo/stepmania-devs
> > 
> 
> Matt Denham
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Stepmania-devs mailing list
> Ste...@li...
> https://lists.sourceforge.net/lists/listinfo/stepmania-devs
>