Re: [Flightgear-devel] fuel gauges ...
On Fri, February 6, 2009 5:39 am, syd adams wrote: Hello , Ok, I have everything in the data folder converted to /level-lbs. (The Concorde was a bit of a nightmare) ... :) If someone could commit the patch , I'm ready to commit the data ... I can update JSBSim.cxx in JSBSim/CVS tonight (if nobody beats me to it:). Someone else need to do the change in FlightGear/CVS, though. It is a small change so it shouldn't cause too much trouble the next time JSBSim in FlightGear is synchronized with JSBSim/CVS. Cheers, Anders -- Anders Gidenstam WWW: http://www.gidenstam.org -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fuel gauges ...
Anders Gidenstam wrote: On Fri, February 6, 2009 5:39 am, syd adams wrote: Hello , Ok, I have everything in the data folder converted to /level-lbs. (The Concorde was a bit of a nightmare) ... :) If someone could commit the patch , I'm ready to commit the data ... I can update JSBSim.cxx in JSBSim/CVS tonight (if nobody beats me to it:). Someone else need to do the change in FlightGear/CVS, though. It is a small change so it shouldn't cause too much trouble the next time JSBSim in FlightGear is synchronized with JSBSim/CVS. I'll sync JSBSim CVS and FlightGear today or tomorrow if you commit it to JSBSim CVS. Erik -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim sliding helicopters bug
Jon S. Berndt jonsber...@comcast.net wrote: The wheel slip angle, for instance, varies wildly in JSBSim when no filtering or other compensation is used: [...] If the forces are ramped down to zero below some threshold, the dynamics improve greatly: This one shows the nose wheel _velocity_ over a timespan, the other three diagrams are showing the slip _angle_. To draw a reasonable conclusion it would be interesting to see the same measurand, say the slip velocity for all of the involved cases and not only for the nose wheel but for for the main gear as well. BUT, basically, I'd say this is not the point at all - these are interesting theoretical approaches to the problem, but for the 'real' user who's getting veered off the apron while he is simply doing a proper run-up at a windy location, this is entirely irrelevant. So, I have to ask you: what is proper tire/ground reaction? With a few lines of code I've reduced the ground reactions artifacts for the f-16 to very small levels - and I really haven't optimized them, yet. They could maybe be improved even more. So what is the cost/benefit to adding more code to do gear modeling more precisely? How much would the user really notice the difference? If we model the ground reactions to such high fidelity, should we then also model the aero characteristics using the Navier Stokes equations? There are always tradeoffs in simulation. In the case of JSBSim, I am hoping to model ground reactions so that the end user is satisfied with the response. I'll tell you that quite a bunch of users is unsatisfied but many of them take the current situation as given because they didn't know that a proper solution had been available. So, please correct me if my conclusion is at fault: 1.) The current, unfortunate state of tire/ground reactions in JSBSim, the fact that FlightGear's default aircraft is slipping over the tarmac is _NOT_ caused by the fact that there's nobody around wo knew better as alledged by this posting of 2007-11-22: Jon S. Berndt j...@hal-pc.org wrote: Maybe it would help to talk to the CDM guys instead of the FDM guys. http://www.google.com/search?q=car-dynamics-model http://www.google.com/search?q=car-dynamics-model+nascar I reckon the car-dynamics guys have a pretty good model of static friction and quasi-static rolling friction. After all, that is their raison d'tre. Whatever they've got is surely more than good enough for our purposes. Yes. I have looked at car dynamics casually. It would be nice to get one of those guys onboard. As far as I can tell, this posting had been written _after_ a patch to implement proper simulation of tire/ground reactions had been submitted to JSBSim. 2.) The current state is also _NOT_ a question of having a budget to pay someone doing rocket science - 2009-02-03: Jon S. Berndt jonsber...@comcast.net wrote: * Jon S. Berndt -- Tuesday 03 February 2009: It's a tough problem, [...[ Maybe we should hire a rocket scientist? :-] [...] With our *huge* budget? :-) NO, it's simply due to the fact that the FlightGear project decided to tie themselves to the development goals of JSBSim of which the 'project steering committee' decided against adding proper ground reaction code - which had been availale for free - for the sake of a smaller line count. FlightGear is suffering from a 'political' decision which has been made at JSBsim. which brings me back to - oh - my own words, written last month: Overall, I think some day the crowd should start making up their mind about wether relying on an externally maintained FDM is still the way to go. Developing a copy of the FDM _in_ FlightGear might return a much higher benefit at reduced effort. Just for the sake of completeness: Think of a scenario on the carrier, you're approaching the catapult from behind oh, too far, you're idling the engine, letting the wind blow you backwards while you're slowly manoeuvering your aircraft right into the catapult position solely by nose wheel steering. That's what I call proper simulation of tire ground reactions. FlightGear _could_ do that - it they didn't depend decisions made at JSBSim. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] The use of models from other formats
Ian, Those boxes import nicely into AC3D here. How about a real challenge? Vivian -Original Message- From: FGD ML [mailto:fg...@pomf.net] Sent: 06 February 2009 10:18 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] The use of models from other formats 2009/2/6 Arnt Karlsen a...@c2i.net On Thu, 5 Feb 2009 11:07:45 +, FGD wrote in message 9dfda0650902050307n513838b7x6f06bca893b2b...@mail.gmail.com: 2009/2/5 Jon Stockill li...@stockill.net Tim Moore wrote: I don't know what to say about AC3D, but Blender has such a large community that I doubt you need to be suffering in isolation this way. Surely this is a known problem with a workaround? Before people spend too much time on that if you have a small sample model that you could upload somewhere I'd be happy to try and work through the conversion process in blender to determine what's required to get acceptable results - once you're happy it *can* be converted properly we can worry about how to achieve that on your platform. Yes a link to some basic cubes was in my previous message. ..??? I could not find that link. Lost message? No, it's me being a newbie to mailing lists, I had not spotted that Curtis wrote to me direct instead of using the reply to and hence the mailer replied to him direct thus stopping the reply message going to the list. Oh well! ;O) (I'll try and learn up some on all that for that in future, it's a bit confusing on only day two) Here's the bit you would have needed! Some people on the forum made this request last night. So I had a mate of mine upload these simple 1mtr boxes so anyone could have some samples to play with. They are only approx 1 metre I just threw them together, I wasn't being micro precise, so don't use them to measure anything dimensionally! LINK http://www.aeroshop3d.com/Quickstart/DocLib/lwo%20BorgBoxes.zip In the filenames; T indicates the model is of triangles, otherwise they are of quads, DS is for double sided otherwise they are single sided. They were made using the current version of lightwave modeller which I routinely have available which is 9.5. On a side note actually, and to the rest of the list, after some more in depth reading, I don't much like the look of Collada as I had felt earlier, it looked a bit too good to be true then and now it seems it really is too good to be true! It would be very likely to become highly problematic in use I suspect. -- Cheers, Ian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim sliding helicopters bug
From: Martin Spott [mailto:martin.sp...@mgras.net] This one shows the nose wheel _velocity_ over a timespan, the other three diagrams are showing the slip _angle_. To draw a reasonable conclusion it would be interesting to see the same measurand, say the slip velocity for all of the involved cases and not only for the nose wheel but for for the main gear as well. Oh, blast it. I printed the wrong chart. Well, it was very late ... :-( BUT, basically, I'd say this is not the point at all - these are interesting theoretical approaches to the problem, but for the 'real' user who's getting veered off the apron while he is simply doing a proper run-up at a windy location, this is entirely irrelevant. If this is truly the case, and if it is due to a gear modeling fidelity issue, then I agree. But, the kind of problem you describe would be a different issue. Since wind effects are only ramped in as velocity increases, the example you describe above should not happen with JSBSim. I'll tell you that quite a bunch of users is unsatisfied but many of them take the current situation as given because they didn't know that a proper solution had been available. It's vitally important that we see such problem reports. I've helped people tune their gear models successfully. If I don't see the error reports, I can't help. There is a bug reporting page at the JSBSim web site that should be used for this: http://sourceforge.net/tracker/?atid=119399group_id=19399func=browse You may have to try loading this page twice, since it seems SourceForge is having problems with its web site, periodically. Just for the sake of completeness: Think of a scenario on the carrier, you're approaching the catapult from behind oh, too far, you're idling the engine, letting the wind blow you backwards while you're slowly manoeuvering your aircraft right into the catapult position solely by nose wheel steering. That's what I call proper simulation of tire ground reactions. FlightGear _could_ do that - it they didn't depend decisions made at JSBSim. Cheers, Martin. JSBSim also does not (quite yet) do blade element modeling, so it's not easy to do a proper snap roll. Nor do we model multiple articulated landing gear struts. Nor do we ... As with any FDM, there are caveats and limitations. Your last paragraph is a good example of something I hadn't considered - that one would actually want to use the wind to do something while at almost zero velocity on the ground. I can look into that. Apart from that, do you have a specific proposal in mind? We should move this to a new thread. Jon -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
Vivian, apparently, the challenge is to start AC3D under Vista 64 -Fred - Vivian Meazza a écrit : Ian, Those boxes import nicely into AC3D here. How about a real challenge? Vivian -Original Message- From: FGD ML [mailto:fg...@pomf.net] Sent: 06 February 2009 10:18 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] The use of models from other formats 2009/2/6 Arnt Karlsen a...@c2i.net On Thu, 5 Feb 2009 11:07:45 +, FGD wrote in message 9dfda0650902050307n513838b7x6f06bca893b2b...@mail.gmail.com : 2009/2/5 Jon Stockill li...@stockill.net Tim Moore wrote: I don't know what to say about AC3D, but Blender has such a large community that I doubt you need to be suffering in isolation this way. Surely this is a known problem with a workaround? Before people spend too much time on that if you have a small sample model that you could upload somewhere I'd be happy to try and work through the conversion process in blender to determine what's required to get acceptable results - once you're happy it *can* be converted properly we can worry about how to achieve that on your platform. Yes a link to some basic cubes was in my previous message. ..??? I could not find that link. Lost message? No, it's me being a newbie to mailing lists, I had not spotted that Curtis wrote to me direct instead of using the reply to and hence the mailer replied to him direct thus stopping the reply message going to the list. Oh well! ;O) (I'll try and learn up some on all that for that in future, it's a bit confusing on only day two) Here's the bit you would have needed! Some people on the forum made this request last night. So I had a mate of mine upload these simple 1mtr boxes so anyone could have some samples to play with. They are only approx 1 metre I just threw them together, I wasn't being micro precise, so don't use them to measure anything dimensionally! LINK In the filenames; T indicates the model is of triangles, otherwise they are of quads, DS is for double sided otherwise they are single sided. They were made using the current version of lightwave modeller which I routinely have available which is 9.5. On a side note actually, and to the rest of the list, after some more in depth reading, I don't much like the look of Collada as I had felt earlier, it looked a bit too good to be true then and now it seems it really is too good to be true! It would be very likely to become highly problematic in use I suspect. -- Cheers, Ian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Q: OpenGL version requirement for FlightGear 1.9.1
Michael, thanks. I am trying to run FG through a multi-display system using Chromium, which is an open source tool that replaces the OpenGL DLL to drive multiple displays without having to recompile FG. FG runs slowly with flickering and reports an error repeatedly about not finding glUseProgram. I suspect the repeated error reporting is causing the slow down and flickering. Also, I suspect that FG thinks it has OpenGL 2.0 support (thus the glUseProgram) when Chromium only supports upto 1.5. Anyway, if anyone has something definitive on FG's OpenGL min version requirements that would help. Best regards, --Dave On Thu, Feb 5, 2009 at 4:49 PM, Michael D. Smith mdsmi...@highland.netwrote: David L. Page wrote: What are the OpenGL version requirements for FlightGear 1.9.1? I haven't found a reference in FG documentation, yet. I have only seen specifications for the latest nVidia or ATI cards. Best regards, --Dave -- David L. Page Knoxville, Tennessee davidp...@ieee.org mailto:davidp...@ieee.org 865.607.8192 -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today- http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Hello David, I would say at least version 1.1 would be good, although I am not sure about older versions. I have 1.3 myself. -- Michael Smith mdsmi...@highland.net (mdsmith2) -- David L. Page Knoxville, Tennessee davidp...@ieee.org 865.607.8192 -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Q: OpenGL version requirement for FlightGear
David L. Page pag...@gmail.com wrote: I am trying to run FG through a multi-display system using Chromium, which is an open source tool that replaces the OpenGL DLL to drive multiple displays without having to recompile FG. Did you know that FlightGear is capable of driving different displays natively ? Please read FlightGear/docs-mini/README.multiscreen in the FlightGear source tree, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
Vivian Meazza wrote: Fred Vivian, apparently, the challenge is to start AC3D under Vista 64 -Fred - Vivian Meazza a écrit : Ian, Those boxes import nicely into AC3D here. How about a real challenge? PS there seems to be a workaround - here: http://www.inivis.com/forum/showthread.php?p=22957 Vivian I have verified the information from the link Vivian provided. Out of the box on Vista 64, Build 6001 SP1, AC3D *did* work. The DEP setting was as shown in this image (Turn on DEP for essential Windows programs...): http://www.rato.us/depset.png I verified that changing the setting to Turn on DEP for all programs... caused AC3D to fail as in the following image: http://www.rato.us/wdep.png I then verified that AC3D would again operate correctly after adding it as an exception. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
Reagan wrote Vivian Meazza wrote: Fred Vivian, apparently, the challenge is to start AC3D under Vista 64 -Fred - Vivian Meazza a écrit : Ian, Those boxes import nicely into AC3D here. How about a real challenge? PS there seems to be a workaround - here: http://www.inivis.com/forum/showthread.php?p=22957 Vivian I have verified the information from the link Vivian provided. Out of the box on Vista 64, Build 6001 SP1, AC3D *did* work. The DEP setting was as shown in this image (Turn on DEP for essential Windows programs...): http://www.rato.us/depset.png I verified that changing the setting to Turn on DEP for all programs... caused AC3D to fail as in the following image: http://www.rato.us/wdep.png I then verified that AC3D would again operate correctly after adding it as an exception. Thanks, Reagan. Is that problem solved? Vivian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] some hopefully helpful gdb core debug output
FlightGear wrote: hi, I am fg-torrents from the forums. I am trying to debug error in triangle intersect problem. Original thread here: http://www.flightgear.org/forums/viewtopic.php?f=2t=2824 I keep running into what looks like other issues causing fg to crash before triangle intersect occurs. I updated all my src today and am following the instructions provided by jester in the forum thread. So after applying the patch provided by jester and doing export FG_SIGFPE=1 then ulimit -c unlimited, I got something about jsbsim ftank or something, you can look at the thread. Now after todays src update I get the following output: (for reference ./configure --prefix=/home/user/fg-debug CFLAGS=-O0 -g CXXFLAGS=-O0 -g) This is a bit like whack-a-mole, but try again with the latest CVS or git version. When you send gdb output, it's helpful to know how you started the program and any interesting variable values. For instance, it would be helpful to know the value of _input.max() below. Tim $gdb fgfs core.24650 Core was generated by `./fgfs'. Program terminated with signal 8, Arithmetic exception. [New process 24650] [New process 24652] [New process 24653] [New process 24651] #0 0x00873b02 in Tape (this=0xb2b00f0, hud=0x87bd9f0, n=0xb2a27a0, x=320, y=240) at HUD_tape.cxx:67 67_odd_type = int(floorf(_input.max() + 0.5)) 1 ? true : false; (gdb) bt #0 0x00873b02 in Tape (this=0xb2b00f0, hud=0x87bd9f0, n=0xb2a27a0, x=320, y=240) at HUD_tape.cxx:67 #1 0x00868a50 in HUD::load (this=0x87bd9f0, file=0x125c040 Huds/NTPS.xml, x=320, y=240, level=0, inde...@0x7fff069b3610) at HUD.cxx:387 #2 0x00869ddd in HUD::init (this=0x87bd9f0) at HUD.cxx:137 #3 0x00ac88f8 in SGSubsystemGroup::init () #4 0x00ac88f8 in SGSubsystemGroup::init () #5 0x004469e0 in fgInitSubsystems () at fg_init.cxx:1682 #6 0x0042bf82 in fgIdleFunction () at main.cxx:928 #7 0x00486dc8 in fgOSMainLoop () at fg_os_osgviewer.cxx:177 #8 0x0042a388 in fgMainInit (argc=1, argv=0x7fff069b3e68) at main.cxx:1073 #9 0x0042981e in main (argc=1, argv=0x7fff069b3e68) at bootstrap.cxx:177 -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
Vivian Meazza wrote: Ian, Those boxes import nicely into AC3D here. How about a real challenge? No problem getting them into blender either. Jon -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
On Fri, Feb 6, 2009 at 4:15 PM, Jon Stockill li...@stockill.net wrote: Vivian Meazza wrote: Those boxes import nicely into AC3D here. How about a real challenge? No problem getting them into blender either. However when I tried to export textured lwo's to ac3d format in blender, the textures were lost. I might have been doing something wrong, though. FTR, the bug in the OSG lwo plugin has been fixed as of revision 9686. -- Csaba/Jester -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Q: OpenGL version requirement for FlightGear 1.9.1
Curt, Thanks. I haven't used the multi-screen functionality. Unfortunately, I don't think it will work for me. I have some special rendering needs that FG's multi-screen won't handle as I understand it. I need to override some OpenGL calls, which Chromium allows me to do. Unfortunately, Chromium doesn't support OpenGL 2.0 or higher, right now. --Dave -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim sliding helicopters bug
If this is truly the case, and if it is due to a gear modeling fidelity issue, then I agree. But, the kind of problem you describe would be a different issue. Since wind effects are only ramped in as velocity increases, the example you describe above should not happen with JSBSim. I just put the default Cessna at EDLN RWY 13 with parking brake applied, the wind is 11009KT. It took approx. three and a half minutes to let the aircraft slip backwards by the length of a main gear cover. Exactly. Given what was happening prior to the fix, this is pretty good. I think with some additional tweaking, this could be improved even more. But, I'm not sure what your point is, here? We should probably specify some requirements. How long should an aircraft stick at one spott? With what kind of tolerance? There is a long, huge, list of items that could be included in landing gear modeling and ground reactions. Anything from tire spin-up/wind-up to castering jitter, strut dynamics, etc. Obviously, we have to make some decisions about how far we want to go in modeling this or that feature. To this point, the focus has been on stability and control, aerodynamics, and such. I'm not opposed to improving the landing gear model. But, I'm not certain I hav e a good feel for how big of an annoyance this is among the larger user base. Consider this a solicitation for input! :-) My proposal is either to develop a copy of the FDM inside FlightGear and to focus primarily on FlightGear's needs (and to try getting a copy of the respective patch) or to have the changes applied to JSBSim's code tree and to later merge this into FlightGear. I don't think having a copy of JSBSim in FlightGear CVS for development purposes is a good idea. I do like the idea of more frequent synchs between JSBSim CVS and FlightGear CVS. But, JSBSim is used on a broader scale than FlightGear (OpenEaagles, for one, and many more ). I think that is a strength - not a weakness. I don't think it would be a good idea to split it up. You may not be aware of this, but the patch previously submitted years ago would not work at all any more. In fact, one of the problems with the patch was that even at that time, JSBSim was undergoing a restructuring. That made it especially difficult for the patch author. In order for the same approach to be applied at this time, one would have to essentially start over. Some of the parts might be applicable and usable, but I believe much of it would have to be rewritten. But, forget about the patch as it was. Even if we wanted to, there's no way it could be applied as-is, at this point. Also, your characterization of the lack of willingness to commit the changes as being due to a concern about line count is incorrect. That's a gross over-simplification, and implies a lack of concern or care about the work that I know went into creating the patch. Obviously, at some point, one has to weigh the amount of code added to address a specific problem. Is doubling the size of the codebase to address a single problem acceptable? Think of the implications for maintenance, comprehension, and documentation. There is a saying that the squeaky wheel gets the grease (although in this case maybe we need less grease!). If we could improve the gear model by adding two lines of code, I would have added that code years ago. If any fix doubles the size of the codebase, no, I'd be looking for a better way to address the problem. With anything in-between, it gets vague, and the rules become less strict. Let me say this, in closing. I've worked with some very heavy duty simulations over the past twenty+ years. Most (all?) of them are horribly incomprehensible for even experienced simulation engineers, let alone students. JSBSim has been complimented in the past because it is straightforward and fairly easy to understand the code, at least as far as the basic stuff goes. Some design choices have been made so far that not everyone agrees with. One of those areas is that landing gear is modeled only with enough fidelity to make it appear to users that the aircraft drives in a realistic manner. Where that is not the case, I need to see specific examples so we can address that. If we can address it with a small amount of code as is currently the case, that's an acceptable solution, in my eyes. If it turns out that we really cannot address any problems without a more serious solution, and the ground reactions are seen as plain-and-simple not plausible, and there is a huge outcry that this should be fixed because it is intolerable, then maybe we'd revisit a modification to our integation scheme to use RK4 and simultaneous solution of a set of equations. That would involve a long and painful surgery, though. It's not an easy thing to manage such a project, with some competing interests, and to keep users and developers happy and feeling good about their contributions
[Flightgear-devel] some hopefully helpful gdb core debug output
hi, I am fg-torrents from the forums. I am trying to debug error in triangle intersect problem. Original thread here: http://www.flightgear.org/forums/viewtopic.php?f=2t=2824 I keep running into what looks like other issues causing fg to crash before triangle intersect occurs. I updated all my src today and am following the instructions provided by jester in the forum thread. So after applying the patch provided by jester and doing export FG_SIGFPE=1 then ulimit -c unlimited, I got something about jsbsim ftank or something, you can look at the thread. Now after todays src update I get the following output: (for reference ./configure --prefix=/home/user/fg-debug CFLAGS=-O0 -g CXXFLAGS=-O0 -g) $gdb fgfs core.24650 Core was generated by `./fgfs'. Program terminated with signal 8, Arithmetic exception. [New process 24650] [New process 24652] [New process 24653] [New process 24651] #0 0x00873b02 in Tape (this=0xb2b00f0, hud=0x87bd9f0, n=0xb2a27a0, x=320, y=240) at HUD_tape.cxx:67 67 _odd_type = int(floorf(_input.max() + 0.5)) 1 ? true : false; (gdb) bt #0 0x00873b02 in Tape (this=0xb2b00f0, hud=0x87bd9f0, n=0xb2a27a0, x=320, y=240) at HUD_tape.cxx:67 #1 0x00868a50 in HUD::load (this=0x87bd9f0, file=0x125c040 Huds/NTPS.xml, x=320, y=240, level=0, inde...@0x7fff069b3610) at HUD.cxx:387 #2 0x00869ddd in HUD::init (this=0x87bd9f0) at HUD.cxx:137 #3 0x00ac88f8 in SGSubsystemGroup::init () #4 0x00ac88f8 in SGSubsystemGroup::init () #5 0x004469e0 in fgInitSubsystems () at fg_init.cxx:1682 #6 0x0042bf82 in fgIdleFunction () at main.cxx:928 #7 0x00486dc8 in fgOSMainLoop () at fg_os_osgviewer.cxx:177 #8 0x0042a388 in fgMainInit (argc=1, argv=0x7fff069b3e68) at main.cxx:1073 #9 0x0042981e in main (argc=1, argv=0x7fff069b3e68) at bootstrap.cxx:177 -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
2009/2/6 Vivian Meazza vivian.mea...@lineone.net Ian, Those boxes import nicely into AC3D here. How about a real challenge? Well sure they do; even I can make a box that behaves itself fairly well, for a box! For the real challenge I think you're supposed to be able to use it FG directly, as in without 3rd party interference! Apparently OSG supports .lwo and .x among a number of other formats, but right now, they just don't happen show up visually in FG if you want to do that, as far as anyone can tell. That is the mystery as I see it. FOr now it seems FG can only support .ac ahnd maybe 3ds, although I've not been able to do exhaustive testing. Presumably there was some testing done at some stage for all claimed formats being working as advertised when switching over to OSG? I don't have enough experience within FG to know where to look that up, but Iam guessing it must be archived somewhere? -- Cheers, Ian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Q: OpenGL version requirement for FlightGear 1.9.1
On Fri, Feb 6, 2009 at 8:01 AM, David L. Page wrote: Michael, thanks. I am trying to run FG through a multi-display system using Chromium, which is an open source tool that replaces the OpenGL DLL to drive multiple displays without having to recompile FG. FG runs slowly with flickering and reports an error repeatedly about not finding glUseProgram. I suspect the repeated error reporting is causing the slow down and flickering. Also, I suspect that FG thinks it has OpenGL 2.0 support (thus the glUseProgram) when Chromium only supports upto 1.5. Anyway, if anyone has something definitive on FG's OpenGL min version requirements that would help. Hi David, Depending on what you are trying to accomplish, FlightGear also has built in functionality to drive multiple displays and multiple windows from a single instance (as of v1.9.0). Look for the docs-mini/README.multiscreen for instructions and examples. Also you can beat this up with hardware and use something like the matrox triple-head-to-go, but even with that, you really want to use FlightGear's capabilities to setup multiple cameras, 1 for each monitor, so you can configure the right separation between the screens to account for the display borders. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
2009/2/6 Vivian Meazza vivian.mea...@lineone.net Reagan wrote Vivian Meazza wrote: Fred Vivian, apparently, the challenge is to start AC3D under Vista 64 -Fred - Vivian Meazza a écrit : Ian, Those boxes import nicely into AC3D here. How about a real challenge? PS there seems to be a workaround - here: http://www.inivis.com/forum/showthread.php?p=22957 Vivian I have verified the information from the link Vivian provided. Out of the box on Vista 64, Build 6001 SP1, AC3D *did* work. The DEP setting was as shown in this image (Turn on DEP for essential Windows programs...): http://www.rato.us/depset.png I verified that changing the setting to Turn on DEP for all programs... caused AC3D to fail as in the following image: http://www.rato.us/wdep.png I then verified that AC3D would again operate correctly after adding it as an exception. Thanks, Reagan. Is that problem solved? It might be OK on Vista, but I am running a workstation Standard version of Sever 2008 MS Windows Build 6001 with SP1 built in. It sure does not work out fine there. Later this year, once it is in production I and others are very likely to be switching to Windows7 and those sorts of fixes are even less likely to work in there, as quite a few rules in that one are changing (and although painful, the changes are decidedly for the greater good). Rather than adding 3rd party involvement I am primarily seeking to have the .lwo support work directly as it appears it should. I and a group of others already have a modeller that works fine, and somewhere between about 50 and 100 aircraft to set up for FG that are actively developed in .lwo format, we just can't get them to show up as we have been lead to understand they probably should. It's already going to be a long and complicated job if it had worked straight away. -- Cheers, Ian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] some hopefully helpful gdb core debug output
Csaba Halász wrote: On Fri, Feb 6, 2009 at 4:12 PM, Tim Moore timo...@redhat.com wrote: This is a bit like whack-a-mole, but try again with the latest CVS or git version. When you send gdb output, it's helpful to know how you started the program and any interesting variable values. For instance, it would be helpful to know the value of _input.max() below. This is the problem I reported in the mail thread [BUG] overflow in HUD_tape.cxx. Oh yeah, who needs a bug tracker :- Indeed, when you could have called your mail [PATCH] overflow in HUD_tape.cxx and had more immediate results :) Tim -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
Fred Vivian, apparently, the challenge is to start AC3D under Vista 64 -Fred - Vivian Meazza a écrit : Ian, Those boxes import nicely into AC3D here. How about a real challenge? ... snip ... Well, that might be a bridge too far, and it's a good reason for not migrating to Vista (of any variety). However, if Ian wants something converted, I'm sure we can oblige one way or another. Vivian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim sliding helicopters bug
Jon S. Berndt jonsber...@comcast.net wrote: From: Martin Spott [mailto:martin.sp...@mgras.net] BUT, basically, I'd say this is not the point at all - these are interesting theoretical approaches to the problem, but for the 'real' user who's getting veered off the apron while he is simply doing a proper run-up at a windy location, this is entirely irrelevant. If this is truly the case, and if it is due to a gear modeling fidelity issue, then I agree. But, the kind of problem you describe would be a different issue. Since wind effects are only ramped in as velocity increases, the example you describe above should not happen with JSBSim. I just put the default Cessna at EDLN RWY 13 with parking brake applied, the wind is 11009KT. It took approx. three and a half minutes to let the aircraft slip backwards by the length of a main gear cover. And, _no_, don't even think of it ;-)) it's definitely _not_ a proper solution to work around such a case by clamping the aircaft to a fixed position as long the brakes are applied :-) Just for the sake of completeness: Think of a scenario on the carrier, you're approaching the catapult from behind oh, too far, you're idling the engine, letting the wind blow you backwards while you're slowly manoeuvering your aircraft right into the catapult position solely by nose wheel steering. That's what I call proper simulation of tire ground reactions. FlightGear _could_ do that - it they didn't depend decisions made at JSBSim. JSBSim also does not (quite yet) do blade element modeling, so it's not easy to do a proper snap roll. Nor do we model multiple articulated landing gear struts. Nor do we ... As far as I can tell, nobody's asking JSBSim to do blade element modeling - to my opinion this is mostly a buzzword. Being able to fly an aircraft by table lookups derived from real life flight test data is quite an appealing approach. Instead, I'm talking about what I'd call a 'misfeature' to which a proper fix had already been submitted (years ago) and I'm convinced that you may apply as many workarounds, filters, whatever you like to the current gear/ground simulation, there'll be always a relevant corner case which remains uncaught as long as you stick to the current approach of gear modelling. I know that the patch which had been submitted to you uses a fundamentally different approach at modelling the tire/surface reactions and forces, but to my understanding this is by far the best way to get rid of the perpetually arising discussions about ground handling. Apart from that, do you have a specific proposal in mind? My proposal is either to develop a copy of the FDM inside FlightGear and to focus primarily on FlightGear's needs (and to try getting a copy of the respective patch) or to have the changes applied to JSBSim's code tree and to later merge this into FlightGear. We should move this to a new thread. Feel free to do that. From my point everything's been said - the sole purpose why I've actually been jumping into this discussion has been to dissect and/or explain the background which has led to the current situation wrt. gear/tire/surface modelling in JSBSim. I actually knew about it for a long time but I wanted to hear both sides. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Q: OpenGL version requirement for FlightGear 1.9.1
David L. Page wrote: Unfortunately, Chromium doesn't support OpenGL 2.0 or higher, right now. As I know FG 1.9.0 is using shaders to render trees and clouds. May be this is a problem. Try to find FG 1.0.0 or 0.9.10, it can be at the same FTP resource as 1.9.1. Alex _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us-- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
2009/2/6 Arnt Karlsen a...@c2i.net On Thu, 5 Feb 2009 11:07:45 +, FGD wrote in message 9dfda0650902050307n513838b7x6f06bca893b2b...@mail.gmail.com: 2009/2/5 Jon Stockill li...@stockill.net Tim Moore wrote: I don't know what to say about AC3D, but Blender has such a large community that I doubt you need to be suffering in isolation this way. Surely this is a known problem with a workaround? Before people spend too much time on that if you have a small sample model that you could upload somewhere I'd be happy to try and work through the conversion process in blender to determine what's required to get acceptable results - once you're happy it *can* be converted properly we can worry about how to achieve that on your platform. Yes a link to some basic cubes was in my previous message. ..??? I could not find that link. Lost message? No, it's me being a newbie to mailing lists, I had not spotted that Curtis wrote to me direct instead of using the reply to and hence the mailer replied to him direct thus stopping the reply message going to the list. Oh well! ;O) (I'll try and learn up some on all that for that in future, it's a bit confusing on only day two) Here's the bit you would have needed! Some people on the forum made this request last night. So I had a mate of mine upload these simple 1mtr boxes so anyone could have some samples to play with. They are only approx 1 metre I just threw them together, I wasn't being micro precise, so don't use them to measure anything dimensionally! LINK http://www.aeroshop3d.com/Quickstart/DocLib/lwo%20BorgBoxes.zip In the filenames; T indicates the model is of triangles, otherwise they are of quads, DS is for double sided otherwise they are single sided. They were made using the current version of lightwave modeller which I routinely have available which is 9.5. On a side note actually, and to the rest of the list, after some more in depth reading, I don't much like the look of Collada as I had felt earlier, it looked a bit too good to be true then and now it seems it really is too good to be true! It would be very likely to become highly problematic in use I suspect. -- Cheers, Ian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
Fred Vivian, apparently, the challenge is to start AC3D under Vista 64 -Fred - Vivian Meazza a écrit : Ian, Those boxes import nicely into AC3D here. How about a real challenge? PS there seems to be a workaround - here: http://www.inivis.com/forum/showthread.php?p=22957 Vivian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Q: OpenGL version requirement for FlightGear 1.9.1
Alex Buzin wrote: David L. Page wrote: Unfortunately, Chromium doesn't support OpenGL 2.0 or higher, right now. As I know FG 1.9.0 is using shaders to render trees and clouds. May be this is a problem. Try to find FG 1.0.0 or 0.9.10, it can be at the same FTP resource as 1.9.1. Alex Do you mean shaders as in vert and frag program running on the GPU that are loaded, compiled, and linked with GLSL? There is support in OSG for these types of shaders, but I could not find any use of the methods in the Simgear source. Perhaps I'm looking in the wrong place. Could you please point me to the appropriate files? Thanks John -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Q: OpenGL version requirement for FlightGear 1.9.1
On Fri, Feb 6, 2009 at 6:10 PM, John Wojnaroski cas...@mminternet.com wrote: Do you mean shaders as in vert and frag program running on the GPU that are loaded, compiled, and linked with GLSL? There is support in OSG for these types of shaders, but I could not find any use of the methods in the Simgear source. Perhaps I'm looking in the wrong place. Could you please point me to the appropriate files? For example simgear/scene/tgdb/TreeBin.cxx or simgear/scene/sky/newcloud.cxx -- Csaba/Jester -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Q: OpenGL version requirement for FlightGear 1.9.1
Csaba Halász wrote: On Fri, Feb 6, 2009 at 6:10 PM, John Wojnaroski cas...@mminternet.com wrote: Do you mean shaders as in vert and frag program running on the GPU that are loaded, compiled, and linked with GLSL? There is support in OSG for these types of shaders, but I could not find any use of the methods in the Simgear source. Perhaps I'm looking in the wrong place. Could you please point me to the appropriate files? For example simgear/scene/tgdb/TreeBin.cxx or simgear/scene/sky/newcloud.cxx Excellent! Thank you. John -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] some HUD_tape.cxx gdb core debug output
--- On Fri, 2/6/09, Tim Moore timo...@redhat.com wrote: From: Tim Moore timo...@redhat.com Subject: Re: [Flightgear-devel] some hopefully helpful gdb core debug output To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: Friday, February 6, 2009, 3:12 PM FlightGear wrote: hi, I am fg-torrents from the forums. I am trying to debug error in triangle intersect problem. Original thread here: http://www.flightgear.org/forums/viewtopic.php?f=2t=2824 I keep running into what looks like other issues causing fg to crash before triangle intersect occurs. I updated all my src today and am following the instructions provided by jester in the forum thread. So after applying the patch provided by jester and doing export FG_SIGFPE=1 then ulimit -c unlimited, I got something about jsbsim ftank or something, you can look at the thread. Now after todays src update I get the following output: (for reference ./configure --prefix=/home/user/fg-debug CFLAGS=-O0 -g CXXFLAGS=-O0 -g) This is a bit like whack-a-mole, but try again with the latest CVS or git version. When you send gdb output, it's helpful to know how you started the program and any interesting variable values. For instance, it would be helpful to know the value of _input.max() below. Tim I just started fg with ./fgfs and I don't know how to obtain the value of _input.max(). I also use a .fgfsrc file if thats of any importance. Fixed the subject line. fg-torrents -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
FGD ML fg...@pomf.net wrote: [...] FOr now it seems FG can only support .ac ahnd maybe 3ds, although I've not been able to do exhaustive testing. Presumably there was some testing done at some stage for all claimed formats being working as advertised when switching over to OSG? Certainly not all formats which are supported in OSG have undergone serious testing with FlightGear there are simply too many, but the .ac and .3ds are definitely not the sole two formats that display correctly with OSG in FlightGear. Anyway, according to my experience and simply by definition, everything that shows up properly in OSG's osgviewer utility also displays nicely in FlightGear. You'd probably wait for the upcoming OSG 2.8 release (which is due to be issued pretty soon), grab a Windows package and check a couple of Lightwave exports against osgviewer, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
2009/2/6 Martin Spott martin.sp...@mgras.net FGD ML fg...@pomf.net wrote: [...] FOr now it seems FG can only support .ac ahnd maybe 3ds, although I've not been able to do exhaustive testing. Presumably there was some testing done at some stage for all claimed formats being working as advertised when switching over to OSG? Certainly not all formats which are supported in OSG have undergone serious testing with FlightGear Oh, I see, I had simply not anticipated that outcome. Are we thinking that some non serious testing went on, on or could it be that no testing took place for some formats? there are simply too many, Well, yes, there are quite a few. but the .ac and .3ds are definitely not the sole two formats that display correctly with OSG in FlightGear. Where might one learn of the others that are known? It may be one of them could provide that which .lwo and .x definitely can not right now. Anyway, according to my experience and simply by definition, everything that shows up properly in OSG's osgviewer utility also displays nicely in FlightGear. Yes, That would follow. You'd probably wait for the upcoming OSG 2.8 release (which is due to be issued pretty soon), grab a Windows package and check a couple of Lightwave exports against osgviewer, Probably so, I shall explain what I found out to my other group members and see if there is agreement along those lines. Thank you for the very concise insight into it all. It has been invaluable. I guess wait and see is realistically the best hope we can have for the foreseeable future. That's a bit of a disappointment really. -- Cheers, Ian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
FGD ML fg...@pomf.net wrote: I guess wait and see is realistically the best hope we can have for the foreseeable future. That's a bit of a disappointment really. Well, you're asking for turn-key support of a format that's just very specific to _your_ job, as the tool you have choosen to use doesn't properly (as it seems) export into one of the other 'common' formats, like 3ds or OpenFlight. I would not call this 'disappointing', instead I'd see this as a nice chance for you to support other people's effort on either improving the .lwo reader in OSG or the development of other conversion tools ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] proper ground reactions (was YASim sliding helicopters bug)
Where is the proper gear model patch, Martin? mail.flightgear.org is down so the archives prior to 2005 are unreachable. I'm interested in taking a look. I'm also wondering what is stopping you from grabbing a copy of JSBSim, applying the patch, and providing some data to the powers that be to validate this proper ground reaction model? If it's as simple as applying a patch, why not spend some time/effort making your case with data rather than simply tossing emails back and forth? Just a thought. D -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
2009/2/6 Martin Spott martin.sp...@mgras.net FGD ML fg...@pomf.net wrote: I guess wait and see is realistically the best hope we can have for the foreseeable future. That's a bit of a disappointment really. Well, you're asking for turn-key support of a format that's just very specific to _your_ job, as the tool you have choosen to use doesn't properly (as it seems) export into one of the other 'common' formats, like 3ds or OpenFlight. I would not call this 'disappointing', instead I'd see this as a nice chance for you to support other people's effort on either improving the .lwo reader in OSG or the development of other conversion tools ;-) Well, that is certainly an interesting view of it all! Simply for the record, when I started making 3d models we had very few choices, I think mostly it was a choice of either using sculpt 3d or not using sculpt 3d really, that is if I do recall back that many years correctly just off the top of my head. g Over the intervening 24 years some other software has become available and I've tried a lot of them as they came and went, always looking for the best of course. I first found lightwave on the Amiga, where it was born, and to be honest I instinctively knew that having a title that could run on 2 platforms (Amiga and Apple) and not look or behave too differently on either, and which did not crash the whole time, and was solid enough to have pretty consitent results was probably a good thing. So I decided to let it stay as long as it continued to do all that and as long as nothing truly better came along. So, here we are. Since then windows 95 happend and that too got a version for it, since it too had that extremely well thought out multiplatform interface and it's concistency I moved over to PCs for doing 3d fairly competently not very long after that. The only choice I made in all that was to stick with that which wsa pretty much first and which has prioven itself time, after time, after time, to just plain flat out work, and to do all it ever said it would! I'm certainly not clear on whether it is a choice or not at that point. With hindsight I probably should have been clearer that the disappointment was related to being told that FG was lwo friendly and then find that not to be the case. No more or less than that, and I do not feel that a too terribly unreasonable reaction really. As for the opportunity, point me at the efforts you allude to, and tell me what you need that I may be able to help with. Bearing in mind I make models, and that's what I am any good at all at then I may not bve able to add anything but that, in fact that's what I've been trying to add to it all since the first moment. However we are not in any position to drive any of that forward, programmming is not what we do. It's outcome is something we work with, and at times simlpy accpet how it is, sometimes with good humour other times grudgingly, particularly when it makes life harder for no obvious reason, as it sometimes does. While I have been exploring this with you here, another has been trying figure out scenery, and has reported good potential, and yet another has been investigating AC3D and Blender and what they could do for us. And that is why we look for something other than them. We know roughly what shape the thing we need is, but not how to make that happen. We also have an appreciation and great respect for config files you can manually edit, so you won't scare us off very easily with those! g We know how much you will need them too, so we really are prepared to be as helpful and as accomodating as possible about them. I've been trying to come up with ideas and ways it could be easy for you to get them without much effort too. So, where is the workshop, and who do we need to work with? -- Cheers, Ian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
Ian, Whoa there, it's not all doom and gloom. As Csaba posted earlier there is a bug in the .lwo handling in osg, not in fg. As he also pointed out, it's believed to have been fixed. I'm checking that now. What has not been pointed out is that there is a conversion utility in osg which will convert 3d file formats from most things to most things. It might even do something with textures. I've tested that, and it shares the same bug that I mentioned above. This should have been fixed too. As I understand it .lwo is not the best format to use in osg, and some conversion, perhaps to .obj, or even .ac might be preferred. I'm trying to confirm that it all works under Windows right now, I'll keep you posted. Shouldn't be long. Vivian -Original Message- From: FGD ML [mailto:fg...@pomf.net] Sent: 06 February 2009 20:52 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] The use of models from other formats 2009/2/6 Martin Spott martin.sp...@mgras.net FGD ML fg...@pomf.net wrote: I guess wait and see is realistically the best hope we can have for the foreseeable future. That's a bit of a disappointment really. Well, you're asking for turn-key support of a format that's just very specific to _your_ job, as the tool you have choosen to use doesn't properly (as it seems) export into one of the other 'common' formats, like 3ds or OpenFlight. I would not call this 'disappointing', instead I'd see this as a nice chance for you to support other people's effort on either improving the .lwo reader in OSG or the development of other conversion tools ;-) Well, that is certainly an interesting view of it all! Simply for the record, when I started making 3d models we had very few choices, I think mostly it was a choice of either using sculpt 3d or not using sculpt 3d really, that is if I do recall back that many years correctly just off the top of my head. g Over the intervening 24 years some other software has become available and I've tried a lot of them as they came and went, always looking for the best of course. I first found lightwave on the Amiga, where it was born, and to be honest I instinctively knew that having a title that could run on 2 platforms (Amiga and Apple) and not look or behave too differently on either, and which did not crash the whole time, and was solid enough to have pretty consitent results was probably a good thing. So I decided to let it stay as long as it continued to do all that and as long as nothing truly better came along. So, here we are. Since then windows 95 happend and that too got a version for it, since it too had that extremely well thought out multiplatform interface and it's concistency I moved over to PCs for doing 3d fairly competently not very long after that. The only choice I made in all that was to stick with that which wsa pretty much first and which has prioven itself time, after time, after time, to just plain flat out work, and to do all it ever said it would! I'm certainly not clear on whether it is a choice or not at that point. With hindsight I probably should have been clearer that the disappointment was related to being told that FG was lwo friendly and then find that not to be the case. No more or less than that, and I do not feel that a too terribly unreasonable reaction really. As for the opportunity, point me at the efforts you allude to, and tell me what you need that I may be able to help with. Bearing in mind I make models, and that's what I am any good at all at then I may not bve able to add anything but that, in fact that's what I've been trying to add to it all since the first moment. However we are not in any position to drive any of that forward, programmming is not what we do. It's outcome is something we work with, and at times simlpy accpet how it is, sometimes with good humour other times grudgingly, particularly when it makes life harder for no obvious reason, as it sometimes does. While I have been exploring this with you here, another has been trying figure out scenery, and has reported good potential, and yet another has been investigating AC3D and Blender and what they could do for us. And that is why we look for something other than them. We know roughly what shape the thing we need is, but not how to make that happen. We also have an appreciation and great respect for config files you can manually edit, so you won't scare us off very easily with those! g We know how much you will need them too, so we really are prepared to be as helpful and as accomodating as possible about them. I've been trying to come up with ideas and ways it could be easy for you to get them without much effort too. So, where is the workshop, and who do we need to work with? -- Cheers, Ian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use
Re: [Flightgear-devel] The use of models from other formats
2009/2/6 Vivian Meazza vivian.mea...@lineone.net Ian, Whoa there, it's not all doom and gloom. I know, I'll live! It was just disappointment. It often passes after no more than a day depending on size! g So far you guys have shown me you are different, and I'm certainly willing to hang around and try to keep a lid on any preconceptions that experience with others might have taught me can be valid. VBG In truth, in many other environments this could have been a show stopper and a bit of a disaster but you guys clearly work differently! You show it in everything you do on this list. As Csaba posted earlier there is a bug in the .lwo handling in osg, not in fg. Yes, I spotted that (gleefully!), had not commented yet as I did not want to tempt fate! As he also pointed out, it's believed to have been fixed. I'm checking that now. I was wondering what the chances are that the bugged version would be the one that wound up in 191b. High hopefully. What has not been pointed out is that there is a conversion utility in osg which will convert 3d file formats from most things to most things. It might even do something with textures. I've tested that, and it shares the same bug that I mentioned above. This should have been fixed too. OK, but right now I'm really looking to stay with my existing format, and as long as we are doing something from ground up, why not have our format get a proper go for a novel change? After all there are converters out there which can produce .lwo right? If we would work to help it happen to start with then even more so. As I understand it .lwo is not the best format to use in osg, and some conversion, perhaps to .obj, or even .ac might be preferred. Well there's one little bit that I don't get with that line of thought; Since it clearly has yet to work at all, what empirical evidence can there be that it is not the best or even an adequate format? We seem to ahve been sort on any testing of it so far too. I'm drawn to conclude that it must be wholly open to discovery on that one for now. I'm trying to confirm that it all works under Windows right now, I'll keep you posted. Shouldn't be long. OK, no mad panic! These aircraft don't have to ship until second quarter '09 anyway. Sorry, yes, it was a leg pull, I got THAT sort of sense of humour I'm afraid. And thanks, and that thanks goes out to all here, truly! -- Cheers, Ian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
Ian, I think we are nearly there. Osg 2.8 has fixed the bug: ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/hunter-lwo-tanks.jpg Here we have a .ac aircraft with 2 .lwo droptanks slaved to it. They drop too! I still cannot confirm how textures are handled, or not as the case might be. No I didn't model the drag :-). Osgconv also works, at least it does for .lwo - .ac, but again no textures to test. I hope that's all more encouraging. So, anything else we can do for you? Vivian PS The Fairey Rotodyne looks like fun - that will be a challenge for the FDM folks! -Original Message- From: FGD ML [mailto:fg...@pomf.net] Sent: 06 February 2009 20:52 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] The use of models from other formats 2009/2/6 Martin Spott martin.sp...@mgras.net FGD ML fg...@pomf.net wrote: I guess wait and see is realistically the best hope we can have for the foreseeable future. That's a bit of a disappointment really. Well, you're asking for turn-key support of a format that's just very specific to _your_ job, as the tool you have choosen to use doesn't properly (as it seems) export into one of the other 'common' formats, like 3ds or OpenFlight. I would not call this 'disappointing', instead I'd see this as a nice chance for you to support other people's effort on either improving the .lwo reader in OSG or the development of other conversion tools ;-) Well, that is certainly an interesting view of it all! Simply for the record, when I started making 3d models we had very few choices, I think mostly it was a choice of either using sculpt 3d or not using sculpt 3d really, that is if I do recall back that many years correctly just off the top of my head. g Over the intervening 24 years some other software has become available and I've tried a lot of them as they came and went, always looking for the best of course. I first found lightwave on the Amiga, where it was born, and to be honest I instinctively knew that having a title that could run on 2 platforms (Amiga and Apple) and not look or behave too differently on either, and which did not crash the whole time, and was solid enough to have pretty consitent results was probably a good thing. So I decided to let it stay as long as it continued to do all that and as long as nothing truly better came along. So, here we are. Since then windows 95 happend and that too got a version for it, since it too had that extremely well thought out multiplatform interface and it's concistency I moved over to PCs for doing 3d fairly competently not very long after that. The only choice I made in all that was to stick with that which wsa pretty much first and which has prioven itself time, after time, after time, to just plain flat out work, and to do all it ever said it would! I'm certainly not clear on whether it is a choice or not at that point. With hindsight I probably should have been clearer that the disappointment was related to being told that FG was lwo friendly and then find that not to be the case. No more or less than that, and I do not feel that a too terribly unreasonable reaction really. As for the opportunity, point me at the efforts you allude to, and tell me what you need that I may be able to help with. Bearing in mind I make models, and that's what I am any good at all at then I may not bve able to add anything but that, in fact that's what I've been trying to add to it all since the first moment. However we are not in any position to drive any of that forward, programmming is not what we do. It's outcome is something we work with, and at times simlpy accpet how it is, sometimes with good humour other times grudgingly, particularly when it makes life harder for no obvious reason, as it sometimes does. While I have been exploring this with you here, another has been trying figure out scenery, and has reported good potential, and yet another has been investigating AC3D and Blender and what they could do for us. And that is why we look for something other than them. We know roughly what shape the thing we need is, but not how to make that happen. We also have an appreciation and great respect for config files you can manually edit, so you won't scare us off very easily with those! g We know how much you will need them too, so we really are prepared to be as helpful and as accomodating as possible about them. I've been trying to come up with ideas and ways it could be easy for you to get them without much effort too. So, where is the workshop, and who do we need to work with? -- Cheers, Ian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web.
[Flightgear-devel] VATSIM connectivity redux
Hi there, I'm sure you've all seen the news recently of Microsoft closing the ACES Studio and throwing doubt on the future of the Flight Simulator franchise. I'm a member of VATSIM's Board of Governors; my official position is VP of Web Services but I work pretty closely with our VP of Development, Ross Carlson, who I chatted with before sending this message. The news about ACES has drummed up renewed interest in VATSIM for alternative pilot client solutions; as you're probably aware we have a quite successful implementation with X-Plane. There are some limitations due to our network protocol (FSD)'s lackings (of which a newer version has been under development for awhile now) but on the whole it really functions quite well. I know there have been many concerns raised in the past in the FG community about working with a closed-source, NDA-requiring entity. I'd like to throw a little fuel on the fire, if I may, and also put forth a couple ideas I had of how we can work together. First, you should know that neither Ross or I nor most of VATSIM view our current closed-source/NDA arrangement as ideal, and we are working our way (albeit quite slowly) to a future version that will be fully open. Second, you should know that while VATSIM does at the moment require developer NDA to gain access to the FSD specifications, I did have a couple thoughts on how FG VATSIM could potentially coexist. One model that has been proposed before is the proxy server model; that would certainly be a possibility. Another model that occurred to me is by creating a stand-alone application that is closed-source and serves as the FlightGear/VATSIM client. By remaining closed-source it would fulfill VATSIM's requirements. How, then, would it communicate with FG? This you guys will know better than I as I'm not familiar with all the interprocess communication options you have available, but one thought is that you could open a TCP/IP socket and pass messages back and forth with the standalone client. Certainly I understand that you as developers of FG will work on features that you find interesting first (VATSIM, as an all-volunteer organization, is much the same way), and for some the mere concept of signing a NDA and/or working on a closed-source project is unacceptable. That's fine; we have no problems with that viewpoint and I don't need reminding of why you feel that way. I am an active open-source developer myself on several projects and completely understand the reasonings of those who might feel this way. However, if there are developers within the FG community who would be interested in working on a project like this, we at VATSIM would be quite keen to participate and I think that you would see a greatly increased visibility for your project as we would be able to heavily promote FlightGear within VATSIM. Participating in VATSIM is always completely free of charge, and indeed it is possible to act as a controller without anything except a computer and internet connection, but as a pilot you must purchase a commercial flightsim. If a client was created for FlightGear, we (and you) could and would promote it as the completely no-cost way to enjoy online flying with real people providing air traffic control via real world procedures. I'd be happy to answer any questions or concerns you might have, on- or off-list, as best as I can. Tim Krajcar t.kraj...@vatsim.net VATSIM VP Web Services -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] proper ground reactions (was YASim sliding helicopters bug)
Where is the proper gear model patch, Martin? mail.flightgear.org is down so the archives prior to 2005 are unreachable. I'm interested in taking a look. I'm also wondering what is stopping you from grabbing a copy of JSBSim, applying the patch, and providing some data to the powers that be to validate this proper ground reaction model? If it's as simple as applying a patch, why not spend some time/effort making your case with data rather than simply tossing emails back and forth? Just a thought. I think what Martin is referring to can be found here: http://developer.berlios.de/projects/openfdm/ Greetings, Torsten -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
On Fri, 6 Feb 2009 20:51:45 +, FGD wrote in message 9dfda0650902061251g657a7a8axe431c89adc385...@mail.gmail.com: 2009/2/6 Martin Spott martin.sp...@mgras.net FGD ML fg...@pomf.net wrote: I guess wait and see is realistically the best hope we can have for the foreseeable future. That's a bit of a disappointment really. Well, you're asking for turn-key support of a format that's just very specific to _your_ job, as the tool you have choosen to use doesn't properly (as it seems) export into one of the other 'common' formats, like 3ds or OpenFlight. I would not call this 'disappointing', instead I'd see this as a nice chance for you to support other people's effort on either improving the .lwo reader in OSG or the development of other conversion tools ;-) Well, that is certainly an interesting view of it all! Simply for the record, when I started making 3d models we had very few choices, I think mostly it was a choice of either using sculpt 3d or not using sculpt 3d really, that is if I do recall back that many years correctly just off the top of my head. g Over the intervening 24 years some other software has become available and I've tried a lot of them as they came and went, always looking for the best of course. I first found lightwave on the Amiga, where it was born, and to be honest I instinctively knew that having a title that could run on 2 platforms (Amiga and Apple) and not look or behave too differently on either, and which did not crash the whole time, and was solid enough to have pretty consitent results was probably a good thing. So I decided to let it stay as long as it continued to do all that and as long as nothing truly better came along. So, here we are. Since then windows 95 happend and that too got a version for it, since it too had that extremely well thought out multiplatform interface and it's concistency I moved over to PCs for doing 3d fairly competently not very long after that. The only choice I made in all that was to stick with that which wsa pretty much first and which has prioven itself time, after time, after time, to just plain flat out work, and to do all it ever said it would! I'm certainly not clear on whether it is a choice or not at that point. With hindsight I probably should have been clearer that the disappointment was related to being told that FG was lwo friendly and then find that not to be the case. No more or less than that, and I do not feel that a too terribly unreasonable reaction really. As for the opportunity, point me at the efforts you allude to, and tell me what you need that I may be able to help with. Bearing in mind I make models, and that's what I am any good at all at then I may not bve able to add anything but that, in fact that's what I've been trying to add to it all since the first moment. However we are not in any position to drive any of that forward, programmming is not what we do. It's outcome is something we work with, and at times simlpy accpet how it is, sometimes with good humour other times grudgingly, particularly when it makes life harder for no obvious reason, as it sometimes does. While I have been exploring this with you here, another has been trying figure out scenery, and has reported good potential, and yet another has been investigating AC3D and Blender and what they could do for us. And that is why we look for something other than them. We know roughly what shape the thing we need is, but not how to make that happen. We also have an appreciation and great respect for config files you can manually edit, so you won't scare us off very easily with those! g ..yeah, but who _are_ you guys, and why all this weird secrecy? We know how much you will need them too, ..I lost you _right_ there. ;o) so we really are prepared to be as helpful and as accomodating as possible about them. ..excellent, that means you guys have figured out how to do business with GPL software? ;o) I've been trying to come up with ideas and ways it could be easy for you to get them without much effort too. ..the only real problem I can see is licensing, and you fix that releasing your own stuff under the GPL, ideally GPLv3, IMO. Some people use dual licenses, e.g. the GPL and an EULA-style commercial sales contract. ..the main thing to remember for your GPL fork, is throw away code belonging to anyone who turns down your request to license their stuff in your project's GPL fork, and get it replaced with new code. (It can stay in your old EULA-style commercial sales contract licensed code as you damned well please, the contract language is what decides that.) So, where is the workshop, and who do we need to work with? ..maybe I can help out playing the Devil's Law Shark? ;o) http://www.amax-toys.com/tem/pdisp_e_1908.html -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/scene/util
Tim Moore timo...@baron.flightgear.org wrote: Update of /var/cvs/SimGear-0.3/source/simgear/scene/util In directory baron.flightgear.org:/tmp/cvs-serv7690/simgear/scene/util Modified Files: StateAttributeFactory.cxx StateAttributeFactory.hxx Log Message: Turn off z buffer writes for clouds. This is standard practice for semi-transparent objects and should cut down on the flickering and other sorting artifacts. Looks like a worthwhile addition to me ! Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
2009/2/6 Vivian Meazza vivian.mea...@lineone.net Ian, I think we are nearly there. Osg 2.8 has fixed the bug: ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/hunter-lwo-tanks.jpg Here we have a .ac aircraft with 2 .lwo droptanks slaved to it. guffaw Now THAT is funny - I'm sure I recognise those tanks from somewhere or other! Thank you very much indeed. They drop too! That may well be overkill at this stage! Drop those and you could start a building project rather than destroy one! I still cannot confirm how textures are handled, or not as the case might be. There's every reason to guess it might work very well indeed, especially if my hunch which I got while debugging through dos messages the other day is right. There might be a neat new dodge for all in there if I am right about that. No I didn't model the drag J. ;O) Does it give any sense of being any worse than you might normally have expected due to it being a .lwo object? Osgconv also works, at least it does for .lwo - .ac, but again no textures to test. Well I'm hoping not to ever be forced to go there! I hope that's all more encouraging. Absolutely, it also makes the dos exploring I did the other day so much more worth while, as I had the distinct feeling it was really trying to work as opposed to just playing dumb. So, anything else we can do for you? You may well live to regret asking that! I'm fully lost on how in practical terms an FG newbie like me would make my installation of it do that though! I don't want to put you lot through a lot of extra handholding as you clearly got far better things to do, but what are the chances of the next version having this fixed like that? In fact when would that be likely to even show up, I have no idea of the rhythm of these things in FG yet. A productive day, and thanks for it, we can all sleep easier knowing there was one of them happening somewhere today! -- Cheers, Ian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VATSIM connectivity redux
On Fri, Feb 6, 2009 at 4:01 PM, Tim Krajcar wrote: Hi there, I'm sure you've all seen the news recently of Microsoft closing the ACES Studio and throwing doubt on the future of the Flight Simulator franchise. I'm a member of VATSIM's Board of Governors; my official position is VP of Web Services but I work pretty closely with our VP of Development, Ross Carlson, who I chatted with before sending this message. The news about ACES has drummed up renewed interest in VATSIM for alternative pilot client solutions; as you're probably aware we have a quite successful implementation with X-Plane. There are some limitations due to our network protocol (FSD)'s lackings (of which a newer version has been under development for awhile now) but on the whole it really functions quite well. I know there have been many concerns raised in the past in the FG community about working with a closed-source, NDA-requiring entity. I'd like to throw a little fuel on the fire, if I may, and also put forth a couple ideas I had of how we can work together. First, you should know that neither Ross or I nor most of VATSIM view our current closed-source/NDA arrangement as ideal, and we are working our way (albeit quite slowly) to a future version that will be fully open. Second, you should know that while VATSIM does at the moment require developer NDA to gain access to the FSD specifications, I did have a couple thoughts on how FG VATSIM could potentially coexist. One model that has been proposed before is the proxy server model; that would certainly be a possibility. Another model that occurred to me is by creating a stand-alone application that is closed-source and serves as the FlightGear/VATSIM client. By remaining closed-source it would fulfill VATSIM's requirements. How, then, would it communicate with FG? This you guys will know better than I as I'm not familiar with all the interprocess communication options you have available, but one thought is that you could open a TCP/IP socket and pass messages back and forth with the standalone client. Certainly I understand that you as developers of FG will work on features that you find interesting first (VATSIM, as an all-volunteer organization, is much the same way), and for some the mere concept of signing a NDA and/or working on a closed-source project is unacceptable. That's fine; we have no problems with that viewpoint and I don't need reminding of why you feel that way. I am an active open-source developer myself on several projects and completely understand the reasonings of those who might feel this way. However, if there are developers within the FG community who would be interested in working on a project like this, we at VATSIM would be quite keen to participate and I think that you would see a greatly increased visibility for your project as we would be able to heavily promote FlightGear within VATSIM. Participating in VATSIM is always completely free of charge, and indeed it is possible to act as a controller without anything except a computer and internet connection, but as a pilot you must purchase a commercial flightsim. If a client was created for FlightGear, we (and you) could and would promote it as the completely no-cost way to enjoy online flying with real people providing air traffic control via real world procedures. I'd be happy to answer any questions or concerns you might have, on- or off-list, as best as I can. Hi Tim, Sorry to quote your whole message ... chalk it up to laziness. :-) As I read through your message a few thoughts occurred to me. First, there is a large variety of opinions represented here on our developers list, and we have a few really die hard open-source folks ... give me open-source or give me death ... But I think the overwhelming majority of FlightGear developers and users are pretty pragmatic. We certainly honor, value, promote, and vigorously protect the GPL nature of FlightGear, but we realize that there are multiple ways to get through life. There's a certain art (probably which none of us have really mastered) :-) of filtering through the list noise and focusing in on the important responses, ignoring the flame bait, and giving people a little slack if they respond with too much haste, or misunderstand the original questions. One idea came to me, and I haven't fully thought through all it's implications, but let me present it here for discussion. What if we (meaning a vatsim developer with protocol access and flightgear developers as consultants) develop a utility that to FlightGear looks like a standard flightgear multiplayer server. This would run on a user's local machine, and their local copy of FlightGear would connect to it like any other multiplayer server. This utility would be closed source, and it would know how to speak the vatsim protocol. So like you say, it would be a bridge between the local copy of FlightGear and the vatsim network. I like
Re: [Flightgear-devel] VATSIM connectivity redux
Curtis, Thanks for the response. This is in fact how a number of our clients operate. There is no VATSIM-specific code in MSFS or XP at all. the VATSIM client joins a multiplayer session hosted by the user, and then pushes other VATSIM users' data as MP planes into the client. Similarly, the client takes the MP data transmitted by the user's sim, translates it to FSD, and sends it out to the network. In recent versions of FS we have been able to automate and hide this for the user's ease of use - the MP session is automatically created, joined to by the client, etc. The instructions for connecting to VATSIM with FS2000 were quite long and difficult; in FS2004 FSX, it's really very easy for the user. Your suggestion was to code a MP server that interfaces with VATSIM; mine is to code a MP client that connects to FG running as a MP server. Both are certainly workable ideas and I think it would come down to whichever is less heavy lifting. One other potential complication you made me think of is that at the moment both MSFS XP can run their client as what MSFS terms a module, meaning a window inside the sim itself, or as a secondary application. I don't know if FG has the ability to do this; certainly it would be nice if possible, but I don't want it to be thought of as a deal-breaker. Good suggestions and a good way to kick off the dialogue. Tim On Fri, Feb 6, 2009 at 2:34 PM, Curtis Olson curtol...@gmail.com wrote: Hi Tim, Sorry to quote your whole message ... chalk it up to laziness. :-) As I read through your message a few thoughts occurred to me. First, there is a large variety of opinions represented here on our developers list, and we have a few really die hard open-source folks ... give me open-source or give me death ... But I think the overwhelming majority of FlightGear developers and users are pretty pragmatic. We certainly honor, value, promote, and vigorously protect the GPL nature of FlightGear, but we realize that there are multiple ways to get through life. There's a certain art (probably which none of us have really mastered) :-) of filtering through the list noise and focusing in on the important responses, ignoring the flame bait, and giving people a little slack if they respond with too much haste, or misunderstand the original questions. One idea came to me, and I haven't fully thought through all it's implications, but let me present it here for discussion. What if we (meaning a vatsim developer with protocol access and flightgear developers as consultants) develop a utility that to FlightGear looks like a standard flightgear multiplayer server. This would run on a user's local machine, and their local copy of FlightGear would connect to it like any other multiplayer server. This utility would be closed source, and it would know how to speak the vatsim protocol. So like you say, it would be a bridge between the local copy of FlightGear and the vatsim network. I like this because we wouldn't necessarily need to change anything within the FlightGear source code, and we would automatically support current and past versions of FlightGear. There would need to be some dancing in terms of the FlightGear mutiplayer protocol. Certainly you could reimpliment a functional interface, but it might save you time if you could borrow some code from the FlightGear multiplayer server. That could only happen with express permission of the authors of that particular code. Some here may argue vigorously against this, but I think a lot of people would be pretty pragmatic about this ... assuming you had full support from the multiplayer server author(s) and it would be their decision to make. Otherwise you'd have to look at the protocol specification and rewrite your own FlightGear compatible interface which probably isn't horribly difficult, so maybe that would be the way to go and you wouldn't risk offending anyone. But if you do that you need to be pretty careful not to look at our multiplayer server code lest it be too tempting to copy from it. I do think it's worth pushing towards vatsim compatibility and I appreciate your persistence as we try to find a way through that satisfies all the different constraints. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/http://baron.flightgear.org/%7Ecurt/ -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today- http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] The use of models from other formats
2009/2/6 Arnt Karlsen a...@c2i.net On Fri, 6 Feb 2009 20:51:45 +, FGD wrote in message 9dfda0650902061251g657a7a8axe431c89adc385...@mail.gmail.com: ..yeah, but who _are_ you guys, and why all this weird secrecy? We're just a bunch of old guys who quite like making stuff in flight sims. You never heard of us, so saying more than that would just be over sharing for the sake of it. No point in that is there? shrug And the secrecy is obviously so secret I don't know anything about it either, in fact I had not even noticed it myself ! shrug I may not yell about where our past stuff was to be found, and we've not really hidden that either, as astute readers of the thread will know, but that is to some extent in due deference to the sim author. There may be no love loss there as we've all come to feel rather taken for granted, but that's no reason to yell the details from the roof tops and be really vulgar about it all. That much is just us trying to show some professionalism about it all, and our recognition that it's probably a good thing that someone does. We know how much you will need them too, ..I lost you _right_ there. ;o) OK, we noticed that coders like config files, they only put them in there trying to give model makers a hard time! ;O) We just happen to think that with due consultation, a better way to get the files into existence in the first place might well be there to be had! so we really are prepared to be as helpful and as accomodating as possible about them. ..excellent, that means you guys have figured out how to do business with GPL software? ;o) No, I'm lost on all that stuff. ..the only real problem I can see is licensing, and you fix that releasing your own stuff under the GPL, ideally GPLv3, IMO. Some people use dual licenses, e.g. the GPL and an EULA-style commercial sales contract. ..the main thing to remember for your GPL fork, is throw away code belonging to anyone who turns down your request to license their stuff in your project's GPL fork, and get it replaced with new code. (It can stay in your old EULA-style commercial sales contract licensed code as you damned well please, the contract language is what decides that.) Look, we make all our own stuff so no one has any rightfull claim to anything in that but us. We don't charge for our stuff so there's no commercial issues either. We could make this far more complicated than it really needs if we keep playing with endless acronyms. So, where is the workshop, and who do we need to work with? ..maybe I can help out playing the Devil's Law Shark? ;o) http://www.amax-toys.com/tem/pdisp_e_1908.html I saw the shark but I'm not clear on where it might be supposed to help! If, as seems possible, it's an in joke of some kind, then maybe I was busy when, whatever it was, happened? ;O) shrug Nearest thing that comes to mind is that old thing about the Happy Days TV show getting past it's sell by date, and Jumping The Shark but I can't do better than that for now! Been a long day. -- Cheers, Ian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] proper ground reactions (was YASim sliding helicopters bug)
Where is the proper gear model patch, Martin? mail.flightgear.org is down so the archives prior to 2005 are unreachable. I'm interested in taking a look. I'm also wondering what is stopping you from grabbing a copy of JSBSim, applying the patch, and providing some data to the powers that be to validate this proper ground reaction model? If it's as simple as applying a patch, why not spend some time/effort making your case with data rather than simply tossing emails back and forth? Just a thought. == I think what Martin is referring to can be found here: == http://developer.berlios.de/projects/openfdm/ == Greetings, Torsten No, that's not it. Actually, there is no patch, per se. There is a branch in JSBSim cvs from several years ago that contains a set of files, some new, some modified. Since that time, the main branch of JSBSim has evolved and grown very considerably. Jon -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Nasal misbehaving badly on my machine: how to debug it?
Hi, This is the first message of a flight sim newbie. After hearing that MSFS was being dismantled, I looked after X-Plane and bought it. Then I discovered that I will probably have to wait 5 weeks to get it by mail so I discovered FlightGear and I'm trying to use it. I couldn't believe there was a opensource flight sim. So I went for it. Unfortunately I'm having a really bad time with nasal scripts. I'm having all kinds of errors on the console. Some of them: Nasal runtime error: No such member: real_time_base at /usr/local/fgfs-cvs//data//Nasal/wildfire.nas, line 226 called from: /usr/local/fgfs-cvs//data/Nasal/wildfire.nas, line 791 called from: /usr/local/fgfs-cvs//data/Nasal/wildfire.nas, line 789 Initializing Nasal Electrical System power up Nasal runtime error: non-objects have no members at /usr/local/fgfs-cvs//data/Nasal/screen.nas, line 498 called from: /usr/local/fgfs-cvs//data/Nasal/screen.nas, line 525 called from: /usr/local/fgfs-cvs//data/Nasal/globals.nas, line 96 At first I thought this could be normal as I had never seem FlightGear running before. But as I had a completely non-working throttle axis on my joystick despite js-demo and jstest shoing it's working fine I started doing some debuging. Obviously me and everybody that I talked about on IRC first believed it ws some kind of misconfiguration but after a big debug session with cptf (I think this is his IRC handle) we got to the conclusion that nasal scripts were misbehaving badly on my machine. This conclusion took force when we found out that at fgfs begining, on a foreach loop at the end of controls.nas, the engines for the Cessna 172 I'm trying to use were being setted fine but if I try to read the same controls.engines hash with the nasal console I got a empty [] This and the bunch of nasal errors on the console seems to be all ills from the same source. I writing to ask for help on how to debug this as I can't see anything else not working as expected on my machine and I really don't know how to even begin debuging this issue. Any ideas? TIA, Rodrigo Severo -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
On Friday 06 February 2009 23:01:26 Vivian Meazza wrote: Osgconv also works, at least it does for .lwo - .ac, but again no textures to test. Using Blender I added a texture to one of the sides of the borgbox, and finally exported to *.lwo format. The texture did not appear in osgviewer. Looking at the resulting *.lwo file in a hex editor showed that apparently the UV coordinates were present in the exported file, but I could see no reference to the image file, and the file size is obviously too small for the image to be embedded. I don't know if this is a feature of Blender's *.lwo exporter, or a feature of osgviewer. Would it be possible to post a link to a *.lwo file that also has textures? -- Roy Vegard Ovesen -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
2009/2/6 Roy Vegard Ovesen roy.v.ove...@haugnett.no On Friday 06 February 2009 23:01:26 Vivian Meazza wrote: Osgconv also works, at least it does for .lwo - .ac, but again no textures to test. Using Blender I added a texture to one of the sides of the borgbox, and finally exported to *.lwo format. The texture did not appear in osgviewer. Looking at the resulting *.lwo file in a hex editor showed that apparently the UV coordinates were present in the exported file, but I could see no reference to the image file, and the file size is obviously too small for the image to be embedded. I don't know if this is a feature of Blender's *.lwo exporter, or a feature of osgviewer. Would it be possible to post a link to a *.lwo file that also has textures? Should be no need, just put the image in there next to the model and it will very probably find it for itself. In a genuine and correctly formed .lwo the image names will be in there somewhere. You can also prefix them with paths, optionally, if you would like that too or find it helpful. Choices, to suit your requirements, is what it is all about with this format. If I were debugging this one I might try and make sure the image is in the same folder as the model when creating it, then, once it's been saved/exported it's proper behaviour would be to look in the same folder as it finds itself in, exactly reflecting how things stood when it was made and before it was moved to where you prefer to use it from. That would probably be the easiest way to make one when new to the system and therefore quite possibly not used to being able to have path facilities if one wanted them. -- Cheers, Ian -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
On Fri, 6 Feb 2009 23:06:59 +, FGD wrote in message 9dfda0650902061506u22068722ld9a43d1ebb574...@mail.gmail.com: 2009/2/6 Arnt Karlsen a...@c2i.net On Fri, 6 Feb 2009 20:51:45 +, FGD wrote in message 9dfda0650902061251g657a7a8axe431c89adc385...@mail.gmail.com: so we really are prepared to be as helpful and as accomodating as possible about them. ..excellent, that means you guys have figured out how to do business with GPL software? ;o) No, I'm lost on all that stuff. ..ah, that's where I try to help out. ;o) ..the only real problem I can see is licensing, and you fix that releasing your own stuff under the GPL, ideally GPLv3, IMO. Some people use dual licenses, e.g. the GPL and an EULA-style commercial sales contract. ..the main thing to remember for your GPL fork, is throw away code belonging to anyone who turns down your request to license their stuff in your project's GPL fork, and get it replaced with new code. (It can stay in your old EULA-style commercial sales contract licensed code as you damned well please, the contract language is what decides that.) Look, we make all our own stuff so no one has any rightfull claim to anything in that but us. We don't charge for our stuff so there's no commercial issues either. We could make this far more complicated than it really needs if we keep playing with endless acronyms. ..so how do you protect your work from piracy? So, where is the workshop, and who do we need to work with? ..maybe I can help out playing the Devil's Law Shark? ;o) http://www.amax-toys.com/tem/pdisp_e_1908.html I saw the shark but I'm not clear on where it might be supposed to help! If, as seems possible, it's an in joke of some kind, then maybe I was busy when, whatever it was, happened? ;O) shrug ..think Devil's Advocate, I'm fairly sure you will want to drop your current legal paperwork in favor of selling your models it under the GPLv3: ;o) http://www.fsf.org/licensing/licenses/gpl.html -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...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. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VATSIM connectivity redux
On Sat, 07 Feb 2009 12:46:31 +1300, James wrote in message 498ccbd7.1030...@gogo.co.nz: Tim Krajcar wrote: Your suggestion was to code a MP server that interfaces with VATSIM; mine is to code a MP client that connects to FG running as a MP server. Both are certainly workable ideas and I think it would come down to whichever is less heavy lifting. FlightGear itself does not work as a server. FlightGear is a multi player client only, the server is separate, few people have or run FG servers, there is no hosting a MP game, you just connect to one of the existing MP servers along with everybody else. Information about the server system can be found here: http://fgms.sourceforge.net/ Here's a map showing who is on the current public servers (they are all interconnected): http://mpmap02.flightgear.org/ If you were to create a VATSIM FlightGear server (and host it of course) then you'd be well on the way to having an really workable solution. --- James Sleeman ..this is the _best_ way to do it. :o) ..legally, if you use and modify your fork of fgms, but keep in in-house and never distribute it, only use it in-house to provide a web service, the GPL becomes irrelevant because you are in full compliance with copyright law. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...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. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
