Re: [Flightgear-devel] Fwd: fg-home on windows and mac
-Original Message- From: Jacob Burbach [mailto:jmburb...@gmail.com] Sent: 08 October 2009 04:08 To: FlightGear developers discussions Subject: [Flightgear-devel] Fwd: fg-home on windows and mac In Linux the users flightgear directory is at /home/username/.fgfs. As I don't have a windows pc and haven't yet tried flightgear on my mac, I wonder if someone can enlighten me to the path for the users directory on those systems. In Windows? I'm not sure exactly what you are asking, or indeed why! FG puts its user stuff here: C:\Documents and Settings\username\Application Data\flightgear.org But you can put the FG exec and data anywhere you like. Vivian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Terrascenery.googlecode.com question
I see that terrascenery.googlecode.com includes a Models/ directory. If I leave this as is, does this directory get searched for models or do I need to copy this over the top of $FGROOT/data/Models/ Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] 3D Clouds update
On Wed, Oct 07, 2009 at 09:17:55PM +, Stuart Buchanan wrote: Unfortunately the 3D cloud performance seems to be very graphics-card specific. My card is a couple of years old, but doesn't seem to have the same problems. I am curious as to what your graphics card is. It would be nice if we could get an idea of which cards work well - and those that that have problems so they could be addressed. -- James Treacy tre...@debian.org -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrascenery.googlecode.com question
Curtis Olson wrote: [-- multipart/alternative, Encoding 7bit, 2 Zeilen --] [-- text/plain, Encoding 7bit, Zeichensatz: ISO-8859-1, 10 Zeilen --] I see that terrascenery.googlecode.com includes a Models/ directory. If I leave this as is, does this directory get searched for models or do I need to copy this over the top of $FGROOT/data/Models/ http://mapserver.flightgear.org/git/gitweb.pl?p=flightgear;a=commit;h=82a68740f196e57f7dca155ba8fd88bbc94466c4 Just added recently, requires: --prop:/sim/paths/use-custom-scenery-data=true Many thanks to Durk ! This actually allows users of TerraSync/SVN to get the most current Shared Models together with the respective Scenery tiles. I'm just right now testing the patch against TerraSync to pull this directory as well. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New route manager?
Are there instructions for the new route mgr? The new version in CVS doesn't not work like before. I added two waypoints, but it just flies a hdg of 0 and doesn't track to the next waypoint any more ... ??? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrascenery.googlecode.com question
Thanks Martin, that's a handy option. Curt. On Thu, Oct 8, 2009 at 8:58 AM, Martin Spott wrote: Curtis Olson wrote: [-- multipart/alternative, Encoding 7bit, 2 Zeilen --] [-- text/plain, Encoding 7bit, Zeichensatz: ISO-8859-1, 10 Zeilen --] I see that terrascenery.googlecode.com includes a Models/ directory. If I leave this as is, does this directory get searched for models or do I need to copy this over the top of $FGROOT/data/Models/ http://mapserver.flightgear.org/git/gitweb.pl?p=flightgear;a=commit;h=82a68740f196e57f7dca155ba8fd88bbc94466c4 Just added recently, requires: --prop:/sim/paths/use-custom-scenery-data=true Many thanks to Durk ! This actually allows users of TerraSync/SVN to get the most current Shared Models together with the respective Scenery tiles. I'm just right now testing the patch against TerraSync to pull this directory as well. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: fg-home on windows and mac
on Windows, it's the environment variable %APPDATA% which maps to what Vivian said on 2k and XP. On Vista (and 7 I think), it maps to user/appdata/roaming/flightgear.org On Thu, Oct 8, 2009 at 3:30 AM, Vivian Meazza vivian.mea...@lineone.netwrote: -Original Message- From: Jacob Burbach [mailto:jmburb...@gmail.com] Sent: 08 October 2009 04:08 To: FlightGear developers discussions Subject: [Flightgear-devel] Fwd: fg-home on windows and mac In Linux the users flightgear directory is at /home/username/.fgfs. As I don't have a windows pc and haven't yet tried flightgear on my mac, I wonder if someone can enlighten me to the path for the users directory on those systems. In Windows? I'm not sure exactly what you are asking, or indeed why! FG puts its user stuff here: C:\Documents and Settings\username\Application Data\flightgear.org But you can put the FG exec and data anywhere you like. Vivian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On 8 Oct 2009, at 15:17, Curtis Olson wrote: Are there instructions for the new route mgr? The new version in CVS doesn't not work like before. I added two waypoints, but it just flies a hdg of 0 and doesn't track to the next waypoint any more ... ??? http://wiki.flightgear.org/index.php/Route_Manager Is the current instructions, feedback is welcomed. The key thing you are probably missing is the 'activation' step, and specifying departure and destination airports. It's a couple more steps than previously - though I do what I can to initialise the values based on current location. In the future I'd like to make more fields mandatory - activation will then also be equivalent with filing a flight plan with the ATC system, whether in the form of AI, or automatically submitting your plan to a human MP controller (who would no doubt be very happy to receive your intentions...). However I realise there is an accuracy / patience trade-off here, since many people don't want to enter an alternate airport or cruise speed. There are some other ways the UX could work, depending on your requirements - for example I could change the code not to require a departure airport, and instead define wp0 as the current location in that case - and I could remove the requirement to have a destination at all. At that point the only different as compared to the previous UX would be the 'activate' step. In terms of IFR flight planning, though, the closer the dialog resembles an IFR paper plan. the happier I would be. Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: fg-home on windows and mac
Of course, I made a mistake it's users/user_name/appdata/roaming/ flightgear.org %APPDATA% is what you want to use in scripts, etc. Cheers, Nic On Thu, Oct 8, 2009 at 10:54 AM, Nicolas Quijano nquij...@gmail.com wrote: on Windows, it's the environment variable %APPDATA% which maps to what Vivian said on 2k and XP. On Vista (and 7 I think), it maps to user/appdata/roaming/flightgear.org On Thu, Oct 8, 2009 at 3:30 AM, Vivian Meazza vivian.mea...@lineone.netwrote: -Original Message- From: Jacob Burbach [mailto:jmburb...@gmail.com] Sent: 08 October 2009 04:08 To: FlightGear developers discussions Subject: [Flightgear-devel] Fwd: fg-home on windows and mac In Linux the users flightgear directory is at /home/username/.fgfs. As I don't have a windows pc and haven't yet tried flightgear on my mac, I wonder if someone can enlighten me to the path for the users directory on those systems. In Windows? I'm not sure exactly what you are asking, or indeed why! FG puts its user stuff here: C:\Documents and Settings\username\Application Data\flightgear.org But you can put the FG exec and data anywhere you like. Vivian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Exposing a property over MP
Related to the new route-manager: I could very easily define a string property which contains a plain text summary of the filed flight-plan. What is the magic required to expose that string (which be 200 or 400 bytes, I guess, depending on how many waypoints are in the route) over MP, so that the ATC 'aircraft' could see them? Is there an 'event' channel in MP, to deal with properties which change infrequently? (Compared to position/velocity/surface positions/ etc) Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On Thu, Oct 8, 2009 at 10:05 AM, James Turner zakal...@mac.com wrote: On 8 Oct 2009, at 15:17, Curtis Olson wrote: Are there instructions for the new route mgr? The new version in CVS doesn't not work like before. I added two waypoints, but it just flies a hdg of 0 and doesn't track to the next waypoint any more ... ??? http://wiki.flightgear.org/index.php/Route_Manager Is the current instructions, feedback is welcomed. Ok, I started up in the alphajet for instance at KLAX (7L). I pulled up the new route manager dialog and it suggested CL02 H1 as the starting location. I set that to KLAX-7L for the start and typed in KPHX for the destination, KSLC for the alternate, cruising speed of 350kts, cruising altitude of 18,500. I then clicked Activate and it still inserted CL02-H1 for the first waypoint and that's it. I removed CL02 and clicked activate again, and this time it put KLAX-07 for the first way point and then put KPHX in twice. So I manually manipulated the list so it contained only one waypoint ... KPHX. Ok! So now the HUD read hdg=0.0 which means the autopilot is configured to fly a straight heading of 0 degrees north. What used to happen is the route manager would compute the heading to the target waypoint, and configure the autopilot to fly that heading. This part apparently doesn't happen any more .. at least not with the alphajet? I like the realism of the new system (assuming the glitches are ironed out). But the old system was designed to be simple and quick and ubiquitous ... it was available and worked for all aircraft assuming they had a reasonably tuned autopilot config and the aircraft author didn't go out of their way to disable it. The old system took 1 second to punch in a way point, and then the autopilot instantly took over and you were flying there. You could use F6 to toggle the heading hold on and off. Not a *realistic* system, but very convenient for some types of testing (or cheating). Is it possible to keep the old simple/easy system available and make the new route manager a new separate system? Right now I don't seem to be able to get the alphajet to navigate to Phoenix (or anywhere else) on it's own. I wasn't really intending to go to Phoenix today, I was just using that as an example. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On 8 Oct 2009, at 16:35, Curtis Olson wrote: Ok, I started up in the alphajet for instance at KLAX (7L). I pulled up the new route manager dialog and it suggested CL02 H1 as the starting location. I set that to KLAX-7L for the start and typed in KPHX for the destination, KSLC for the alternate, cruising speed of 350kts, cruising altitude of 18,500. I then clicked Activate and it still inserted CL02-H1 for the first waypoint and that's it. I removed CL02 and clicked activate again, and this time it put KLAX-07 for the first way point and then put KPHX in twice. So I manually manipulated the list so it contained only one waypoint ... KPHX. Ok! This is a straight bug, I'll look into it. If you are sitting at KLAX 7L, it's supposed to load up that airport and runway automatically. So now the HUD read hdg=0.0 which means the autopilot is configured to fly a straight heading of 0 degrees north. I suspect the HUD functionality is confused, I was unaware it even existed, again I'll take a look tonight. What used to happen is the route manager would compute the heading to the target waypoint, and configure the autopilot to fly that heading. This part apparently doesn't happen any more .. at least not with the alphajet? I like the realism of the new system (assuming the glitches are ironed out). But the old system was designed to be simple and quick and ubiquitous ... it was available and worked for all aircraft assuming they had a reasonably tuned autopilot config and the aircraft author didn't go out of their way to disable it. The old system took 1 second to punch in a way point, and then the autopilot instantly took over and you were flying there. You could use F6 to toggle the heading hold on and off. Not a *realistic* system, but very convenient for some types of testing (or cheating). Is it possible to keep the old simple/easy system available and make the new route manager a new separate system? There's a various things here - as the Wiki page notes, the key one is that the route manager *was* a sort of generic GPS thing that talked to the autopilot directly. That's a wretched setup which has caused all manner of horrible code in the aircraft that do want to model a real GPS or FMS device. For the quick things you want to do, your best choice is actually the new GPS code - search for a waypoint (of any kind) and hit 'DTO', and it'll do most of the rest. The catch is that the 'gps-slave' feature of navradio is currently abused, so just driving the CDI/HSI via the 'gps-slaved' toggle doesn't always work. Aircraft that have a 'real' GPS are generally working around the broken-ness in Nasal (eg, theB1900d). So, if you're in an aircraft that has the GPS instrument, and has a panel switching to select the NAV/GPS toggle, *and* I fix the implementation of the toggle, that will be a good solution. Of course, in that case, the route manager also works, because the GPS will talk to it seamlessly! What I could do, is expand the 'no-FMS/GPS' code in the route-manager, which, as you noted, is essentially an unrealistic feature, to drive some outputs for the autopilot. My main concern is to avoid complicating life for panel/aircraft developers who want to build the realistic solution, though. What I'd prefer, though, is to make the new GPS a default instrument, and fix the gps-nav-radio slave, so that it works in any aircraft. Then you can use the GPS for all the quick functions, and the route- manager can be for more realistic flight planning. As far as I can see, executing a DTO in a GPS is as quick as you need, but entirely realistic... Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: fg-home on windows and mac
Thanks guys. The reason for asking is that you can put nasal scripts in fg-home/Nasal, and they will be loaded only after the scripts in fg-root/Nasal have been loaded. It guarantees you will have access to all the flightgear nasal apis from your script at load time. Ok, so XP and prior should be C:\Documents And Settings\username\Application Data\flightgear.org and Vista and up would be C:\Users\username\appdata\roaming\flightgear.org. Is that right? I'm thinking Mac might be the same as on Linux, but will have to wait for someone to confirm that. thanks --Jacob -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrascenery.googlecode.com question
Martin Spott wrote: This actually allows users of TerraSync/SVN to get the most current Shared Models together with the respective Scenery tiles. I'm just right now testing the patch against TerraSync to pull this directory as well. BTW, another part of The Plan is to ship the Base Package distribution only with those models which are required for the 1x2 degree Scenery chunk (this selection could be automated quite easily), thus reducing the size of the Base Package download for those who'd just like to have a quick look at FlightGear. User who wish to fly a wider area could still, as before, load the 'SharedModels.tgz' alongside the World Scenery packages or via TerraSync/SVN - as soon as FlightGear has seen a software release that includes the recent Scenery-related changes. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On Thu, 8 Oct 2009, James Turner wrote: Related to the new route-manager: I could very easily define a string property which contains a plain text summary of the filed flight-plan. What is the magic required to expose that string (which be 200 or 400 bytes, I guess, depending on how many waypoints are in the route) over MP, so that the ATC 'aircraft' could see them? The way the MP protocol is done now you really really do not want to do that by creating a new MP enabled string property and put the flight-plan in it. Not only is the string encoding horribly inefficient (a 32bit word per character) but it would also be sent in each and every packet. Is there an 'event' channel in MP, to deal with properties which change infrequently? (Compared to position/velocity/surface positions/ etc) No, there isn't but this might be time to create one. There is a rather complicated Nasal module for that kind of communication in Nasal/mp_broadcast.nas which utilizes a MP enabled string property (but send the relatively short empty string, , when nothing is going on. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On 8 Oct 2009, at 18:08, Anders Gidenstam wrote: The way the MP protocol is done now you really really do not want to do that by creating a new MP enabled string property and put the flight- plan in it. Not only is the string encoding horribly inefficient (a 32bit word per character) but it would also be sent in each and every packet. That sounds bad :) Is there an 'event' channel in MP, to deal with properties which change infrequently? (Compared to position/velocity/surface positions/ etc) No, there isn't but this might be time to create one. There is a rather complicated Nasal module for that kind of communication in Nasal/mp_broadcast.nas which utilizes a MP enabled string property (but send the relatively short empty string, , when nothing is going on. Eurgh, that sounds bad too. The 'usual' way to handle this would be to interleave the current update packets with 'event' packets, for properties that change more slowly. Using a sequence number for each event packet, and using the regular update packets to send the current sequence number, it's possible to make the event packet delivery reliable - without incurring the overhead (or complexity) of TCP. There's quite a lot of improvements that could be made to higher levels of MP, if arbitrary properties could be synchronised over MP :) Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
The way the MP protocol is done now you really really do not want to do that by creating a new MP enabled string property and put the flight-plan in it. Not only is the string encoding horribly inefficient (a 32bit word per character) but it would also be sent in each and every packet. Wow, that's really bad, why are strings being encoded with 32 bits per character exactly? --Jacob -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On Thu, 8 Oct 2009, James Turner wrote: That sounds bad :) It is, but in my experience there is no core developer feeling particularly responsible for the MP subsystem - most of the few patches that has been submitted in the past years have disappeared into the mailing list archive without (re)action. Eurgh, that sounds bad too. Well, it isn't ideal but it works for my purposes - without breaking MP compatibility and without me having to spend a large effort on developing something reasonable and more complete and then try for ages to get it committed to the code. These days I don't have time to do significant development, anyway, with work + commuting taking about 12 hours out of every day. The 'usual' way to handle this would be to interleave the current update packets with 'event' packets, for properties that change more slowly. Using a sequence number for each event packet, and using the regular update packets to send the current sequence number, it's possible to make the event packet delivery reliable - without incurring the overhead (or complexity) of TCP. Well, I would rather try to reduce what we send and mostly only send property values when they have changed. Currently every packet contains all (active) MP enabled properties - and many of them are constant or change very seldom. In that model a string property that rarely changes would not be a huge problem. Perhaps some type of publish-subscribe model could also be useful - so the receivers only receive the properties they care about (usually position and velocities and those driving external animations if within visual distance). Of course, this adds up to a rather sophisticated protocol so if some suitable existing middleware could be found that might be more preferable than trying to go our own way (certainly if one considers the current level of activity in this area:). There's quite a lot of improvements that could be made to higher levels of MP, if arbitrary properties could be synchronised over MP :) Yes, indeed. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
Erm, I just updated CVS, but my route manager dialog looks like the same. Is that correct? BTW, I just updated source, so I think that's the problem ;) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On 8 Oct 2009, at 20:53, Victhor Foster wrote: Erm, I just updated CVS, but my route manager dialog looks like the same. Is that correct? BTW, I just updated source, so I think that's the problem ;) Correct - you need to update the data package as well - and in general that's going to be true for the next little while, as the C++ and GUI features will be developing in parallel. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
James Turner wrote: There's quite a lot of improvements that could be made to higher levels of MP, if arbitrary properties could be synchronised over MP :) As far as _I_ remember, the current state of the protocol was _not_ designed for having everyone dump arbitrary data to the crowd but instead to allow for synchronization of positions, velocities and accelerations at reduced latency even over low-bandwidth lines. The current MP protocol is probably not perfect, but I think it still does quite a good job at its intended purpose. I remember running MP over a 64 kBit's ISDN line at satisfactory performance. If bandwidth is not a matter, then you'd probably want to jump on the HLA train and join the CERTI/VirtualAir effort. They're offering everything like subscribing to attributes and the such yet I have to state that reduced bandwidth footprint, compared to the current state, would be beneficial to have in CERTI ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
The problem is, CVS takes more than 30 minutes just to scan the directories, and this causes my internet connection to stop working for the meantime. When it starts the actual checkout process, the connection works again. On 8 Oct 2009, at 20:53, Victhor Foster wrote: Erm, I just updated CVS, but my route manager dialog looks like the same. Is that correct? BTW, I just updated source, so I think that's the problem ;) Correct - you need to update the data package as well - and in general that's going to be true for the next little while, as the C++ and GUI features will be developing in parallel. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
Anders Gidenstam wrote On Thu, 8 Oct 2009, James Turner wrote: That sounds bad :) It is, but in my experience there is no core developer feeling particularly responsible for the MP subsystem - most of the few patches that has been submitted in the past years have disappeared into the mailing list archive without (re)action. Eurgh, that sounds bad too. Well, it isn't ideal but it works for my purposes - without breaking MP compatibility and without me having to spend a large effort on developing something reasonable and more complete and then try for ages to get it committed to the code. These days I don't have time to do significant development, anyway, with work + commuting taking about 12 hours out of every day. The 'usual' way to handle this would be to interleave the current update packets with 'event' packets, for properties that change more slowly. Using a sequence number for each event packet, and using the regular update packets to send the current sequence number, it's possible to make the event packet delivery reliable - without incurring the overhead (or complexity) of TCP. Well, I would rather try to reduce what we send and mostly only send property values when they have changed. Currently every packet contains all (active) MP enabled properties - and many of them are constant or change very seldom. In that model a string property that rarely changes would not be a huge problem. Perhaps some type of publish-subscribe model could also be useful - so the receivers only receive the properties they care about (usually position and velocities and those driving external animations if within visual distance). Of course, this adds up to a rather sophisticated protocol so if some suitable existing middleware could be found that might be more preferable than trying to go our own way (certainly if one considers the current level of activity in this area:). There's quite a lot of improvements that could be made to higher levels of MP, if arbitrary properties could be synchronised over MP :) Yes, indeed. Way back in the early iterations of MP we had 2 sorts of messages - those which were transmitted on every cycle, and those which were transmitted on change of data. The trouble with that is with clients joining and leaving, it is hard to ensure that the clients are up-to-date. So you need to re- transmit on clients joining, which means triggering the originating client etc. etc. I think for that reason it was abandoned. It's just easier and more reliable to transmit everything all the time. And actually, the end result in data transmitted terms turns out to be not that different. Vivian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On 8 Oct 2009, at 21:37, Vivian Meazza wrote: Way back in the early iterations of MP we had 2 sorts of messages - those which were transmitted on every cycle, and those which were transmitted on change of data. The trouble with that is with clients joining and leaving, it is hard to ensure that the clients are up-to-date. So you need to re- transmit on clients joining, which means triggering the originating client etc. etc. I think for that reason it was abandoned. It's just easier and more reliable to transmit everything all the time. And actually, the end result in data transmitted terms turns out to be not that different. Easier certainly - but I think that was a bad tradeoff in the longer term. Sure, new clients will need to do more synchronize state, but potentially a lot of infrequently changing data can be removed from the regular updates, making them smaller too - while allowing, as everyone seems to agree, richer and easier MP interaction. As simple as possible is a good motto, but the current system seems a bit too simple. Of course, it does work - and I've got enough other FG projects that someone else can worry about this, for the moment. I'd be happy to share what I know about mixed reliable/best-effort real time networking, but it's not exactly much :) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On Thu, 8 Oct 2009, Vivian Meazza wrote: Way back in the early iterations of MP we had 2 sorts of messages - those which were transmitted on every cycle, and those which were transmitted on change of data. The trouble with that is with clients joining and leaving, it is hard to ensure that the clients are up-to-date. So you need to re- transmit on clients joining, which means triggering the originating client etc. etc. I think for that reason it was abandoned. It's just easier and more reliable to transmit everything all the time. And actually, the end result in data transmitted terms turns out to be not that different. Yes, that is one issue. The approach I aimed for the last time I tried to mess with the MP subsystem was to send properties on change (perhaps repeated Y times) and every X seconds (to update newly joined users and cover lost packets). That seemed to be simple enough that it could even be backwards compatible - but unfortunately it caused occasional failures in the property interpolation code on the receiving side that I didn't manage to sort out. Going in that direction could be a feasible way to reduce the bandwidth consumption, though. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On 8 Oct 2009, at 21:54, Anders Gidenstam wrote: Going in that direction could be a feasible way to reduce the bandwidth consumption, though. One other observation - there's several unused SGProperty flags (besides ARCHIVABLE) - it might make sense to add a 'shared' or 'published' flag, to allow properties to opt-in to being sent this way. Then the MP code 'just' has to search the tree (or keep an index) of such properties, listen for changes to them, and re-send them at some low rate (maybe send one in each regular packet, so it might take a minute to receive them all...) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shader menu proposal
syd adams wrote: I've made 2 versions of a shader menu dialog , rather than manage them from the property browser. Is (one ) of them worth commiting ? Another option that would be nice is a random vegetation density-factor property that could be set with a slider. That is , the density property could be 0-1 , and the material.xml densities would be multiplied by the density factor property... Any opinions ? Cheers Hi Syd, You asked for opinions, so here are mine. Thanks for taking the time to look at this - I think improving out general UI is a very good thing. It's far too easy for us old-hands to get used to some of the less usable aspects of the current UI. I'm in two minds as to whether I like the idea of splitting the rendering dialog. To be honest, the difference between shader effects, and, say, Particles will be lost on most users. However, the current dialog would benefit from being split : - How about seperating the Display Options from Rendering Options: Display Options - Frame rate - Chat messages - View Name Popup (from the Active Views dialog) - 2D Panel (currently under it's own menu, which is a bit inconsistent) - HUD (Not currently displayed as a menu item) Rendering Options - Everything else from the current Rendering Options - Shader Effects - 3D cloud settings. FWIW: I think the shader dialog as it stands is a bit confusing as the Enable Effects checkbox has no effect on 3D clouds (though I've heard that Tim is planning to integrate it). There are also a couple of minor UI tidy-up things as well, but they can wait. -Stuart -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On 8 Oct 2009, at 21:09, Victhor Foster wrote: The problem is, CVS takes more than 30 minutes just to scan the directories, and this causes my internet connection to stop working for the meantime. When it starts the actual checkout process, the connection works again. In general, you only need to update the gui/dialogs dir - which should be very quick. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On 8 Oct 2009, at 16:35, Curtis Olson wrote: Ok, I started up in the alphajet for instance at KLAX (7L). I pulled up the new route manager dialog and it suggested CL02 H1 as the starting location. I set that to KLAX-7L for the start and typed in KPHX for the destination, KSLC for the alternate, cruising speed of 350kts, cruising altitude of 18,500. I then clicked Activate and it still inserted CL02-H1 for the first waypoint and that's it. I removed CL02 and clicked activate again, and this time it put KLAX-07 for the first way point and then put KPHX in twice. So I manually manipulated the list so it contained only one waypoint ... KPHX. Ok! Turns out CL02 is a heliport either in, or very close, to KLAX. So this was a feature! What's needed is really aircraft type information, but in the short term I'm going to add some configuration properties to allow seaports and heliports to be excluded (by default) from route-manager and GPS searches. The other thing, as you found, is that editing active routes behaves oddly. For the moment, it's best to avoid editing an active route, but obviously this needs to be supported; it just raises headaches and potential edge cases in the GPS code. Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On Thu, 2009-10-08 at 22:45 +0100, James Turner wrote: I've also noticed that if I put a Altitude constraint (ie: @alt) the route manager always shows 0ft. It seems to always get the altitude from the NAV database, not what I enter. S. On 8 Oct 2009, at 16:35, Curtis Olson wrote: Ok, I started up in the alphajet for instance at KLAX (7L). I pulled up the new route manager dialog and it suggested CL02 H1 as the starting location. I set that to KLAX-7L for the start and typed in KPHX for the destination, KSLC for the alternate, cruising speed of 350kts, cruising altitude of 18,500. I then clicked Activate and it still inserted CL02-H1 for the first waypoint and that's it. I removed CL02 and clicked activate again, and this time it put KLAX-07 for the first way point and then put KPHX in twice. So I manually manipulated the list so it contained only one waypoint ... KPHX. Ok! Turns out CL02 is a heliport either in, or very close, to KLAX. So this was a feature! What's needed is really aircraft type information, but in the short term I'm going to add some configuration properties to allow seaports and heliports to be excluded (by default) from route-manager and GPS searches. The other thing, as you found, is that editing active routes behaves oddly. For the moment, it's best to avoid editing an active route, but obviously this needs to be supported; it just raises headaches and potential edge cases in the GPS code. Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
James wrote -Original Message- From: James Turner [mailto:zakal...@mac.com] Sent: 08 October 2009 22:06 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Exposing a property over MP On 8 Oct 2009, at 21:54, Anders Gidenstam wrote: Going in that direction could be a feasible way to reduce the bandwidth consumption, though. One other observation - there's several unused SGProperty flags (besides ARCHIVABLE) - it might make sense to add a 'shared' or 'published' flag, to allow properties to opt-in to being sent this way. Then the MP code 'just' has to search the tree (or keep an index) of such properties, listen for changes to them, and re-send them at some low rate (maybe send one in each regular packet, so it might take a minute to receive them all...) This, or something very like it, is a long outstanding proposal that never quite made it. No one got a round tuit for it I guess. That said, a minute delay on event-driven properties is probably too much. Vivian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On 8 Oct 2009, at 23:05, Scott Hamilton wrote: I've also noticed that if I put a Altitude constraint (ie: @alt) the route manager always shows 0ft. It seems to always get the altitude from the NAV database, not what I enter. Altitude constraints are a mess - in the short term, they are best avoided. Keep in mind the GPS code doesn't really do proper vertical navigation - it computes some data like the altitude change and climb/ descent rate for a leg, but I'm not sure if any real aircraft is driving the VNAV mode of an autopilot from it. It's definitely something I will look at, but it's tied up with some other features. At some point I want to support GPS precision approaches and then obviously all the VNAV logic will need to be properly cleaned up - right now it's been copied mostly unchanged from the original gps code. As always, user stories are good - what do you expect the behaviour to be from the route-manager? Just to track valid altitudes? For the autopilot VNAV to follow the altitude profile exactly? Something in between? This is also tied up with accurate enroute time calculations and calculating top-of-climb / top-of-descent information, it's quite a mess to unpick. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Exposing a property over MP
On 8 Oct 2009, at 23:05, Vivian Meazza wrote: This, or something very like it, is a long outstanding proposal that never quite made it. No one got a round tuit for it I guess. That said, a minute delay on event-driven properties is probably too much. Well if it's 30 seconds, I think a 30 seconds 'synchronising state with MP server' would be fine for most people - especially if it happens in parallel with scenery loading. If it's more like two minutes, then it certainly needs some thought, but I'd rather have a slightly sub-optimal UX for this case, but support event-drive props. (Especially if I want to centralise ATIS / active runways / navaid idents in the future, as John Denker has suggested before) Another option is for the MP server to cache all the props from each client, and allow clients to request a 'burst' of the cached state right after they connect, but before the normal updates start. I don't know how the MP server-server tieing is implemented, but I suspect such a cache would also be valuable in proxying event-driven props between servers. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shader menu proposal
Thanks for the input. I admit I was uncertain about moving the 3d clouds there , but thought I'd heard it mentioned that the trees and 3d clouds were going to be moved into the effects... The reason I thought this needed to be changed was the growing length of the rendering dialog , but my fix may not be the best. Your suggestion of a Display and Rendering options sounds good to me Cheers -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New route manager?
On Thu, Oct 8, 2009 at 10:54 AM, James Turner zakal...@mac.com wrote: This is a straight bug, I'll look into it. If you are sitting at KLAX 7L, it's supposed to load up that airport and runway automatically. Ok, thanks for looking into it. As you suggest, filtering out heliports and seaports by default might be worth considering. I suspect the HUD functionality is confused, I was unaware it even existed, again I'll take a look tonight. What the original route manager did was constantly compute the heading to the next waypoint and dump that value into /autopilot/settings/true-heading-deg Then the autopilot could be activated in true-heading-follow mode and you would fly right to the destination. I just did a cvs update and I see a number of fixes, but I'm still confused about how to make the autopilot follow what the new route manager is doing? I opened up the gps dialog box and checked NAV Slave, but when I put the autopilot into NAV1 CDI Course follow mode, it flew a heading of 40 degrees where the proper heading would be closer to 274. Is there still a missing connection in the code, or is the missing connection in my head? :-) Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shader menu proposal
The new shader dialog looks good, but it doesn't want to enable the water shader. And I think it's not turning on the crop shaders as well. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shader menu proposal
Did you update the Effects folder ? It's necessary for the changes to work Cheers, Nic On Thu, Oct 8, 2009 at 8:12 PM, Victhor Foster victhor.fos...@gmail.comwrote: The new shader dialog looks good, but it doesn't want to enable the water shader. And I think it's not turning on the crop shaders as well. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shader menu proposal
you neede to update the Effects folder On Thu, Oct 8, 2009 at 5:12 PM, Victhor Foster victhor.fos...@gmail.comwrote: The new shader dialog looks good, but it doesn't want to enable the water shader. And I think it's not turning on the crop shaders as well. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shader menu proposal
Ok, thanks. you neede to update the Effects folder On Thu, Oct 8, 2009 at 5:12 PM, Victhor Foster victhor.fos...@gmail.com wrote: The new shader dialog looks good, but it doesn't want to enable the water shader. And I think it's not turning on the crop shaders as well. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
