Hi Raph,

We all agree that ASCII file editing (like with Maya .ma) would be very
useful.

My point was just about the crash issue. Having working with the source
code of Softimage (even if I was not a persistence specialist), I can
imagine how hard it would be to debug a crash in an ASCII scene file. By
hard, I mean, from a production point of view. Of course people are free to
spend days/weeks/months trying to debug such problem :).






On Sun, Sep 8, 2013 at 8:20 PM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> There's actually a surprising number of issues that you can spot right
> away when you have an ascii file that don't involve the kind of ASCII
> search that feels like picking fleas off a wolf.
>
> Scene bloat, something Maya suffers for enormously but Soft isn't exactly
> immune to, is just one of many examples where if you have an ascii file
> finding the recurring pattern of orphaned data is easy and can bring a file
> back from the death.
>
> Mind, not that it seems this is ever going to happen for Soft anyway at
> this point.
>
>
> On Mon, Sep 9, 2013 at 9:22 AM, Guillaume Laforge <
> guillaume.laforge...@gmail.com> wrote:
>
>> I don't want to be the TD searching in this ASCII .scn file trying to
>> find out how to fix the crash.
>>
>> Just saying :)
>>
>>
>> On Sun, Sep 8, 2013 at 3:01 PM, Andy Jones <andy.jo...@gmail.com> wrote:
>>
>>> I 100% agree and am fully in favor of an ascii scene format.  Just
>>> pointing out that it alone unfortunately doesn't solve the crash
>>> recovery problem.
>>>
>>>
>>> On Sun, Sep 8, 2013 at 3:23 AM, Angus Davidson
>>> <angus.david...@wits.ac.za> wrote:
>>> > An Ascii file format really is a must. Apart from being able to hack
>>> and restore file (which saved many of my students when we were still using
>>> Maya, it also allow Czars Git plugin to become far more useful. To be able
>>> to run diffs on a scene to find out whats actually changed  would be
>>> amazing.
>>> >
>>> > Kind regards
>>> >
>>> > Angus
>>> > ________________________________________
>>> > From: Andy Jones [andy.jo...@gmail.com]
>>> > Sent: 08 September 2013 10:15 AM
>>> > To: softimage@listproc.autodesk.com
>>> > Subject: Re: Would you like to recover your scene?
>>> >
>>> > I'd love an ascii scene file format as much as the next guy, but
>>> > people still lose plenty of unsaved changes with Maya ascii.  Aside
>>> > from general hackability, the big advantage of .ma is being able to
>>> > fix broken scenes after they've been saved.
>>> >
>>> > On Sat, Sep 7, 2013 at 9:48 AM, Toonafish <ron...@toonafish.nl> wrote:
>>> >> Word !  That would save sooo many lives.
>>> >>
>>> >>
>>> >> - Ronald
>>> >>
>>> >>
>>> >> On 9/7/2013 18:23, Octavian Ureche wrote:
>>> >>
>>> >> Native ascii scene file format. Period.
>>> >> Though we've been asking for it forever now.
>>> >>
>>> >> -Octav
>>> >>
>>> >>
>>> >> On Sat, Sep 7, 2013 at 6:58 AM, 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
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>         Octavian Ureche
>>> >>  +40 732 774 313 (GMT+2)
>>> >>  Animation & Visual Effects
>>> >>           www.okto.ro
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Ronald van Vemden
>>> >> -----------------------------------------------
>>> >> 3D Graphics & Animation
>>> >> Cyberfish Laboratories | www.cyberfish.nl
>>> >> Toonafish | www.toonafish.nl
>>> >> tel. +31(0)20 5289291
>>> >> fax  +31(0)20 5289292
>>> >> email: ron...@toonafish.nl
>>> >
>>> > =
>>> > <table width="100%" border="0" cellspacing="0" cellpadding="0"
>>> style="width:100%;">
>>> > <tr>
>>> > <td align="left" style="text-align:justify;"><font
>>> face="arial,sans-serif" size="1" color="#999999"><span
>>> style="font-size:11px;">This communication is intended for the addressee
>>> only. It is confidential. If you have received this communication in error,
>>> please notify us immediately and destroy the original message. You may not
>>> copy or disseminate this communication without the permission of the
>>> University. Only authorised signatories are competent to enter into
>>> agreements on behalf of the University and recipients are thus advised that
>>> the content of this message may not be legally binding on the University
>>> and may contain the personal views and opinions of the author, which are
>>> not necessarily the views and opinions of The University of the
>>> Witwatersrand, Johannesburg. All agreements between the University and
>>> outsiders are subject to South African Law unless the University agrees in
>>> writing to the contrary. </span></font></td>
>>> > </tr>
>>> > </table>
>>> >
>>> >
>>>
>>>
>>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>

Reply via email to