Re: [Flightgear-devel] Mipmapping of liveries

[jean pellotier]

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=60133471&iu=/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)

[jean pellotier]

>
> 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=48897511&iu=/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

[jean pellotier]

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=48897031&iu=/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

[jean pellotier]

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=48897031&iu=/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

[jean pellotier]

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=49501711&iu=/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

[jean pellotier]

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
./Aircraft/Heinkel-He-177/Models/Images

[Flightgear-devel] making sign of side-slip consistent between fdm (bug 901)

[jean pellotier]

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=48808831&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] about fdm properties

[jean pellotier]

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

[jean pellotier]

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] Air-to-air refuelling enhancement

[jean pellotier]

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 @@
FixedCanopyGlass
Canopy_1

+
+ 
+ Hose
+ Drogue
+ false
+ 


Pilot/pilot.xml


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

[jean pellotier]

>>> - 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

[jean pellotier]

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)

[jean pellotier]

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

Re: [Flightgear-devel] About the bug 385

[jean pellotier]

Le 03/03/2012 23:12, ThorstenB a écrit :
> Am 03.03.2012 03:28, schrieb Robert:
>> 2012/3/2 ThorstenBmailto: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

[jean pellotier]

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=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone&groupby=&sort=&id=385#makechanges

It appear in my setup that adding a radar section in the 
intrumentation.xml (or any name called by the  field in 
the -set.xml file) solve the bug, for all the planes tested (b1900d, 
bo105, iar80, super constellation etc...)

   
 wxradar
 0
   

- 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

flightgear-devel@lists.sourceforge.net

[jean pellotier]

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] Carrier Altitude

[jean pellotier]

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. -->
 			0
 			-1
 		
+false
 	
 	
 		translate
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. -->
 			0
 			-1
 		
+false
 	
 
 	
--
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

[jean pellotier]

> 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

[jean pellotier]

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.

[jean pellotier]

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

[jean pellotier]

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

Re: [Flightgear-devel] about mp refueling

[jean pellotier]

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

[Flightgear-devel] about mp refueling

[jean pellotier]

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 setBoolValue("tanker",isTanker);
+//props->setBoolValue("tanker",isTanker);
+props->tie("tanker", SGRawValuePointer(&isTanker));
 
 props->tie("controls/invisible",
 SGRawValuePointer(&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] aircraft search

[jean pellotier]

Le 23/07/2010 22:03, Alex Romosan a écrit :
> Alex Romosan  writes:
>
>
>> James Turner  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

[jean pellotier]

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® 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

[jean pellotier]

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 .xml file:
>
>
> [...]  
> The next list contains aircraft that have the bug,
> but it doesn't take any effect because  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® 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

[jean pellotier]

> Message du 12/02/10 12:56

> 
> I've checked in fixes to several shaders. Please test with current CVS. Some
> of the shaders referenced glFrontMaterial.ambient even though a color mode
> of AMBIENT_AND_DIFFUSE was set, which means that the fixed function pipeline
> takes the ambient color from the vertex color. I don't know what the spec
> says about this situation, but mixing the old pipeline with shaders is
> deprecated and probably a fertile source of bugs. Also, I cleaned up some
> other shader errors.
> 

It work if i remove the crop and landmass option, wich are still affected.

ps: i'm not sure the change i did to landmass.frag and crop.frag were of any 
effect, i just tested them in montagnous area, and a flight today in flat 
landscape showed buggy crop and landmass.

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

[jean pellotier]

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] Shader issue on ATI cards

[jean pellotier]

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=6&t=6875&sid=b02b4d5ebd4c827ca26fc60fd857dda7&p=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] Problem with modified apt.dat file

[jean pellotier]

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

[jean pellotier]

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

[jean pellotier]

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

[jean pellotier]

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

[jean pellotier]

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] fg shows a blank screen

[jean pellotier]

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] Latest CVS still showing major MP problems...

[jean pellotier]

Stuart Buchanan a écrit :
> Jacob Burbach wrote:
>   
>> Missing persons are listed in /ai/models/multiplayer[*], and
>> /ai/models/multiplayer[*]/valid is true. Yet they do not show up in mp
>> list, nor can I see there chat. Something has obviously changed within
>> the last few weeks, was fine before that. Another one of those
>> flightgear mysteries I guess...
hi, today i was testing mp properties export, running two FG instances, 
with crossed multiplay  ports on same PC (port 5000 and 5001), and i 
never had contacts in pilot list, neither chat working, but the planes 
were visible as usual.  i didn't test with a server, but last time i 
tried it worked.
i used no scenery (i was on water, but not a problem with jsbsim :) )  
planes were c172, F-4N and ufo.

and a little off-topic question, are the mp models now solid?

my 2 cents,

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]

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

[jean pellotier]

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 !!

[jean pellotier]

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 - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-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 !!

[jean pellotier]

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 !!

[jean pellotier]

> 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] working ridge lift !!

[jean pellotier]

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] aircraft modeling question

[jean pellotier]

 > 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

[jean pellotier]

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

[jean pellotier]

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

[jean pellotier]

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

[jean pellotier]

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  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

Re: [Flightgear-devel] Carrier landing and groundcache with JSBSimAircrafts

[jean pellotier]

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

[jean pellotier]

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] nimitz elevators non solid

[jean pellotier]

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

[jean pellotier]

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

Re: [Flightgear-devel] c172p-dual-pilot broken

[jean pellotier]

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] c172p-dual-pilot broken

[jean pellotier]

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

[Flightgear-devel] today's bug with pilot list

[jean pellotier]

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

[jean pellotier]

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

[jean pellotier]

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

[jean pellotier]

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

[jean pellotier]

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 @@
 	
 		rotate
 		Aiguille1-Adf
-		/orientation/heading-magnetic-deg
-		
-			0
-			0
-			0
-		
-		
-			1
-			0
-			0
-		
-	
-
-	
-		rotate
-		Aiguille1-Adf
 		/instrumentation/adf/indicated-bearing-deg
 		1
 		
-
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=100&url=/___
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)

[jean pellotier]

>> 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:

settacan(arg[0], "X")

settacan(arg[0], "Y")

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=100&url=/
___
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

[jean pellotier]

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=100&url=/
___
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

[jean pellotier]

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=100&url=/
___
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

[jean pellotier]

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:


Wave-Off-51
Models/Geometry/Nimitz/Models/wave-off.xml

0.1
0.77
-0.39



Wave-Off-52
Models/Geometry/Nimitz/Models/wave-off.xml

0.1
-0.77
-0.39



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=100&url=/
___
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

[jean pellotier]

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=cache&w=900&h=670&media=school:move:porte-avion:flols:waveoff-nimitz.jpg

have a nice landing on Nimitz

jano








  
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

  
  
carrier
LFRJ-bak26-1
	AI/Airports/LFRJ/BAK26+flols.xml
098Y
	line
	48.53306323
	-4.137254038
	335.4462275
	253.32
	
		25
		-30
		1.8 -->

	
	0
	0
	0
0
 
 
	  carrier
	  LFRJ-bak08-1
	  AI/Airports/LFRJ/BAK08+flols.xml
	  098Y
	  line
	  48.52714689
	  -4.166412234
	  334.8964534
	  73.32
	  
	  
		  25
		  -30
		  1.5
	  
	  
		  park-1
		  10
		  365
		  610
		  -2
	  
	  
	  
		  park-2
		  190
		  252
		  600
		  0
	  
	  
	  
	  0
	  0
	  0
  0
  

  
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 @@
 		Models/Geometry/Nimitz/Models/wave-off.xml
 		
 			0.1
-			0.77
-			-1.18
+			1.18
+			-0.77
 		
 	
 	
@@ -298,8 +298,8 @@
 		Models/Geometry/Nimitz/Models/wave-off.xml
 		
 			0.1
-			-0.77
-			-1.18
+			-1.18
+			-0.77
 		
 	
 	
-
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=100&url=/___
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?

[jean pellotier]

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/ 
> 
> 
>
> -
> 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=100&url=/
> 
>
> ___
> 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=100&url=/
___
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

[jean pellotier]

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

[jean pellotier]

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

[jean pellotier]

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

[jean pellotier]

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] FGCOM : sound card issues

[jean pellotier]

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

[Flightgear-devel] FGCOM : sound card issues

[jean pellotier]

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?

- currently fgcom is using my motherboard sound card with alsa, but the 
PTT don't work as it should: it never mute the mic (I use a bass pedal 
instead).
the motherboard chipset is a NVidia nforce2 , and the sound chipset 
seems to be realteck
ALC650F.
fgcom move the mic volume, but in this sound card, it does not affect 
the capture volume, just the playback volume of the mic.
there's a capture volume in this card but it's not usable because it has 
just a range of 15 dB, to ajust mic gain a little.
the only way to do it is to switch on/off the capture switch with for 
exemple:
amixer cset numid=29 0 (to mute)
amixer cset numid=29 1 (to unmute)
is there a way to make it working with that switch?

- at last, something about sound card config, yesterday we tryed to be 3 
in atc mode (a way to have air to air contact with curent fgcom) but it 
was impossible for me to understand what other said, because of lots of 
repeatable echo (suitable for reggae i think!!).
it was because of send of fgcom output to capture channel, by the 
microphone, or more probably by the sound card settings. (adjusting 
sound card volume and switch worked for two of us, so as to capture only 
mic input).
so be sure to  only capture mic when  using  fgcom .

jean.








-
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

[jean pellotier]

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

[jean pellotier]

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 :



0
1
0
-2
800
600
false
   -->

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

[jean pellotier]

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

[jean pellotier]

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

[jean pellotier]

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

[jean pellotier]

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