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 :-)
