Re: Note about PATH in WinXP [Flightgear-devel] Re: [ANN]Blender 2.37

2005-06-05 Thread theoreticle
Yes, I like that path as you set it: 
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\wbem;%userpath%'.


I wanted to use the GnuWin32 core utilities, so I went ahead and copied 
those into the system32 folder instead of defining a Path for them, but 
didn't overwrite the three Win command that had the same name (expand, sort 
and something else).  This is really nice for not having to switch back and 
forth between Unix/DOS-style commmands.  I cannot tell you how many times 
I've typed 'ls' at a WinXP command prompt!


- Original Message - 
From: Giles Robertson [EMAIL PROTECTED]

To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Saturday, June 04, 2005 6:53 AM
Subject: RE: Note about PATH in WinXP [Flightgear-devel] Re: [ANN]Blender 
2.37




%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\wbem;C:\;C:\WINDOWS\system32;C:\YAFRAY_DIR;C:\Python24


You should not include both %SystemRoot% and C:\WINDOWS paths. %SystemRoot% 
will be defined to the correct place on all NT-based systems (I don't know 
about 3.1/95/98/ME); however, if, for any reason your systemroot is not 
C:\WINDOWS (as it might be if you have 2000 and XP installed, and are 
booting into 2000), you could be calling up system applications for the 
wrong windows version (but only if they don't exist in %systemroot%). The 
mantra used to be that a short path is a fast path, but I think that 
consideration is probably now irrelevant.


My practice is to have a path that looks like this:

%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\wbem;%userpath%;

and to define everything else in a separate variable, %userpath%. However, 
there's no reason to do that except for greater aesthetics.


Giles Robertson







___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d 


___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: Note about PATH in WinXP [Flightgear-devel] Re: [ANN]Blender 2.37

2005-06-04 Thread Giles Robertson
 %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\wbem;C:\;C:\WINDOWS\system32;C:\YAFRAY_DIR;C:\Python24

You should not include both %SystemRoot% and C:\WINDOWS paths. %SystemRoot% 
will be defined to the correct place on all NT-based systems (I don't know 
about 3.1/95/98/ME); however, if, for any reason your systemroot is not 
C:\WINDOWS (as it might be if you have 2000 and XP installed, and are booting 
into 2000), you could be calling up system applications for the wrong windows 
version (but only if they don't exist in %systemroot%). The mantra used to be 
that a short path is a fast path, but I think that consideration is probably 
now irrelevant.

My practice is to have a path that looks like this:

%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\wbem;%userpath%;

and to define everything else in a separate variable, %userpath%. However, 
there's no reason to do that except for greater aesthetics.

Giles Robertson
winmail.dat___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Re: [ANN] Blender 2.37

2005-06-03 Thread Melchior FRANZ
* Sam Heyman -- Friday 03 June 2005 00:30:
 I have downloaded Blender 2.37 for Windows XP and it seems to work, 
 although I do get the message No Python Installed in the command window.

Well, then install Python? Exporting to AC3D format *requires* Python.
http://www.python.org/



 The problem is I can't open my aircraft.ac file.

Importing *.ac requires Python, too.  :-)  And even with Python installed,
you can't just Open it. You need to Import it (different menu entry).



 It says that it can't  
 open the texture file (fokker100.rgb), which I borrowed from the fokker 100.

It certainly can read fokker100.rgb. But if you have edited it and saved
it again, it's probably not a valid SGI image any more. See my other post.



 Does anyone know why this is happening? Can one create a new texture 
 using Blender?

Yes. You can draw to an applied texture directly on the 3D object and save
that. You won't get a pretty texture from that, but a useful draft that you
improve in gimp etc. Also, you can export textures with outlines of the
unwrapped, flattened faces. Which again requires Python. You just need
to fill that with color. 

m.

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Re: [ANN] Blender 2.37

2005-06-03 Thread Melchior FRANZ
* Andy Ross -- Saturday 04 June 2005 00:27:
 Hrm... maybe Blender should be using Nasal.

How would the filter read and write AC3D files? Without file IO
support?

m.

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: [ANN] Blender 2.37

2005-06-03 Thread Andy Ross
Melchior FRANZ wrote:
 How would the filter read and write AC3D files? Without file IO
 support?

It's written.  Here's proof:  http://plausible.org/andy/iolib.c

It probably won't compile against the SimGear nasal sources, though.
I really need to get my act together and make a new release.  There's
a bunch of stuff like this (integration to the pcre regex library,
utf8 string functions, unix syscall interface, the bits library I
mentioned earlier...) waiting for me to finish test code, write
documentation, and do integration stuff.

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Re: [ANN] Blender 2.37

2005-06-03 Thread Melchior FRANZ
* Andy Ross -- Saturday 04 June 2005 00:44:
 Melchior FRANZ wrote:
  How would the filter read and write AC3D files? Without file IO
  support?
 
 It's written.  Here's proof:  http://plausible.org/andy/iolib.c

Bah. That's no proof. I'm sure that's just made up!  :-}



 a bunch of stuff like this (integration to the pcre regex library,
 utf8 string functions, unix syscall interface, the bits library I
 mentioned earlier...)

But fgfs won't depend on pcre, right? Or do you plan to statically
link it? Sounds like great stuff, but how well would this work under
MICROS~1? Unix syscall? Or rather POSIX?

m.

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: [ANN] Blender 2.37

2005-06-03 Thread Andy Ross
Melchior FRANZ wrote:
 But fgfs won't depend on pcre, right? Or do you plan to statically
 link it? Sounds like great stuff, but how well would this work under
 MICROS~1? Unix syscall? Or rather POSIX?

Right.  The library stuff gets complicated enough that individual
projects will need to make their own decisions as to what is
appropriate to include.  Adding another library dependency to
FlightGear just to get regular expressions (for which I can't think of
a single application in a flight simulator) would be silly.

Really, I did the pcre integration because it was cool, and because
regex handling is the sine qua non of the modern scripting language,
and because I'd like to write an Apache templating module for Nasal.

The unix package is really unix (or POSIX, or SUSv2, or whatever you
want to call it -- the stuff for which there is no direct analog in
win32): pipes, opendir/readdir, fork/exec, dup2.  I'm not even going
to attempt to write a platform-independent library for this stuff;
that's what Perl and Python do, and it's one of the big reasons that
they're so huge.  There's no reason it won't work under cygwin,
though.  Likewise, this isn't likely to be very useful to FlightGear.

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: IMPORTANT NOTE ABOUT PATH/PYTHON [Flightgear-devel] Re: [ANN] Blender 2.37

2005-06-03 Thread theoreticle
Since PATH is not specifically defined through the Environment Variables 
(see my post two or three back in this thread about getting .ac files to 
import into Blender), if you create a new PATH variable, you should 
definitely definitely definitely add C:\WINDOWS\system32\; before anything 
else!  I just figured out that, if you don't do this... a whole lotta stuff 
like ipconfig, ping, etc. are not going to work!


If anyone can think of any other vital PATHs that need to be added, please 
let me know!



- Original Message - 
From: Andy Ross [EMAIL PROTECTED]

To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Friday, June 03, 2005 7:16 PM
Subject: Re: [Flightgear-devel] Re: [ANN] Blender 2.37



Melchior FRANZ wrote:

But fgfs won't depend on pcre, right? Or do you plan to statically
link it? Sounds like great stuff, but how well would this work under
MICROS~1? Unix syscall? Or rather POSIX?


Right.  The library stuff gets complicated enough that individual
projects will need to make their own decisions as to what is
appropriate to include.  Adding another library dependency to
FlightGear just to get regular expressions (for which I can't think of
a single application in a flight simulator) would be silly.

Really, I did the pcre integration because it was cool, and because
regex handling is the sine qua non of the modern scripting language,
and because I'd like to write an Apache templating module for Nasal.

The unix package is really unix (or POSIX, or SUSv2, or whatever you
want to call it -- the stuff for which there is no direct analog in
win32): pipes, opendir/readdir, fork/exec, dup2.  I'm not even going
to attempt to write a platform-independent library for this stuff;
that's what Perl and Python do, and it's one of the big reasons that
they're so huge.  There's no reason it won't work under cygwin,
though.  Likewise, this isn't likely to be very useful to FlightGear.

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: Note about PATH in WinXP [Flightgear-devel] Re: [ANN]Blender 2.37

2005-06-03 Thread theoreticle
Been digging through all of the MS articles, and if you do define a PATH to 
use Python (think you have to to get Blender to use Python), here's an 
example of how it should look:


%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\wbem;C:\;C:\WINDOWS\system32;C:\YAFRAY_DIR;C:\Python24

(The YAFRAY is optional, if you want to use the Yet Another Free Ray Tracer 
for Blender which most of the Blender types recommend)


- Original Message - 
From: [EMAIL PROTECTED]

To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Friday, June 03, 2005 9:05 PM
Subject: Re: IMPORTANT NOTE ABOUT PATH/PYTHON [Flightgear-devel] Re: 
[ANN]Blender 2.37



Since PATH is not specifically defined through the Environment Variables 
(see my post two or three back in this thread about getting .ac files to 
import into Blender), if you create a new PATH variable, you should 
definitely definitely definitely add C:\WINDOWS\system32\; before anything 
else!  I just figured out that, if you don't do this... a whole lotta 
stuff like ipconfig, ping, etc. are not going to work!


If anyone can think of any other vital PATHs that need to be added, please 
let me know!



- Original Message - 
From: Andy Ross [EMAIL PROTECTED]

To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Friday, June 03, 2005 7:16 PM
Subject: Re: [Flightgear-devel] Re: [ANN] Blender 2.37



Melchior FRANZ wrote:

But fgfs won't depend on pcre, right? Or do you plan to statically
link it? Sounds like great stuff, but how well would this work under
MICROS~1? Unix syscall? Or rather POSIX?


Right.  The library stuff gets complicated enough that individual
projects will need to make their own decisions as to what is
appropriate to include.  Adding another library dependency to
FlightGear just to get regular expressions (for which I can't think of
a single application in a flight simulator) would be silly.

Really, I did the pcre integration because it was cool, and because
regex handling is the sine qua non of the modern scripting language,
and because I'd like to write an Apache templating module for Nasal.

The unix package is really unix (or POSIX, or SUSv2, or whatever you
want to call it -- the stuff for which there is no direct analog in
win32): pipes, opendir/readdir, fork/exec, dup2.  I'm not even going
to attempt to write a platform-independent library for this stuff;
that's what Perl and Python do, and it's one of the big reasons that
they're so huge.  There's no reason it won't work under cygwin,
though.  Likewise, this isn't likely to be very useful to FlightGear.

Andy

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d