Yeah, my point isn't that replaying the commands is currently a viable alternative for scene recovery (though I would say it's better than nothing in the cases where the auto-recovery fails). Just that it could be a really good solution, if some more effort were put into ensuring every interaction got logged as a command of some kind. And since a lot of people rely on command logging as a way to build scripts, they'd be killing two birds with one stone. The plugin is just a proof of concept.
A journaling approach just seems like a better way to deal with file recovery than a weird last-second binary dump, especially given that the dump often contains the thing causing the crash in the first place and has no way to handle things like power outages, auto-logouts, etc. There's no reason 3D software can't be as robust with file recovery as Nuke is. Even if there are commands that can't be logged for some reason, you could have a special dirty state that triggers a normal auto-save in those instances to ensure that the journal-based recovery can still work properly. On Fri, Sep 6, 2013 at 8:58 PM, Matt Lind <ml...@carbinestudios.com> wrote: > My only beef with your plugin is it cannot account for commands which do not > log. There’s a good probability the scene your plugin generates is not an > accurate representation of what last state of the scene actually was before > it crashed. Animation edits, for example, do not log at all. Custom tools > flagged to not log, or tools called from self installing commands do not log > either. > > > > Back in good ol’ days of XSI v6.x when we were treading water to get > anything to function in XSI without exploding, I desperately tried to > salvage crashed scenes using a similar technique, but because many commands > were not logged it was not possible to salvage work or even rebuild it > enough to send to Softimage to diagnose the cause of the crash to get it > fixed. Critical missing steps caused the rebuild script to error out, or if > it was lucky enough to get to the end without error, the end result was not > at all like what it should’ve been. > > > > > > Matt > > > > > > > > From: softimage-boun...@listproc.autodesk.com > [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Andy Jones > Sent: Friday, September 06, 2013 8:44 PM > To: softimage@listproc.autodesk.com > Subject: Re: Would you like to recover your scene? > > > > I've said this before, but the script log comes really really close to > implementing "journalling" which is the thing that made filesystems more > robust in the 2000's. the binary dump emergency save thing is really kind > of a silly way to attack the problem of replaying a journal of operations. > If Autodesk realized this, they'd prioritize the completeness of command > logging and build a simple toolset for replaying the unsaved operation > journal. > > > > I sent my "repeatHistory" plugin to the beta list a while ago and got > crickets. Maybe I'll try again... > > > > All it does is parse the script log for the last open or save operation and > them exec the remainder. It would work even better with an event that sets > the script log path on scene open/save. > > > On Friday, September 6, 2013, Jeremie Passerin wrote: > > Got issue with the auto-recover lately, but the scene was actualy properly > saved before crashing. just needed to load it manually. > > http://xsisupport.com/2011/10/15/crash-recovery-in-softimage/ > > > > On 6 September 2013 13:18, Eric Thivierge <ethivie...@hybride.com> wrote: > > You're doing it wrong... > > > > On September-06-13 4:15:36 PM, Eric Lampi wrote: > > SoftImage: "Hey Eric, I see that you crashed.. How would you like to > recover your scene?" > > Eric: "Sure that would be great! Go right ahead, bring it on back!" > > SoftImage "You'll get nothing and like it!" > > Meh > > Eric > > Freelance 3D and VFX animator > > http://vimeopro.com/user7979713/3d-work > > > >
