Re: [Flightgear-devel] Mipmapping of liveries
Le 25/09/2013 23:39, Gary Neely a écrit : I've felt my machine come to a crawl while certain planes are loaded in MP-- I had to remove some because they were too much of a hit for my poor aging system. it's the same here, FG take age sometimes to load 3D stuff, mostly because it create the mipmap on the fly, from the png/jpg/rgb texture, and this operation is long specially for huge textures! I didn't removed them, but converted them to dds with a bash script: http://wiki.flightgear.org/Fr/convertir_un_avion_en_dds About FG and dds texture, could it be possible to propose a dds version of our planes in an official manner, or do i need to make a paralel hangar, with hidden advertisings? I'm fine with fgdata having png/rgb textures, as they are lossless and easy to work on, and a non dds version is still needed for who don't want to use dds (for patent issues, or other reasons). If you want to try a dds version, to make an opinion, i've converted some here: http://janodesbois.free.fr/flightgear/dds_planes_2.12/ you will need the Generic folder, and you can add the Instrument and Instrument-3d, to have full dds planes. my concern is not to force dds use, but to allow a better mp experience (try to change livery for example, in external view). jano -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mipmapping of liveries
On 26/09/2013 01:16, Tomash Brechko wrote: 2013/9/26 jean pellotier jean.pellot...@wanadoo.fr mailto:jean.pellot...@wanadoo.fr it's the same here, FG take age sometimes to load 3D stuff, mostly because it create the mipmap on the fly, At this point I'm kinda lost :). Back to my original question then: does FG mipmaps liveries by default, or does it not? It's not clear whether you include aircrafts in 3D stuff or not :). Yes the aircrafts are included in 3D stuff and FG create the mipmaps when loading the planes. jano -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] making sign of side-slip consistent betweenfdm (bug 901)
Beta is positive when the wind hits the right side of the vehicle. This is the only standard convention I have ever seen. I would recommend strongly against artificially changing the sign of this parameter as output from JSBSim. Jon I did a merge request considering jsbsim got right here, ie positive when the wind come from the right. you can find them here: http://code.google.com/p/flightgear-bugs/issues/detail?id=901#c12 the yasim planes using: orientation/side-slip-deg in autopilot or animation were tweaked with a sign inversion to have the same behaviour as before. three files are left inchanged as i don't know wich behaviour is correct, and as they were inversed between yasim and jsbsim planes: Nasal/dynamic_view.nas Huds/NTPS.xml /Huds/Instruments/turn-bank-indicator.xml the dynamic view got nearly no effect from the side-slip, so it's not a concern here, for the two hud files, i need to how they should behave, anyone got a clue? as a side note, i think the bocian's yawstring got a wrong sign in the animation, the string should be aligned whith the airflow, and it currently do the oposite (imho). jano -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata space in filenames
i finally did a merge request with the correction to the offending files, tell me if this a thing to do, or i should wait for the maintainers to react (but some are not actif anymore). https://gitorious.org/fg/fgdata/merge_requests/114 jano -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata space in filenames
Le 06/08/2013 13:58, James Turner a écrit : I think I'm sufficiently motivated to see if I can write a pre-commit hook which rejects names containing spaces. (Not sure how to install hook-scripts on Gitorious, but it must be documented somewhere) If anyone can postulate the shell-fu to detect file (not directory) names which differ only in case, I could add that too. James for who want to check before commiting, there's a bash script in the flightgear source doing the space search and more, initially intended to be run before commiting: scripts/tools/fg-check can someone with write acces address the space for the : ./Aircraft/OV10/USAFE Panel.rtf i think it's unmaintened for now, and i don't think a merge request is needed here :) jano -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgdata space in filenames
Hi, weren't the space in fgdata filenames banished long time ago? here's a list of current offending files. I'd like to give a special reward to the README OR DIE.txt :D jano -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgdata space in filenames
Hi, weren't the space in fgdata filenames banished long time ago? here's a list of current offending files. I'd like to give a special reward to the README OR DIE.txt :D jano ./Aircraft/B-25/Models/Liveries/Aluminum II.png ./Aircraft/B-25/Models/Liveries/Aluminum II.xml ./Aircraft/C130/Models/Interior/Panel/Instruments/weapons/A-10-armament-panel copy.xml ./Aircraft/D510/Models/Liveries/Patrouille de France FlightGear.xml ./Aircraft/D510/Sounds/BaBoOn D-510 Sounds.txt ./Aircraft/D510/Sounds/BaBoOn D-510 Sounds.html ./Aircraft/D510/Sounds/BaBoOn D-510 Tire Squeal.wav ./Aircraft/D510/Sounds/BaBoOn D-510 Engine Start.wav ./Aircraft/D510/Sounds/BaBoOn D-510 Engine Start2.wav ./Aircraft/D510/Sounds/BaBoOn D-510 Wheel Cockpit.wav ./Aircraft/D510/Sounds/BaBoOn D-510 Start.wav ./Aircraft/D510/Sounds/BaBoOn D-510 Gunfire Cannon 20mm.wav ./Aircraft/D510/Sounds/BaBoOn D-510 OnOff.wav ./Aircraft/D510/Sounds/BaBoOn D-510 Wind.wav ./Aircraft/D510/Sounds/BaBoOn D-510 Engine Idle Slow motion.wav ./Aircraft/PC-6/Systems/Copie de electrical.xml ./Aircraft/OV10/USAFE Panel.rtf ./Aircraft/UH-1/Models/Liveries/texture RCAF.xcf ./Aircraft/AG-14/Models/Instruments/Oil/OIL Temp-Press.png ./Aircraft/PC-21/Models/Instruments/HUD Repeater ./Aircraft/PC-21/Models/Instruments/HUD Repeater/HUDRepeater.ac ./Aircraft/PC-21/Models/Instruments/HUD Repeater/HUDRepeater.xml ./Aircraft/ec130/Tutorials/runup_and_ before_takeoff_tutorial.xml ./Aircraft/Mirage-2000/Models/Interior/Panel/Instruments/Mfd/rwr/rwr (copie).ac ./Aircraft/Mirage-2000/Missiles/Meteor/Main Parts.png ./Aircraft/fokker50/Models/instruments/general/dme (copy).rgb ./Aircraft/fokker50/Models/instruments/overhead/Useful bits ./Aircraft/fokker50/Models/instruments/overhead/Useful bits/rotary.rgb ./Aircraft/CRJ700-family/Docs/General information.html ./Aircraft/Fokker-Spin/Models/spoked wheel.png ./Aircraft/Mirage_F1/Models/cockpit/frein parc.ac ./Aircraft/Mirage_F1/Models/cockpit/frein parc.xml ./Aircraft/Mirage_F1/Models/cockpit/manette gaz ./Aircraft/Mirage_F1/Models/cockpit/manette gaz/manette gaz.ac ./Aircraft/Mirage_F1/Models/cockpit/manette gaz/manette gaz.xml ./Aircraft/Mirage_F1/Models/cockpit/manette gaz/gaz.png ./Aircraft/Mirage_F1/Models/Instrument/Panneau Alarme ./Aircraft/Mirage_F1/Models/Instrument/Panneau Alarme/Panneau Alarme.ac ./Aircraft/Mirage_F1/Models/Instrument/Panneau Alarme/Panneau Alarme.png ./Aircraft/Mirage_F1/Models/Instrument/Panneau Alarme/Panneau Alarme.xml ./Aircraft/Mirage_F1/Models/Instrument/Bouton Indicateurs ./Aircraft/Mirage_F1/Models/Instrument/Bouton Indicateurs/Indicateur.ac ./Aircraft/Mirage_F1/Models/Instrument/Bouton Indicateurs/urgence.ac ./Aircraft/Mirage_F1/Models/Instrument/Bouton Indicateurs/urgence.xml ./Aircraft/Mirage_F1/Models/Instrument/Bouton Indicateurs/Indicateur ALT CAP.png ./Aircraft/Mirage_F1/Models/Instrument/Bouton Indicateurs/Indicateur.xml ./Aircraft/Zlin-50lx/Models/Liveries/Zlin PAFrouge.xml ./Aircraft/Zlin-50lx/Models/Liveries/Zlin PAFblanc.xml ./Aircraft/Zlin-50lx/Models/Liveries/Zlin PAFbleu.xml ./Aircraft/eastbourne_mono/Models/spoked wheel.png ./Aircraft/fokker100/Documents/Readme Credits.txt ./Aircraft/fokker100/Documents/Fokker 100.rtfd ./Aircraft/fokker100/Documents/Fokker 100.rtfd/220px-Klm.fokker.f100.ph-ofg.arp.jpg ./Aircraft/fokker100/Documents/Fokker 100.rtfd/TXT.rtf ./Aircraft/fokker100/Documents/Fokker 100.rtfd/220px-Air_Niugini_Fokker_100_Mt_Hagen_PNG.jpg ./Aircraft/fokker100/Documents/thumbnail (Big).jpg ./Aircraft/fokker100/Documents/README (old).txt ./Aircraft/fokker100/Models/Effects/trail/smoke copy.png ./Aircraft/fokker100/Models/Liveries/Blank copy.png ./Aircraft/fokker100/Readme Credits.txt ./Aircraft/Lancair-235/Models/Liveries/Rouge PH-JPR.xml ./Aircraft/tu154b/Model/Effects/stream failure.xml ./Aircraft/AVRO-IV-Triplane/Models/spoked wheel.png ./Aircraft/Heinkel-He-177/Models/Images/FS/He177 Greif ./Aircraft/Heinkel-He-177/Models/Images/FS/He177 Greif/He177.air ./Aircraft/Heinkel-He-177/Models/Images/FS/He177 Greif/model ./Aircraft/Heinkel-He-177/Models/Images/FS/He177 Greif/model/Model.cfg ./Aircraft/Heinkel-He-177/Models/Images/FS/He177 Greif/model/He177.mdl ./Aircraft/Heinkel-He-177/Models/Images/FS/He177 Greif/panel ./Aircraft/Heinkel-He-177/Models/Images/FS/He177 Greif/panel/Main_Panel.BMP ./Aircraft/Heinkel-He-177/Models/Images/FS/He177 Greif/panel/Panel.cfg ./Aircraft/Heinkel-He-177/Models/Images/FS/He177 Greif/sound ./Aircraft/Heinkel-He-177/Models/Images/FS/He177 Greif/sound/Sound.cfg ./Aircraft/Heinkel-He-177/Models/Images/FS/He177 Greif/texture ./Aircraft/Heinkel-He-177/Models/Images/FS/He177 Greif/texture/AC
[Flightgear-devel] making sign of side-slip consistent between fdm (bug 901)
hi there, following this bug report: http://code.google.com/p/flightgear-bugs/issues/detail?id=901 it appears that orientation/side-slip-deg and side-slip-rad don't have the same sign, depending if it's a yasim or a jsbsim plane. is there a commonly adopted convention for this property? if not, shouldn't we document somewhere the meaning of the different fdm properties present in fg tree, to avoid such problems in the future ? jano -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] merge request #203: Update of tutorials marker, correction to pushback
Hello Hyde, I have a comment from James Turner on my merge request I did to the 777 tuturial and checklists to ask you for a review of this request. If you can take time to review my modifications. Thanks a lot. Regards. Jean-Yves -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] about fdm properties
Hi the quiet mailing list :) here are some questions about the fdm properties : - How come some fdm properties don't have the same meaning, dépending the fdm used? i'm thinking of properties in the following property trees: /accelerations /orientation /velocities /position if you want some examples, you can have a look at the bug reports 202: http://code.google.com/p/flightgear-bugs/issues/detail?id=202 and 901: http://code.google.com/p/flightgear-bugs/issues/detail?id=901 those are properties i needed to use and found buggy, but they could not be the only one affected. - is there anybody among the dev interested in this area of FG anymore? despite the bug report and the solution proposed, nothing change, except the need to have external patch to have this right. - would it be a good idea to document those properties somewhere? if so i can make a list, but i would let the description to english native users. imho, this make FG broken in some area (like hud trajectory marker with jsbsim for the sideslip, or the reported speed in radar2 for yasim planes) but the only comments i got in the bug reports were what will it break to put it right. jano -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplay refuel test
hi Geoff , And I understand some screen shots were posted on the PAF forum, but still to find these... a link would help... http://equipe-flightgear.forumactif.com/t1096p15-vol-en-formation-avec-un-fg-patche#20638 Oh, and I always use mpserver14.flightgear.org, Switzerland, and perhaps attempts while using the SAME fgms server may be better... yep, that's the rule we are following during our formation flight: to be on the same mpserver. Being on different servers give more jitter and lag, and there's no way to compensate for the inter-server lag now, as we have no information about them. http://wiki.flightgear.org/Mp-patch Have downloaded and am looking at your wiki lag patches with an aim to patch my 2.11... in Windows 7 and Ubuntu... but not sure how far I will get... good luck :) , for your information, a patched 2.11 windows binary is available and updated once a week, if you can't compile it yourself, see detail on the wiki. It would certainly be nice if both pilots saw the same scene ;=)) But this is not the ONLY problem... basically the mp sending rate is fine with 10 pps Well yes if the packets flow, but many things do seem to interrupt that flow... One of the biggest is F3 - take a screen shot - This seems to stop packets for a seconds or more... i never use F3 for screenshots, as it freeze fg , instead i use the os printshot feature, much better and harmless (and it has the antialiasing from the gpu) Loading a new scenery tile can be another... new weather metar, although in the victor I usually select simple Fair weather... but there seems to be a number of things that 'change' the packet flow... I even suspect mp chat causes small blips... those are not change in paquet flow, but 'freeze' in FG itself, when some frame take time to render, being stuck on a model loading, or a metar change, or a F3 etc To avoid mipmap generation hang, I use dds texture for all the planes in my aircraft folder (with a script), the mipmap are not generated on the fly and the loading is faster (taking less space in ram too). that's why in the paf hangar we are providing both a .png and a .dds version of the planes. So the aircraft pilot sees the tanker quickly move away... accelerate and moves forward... quite un-nerving... And this can happen even without a heavy F3 event... perhaps even due to system thread changes, ie nothing to do with the running fgfs... we call this the rubber band phenomen :D, mainly caused by jitter, and worse if we are not on the same server. So I must take another look at this fill-in code, and would like to hear from the person or persons who implemented it... and understand why the very apparent slide fast forward, and what controls how quickly the position returns to that of the current packets after such an artificial change... any README, links, etc... the current code in AIMultiplayer.cxx got a prediction system, but try to nether use it. this is done to have only an interpolation between two packets to do. so we display the mp plane at least one packet late to have a margin. And then there is how will your 'lag' correction effect this current extrapolation code? If at all... I reused the existing code, with some modifications wich are: - very slow response to jitter: the rubber band phenomen is just a little noticeable, seen as a speed variation of the followed plane. - i'm sending and using planes's accelerations (only for yasim and jsbsim yet), so the position is predicted using position, speed and acceleration with a basic equation. If some are interested i can detail a little more this on the wiki page. if you are using the patch, be aware that non patched yasim planes transmit a velocity in airmass instead of ecef, so they are very shaky if displayed in the futur with some wind. Maybe later try an E-W run, since you do mention some differences depending on direction... this is an effect of the patch with jsbsim aircraft, i needed to find an acceleration suitable, so i added one in jsbsim, but aparently this is not perfect yet, but at 10 pps, it nearly unnoticeable. I guess this should be a jsbsim expert job :) jano -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplay refuel test
Hi Geoff i guess you are seing something like that: http://www.youtube.com/watch?v=VWn6_RFp97Y where this is the closest you can see the following plane, but in fact he see itself very close to the drogue and what you want is like this: http://www.youtube.com/watch?v=kGHRDrc_n98 you should have a look at this page, wip but working fine for the few pilots testing it : http://wiki.flightgear.org/Mp-patch basically the mp sending rate is fine with 10 pps, but you need a way to compensate for the lag. I can't try a refuel with you before this WE, but i will if you are still flying the victor somewhere. jano NOTAM: To flyers who fly 'probe' enabled aircraft in Europe... or even if NOT... I will be flying the 'victor' refueling tanker for the next few days from KFPY, south 180 track, then turn around at the southern mountains, north on 360, at 12,000 feet – FL120 STD QNA – and am interested in 'hot' flyers who want to try air-to-air REFUELING (AAR) in suitably equiped aircraft, well ANY aircraft... The tanker will maintain, under autopilot, 220 knots (KTAS), at the said 12,000 feet, either 180 or 360, under the callsign GA006. The flights will commence about noon, or before, UTC, and close about 20:00 UTC. The track can be followed using http://test.fgx.ch, or other mp map URLS. Click on 'GA006' to localize... Reason: (a) I have tried with several aircraft over the last few days, and learned that this is QUITE difficult, but I hope NOT impossible! (b) The present suggested pps (Hz) is 10 when you set up –multiplay=, but FG 2.11 has fill-in extrapolation code when fgfs packets do not arrive in time, so maybe this is too high. This is the basic question... So the idea is to reduce this IFF this fill-in code helps, ie does its job... The theoretic idea is that with this code we can reduce the bandwidth used by 10 Hz to perhaps 2-4 Hz, but this needs to be FULLY tested, and confirmed... Now I have tried this over several day, in several aircraft – A-10, f-14b, a4 and failed, FAILED to touch the trailing drogues... it is TOUGH... autopilots help you get to the 'zone' but it needs manual flying to get to the RIGHT PLACE... If you are using a joystick maybe you need to even adjust the dead spot and the 'sensitivity' of the inputs... lots of learning, understanding and doing fgdata xml changes... And I have had a few pilots joining in ad hoc, but so far no one has actually contacted with the trailing outer wing drogues... The 'victor' can refuel 2 aircraft at a time... and I would LOVE to see/capture that... One, french I think, got so frustrated at his attempts, began firing missiles at the tanker. Thankfully, he MISSED, but was CLOSE ;=)) Also if you alert me to your attempt to refuel from my tanker, via mp chat, email, fgcom, … AND I am on board at the time -: (a) I will offer a VIRTUAL bottle of good Bordeau rouge to the first pilot who maintains drogue contact for say a minute, or more ;=)) (b) I will take some screen shots and post them. Be warned, during a screen shots (F3), fgfs stops sending mp packets for up to a second or so, and in the close fgfs the fill-in (extrapolation) code is activated, with some interesting, and sometimes quite alarming effects... Also I have heard others mention that the live metar update can also cause mp packet delays. The tanker will be flying under the 'Fair weather' scenario to avoid this. Maybe you should choose this as well... I really seek help from other pilots to analyse this multiplayer bandwidth situation. We have chosen 10 Hz, but WHY? Can less than 10 Hz be used with no adverse effect? That is the BIG question... Simply, what really is the optimum packets-per-second (pps) rate? Maybe it changes depending on circumstances... We know the lower the Hz the lower the bandwidth used by FGMS servers... but can the extrapolation code fill-in for the missing packets? Is 10 Hz good? Should it be higher, or lower depending on circumstance.. Lots to learn... Of course I am sure there are OTHER ideas... Hope you can help, and have some FUN at the same time;=)). Look forward to seeing you on my rear view... and I will take some pics... Regards, Geoff. CC: to users list... BCC: to others... -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reloading checklist
Hi Stuart thanks for the clue : This is what I did : var checklist=777-200-checklists.xml; var checklist_path=sprintf(%s/%s,getprop(/sim/aircraft-dir),checklist); print(checklist_path); var data = io.read_properties(checklist_path,/sim/checklists); It does reload the checklists but conditions are not evaludated JY On Wed, Apr 10, 2013 at 11:01 PM, Stuart Buchanan stuar...@gmail.comwrote: Hi Jean-Yves, On Mon, Apr 8, 2013 at 8:27 PM, Jean-Yves LEBLEU wrote: Hello, I have started to write checklists for 777, is there any way to reload the checklist without restarting flightgear, I tried with shift-esc with no success. Or maybe there is a little nas script to do the trick ? Yes, this should be possible, provided your checklists are in a separate file. See Nasal/io.nas and the read_properties() function. There are some examples in the comments around line 67. -Stuart -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reloading checklist
I made some more tests, conditions are evaluated properly On Thu, Apr 11, 2013 at 10:36 PM, Stuart Buchanan stuar...@gmail.comwrote: On Thu, Apr 11, 2013 at 8:35 PM, Jean-Yves LEBLEU wrote: This is what I did : var checklist=777-200-checklists.xml; var checklist_path=sprintf(%s/%s,getprop(/sim/aircraft-dir),checklist); print(checklist_path); var data = io.read_properties(checklist_path,/sim/checklists); It does reload the checklists but conditions are not evaludated Hi Jean-Yves, It is strange that the conditions are not evaluated. Have you had a look using the property browser to see if the property structure is as you would expect? It might be worth trying deleting the /sim/checklists node first, something like: props.globals.getNode(/sim).removeChild(checklists); -Stuart -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Air-to-air refuelling enhancement
Le 10/04/2013 22:57, Stuart Buchanan a écrit : I've (finally) managed to add the code to allow offsets for the tanker fuelling positions and the receivers probe position. See the A-4F for an example of how to set this. One can now use small envelope sizes and use the relative drogue and probe position to refuel. thanks Stuart, will have a try this week end (and thanks for the thanks :) ) one more bug (was my mistake ): in tanker .nas, we need to normalise the degre in line 26O-261 to have: me.hOffsetN.setDoubleValue(view.normdeg(me.bearing - ac_hdg)); me.vOffsetN.setDoubleValue(view.normdeg(elev - ac_pitch)); this was done in the 2.10.1, but not in next ( i sent you a mail probably lost in the numerical world). jano -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Reloading checklist
Hello, I have started to write checklists for 777, is there any way to reload the checklist without restarting flightgear, I tried with shift-esc with no success. Or maybe there is a little nas script to do the trick ? Thanks for any answer. Jean-Yves -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] merge request on fgdata
Hello all, Just to know, is it worth to send merge request on fgdata on gitorious ? I have sent a merge request to a new parking.xml file. No worry, just to understand the process and if I can continue to add new parking position to airports. Thanks for the great work an improvment on flightgear. Jean-Yves -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Segmentation fault 2.10
Hi all, I am trying to run a master slave configuration of flightgear, as soon as the master connects to the slave, the slave crash. I use flightgear PPA installation on ubuntu Linux jylebleu-ThinkPad-T520 3.5.0-25-generic #39-Ubuntu SMP Mon Feb 25 19:02:34 UTC 2013 i686 i686 i686 GNU/Linux Here is the end of the debug output : Adding flight: ALASKA7558 IFR KGEG KSEA 290 6/22:30:00 6/23:37:00 WEEK DH4-ASA Adding flight: ALASKA7559 IFR KTUS KSEA 320 1/11:00:00 1/15:05:00 WEEK 73H-ASA Adding flight: ALASKA7559 IFR KTUS KSEA 320 2/11:00:00 2/15:05:00 WEEK 73H-ASA Adding flight: ALASKA7559 IFR KTUS KSEA 320 0/11:00:00 0/15:05:00 WEEK 73H-ASA Adding flight: ALASKA7559 IFR KTUS KSEA 350 1/11:00:00 1/15:05Running Main Loop === Current Unix calendar time = 1362809353 warp = 0 Current GMT = 3/9/2013 6:9:13 Current Unix calendar time = 1362809353 warp = 0 Current GMT = 3/9/2013 6:9:13 Current Julian Date = 2.45636e+06 COURSE: GMT = 2/9/113 6:09:13 March 21 noon (GMT) = 1363867200 Time since 3/21/113 GMT = -12.2436 days = -12 hours = 6.15361 lon = 0 lst = 17.3536 COURSE: GMT = 2/9/113 6:09:13 March 21 noon (GMT) = 1363867200 Time since 3/21/113 GMT = -12.2436 days = -12 hours = 6.15361 lon = 122.357 lst = 9.19646 Current lon=0.00 Sidereal Time = 17.2935 gst = 329.293 Current LOCAL Sidereal Time = 9.13632 (9.13635) (diff = -0.0601449) Success reading data. Success reading data. Success reading data. trigger listener #117 trigger listener #124 Success reading data. trigger listener #124 ./start_fgfs_slave: line 15: 3890 Segmentation fault (core dumped) fgfs --verbose --log-level=debug --aircraft=c172p --fg-root=/usr/share/games/flightgear/ --fg-scenery=/usr/share/games/flightgear/Scenery --disable-random-objects --native-fdm=socket,in,60,,5510,udp --native-ctrls=socket,in,60,,5511,udp --fdm=null --disable-hud --disable-sound --prop:/sim/ai/enabled=false --prop:/sim/ai-traffic/enabled=false --prop:/sim/rendering/bump-mapping=false --prop:/sim/rendering/draw-otw=false Here is the content of the about box : gl-vendor:Intel Open Source Technology Center gl-version:3.0 Mesa 9.0.2 gl-renderer:Mesa DRI Intel(R) Sandybridge Mobile x86/MMX/SSE2 gl-shading-language-version:1.30 Shoult I open a bug, or give more information ? Thanks for your help. Regards. Jean-Yves -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Air-to-air refuelling enhancement
Le 24/02/2013 23:44, Stuart Buchanan a écrit :
Hi All,
I've just committed some small changes to the AI air-to-air refueling
function:
1) Added support for multiple tankers of each type, selectable through
the AI-Tankers GUI. Tankers are now defined in AI/tankers.xml.
2) Added an A-4F buddy tanker.
3) Enhanced the UI to allow the user to set the speed of the tanker,
and the radius at which contact is made. Note that this is based on
the origin of tanker and user. As a future enhancement I want to add
offsets to indicate the position of the refuelling probe/receiver
on the user aircraft, and the location of the boom/drogue on the tanker.
4) Added a user-toggled function to display messages when contact i
made or lost. Some aircraft
don't seem to have any obvious cockpit indicator that refuelling is in
progress, and we don't currently animate the probe being in the drogue
:)
5) Added maximum fuel flow definitions to both the tanker and
receiver. While the KC-135 supports
flow of 6000 lbs/min, smaller tankers (such as the A4-F buddy tanker)
only provided ~1300 lbs/min. the actual fuel flow is taken as the
minimum of the two.
Note that the maximum fuel flow affects both AI and MP tankers. I've
been unable to test with the latter, but have set a default to ensure
backwards compatibility.
Feedback welcome as always.
-Stuart
hi Stuart,
after a few runs behind ai tankers, and some crashs in the sky, i think
the a4f need to have at least the drogue and hose not hot.
here's a diff :
--- a/Models/Geometry/A4-F/a4-f-tanker.xml
+++ b/Models/Geometry/A4-F/a4-f-tanker.xml
@@ -14,6 +14,12 @@
object-nameFixedCanopyGlass/object-name
object-nameCanopy_1/object-name
/effect
+
+ animation
+ object-nameHose/object-name
+ object-nameDrogue/object-name
+ enable-hotfalse/enable-hot
+ /animation
model
pathPilot/pilot.xml/path
the radius definitely need the offsets , i was unable to make contact in
the usual position with a short radius :)
when you're in tanker.nas , I think that in turns, the tanker don't have
a rotation correct respect to the bank angle, when you follow you don't
have the same bank angle and it's a bit strange. here i got a much
better behaviour with this patch:
--- a/Nasal/tanker.nas
+++ b/Nasal/tanker.nas
@@ -155,7 +155,7 @@ var Tanker = {
}
var distance = dt * (me.ktas - me.headwind) * NM2M / 3600;
- var deviation = me.roll ? 0.5 * dt * 1085.941 *
math.tan(me.roll * D2R) / me.ktas : 0;
+ var deviation = me.roll ? dt * 1085.941 *
math.tan(me.roll * D2R) / me.ktas : 0;
if (me.mode == leg) {
if (me.lastmode != leg) {
jano
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Goals for the 3.0 release
- AI Tanker enhancements to allow users to select from a range of tanker models. This is particularly relevant for naval probe-equipped aircraft, where there is a much greater variety of tanker types. Could we also tighten the envelope in which we receive fuel? I did AAR with the F-16 yesterday, and my tanks were basically full by the time I had reached the actual refueling position... I started getting contact ~50 m away from the tanker ?! I was already planning to make the refuelling point configured on a per-tanker basis, as obviously different aircraft have different (sometimes multiple) refuelling positions. It sounds like it would be worth having a slide to allow the user to configure how large the envelope is as well. a slider seems good to me, as the code is used for the mp tanker too, and i think the box was done this size to allow mp refueling with some jitter effects. jano -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] (JSBsim) body accelerations
Le 19/12/2012 17:54, James Turner a écrit :
On 19 Dec 2012, at 16:22, Curtis Olson wrote:
Gyros: /orientation/{p,q,r}-body
Accelerometers: /accelerations/pilot/{x,y,z}-accel-fps_sec
Both of these are expressed in the pilot/body frame of reference. The
accelerometer values include gravity. I've used these to drive a 15 state
kalman filter and observe good attitude estimate convergence for both yasim
and jsbsim aircraft.
Right - but I think exposing the values without gravity added in is useful,
and the for the internal (C++) value, the Yasim one doesn't include gravity,
so neither should then JSBsim value (both FDMs compute both variants
already!). Then we could start exposing linear accelerations over MP (or a
future MP system) and make the prediction better. (And obviously that
prediction won't want to include gravitational terms)
James
hi, my two cents, as someone interested in better formation flight.
First, about using FGAccelerations::GetUVWdot as acceleration, i'm not
sure you will have what you want. i'm trying to do (slowly) something
about the lag ( http://wiki.flightgear.org/Mp-patch ), and i tried to
use UVWdot, but seems to me it give the dérivative of the speed in the
aircraft reference, not the acceleration in ECEF, expressed in body
coordinate.
if the speed vector is stable/aircraft, UVWdot will be 0, but the the
body acceleration can be huge in inertial referential. (that's how i
understand the effect i see, and the UVWdot props variation in constant
g turns, i didn't went to understand the jsbsim code ;)
second, could it be possible to have a look at other fdm properties wich
are inconsistent between yasim and jsbsim ?
i think of velocity_wind_body (maybe a velocity_body is needed) (bug 202)
and bug 901 (orientation/side-slip-deg)
chears
jano
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)
Le 16/11/2012 15:27, Torsten Dreyer a écrit :
Hi,
in just about one month from now we are entering another round of the
release process, starting with the four weeks feature freeze period.
This is probably a good time to check in all the great and fancy new
features that still hide in your local branches.
hi, not a fancy new feature, but could someone apply this diff to
tanker.nas?
it's to make the hud markers work whith the ai tanker, for those who
want to cheat a little :)
http://janodesbois.free.fr/fg_screens/2012/fgfs-screen-002.jpg
jano
diff --git a/Nasal/tanker.nas b/Nasal/tanker.nas
index 4bca859..54d7183 100644
--- a/Nasal/tanker.nas
+++ b/Nasal/tanker.nas
@@ -112,6 +112,7 @@ var Tanker = {
m.ai.getNode(navaids/tacan/channel-ID, 1).setValue(m.tacan);
m.ai.getNode(refuel/type, 1).setValue(type);
m.ai.getNode(refuel/contact, 1).setBoolValue(0);
+ m.ai.getNode(radar/in-range, 1).setBoolValue(1);
m.latN = m.ai.getNode(position/latitude-deg, 1);
m.lonN = m.ai.getNode(position/longitude-deg, 1);
@@ -125,6 +126,8 @@ var Tanker = {
m.brgN = m.ai.getNode(radar/bearing-deg, 1);
m.elevN = m.ai.getNode(radar/elevation-deg, 1);
m.contactN = m.ai.getNode(refuel/contact, 1);
+ m.hOffsetN = m.ai.getNode(radar/h-offset, 1);
+ m.vOffsetN = m.ai.getNode(radar/v-offset, 1);
m.update();
m.model.getNode(path, 1).setValue(type == boom ? boom_tanker : probe_tanker);
@@ -202,7 +205,9 @@ var Tanker = {
var dalt = alt - me.ac.alt();
var ac_hdg = getprop(/orientation/heading-deg);
-
+ var ac_pitch = getprop(/orientation/pitch-deg);
+ var elev = math.atan2(dalt, me.distance) * R2D;
+
me.latN.setDoubleValue(me.coord.lat());
me.lonN.setDoubleValue(me.coord.lon());
me.altN.setDoubleValue(alt * M2FT);
@@ -213,9 +218,12 @@ var Tanker = {
me.vertN.setDoubleValue(0);
me.rangeN.setDoubleValue(me.distance * M2NM);
me.brgN.setDoubleValue(me.bearing);
- me.elevN.setDoubleValue(math.atan2(dalt, me.distance) * R2D);
+ me.elevN.setDoubleValue(elev);
me.contactN.setBoolValue(me.distance 76 and dalt 0 # 250 ft
and abs(view.normdeg(me.bearing - ac_hdg)) 20);
+
+ me.hOffsetN.setDoubleValue(me.bearing - ac_hdg);
+ me.vOffsetN.setDoubleValue(elev - ac_pitch);
var droll = me.roll_target - me.roll;
if (droll 0) {
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] broken embedded nasal ?
Hi, seems the embedded nasal doesn't work anymore for me, liverie update and some alias stuff doesn't work on mp models. this is with afresh git fg, and tested by using 127.0.0.1 as server. I tried a few planes and it was the same... jano -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] About the bug 385
Le 03/03/2012 23:12, ThorstenB a écrit : Am 03.03.2012 03:28, schrieb Robert: 2012/3/2 ThorstenBbre...@gmail.commailto:bre...@gmail.com But we don't know why this only happens with the ATI, only with their driver versions 11.5 and above, and only on Windows. Thorsten, this bug is also present on Linux (in my case), and I think I have read in the google bug-reports that OSX is affected, too. Never heard anyone reporting the issue for Linux. Indeed, there was a related bug for Mac (#356), but that was reported to be fixed with OSG 3.0.1, only leaving an ugly effect (whatever that is). Anyway, anyone reproducing the issue and capable of compiling FG 2.7.0/Git could help by providing the terminal output when running a debug patch, see #385, comment 41 for details: http://code.google.com/p/flightgear-bugs/issues/detail?id=385#c41 cheers, Thorsten Hi, thanks for the patch, as I am on linux and affected by the bug (and the one complaining the most), I guess i will try it, BTW, whitch OSG version do i have to use? last devel version is ok? cheers jano -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] About the bug 385
Hi, happy ati user :) I'm affected from quite some time by the bug 385: http://code.google.com/p/flightgear-bugs/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestonegroupby=sort=id=385#makechanges It appear in my setup that adding a radar section in the intrumentation.xml (or any name called by the instrumentation field in the -set.xml file) solve the bug, for all the planes tested (b1900d, bo105, iar80, super constellation etc...) radar namewxradar/name number0/number /radar - is there some clue why the radar can have such an impact? - is it possible to add the radar section to the aircrafts in the base package affected by the bug, or do we have to buy nvidia again? jano -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees
Le 11/01/2012 18:59, Mathias Fröhlich a écrit : Hi, On Sunday, January 01, 2012 11:41:22 Mathias Fröhlich wrote: I think then, computing mipmaps for any texture file on the CPU in the loader thread should globally improove the situation. Also avoiding the compression already in the files should help every use case. Except that the on disk memory consumption is higher. Well and except that the database loader has more work to do on the CPU. Ok, checked in is a log message that checks for image formats that depend on OpenGL extensions not required to be present. That should at least help people running drivers providing those extensions to see when they use texture files that do not work fo all. Greetings Mathias is there an easy way to disable this message? since i'm using dds texture, it's flooding the console... jano -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Le 29/12/2011 14:16, Mathias Fröhlich a écrit : Hi Erik, On Thursday, December 29, 2011 13:33:09 Erik Hofman wrote: Setting compression to 'none' does speed up texture switching considerably. Unfortunately there's little difference in switching from internal to external view for the first time. Thanks. I do also see an initial frame drop on switching views with the f16. That is with or without textures that could be uploaded. I do have read somewhere that generating mipmaps can also be slow for some drivers (NVidia?) and the dds textures provided pre generated mipmaps. That's probably what I wrote now several times. And over the time where I had different drivers installed on this current machine and over the machines that I had access to using an nvidia driver it looks like this being a problem. this is the same here with fglrx driver, so not a particular driver issue, but may be the mipmap generation? for me as a multiplayer pilot, dds (with pregenerated mipmap) is the way to go, as it provide me (with a luckily dds compliant driver) a better flightgear experience with dds textures (materials and planes): smoother flight, mp planes converted load faster, no more age to pass on external view for the first time or change livery. [...] jano -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] about close formation flight
Hi, I'm trying to do something about the lag and the rubber band phonomen. In local lan, with recorded session, that works quite well, see: http://www.youtube.com/watch?v=LyBUPlf5NSwfeature=youtu.be Next is to test this with other multiplayers, and too bad the men interested are on windows, could someone give us a patched windows binary? the patch: http://janodesbois.free.fr/a_virer/mp_2011_12_06.diff I started a wki page about the film, do you think it's a good place to speak about multiplayer code improvement? http://wiki.flightgear.org/Toward_real_close_formation_flight jano -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
Le 13/02/2011 23:32, henri orange a écrit : Hi, Peter I have done from an old code by Gérard a process which answer to the request. It adjust the altitude of the Carrier, when cruising, according to the visual surface of the water. But mistake, it does answer to any condition, including the Tsumani effect when two tiles are not the same hight. The presentation of the project is there: http://www.flightgear.org/forums/viewtopic.php?f=4t=11043 http://www.flightgear.org/forums/viewtopic.php?f=4t=11043 It should, could, must, be improved. Hi, Jean I have tried to use your patch, i could not get it to work. Seems to get the same issue than with an old version by Gérard. geodinfo is giving the terrain_hight, which is the carrier Deck surface not the water surface. hi henri, my patch is only for the mp carriers when you command it, not for the ai carriers, and the position of the point from wich geodinfo is used works fine (here) with the Nimitz, Vinson, Eisenhower and clemenceau. but you need to have a non solid wake, and no deck below the reference point you consider to use geodinfo. jano -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
Le 25/01/2011 21:07, Peter Brown a écrit :
On Jan 25, 2011, at 2:55 PM, Vivian Meazza wrote:
Is there a problem with maintaining vertical sync with MPCarrier? If
there is please file a report here:
http://code.google.com/p/flightgear-bugs/issues/list
Vivian
No Vivian,
Curt suggested that carriers do a terrain height check and follow the
polygon curvature of the FlightGear world.
Not knowing if there was something in place to maintain sync with
vertical change, I commented that that would be a great idea if possible.
Peter
hi, here's a diff to have the mp carrier follow the sea level , if you
find something usefull in it.
I didn't test it recently against the tsunami crossing the sea, but
was working months ago.
jano
diff --git a/Aircraft/MPCarrier/Systems/commander.nas b/Aircraft/MPCarrier/Systems/commander.nas
index 1a85867..f49f5c5 100644
--- a/Aircraft/MPCarrier/Systems/commander.nas
+++ b/Aircraft/MPCarrier/Systems/commander.nas
@@ -31,6 +31,7 @@ var c_control_rudder = surface-positions/rudder-pos-deg;
var c_control_mp_ctrl = controls/mp-control;
var c_control_radius = controls/turn-radius-ft;
+var index = 0;
# Player constants
var p_lat = /position/latitude-deg;
@@ -168,6 +169,24 @@ var toggleAIControl = func {
}
gui.popupTip(((AI_control) ? AI : Manual) ~ control.)
}
+###
+var ground_contact = func {
+ # set speed to 0 if near #
+ if (getprop(/ai/models/carrier[ ~ index ~ ]/controls/base-speed-kts) == 0) {
+if (getprop(/ai/models/carrier[ ~ index ~ ]/velocities/speed-kts) 0.2) {
+ interpolate(/ai/models/carrier[ ~ index ~ ]/velocities/speed-kts,0,5)
+}
+ };
+ # try to keep the boat on the sea #
+ # be sure to have a wake non solid or the boat will climb to the moon :)
+ # the test point is supposed to be above the tsunami hight, but long time not tested
+
+ var geo_coord = geo.aircraft_position().apply_course_distance((carrier_base.getNode(c_heading).getValue()+75), 50);
+ var info = geodinfo(geo_coord.lat(),geo_coord.lon());
+ var time = 10;
+ interpolate(/ai/models/carrier[ ~ index ~ ]/position/altitude-ft,(info[0]*M2FT +2),time);
+ settimer(ground_contact,time);
+}
###
var init = func {
@@ -187,6 +206,9 @@ var init = func {
MPCarriersNW);
MPCarriersNW.mp_network_init(1);
+ settimer(ground_contact,200); # get error if the water is not present when first check,
+# wich some time take times...
+
# Make sure the current speed and course will be transmitted.
setprop(p_control_speed,
carrier_base.getNode(c_control_speed).getValue());
@@ -208,6 +230,8 @@ var init = func {
p = controls/tgt-speed-kts;
props.globals.getNode(p, 1).alias(carrier_base.getNode(p));
+ index = carrier_base.getNode(id).getValue() - 1;
+
# Avoid ugly error messages if the current carrier doesn't
# have a walk view.
if (!contains(globals, walkview)) {
diff --git a/Models/Geometry/Nimitz/eisenhower.xml b/Models/Geometry/Nimitz/eisenhower.xml
index a625091..3bffac9 100644
--- a/Models/Geometry/Nimitz/eisenhower.xml
+++ b/Models/Geometry/Nimitz/eisenhower.xml
@@ -338,6 +338,7 @@ apart from most of the very excellent textures, remain. --
y0/y
z-1/z
/axis
+enable-hot type=boolfalse/enable-hot
/animation
animation
typetranslate/type
diff --git a/Models/Geometry/Nimitz/nimitz.xml b/Models/Geometry/Nimitz/nimitz.xml
index db63b2f..c70e950 100644
--- a/Models/Geometry/Nimitz/nimitz.xml
+++ b/Models/Geometry/Nimitz/nimitz.xml
@@ -361,6 +361,7 @@ apart from most of the very excellent textures, remain. --
y0/y
z-1/z
/axis
+enable-hot type=boolfalse/enable-hot
/animation
animation
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] carrier questions
Message du 10/12/10 10:14 De : Vivian Meazza A : 'FlightGear developers discussions' Copie à : Objet : Re: [Flightgear-devel] carrier questions Hi Curt, Yup, if you are in a AAR-capable aircraft, click on AI-AITanker. Click Request in the window displayed, and a tanker will be instantiated nearby. The controller will tell you where it is relative to your current position. Hope it still works! I haven't tested it for several years. Vivian yes it still works, it use the kc135 for the boom aircraft, and the ka-6 for the probe equiped aircrafts, (a little more challenging to spot). you can use a victor or a KC130 instead, but they don't have an ai model. IIRC the altitude given is MSL, not fligth level. jano -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] carrier questions
Le 03/12/2010 20:28, Curtis Olson a écrit : On Fri, Dec 3, 2010 at 1:04 PM, Jan Mattsson wrote: 1. 9 degrees: http://en.wikipedia.org/wiki/Nimitz_class_aircraft_carrier 2. 3-4 degrees: http://en.wikipedia.org/wiki/Modern_US_Navy_carrier_operations Hi Jan, Thanks for your reply. What I'm wondering though is for the FlightGear Nimitz, what glide slope approach path puts me in the sweet spot of the FLOLS? after a look in Models/Geometry/Nimitz/Models/flos.xml, the optimal path is 3.5 degres, and in nimitz.xml, the flos got an offset of 8 degres, not sure if that correspond to the deck orientation. jano -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] surface positions no more exported by mp.
hi i'm here to report a bug: from commit d39841d in flightgear, the surface positions are not sent anymore. the properties in ai/models/multiplayer[i]/surface-positions/ have a value of : (none). that still works with players using older fg version. if you want to quickly test this just use 127.0.0.1 as output server address, you will see yourself and the mp-you in the same time. a solution is to add the properties to the -set files, but I,m not sure to be volunter to do this in all the data :D have a nice day jano -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about mp refueling
Le 29/08/2010 11:16, Vivian Meazza a écrit :
jean pellotier wrote
Le 28/08/2010 22:49, Vivian Meazza a écrit :
AFAIKS in the code an aircraft gets a TACAN if the callsign is MOBIL1
(060X), MOBIL2 (061X), or MOBIL3 (062X). On the other hand if the
callsign
includes MOBIL, it is recognized as a tanker on MP. The property
'isTanker'
is not transmitted by default over the net and is not handled on
receipt. It
is set to 'false' for all mp aircraft, and is only set to true if the
callsign contains MOBIL is the first part.
The tanker property is used in aar.nas to determine if refueling takes
place.
Hmm ... this one needs a bit more investigation ... mainly to remind
myself
what I did in the first place :-).
you're right, and thinks are now more clear to me. in fact the change in
the tanker property is taken in account by aar.nas, so exporting it by
mp will work.
I just wanted not to be forced to use a MOBIL callsign to do refueling
by mp, this function should be enabled only by the tanker property.
Hmm - the code doesn't set tanker to false if it can't find MOBIL in the
callsign. So if you set tanker to true on MP - that might work.
the code doesn't set tanker to false, but never set contact to true line
462 in AIMultiplayer.cxx, starting with:
if ( isTanker) {
and without contact, no refueling ...
to summarry: the c++ code only test the tanker contact if the callsign is a
MOBIL, and aar.nas use the tanker property and
the contact to allow refueling.
my code use the tanker property instead of the callsign test in the c++ code,
but i'm not sure this is the best way to go.
I think there is a chance that you can already do what you want. If you
would like to try?
we are a lot who tried a refuel without a MOBIL tanker, without a
success so far, and the question they ask is what's wrong, i took a
tanker, and refueling is impossible?
Vivian
jano
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about mp refueling
Le 28/08/2010 20:01, Vivian Meazza a écrit : jean pellotier wrote: currently we can only refuel by mp behing a MOBIL plane, with a plane having the multiplay/tanker set. here's a proposal that permit to use any callsign (yes i know in this case the tanker will not have a tacan working), and any plane, for exemple the tanker pilot can cut the probe/drogue alimentation, or with adding a refueling pod any plane can become a tanker if a c++ guru can have a look and commit (any comment welcome, my c++ skills are just at a beguinner state). the victor is waiting for this (or something similar), with a refuelling available by mp only when the drogue is out . It is already the case that any aircraft can become a tanker simply by using a callsign starting MOBIL by using the callsign MOBIL, we just have a tacan, and are able to be used as tanker only if the plane has multiplay/tanker set to true, so this only works for some planes (victor, c130 and kc135), and to have a working refueling, the tanker pilot must have a MOBIL callsign. I'm not quite sure what you want here. Would I be correct in saying that you want to be able to switch the tanker status on and off over MP? If so - I think that is a good idea, and one that was intended from the outset, but never got implemented. (I cant remember why - I think it just got lost). I want two things: permit a working refueling with whatever callsign you want, even if the tacan can only be used with MOBIL callsigns, and the second is to be able to switch the tanker on/off status while flying, eg if your drogue is not deployed (got the victor ready for this), or if you are low in fuel (for the day the tanker fuel content will be impacted by the refueling). Another concern is that in case we are using a refueling pod, a lots of planes can be used as casual tankers. If so I'll get on the case. if so many thanks. Vivian jano -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about mp refueling
Le 28/08/2010 22:49, Vivian Meazza a écrit : AFAIKS in the code an aircraft gets a TACAN if the callsign is MOBIL1 (060X), MOBIL2 (061X), or MOBIL3 (062X). On the other hand if the callsign includes MOBIL, it is recognized as a tanker on MP. The property 'isTanker' is not transmitted by default over the net and is not handled on receipt. It is set to 'false' for all mp aircraft, and is only set to true if the callsign contains MOBIL is the first part. The tanker property is used in aar.nas to determine if refueling takes place. Hmm ... this one needs a bit more investigation ... mainly to remind myself what I did in the first place :-). you're right, and thinks are now more clear to me. in fact the change in the tanker property is taken in account by aar.nas, so exporting it by mp will work. I just wanted not to be forced to use a MOBIL callsign to do refueling by mp, this function should be enabled only by the tanker property. jano -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] about mp refueling
Hi,
currently we can only refuel by mp behing a MOBIL plane, with a plane
having the multiplay/tanker set.
here's a proposal that permit to use any callsign (yes i know in this
case the tanker will not have a tacan working), and any plane, for
exemple the tanker pilot can cut the probe/drogue alimentation, or with
adding a refueling pod any plane can become a tanker
if a c++ guru can have a look and commit (any comment welcome, my c++
skills are just at a beguinner state).
the victor is waiting for this (or something similar), with a refuelling
available by mp only when the drogue is out .
jano
diff --git a/src/AIModel/AIMultiplayer.cxx b/src/AIModel/AIMultiplayer.cxx
index d2fb505..be90190 100644
--- a/src/AIModel/AIMultiplayer.cxx
+++ b/src/AIModel/AIMultiplayer.cxx
@@ -51,18 +51,8 @@ FGAIMultiplayer::~FGAIMultiplayer() {
bool FGAIMultiplayer::init(bool search_in_AI_path) {
props-setStringValue(sim/model/path, model_path.c_str());
//refuel_node = fgGetNode(systems/refuel/contact, true);
-isTanker = false; // do this until this property is
- // passed over the net
+isTanker = false; // set the tanker property to false by default for all mp aircrafts
-string str1 = _getCallsign();
-string str2 = MOBIL;
-
-string::size_type loc1= str1.find( str2, 0 );
-if ( (loc1 != string::npos str2 != ) ){
-// cout string found str2 in str1 endl;
-isTanker = true;
-// cout isTanker isTanker mCallSign endl;
-}
return FGAIBase::init(search_in_AI_path);
}
@@ -70,7 +60,8 @@ void FGAIMultiplayer::bind() {
FGAIBase::bind();
props-tie(refuel/contact, SGRawValuePointerbool(contact));
-props-setBoolValue(tanker,isTanker);
+//props-setBoolValue(tanker,isTanker);
+props-tie(tanker, SGRawValuePointerbool(isTanker));
props-tie(controls/invisible,
SGRawValuePointerbool(invisible));
@@ -102,6 +93,7 @@ void FGAIMultiplayer::unbind() {
props-untie(controls/lag-adjust-system-speed);
props-untie(controls/invisible);
props-untie(refuel/contact);
+props-untie(tanker);
}
void FGAIMultiplayer::update(double dt)
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] material error
Le 09/08/2010 21:22, syd adams a écrit : Hi folks , hope someone can point me in the right direction ... I just did a new git clone of flightgear , simgear, fgdata (deleted all local copies first) , and recompiled all last night. I now get this error : Error building technique: findAttr: could not find attribute bool which is generated here : simgear/scene/material/makeEffect.cxx the aircraft Ive tried now have no interior textures , and transparent lights are black squares ... scenery appears to be normal though. My first thought was I missed files during the download , but everything does seem to be there does anyone else see this ? Cheers i had something similar some time ago, but not sure this was the same message, this was because of a bad git branch for simgear, as tim guessed. with simgear and flightgear in next, and fgdata in master, the problem went away. jano -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] aircraft search
Le 23/07/2010 22:03, Alex Romosan a écrit : Alex Romosanromo...@sycorax.lbl.gov writes: James Turnerja...@bugless.co.uk writes: Can you email me what you get for --show-aircraft? (off list, is best) fgfs --show-aircraft Available aircraft: (that is nothing). this on linux. on non ext* file systems readdir doesn't return the file type in d_type so this explains why i kept getting an empty list for show-aircraft (my flightgear directory is on reiserfs). i've already sent the patch to james, but maybe somebody else also wants to give it a try (works for me). --show-aircraft works here with the patch, same as you, datas on a reiserfs file system, and now planes which were impossible to lauch are ok . jano -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Stuart Buchanan a écrit : Providing a higher granularity of control would be tricky but not impossible - I guess you could define a list of model names that are to be loaded completely... could it be done per callsign, like the ignore chat message check box, with maybe a command line option to set specific callsign in the load detailled group? In case of formation flight (or dual control) we know the others callsign we want to have detailled planes, and not to load others models is sometimes good for the (not) induced lag, this can make possible formation aérobatics without too much lag from model loading. my two cents... jano -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Negative-drag-bug in 20 aircraft models
andrea...@gmx.net a écrit : Hi everyone! I think I found a little bug in a couple of JSBSim-aircraft: The property /fdm/jsbsim/aero/coefficient/CDde (Drag_due_to_Elevator_Deflection) takes negative values when the elevator moves up, so the elevator face is accelerating the plane. The wrong code is found in the model.xml file: [...] The next list contains aircraft that have the bug, but it doesn't take any effect because elevator-pos-norm is always zero. (Who can tell me why?) victor - for this one i submitted a modified version to the author a month ago, but it didn't reached CVS yet (and i don't have his mail so I can't tell what's going on) here it is: http://janodesbois.free.fr/doc/victor.tar.gz -added *-norm properties -animated aero control surfaces -working as tanker, and can be refueled too jano -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader issue on ATI cards
Stuart Buchanan a écrit : Hi All, A number of people with ATI cards are having problems with the default shaders on the current windows v2.0.0 RC: http://www.flightgear.org/forums/viewtopic.php?f=6t=6875sid=b02b4d5ebd4c827ca26fc60fd857dda7p=64237#p64237 Does anyone on the -dev list have an ATI card that is working (or not) with the shader options? I've had a look at the shader code and I can't see anything wrong, but I don't have a working FG computer right now to experiment with. -Stuart here are the screens of some issues with my HD4650: the color change done to close/far field (gren/red/darker): http://janodesbois.free.fr/fg_screens/decembre09/screens_fg_windowsXP/ and some clouds and others, specialy if the sun is low on horizon (starting from number20): http://janodesbois.free.fr/fg_screens/2010_janvier/ the 32-38 serie is turning with the propeller. this was with a windows binary from november i think, i didn't test the 2.0 binary yet on windows. on debian sid, i'm using the radeon driver so am unable to use flightgear, except low poly jsbsim planes without scenery, but with an ubuntu recently installed i've got the same color change. jano -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader issue on ATI cards
Arnt Karlsen a écrit : On Thu, 11 Feb 2010 13:21:32 +0100, Geoff wrote in message 1265890892.6457.3.ca...@dell02: On Thu, 2010-02-11 at 10:45 +, Stuart Buchanan wrote: jean pellotier wrote: here are the screens of some issues with my HD4650: the color change done to close/far field (gren/red/darker): ..you are running Ubuntu 8.04LTS with ATI's proprietary fglrx, or is there a Catalyst driver too? Have you tried a recent Live CD or Live USB with radeon, radeonhd and fglrx on your box? ..x.org's docs trails development a bit, radeonhd was supposed to support the newer cards better than radeon, but radeon looks like it's winning the race: ;o) http://www.x.org/wiki/RadeonFeature http://www.x.org/wiki/radeonhd:feature http://www.x.org/wiki/Projects/Drivers On ubuntu karmic i use the provided fglrx driver (9.12) and on windows xp both the 9.12 and 10.01 catalyst driver (the hotfix version) (but didn't test windows for a while). my main OS is a debian sid, with a git radeon, but glsl are not implemented yet (rv730) . glxinfo give me: OpenGL shading language version string: 1.10 and fg run too slowly, but kompiz is fine. a temporary fix is to remove the gl_FrontMaterial.ambient part in 3 files, and so i have no more dark/blue/green super FX, but don't ask me to say why :) . that works with the crop and landmass. here's the diff: jano Index: Shaders/crop.frag === RCS file: /var/cvs/FlightGear-0.9/data/Shaders/crop.frag,v retrieving revision 1.1 diff -u -r1.1 crop.frag --- Shaders/crop.frag 8 Aug 2009 10:17:59 - 1.1 +++ Shaders/crop.frag 11 Feb 2010 23:11:07 - @@ -59,7 +59,7 @@ c1 = mix(c1, clamp(n+nvL[2]*4.1+vec4(0.1, 0.1, nvL[2]*2.2, 1.0), 0.7, 1.0), smoothstep(snowlevel+300.0, snowlevel+360.0, (rawpos.z)+nvL[1]*3000.0)); vec3 diffuse = gl_FrontMaterial.diffuse.rgb * max(0.0, dot(VNormal, gl_LightSource[0].position.xyz)); -vec4 ambientColor = gl_FrontLightModelProduct.sceneColor + gl_LightSource[0].ambient * gl_FrontMaterial.ambient; +vec4 ambientColor = gl_FrontLightModelProduct.sceneColor + gl_LightSource[0].ambient;// *gl_FrontMaterial.ambient; //ambientColor = vec4(0.01); vec4 ambient_light = ambientColor + gl_LightSource[0].diffuse * vec4(diffuse, 1.0); Index: Shaders/default.vert === RCS file: /var/cvs/FlightGear-0.9/data/Shaders/default.vert,v retrieving revision 1.4 diff -u -r1.4 default.vert --- Shaders/default.vert 19 Nov 2009 16:20:54 - 1.4 +++ Shaders/default.vert 11 Feb 2010 23:11:07 - @@ -22,7 +22,6 @@ halfVector = normalize(gl_LightSource[0].halfVector.xyz); diffuse = gl_Color * gl_LightSource[0].diffuse; alpha = gl_Color.a; -constantColor = gl_FrontLightModelProduct.sceneColor -+ gl_FrontMaterial.ambient * gl_LightSource[0].ambient; +constantColor = gl_FrontLightModelProduct.sceneColor + gl_LightSource[0].ambient; //*gl_FrontMaterial.ambient ; fogCoord = abs(ecPosition.z); } Index: Shaders/landmass.frag === RCS file: /var/cvs/FlightGear-0.9/data/Shaders/landmass.frag,v retrieving revision 1.1 diff -u -r1.1 landmass.frag --- Shaders/landmass.frag 8 Aug 2009 10:17:59 - 1.1 +++ Shaders/landmass.frag 11 Feb 2010 23:11:07 - @@ -44,7 +44,7 @@ c1 = mix(c1, clamp(n+nvL[2]*4.1+vec4(0.1, 0.1, nvL[2]*2.2, 1.0), 0.7, 1.0), smoothstep(snowlevel+300.0, snowlevel+360.0, (rawpos.z)+nvL[1]*3000.0)); vec3 diffuse = gl_FrontMaterial.diffuse.rgb * max(0.0, dot(normalize(VNormal), gl_LightSource[0].position.xyz)); -vec4 ambientColor = gl_FrontLightModelProduct.sceneColor + gl_LightSource[0].ambient * gl_FrontMaterial.ambient; +vec4 ambientColor = gl_FrontLightModelProduct.sceneColor + gl_LightSource[0].ambient; // * gl_FrontMaterial.ambient; //ambientColor = vec4(0.01); vec4 ambient_light = ambientColor + gl_LightSource[0].diffuse * vec4(diffuse, 1.0); -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with modified apt.dat file
Andrew Gillanders a écrit : Hello all, I am having trouble with an updated apt.dat file. I think it is with compressing it. I used the command 'tar cfz apt.dat.gz apt.dat'. Is this correct? to me it should be 'gzip apt.dat' BTW, you can put apt.dat uncompressed in FG, fg will load it instead of the apt.dat.gz, it's sometimes more convenient for checking changes. jano -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] navaids update
Martin Spott a écrit : Salut Jean, jean pellotier wrote: Is nav.dat supposed to be updated from robin X-plane database? If nobody else is going to do that, I'll be updating the file from Robin's most current package during our pre-release phase (however this is going to be defined ). I see the update is done, thanks, (and sorry for windows users waiting for a compatible binary build :) ). It appears that Atlas don't like the new nav.dat.gz, and crash on start up, because some navaids contains empty field for the balise name (i guess it's the balise name). here's a diff where the missing fields are replaced with IXXX. may be the real name is available, but i didn't found the few i checked. and Atlas don't crash anymore. jano 12062c12062 4 47.49051500 -111.20608600 3526 10950 18 238.500 KGFA 21 ILS-cat-I --- 4 47.49051500 -111.20608600 3526 10950 18 238.500 IXXX KGFA 21 ILS-cat-I 12103c12103 4 38.85886700 -094.55694100 1090 10930 18 11.886 KGVW 01 ILS-cat-I --- 4 38.85886700 -094.55694100 1090 10930 18 11.886 IXXX KGVW 01 ILS-cat-I 12393c12393 4 46.5362 -087.54817000 1419 11050 18 76.841 KMQT 08 ILS-cat-I --- 4 46.5362 -087.54817000 1419 11050 18 76.841 IXXX KMQT 08 ILS-cat-I 13389c13389 4 70.33308600 -149.56581800 67 10970 18 107.900 PAKU 05 ILS-cat-I --- 4 70.33308600 -149.56581800 67 10970 18 107.900 IXXX PAKU 05 ILS-cat-I 14125c14125 5 45.29766700 -072.73483300375 11070 18 36.999 CZBM 05L LOC --- 5 45.29766700 -072.73483300375 11070 18 36.999 IXXX CZBM 05L LOC 14255c14255 5 35.27726300 -089.66926600312 11155 18 153.681 KLHC 15 LOC --- 5 35.27726300 -089.66926600312 11155 18 153.681 IXXX KLHC 15 LOC 14372c14372 5 70.25181500 -148.35802800 45 10970 18 106.500 PUO 05 SDF --- 5 70.25181500 -148.35802800 45 10970 18 106.500 IXXX PUO 05 SDF -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] navaids update
Hi, I've got a question about the navaids, particularly nav.dat. Is nav.dat supposed to be updated from robin X-plane database? The french missing navaids I submited to robin ( approach locators ) are included in recent nav.dat from X-plane, and I was waiting them to come in Flightgear, but apparently we are using the version just before. here's a diff toward our current nav.dat with the missing french locators, if you find some interest in using french airports :) . jano --- fg_nav.dat 2009-12-14 11:22:24.0 +0100 +++ jjano_nav.dat 2009-12-14 11:22:02.0 +0100 @@ -1,6 +1,104 @@ I 810 Version - DAFIF data cycle 2007.09, build 20070106, metadata NavXP810. Copyright © 2007, Robin A. Peel (ro...@xsquawkbox.net). This data is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program (AptNavGNULicence.txt); if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. This product was developed using DAFIF (the Defense Aeronautical Flight Information File), a product of the US National Imagery and Mapping Agency (NIMA). NIMA requires the following warranty statements: (A) Under 10 U.S.C. 456, no civil action may be brought against the United States on the basis of the content of a navigational aid prepared or disseminated by either the former Defense Mapping Agency (DMA) or the National Imagery and Mapping Agency (NIMA). (B) The DAFIF product is provided as is, and no warranty, express or implied, including, but not limited to the implied warranties of merchantability and fitness for particular purpose or arising by statute or otherwise in law or from a course of dealing or usage in trade, is made by NIMA as to the accuracy and functioning of the product. ©: Neither NIMA nor its personnel will be liable for any claims, losses, or damages arising from or connected with the use of this product. The user agrees to hold harmless the United States National Imagery and Mapping Agency. The user's sole and exclusive remedy is to stop using the DAFIF product. +2 43.9122 002.0644528 323 250.0 AB Albi le Sequestre NDB +2 49.9762 002.80941666361 321 1500.0 ABY Albert Bray NDB +2 43.26527778 005.58638000590 366 250.0 ADC Le Castellet NDB +2 44.1505 000.6738156 400 250.0 AG Agen la Garenne NDB +2 45.7105 000.4269397 404 250.0 AGO Angouleme Brie Champniers NDB +2 44.9558 002.3680 2310 343 250.0 AR Aurillac NDB +2 47.5772 -000.1513305 292 250.0 AS Angers Marce NDB +2 45.8616 006.0205 2205 384 250.0 AT Annecy Meythet NDB +2 44.4422 004.3619676 427 250.0 AUB Aubenas Ardeche Meridionale NDB +2 46.88167000 002.92888955679 306 250.0 AV Avord NDB +2 47.9202 003.5022505 417 250.0 AX Auxerre Branches NDB +2 47.6108 002.7827528 405 250.0 BIC Briare Chatillon NDB +2 45.52027800 004.29889000 1371 299 250.0 BO Saint Etienne Boutheon NDB +2 46.2038 005.2888869 423 250.0 BOR Bourg Ceyzeriat NDB +2 42.4258 009.5375 33 369 250.0 BP Bastia Poretta NDB +2 45.6158 004.99278000 1076 388 250.0 BR Lyons Bron NDB +2 47.0175 002.2816509 375 250.0 BRG Bourges NDB +2 44.3652 -001.1288 92 358 250.0 BRS Biscarrosse Parentis NDB +2 47.2669 006.2025 1348 370 250.0 BSV Besancon la Veze +2 49.4916 002.0294377 391 250.0 BV Beauvais Tille NDB +2 44.5669 003.4691 4062 393 250.0 BX Mende Brenoux NDB +2 46.7216 004.8430656 391 250.0 CC Chalon Champforgeuil NDB +2 45.8044 003.3616 1066 367 250.0 CF Clermond Ferrand Auvergne NDB +2 49.0052 002.7402352 370 250.0 CGZ Paris Charles de Gaulle NDB +2 45.5925 005.88361100840 346 250.0 CH Chambery Aix les Bains NDB +2 48.0077 003.6961545 353 250.0 CHY Chailley NDB +2 44.38527778 001.4155951 348 250.0 CL Cahors Lalbenque NDB +2 43.2225 002.2077489 345 250.0 CS Carcassonne Salvaza NDB +2 43.5228 007.04527778 98 385 250.0 CSC Cannes Mandelieu NDB +2 41.7952 008.7241295 387 250.0 CT Ajaccio Campo dell'Oro NDB +2 48.7591 004.3188604 347
Re: [Flightgear-devel] Flight Gear on Windows
Vivian Meazza a écrit : Geoff, I agree with all you have said, but would add the following: The reset bug has been sorted. The crash-on-exit bug has probably been sorted, but I haven’t had time to test it yet. I don’t see the red/orange effect you report. got something like that too on linux, but guess what? with an ati card it's related to shaders, as once i remove the shader effects, scenary is ok. depending on sun and orientation, scenery get sudenly darker, or green, or blue affecting differently far and close field. some screens: http://janodesbois.free.fr/fg_screens/decembre09/fgfs-screen-005.png http://janodesbois.free.fr/fg_screens/decembre09/fgfs-screen-006.png http://janodesbois.free.fr/fg_screens/decembre09/fgfs-screen-024.png and an other (ati?) bug: if i have a look on the airport from obove vertically, then texture become a mess, and all is fine once shaders removed: http://janodesbois.free.fr/fg_screens/decembre09/fgfs-screen-027.png ps: and to answer to the question why have you taken an ati card? that was the only way to flight with shaders on an agp card, and so my PC can last some years more :) . using fglrx, on a debian sid with an ati radeonhd4650. jano -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fg shows a blank screen
Jari Häkkinen a écrit : Hi all, I only get a blank single colour screen when I run fg (latest cvs/svn versions of plib/osg/simgear/fg). The colour changes with time settings, it is grey at noon, bluish at dusk, and black in night time. I can see the top menu and I have sound. I get the message saying which runway I am located at. same here with the last OSG svn, menu and hud is working and the plane too, but i only have black to blue screen, taking an old OSG solved the problem for me (i used the 10820 revision). jano -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fg shows a blank screen
Jari Häkkinen a écrit : On 2009-11-28 16.55, jean pellotier wrote: Jari Häkkinen a écrit : Hi all, I only get a blank single colour screen when I run fg (latest cvs/svn versions of plib/osg/simgear/fg). The colour changes with time settings, it is grey at noon, bluish at dusk, and black in night time. I can see the top menu and I have sound. I get the message saying which runway I am located at. same here with the last OSG svn, menu and hud is working and the plane too, but i only have black to blue screen, taking an old OSG solved the problem for me (i used the 10820 revision). I traced the problem to changeset 10838 in OSG. I cannot say what goes wrong but maybe one of the list readers do. http://www.openscenegraph.org/projects/osg/changeset/10838/OpenSceneGraph/trunk Is this a mac specific problem or does it occur in other OSs too? Jari not mac specific, here on debian SID, amd athlon xp2800+, nvidia 6200. jano -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ridge lift in south hemisphere
jean pellotier a écrit :
hi, yesterday we were near the Kilimanjaro (HTKJ) and up to reach the
top with a c172, we tried to use the lift given by ridge lift, but it
was always 0.
I tried to start at Quito (SEQU) and ridge lift get elevation values
only once in north hemisphere.
it seems that:
(globals-get_scenery()-get_elevation_m(SGGeod::fromGeodM(
SGGeod::fromRad(probe_lon_rad[i],probe_lat_rad[i]),
2), elevation, 0))
in environment/ridge_lift.cxx is always false in south hemisphere, an
can't report the ground elevation
The responsable was the test for the pole position, to avoid a division
by cos(lat) =0, here's a patch addressing this issue, if someone can
have a look and commit, thanks.
jano
Index: src/Environment/ridge_lift.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Environment/ridge_lift.cxx,v
retrieving revision 1.8
diff -u -r1.8 ridge_lift.cxx
--- src/Environment/ridge_lift.cxx 20 May 2009 09:24:56 - 1.8
+++ src/Environment/ridge_lift.cxx 23 May 2009 06:47:58 -
@@ -176,7 +176,7 @@
probe_lat_rad[i] = asin(sin(user_latitude_rad)*cos(probe_radius_ratio)
+cos(user_latitude_rad)*sin_probe_radius_ratio*cos(ground_wind_from_rad));
- if (probe_lat_rad[i] SG_EPSILON ) {
+ if (abs(abs(probe_lat_rad[i]) - SG_PI / 2.0) SG_EPSILON ) {
probe_lon_rad[i] = user_latitude_rad; // probe on a pole
} else {
probe_lon_rad[i] = fmod((user_longitude_rad+asin(sin(ground_wind_from_rad)
@@ -191,11 +191,7 @@
double elevation = 0;
if (globals-get_scenery()-get_elevation_m(SGGeod::fromGeodM(
SGGeod::fromRad(probe_lon_rad[i],probe_lat_rad[i]), 2), elevation, 0)) {
-if ( elevation 0.1 ) {
probe_elev_m[i] = elevation;
-} else {
- probe_elev_m[i] = 0.1 ;
-}
} else {
probe_elev_m[i] = 0.1;
}
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, Big Spaceship. http://www.creativitycat.com ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Ridge lift in south hemisphere
hi, yesterday we were near the Kilimanjaro (HTKJ) and up to reach the top with a c172, we tried to use the lift given by ridge lift, but it was always 0. I tried to start at Quito (SEQU) and ridge lift get elevation values only once in north hemisphere. it seems that: (globals-get_scenery()-get_elevation_m(SGGeod::fromGeodM( SGGeod::fromRad(probe_lon_rad[i],probe_lat_rad[i]), 2), elevation, 0)) in environment/ridge_lift.cxx is always false in south hemisphere, an can't report the ground elevation jano -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] working ridge lift !!
Torsten Dreyer a écrit : I just commited this patch with some changes: The properties probe_elev_m[0..4] were uninitialized and used in the Run() method before being initialized by a scan of the ground elevations. The first scan was performed after one second, so for the first second the probe_elev_m were used in an uninitialized state. I changed the timer behaviour to run the scan before the probe_elev_m values are used. To check, if this solves (and not hides) the nan issue, i commented out the line containing the isnan() check. Please report, if this works. Torsten that works here, no more nan, and now time to cross the alps in glider :). btw is there a particular reason why an unitialized state variable is more often nan than on other OS and platform? or is my ram more subject to cosmic ray attack? (here with debian SID 32bits on athlon XP 2800+ single core at 1.8GHz, 2.5 G ram and nvidia 6200, gcc 4.3.3-5, kernel 2.6.26-1-686, SG, OSG Plib and FG all cvs or svn). here's a screen where i got unitialised probe-elev-m, where probe-elev-m[4] is the killer, all the nan in other fields just propagated along the calculs to freeze FG, starting by environment/ridge-lift-fps. jano -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] working ridge lift !!
Patrice Poly a écrit : the fix, as a patch http://www.bentha.net/fgfs/ridge-lift/Environment.diff.bz2 hope this works... nope, same behaviour!! i think that on my slow PC, your ridge lift is sometimes initialised a little to early (while position is 0,0,0 maybe), resulting in some nan in the result of terrain scan, wich lead to a nan in /environment/ridge-lift-fps. and as it's used to compute the next aircraft position, nan go all along the calculs... i tested : _ridge_lift_fps_node-setDoubleValue( 0 ); and no more nan, all the properties in ridge-lift are now valid. jano -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] working ridge lift !!
hi And ty Torsten for committing ! I hope it doesn't trigger too much bugs. My side I don't see weird things. for me FG is quite impossible to use with the ridge drift, on startup it start having full of nan nan nan, cull visitor and so on, with 1 fps, nearly 90% of my try to start are bad. i commented some lines in ridge_lift.cxx (from 210 to 307, and change 309 to: _ridge_lift_fps_node-setDoubleValue( 0); and i don't have anymore working ridge lift, and no more nan nan nan. having looked inthe properties /environment/ridge-lift, some values were nan when i had the cull visitor, like some probe-lon-deg, probe-elev-m. my test were in LFKE, LFHE and some others, with the bocian and ask21. if that's related to system or hardware: amd athlonXP 2800+, 2.5G ram, nvidia geforce 6200, and debian sid... jano -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] working ridge lift !!
I would be interested to see on which platforms / configuration this happens, maybe when more feedback comes in ?? I've got a 32 bits debian SID system, and my athlon xp 2800+ is a single core, i usually got nearly 20 fps near KSFO. jano -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] aircraft modeling question
My questions is this ... from a modeling perspective, can that 2nd aircraft be animated with absolute lon/lat/elev and roll/pitch/yaw degrees? Or would we need to compute an X, Y, Z offset in meters for the second aircraft? It would be a pain to figure out the orientation transform relative to the original aircraft ... can the secondary aircraft be animated with absolute angles relative to the world coordinate frame? Hi, you can have a look in tanker.nas, where the tanker move using direcly his lat, lon, alt, and differents inclinaisons with no relative reference, but be sure to not make your model solid, or you may have a lot of crashs. my2 cents jano -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier landing and groundcache with JSBSimAircrafts
Mathias Fröhlich a écrit : I tested this few more times, in a place with severals carriers (eisenhower, foch, clemenceau...) and if i start FG far from this place, then move with the location menu to the closest airport, carriers are not solid (all the carriers). If i start near the carriers, then move far away, and then come back, carriers are solid. I remember a long flight from KLSV to the carrier near KHAF, and the carrier was not solid . To me it depend if the 3D model is loaded in startup. Can you please retest? I have found a problem with model loading and setting of the traversal masks that should now be fixed. i tested, starting FG in KLSV, going to KHAF with location menu, and after 50 nm cruise to the Carl Vinson, and, he is solid now, but the arresting wires don't work in this case. second try, starting on the carrier deck, all is fine. using the location menu has same effects on other carriers near LFTH (got foch, clemenceau and eisenhower here), none of them have a working wire if i come near with location menu from far, but now they are solid btw with little front wind, little fuel, the f14 don't need the wires to stop on the carrier :). jano -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] jsbsim wind correction in opposite direction
Jon S. Berndt a écrit : Yes, the difference stems from the need to know what the wind is bringing, and the vectorial definition of where it's going. The problem was that sometimes we just had a vector where we expected to see North, East, and Down, wind components. Well ... fine, but is that to or from. The convention was unspecified, and that caused confusion. From the FlightGear side, I can see winds being specified either way. In the flight dynamics code, however, I expect to see a wind velocity vector - the direction it's going. The question is, where does the conversion to the wind velocity vector form break? Jon After having seen in some places in last JSBSim code that wind direction is the direction the wind is toward, here's a patch that revert the values used in wind vector for JSBSim, that work for me, wind is now correctly applied. i didn't tested vertical composante . hope that helps jano Index: src/FDM/JSBSim/JSBSim.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/JSBSim/JSBSim.cxx,v retrieving revision 1.55 diff -u -r1.55 JSBSim.cxx --- src/FDM/JSBSim/JSBSim.cxx 27 Mar 2009 11:44:35 - 1.55 +++ src/FDM/JSBSim/JSBSim.cxx 1 Apr 2009 13:42:55 - @@ -328,9 +328,9 @@ Atmosphere-UseInternal(); } -fgic-SetVNorthFpsIC( wind_from_north-getDoubleValue() ); -fgic-SetVEastFpsIC( wind_from_east-getDoubleValue() ); -fgic-SetVDownFpsIC( wind_from_down-getDoubleValue() ); +fgic-SetVNorthFpsIC( -wind_from_north-getDoubleValue() ); +fgic-SetVEastFpsIC( -wind_from_east-getDoubleValue() ); +fgic-SetVDownFpsIC( -wind_from_down-getDoubleValue() ); //Atmosphere-SetExTemperature(get_Static_temperature()); //Atmosphere-SetExPressure(get_Static_pressure()); @@ -625,9 +625,9 @@ tmp = turbulence_rate-getDoubleValue(); //Atmosphere-SetTurbRate(tmp); -Atmosphere-SetWindNED( wind_from_north-getDoubleValue(), -wind_from_east-getDoubleValue(), -wind_from_down-getDoubleValue() ); +Atmosphere-SetWindNED( -wind_from_north-getDoubleValue(), +-wind_from_east-getDoubleValue(), +-wind_from_down-getDoubleValue() ); //SG_LOG(SG_FLIGHT,SG_INFO, Wind NED: // get_V_north_airmass() , // get_V_east_airmass() , -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] jsbsim wind correction in opposite direction
hi, with last update, i think that jsbsim is applying the wind correction in opposite direction. i tried to follow a tanker first with a F-4N, and it was the same with the c172p, facing wind from environment, air speed was equal to ground speed minus wind speed. that was not the case last time i did a compile, 5 days ago. and no problem with yasim planes. jano -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier landing and groundcache with JSBSimAircrafts
Vivian Meazza a écrit : I've been testing the carrier stuff with YASim. It usually works, but a occasionally the deck isn't solid, and the ac falls right through on landing. This bug is intermittent: I have been unable to reproduce it reliably, or identify the conditions under which it occurs. Only twice in 20 or so landings. The same for me, a day i was using mp_carrier, i started FG in KLSV and used position menu to teleport to KSAN, and the two times i did this carrier was not solid, I didn't check if it was true one more time, but with starting FG directly in KSAN the carrier was solid. jano -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier landing and groundcache with JSBSimAircrafts
jean pellotier a écrit : Vivian Meazza a écrit : I've been testing the carrier stuff with YASim. It usually works, but a occasionally the deck isn't solid, and the ac falls right through on landing. This bug is intermittent: I have been unable to reproduce it reliably, or identify the conditions under which it occurs. Only twice in 20 or so landings. The same for me, a day i was using mp_carrier, i started FG in KLSV and used position menu to teleport to KSAN, and the two times i did this carrier was not solid, I didn't check if it was true one more time, but with starting FG directly in KSAN the carrier was solid. jano I tested this few more times, in a place with severals carriers (eisenhower, foch, clemenceau...) and if i start FG far from this place, then move with the location menu to the closest airport, carriers are not solid (all the carriers). If i start near the carriers, then move far away, and then come back, carriers are solid. I remember a long flight from KLSV to the carrier near KHAF, and the carrier was not solid . To me it depend if the 3D model is loaded in startup. my two cents jano -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier landing and groundcache with JSBSimAircrafts
gerard robin a écrit : foch/clemenceau (the same carrier, old version from cvs ) was built for JSBsim aircrafts ( the Crusader and others from my hangar) , it was (is) probably not YASim compatible ( not consistent, not solid ). I use a scenario that make it solid, and the wire usable, and now after the ground cache change i removed all solid part and it's still solid , and more dangerous because the island is now solid :). except if i change airport as said before. It's the same with Nimitz and Eisenhower. Btw how do we make a part non solid now? like the wakes? I have recently rebuilt a new version which is compatible JSBsim aircrafts, Yasim aircraft (tested with seahawk) with FG 1.9.1 If you want it it is here http://pagesperso-orange.fr/GRTux/Clemenceau.tar.bz2 BTW: the MP-Carrier is only virtual, when we use it, we are using our local version with our local parameters/file. Only the position is specific to MP. If it is not consistent with MP , it is not consistent with the usual AI / scenario. which the case with the Foch/clemenceau CVS the tests were done only with ai carriers. jano -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] About YASim Documentation
Hello there, In the YASim source code I found a mention to a TeX documentation. I was not able to find it on the Wiki, and googling gave no result. Does it exist, and where could I find it, please ? Cheerio, JB -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FLOATING POINT INTERRUPT (SIGFPE)
Hello there, Sorry to bother you with the rookie problems, but I didn't find anything on the Archive about that. My newly installed FlightGear crashes when I launch it, and send me in terminal the error in the object. It appears to happen when loading the sceneries to be more precise. I am running Fedora 9 and SDL as Glut Utility. Did anyone get this problem before ? Cheers, JB -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nimitz elevators non solid
Mathias Fröhlich wrote : Hi, On Thursday 12 March 2009 22:43:15 jean pellotier wrote: I've got a problem with the elevators on nimitz, since some days, when called up, it looks ok, but elevator 3d model isn't solid, the part solid is where is the elevator down. each try i finish on the low position (in best case) under the elevator 3d model. Ok, I have now checked in everything that I have in this area. So, at least all *known* issues are solved. Is that still a problem? Greetings Mathias work well now, thanks jano -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] nimitz elevators non solid
hi, I've got a problem with the elevators on nimitz, since some days, when called up, it looks ok, but elevator 3d model isn't solid, the part solid is where is the elevator down. each try i finish on the low position (in best case) under the elevator 3d model. jano -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] c172p-dual-pilot broken
hi, trying the c172p dual pilot, it don't load, saying it can't find the file: Aircraft/SenecaII/Instruments-3d/kx165tso1.xml wich don't exist anymore! i removed the references to this file and it load fine, but i don't have the radios, any way to make them come back? jano -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172p-dual-pilot broken
Anders Gidenstam a écrit : Done and it seems to work. It is available here: http://www.gidenstam.org/FlightGear/DualControl/ (Btw, as far as I could see the previous version there carried its own copies of the KX165 radios - are you sure you had the latest version installed?) In the longer run it would be nice to merge the dual control functionallity into the kx165 units in Instruments-3d instead of having separate versions. Cheers, Anders thank you for the quick reply, you are right, I was thinking it was included in CVS, and forgot it was an add-on , sorry for the noise :) jano -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] today's bug with pilot list
Hi, today i got a bug in pilot list, the pilot list windows disappeared with a message in console: Nasal runtime error: floating point error in math.sin() at /stockage/logiciels/flightgear/cvs-OSG/install/share/FlightGear/Nasal/geo.nas, line 160 called from: /stockage/logiciels/flightgear/cvs-OSG/install/share/FlightGear/Nasal/multiplayer.nas, line 274 called from: /stockage/logiciels/flightgear/cvs-OSG/install/share/FlightGear/Nasal/multiplayer.nas, line 251 called from: /stockage/logiciels/flightgear/cvs-OSG/install/share/FlightGear/Nasal/multiplayer.nas, line 286 called from: /stockage/logiciels/flightgear/cvs-OSG/install/share/FlightGear/Nasal/multiplayer.nas, line 183 called from: /stockage/logiciels/flightgear/cvs-OSG/install/share/FlightGear/Nasal/globals.nas, line 96 I did a telnet in the mpserver02 and it seems that pab was the cause of that, by not sending any numbers: navy...@local: 3991485.570654 95139.017927 4957283.165346 51.339734 1.365414 167.886556 -2.586626 2.820793 0.535251 Aircraft/sopwithCamel/Models/sopwithCamel-model-Y.xml p...@202.65.xxx.xxx: . . . . . . . . . Aircraft/c172p/Models/c172p.xml some...@xx.xx.xxx.xxx: -2711933.707939 -4270428.564775 3871851.155946 37.615410 -122.417570 713.505101 -0.840616 0.623783 -0.324802 Aircraft/OV10/Models/USAFE/OV10.xml as soon as he disconnected, pilot list came back. i don't know if that can be considered as a bug, but it's a good way to force players to use their radar :). jano -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] gyro compas drift
hi, doing some nav with the pa24-250, i found the gyro compas drift was always -15°/hour. I never went in a real aircraft except as passenger, but if i refer to this page: http://en.wikipedia.org/wiki/Heading_indicator Shouldn't drift be related to the sin(lat), and opposite sign in the southern hemisphere? I think the relevant code is in instrumentation/heading_indicator.cxx, line 77: offset -= dt * (0.25 / 60.0); // 360deg/day but i don't know c++, so can't propose a patch. cheers jano -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Route Manager/ io.nas
Alasdair Campbell a écrit : In eager anticipation of James Turners' proposed improvements to the Route Manager/GPS code, I have been playing around some and noted that that the route manager dialog contains a Load List option. If I try to use this option, I find that I am unable to load any file (fails the sanity check in data/nasal/io.nas (even as root)) The enclosed temporary patch, removing the check resolves the problem for me. A quick grep seems to to me that this this is the only place where nasal io is used. I may be wrong, but could someone with more nasal expertise check this out? Kind regards, Alasdair I had same trouble, and found that it works if the files are in .fgfs/routes i think adding your path readable in Nasal/IOrules should work... jano -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final (?) 3D clouds patch
Stuart Buchanan a écrit : Was the weather scenario set to METAR as well - one of the bugs I fixed with the latest patch was that previously --enable-real-weather-fetch over-wrote the various scenarios. Now, you will only get METAR if you have METAR as the scenario, as well as --enable-real-weather-fetch. -Stuart Hi, just to say something about real weather fetch and METAR, it seems to me that metar information are only used once, after thet next metar update is not taken into account (in the different clouds layers or in /environment properties) , but i think you know this (i saw a TODO in fgclouds.cxx). an other thing is a concern about: /environment/temperature-sea-level-degc /environment/dewpoint-sea-level-degc and the temperatures properties in the clouds layers wich are not changed (always 15 and 5) . i tried this formula in FGClouds::update_env_config (): fgDefaultWeatherValue( temperature-degc,( fgGetDouble(/environment/metar/temperature-degc) + 0.0065 * 0.3048 * station_elevation_ft )) but my knowledge of c++ being close to 0, station elevation was not taken into account but temperature was updated. cheers jano -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OV-10 adf needle
here's a patch concerning the OV-10 aircraft, adf needdle is rotated by the heading fist, wich is false, the adf bearing rotation is enough jano Index: ./Aircraft/OV10/Models/USAFE/Instruments/BDHI/HI-f8e.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/OV10/Models/USAFE/Instruments/BDHI/HI-f8e.xml,v retrieving revision 1.1 diff -u -r1.1 HI-f8e.xml --- ./Aircraft/OV10/Models/USAFE/Instruments/BDHI/HI-f8e.xml 28 Feb 2007 22:25:48 - 1.1 +++ ./Aircraft/OV10/Models/USAFE/Instruments/BDHI/HI-f8e.xml 19 Oct 2008 11:58:38 - @@ -309,22 +309,6 @@ animation typerotate/type object-nameAiguille1-Adf/object-name - property/orientation/heading-magnetic-deg/property - center - x-m0/x-m - y-m0/y-m - z-m0/z-m - /center - axis - x1/x - y0/y - z0/z - /axis - /animation - - animation - typerotate/type - object-nameAiguille1-Adf/object-name property/instrumentation/adf/indicated-bearing-deg/property factor1/factor center - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multikey: vi-like commands in fgfs (II)
In adition to your proposal, could you add the Tacan Setting like you offer about Radio Settings Sure. The current config is just a start. It should demonstrate the system and encourage developers to discuss the most efficient key scheme. All sections are still very basic, there's a lot missing in the whole radio section. We'll also want an 'i' (instrumentation) section etc. m. nice to see that tacan was added, just something's wrong: x and y have to be replaced by X and Y in the lines: scriptsettacan(arg[0], X)/script scriptsettacan(arg[0], Y)/script my 2 cents, jano. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about the carrier used in scenario
Vivian Meazza a écrit : OK - Wave Off Lights 71, 72 were in the wrong position, as were 61, 62, which confused me. Fixed now in cvs - please check that the problem is solved for you. now 71 and 72 are in the right place, but 61 and 62 are in the same place as 51 and 52, so there's missing two lights ... setting 51 and 52 this way did the job: model nameWave-Off-51/name pathModels/Geometry/Nimitz/Models/wave-off.xml/path offsets x-m0.1/x-m y-m0.77/y-m z-m-0.39/z-m /offsets /model model nameWave-Off-52/name pathModels/Geometry/Nimitz/Models/wave-off.xml/path offsets x-m0.1/x-m y-m-0.77/y-m z-m-0.39/z-m /offsets /model have a nice day :) jano - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about the carrier used in scenario
Vivian Meazza a écrit : So they are - fixed in cvs (I hope) - try again that's ok for me, thanks. jano - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about the carrier used in scenario
Vivian Meazza a écrit : Glad that we've fixed that - it must have been that way for several years. But what is the real issue with the demo? I couldn't get it to work here - doesn't it need the model as well? oh sorry, i didn't gave you all needed to do it working, here's what's missing: first the scenary used (7M)needed to have cable in the suitable hight: http://janodesbois.free.fr/doc/meeting-08-2008.tar.gz it contains terrain with little differents with scenery 1.0, so i recommend to uncompress it where you want and to give his path with something like that: --fg-scenery=path/to/meeting-08-2008:path/to/data/scenery and here's all the 3D models needed for the 4 airports and lot of planes low-poly, included the scenario (37M) : http://janodesbois.free.fr/doc/data.tar.gz or only the files needed for the scenario: http://janodesbois.free.fr/doc/scenario-LFRJ.tar.gz then just start at LFRJ with the LFRJ_wires_demo.xml enabled! for french users: http://fr.flightgear.tuxfamily.org/doku.php?id=meeting:representations:03-08-2008 I imagine that you would really like a new AI Object which is a subset of the AICarrier, rather than your current hack? yes that would be cool, the most important would be that all the coordonnes shouldn't need to be relative, but given as the ufo's output. for me a flols who can work alone, and the same for the cable would be perfect, but i'm not specialist! and one more thing about using the carrier for ground arresting cable, it is impossible to give a roll in the scenario file, because the first seconds the boat fdm make it flat jano, trying to catch a wire navigating through the ground - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] about the carrier used in scenario
hi all we did a scenario that use the carrier type to make an arresting cable with a flols working, at LFRJ airport (Landivisiau, France), but if we check the turn to wind button the cable and the flols are moving, considered like a normal carrier. Is there a way to make it fix relative to the ground, or the only way is to never use turn to wind? i join the scenario file (LFRJ_wires_demo.xml) Concerning the flols, last two red lights (the lowests) taking part of the wave off are not in the right place, compared to the flols model, as you can see here: http://wiki.flightgear.org/images/thumb/9/9d/Carrier5.jpg/800px-Carrier5.jpg here's a patch to synch them, that seems to be an inversion between y and z axis,here's the result: http://fr.flightgear.tuxfamily.org/lib/exe/fetch.php?cache=cachew=900h=670media=school:move:porte-avion:flols:waveoff-nimitz.jpg have a nice landing on Nimitz jano ?xml version=1.0? PropertyList scenario description Arrestor Cables for training of landing in a aircraft carrier. park-1 is a parking position for Heavy Military Aicraft park-2 is a parking position for Military Jet !-- park-3 is for a civilian aircraft /-- /description entry typecarrier/type nameLFRJ-bak26-1/name modelAI/Airports/LFRJ/BAK26+flols.xml/model TACAN-channel-ID098Y/TACAN-channel-ID wireline/wire latitude48.53306323/latitude longitude-4.137254038/longitude altitude335.4462275/altitude heading253.32/heading flols-pos x-offset-m25/x-offset-m y-offset-m-30/y-offset-m z-offset-m1.8/z-offset-m -- /flols-pos max-lat0/max-lat min-lat0/min-lat max-long0/max-long min-long0/min-long /entry entry typecarrier/type nameLFRJ-bak08-1/name modelAI/Airports/LFRJ/BAK08+flols.xml/model TACAN-channel-ID098Y/TACAN-channel-ID wireline/wire latitude48.52714689/latitude longitude-4.166412234/longitude altitude334.8964534/altitude heading73.32/heading flols-pos x-offset-m25/x-offset-m y-offset-m-30/y-offset-m z-offset-m1.5/z-offset-m /flols-pos parking-pos namepark-1/name heading-offset-deg10/heading-offset-deg x-offset-m365/x-offset-m y-offset-m610/y-offset-m z-offset-m-2/z-offset-m /parking-pos !-- Military Jets /-- parking-pos namepark-2/name heading-offset-deg190/heading-offset-deg x-offset-m252/x-offset-m y-offset-m600/y-offset-m z-offset-m0/z-offset-m /parking-pos !-- Civilian Aircrafts /-- !-- parking-pos namepark-3/name heading-offset-deg0/heading-offset-deg x-offset-m200/x-offset-m y-offset-m-600/y-offset-m z-offset-m0/z-offset-m /parking-pos /-- max-lat0/max-lat min-lat0/min-lat max-long0/max-long min-long0/min-long /entry /scenario /PropertyList !-- latitude-deg type=double48.53306323/latitude-deg longitude-deg type=double-4.137254038/longitude-deg elevation-ft type=double335.4462275/elevation-ft --Index: Models/Geometry/Nimitz/Models/flols.xml === RCS file: /var/cvs/FlightGear-0.9/data/Models/Geometry/Nimitz/Models/flols.xml,v retrieving revision 1.6 diff -u -r1.6 flols.xml --- Models/Geometry/Nimitz/Models/flols.xml 21 Apr 2008 08:23:20 - 1.6 +++ Models/Geometry/Nimitz/Models/flols.xml 29 Jul 2008 18:33:25 - @@ -289,8 +289,8 @@ pathModels/Geometry/Nimitz/Models/wave-off.xml/path offsets x-m0.1/x-m - y-m0.77/y-m - z-m-1.18/z-m + y-m1.18/y-m + z-m-0.77/z-m /offsets /model model @@ -298,8 +298,8 @@ pathModels/Geometry/Nimitz/Models/wave-off.xml/path offsets x-m0.1/x-m - y-m-0.77/y-m - z-m-1.18/z-m + y-m-1.18/y-m + z-m-0.77/z-m /offsets /model animation - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screen bug (?) - Repeating pattern - Any hint? Already known prob?
Curtis Olson a écrit : On Sun, Jul 20, 2008 at 6:48 AM, Roberto Inzerillo wrote: Hi all, I'm very glad the community is still hard working on FGFS, I enjoyed it very much in the past. I lost interest sometime ago because of my job, now I'd like to keep contributing with a few 3d models again but ... there's a prob with the screen that bothers me and I don't find to get the solution. The screen looks garbage after loading the scenario (see samples at: http://www.laubfrosch.it/fgfs/screen_bug/pic1.jpg http://www.laubfrosch.it/fgfs/screen_bug/pic2.jpg http://www.laubfrosch.it/fgfs/screen_bug/pic1.jpg), I guess it has to do with the graphic card but don't know where to investigate. Did anyone had the same prob and ended up solving it? My system: Windows XP Home Ed AthlonXp 2500+ Gigabyte GA-7VT600 ATI Radeon 9600 (Catalyst 8.4 default settings) Flightgear 1.0.0 (default settings) Tryed various changes in settings (both inside FGFS and Catalyst) but neither got any improvement :-( Hi Roberto, have you tried installing the latest graphics drivers from ATI. Usually this is the first thing to try if you encounter graphics problems with FlightGear. FlightGear uses OpenGL and many system ship with dated or poor or non-existant opengl drivers. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ http://baron.flightgear.org/%7Ecurt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel this is similar as in tis topic in forum: http://www.flightgear.org/forums/viewtopic.php?p=13727#p13727 changing point sprites for runway lighting to false made it working for some guys in french forum... good luck jano - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] 737-300 3d model - FDM alignment problem
Anders Gidenstam a écrit : Hi, Hasn't anyone noticed that the FDM model landing gears (in fact, the whole FDM model) on the 737-300 is 9 meters behind the 3d model landing gears?! I almost never fly jetliners but that there was an alignment problem was obvious from the first glance in external view during taxing.. It is pretty much invisible from cockpit view, though, so I can see how serious pilots might not notice the problem.. :) I thought I had sent this patch last year, but it seems I might not have done that. Anyway, here are two alternative ways of aligning the 3d model with the FDM model: Alt.1. Adjust the visual reference point (VRP) in the JSBSim FDM config: http://www.gidenstam.org/FlightGear/aircraft_updates/737-300-offsets-1.diff Alt.2. Adjust the offsets in the 3d model XML file. Note that one has to modify the cockpit view location and usually also need to add a corresponding target-z-offset to the external views to make those look good with the repositioned 3d model. http://www.gidenstam.org/FlightGear/aircraft_updates/737-300-offsets-2.diff I think alternative 2. is preferable since it avoids the risk of losing the VRP offset, should the FDM config be overwritten during a future JSBSim update. The Alt.2. method also works for YASim aircraft, should any of those need alignment. Silly (and old) postfix demo: http://www.gidenstam.org/FlightGear/aircraft_updates/fgfs-737-300_adjusted.jpg Try that with the 737-300 in CVS... Cheers, Anders Hi, same thing with the E3B and the KC135, 3d model is 21m before fdm. here are the files i changed: http://janodesbois.free.fr/doc/Aircraft.tar.gz ( i used Alt. 2) if someone want to test and commit? i don't know if that has an effect on visual distance aar works in mp mode, for the KC135. (not tested yet). Cheers, Jean - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] concerning the Foch carrier
Hi all, trying to use the Foch as a carrier in OSG, it appeared : -it was too low on the water, so the deck is under water (somebody told me about global warming, but isn't it supposed to float?) - the deck was not solid. It don't make solid the 'OBJECT group' defined in the .ac i join the modified files, i only made solid the deck , the hangar's floor and the elevator, so as to move the planes easily on board. here are the files : http://janodesbois.free.fr/doc/foch.tar.gz may be there was a more elegant way to do the job, let me know if you have better idea. ps: in the plib version he don't have the right hight, as i remenber addind +9m offset in the y axis did the job (in foch.xml). if you want to test it, use the foch_demo scenario and start at LFTH, tacan is 026X. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bizarre dynamic scenery
Ron Jensen a écrit : On Mon, 2008-01-21 at 14:32 +0100, Nagy Mate wrote: We noticed a rather peculiar effect, having landed our plane near (under) a grey parking passenger jet. Fiddling with our flight controls made the control surfaces of the jet move in the same way. The jet was otherwise inert, and the effect didn't happen with other nearby planes on the ground. (This was noticed on the master half of a native protocol slaved pair.) Has anyone else seen something like this before? :) - Mate Nagy Yes, it sounds like the jet model config has absolute paths instead of relative paths for the control animations. If you tell us which jet it was someone will fix it. Thanks, Ron the bo105 has this problem, specialy the doors witch are invisible when it's an mp aircraft. (and the livery change is global) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCOM : sound card issues
Csaba Halász a écrit : On Dec 22, 2007 11:36 AM, jean pellotier [EMAIL PROTECTED] wrote: Hi alls, few issues with fgcom: - My PC is ready to test fgcom with jack, (adat card rme96/8) but I can't manage to compile with: USE_PA_JACK=1, the first lines of error are: portaudio/src/hostapi/jack/pa_jack.c:71:27: error: pa_ringbuffer.h: Aucun fichier ou répertoire de ce type portaudio/src/hostapi/jack/pa_jack.c:72:27: error: pa_debugprint.h: Aucun fichier ou répertoire de ce type what should i do to make it working? I don't speak french, no idea what those errors are. However, I did manage to compile with jack support, I only needed to add -ljack into the STATIC_LIBS variable at the top of src/Makefile. Nevertheless, I recommend you use openal or alsa if possible. sorry, it just says can't find a file matching for pa_ringbuffer.h and pa_debugprint.h. Probably you are using an old version of fgcom. Openal and alsa output drivers are now using software muting, do not touch the hardware mixer at all. i use the last svn version (perhaps i'm wrong?) and pressing PTT change my sounds settings in alsamixer. Version 1.1.0 build 66M Using iaxclient library Version SVN 66M - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCOM : sound card issues
Csaba Halász a écrit : On Dec 23, 2007 2:25 AM, jean pellotier [EMAIL PROTECTED] wrote: sorry, it just says can't find a file matching for pa_ringbuffer.h and pa_debugprint.h. Interesting. Doing a search of all the files the string pa_ringbuffer is not mentioned anywhere. Maybe you have another iaxclient on your system as well? it concern the files pa_ringbuffer.h and pa_debugprint.h wich are on last portaudio stable release: http://www.portaudio.com/archives/pa_stable_v19_20071207.tar.gz but are are not present in the portaudio included with fgcom's source, i tried replace portaudio or import the files but it failed . i use the last svn version (perhaps i'm wrong?) and pressing PTT change my sounds settings in alsamixer. With the alsa or openal drivers? *Not* pa-alsa! you're right, with alsa that seems to be fine... i just need to test to be sure. thanks - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Error in latest fgcom
Csaba Halász a écrit : On Dec 13, 2007 7:22 PM, Will Harrison [EMAIL PROTECTED] wrote: Reading list of airports...error during reading airports! Stopping service What could be wrong here? Thanks, Updated positions.txt entry: AYGN,119.600,-10.312313,150.332745,ACTIVATE LIGHTS ONLY MULTICOM,Gurney causes field length overflow. FIX: Increased field length in svn rev 66. i sent this yesterday, if that helps... HI trying to run the last fgcom update I'd got the following error: Reading list of airports...error during reading airports! the issue is with positions.txt, trying an old one worked perfectly. when the before the last field contain more than 24 char, reading the file fails. after correction, it's concern all the ACTIVATE LIGHTS ONLY MULTICOM and other terminating with MULTICOM, and a very long finishing by UNICOM (i don't remenber) I'm not a programmer so I can't tell why, but i add my positions.txt just to make it working for others having the same problem. here's my positions.txt working (sorry i don't know how to deal with diff) http://janodesbois.free.fr/doc/positions.txt jean. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] dual head problem
Guillaume CHAUVAT a écrit : I have the same bug, FG/OSG always opens on the :0 display, although my $DISPLAY has an other value. I think it's not due to OSG itself, because osgviewer has not this bug. Guillaume I tryed using a camera view in preference.xml, like the files john sent to me, just added : camera host-name type=string/host-name display0/display screen1/screen shear-x0/shear-x shear-y-2/shear-y width800/width height600/height fullscreen type=boolfalse/fullscreen /camera -- in the rendering section of preference.xml. it works, it make me a view splitted between the two screens. But I still don't know if it's possible to start FG-OSG from the second screen (using DISPLAY setting or in preference.xml) as it never did for me, and how to configure a static view in a camera section (like the boomer view while flying the KC-135). To finish, i've got some issues using dual view with clickable panels: I was unable to start the lightning, none of the clickable element worked, even tab that should call a menu did not work. with the pa24-250 it's different: automatique pilot contol and the radio panel are working, but none of the other switchs (still working with keyboard shortcut). I can join my Xorg.conf and other pc information if that helps jean . - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] dual head problem
Hi, that would be fine if i coud have the files, i think i can set up X, but i need things to tell OSG witch screen to use, it always use the fist one, and sometimes i woul'd like to run FG on the smaller screen. thanks for the answers. John Wojnaroski a écrit : Hi, OK, I've just starting working with OSG and multiple cameras so may not have all the details. OSG only requires a single instance of FG to use multiple cameras. You'll need to set up your xorg.conf file to run your graphics boards under a single X server and there are some lines you'll need in the preferences.xml file to configure the cameras, FOVs, and displays. If you understand what I've just said and have done this, then that pretty much exhausts my current understanding of OSG and multiple cameras. If OTOH, you're not clear on how to do this, I can provide a copy of the files that others have been kind enough to provide and I've edited for my setup. I'm not at my machine with those files, but will send them later today via private mail, if you like. These files set up X windows and configure FG-OSG to produce three views (left, center, right). You'll need pretty hefty graphics cards to get a decent frame rate. John jean pellotier wrote: hi, I think i did (I'm using a script to compile). I've got the following line in my configure.log: #define ENABLE_OSGVIEWER 1 John Wojnaroski a écrit : Hi, did you run configure with--enable-osgviewer ? JW jean pellotier wrote: Hi all I tryed to run flightgear cvs-OSG using two displays, running two X instances (different resolution) and when I start flightgear in a terminal on the second display, it always start on the fist one. The 0.9.10 version worked fine for this. is this a bug or there's something to do before compiling? debian SID, amd2800+, geforce 6200 jano. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] dual head problem
Anders Gidenstam a écrit : Hi, I think the previous proposal was to reconfigure X to see both screens as one big X screen (e.g as NVidia TwinView does). I don't have the same resolution on the two screens, that's why I use dual head display. (1280x1024 and 1024x768) However, it would not be good if FlightGear/OSG cannot be instructed which X screen to start on. Have you tried setting DISPLAY ? yes I did, setting DISPLAY to :0.1 other programs work but not FG-cvs-OSG, i will try command to configure OSG in preference.xml, as soon as i've got the files. As a side note I think it would be great if FlightGear could honour the standard X client command line arguments -geometry and -display . I think it didn't the last time I tried. Cheers, Anders - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] dual head problem
hi, I think i did (I'm using a script to compile). I've got the following line in my configure.log: #define ENABLE_OSGVIEWER 1 John Wojnaroski a écrit : Hi, did you run configure with--enable-osgviewer ? JW jean pellotier wrote: Hi all I tryed to run flightgear cvs-OSG using two displays, running two X instances (different resolution) and when I start flightgear in a terminal on the second display, it always start on the fist one. The 0.9.10 version worked fine for this. is this a bug or there's something to do before compiling? debian SID, amd2800+, geforce 6200 jano. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] dual head problem
Hi all I tryed to run flightgear cvs-OSG using two displays, running two X instances (different resolution) and when I start flightgear in a terminal on the second display, it always start on the fist one. The 0.9.10 version worked fine for this. is this a bug or there's something to do before compiling? debian SID, amd2800+, geforce 6200 jano. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Version mismatch
Hi, I'm trying to make a multiple display with :--native-fdm=socket,out,24,x.x.x.x,5505,udp for the master--native-fdm=socket,in,10,,5505,udp --fdm=external for the slaveand everything runs fine. But when i want to add :--native-ctrls=socket,out,10,152.81.40.31,5506,tcp to the master --native-ctrls=socket,in,10,,5506,tcp to the slave,I get an error message :Version mismatch with raw controls packet format.FlightGear needs version = 27 but is receiving version = 452984832In that case, slave's commands are bouncing from a position to another and that s quite bad :/regards gallypette _ Besoin d'un e-mail ? Créez gratuitement un compte Windows Live Hotmail, plus sûr, plus simple et plus complet ! http://www.windowslive.fr/hotmail/default.asp- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] osg transparency bug
7000 ft above KSFO, daytime: http://people.freebsd.org/~jylefort/fg-noon.png As you can see, the thin cloud layer does not hide the ground. However, after switching the time of day to night: http://people.freebsd.org/~jylefort/fg-night.png The airport and city lights only become visible (all of a sudden) after descending below the cloud layer. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpyXzN9hU9uu.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] On 11/22/06, Foo Bar [EMAIL PROTECTED] wrote:
On Wed, 22 Nov 2006 19:36:56 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: It seems to become common practice to include the email address in the attribution line of replies. This is a very bad habit, as the addresses end up in the mailing list archives, where harvesters happily pick them up. Spammers will be grateful. I won't. I get enough spam already! Please stop this shit. Otherwise I'll stop posting to the fgfs lists, and will only send private messages. In the sf archives the email addresses are truncated. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpaTn4fxnSZd.pgp Description: PGP signature - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Not only landing lights...
On Wed, 25 Oct 2006 09:56:24 +0200 Melchior FRANZ [EMAIL PROTECTED] wrote: * Yurik V. Nikiforoff -- Wednesday 25 October 2006 07:24: There are two problems around this issue. These two problems sound exactly like the ones that we had with another light patch a while ago. It was done the wrong way (lights not in the scenegraph) and was unfixable. According to Mathias, who knows his stuff. :-) This one: http://people.freebsd.org/~jylefort/flightgear-aircraft-lights.diff -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpl1wn5lopMy.pgp Description: PGP signature - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] airport lights
On Mon, 19 Jun 2006 23:12:05 -0700
syd sandy [EMAIL PROTECTED] wrote:
I know this was discussed a while back , and if there was a solution I
think I missed it.
So I'll stick my neck out and ask
I used to get better framerates night flying, unless I enabled enhanced
lights.
Now it doesnt matter if enhanced lights are enabled or not , I get the
low framerates as soon as the airport lights come on. Ive got a 1.1 gig
AMD Athalon , with a Geforce 4 MX4000.
Average framerates are 25 - 30 , and drop to about 8 looking at KSFO at
night.
Is there a way to get the old style lighting back? Ive looked through
the code but haven't sorted that out .
I apologize if I missed the solution , if its been posted , but I'm
working on the cockpit lighting for the 777-200 , and its frustrating
enough that I give up after a while .Well , that and whatever recent
change that has caused the program to sit at Initializing subsystems
for a good 4-5 minutes.
Thanks for any help, I really think its a fantastic program , and wish I
had time to brush up on my opengl programming so I could contribute more
than just aircraft.
I give up on the sourceforge mail archive and I therefore reproduce my
mail below; you can solve your problem by applying the provided patch:
===
From: Jean-Yves Lefort [EMAIL PROTECTED]
To: flightgear-devel@lists.sourceforge.net
Reply-To: flightgear-devel@lists.sourceforge.net
Subject: [Flightgear-devel] performance and appearance issues with point sprites
Date: Sun, 5 Mar 2006 06:42:17 +0100
X-Mailer: Sylpheed running on FreeBSD
A little table (GeForce4 MX 4000, 1280x960) for fgfs --timeofday=midnight:
point-spriteenhanced-lighting fps runway/taxiway lights
===
false false 18 steady pixels [1]
false true2 steady thick points [1]
truefalse 11 dim and blinking pixels [2]
truetrue11 steady thin points [3]
[1] Identical to CVS 20060126.
[2] Nice for christmas, but otherwise completely broken. This is what
I get without the patch.
[3] Best attempt at looking like a real airport, I'd use this on a
more powerful system.
Enabling line-smooth removes about 7 fps from these figures.
See the attached patch (I think point-sprite and line-smooth should be
disabled by default).
--
Jean-Yves Lefort
[EMAIL PROTECTED]
http://lefort.be.eu.org/
[flightgear-perf.diff text/plain (1.3KB)]
Index: src/Main/renderer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v
retrieving revision 1.44
diff -u -r1.44 renderer.cxx
--- src/Main/renderer.cxx 21 Feb 2006 01:19:19 - 1.44
+++ src/Main/renderer.cxx 5 Mar 2006 05:29:14 -
@@ -222,8 +222,9 @@
glFrontFace ( GL_CCW );
// Just testing ...
-if ( SGIsOpenGLExtensionSupported(GL_ARB_point_sprite) ||
- SGIsOpenGLExtensionSupported(GL_NV_point_sprite) )
+if ( (SGIsOpenGLExtensionSupported(GL_ARB_point_sprite) ||
+ SGIsOpenGLExtensionSupported(GL_NV_point_sprite))
+fgGetBool(/sim/rendering/point-sprite))
{
GLuint handle = thesky-get_sun_texture_id();
glBindTexture ( GL_TEXTURE_2D, handle ) ;
@@ -232,7 +233,8 @@
// glEnable(GL_POINT_SMOOTH);
glPointSpriteIsSupported = true;
}
-glEnable(GL_LINE_SMOOTH);
+if ( fgGetBool(/sim/rendering/line-smooth) )
+glEnable(GL_LINE_SMOOTH);
// glEnable(GL_POLYGON_SMOOTH);
glHint(GL_POLYGON_SMOOTH_HINT, GL_DONT_CARE);
glHint(GL_LINE_SMOOTH_HINT, GL_DONT_CARE);
===
--
Jean-Yves Lefort
[EMAIL PROTECTED]
http://lefort.be.eu.org/
pgpuRvu4VKXw7.pgp
Description: PGP signature
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] b1900d fixes
Hi, I'm attaching two small fixes for the b1900d: - Unbreak night lighting of the GPWS buttons - Fix the author tag (spelling, and remove the line break since the property browser does not like it) PS: Syd: now the instruments lighting stays on even when I switch off the battery, both generators, the avionics switch and the engines. Is this intended? -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ Index: Aircraft/b1900d/b1900d-set.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/b1900d/b1900d-set.xml,v retrieving revision 1.11 diff -u -r1.11 b1900d-set.xml --- Aircraft/b1900d/b1900d-set.xml 11 Apr 2006 21:11:12 - 1.11 +++ Aircraft/b1900d/b1900d-set.xml 13 Apr 2006 17:03:02 - @@ -19,9 +19,7 @@ descriptionBeechcraft B1900D (YASim) w 3d panel/description statusdevelopement/status - authorSyd Adams (3d model/FDM) - - Jean-Yves Lefort (MKVIII gpws) - /author + authorSyd Adams (3d model/FDM) - Jean-Yves Lefort (MK VIII EGPWS)/author flight-modelyasim/flight-model aerob1900d/aero @@ -37,7 +35,7 @@ red alias=/sim/model/b1900d/material/instruments/emission/red/ green alias=/sim/model/b1900d/material/instruments/emission/green/ blue alias=/sim/model/b1900d/material/instruments/emission/blue/ -factor alias=/sim/model/b1900d/material/instruments/factor/ +factor alias=/controls/lighting/instruments-norm/ /emission /assemblies /mk-viii pgpiRlH82EMFv.pgp Description: PGP signature
[Flightgear-devel] b1900d polish
Hi, I've removed the old GPWS objects from the b1900d model, since it now uses the MK VIII. The anim patch is attached, and the .ac file with the GPWS, GPWSon, BELOW-GS, BelowGsOn and warninglamps objects removed can be found here: http://people.freebsd.org/~jylefort/b1900d.ac.gz Syd Adams CC'ed. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ Index: Aircraft/b1900d/Models/b1900d-anim.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/b1900d/Models/b1900d-anim.xml,v retrieving revision 1.3 diff -u -r1.3 b1900d-anim.xml --- Aircraft/b1900d/Models/b1900d-anim.xml 4 Mar 2006 22:28:51 - 1.3 +++ Aircraft/b1900d/Models/b1900d-anim.xml 20 Mar 2006 17:10:16 - @@ -2570,47 +2570,6 @@ z-m-0.088/z-m /center /animation -!-- GPWS-- -animation - typeselect/type - object-nameBelowGsOn/object-name - condition -and -greater-than - property/instrumentation/nav[0]/gs-needle-deflection/property - value1.3/value -/greater-than -less-than - property/position/altitude-agl-ft/property - value1000.0/value -/less-than - /and - /condition -/animation - -animation - typeselect/type - object-nameGPWSon/object-name - condition -less-than - property/instrumentation/airspeed-indicator/indicated-speed-kt/property - value180.0/value -/less-than -less-than - property/position/altitude-agl-ft/property - value1000.0/value -/less-than - less-than -property/gear/gear/position-norm/property -value1/value - /less-than - equals -property/surface-positions/flap-pos-norm/property -value0.0/value - /equals -/condition -/animation - !--__ airspeed -- pgpPZXDL5bTDK.pgp Description: PGP signature
Re: [Flightgear-devel] fix mouse view regression
On Fri, 10 Mar 2006 08:14:17 +0100 Mathias Fröhlich [EMAIL PROTECTED] wrote: On Thursday 09 March 2006 21:19, Jean-Yves Lefort wrote: This change actually breaks the view mode with PU_USE_GLUT (at least for me). It was working properly before the change; now the view jumps whenever the mouse reaches a screen edge. Checked in a fix which at least fixed that form me. Please give it a try. It works, thanks. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgprveOmEOJtr.pgp Description: PGP signature
[Flightgear-devel] fix mouse view regression
input.cxx log:
revision 1.82
date: 2006-02-16 01:30:28 +; author: david; state: Exp; lines: +5 -11
The constrained property for a mouse mode now actually constrains
the mouse rather than wrapping it. Wrapping around to the other side
of the screen has very bad consequences when using the mouse for
flying or viewing -- it can result in sudden jumps in the controls or
the viewpoint when the mouse jumps to another side of the screen.
Right now, the mouse is constrained to stay between 25% and 75% of the
screen on both the X and Y axis -- whenever it hits an edge, it jumps
back to the centre of the screen again (which causes no control or
view jump).
This change actually breaks the view mode with PU_USE_GLUT (at least
for me). It was working properly before the change; now the view jumps
whenever the mouse reaches a screen edge.
If nobody has a better idea, I suggest to commit the attached patch
(it simply restores the pre-1.82 code in the PU_USE_GLUT case).
--
Jean-Yves Lefort
[EMAIL PROTECTED]
http://lefort.be.eu.org/
Index: src/Input/input.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Input/input.cxx,v
retrieving revision 1.83
diff -u -r1.83 input.cxx
--- src/Input/input.cxx 21 Feb 2006 01:18:51 - 1.83
+++ src/Input/input.cxx 9 Mar 2006 20:16:54 -
@@ -387,6 +387,23 @@
// Constrain the mouse if requested
if (mode.constrained) {
bool need_warp = false;
+#ifdef PU_USE_GLUT
+if (x = 0) {
+ x = xsize - 2;
+ need_warp = true;
+} else if (x = (xsize-1)) {
+ x = 1;
+ need_warp = true;
+}
+
+if (y = 0) {
+ y = ysize - 2;
+ need_warp = true;
+} else if (y = (ysize-1)) {
+ y = 1;
+ need_warp = true;
+}
+#else /* PU_USE_SDL */
if (x = (xsize * .25) || x = (xsize * .75)) {
x = int(xsize * .5);
need_warp = true;
@@ -396,6 +413,7 @@
y = int(ysize * .5);
need_warp = true;
}
+#endif
if (need_warp)
fgWarpMouse(x, y);
pgpFSCS4CtggH.pgp
Description: PGP signature
Re: [Flightgear-devel] Re: fix for exit crash
On Tue, 7 Mar 2006 08:07:00 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: * Martin Spott -- Monday 06 March 2006 15:17: FreeBSD-5.3: Assertion failed: (status == 0), function ~SGMutex, file /opt/FlightGear/include/simgear/threads/SGThread.hxx, line 227. Abort (core dumped) OK, that's enough proof. This definitely needs to be fixed. If it can't be done cleanly before the release, then we can still comment out the destructors again for a *very* short period. This is a crude hack that mustn't prevail for years again. Less offensive (while still bad) would be to only comment out the triggering ASSERT. What about my solution? -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgp5PX6oHItb1.pgp Description: PGP signature
