Re: [Flightgear-devel] Stepping and other inquisitions
On Fri, 27 Feb 2004 10:23:00 -0600 Curtis L. Olson wrote: What we did with the FGNetFDM and FGNetCtrls structures was to write separate header files outside the scope of the FlightGear project and put these into the public domain. Actually, our first experiment was with 0.9.3, where this was not true yet. I've just had a look at the CVS files, and was happy to find out that now, I don't have doubts any more on the legal aspect of using the header file (net_fdm.hxx). We do take the GPL and all licensing terms and restrictions very seriously in the FG project. We try very hard to honor the license terms of other people's work, and only include it if the license terms are compatible with FG's. Likewise we hope everyone else will give similar attention to FG's GPL license terms and play fairly. Many of us have put in literally hundreds and thousands of hours into FG as volunteers. We have made all our efforts available to the world under the terms of the GPL. We could probably have a long heated debate about the specifics of various open source licenses, but the GPL gives a fair balance between allowing us to protect our work and dictate it's use while at the same time providing everyone with enough freedom to make reasonable use of our efforts. Even if someone finds a way to leverage flightgear to make money (i.e. building a larger product on top of it or what ever) the terms of the GPL keep the playing field level so that anyone (should they choose) would have the opportunity to do the same things. I take the legal aspects of the GPL (and the freedom-of-information / community spirit as well) very seriously myself, and that is why I ask the question. You might heave misunderstood me, I want to do all this the right way, and that is why I asked the question on this list. What I was saying is that our code just cannot be distributed (it is not its aim anyway), and giving away the source is just out of the question for confidentiality reasons. That is why I want to keep the codes separated. However, if I can work on a non-confidential addition to flightgear, I'll be happy to submit it to the community. There is one issue I'm working on right now (although it's not even close to average prioririty in my workload, I have to think about it when I'm not at work), which might be interesting to discuss. How could I go about drawing an OpenGL HUD (we already have the code, which cannot be distributed) on top of the flightgear visual, using only software (video hardware is always possible, but too expensive for an inexpensive simple visual system) ? The problem is that even the symbols drawn on the HUD are some company's property (it's not even ours), so I can't be doing that in a source that would be redistributed. I like to think in terms of a data channel and a command channel. The data channel would be the NetFDM structure that would get blasted over via UDP at a fast rate (i.e. 60 hz) If you drop a packet, don't spend time trying to resend old data, just send the new data and keep going. The command channel is a lower bandwidth, high reliablity channel. You are guaranteed that every message gets to the reciever once (and only once.) This is great for setting up weather conditions, time of day, camera parameters, and anything else that might have an impact on the visuals. We have a convenient telnet interface to all the internal properties and built in commands. Anything you can set from the keyboard, or mouse, or gui, you can do from a remote program or script. It's much lower bandwidth, but very convenient. All that I had already figured out, but thanks. We might be trying to set up a connection with telnet as well, and set properties that way. Actually I was using a web browser to monitor the properties during our first tries. But the telnet interface in raw mode could be useful for controlling flightgear from our simulator. Also I should point out that if you can run your monitors/projectors at 60hz refresh rate, and then sync FG to the vertical refresh signal, and if your hardware is fast enough to sustain at least 60hz, then you can have extremely smooth displays. If you are able to send the NetFDM packets at exactly 60hz to all your display channels, you can have remarkably good syncronization between channels, and very smooth animation over all. But the key is to have *everything* running at a solid consistant frame rate. If you can't do 60hz, we have a mechanism to artificially throttle the frame rate to something lower, like 30hz or 20hz. Sometimes a slower consistant frame rate produces much smoother results than a faster, but varying frame rate. Actually we have a cycle period of 60ms, and we can try to lower it to 40ms, but that's only 16 to 25hz. And our display is indeed 60hz. Anyway, we can't do much better than that, and it's not only code efficiency, there are other issues. Thanks for the tip
Re: [Flightgear-devel] Stepping and other inquisitions
On Wed, 25 Feb 2004 22:55:50 +0100 Erik Hofman wrote: It should also be working with the latest version of FlightGear. And if they patched FlightGear to support their software they *must* send you the source at your request (GPL compatibility). How interesting... I was just about to ask about this kind of thing. First of all, congrats to Curt and to the mother for the baby. And now to my question. If I write a .h file that re-defines the NetFDM structure, so that a C program can interact with fgfs via the native FDM protocol, will the file be considered as part of FlightGear and consequently inherit the GPL (and the whole C program along with it) ? Or is it only considered as some sort of data definition only ? Actually, we might be considering the use of FlightGear as a simple visual system on some of the simulators we have at work (we use other systems I once told you about, APOGEE by SOGITEC), but of course the code of our simulators can't be GPL... It will most probably never be redistributed anyway, so nobody would have noticed, but I just wanted to know exactly how much legal interaction actually takes place, so that I can give accurate information about this to other people here which would ask that sort of question. By the way, my colleagues were surprised that with only a couple of days' work (most of that time spent studying the NetFDM code), it just worked... Of course, it needs some tweaking, but position and orientation were correctly displayed, which was already impressive if we compare that to some of the very burdensome protocols we sometimes have to deal with... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Jorge Van Hemelryck wrote: On Wed, 25 Feb 2004 22:55:50 +0100 Erik Hofman wrote: It should also be working with the latest version of FlightGear. And if they patched FlightGear to support their software they *must* send you the source at your request (GPL compatibility). How interesting... I was just about to ask about this kind of thing. First of all, congrats to Curt and to the mother for the baby. And now to my question. If I write a .h file that re-defines the NetFDM structure, so that a C program can interact with fgfs via the native FDM protocol, will the file be considered as part of FlightGear and consequently inherit the GPL (and the whole C program along with it) ? Or is it only considered as some sort of data definition only ? The header files for native.hxx and native_ctrl.hxx have been modified and don't fall under the GPL, just for this purpose. There have been problems with GPL'ed headers for other projects. Actually, we might be considering the use of FlightGear as a simple visual system on some of the simulators we have at work (we use other systems I once told you about, APOGEE by SOGITEC), but of course the code of our simulators can't be GPL... It will most probably never be redistributed anyway, so nobody would have noticed, but I just wanted to know exactly how much legal interaction actually takes place, so that I can give accurate information about this to other people here which would ask that sort of question. By the way, my colleagues were surprised that with only a couple of days' work (most of that time spent studying the NetFDM code), it just worked... Of course, it needs some tweaking, but position and orientation were correctly displayed, which was already impressive if we compare that to some of the very burdensome protocols we sometimes have to deal with... Well, you have to provide the source code at the request of the user. If there aren't any users, you wouldn't have to provide the source :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Jorge Van Hemelryck wrote: How interesting... I was just about to ask about this kind of thing. First of all, congrats to Curt and to the mother for the baby. And now to my question. Thanks. :-) Today is a day I'm struggling to get through with very little sleep so hopefully no one will ask me to do anything that requires problem solving or actual thought. If I write a .h file that re-defines the NetFDM structure, so that a C program can interact with fgfs via the native FDM protocol, will the file be considered as part of FlightGear and consequently inherit the GPL (and the whole C program along with it) ? Or is it only considered as some sort of data definition only ? What we did with the FGNetFDM and FGNetCtrls structures was to write separate header files outside the scope of the FlightGear project and put these into the public domain. There is no problem with including these files in a GPL program such as FlightGear, and also no problem including these files in some other proprietary software. I don't see this as an attempt to circumvent the GPL. It's just a convenience to make communication easier and make FG usable for a larger set of tasks. Actually, we might be considering the use of FlightGear as a simple visual system on some of the simulators we have at work (we use other systems I once told you about, APOGEE by SOGITEC), but of course the code of our simulators can't be GPL... It will most probably never be redistributed anyway, so nobody would have noticed, but I just wanted to know exactly how much legal interaction actually takes place, so that I can give accurate information about this to other people here which would ask that sort of question. We do take the GPL and all licensing terms and restrictions very seriously in the FG project. We try very hard to honor the license terms of other people's work, and only include it if the license terms are compatible with FG's. Likewise we hope everyone else will give similar attention to FG's GPL license terms and play fairly. Many of us have put in literally hundreds and thousands of hours into FG as volunteers. We have made all our efforts available to the world under the terms of the GPL. We could probably have a long heated debate about the specifics of various open source licenses, but the GPL gives a fair balance between allowing us to protect our work and dictate it's use while at the same time providing everyone with enough freedom to make reasonable use of our efforts. Even if someone finds a way to leverage flightgear to make money (i.e. building a larger product on top of it or what ever) the terms of the GPL keep the playing field level so that anyone (should they choose) would have the opportunity to do the same things. By the way, my colleagues were surprised that with only a couple of days' work (most of that time spent studying the NetFDM code), it just worked... Of course, it needs some tweaking, but position and orientation were correctly displayed, which was already impressive if we compare that to some of the very burdensome protocols we sometimes have to deal with... I like to think in terms of a data channel and a command channel. The data channel would be the NetFDM structure that would get blasted over via UDP at a fast rate (i.e. 60 hz) If you drop a packet, don't spend time trying to resend old data, just send the new data and keep going. The command channel is a lower bandwidth, high reliablity channel. You are guaranteed that every message gets to the reciever once (and only once.) This is great for setting up weather conditions, time of day, camera parameters, and anything else that might have an impact on the visuals. We have a convenient telnet interface to all the internal properties and built in commands. Anything you can set from the keyboard, or mouse, or gui, you can do from a remote program or script. It's much lower bandwidth, but very convenient. Also I should point out that if you can run your monitors/projectors at 60hz refresh rate, and then sync FG to the vertical refresh signal, and if your hardware is fast enough to sustain at least 60hz, then you can have extremely smooth displays. If you are able to send the NetFDM packets at exactly 60hz to all your display channels, you can have remarkably good syncronization between channels, and very smooth animation over all. But the key is to have *everything* running at a solid consistant frame rate. If you can't do 60hz, we have a mechanism to artificially throttle the frame rate to something lower, like 30hz or 20hz. Sometimes a slower consistant frame rate produces much smoother results than a faster, but varying frame rate. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
Re: [Flightgear-devel] Stepping and other inquisitions
On Thu, 26 Feb 2004 11:24:19 -0500, Norman Vine [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Martin Spott writes: Erik Hofman wrote: Too often companies don't really understand the power of Freeware/Open-Source software. If they don;t like the way the netFDM structure is maintained it is easy to create a network protocol for FlightGear that suits their needs. Please don't misunderstand me, I'm not an advocate of this company but I can partially follow their move: If there were _one_ network protocol that doesn't picture internal data structures of FlightGear but that was designed with the goal of a universal network protocol in mind, then there would not even be any discussion over network protocols. People would simply look into some README and implement what's written there. I have reccomended that we use this package before and am doing so again :-) http://www.unidata.ucar.edu/packages/netcdf/ ..http://www.unidata.ucar.edu/packages/netcdf/copyright.html is compatible with the GPL? It looks that way to me, but IANAL. -- ..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
Re: [Flightgear-devel] Stepping and other inquisitions
On 2/25/04 at 10:55 PM Erik Hofman wrote: Joshua W. Keane wrote: Don't you just hate bugs!? The problem is that i'm using a precompiled or prebuilt version of flightgear, v0.9.2 because it is currently the version supported by the aerosim blockset for matlab/simulink. It should also be working with the latest version of FlightGear. And if they patched FlightGear to support their software they *must* send you the source at your request (GPL compatibility). Umm, I would have thought that that only applies if they redistribute their patched version of FlightGear. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
David Luff wrote: Umm, I would have thought that that only applies if they redistribute their patched version of FlightGear. If they don't redistribute it, then there would be no patch. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Martin Spott wrote: Hello Martin, For the time being, we are going to stick with the 0.9.2 version because it works. The protocol we use is the UDP-based external FDM. We form the structure NetFDM as defined in the FlightGear header net_fdm.hxx and then send it to the UDP socket. We had problems in the past with the way this structure is defined. It changes with each new release of FlightGear and there is no backward compatibility (i.e. a newer version of FG will not accept a NetFDM structure in the older format) Also there is the byte alignment problem - depending on compiler settings, the NetFDM structure will have a different size, and if the size comes out to be different than the one FlightGear expects, the data is rejected. It might help to give FlightGear a well defined, at least compiler- (better: platform-) independent NetFDM interface, Out of necessity this structure is extended as new needs are discovered. We include a version number in the structure so software on either end can verify they are passing the same version of the contents. The included source code that can take an instance of NetFDM and translate it into FG properties as well as the code that can build an instance of NetFDM from the current state of the property tree can optionally do it's work in network byte order. When the structure does change, it is literally trivial to upgrade the other end. Copy over the new structure, see if you care about any of the new fields (usually not) and recompile your software. If they want the ultimate in flexibility they should use Eric's generic output facility because there you can define exactly what output you want via an xml config file and it only changes when you want it to change. Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Erik Hofman wrote: Too often companies don't really understand the power of Freeware/Open-Source software. If they don;t like the way the netFDM structure is maintained it is easy to create a network protocol for FlightGear that suits their needs. Please don't misunderstand me, I'm not an advocate of this company but I can partially follow their move: If there were _one_ network protocol that doesn't picture internal data structures of FlightGear but that was designed with the goal of a universal network protocol in mind, then there would not even be any discussion over network protocols. People would simply look into some README and implement what's written there. I made some attempts myself driving FlightGear from an external 'FDM' program and after discussing the topic on this list I came to the conclusion that the currently available network FDM interfaces are nothing but simple hacks. Not to offend anyone: I'm absolutely fine with the sitation, that 'worksforme' is the most relevant for such a hack - but that does not rule out that a well defined protocol would be 'useful to have', Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Martin Spott wrote: Please don't misunderstand me, I'm not an advocate of this company but I can partially follow their move: If there were _one_ network protocol that doesn't picture internal data structures of FlightGear but that was designed with the goal of a universal network protocol in mind, then there would not even be any discussion over network protocols. People would simply look into some README and implement what's written there. I think we have worked pretty hard to address people's needs when they ask for help. In this case, I think the company has viewed us a static entity and as far as I know hasn't even vocalized any desires or any comments on this subject. That's ok, but sometimes asking for help or asking if something can be changed or adjusted can make a world of difference. On the flip side, we are all busy, and all volunteers so we can't always do everything we'd like to do. I made some attempts myself driving FlightGear from an external 'FDM' program and after discussing the topic on this list I came to the conclusion that the currently available network FDM interfaces are nothing but simple hacks. Not to offend anyone: I'm absolutely fine with the sitation, that 'worksforme' is the most relevant for such a hack - but that does not rule out that a well defined protocol would be 'useful to have', Please tell me what elements the current interface is missing? Right now I'm flying flightgear with an external (proprietary) FDM as part of a side project I'm involved in. It's been working great for a year, and supports all the functionality I need. Regards, Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Curtis L. Olson wrote: Please tell me what elements the current interface is missing? Aside from the fact that my project is frozen for a yet undetermined amount of time because I need all my spare time for the PPL My _taste_ would have been a (documented ;-)) bit-pattern that I could generate on another host running Unix as well as from a microcontroller, communicating over a serial 9.6 kBit/s line. It might be easier to run a separate daemon for checksumming and unpacking the bit pattern which connects over a local socket to FlightGear and employs Erik's configurable interface, but on the other hand it would be 'nicer' to have this running as another thread within FlightGear (like the weather interface). It would be even nicer to have Erik's configurable interface being capable to deal with this more complex task. But please remember: I won't need it for the next time :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Stepping and other inquisitions
Martin Spott writes: Erik Hofman wrote: Too often companies don't really understand the power of Freeware/Open-Source software. If they don;t like the way the netFDM structure is maintained it is easy to create a network protocol for FlightGear that suits their needs. Please don't misunderstand me, I'm not an advocate of this company but I can partially follow their move: If there were _one_ network protocol that doesn't picture internal data structures of FlightGear but that was designed with the goal of a universal network protocol in mind, then there would not even be any discussion over network protocols. People would simply look into some README and implement what's written there. I have reccomended that we use this package before and am doing so again :-) http://www.unidata.ucar.edu/packages/netcdf/ Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Martin Spott wrote: Erik Hofman wrote: If they don't redistribute it, then there would be no patch. Hello Martin, For the time being, we are going to stick with the 0.9.2 version because it works. The protocol we use is the UDP-based external FDM. We form the structure NetFDM as defined in the FlightGear header net_fdm.hxx and then send it to the UDP socket. We had problems in the past with the way this structure is defined. It changes with each new release of FlightGear and there is no backward compatibility (i.e. a newer version of FG will not accept a NetFDM structure in the older format) Also there is the byte alignment problem - depending on compiler settings, the NetFDM structure will have a different size, and if the size comes out to be different than the one FlightGear expects, the data is rejected. It might help to give FlightGear a well defined, at least compiler- (better: platform-) independent NetFDM interface, Too often companies don't really understand the power of Freeware/Open-Source software. If they don;t like the way the netFDM structure is maintained it is easy to create a network protocol for FlightGear that suits their needs. If it seems useful enough, chances are the code could even end up in FlightGear. Maybe it would be a good idea to extend the generic protocol to also accept incoming packages and (if needed) add support for sending binary data. Then it would be as easy as defining your own protocol configuration file and put it in the FlightGear/data/Protocols directory. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Erik Hofman wrote: If they don't redistribute it, then there would be no patch. Hello Martin, For the time being, we are going to stick with the 0.9.2 version because it works. The protocol we use is the UDP-based external FDM. We form the structure NetFDM as defined in the FlightGear header net_fdm.hxx and then send it to the UDP socket. We had problems in the past with the way this structure is defined. It changes with each new release of FlightGear and there is no backward compatibility (i.e. a newer version of FG will not accept a NetFDM structure in the older format) Also there is the byte alignment problem - depending on compiler settings, the NetFDM structure will have a different size, and if the size comes out to be different than the one FlightGear expects, the data is rejected. It might help to give FlightGear a well defined, at least compiler- (better: platform-) independent NetFDM interface, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Don't you just hate bugs!? The problem is that i'm using a precompiled or prebuilt version of flightgear, v0.9.2 because it is currently the version supported by the aerosim blockset for matlab/simulink. Thanks Josh At 07:57 PM 2/23/2004, you wrote: Joshua W. Keane said: Hello everyone, I'm working on a simulation project using a simulink model. Currently, I'm running an interface using the Aerosim blockset for matlab/simulink, but the program steps/chops, especially when the sun/moon position is updated (and when other info is output to the cmd window). I'm currently running both on a single computer, but this computer is a pretty high-end machine. So the question really is: can I stop those updates from occuring, or should I just try using a network with 2 computers? Another thing i've seen is the fact that after a minute of running my simulation, the simulation suddenly turns to night. Can anyone tell me why this is? and how can I stop it from occuring? One last thing: there is a command to do not advance time of day (--enable-clock-freeze) and if i've read the documentation correctly, this should keep the time of day constant while letting the simulation run, right? But when I go and set that - it pauses the simulation and i can not do anything. Do i have the wrong idea about this? I would guess that the effect you are seeing is actually from loading scenery data. Have you built flightgear configured --with-threads? The turning to night sounds like an old bug that has been fixed in CVS. My guess is that the --enable-clock-freeze issue you describe is a bug. Same thing happens here. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Joshua William Keane George Washington University Graduate Student Vehicle Dynamics Branch NASA Langley Research Center Hampton, VA 23681 Mail Stop 153 Phone: (757) 864-9636 Fax: (757) 864-7722 Email: [EMAIL PROTECTED] Office: Bldg 1192C, Room 159 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Joshua W. Keane wrote: Don't you just hate bugs!? The problem is that i'm using a precompiled or prebuilt version of flightgear, v0.9.2 because it is currently the version supported by the aerosim blockset for matlab/simulink. It should also be working with the latest version of FlightGear. And if they patched FlightGear to support their software they *must* send you the source at your request (GPL compatibility). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Joshua W. Keane said: Don't you just hate bugs!? The problem is that i'm using a precompiled or prebuilt version of flightgear, v0.9.2 because it is currently the version supported by the aerosim blockset for matlab/simulink. That's an old version. One thing that might help if you can't upgrade or compile is increasing the visibility way up (z key), wait a few seconds for Flightgear to load the extra scenery and then decreasing it back down before you take off. This will eliminate the scenery loading for a short period, longer if you don't travel far. Otherwise see about getting an update. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Jim Wilson wrote: Joshua W. Keane said: Don't you just hate bugs!? The problem is that i'm using a precompiled or prebuilt version of flightgear, v0.9.2 because it is currently the version supported by the aerosim blockset for matlab/simulink. [...] Otherwise see about getting an update. I got a short reply from them several weeks ago after pointing out that they were using an old version of FGFS. They told me they were not interested in upgrading because they didn't want to track the changes between 0.9.2 and 0.9.3, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Martin Spott said: I got a short reply from them several weeks ago after pointing out that they were using an old version of FGFS. They told me they were not interested in upgrading because they didn't want to track the changes between 0.9.2 and 0.9.3, That's understandable but I would think they could have built it with thread support. The lighting bug is just a little annoying. As I type this I just remembered that you can force a lighting update with F4 (not 100% sure that works in 0.92, but it's worth a try). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Stepping and other inquisitions
Hello everyone, I'm working on a simulation project using a simulink model. Currently, I'm running an interface using the Aerosim blockset for matlab/simulink, but the program steps/chops, especially when the sun/moon position is updated (and when other info is output to the cmd window). I'm currently running both on a single computer, but this computer is a pretty high-end machine. So the question really is: can I stop those updates from occuring, or should I just try using a network with 2 computers? Another thing i've seen is the fact that after a minute of running my simulation, the simulation suddenly turns to night. Can anyone tell me why this is? and how can I stop it from occuring? One last thing: there is a command to do not advance time of day (--enable-clock-freeze) and if i've read the documentation correctly, this should keep the time of day constant while letting the simulation run, right? But when I go and set that - it pauses the simulation and i can not do anything. Do i have the wrong idea about this? Thanks Josh Joshua William Keane George Washington University Graduate Student Vehicle Dynamics Branch NASA Langley Research Center Hampton, VA 23681 Mail Stop 153 Phone: (757) 864-9636 Fax: (757) 864-7722 Email: [EMAIL PROTECTED] Office: Bldg 1192C, Room 159 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Joshua W. Keane said: Hello everyone, I'm working on a simulation project using a simulink model. Currently, I'm running an interface using the Aerosim blockset for matlab/simulink, but the program steps/chops, especially when the sun/moon position is updated (and when other info is output to the cmd window). I'm currently running both on a single computer, but this computer is a pretty high-end machine. So the question really is: can I stop those updates from occuring, or should I just try using a network with 2 computers? Another thing i've seen is the fact that after a minute of running my simulation, the simulation suddenly turns to night. Can anyone tell me why this is? and how can I stop it from occuring? One last thing: there is a command to do not advance time of day (--enable-clock-freeze) and if i've read the documentation correctly, this should keep the time of day constant while letting the simulation run, right? But when I go and set that - it pauses the simulation and i can not do anything. Do i have the wrong idea about this? I would guess that the effect you are seeing is actually from loading scenery data. Have you built flightgear configured --with-threads? The turning to night sounds like an old bug that has been fixed in CVS. My guess is that the --enable-clock-freeze issue you describe is a bug. Same thing happens here. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
