Re: [Flightgear-devel] /sim/navdb ?
Boris Koenig wrote: Hi ! Guess, who's here ;-) A quick question: I'm about to finish several smaller Nasal dialogs, now I wanted to add a simple flight planning dialog using Nasal, I thought I would find the necessary elements for the combo boxes under /sim/navdb within the property tree, but there does not seem to exist anything that I expected - is the data from the navaids file anywhere else exported within the property tree, or is it simply not yet there ? It's not there, and it probably never will be. The reason is simple, you would store too much data resident in memory which isn't needed more than 99% of the time. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] speed-with-pitch
På Tue, 21 Sep 2004 12:00:09 +0200, skrev Roy Vegard Ovesen [EMAIL PROTECTED]: I would suggest to use airspeed as input to a PID controller, your desired airspeed as reference and the elevator control surface as output. I haven't tried this, so good luck! Works like a charm :-) I got it stable with: Kp=0.0125, Ti=30.0, Td=0.0 with the Piper. You can start from there, and I'm sure that fine tuning will get better performance. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] /sim/navdb ?
Boris Koenig wrote: Erik Hofman wrote: Boris Koenig wrote: where else exported within the property tree, or is it simply not yet there ? It's not there, and it probably never will be. woohoo - don't say that: I was just about to make a terrible mess of the code ;-) No need, that has already been done. It turned out to be unsatisfactory after all. The reason is simple, you would store too much data resident in memory which isn't needed more than 99% of the time. okay, that's of course a point - otherwise it would definitely be useful if one could request certain nav-data to be made available within the property tree on demand, what do you think ? Alternatively, I was thinking of either using a separate fgcommand that pushes the data in the property tree when requested - so one would basically still have something like: /sim/navdb/vor /sim/navdb/ndb /sim/airports/ But it would only be an empty node, that would only be filled on demand with the return value of a fgcommand that makes a certain request. How about that ? What would be an idea is to use an fgcommand that looks at (for example) /sim/navdb/id and returns the data of that particular id in /sim/navdb/vor et all. I would also like to add support for puPopup's as well as exporting the menubar to the property tree - so that it can be populated/changed dynamically - any objections ? Popup dialogs should already be supported. Generating a dynamic menu structure might be harder than you think, the best option is a triggered reload I guess (which is already supported, see Debug-Reload GUI). Erik Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] /sim/navdb ?
Norman Vine said: Erik Hofman writes: Boris Koenig wrote: A quick question: I'm about to finish several smaller Nasal dialogs, now I wanted to add a simple flight planning dialog using Nasal, I thought I would find the necessary elements for the combo boxes under /sim/navdb within the property tree, but there does not seem to exist anything that I expected - is the data from the navaids file anywhere else exported within the property tree, or is it simply not yet there ? It's not there, and it probably never will be. The reason is simple, you would store too much data resident in memory which isn't needed more than 99% of the time. Hmm... a simple disk based database indexed by a new field which was the tile id of the object should be plenty quick enough for this type of thing with out to much of a memory hit Searches would then only need be made for those tiles of interest which would be dramatically faster then searching the 'world' One might get better results using a more sophisticated index such as a dedicated RTree if necessary but a tile based scheme would fit nicely with the existing 'indexing' Then again the current DB is about the size of the highres textures so my guess is that until the DB is significantly upgraded it could just be placed into memory you would still want some kind of spatial indexing though It would be kind of cool to be able to have a property system wrapper for data files like this, that swapped the interesting parts in and out as needed. The indexing could be designed to optimise this, for each type of layout. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
On 9/17/04 at 2:04 PM John Wojnaroski wrote: - Original Message - From: Jon Stockill [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, September 17, 2004 11:54 AM Subject: Re: [Flightgear-devel] A voice for FG John Wojnaroski wrote: Hi, The last month or so I've been working with adding synthetic speech and voice recognition to my 747 project. The results have been quite good; unfortunately it's kind of hard to demonstrate or display the results. Jim Brennan is preparing a corpus of messages and ATC phrases which will be used to create a LM (Language Model) for speech recognition and the synthetic speech voices come from a variety of sources -- most notably, the FestVox folks at CMU, MBROLA, and the OGI-Festival project at CSLU. I was working with the pre-release of festival 2.0 at work last week, and the new synthesis methods and voices that are available in that release sound particularly impressive. I did think of the possibility of using it for air traffic control, if not live then as an easy method to generate a batch of samples for use in a similar way to the way ATIS works at the moment. The approach that I've taken is to start a festival server on a networked machine and a small client program that receives a text message as a string , stuffs it into a festival protcol wrapper and calls the festivalStringToWave() method. This also will allow you to send control commands and files to the server to change voices, LMs, etc.. ../bin/festival --server loopback starts the server and any client on the local machine can connect by default. Connections over a LAN require a small Scheme script to add users to the festival_access_list as part of the argument list. The client program then has a few lines of socket code to connect to FG. On the FG side all you need is something to send a text string over the socket. Something like FGVoice::fg_say_mesg(this is a test); There are a couple of good examples in the /examples/ directory which I used to create a atc_net_demo.cpp application. The voice recognition is just as easy (actually easier to set up) but training the model, building the Acoustic model, and the dictionary plus any special phones is a little more envolved. If you don't mind a bit of a delay (around 2-3 sec) to decode the audio, you can use the existing models and get pretty good results. The resultant text string is sent to the AI controller where it is parsed into tokens and analyzed(compiled?). I'm not sure how all of this would fit into FG. I suspect the easiest way would be to create a voice object and a few methods and leave it up to the individual user if they want to setup the TTS festival package or ASR programs. This all sounds very exciting, especially the encouraging results from the voice recognition stage, and the fact that Jon thinks that Festival 2 is sounding pretty good. Could you send me the code you've got so far for sending strings across to FG? I'm a bit unclear which parts you are actually working on. Are you working on the decoding of the speech to text-strings only so far, or have you actually started on logically decoding the text strings for ATC-AI? This is the part I'm currently in deep thought about. A few random thoughts. Speech recognition for ATC ought to be easier than the general case, since the smaller vocabulary ought to mean that better guesses can be made, if this sort of thing can be specified to the ASR engine. Having it on another PC could be nice from the point of view that the engine sound from the FG PC can come from the speakers - with ATC from the TTS/ASR PC put though headphones to fairly realistically simulate the real environment. I guess eventually this support could be optionally compiled into FG as well. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problems Compiling with Cygwin again
Hi ! I wrote some weeks ago in the users list, that i have problems with compiling with cygwin. I have tried several things including a new installation of Windows XP and Cygwin. I installed the cygwin packages described in the documatation on the flightgear website. I`m using the newest versions of Simgear, Flightgear, Plib, openal. I downloaded them today. Plib and openal are compiling ok. But the sound files called testopenal1 of simgear wont compile It seems that Simgear does not link to Openal. So I added -lopenal manually to the makefile. After that i get the next error. The output then looks like this: Making all in sound make[3]: Entering directory `/usr/local/source/SimGear/simgear/sound' g++ -g -O2 -D_REENTRANT -L/usr/X11R6/lib -o openal_test2.exe openal_test2.o . ./../simgear/sound/libsgsound.a ../../simgear/debug/libsgdebug.a ../../simgear/m isc/libsgmisc.a ../../simgear/structure/libsgstructure.a -L/usr/local/lib -lopen al -lwinmm -ldsound -ldxguid -lole32 openal_test2.o(.text+0xd2): In function `_ZTv0_n12_N9logstreamD0Ev': /usr/local/source/SimGear/simgear/sound/../../simgear/debug/logstream.hxx: undef ined reference to `__imp__alSourcef' openal_test2.o(.text+0xe5):/usr/local/source/SimGear/simgear/sound/../../simgear /debug/logstream.hxx: undefined reference to `__imp__alGetError' openal_test2.o(.text+0x1d4):/usr/local/source/SimGear/simgear/sound/../../simgea r/debug/logstream.hxx: undefined reference to `__imp__alSourcef' openal_test2.o(.text+0x1e7):/usr/local/source/SimGear/simgear/sound/../../simgea r/debug/logstream.hxx: undefined reference to `__imp__alGetError' I really appreciate any help. Im a bit desperate I want to use Flightgear for my master thesis. Being unable to compile for weeks now counts as lost time for my thesis. I want to use it as FlightSimulator for a Fitnessmachine with which u can simulate flying like a bird and train by doing so. Thx in advance for any clues. Cu, Floh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Fw: Voice stuff (sans attached)
FYI if anyone wants the files (about 200k) give a holler you can run the whole mess on a single machine along with FG. The hit to the frame rate is TBD. - Original Message - From: John Wojnaroski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 9:44 AM Subject: Voice stuff Hi David, Attached are two files: comm_747 is a really bad hack for the CMU Sphinx ASR engine to create a text string and sent it out on the network to the atc_server voice.tgz is more hacking to send a text string to the festival server.. lines 73 to 76 is my highly sophisticated AI /ATC controller ;-) it untars as /Voice You can run festival as a server ../bin/festival --server on the same machine you run atc_net_demo and the audio will be produced on that machine or you can uncomment lines 295-309 and also send a .wav file back to the client machine. A quick recap: Machine #1 runs sphinx2 which receives the audio input from the user, converts it to text and sends it over to Machine #2 which parses the text string into tokens and does it's AI/ATC stuff, formulates a text response and passes that to the festival server (in this case on 127.0.0.1) which creates the audio file and outputs it to the local soundcard. If you run the festival server on a seperate network machine or back on #1 you need to create a short .scm script to add the user to the festival access list as in atc.scm You need to upload the ASR sphinx2 stuff and TTS festival stuff from CMU or wherever. If you need some help or tips in that area give a holler... http://linux-sound.org/speech.html is a list of speech related websites you might find useful. In particular-- the Festival set, XVoice, Sphinx, and MBROLA. I'm using the You'll find http://www.speech.cs.cmu.edu/tools/lmtool.html quite useful for creating a LM and phonelist for the ASR program. With the smaller dictionaries voice recognition is very good but if you mumble a lot (like I do) the XVoice folks have a wiki page with instructions on how to add a voice trainer and improve/tailor the AM for individual speech patterns. Setting up the programs takes a little work. You can use the AM provided with sphinx2, but you'll get much better results if you upload and install the hub4-2000-11-17-1 model. And you will need to create a LM that contains ATC phrases and words Good luck, again you've got my email, don't hesitate if you need help or have questions. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
On Tue, 21 Sep 2004 11:27:37 -0400, Chris wrote in message [EMAIL PROTECTED]: On Tue, 21 Sep 2004 16:02:34 +0100 Jon Stockill [EMAIL PROTECTED] wrote: Those demos are based on festival 1.4 - the prerelease of 2.0 includes a synthesis module called multisyn, which is a great improvement on the older modules. http://flightgear.stockill.org.uk/testing/atis.wav contains the synthesised text of an atis transmission using one of the multisyn voices. That's a great Cleveland accent! :) ..if you like a draaawl, try sox -V atis.wav atis.ogg speed 0.5 # ;-). Really amazing how a few extra seconds spent on the tape adds to speeding up getting-the-message, try it with speeds around .8 to .9. Seriously, this is pretty cool. If it's being run on the same machine at fgfs, what is the overhead involved? Would framerates be expected to drop into the dirt while the speech is being done? -c -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] speed-with-pitch
I would suggest to use airspeed as input to a PID controller, your desired airspeed as reference and the elevator control surface as output. I haven't tried this, so good luck! Works like a charm :-) I got it stable with: Kp=0.0125, Ti=30.0, Td=0.0 with the Piper. You can start from there, and I'm sure that fine tuning will get better performance. Thanks Roy, it works better now, but still not enough to prevent crashing. It looks like I'll still need an external monitor to clamp the pitch angle. For instance, if I'm doing an idle descent at 250 kts and reset the speed to 300, I need to keep the airplane from going straight down. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problems Compiling with Cygwin again
Florian Schießl Sent: Tuesday, September 21, 2004 4:51 PM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Problems Compiling with Cygwin again Hi ! I wrote some weeks ago in the users list, that i have problems with compiling with cygwin. I have tried several things including a new installation of Windows XP and Cygwin. I installed the cygwin packages described in the documatation on the flightgear website. I`m using the newest versions of Simgear, Flightgear, Plib, openal. I downloaded them today. Plib and openal are compiling ok. But the sound files called testopenal1 of simgear wont compile It seems that Simgear does not link to Openal. So I added -lopenal manually to the makefile. After that i get the next error. The output then looks like this: Making all in sound make[3]: Entering directory `/usr/local/source/SimGear/simgear/sound' g++ -g -O2 -D_REENTRANT -L/usr/X11R6/lib -o openal_test2.exe openal_test2.o . ./../simgear/sound/libsgsound.a ../../simgear/debug/libsgdebug.a ../../simgear/m isc/libsgmisc.a ../../simgear/structure/libsgstructure.a -L/usr/local/lib -lopen al -lwinmm -ldsound -ldxguid -lole32 openal_test2.o(.text+0xd2): In function `_ZTv0_n12_N9logstreamD0Ev': /usr/local/source/SimGear/simgear/sound/../../simgear/debug/lo gstream.hxx: undef ined reference to `__imp__alSourcef' openal_test2.o(.text+0xe5):/usr/local/source/SimGear/simgear/s ound/../../simgear /debug/logstream.hxx: undefined reference to `__imp__alGetError' openal_test2.o(.text+0x1d4):/usr/local/source/SimGear/simgear/ sound/../../simgea r/debug/logstream.hxx: undefined reference to `__imp__alSourcef' openal_test2.o(.text+0x1e7):/usr/local/source/SimGear/simgear/ sound/../../simgea r/debug/logstream.hxx: undefined reference to `__imp__alGetError' I really appreciate any help. Im a bit desperate I want to use Flightgear for my master thesis. Being unable to compile for weeks now counts as lost time for my thesis. I want to use it as FlightSimulator for a Fitnessmachine with which u can simulate flying like a bird and train by doing so. Thx in advance for any clues. Cu, Floh Have you downloaded and installed openal_cyg.tgz from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/ It still seems to be required for Cygwin. The error with test openal_test2.exe or something like it was present in an earlier version of simgear. Have you definitely downloaded the latest version of Simgear? FGFS does compile under Cygwin - I did it this morning. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fw: Voice stuff (sans attached)
On Tue, 21 Sep 2004 09:58:30 -0700, John wrote in message [EMAIL PROTECTED]: FYI if anyone wants the files (about 200k) give a holler ..yhooo! ;-) you can run the whole mess on a single machine along with FG. The hit to the frame rate is TBD. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
Boris Koenig wrote: Jon Stockill wrote: Those demos are based on festival 1.4 - the prerelease of 2.0 includes a synthesis module called multisyn, which is a great improvement on the older modules. http://flightgear.stockill.org.uk/testing/atis.wav contains the synthesised text of an atis transmission using one of the multisyn voices. Thanks for the clarification and the example - it does indeed sound already quite usable, particularly taking into account that your example file did not even make use of any customized language model ! Yes, that's the result of just feeding the text of an atis report I found with google straight into the text2wave script. I'm sure it could be improved quite a lot just by playing around with punctuation to get the correct cadence. I only wonder, how long the actual calculation of a new language model takes - any ideas ? None at all I'm afraid. I just needed festival to add easily generated speech to a telephone IVR project. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Monday 20 September 2004 08:39, Vivian Meazza wrote:
{snip...]
Lee,
Here's some pics off the effects I obtained:
http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_drag-full_g
ravity.jpg
http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-acc
elerating.jpg
http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-bom
bs_overtaking. jpg
http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-bra
king.jpg
I hope that you can achieve the same.
Regards
Vivian
Sadly, no. Those pics are pretty much what I was hoping to see
here but it's just not happening. This is very odd.
I could post a pic showing the a/c after braking, with the string
of bombs behind and the cluster around the nose (which would
show that it had moved, while releasing bombs and was now
stationary) but is there any point?
I'm a bit reluctant to do a full fresh cvs checkout because I'd
have to also get a new base package too, wouldn't I? Still on
dial-up here so I'd like to avoid having to do that if possible.
If I delete the source code directories from my local cvs and
then did an update, would it replace anything that was missing?
I guess I could try getting FG installed on one of my other
workstations and see if I get the same results.
I did try setting a more verbose log-level but didn't see
anything there either.
This is such a strange problem. Because there are no apparent
run-time errors it's difficult not to conclude that there's a
logic error in the code but the fact it works elsewhere rules
that out.
Feeling pretty stumped here:-/
LeeE
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal'ing ...
[Sorry I've been so long getting back to this; I had to go to Japan on short notice and this is the first chance I've had in the hotel room to catch up on personal stuff without jet-lag. :)] Boris Koenig wrote: I don't seem to be able to access a method like gui.Widget.new() from an object defined in another module, even though I _think_ ;-) I'm doing the right thing, basically that is: two .nas-files stored in /Nasal/ whose contents will be made available as modules within Nasal. This is an ordering issue. Remember that loading and running a script are the same thing in Nasal. If the test2 module loads before test1, then test1 will not be initialized when test2 tries to use it. Some of the Nasal files get around this issue by doing their initialization work in a timer that is registered to run after a zero-length timeout. Look for a function called INIT() in several scripts; I believe one of them has an extensive comment talking about how the mechanism works. What would be a better, permanent solution would be to support an import feature. Thus, test2 could execute something like import(test1) which would stop execution and load the test1 module before returning. Note that this is another reason to support recursive interpreter contexts, which I talked about earlier. But I did meanwhile play around with the mechanism that you used in that example, and I'm surprised to see that it _seems_ already quite possible to dynamically create a gui ... I haven't yet tried to create every PUI - control, but so far it's already extremely usable. The current GUI system creates an interface out of a property tree. That tree can be dynamically created with a Nasal script, so yes: what you want to do is possible. Not every PUI binding is supported, though. For example, you can create the interface dynamically, but you can't change its structure at runtime (although you can destroy and re-create the dialog, which might be good enough for many purposes). If those get used, you can end up in a situation where the old and new versions of the file are in use simultaneously. Likewise, think of timers registered by the old version that get run after the new one is loaded. but, this shouldn't happen if the other Nasal code gets reloaded, too - right ? No. Timers and other references are not stored symbolically. That is, they are stored in C++ space as a NaRef object, which contains a pointer into the garbage collected Nasal storage. The timer does not store something like module.SomeFunction() which would do the symbol lookup when executed. If you reload a module, references to the older objects will stay alive. Also, what's the preferred way of implementing a basic event loop using Nasal, I've played around with this by using either a normal loop, or a timer - what's the best choice to poll a certain node from the property tree and act upon it assuming a certain value ? You can't spin in a Nasal loop at the moment; you will just hang the simulator. This would require the multiple contexts feature to implement -- the Nasal subsystem could let a script execute for N instructions and then put it on a save list for execution the next frame. Even then, there are significant performance and resource issues with that kind of programming. Right now, polling in a timer is probably your best bet. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] speed-with-pitch
På Tue, 21 Sep 2004 12:02:34 -0500, skrev David Culp [EMAIL PROTECTED]: I would suggest to use airspeed as input to a PID controller, your desired airspeed as reference and the elevator control surface as output. I haven't tried this, so good luck! Works like a charm :-) I got it stable with: Kp=0.0125, Ti=30.0, Td=0.0 with the Piper. You can start from there, and I'm sure that fine tuning will get better performance. Thanks Roy, it works better now, but still not enough to prevent crashing. It looks like I'll still need an external monitor to clamp the pitch angle. For instance, if I'm doing an idle descent at 250 kts and reset the speed to 300, I need to keep the airplane from going straight down. 50 kts is quite a large change in reference, if you could change it gradually from 250 to 300, I'm sure that would be safer. It is not uncommon, in the process control world, to only let the reference change as a ramp. A gradual change at some appropriate rate, instead of a sudden change. If you feel that you absolutely have to control the pitch angle, I would suggest that you go for a cascade configuration. One controller to control pitch angle using the elevator and one to control airspeed using the (controlled) pitch angle. Now you can easily limit the pitch angle. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems Compiling with Cygwin again
HI! Thx that helped, now it works. :) Vivian Meazza wrote: Have you downloaded and installed openal_cyg.tgz from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/ It still seems to be required for Cygwin. The error with test openal_test2.exe or something like it was present in an earlier version of simgear. Have you definitely downloaded the latest version of Simgear? FGFS does compile under Cygwin - I did it this morning. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Cu, Floh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fw: Voice stuff (sans attached)
On Tue, 21 Sep 2004 19:13:21 +0100, Giles wrote in message [EMAIL PROTECTED]: http://homepages.westminster.org.uk/giles.robertson/fgfsvoice.htm ..yes??? An autorization dialog and a 401.3 off a wintendo server? Giles Robertson -Original Message- From: Arnt Karlsen [mailto:[EMAIL PROTECTED] Sent: 21 September 2004 18:52 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Fw: Voice stuff (sans attached) On Tue, 21 Sep 2004 09:58:30 -0700, John wrote in message [EMAIL PROTECTED]: FYI if anyone wants the files (about 200k) give a holler ..yhooo! ;-) you can run the whole mess on a single machine along with FG. The hit to the frame rate is TBD. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
