Re: [Flightgear-devel] How to check if the plane is on the ground (Weight on wheel)?
Not sure about C/C++ but in the property tree it's /gear/gear[index]/wow-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sim usage on a TV show
Hi, I work for a TV production company in Colombia, we are doing a show about people that like videogames, one of them likes flight simulators and we are wondering if it is possible to use material from your Flight simulator, also knowing if theres any document we can have to support its use and the distribution of this material to perpetuity and through all media and regions. Thank you very much I'm sure someone more central to the flightgear project will give you a more correct answer, But as flightgear is GPL, You are able to freely download/use/modify (with the right skill) and redistribute it (as is or as long as your changes are made public). The GPL license is included with a flightgear install under COPYING, But to save on the download here is the link from the source repository: https://www.gitorious.org/fg/flightgear/blobs/next/COPYING If you need to download it, here is a link to the download page: http://www.flightgear.org/download/ I've never heard of any law that states you cannot record video from software and broadcast it, even commercial software, but I'm not a lawyer, I don't live in America and that's more an area for some type of legal department to look into. I'd bet that flightgear attracts a fair few users because of youtube videos, I can't see any reason why this would not be allowed (and if I lived there I'd totally watch this too). -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Benchmark matrix
On 21/06/13 21:26, Arnt Karlsen wrote: On Thu, 20 Jun 2013 10:20:03 -0700 (PDT), geneb wrote in message alpine.lfd.2.03.1306201018050.25...@deltasoft.com: On Thu, 20 Jun 2013, Alan Teeder wrote: Instead of all this mudslinging about what slows what on which processor, could some thought be given to producing a benchmark suite for Flightgear. It would need to take in all of the, by now well known, variables - making it by no means a simple beast to manage. If this could be automated in some way it would be much easier to capture, and then submit, consistent data. A scripted run would be an EXCELLENT tool. ..aye, and a scripted run can be set up to play all the tricks, even if it needs to run FG several times to e.g. reset the graphics, and it can be set up to finish the run by offering to upload the results automatically. :o) Actually this is probably in my interests, I'm improving the concorde (3D cockpit, less laggy nasal, autopilot - slowly) but I have fairly powerful hardware so I'd like to know how much of what I do affects other users. A long time ago, I remember using this to try and figure out why I was getting 10fps on a nvidia GTX470 with the lowest settings and default renderer (I was accidently running a debug build): http://wiki.flightgear.org/Howto:Debugging_FlightGear_Crashes#Minimal_Startup_Profile I might come up with a dash script that tests things in different areas with different settings, But that will only be helpful on linux. I'll probably just use the telnet server to pull the property tree frame rates/spacing I haven't used it yet but I imagine it would be quite easy). -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Benchmark matrix
On 22/06/13 02:08, Arnt Karlsen wrote: On Sat, 22 Jun 2013 01:11:39 +1000, Christopher wrote in message 51c46d2b.8060...@gmail.com: On 21/06/13 21:26, Arnt Karlsen wrote: On Thu, 20 Jun 2013 10:20:03 -0700 (PDT), geneb wrote in message alpine.lfd.2.03.1306201018050.25...@deltasoft.com: On Thu, 20 Jun 2013, Alan Teeder wrote: Instead of all this mudslinging about what slows what on which processor, could some thought be given to producing a benchmark suite for Flightgear. It would need to take in all of the, by now well known, variables - making it by no means a simple beast to manage. If this could be automated in some way it would be much easier to capture, and then submit, consistent data. A scripted run would be an EXCELLENT tool. ..aye, and a scripted run can be set up to play all the tricks, even if it needs to run FG several times to e.g. reset the graphics, and it can be set up to finish the run by offering to upload the results automatically. :o) Actually this is probably in my interests, I'm improving the concorde (3D cockpit, less laggy nasal, autopilot - slowly) but I have fairly powerful hardware so I'd like to know how much of what I do affects other users. A long time ago, I remember using this to try and figure out why I was getting 10fps on a nvidia GTX470 with the lowest settings and default renderer (I was accidently running a debug build): http://wiki.flightgear.org/Howto:Debugging_FlightGear_Crashes#Minimal_Startup_Profile I might come up with a dash script that tests things in different areas with different settings, But that will only be helpful on linux. ..if you specify your FG commandlines, the Windroids will have a starting point, if they manage to come up with something that works on Mac 'n Linux too, we will be able to get a benchmark that fits all supported platforms. I'll probably just use the telnet server to pull the property tree frame rates/spacing I haven't used it yet but I imagine it would be quite easy). ..easier than e.g. wget on FG's web property server??? Might unduly disadvantage Wintendo, they do have Microsoft Internet Explorer built right into their os, and they may be able to script that too, and on benchmarking FG, we want the truth, and we wanna be conservative and err on the side of caution. ;o) To be honest I have never used the FG telnet/HTTP server so I didn't think about the HTTP part. I'll look at getting some type of script running tomorrow, I suppose if I get real creative and use msys/mingw I could probably get it cross-platform too (you mac guys should already have everything I need), but running linux, I'll try for that first. I'll need to come up with a long line of tests, Eg something like the minimal startup profile in the middle of the ocean and then test individual things like 3d clouds, the quality slider thing, random buildings/trees, advanced weather, different aircraft (compare ufo to concorde and you will see - but something in the default package), and then test it all again with rembrandt. I might also come up with an aircraft tester to see how different planes affect frame rates. Also there are strange things with my computer, Running rembrandt with all the effects off (it's probably just shadows) actually feels faster than the default renderer. Also either random buildings or random trees brings my computer to it's knees when flying around a populated area like hawaii, but I won't speculate anymore, I'll just wait until I come up with a script and see if it's what you guys are after. Feel free to suggest different tests for me to try. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Possible IVSI bug
I'm currently developing the concorde cockpit (slowly), But I've decided
to fix other things as well, at 50,000ft the IVSI jitters so I'm looking
into it. I know very little C++, but from what I can tell at first, the
IVSI data was a bit off. I ended up using these tables:
I added another decimal place to this list:
static double altitude_data[][2] = {
{ 0.00, 0.00 }, //These values are pressure values converted
from (1-delta(alt))*29.92
{ 3.058, 2952.76 },
{ 5.857, 5905.51 },
{ 8.416, 8858.27 },
{ 10.749, 11811.02 },
{ 12.874, 14763.78 },
{ 14.803, 17716.54 },
{ 16.552, 20669.29 },
{ 18.133, 23622.05 },
{ 19.559, 26574.80 },
{ 20.842, 29527.56 },
{ 21.993, 32480.31 },
{ 23.024, 35433.07 },
{ 23.935, 38385.83 },
{ 24.727, 41338.58 },
{ 25.414, 44291.34 },
{ 26.010, 47244.09 },
{ 26.528, 50196.85 },
{ 26.977, 53149.61 },
{ 27.366, 56102.36 },
{ 27.704, 59055.12 },
{ 27.997, 62007.87 },
{ 28.252, 64960.63 },
{ 28.472, 67913.39 },
{ 28.663, 70866.14 },
{ 28.828, 73818.90 },
{ 28.970, 76771.65 },
{ 29.094, 79724.41 },
{ 29.201, 82677.17 },
{ 29.294, 85629.92 },
{ 29.374, 88582.68 },
{ 29.444, 91535.43 },
{ 29.505, 94488.19 },
{ 29.558, 97440.94 },
{ 29.604, 100393.70 },
{ -1, -1 }
};
I figured out what the slope table actually was, It's more correct like
this (I think). The old slope table was somehow 2952.76 (900m to feet)
divided by these variables, and they weren't even that close. It makes
no sense like that, so I'm using inHg per fps.
static double pressure_data[][2] = {
{ 0.00, -0.0648736 }, // Not a guess anymore.
{ 2952.76, -0.0594508 }, // These values are actually
(delta(alt+30ft)-delta(alt-30ft))*29.92
{ 5905.51, -0.0543818 },
{ 8858.27, -0.0496502 },
{ 11811.02,-0.0452403 },
{ 14763.78, -0.0411364 },
{ 17716.54, -0.0373236 },
{ 20669.29, -0.0337873 },
{ 23622.05, -0.0305132 },
{ 26574.80, -0.0274875 },
{ 29527.56, -0.0246969 },
{ 32480.31, -0.0221284 },
{ 35433.07, -0.0197694 },
{ 38385.83, -0.0172583 },
{ 41338.58, -0.0149748 },
{ 44291.34, -0.0129935 },
{ 47244.09, -0.0112744 },
{ 50196.85,-0.00978270 },
{ 53149.61, -0.0084883 },
{ 56102.36, -0.0073653 },
{ 59055.12, -0.0063908 },
{ 62007.87, -0.0055452 },
{ 64960.63, -0.0048115 },
{ 67913.39, -0.00416220 },
{ 70866.14, -0.0035993 },
{ 73818.90, -0.0031144 },
{ 76771.65, -0.0026964 },
{ 79724.41, -0.0023359 },
{ 82677.17, -0.0020248 },
{ 85629.92, -0.0017561 },
{ 88582.68, -0.0015240 },
{ 91535.43, -0.0013233 },
{ 94488.19, -0.0011496 },
{ 97440.94, -0.0009994 },
{ 100393.70, -0.0008692 },
{ -1, -1 }
};
Then I changed the ft_per_s line to this
_speed_ft_per_s = rate_inhg_per_s / slope_inhg;
I do understand the jitter just may be a fact of life because it is an
IVSI, but looking at the inputs it uses, I don't really see why it
jitters so much.
And I cannot seem to get this into the property tree like this (to see
if it jitters too). It's just a debugging line, I'm not actually going
to export inhg/s as it is useless. It does seem to flicker once every 10
seconds or so however...
_inhg_diff_node-setDoubleValue(rate_inhg_per_s);
This is just as jittery with 1/500'th of the responsiveness value, but
atleast I can see it in the property tree. (More debug code).
_speed_rt_per_s = fgGetLowPass( last_speed_rt_per_s, _speed_rt_per_s, dt
/ 100 );
Sorry If I have broken any procedures with the mailing list, This is
also *nearly* the first time I have ever touched C++ (first mailing list
post too), but /src/Instrumentation/inst_vertical_speed_indicator.cxx is
not hard to understand.
The updated table values were taken from my spreadsheet, I calculated
the delta values and plugged them into the formulas to convert them to
inHG difference from 29.92, and finally inHG difference between alt+30
and alt-30 (it gives fps this way, the line is sampled over 60ft
though). The old values might have been sampled over a larger step
perhaps. They are kinda close to (my value) * 2952.76 / 60.
If I manage to debug this (aka get lucky at the moment), I'll create a
merge request with the fixed tables included.
TL;DR: IVSI jitters like crazy and I want to know if I can write a
double on the property tree without filtering it through fgGetLowPass.
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Possible IVSI bug
I knew something was up when I said they were close to (1km to feet) /
60. I took the 900m part out of the formula but didn't add a 60 part,
didn't check it properly. These are correct. And now accurate to a foot :)
static double pressure_data[][2] = {
{ 0.00, -0.001081226 }, // Not a guess anymore.
{ 2952.76, -0.000990846 }, // It's the delta difference * inHG.
{ 5905.51, -0.000906363 }, // These values are actually
(delta(alt+0.5)-delta(alt-0.5))*29.92
{ 8858.27, -0.000827504 },
{ 11811.02, -0.000754005 },
{ 14763.78, -0.000685607 },
{ 17716.54, -0.000622061 },
{ 20669.29, -0.000563121 },
{ 23622.05, -0.000508553 },
{ 26574.80, -0.000458125 },
{ 29527.56, -0.000411614 },
{ 32480.31, -0.000368806 },
{ 35433.07, -0.000329489 },
{ 38385.83, -0.000287638 },
{ 41338.58, -0.000249581 },
{ 44291.34, -0.000216559 },
{ 47244.09, -0.000187906 },
{ 50196.85, -0.000163044 },
{ 53149.61, -0.000141472 },
{ 56102.36, -0.000122754 },
{ 59055.12, -0.000106513 },
{ 62007.87, -0.92420 },
{ 64960.63, -0.80192 },
{ 67913.39, -0.69370 },
{ 70866.14, -0.59989 },
{ 73818.90, -0.51907 },
{ 76771.65, -0.4494 },
{ 79724.41, -0.38932 },
{ 82677.17, -0.33746 },
{ 85629.92, -0.29269 },
{ 88582.68, -0.25399 },
{ 91535.43, -0.22054 },
{ 94488.19, -0.19161 },
{ 97440.94, -0.16656 },
{ 100393.70, -0.14487 },
{ -1, -1 }
};
Btw, I've never used a mailing list before. Hopefully this ends up as a
reply of my first message.
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
