This is what I have been doing all along:
Application/
Plugins/
commands/
events/
filters/
menus/
operators/
properties/
NC_ToolsUpdate.js
The only exception being NC_ToolsUpdate.js which used to be in the
commands directory. It'll be another day or so before I find out if
this works.
Matt
> -----Original Message-----
> From: owner-xsi(at)Softimage.COM
> [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Bernard Lebel
> Sent: Saturday, March 01, 2008 6:07 AM
> To: XSI(at)Softimage.COM
> Subject: Re: XSI crashes on startup when updating a workgroup
>
> I was thinking about this. Another very simple way to force
> the sync plugin to load without messing around with files
> names and load/unload/update commands would be to put the
> sync plugin in the root of Application/Plugins, and all other
> plugins in a subdirectory (Application/Plugins/Plugins).
>
> Bernard
>
>
>
> On Fri, Feb 29, 2008 at 7:58 PM, Bernard Lebel
> <3dbernard(at)gmail.com> wrote:
> > On Fri, Feb 29, 2008 at 5:05 PM, Matt Lind
> <mlind(at)carbinestudios.com> wrote:
> > > Could you elaborate here? What do you mean by, "also
> allowed us
> > to > change the log commands preference without having
> reset to true
> > by XSI, > by modifying the user preference file."
> >
> > Having the command logging preference turned on slows down
> XSI. So
> > unless a user explicetely requires it, it had to be turned off.
> >
> > The problem is that if the preference is true, and that
> you set it to
> > false in a script, XSI will automatically set it back to
> true after
> > execution. I believe this decision was made because of
> users abusing
> > support with having commands no longer logged without knowing why.
> >
> > So the only way to turn off command logging is to not do
> it with a
> > script that is executed in the XSI scripting engine.
> >
> > The file %XSI_USERROOT%\Data\Preferences\default.xsipref has the
> > command logging preference. Over here it's on line 122:
> > scripting.cmdlog = True
> > If you change this value to False and save the file, then you've
> > effectively disabled command logging without risking having
> it turned
> > to True by XSI.
> >
> > Now the thing is that some users actually want command
> logging. You
> > can't force them to not have it. So one solution is to have
> the user
> > value recorded in a database, and query the database to
> find out the
> > value the user really wants.
> >
> > How you perform this modification is entirely up to you.
> At big bang
> > a colleague wrote a JScript script that we would use to start XSI.
> > The script did many things:
> > - request a php page through an httprequest object (this
> is one handy
> > application of an apache server) so the user value can be retrieve
> > - rewrite the xsipref file
> > - launch the XSI batch file and die
> >
> > The script would also control the log file (to cut a long story
> > short, this was to make sure the last log would not get
> overwritten
> > by a new launch of XSI, and could be sent to a network location so
> > that we could look at it without bothering the user).
> >
> >
> > Speaking of apache server. It is the same process to
> synchronize the
> > local workgroup.
> > The JScript script would send a GET request for a php file to the
> > apache server (via a XMLRequest object), which would return an XML
> > with all the network workgroup files, including their mtime and an
> > http url to access them via the http protocol.
> > Then the JScript file would compare the XML mtimes vs the local
> > mtimes. For each server file more recent, it would send a
> single http
> > request to download the server file, using the http url
> provided in
> > the XML file, and write it in the local workgroup. Worked very well.
> >
> > Doing things this way allowed to not even bother about
> > UpdatePlugins() and stability. In fact, you don't even
> need to have
> > the local workgroup installed, as it will be created and
> populated at
> > the first launch.
> >
> > The impact of such processes is that there is a delay between the
> > moment you double-click the launch icon and the moment XSI
> actually
> > starts. Unless you were downloading the entire workgroup,
> it was 1-2
> > seconds.
> >
> >
> >
> >
> >
> >
> >
> >
> > > Unfortunately, I don't have any experience with Apache
> servers or
> > the > like. I'd like to get more involved in that area but don't
> > know where > to begin.
> >
> > I cannot tell you how to install and configure an apache server.
> > That's what sysadmins are there for :-) From what I know
> it should
> > run on Windows, but former sysadmin colleagues advised me
> to only run
> > one on a linux box.
> >
> > I can only recommend getting familiar with the XMLRequest and
> > WinHttpRequest objects (they share lots of functionality),
> Ajax and
> > PHP. Since you're already proficient with JavaScript, the request
> > objects should be very easy. Examples abound on the
> internet. PHP is
> > also quite an easy language imo. The problem is that if you go the
> > XMLRequest/Ajax route, you'll hardly make it without
> learning PHP at
> > the same time, Ajax being the client-side code, while PHP
> being the
> > server-side.
> >
> > Getting the basics of these nailed down will get you a long way.
> >
> > I know no other use of an apache server than everything I already
> > mentioned, unfortunately.
> >
> >
> >
> >
> >
> >
> > > Using your filenames as an example, if I needed to update
> > async.js, I > can't do it when XSI is loading because
> async.js will
> > be executing. The > only other time I can pull the
> latest version
> > of async.js and not get in > the way of the user would be
> when XSI
> > terminates. I can then unload the > plugin manually from XSI and
> > replace it. Next time XSI starts, it will > use the new
> version of
> > async.js. This is useful for occasions where the >
> production pipeline changes affecting tool delivery.
> >
> > The idea is to never have to update the async.js plugin.
> Once it's
> > written, tested and deployed, it must be only in the most major
> > circumstances that this specific plugin should be updated.
> Only other
> > plugins are updated. Again, using
> LoadPlugin()/UpdatePlugins() through
> > a loader plugin should completely eliminate the problem.
> >
> >
> > Bernard
> >
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following
> text in body:
> unsubscribe xsi
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
