Re: [Flightgear-devel] Rembrandt - Some Feedback
On Sunday, April 01, 2012 01:45:52 PM ThorstenB wrote: With Rembrandt, brightness of the scenery seems to depend on the view's pitch angle a lot. So, when you fly along and pitch up/down heavily (take the ufo), you see the ground becoming brighter and darker. It mainly seems to affect the bright (non-shadow) areas. When pitching up, the ground eventually becomes as dark as the shadows (no contrast), while when pitching down, you see the ground being bright and only the shadows are dark: http://imageshack.us/photo/my-images/837/fgfsscreen.png/ cheers, Thorsten This sounds (looks) like the gamma is changed with the pitch angle. This would cause the mid-tones to change while the highlites and shadows remain the same. Hal-- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Live Multiplayer
On Friday, December 23, 2011 06:22:35 PM Pedro Morgan wrote: Is there a way we can work towards a more accessible multiplayer enviroment for next year + snip ATC == chat.. we need to look at skype. android and speakers with text to sound.. We alrady have fgcom - no need for skype since fgcom has integration with FG so that things like changing the freq. on the in sim com radio(s) causes fgcom to connect to a different channel and it also trys to simulate radio propagation. Is fgcom perfect? No it still needs work but it would be a lot of work to figure out how to get skype to do what fgcom already does and that same amount of effort could significantly improve fgcom. I don't see the point in moving to skype. There is alread some text to sound support using the festival text to speach engine. Festival works on a wide range of systems (Windows, Linux and Mac) although I don't know if it works on android. The text to speach support is primitive at best but I don't personnally think this is a big issue since IMHO the text chat feature in FG should be removed in favor of real voice communications via fgcom. After all few if any aircraft have text chat capabilities but almost all aircraft have com radios. snip Hal -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Live Multiplayer
On Saturday, December 24, 2011 04:07:06 PM Pedro Morgan wrote: Ok here's the scenario.. I'm a kid and taken off in a 747 and need some real world kinda help to land for teens... Problem with FG is that it needs to simulate a bit more.. and not be a long winded things snip ATC == chat.. we need to look at skype. android and speakers with text to sound.. We alrady have fgcom - no need for skype since fgcom has integration with FG so that things like changing the freq. on the in sim com radio(s) causes fgcom to connect to a different channel and it also trys to simulate radio propagation. Is fgcom perfect? No it still needs work but it would be a lot of work to figure out how to get skype to do what fgcom already does and that same amount of effort could significantly improve fgcom. I don't see the point in moving to skype. Indeed 1000% of above... agreed.. problem is that I want to control the kids downstairs and do do that I can use any comms system I want.. eg holding nose and saying in ATc voice.. down a toilet roll.. Turn left heading 295 .. decend and maintain 30 ft ,... etc.. At the end of the day its a VOIP server.. and is it peer to peer.. We need to get into the peer to peer and local networks more.. You can do this today with fgcom. Just setup a fgcom server on your local upstairs machine and you are good to go. You don't even need FG running to use fgcom to communicate with other users on your network. Make and easy install system and some sponshorship.. aas VOIP ==bandwidth == Money at the end fo the day.. is reality.. Skype, Asterix and Goggle talk are various platform..which potentially we can link into.. Maybe we can create a FGCOM virtual machine with amazon.. and others international.. There is alread some text to sound support using the festival text to speach engine. Festival works on a wide range of systems (Windows, Linux and Mac) although I don't know if it works on android. The text to speach support is primitive at best but I don't personnally think this is a big issue since IMHO the text chat feature in FG should be removed in favor of real voice communications via fgcom. After all few if any aircraft have text chat capabilities but almost all aircraft have com radios. What the Sim missing at the moment is some real ATC... We can create that with a STAR and SID patterns and is and ATC exersice.. Indeed the problem is that FG is all about the pilots and it actually needs some ATC to make it more real.. FG already has an ATC aircraft. What has been missing is people who are willing to send the time needed to setup a working ATC system for more than an hour or two at one or two airports using the existing tools. One of the issues is that fgcom is an addin and as a result ATC is broken out of the box since most (particularly new) pilots do not have a working com radio (IE. fgcom is not installed/running). Vatsim is a network, ivao is another.. Fg has all the flight side worked out.. I think there is already a Vatsim add in available for FG. maybe we need some zones of control.. both for the benefit of new pilots who wanna fly.. and pilots who do international and long range nav et all.. Certainly chatting to a russian aircraft AN225 and quided into london with a few smaller ones around tickles the OAT.. Whats the protocol anyway ?? For what part? Most of this is UDP packets using a FG specific format. I think this is described on one of the FG wiki pages. You should be able to google it. love u all pedro snip Hal - - Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
On Saturday, October 15, 2011 02:41:15 PM TDO_Brandano - wrote: Really, couldn't we just split off all the aircrafts to a separate SVN repository? Or to several GIT repositories? That way they could be checked out individually. I don't think we need the level of detailed history that GIT provides when it comes to aircraft data, and that way it would be possible for the Flightgear frontends to grab the aircrafts dynamically, if not even FGFS itself when using the multiplay protocol. And a developer should not need to download EVERY aircraft that was ever made for FGFS, One aircraft to test FGFS itself would be enough in most cases, and when checking aircraft specific issues it's a quick job updating only the one plane under exam. Cheers, Alessandro I don't think one aircraft is enough to test FGFS with. Too many differences between these aircraft. YASim vs. JSBSim and vastly different use of Nasal are just two examples. But I think it should be possible to test everything in FGFS with perhaps 8 or10 aircraft and there is definitly no need to have every aircraft in GIT for this testing. So the basis idea that we don't need all of the aircraft in GIT for testing is correct. Hal Date: Sat, 15 Oct 2011 23:33:14 +0200 From: flightg...@sablonier.ch To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] GIT Am 15.10.11 22:41, schrieb Christopher Baines: I know of another project who's main git repository contains a script, that manages the other git repositories, this allows them to split the gigs of data they have in to more sensible chunks, without having to pull every repository individually. Though the current state will be annoying for new developers on average speed internet connections as afaik, git cannot clone, stop half way, then continue. Looks like we have to live with a mix of clueless git experience and personal preferences of some administrators ? Cheers, Yves - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Content protection for modders?
On Sunday, August 28, 2011 07:43:47 AM Paul Guhl wrote: Hello all, i see the intention behind protecting models has been misunderstood. Lets clarify the issues: the modellers asked me to provide secured file format to prevent model theft and resell for benefit. They are willing to contribute to FG and don't plan to sell add-ons. Instead they would like to see their copyright enforced and not abused by others. AFAIK open source licenses in generall are about the programs and their code, not the conent people create with this software. I bet noone would ask companies using open office to disclose their documents or excel sheets ;). I also notice that MSFS enjoys greater attention by add-on creators. As for the protection realization: i think of an OSG format plugin supporting common OSG plugin conventions. The code won't be disclosed and only shipped in compiled form for dynamic linking against. Best Regards Paul If you don't want your stuff to be open source then don't use an open source license. But that means that you will have to maintain your own repository(s) and download facilities. It is also possible to dual license things such as having an open source license for non-commerical uses and a restriced fee based license for commercial uses. Again I think this would prevent it from bing hosted by FlightGear. Also if you could use an obscured file format then your stuff is NOT open source no matter what else you do. Security through obscurity never works and it surprises me that anyone thinks that it will but it appears that many do believe this. On the other hand if you license your stuff so that only certain uses are allowed any use outside of those that are allowed gives you the right to take legal action to prevent the missuse of your content. This has nothing to do with the format of the content (IE. readable or obscured). The reason that MSFS has an active commerical addon community is because of the profit motive. IE. these folks are doing it because they expect to make money and I don't think this has much if anything to do with the model file format. On the other hand no one is expecting to make a profit doing FG add ons. In addition, in FG much of the model are things beyond the 3D model. Althought the 3D model is important and a lot of work the bigger picture is that there is a huge amount of work involved in creating high quality FDMs and in doing things like animating the model and creating realistic systems (for example havng a realistic startup procedure). These non-3D parts of a model are at least as much work as doing the comparible quality 3D model part if not more. Of course this depends on the complexity of the aircraft being modeled and in some very simple aircraft the 3D model may be the single largest part of the effort but in complex aircraft it is not. All of the non-3D parts are in plain text (XML) and there is no way to obscure these without rewriting significant parts of FlightGear. On the other hand I would like to see some additional 3D formats supported. But not because I want to hide my content but because of the extra functionality. For example with the OSG or Blender formats we would have the potential to use bones in our models and this would allow for additional animation flexibility. This would be very useful for animating things like pilots or wing warping (Wright flier). Hal -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.4.0: on short final
On Friday, August 12, 2011 01:33:36 PM Torsten Dreyer wrote: Am 08.08.2011 23:07, schrieb Torsten Dreyer: Hi all, snip Some off topic: Today, Martin and I started to prepare our new simulator for road transport. Enjoy some pics here: http://www.c172fg.de/ Torsten, Still off topic - minor spelling error/typo on http://www.c172fg.de/. The text for the first photo should have flooded instead of flodded. Hal -- FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. http://p.sf.net/sfu/wandisco-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.4.0: on short final
On Monday, August 08, 2011 03:52:11 PM Martin Spott wrote: Derrick Washington wrote: Just wondering, have you guys addressed the serial transmission issues in this release? Bi-directional support, transmitting and receiving to the same port using multiple generic protocol command line options? We're pretty close to the release, feature freeze had been 17th July. Cheers, martin. In other words this might make it into 2.6 since it is very late in the 2.4 release cycle and no one has even started working on this yet. Hal -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The state of things in Flight Gear
On Wednesday, July 27, 2011 04:04:09 AM Slavutinsky Victor wrote: Moreover, that explanations not provided not for me only but for anyone. It's open source but way it open it can not be developed by ones for whom it seems to be open. That's the real problem what I can not solve, and, I suppose, no one outside of FG community can. The lack of internal documentation is an issue for many of not most open source projects. One reason for this is that it is a big undertaking to completely document a system of the complexity of FG. For example I just finished (meaning that it is good enough - not that it is perfect) documenting a Class for another project. This was a relatively simple class with about 22 methods. I spent the better part of a week's full time effort to document it and I wrote the code so I knew what it did before I started working on the documentation. I have not looked at the FG internals but I would guess that it has hundreds of Classes and many of these are likely more complex than the one I just documented. So writing detailed internal documentation for FG would probably keep some one occupied full time for the better part of a year. In the long run having this documentation would help the project but it is a huge undertaking. In addition, it is an undertaking that has little if any short term impact on the project which makes it even less attractive for potential contributers. Hal -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved forests
On Wednesday, July 27, 2011 03:30:06 PM Stuart Buchanan wrote:
Hi All,
I've got a small patch to improve the FG forests, along with some
particularly bad C++ I need advice on.
The patch does the following:
1) Fixes the longstanding bug where the first set of tree definitions
in a tile were used for all forests within that tile. This meant that
if you have an area of deciduous forest next to some evergreen, you'd
only see one type of tree or the other, depending on which was loaded
first.
2) Re-introduce a feature to fade in trees by distance, so that a
reduced density is visible at 2*tree-range-m, with full density at
tree-range-m. As the default tree-range-m is 8km, this help stop
forests springing up well after the rest of the tile is perfectly
visible.
On my machine I don't see any performance impact, despite the fact
that more trees are displayed. I'd appreciate it if those with more
graphics-constrained systems than my own would test this and let me
know if they think the frame-rate hit is acceptable given the
improvements in apparent tree coverage.
I'd also be interested to hear if tree range is a performance issue in
general and people would like control of it in a similar way to the 3D
clouds distance slider (if anyone uses that!).
The patch is available from http://www.nanjika.co.uk/flightgear/forest.diff
If I have time I'll do battle with git and see if I can submit it via
gitorious properly...
Now, for the bad C++ :)
Within the patch is the code below. The (*j)- just looks ugly. Surely
there's a better way?
I'm sure those of you who write C++ more regularly than me will
immediately be able to tell me where I'm going wrong!
-Stuart
TreeBin* treebin;
SGTreeBinList::iterator j;
bool found = false;
for (j = randomForest.begin(); (j != randomForest.end()) (!found);
j++) {
if (((*j)-texture == mat-get_tree_texture() )
((*j)-texture_varieties == mat-get_tree_varieties())
((*j)-range == mat-get_tree_range())
((*j)-width == mat-get_tree_width())
((*j)-height== mat-get_tree_height() ) ) {
treebin = *j;
found = true;
}
}
It appears that SGTreeBinList is a list of pointers to some structure. If
that is the case then you need to dereference two pointers to get stuff from
the structure since the iterator, j, is a pointer. Thus you get *j-texture -
*j dereferences j and - dereferences the pointer pointed to by j. I don't
think that you gain anything by writing this as (*j)-texture since this is
basically the same thing as *j-texture. IMO *j-texture is easier to read.
But there is one minor and very common issue with the code that should be
fixed. In the for loop
for (..; ..; j++)
should be
for (..; ..; ++j)
if you use j++ the compiler has to make a copy of j with each iteration of the
loop but if you use ++j it does not have to make a copy. This will make the
loop more efficient although only by a small amount.
Hal
--
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 63, Issue 5
On Tuesday, July 12, 2011 12:02:04 AM Emilian Huminiuc wrote:
On Tuesday 12 July 2011 04:18:33 Hal V. Engel wrote:
On Monday, July 11, 2011 10:05:07 AM BARANGER Emmanuel wrote:
have you tested the script of Pierre NEGRE ? :
http://rene16.dyndns.org/run/ (import/export .AC for Blender 2.58)
Where can this be found? The web page is in French (I think) and I don't
find any links to the AC3D plug-in. I thought that perhaps the plug-in
was availble as a native part of 2.58 but I just built blender svn and it
does not have any AC3D import/export support.
Blender 2.5 has a better UI than 2.4 and I would like to be able to use
it for work on my models but the lack of AC3D support makes this
impossible.
Hal
Hal, try here
http://rene16.dyndns.org/run/index.php?option=com_contentview=articleid=5
3Itemid=61
and then click io_scene_ac.
Found it and installed it. After I got it activated I tried importing some
simpler models. The import blows up with a bunch of python errors. So it
looks like we will need to wait for something that actually works.
Btw. I've noticed you have gentoo, and that you upgraded to osg3. Have you
got an ebuild for that?
I've tried by modifying the existing 2.9.10 one, but it seems i've been
missing some things, since most models were looking wrong :(.
I just copied the 2.9.10 ebuild from the gamerlay overlay to my local overlay
and renamed it. The only change I made was to comment out the cmake.patch
lines.
IE.
# src_prepare() {
# epatch ${FILESDIR}/${PN}-cmake.patch
# }
My models look OK with this setup.
There is also a version bump request in the Gentoo bug tracker (365143) but it
has not been responded to other than it being assigned to the group that
handles gaming stuff. I bumped it for 3.0 about a week ago. It might actually
be faster to contact the person who does the gamerlay overlay since the most
recent version in portage is 2.8.3 which is rather old at this point. You
should consider voting for the bug.
By the way my current FG setup is crashing occationally. I am not sure of the
source of the crashes at this point. That is I don't know if the crashes are
related to the aggressive optimization or if they are OSG3 related or
something in the recent GIT versions of FG or simgear. I will try to sort it
out over the next few days.
Hal
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on Lean Startup
Secrets Revealed. This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor GUI layout improvements
On Monday, July 11, 2011 05:37:06 AM Stuart Buchanan wrote: Hi Thorsten, I think we've gone beyond what can be done for the upcoming release, but comments below. On Sun, Jul 10, 2011 at 7:30 AM,thorsten.i.renk wrote: 2) As it stands, it's very difficult for a new user to understand the difference between Local Weather and Global Weather. let alone how they inter-relate. Enabling the Local Weather package requires setting Enabled local weather module from the Local Weather Settings menu, yet the rest of the settings a user is likely to want are in the Local Weather dialog. As a first step to sorting this out, I'd like to do the following: 2a) Move the Enable local weather module checkbox to the Local Weather dialog. In my opinion, a clean solution would be to introduce a new master weather dialog on which the user can specify * is live weather to be used or an offline solution * which weather system (local or global) is supposed to render the weather information (and supply the offline solution if applicable) Yes, a unified dialog for high level weather setting would be a very good idea, This would undo some of the work that (Torsten?) did to amalgamate the various global weather dialogs some time ago, but I think splitting off the METAR/scenario section at the bottom of the dialog makes a lot of sense given that in most modes the various detailed configuration options are read-only anyway. I also wonder if the terms global and local are really applicable. Would static weather modeling and dynamic weather modeling be better terms, or how about simple/complex? 2b) Move Local Weather Settings to the Debug menu, on the assumption that more users will never need to modify the settings there (Thorsten R. - is this true?) No - quite the contrary. The design philosophy is (not strictly true, but mostly): * Local Weather (i.e. what used to be Local Weather Tiles) is a launcher - everything you select here is parsed only at startup of the weather system, but cannot be modified runtime I think this launcher aspect is something that we want to hide from the end-user. Most people just want to be able to change the weather system and then press Apply or OK. Having to press Stop first is very different from the rest of the UI. I think we'll want to make this implicit, so the user can press (say) Apply, and the underlying weather system stops and then is started under the covers with the new parameters. Apart from the stop/start time (which could be handled by a please wait message), is there any reason we couldn't do this? * Local Weather Settings contains all options which can be modified runtime. The main purpose is to get a handle on performance - for instance you might start out on relatively clear skies, so you can render clouds out to 55 km without large framerate impact - but then as you go on, you come into overcast skies, and the framerate drops like a rock - this menu allows you to choose runtime that you'd like to see clouds only to 20 km and get the framerate back So in my view, this should not appear in debug (for reference - I use the 'Settings' menu maybe 3-4 times per hour of flight or so). I think 90% of users are going to struggle to understand what most of these settings mean. Is there one particular setting that you are changing regularly? Perhaps we could extract it alone and give it a easier to understand name? Alternatively, could we use some arbitrary Performance/Quality slider that is mapped to these settings? -Stuart Or a Performance/Quality setting that could be tied to a frame rate thresholds that would automatically throttle the rendering quality based on what frame rates the user is seeing. Hal --- --- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 63, Issue 5
On Monday, July 11, 2011 10:05:07 AM BARANGER Emmanuel wrote: have you tested the script of Pierre NEGRE ? : http://rene16.dyndns.org/run/ (import/export .AC for Blender 2.58) Where can this be found? The web page is in French (I think) and I don't find any links to the AC3D plug-in. I thought that perhaps the plug-in was availble as a native part of 2.58 but I just built blender svn and it does not have any AC3D import/export support. Blender 2.5 has a better UI than 2.4 and I would like to be able to use it for work on my models but the lack of AC3D support makes this impossible. Hal -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OSG3 frame rates and multithreading
On Saturday, July 09, 2011 11:33:21 PM thorsten.i.r...@jyu.fi wrote: Maybe you're also so lucky that no matter what conditions, your framerate is high enough - I'm not, so I have to change settings when the scene changes enough. * Thorsten Speaking of frame rates and eye candy. I recently changed from OSG2 to OSG3. When I installed it I also rebuilt simgear and FG using -O3 optimization for all packages including OSG. With OSG2.X using the same GCC optimization settings I was getting about 22FPS with minimal eye candy and sometimes it would drop down into the 15FPS range although at times it was also somewhat higher with a peak rate of about 25FPS. Usable but not optimal. After the upgrade to OSG3 the same setup (IE. how much eye candy was being used, same aricraft, similar weather other settings the same) was running at about 45FPS. So it basically doubled the frame rate! Of course YMMV. I was able to add a considerable amount of eye candy and still have my frame rate remain above 30FPS. I now have the frame rate throttled at 30Hz and it basically locks onto 30FPS and stays there. This is with multiplayer turned off. This is a near optimal setup for me although I would like to be able to get this frame rate with full eye candy and multiplayer enabled. FYI I am running the following: AMD Athlon 64 4800+ with 2 gig ram Nvidia 7950 with 256 meg ram no over clock on the CPU or GPU Gentoo Linux 64 bit install FG and Simegear packages from the gamerlay overlay OSG3 hand created ebuild in the local overlay So this is not a high end machine by current standards although it is not a low end machine either. I have local weather selected with tie range to frame rate set to about 30 although it is hard to tell exactly where this is set in the dialog. Also in my preferences.xml I have: multithreading-mode AutomaticSelection /multithreading-mode With OSG2 this worked and I could see fgfs using CPU cycles on both CPU cores. This did increase frame rates compared to single threading but only by perhaps 25% on average but it also seemed to improve frames rates even more under condidtions that would result in lower frames rates.With OSG3 this does not happen and it appears to only be single threaded. Do I have to do something different with OSG3 to get multithreading? If multithreading was working would I see a similar frame rate improvement in OSG3 to what I got with OSG2? Hal -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No panel or object display in latest code
On Sunday, July 03, 2011 10:28:41 AM Roland Häder wrote: Hi Bruce, this is how I configure osg (3.0.0 ATM): reconfigure.sh -- #!/bin/sh export CFLAGS=-g -O3 -fPIC export CXXFLAGS=-g -O3 -fPIC cmake -D CMAKE_BUILD_TYPE:STRING=Release -D \ CMAKE_INSTALL_PREFIX:PATH=/opt ../../osg/ reconfigure.sh -- As you can see, I specify ../../osg/ which means I'm doing a so called out-of-source-tree build. Jester told me that this has the big advantage that the checkout (source) tree doesn't get polluted with build files so it remains in a clean state. And you can have differently configured source trees (e.g. one with Release, other with Debug and both with different install prefixes). Regards, Roland Is FG compatible with OSG3? Hal -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A new goodie for FlightGear presentations
On Thursday, June 30, 2011 02:31:15 PM Torsten Dreyer wrote: The instruments will be replaced by TFT displays and certainly all controls will be functional, I'd even love to see the control surface move, have force- feedback and (dreaming...) Have you considered using something like this: http://www.simkits.com/products.php?groupid=54 These guys sell fairly compete 172 panels and the protocall/interface to these devices is documeted and available to anyone who asks. You need to specifically ask for the protocall/interface docs since the only docs on-line are about using their (Windows and MS Flight Sim) software. I got a copy of one of the protocall/instaerface docs (I think it was for the altimeter but I can't find it now) about two years ago and it should not be an issue to hook these into FlightGear even on a Linux box. The only drawback I see for these is that they are not cheap at about $400 to $600 per instrument if prebuilt but you can also get these in kit forum and get these for less than 1/2 the prebuilt price. Compared to a TFT panel they would be more realistic in your aircraft. Hal -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A new goodie for FlightGear presentations
On Thursday, June 30, 2011 05:25:52 PM Hal V. Engel wrote: On Thursday, June 30, 2011 02:31:15 PM Torsten Dreyer wrote: The instruments will be replaced by TFT displays and certainly all controls will be functional, I'd even love to see the control surface move, have force- feedback and (dreaming...) Have you considered using something like this: http://www.simkits.com/products.php?groupid=54 These guys sell fairly compete 172 panels and the protocall/interface to these devices is documeted and available to anyone who asks. You need to specifically ask for the protocall/interface docs since the only docs on-line are about using their (Windows and MS Flight Sim) software. I got a copy of one of the protocall/instaerface docs (I think it was for the altimeter but I can't find it now) about two years ago and it should not be an issue to hook these into FlightGear even on a Linux box. The only drawback I see for these is that they are not cheap at about $400 to $600 per instrument if prebuilt but you can also get these in kit forum and get these for less than 1/2 the prebuilt price. Compared to a TFT panel they would be more realistic in your aircraft. Hal Also there are these guys: http://www.flightillusion.com/ I don't know if they make the protocall/interface docs available or not. But might be worth a try. Hal -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
On Saturday, June 25, 2011 09:04:30 AM Jari Häkkinen wrote: On 2011-06-25 16.06, Vivian Meazza wrote: The most _likely_ cause is the ATI Radeon HD 4670/256 MB VRAM. The GeForce 8600M GT is known to be better at handling shaders. 256 Mb VRAM is in both cases a bit small for FG nowadays. There are other possible contributors to a low framerate - AI traffic is one. 60 fps could be a maximum if you are using this option - --prop:/sim/frame-rate-throttle-hz=60 It might well be on by default. I am not using the frame-rate-throttle option but I tried it with a lower limit. This will naturally decrease the frame rate so it seems like 60 is a limiting number. I have to decide if the 3D clouds are worth a graphics card upgrade. Thanks for the response. Jari The 60 FPM limit is probably because the diver is syncing to the vblank signal from the monitor. For most LCD type monitors with will either be 60Hz or 120Hz. For the nvidia X11 drivers you can turn sync to vblank on and off. I generally have mine on since there is no reason to have the video card produce a frame rate higher than the monitor refresh rate. I don't know if this is configurable in the OS/X video drivers. Hal --- --- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Friday, June 24, 2011 05:19:58 AM Francesco Angelo Brisa wrote: 2011/6/24 TDO_Brandano - tdo_brand...@hotmail.com Ok, before I get flamed to a crisp, let me explain what is my reasoning behind this. Right now the fgdata repository is about 9 GB. [...] I agree with Brandano, airplanes data is way too big for git, and the problem will only get worst with time. I would keep in git only a maximum of 3 aircrafts + UFO for scenery building. The rest should be kept away (I have no good idea right now). Can't the repository be hosted on the same server of the fgdata ? Cheers Francesco 1. GIT is not the real issue as it is a powerful version control tool that can handle as much as any other tool out there. 2. The real issue is that fgdata is too big resulting in huge downloads and developers getting all kinds of stuff that they don't need. That is most of the work in fgdata is aircraft work and most aircraft devs only touch one or two of the hundreds of aircraft in the repository. 3. Regardless of what source code control system is used #2 is still an issue unless fgdata/Aircraft is somehow decomposed into seperate repositories for each aircraft. 4. I think #3 applies to all aircraft including the UFO and any other core aircraft. That is all aircraft should have code managed in the same way. 5. Having seperate aircraft repositories implies that there will be an fgdata build that can create a fully functional fgdata directory with some set of aircraft. 5a. Perhaps this build can be configured by the user to use the aircraft status as a way to filter which aircraft are included in the build and perhaps there should be a small default set of aircraft that are always part of the build. 5b. For those following GIT who need to do regualr updates to fgdata to keep it in sync with fgfs GIT this will make that process faster and less bandwidth hungery. 6. Because we now have a functioning --fg-aircraft configuration using seperate repositories should be easy for aircraft devs to setup even if they are working on more than one aircraft. 7. Having seperate repositories for each aircraft would also facilitate managing who has commit and review privilages for each aircraft and allow for more fine grained security. 8. There are a lot of details that need to be sorted out to make this work. Hal Waiting for comments, flames and people asking who is this guy?, yours sincerely, Alessandro Garosi (aka Brandano on IRC) - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] P-51D and SCR-522C merge request
I have just put in merge request 106 to merge P-51D and SCR-522C updates. These inlcude the VHF radio functionality and the propwash changes to the FDM. Hal -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal updating properties in the menu
On Sunday, June 19, 2011 05:12:31 PM Ron Jensen wrote: On Sunday 19 June 2011 17:55:25 Hal V. Engel wrote: On Sunday, June 19, 2011 02:15:54 PM Ron Jensen wrote: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg3 02 08 .html gui.menuBind(radio, dialogs.Radio.open()); Thanks I knew I saw something about this on the list but I coundn't find the emails that covered it. When I try to use it it fails when I click on the menu item. snip Hal In the example case you are running in the namespace dialogs so, in the setfile you would have: nasal dialogs filemynasal.nas If you have something different, you need something different... Assuming you load the nasal in this block: nasal p51d fileAircraft/p51d/Nasal/over-ride-flaps.nas/file fileAircraft/p51d/Nasal/stores.nas/file fileAircraft/p51d/Nasal/limits.nas/file fileAircraft/p51d/Nasal/engine-start.nas/file fileAircraft/p51d/Nasal/sputter.nas/file fileAircraft/p51d/Nasal/climbrate.nas/file fileAircraft/p51d/Nasal/gear-doors.nas/file fileAircraft/p51d/Nasal/gear-lever.nas/file /p51d /nasal gui.menuBind(radio, p51d.radio.open()); Ron Ron, Thanks that was the issue. I had the radio nasal file in a SCR_522C section in my *set.xml file and I should have used SCR_522C.Radio.open() in the gui.menuBind() call. I have it working nicely now. I will have the radio code in my fgdata clone updated shortly and when this gets merged into fgdata it should be usable by anyone who is modeling a WWII/Korean war era US or UK military aircraft since almost all of these used this radio. At this point the radio control unit is fully modeled and fully functional. About the only area where it could use improvement is that it currently has no keyboard mappings but all of it's features can be manipulated with a mouse. Hal -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Functions for Propwash and Downwash [was: Clarification on YASim input]
On Sunday, June 19, 2011 09:58:48 AM Bertrand Coconnier wrote: 2011/6/19 Ron Jensen w...@jentronics.com: On Saturday 18 June 2011 21:00:41 Jon S. Berndt wrote: Here's an example from Hal's P-51D Mustang. This is from an old version, so it may have changed by now, but it illustrates the approach. In the aerodynamics section of the config file - but outside of any axis element - is this definition of qbar due to propwash: [Note: v is shorthand for value, and p is shorthand for property.] function name=aero/thrust-qbar_psf product v 0.5 /v p atmosphere/rho-slugs_ft3 /p pow sum p velocities/u-aero-fps /p product p propulsion/engine/prop-induced-velocity_fps /p v 2.0 /v /product /sum v 2.0 /v /pow /product /function I recently added this function to the A6M2 Zero. I placed it on CYdr (rudder yaw) and dCLdf (flap lift delta) as well as CMde. It makes the plane fly much, much better during the initial takeoff roll. It probably should be used with CMdf (pitch due to flaps) as well. But why are you multiplying propulsion/engine/prop-induced-velocity_fps by 2? The total velocity of the air flow in the far slipstream is V+2*w where V is the velocity of the airplane and w is the induced velocity as computed by the momentum theory. See the following discussion in the JSBSim mailing list : http://sourceforge.net/mailarchive/forum.php?thread_name=201004181833.32417 .ghmalau%40gmail.comforum_name=jsbsim-devel Bertrand. I just added this to the P-51D this morning. I have this setup so that the propwash affects Roll_moment_due_to_rudder Cldr, Pitch_moment_due_to_flaps Cmflap, Delta_Lift_due_to_flaps dCLflap, Lift_due_to_Elevator_Deflection CLde, Pitch_moment_due_to_gear Cmgear, Pitch_moment_due_to_elevator Cmde and Pitch_moment_due_to_alpha_horiz_tail Cmht. It had a significant impact on low speed high power handling. The rudder has authority much earlier during take off and the tail lifts in a very natural way during the take off run. Over all these changes made take offs easier and more natural feeling. This also made it less likely to ground loop during the engine runup. This is an easy enhancement to do and it appears to improve ground handling and take off significantly. I have these changes checked in to my fgdata GIT clone if anyone wants to try them. Hal -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clarification on YASIM input (actionpt)
On Saturday, June 18, 2011 08:00:41 PM Jon S. Berndt wrote: From: syd adams [mailto:adams@gmail.com] Does jsbsim ? I've just begun to look into it , so I don't really know jsbsim's capabilities. It's not automatic - not a natural effect calculated by JSBSim code itself. Like many things in JSBSim, the facilities are present to let the aircraft flight model developer add these kinds of things. The contributions from the tail, (such as moment due to elevator, lift due to elevator) are functions of alpha and qbar. Both alpha and qbar are affected by propwash, since propwash speeds up the airflow immediately behind it if it is producing thrust. When defining lift or moment contributions from the elevator, the alpha and qbar that are parts of that definition can be modified by a function that includes the effects of propwash. So, it's very configurable. You could even include the effects of beta (sideslip) so the effects are blended out if beta is too high. Here's an example from Hal's P-51D Mustang. This is from an old version, so it may have changed by now, but it illustrates the approach. In the aerodynamics section of the config file - but outside of any axis element - is this definition of qbar due to propwash: [Note: v is shorthand for value, and p is shorthand for property.] function name=aero/thrust-qbar_psf product v 0.5 /v p atmosphere/rho-slugs_ft3 /p pow sum p velocities/u-aero-fps /p product p propulsion/engine/prop-induced-velocity_fps /p v 2.0 /v /product /sum v 2.0 /v /pow /product /function Later, within the pitch axis definition, is this definition: function name=aero/coefficient/Cmde descriptionPitch_moment_due_to_elevator/description product propertyaero/thrust-qbar_psf/property propertymetrics/Sw-sqft/property propertymetrics/cbarw-ft/property propertyfcs/elevator-pos-rad/property table independentVarvelocities/mach/independentVar tableData 0.-0.8 2.-0.200 /tableData /table /product /function These were never in any of the code I worked with and were removed before I started working on the FDM. My current Cmde function looks like this: function name=aero/coefficient/Cmde descriptionPitch_moment_due_to_elevator/description product propertyaero/qbar-psf/property propertymetrics/Sw-sqft/property propertymetrics/cbarw-ft/property propertyfcs/elevator-pos-rad/property table independentVarvelocities/mach/independentVar tableData 0. -0.9 0.66 -0.6 0.74 -0.4 1. -0.05 /tableData /table /product /function This is using the qbar-psf which is not influenced by prop wash. The Cmde function Jon has above has a lookup table that goes from MACH 0 to MACH 2 in a linear fashion. This looks like something intended for a supersonic aircraft and is not what I would expect from a subsonic aircraft. The table I am using goes from MACH 0 to MACH 1 and has a strong inflection at MACH 0.74 which is unlike the one in Jons function since it is non-linear. There are other interesting things in the look up table. MACH 0.66 is were MACH drag becomes a factor for the P-51 series and MACH 0.74 is the speed at which compressibility effects start to set in. I have not changed this function and this is what I grabbed from the JSBSim code repository when I started working on the P-51D. So someone, perhaps Jon, worked on this at some point. It looks to me like this is basically correct for the P-51 since the MACH values used are right from the NACA reports. The above should cause a very mild tuck at speeds above MACH 0.66 and the tuck should get much stronger above MACH 0.74. This is sort of what happens to the real thing at these speeds but it also porpoises above MACH 0.74. I have a seperate compressibility function that adds more tuck and also causes the porpoise affect above MACH 0.74 by changing the pitch moment in a sinusoidal fashion with the frequency and strength increasing at higher MACH numbers. All of this is writen in pure JSBSim functions with no need for Nasal. The airframe will break up at about MACH 0.8 since the G forces from the porpoising will cause too much negitive G. I also agree with Jon that JSBsim is VERY powerful and if you understand how some force should act on the airframe you are modeling you should be able to write a function or a set of functions that will provide those forces for your model. But it can take a lot of effort to put these things together. One thing that we need is for modelers to start building up example JSBSim code for things that
[Flightgear-devel] Nasal updating properties in the menu
I need to over ride one of the default menu items so that I can use a custom menu. After some effort I have figured out what needs to be changed in the property tree. The code looks like this: # Disable the menu item Equipment radio so we use our own gui. gui.menuEnable(radio,0); # override default radio menu setprop(sim/bindings/menu/binding[35]/dialog-name, SCR-522C-radio); setprop(sim/menubar/default/menu[5]/item[3]/binding/dialog-name, SCR-522C-radio); setprop(sim/menubar/default/menu[5]/item[3]/name, SCR-522C-radio); gui.menuEnable(SCR-522C-radio,1); And this is working. But I am concerned that if the menus should be changed (IE. items added or removed) that this would no longer be correct and the code will start failing. Is that true? If so ithere a better way to do this sort of thing? Hal -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal updating properties in the menu
On Sunday, June 19, 2011 02:15:54 PM Ron Jensen wrote: On Sunday 19 June 2011 15:04:11 Hal V. Engel wrote: I need to over ride one of the default menu items so that I can use a custom menu. After some effort I have figured out what needs to be changed in the property tree. The code looks like this: # Disable the menu item Equipment radio so we use our own gui. gui.menuEnable(radio,0); # override default radio menu setprop(sim/bindings/menu/binding[35]/dialog-name, SCR-522C-radio); setprop(sim/menubar/default/menu[5]/item[3]/binding/dialog-name, SCR-522C-radio); setprop(sim/menubar/default/menu[5]/item[3]/name, SCR-522C-radio); gui.menuEnable(SCR-522C-radio,1); And this is working. But I am concerned that if the menus should be changed (IE. items added or removed) that this would no longer be correct and the code will start failing. Is that true? If so ithere a better way to do this sort of thing? Hal http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg30208 .html gui.menuBind(radio, dialogs.Radio.open()); Thanks I knew I saw something about this on the list but I coundn't find the emails that covered it. When I try to use it it fails when I click on the menu item. Here is my code: var radio = gui.Dialog.new(sim/gui/dialogs/SCR-522C/dialog, Aircraft/Instruments-3d/SCR-522C/Dialogs/radios.xml); gui.menuBind(radio, dialogs.radio.open()); When I select Equipment -- Radios I get the following error message in the console: Nasal runtime error: undefined sysbol: dialogs at /sim/bindings/menu/bindings[35], line 1 I must be doing something wrong but I don't see what it is. Can anyone here spot my error? Hal --- --- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SCR-522
On Saturday, June 18, 2011 01:17:10 AM Vivian Meazza wrote: Hal, Since the dialog seems to be fundamentally broken, and in view of the freeze that has been declared on fgdata, I won't be merging this immediately. I'll see if I can fix up the Nasal errors, and then review the situation. Vivian Vivian, Beyond commenting out the calls related to the menu I made some other changes to the nasal code including adding a reimplementation of controls.ptt() and a new listener for the tr-lock along with correcting other issues with the code (references to systems/comm were changed to instruments/comm and some of the code had logic errors). At this point with the menu related stuff commented out it all works and no error or warning messages are produced. Everything else that is new is in the xml file which is now approaching 680 lines. I still need to add illumination animations for the new components (fittings/connectors) on the bottom if the control box so it may be over 700 lines when this is all in place. All of the items in the xml are animations of some sort. I am not even close to being proficient on the menu part of this since the only FG related menu I have ever made was the P-51D specific menu. This is a very simple menu that does mostly very simple things (IE. it is a list of things that the user can choose to enable/disable like loading rockets or drop tanks) and this is a standalone menu not something that is a replacement for a standard menu item. So it is a very different beast from the radio menu. The radio can be used as is and is fully functional. The only issue is that it is limited to the VHF frequencies that were programmed into comm1 and comm2 at startup. Users could setup some property over rides for these in fgrun or on the command line to setup the four VHF channels for their flight plan or change these using the property browser. This would actually be more realistic but less convenient than having a menu to change these since in the real thing you can't change the installed frequencies other than having a radio tech do this on the ground. That is the radio needs to have new crystals installed and then be tuned up/adjusted for the changed frequencies. So it is worth while getting the new version integrated into your Spit even if it will not be part of GIT until after the freeze. In the mean time maybe we can figure out the menu stuff. I will have this in my fgdata clone later today. Hal -Original Message- From: V. Engel [mailto:hven...@gmail.com] Sent: 18 June 2011 05:50 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] SCR-522 On Friday, June 17, 2011 11:33:29 AM Hal V. Engel wrote: On Sunday, June 12, 2011 03:07:25 AM Vivian Meazza wrote: Hal, snip I grabbed your code off of GIT and did some minor mods to it mostly to point things at the right locations. The menu XML is currently unmodified. I am trying to get it to work but I am getting loadxml errors from Nasal when I hit the var radio = gui.Dialog.new(dialog, Aircraft/Instruments-3d/SCR-522C/Dialogs/radios.xml) line of code. The error message says: loadxml: reading 'full path to the above file' denied (unauthorized access) Nasal runtime error: Dialog class: XML dialog mush have name From mfranz on the forums I learned that this should not be happening and that it could be an issue with the loadxml fgcommand when using --fg-aircraft. My fg-aircraft path is showing up in the log in the IORules/READ: line when I have --log-level=info set. I am running GIT from about 3 weeks ago. That's all looking good. Can we get it into Git soon? snip I now have everything except the menu working. The 3D model is complete although the texturing of the fittings on the bottom of the unit is crude (but these are not visible in most installations). All of the controls have hot spots and the radio control unit can be fully manipluated with a mouse. Everything appears to be working correctly including how the ptt works with a remote ptt switch. All of the lights are functional and so is the dimming mask. I will be pushing this to my gitorious fgdata copy tomorrow along with some other P-51D updates after I make sure that everything is tested again. WIth the freeze I don't know if I will be able to get this into GIT but the radio has been in GIT for some time so perhaps I can. Once it is in my gitoriious copy of fgdata you can grab it for your Spitfire work. In the mean time perhaps some one here might know how to get the radio menu working or perhaps have some ideas about things that can be tried. Hal -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure
Re: [Flightgear-devel] SCR-522 (was RatingSystemRedux(wasRe:Flightgear-devel Digest, Vol 61, Issue 12))
On Sunday, June 12, 2011 03:07:25 AM Vivian Meazza wrote: Hal, snip Too much info - does that photo show the dimmer mask in the down position? I think so, it looks as if I am wrong about the hole theory - the blue is transparent mask over - what? Perhaps a more transparent blue mask? The T/R lamp is not masked. But I'm not sure that we want to introduce a transparency in our model - bad for framerate. We can easily fix things to look right without transparency. My current working therory is that the mask is a set of darker colored lenses that can be moved over the lighter colored lenses to reduce the brightness. I now have a light and a dark version of the lense/light and have select animations that enable to correct one depending on the possition of the mask control lever. No need for transparancy. Not hard to do and I have it working nicely at this point. This also reduced the number of vertices in the model by a significant amount. I will change the colors of the lamps to match the documentation. But this is another case where the evidence is contradictory. What colors should these be when lit and off? I will make my best guess and if some evidence comes along that my guess is incorrect it will get fixed. Green is a very usual colour for channel lights - and red/orange for T (but we know that the SCR-522 worked in reverse). But all photos show the unlit lamps/mask to be blue. Not all of them. See: http://images.cloud.worthpoint.com/wpimages/images/images1/1/0709/12/1_d877943869d6f53fd314861cb0592d63.jpg snip Please take anything you want. Did you notice that the binding for F12 was changed to bring up the new menu? I would really like to use the new dialog in the same way as the default one rather than in the aircraft-specific menu, but right now can't figure out how to do that. I grabbed your code off of GIT and did some minor mods to it mostly to point things at the right locations. The menu XML is currently unmodified. I am trying to get it to work but I am getting loadxml errors from Nasal when I hit the var radio = gui.Dialog.new(dialog, Aircraft/Instruments-3d/SCR-522C/Dialogs/radios.xml) line of code. The error message says: loadxml: reading 'full path to the above file' denied (unauthorized access) Nasal runtime error: Dialog class: XML dialog mush have name Is this what is preventing you from using this as a replacement for the default radio dialog? I am stumped as I have not been able to find anything on-line about this error message other than cases where the file didn't exist or a null file name was passed neither of which is the case here. Any ideas about what to look for? snip Looks like the our channel select buttons could do with a bit more detailing - from this and other photos, it looks as if they had a raised rim. I have added the rims to my local model now. I also have pick amination on the channel select buttons and the mask lever. I need to implement the tr lock and T/R/REM lever animation and hot spots. I also need to get the T/R light working correctly and also get this so that the ptt button works correctly when the radio is in the REM (ptt button should work) and R (ptt button should be ignored) positions. snip That's all looking good. Can we get it into Git soon? I spent about 8 hours over the last few days working on the radio. The radio looks very good right now and is getting closer. Once I get the menu stuff working and sort out the remaining details I will get it into GIT. Hopefully someone here has a clue about what is going on with the XML loading issue. If I can get passed that then the rest should go quickly. Hal -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rating System Redux
On Monday, June 13, 2011 06:12:04 AM Gijs de Rooy wrote: Vivian wrote: Just how many systems are there – this must be a 4 as well? So that would become 3 + 3 + 4 + 4 = 14 = early production. Good enough for me J My 2nd point wasn't about the Jetman ;) But yeah, I do think the Cockpit might be a 4 rather than a 5 then. Will wait for some more opinions. I approach all of the catigories with the thought that I am rating how complete the model is in that catigory. For example for Systems if I rate it a 4 then it should have it's over all sustems about 75% complete. Then same for other other catigories. The descriptions on the wiki page are more like a guild to help with what types of things belong in each catigory and the info there is very helpful for normal aircraft. Things like the jetman are sort of corner cases but it wouldn't hurt to add info to the wiki about how these types of things shuold be rated. So your jetman is missing a few things from the cockpit but if there should be 5 things in the cockpit to make it complete and it has 4 (or 10 and 7) then it is it is a 4. Hal -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rating System Redux
On Monday, June 13, 2011 05:16:59 AM Gijs de Rooy wrote: Hi all, snip I think the alpha-range is rather big, compared to the others. There is an awfull lot of difference between a total=0 aircraft and a total=8 (eg. Model=3, FDM=3, Cockpit=0, Systems=2). I don't care if my vehicles end up low in the completness-rating (I consider my best aircraft early production) but I do feel offset to see my aircraft end up next to an empty hull. Adding in a 0-4 rating would be nice IMO; we can call that pre alpha. Just some Monday afternoon ideas :) Cheers, Gijs I am not sure that I am bothered by this since for the most part users will not be interested in alpha models. But you are right the alpha staus implies that the model is in a state where it could be tested by users and there are models in GIT that are not that far along. The other possibility is that we discourage including a status rating until such time that the model is user testable. This also makes it possible, with some work to the download page, to exclude models with no status from appearing on the download page. This way aircraft devs would be able to control when their model appears on the download page. Hal -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SCR-522 (was Rating SystemRedux(wasRe:Flightgear-devel Digest, Vol 61, Issue 12))
On Saturday, June 11, 2011 02:19:39 AM Vivian Meazza wrote: Hal, I put some comments in-line. Vivian -Original Message- From: Hal V. Engel [mailto:hven...@gmail.com] Sent: 11 June 2011 02:03 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] SCR-522 (was Rating SystemRedux(wasRe:Flightgear-devel Digest, Vol 61, Issue 12)) On Friday, June 10, 2011 08:16:52 AM Vivian Meazza wrote: Hal, snip On closer reading of p24 and on looking at the diagram on p9 of the manual, it seems possible that the dimmer mask only covered the Channel indicator lamps, and not the T/R/REM. light. What specifically on page 9 are you seeing? I am not sure I agree but I can't say for sure. All of the lamps are in line with each other so they could easily use the same types of masks and a common lever for dimming all five lamps. In addition, not dimming the T/R/REM lamp would not make operational sense since they would have been very concerned about night blindness and the lamp is white (see next paragraph) which is not a good thing from a night vision point of view. Also the 1952 USAF F-51D/K/H manual seems to imply that all of the lamps are dimmed by the lever although it does not say this explicity. On the other hand the Aug. 1945 USAAF P-51D/K manual seems to imply that the dimmer mask only affects the channel lights but again it is not explicit about this. So I don't know. Perhaps the Spit pilot manuals can shed some light on this? Also something that I had missed from the 1952 manual is that the T/R/REM lamp is white and the others are green. In most photos I have seen the lamps all appear to be a greenish blue color, this is clearly the case in the ebay auction photos, but perhaps this is because they are not lit in these photos. A yellowish lamp under a blueish lens would glow a green color when lit while still appearling blue when not lit. Also the photo at this link shows the channel lamps as a green blue and the T/R/REM lamp as white. http://www.worthpoint.com/worthopedia/radio-control-box-bc-602-part- scr-522-76082646 I will change the colors of the lamps to match the documentation. But this is another case where the evidence is contradictory. What colors should these be when lit and off? I will make my best guess and if some evidence comes along that my guess is incorrect it will get fixed. snip Please take anything you want. Did you notice that the binding for F12 was changed to bring up the new menu? I would really like to use the new dialog in the same way as the default one rather than in the aircraft-specific menu, but right now can't figure out how to do that. I has a new high level menu for the VHF radio stubbed in (IE. the menu does not do anything yet). So I have some thing working and when I have a chance to look at your stuff I will try to generalize it so that it has it's own high level menu. I think we might end up with 2 near-identical entries in Aircraft/Instruments-3d. I suppose that's OK, since UK aircraft would expect the TR1133, and the US the SCR-522. Hmm, what was it known as in RAF P51s? I think this may be the case and it might make sense to consolidate these into one set of models and code. The names used internally by the aircraft models does not really matter since to the user these are the same units. They look and function in exactly the same way. snip I now discover that the boxes were the same - only the internals differed. However, I haven't yet discovered where the boxes were fitted. I found this online: http://target4today.co.uk/forum/viewtopic.php?showtopic=643mode=show=20page=3 It shows where various things are located for weight and ballance on the Spit. The TR 1133 is item G and with the dynamotor and other radio items is part of item 18. These are located behind the VHF antenna at 109 inches behind the datum point which appears to be at about 25% cord. This is well behind the cockpit and these might not be visible to the pilot or when looking through the canopy from the outside. The above is from a thread on the target4today web site forum. A user named bomber is working on a JSBSim Spit FDM for the target4today software and there are two extensive threads about this in their forum. snip I think that one might be a modern reproduction - it's all very shiny and new. It could also be a refinished original or NOS. These were produced in huge numbers (perhaps several hundered thousand) and it appears that NOS or refinished examples regularly appear on ebay. snip Looks like the our channel select buttons could do with a bit more detailing - from this and other photos, it looks as if they had a raised rim. I was not able to see the rim in the photos I originally used although I did see that there is a recess in the top of the button which I thought was a dish shape and I created a shadow
Re: [Flightgear-devel] SCR-522 (was RatingSystemRedux(wasRe:Flightgear-devel Digest, Vol 61, Issue 12))
On Sunday, June 12, 2011 03:07:25 AM Vivian Meazza wrote: Hal, On page 9 I see what I think is the mask in place over the channel lights with the small hole over the channel visible - compare and contrast that with the photos that we have found with the in the day position. Page 9 also shows the T/R/REM. light unmasked. The words on page 24 also imply this to be the case. But see my comments lower down snip Not quite in line - but yes it would not have been difficult to have extended the mask to cover all lamps - and I agree that it would be logical for this to be the case. snip Too much info - does that photo show the dimmer mask in the down position? I think so, it looks as if I am wrong about the hole theory - the blue is transparent mask over - what? Perhaps a more transparent blue mask? The T/R lamp is not masked. But I'm not sure that we want to introduce a transparency in our model - bad for framerate. We can easily fix things to look right without transparency. I think the mask is between the lens and the light bulb and is not visible from the outside. If that is the case then changing it's possition would not change how these looked other than how bright they are when lit. I think you are right about not using transparency and that the needed affect can be done using object illumination animation settings in the models XML file. So it appears that the mask can be removed from the model which reduces the number of vertices significantly. The other related open question is which way does the level move to open or close the mask? snip That's all looking good. Can we get it into Git soon?\ Soon yes but at the moment I am swamped with other stuff. But I will try to get to it and finish it in the next few days. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SCR-522 (was Rating System Redux(wasRe:Flightgear-devel Digest, Vol 61, Issue 12))
On Friday, June 10, 2011 08:16:52 AM Vivian Meazza wrote: Hal, I've completed the T/R/REM lock, and the day/night mask - this might be different to your interpretation of a dimmer - AFAIKS its just a plate with big/small holes which is slid across the lamps. That required a bit of modification of the existing model here: ftp://abbeytheatre2.org.uk:2121/flightgear/SCR-522/TR1133-Control-Night.jpg I didn't find too much to go on with the day/night mask/dimmer in the docs I had before. From reading the section about this in the radio manual (page 24) it appears that this was probably not infinitely adjustable and that having a large hole and a small hole fits the description in the manual better although, as you wrote, this is a matter of interpretation since the manual is not explicit about this. All is now pushed into Git. I could add the dialog etc. to the P51D if you would like. The model is very close now. I have improved the textures as well (the box and cover plates now have a crinkle finish). I still need to add the fittings on the bottom but these are a fairly simple cubes, cylinders and spheres type of things (IE. very east to model) and I should have that done in the next day or two. I have adapted your top and light mask to the model so the new version should work for you as well without many changes to your code. This also reduces the number of vertices/edges so the model is a little smaller than it was. Also the cover plates were interchangeable according to the manual. One of these plates has the placards and the other has mounting holes and depending on the installation these covers were interchanged so that the one without placards could be attached to the mounting surface/bracket in the aircraft. It appears that your installation has it mounted with what is the mounting cover visible in the cockpit which is not correct. I have put the placards on both side covers so that it can be mounted either way with the placards still visible. This works fine in the P-51D and it should work in your Spit as well. Don't bother with implementing this in the P-51D since I can look at (and steal - is that OK?) your code. I had a look at your stuff and it did not appear to be a big deal to port this to the SCR-522 and the P-51D. I will try to generalize this so that it can be used by any aircraft since it could be useful to those working on other WWII aircraft like the P-47, P-38, P-39, P-40, Corsair, F6F, B-17 and perhaps a dozen others. I'm looking forward to the updated models - I think you did an outstanding job just working from photos. I don't know yet if the TR1133 had a single box containing the transmitter and receiver, or 2 boxes. In any case, I think the SCR-522 was also fitted to UK aircraft, at least later in WW2 - after all that was the purpose of the contract. The radios in US and Britsh aircraft were standardized very early in the war. There was lots of cooperation between the US and the UK particularly on electronics (communication radios and radar) and this started before the US was officially at war. Reading the history on these VHF radios it appears that the initial prototypes where Britsh and that these were improved and made into production items by companies in the US primarily Bendix. The BC-602-A control box appears to have been used for all 4 channel VHF radios through out the war (and into the Korean war at least in the P-51D's) and it was basically unchanged from what it looked like as a prototype. This is a nice photo of the cockpit control: http://spitfiresite.com/wp-content/uploads/2010/07/02es09_020.jpg There is at least one difference from the drawings in the manual. The raised part of the top that goes over the lights is stamped into the top cover. The drawings show this as a seperate piece that is rivited to the top cover. So there appears to have been some minor cosmetic changes to these during thier production life. Also here is an ebay auction for a BC-602-A that shows more detail as it shows three sides of the unit. http://cgi.ebay.com/WWII-Signal-Corps-BC-602-A-Radio-Box-w-Connector- P-51-/220792306832?pt=LH_DefaultDomain_0hash=item33683f3c90 The one in this auction has a serial number of 8840 so this can't be a late war unit since these had to have been produced in the tens if not hundreds of thousands (after all it would have taken over 10,000 of these just to equip P-51s and these were used in every plane the US and UK put in the air many of these produced in 10,000 quantities) so it looks like the rivets on the top cover were only on very early examples. Hal -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking.
Re: [Flightgear-devel] SCR-522 (was Rating System Redux (wasRe:Flightgear-devel Digest, Vol 61, Issue 12))
On Wednesday, June 08, 2011 01:22:20 AM Vivian Meazza wrote: Hal, Glad to be able to help. I'm looking forward to your corrected model, then I'll use it in part or in for the TR1133. As you probably know, the SCR-522 was the TR1133 built initially under a UK contract in the US. The TR1133 transmitter and receiver were reworked by Bendix into a single unit, but the cockpit control box remained unchanged throughout the life of the equipment AFAIKS. I now have a working Channel selector interfaced with comm[0] - trivial. Now for a menu to set the Channel frequencies Vivian I am working on the model for the control unit now. It turns out that my eyeball was slightly miscalibrated and the model was too small by perhaps 10% or so. The new version is somewhat bigger (about 1.3 CM longer for example). But the old version had about the correct proportions. It is now correctly sized and has the content of the placards as well. I am working on other details like rivets, connectors and screw heads. The dimmer control now dimms all of the lights including the TR light. I will also be adding the transmitter/reciever and the dynamotor boxes and perhaps some connectors so that these can be placed in models where these are visible like the P-51D. These may not be too useful for your version of the radio since I will be modeling the Bendix version with a single TR box. These also may not be visible in your aircraft. When I have the models in place and have updated the P-51D to use them (the bigger radio requires some changes to the P-51D configuration to get it properly placed in the cockpit) I will push these into my gitorious repository and request a merge. I have lots on my plate right now so this will probably be early next week. One interesting side note for those with an interest in electronics. The dynamotor has several different output voltages including 28 volts and 300 volts. From my radio backgound (AC6VZ) I know that the 300 volt output is probably for the power amp stage of the transmitter. I am not too sure how much power output this unit had but from what I have read air to air range was several hundred miles. Total power consumption when transmitting is about 320 watts and 308 watts in recieve so it appears that it's output is around 10 watts. This is comparible to modern aircraft VHF radios. Of course modern aircraft radios probably only consume 15 to 20 watts max when transmitting and perhaps only 1 watt when recieving since they are solid state and don't have all of the losses in the dynamotor. Hal -Original Message- From: Hal V. Engel [mailto:hven...@gmail.com] Sent: 07 June 2011 23:24 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] SCR-522 (was Rating System Redux (wasRe:Flightgear-devel Digest, Vol 61, Issue 12)) On Tuesday, June 07, 2011 12:49:34 AM Vivian Meazza wrote: I expect you have already seen this - ftp://abbeytheatre2.org.uk:2121/flightgear/SCR-522/SCR-522.pdf Right now I'm busy converting the SCR-522 into its progenitor, the TR1133. Not that it's hard - externally they are exactly the same bits of kit. I have found a number of duplicate vertices/bad surfaces however. Based on the Manual there are some small errors in the interpretion the function of the T/R/REM, and some of the dimensions. Key. I'll push the TR1133 into git soon, but as a new item: I will not overwrite any of the SCR-522 stuff. This is great info. I googled the SCR-522 when I was working on it's model and did not find much on line other than grainy old photos. Because of this I sized the unit by comparing it to photos of it in place in a P-51 cockpit. So I knew that it's dimensions were not totally correct and I was not sure about some other details. I mistakenly thought that the switch-locking lever was a dimmer for the T-R-REM indicator lamp. Also I did not know that I had the T-R indicator lamp function backwards (IE. off when receiving which is what it is on modern radios - when it should be on when recieving). So these things are wrong in my model. Also from the photos I had it was not apparant that the front and back of the control box had removable covers so the screws are missing as well as the covers not being propery contured. My model is also missing the connectors on the bottom of the control box. Then Vivian is able to find a complete manual for the radio which includes good line drawings for all of the radio components including dimensions. Having these drawings makes it possible to add other stuff (radio box, dynamotor, cables and connectors) behind the armor plat in the P-51D (above the fusealge fuel tank) and have things accurately modeled. So this is very useful to me as it will make the P-51D model more accurate and detailed. One orher issue is that there are two placards
Re: [Flightgear-devel] SCR-522 (was Rating System Redux (was Re:Flightgear-devel Digest, Vol 61, Issue 12))
On Tuesday, June 07, 2011 12:49:34 AM Vivian Meazza wrote: I expect you have already seen this - ftp://abbeytheatre2.org.uk:2121/flightgear/SCR-522/SCR-522.pdf Right now I'm busy converting the SCR-522 into its progenitor, the TR1133. Not that it's hard - externally they are exactly the same bits of kit. I have found a number of duplicate vertices/bad surfaces however. Based on the Manual there are some small errors in the interpretion the function of the T/R/REM, and some of the dimensions. Key. I'll push the TR1133 into git soon, but as a new item: I will not overwrite any of the SCR-522 stuff. This is great info. I googled the SCR-522 when I was working on it's model and did not find much on line other than grainy old photos. Because of this I sized the unit by comparing it to photos of it in place in a P-51 cockpit. So I knew that it's dimensions were not totally correct and I was not sure about some other details. I mistakenly thought that the switch-locking lever was a dimmer for the T-R- REM indicator lamp. Also I did not know that I had the T-R indicator lamp function backwards (IE. off when receiving which is what it is on modern radios - when it should be on when recieving). So these things are wrong in my model. Also from the photos I had it was not apparant that the front and back of the control box had removable covers so the screws are missing as well as the covers not being propery contured. My model is also missing the connectors on the bottom of the control box. Then Vivian is able to find a complete manual for the radio which includes good line drawings for all of the radio components including dimensions. Having these drawings makes it possible to add other stuff (radio box, dynamotor, cables and connectors) behind the armor plat in the P-51D (above the fusealge fuel tank) and have things accurately modeled. So this is very useful to me as it will make the P-51D model more accurate and detailed. One orher issue is that there are two placards on the side of the radio control box that in P-51 installations were visible. These are visible in Figure 17 of the radio manual (page 37) but are only shown edge on. I know that these are brass plates with red and black backgrounds but I didn't know what was on these placards and my current texture no content on the placards. There are no photos/drawings of these particular placards in the manual. I will do some googling to see if I can find more info about these placards. Hal -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rating System Redux
On Friday, June 03, 2011 11:45:26 AM Stuart Buchanan wrote: On Fri, Jun 3, 2011 at 6:56 PM, ThorstenB wrote: Hi Stuart and all, http://wiki.flightgear.org/Formalizing_Aircraft_Status We have some (too few!) aircraft providing documentation / tutorials, i.e. how to start, how to use instruments... I like extremely detailed/realistic aircraft, and I'm not asking everyone to provide cheating autostart options. But realistic FDMs/cockpits/... are still of little use when people don't know how to use them. So, wouldn't it be a good idea to make the level of documentation/tutorials part of the new rating system? Especially since that's certainly of interest to new users (new to FG, or just new to the aircraft). You may have seen that I've proposed putting it at least partly within the Systems rating, as really it is related to operating those systems. There are some things that should be covered in the in-sim help or a pilots handbook that are related to the FDM such as Vne, stall speeds, service ceiling and the like. So perhaps there is an FDM component to this as well but this is probably a nit and having it covered in the Systems catigory seems OK to me. Thus far, my proposal is that for a Systems:3 rating, there must be either in-sim instructions or a tutorial for the correctly modelled engine startup. I think that is reasonable, and will allow new users to at least start the engine, if not get into the air. We could extend that such that for each of the modelled systems for a given rating there must be either - in-sim help/checklist - in-sim tutorial - referenced documentation elsewhere (Manual, wiki, freely available PoH) Does that seem reasonable or too draconian? This strikes me as an OK approach. As the systems being modeled get more complex and/or numerous having everything covered by in-sim help/check lists is not feasible (IE. the help text becomes too big). But there is also a need for more documentation as more systems are added to the model. Having some basic aircraft help (perhaps startup, take off and landing check lists along with some other basic info) and referring users to a pilot's handbook that covers in detail how these systems work IRL should be enough to satisfy this requirement. For many aircraft getting the pilots handbook is not hard but it can take some research to find. I had considered adding the pilots handbook to my aircraft directory in a Docs subdirectory since it has been put in the public domain by US.gov (IE. no IP issues - something that will not be the case for all aircraft). But the best of the handbooks available is fairly large (around 54 meg) and I am a little hesitant to add it since adding the handbook almost doubles the download size of the aircraft. I didn't even think about this when rating my aircraft since I had assumed that most if not all aircraft with with a shot at something beyond a beta rating would either have extensive in-sim documentation or a pilots handbooks would be available. For me adding this requirement to the rating system would not affect how I scored my model but it may impact others. The problem with having it as a completely separate rating is that when calculating an overall status for the aircraft it dilutes the other ratings (in particular FDM) unless one starts weighting the different ratings. -Stuart -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rating System Redux (was Re:Flightgear-devel Digest, Vol 61, Issue 12)
On Tuesday, May 31, 2011 03:02:09 PM Vivian Meazza wrote: Hal, I can't follow your logic - because there are some aircraft that need a lot of work, the system shouldn't recognize advanced features in other aircraft that do have them? I should have been clearer - Sorry. What I was trying to say is that we shouldn't need special cases to include this type of stuff in the rating. I also disagree with Stuart that such advanced features are nice-to-haves and add little to the simulation - why the hell are we including them then? Do the stores so nicely added to the P-51 add nothing? These add a lot. I treated them as systems and included them in Systems rating. Seemed like the right way to handle this stuff to me. On the other hand, the ability to change liveries adds to the model? Sure doesn't wring my withers, but I suppose the airliner aficionados (and I'm not one) absolutely must have that. I agree with this (IE. that liveries only make sense for some models). Stuart changed the External Model category to make liveries optional to get a 4 or above. The P-51 is a superb model already, and at a reasonable frame rate here - about 75% of my benchmark figure. The yasim p51d gets about 35 FPS on my older system (it's probably a mid level system by todays standards) and the jsbsim version gets about 22 FPS under the same conditions. Considering how much more detail there is in the JSBSim cockpit I think it does OK frame rate wise. It would benefit from a tutorial on the start procedure - It does have a complete startup check list/procedure in the aircraft specific help that is basically copied from the pilots manual. The startup is fairly simple (comparable to a single engine GA aircraft) so most users should be able to get it running by reading the startup check list/procedure. but apparently that would win no points either. That seems to be a missed opportunity too. I agree that the quality of the aircraft specific help and the existence of tutorials needs to be factored into the rating system some how. I suppose the P-51 FDM is accurate - but I find it not all that pleasant to fly. There is a high pilot work load during take off and initial climb out and this makes things unpleasant during those part of a flight. Once up to or above normal climb speed and trimmed it becomes fairly easy to fly. It also can be a handful in high G maneuvers since it will snap if there is a yaw angle as you approach stall. You can appoach stall at fairly high speeds in high G maneuvers without blacking out. FG pilots will likely find this behavior surprising since the JSBSim P-51D is the only FG aircraft I know of that will do this. But after the pilot gets used to this behavior it gives the pilot a level of feedback near stall that is very useful. I would say that you have probably slightly underrated its score. I may have been overly critical with my ranking but I have a very long todo list and I am acutely aware of how much work remains to be done. I think this is a common situation among those who are trying to create very high quality models and I also believe that most individuals trying to create high quality models will tend to underrate their own models. I think this is a good thing since it sets a very high bar. In the final analysis - the system currently proposed is only marginally better than the current wet finger in the air method. I think we are falling a bit short here in our aim to be both objective, and to tell users more about the available aircraft. This I don't totally agree with. The system is far from perfect but at least we have a documented rating system that is somewhat objective and fairly easy to do. We can improve on it going forward to make it more complete and what we have now is a good starting place and is clearly better than the wet finger in the air method. In particular, the failure to tell users that they need a powerful system to use a model, and something about the difficulty of use, is going to disappoint and or frustrate users. I think these are separate issues from rating model maturity. Hal -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rating System Redux (was Re:Flightgear-devel Digest, Vol 61, Issue 12)
On Tuesday, May 31, 2011 10:26:18 PM Robert wrote: I absolutely agree with Vivian. The users should know about planes that need much resources (CPU, RAM, VRAM). This value should not influence the total score. I think how much compute power is needed and how difficult a model is to use/fly are seperate subjects from the status/maturatity of the model. In general models that are more mature will tend to require more compute resources and also will be more difficult to use/fly for aircraft of similar complexity IRL. Ease of use of the models should reflect how difficult the aircraft is to fly IRL at least for mature models. New users, particularly younger ones, sometimes think that FG is a game rather than a simulation and assume that how it presents aircraft should be arcade game like. I have seen a number of forum threads that started off with something along the lines of I just started using FG today and I tried to fly complex high performance aircraft and I always crash during take off Invariably the next post will point out that complex high performance aircraft requires a lot of skill and experience to fly and will ask the user if he has tried the C172P or some other basic aircraft. The OP will reply no but I will. Then they report that they were succesful with the more basic aircraft and are happy with FG. IRL you don't climb into the pilots seat of a complex high performance aircraft for your first flight ever and expect to walk away in one piece. Why would this be different for FG and why would FG users expect it to be different? Having a difficulty rating someplace visible to users is a good idea since it might clue in at least some new users that they probably need to start out with something easy to fly usless they fly complex aircraft IRL. So I agree ratings for difficulty of use and how much compute power is needed should be seperate from the status since these have nothing to do with model maturity. Maybe using the total score is not a good idea at all, because some users prefer the eye candy and don't worry about frame rate too much, others prefer an accurate FDM and a high framerate. So the total score doesn't tell the whole story! The overall status is for backward compatibility. It is displayed in fgrun and on the download page already. Also the most mature models will have eye candy, complex system modeling and a high quality FDM. So I think it does tell most of the story and users can infer how much compute power is needed for a given level of real life aricraft complexity from the status rating. A very simple aircraft (IE. Piper Cub or sail plane) of any status probably will run fine on a low to mid level system. But a highly complex aircraft that has a mature model (production or above) will probably require a high end machine to get good frame rates. It's not really rocket science as it just requires some common sense to figure out. But I don't see any reason not to also include information about required compute power for each model. But the idea of showing the user individual scores (FDM, Systems, Cockpit, 3d model, + needed resources) is a good one! What do you think? At this point users have to look in the XML files to see the FDM, Systems, Cockpit and External model scores. These are not visible in any UI or on the download page. So at this point only users who understand how things are setup in FG will be able to find this information and more work will be needed to make it available to nave users. Another issue is for the needed resources and difficulty rating to make sense there needs to be documentation on how to create the ratings and a description some place for user so that they can understand what these mean. Hal -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2d panel visibility
On Tuesday, May 31, 2011 11:00:58 AM Curtis Olson wrote: I could be imagining this, but I seem to recall a while back, someone asking if it was possible to keep a 2d panel visible all the time, even in external views. I just took a quick peek at .../Cockpit/panel.cxx and it doesn't appear that we have the ability to do this, but I just thought I'd ask in case there is some other mechanism someone has added? I am working on a project where we are modeling a skydiver in free fall, and we want to display some basic information on the edge of the screen (like decent rate). But because this is not an aircraft, it makes more sense to use external views. Also we are trying hard to avoid needing to modify source code, and we'd like to do this in v2.0 (the most current release). The HUD would be another alternative, but we'd like to avoid needing to extend the HUD code to add our specific widgets. Perhaps we could use gui widgets and display the information numerically, but an instrument communicates the data so much better. Are there any other options or ideas that I'm missing? Thanks, Curt. Have you thought about modeling the skydiver as an aircraft with the cockpit being the view out of his/her goggles? The panel would be nothing and the instruments could be just positioned about a meter in front of the pilots point of view. You could then keep the instruments in view as the pilot changed his view direction (IE. look up, down, left, right) by rotating them about the pilots head. You should be able to do all of this using the existing XML. Or you could create a 3D model for the skydivers body and possition the instruments on his/her body (IE on the top of the belly mounted chute pack) so that you need to look down to see them. Hal -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rating System Redux (was Re: Flightgear-devel Digest, Vol 61, Issue 12)
On Monday, May 30, 2011 12:47:41 PM Stuart Buchanan wrote: I don't have a good answer for the other items. Some are nice-to-haves that enrich the simulation experience but don't impact simulation of flight itself, but others (such as a co-pilot) are more important for multi-crew aircraft. Call them all advanced features. That could be a/the criterion for advanced production I'm not sure. The Advanced production bar is already very high - two 5s and two 4s. I'm not sure if any aircraft will actually gain it! I would expect that at this point only a few aircraft out there are close to or are advanced production quality. It is a very high standard and any aircraft that is that far along should really stand out. I would expect that most of the most advanced current models only need perhaps 1 or 2 points to get there but adding points when the models are that far along is a lot of work. But I would be surprised if there were more than a handful of aircraft that were far enough along to only need 1 or 2 points to become advanced production. I think I agree with Stuart that having some things called advanced features does not add much if anything to the system particularly when we have so many models that are missing many basic things. An example of one that is close but needs more work is the p51d-jsbsim model. It only needs to improve the external model (add livery support to go from a 3 to a 4) to get to production status and then add one more point in cockpit, external model or systems would make it advanced production. Currently it has the following ratings: rating FDM type=int5/FDM systems type=int4/systems model type=int3/model cockpit type=int4/cockpit /rating The 3D modeling stuff is not my strong suit but I do have new more accurate 3D models for the fuselage and wing (including flaps and aileraons) for the P-51D that I created a while back. I have also more accurately modeled the cooling inlet passages and the oil and coolant radiators so that these will look correct (once textured) when looking into the cooling inlet. I need to uvmap all of this stuff now and this is where I get stuck as I can't figure out how to do this so that the resulting uvmaps can be used to create livery support. Having a nice user friendly uvmap for the fugelage and wings is more or less nessary to move ahead with libery support I think. For Systems adding emergency gear release support, oxygen system support, full cooling system support, VHF radio support, rear warning radar support, IFF support and some missing electrical system stuff would increase this to a 5. The 3D models for the controls for all of these systems are already in the cockpit. One comment about systems. For the P-51 series there are two cooling doors that are used to control cooling airflow. One for the engine coolant and one for the oil cooler. JSBSim has support for the coolant door controls but not for the oil cooler door controls. I have the automatic coolant door stuff modeled but not the automatic oil cooler stuff because of this. I also need to add manual overides for these at some point (the controls are in the cockpit but currently only allow for automatic control). What I am getting at is that some systems can not be fully modeled because of limitations in the FDM being used and aircraft authors should rate these as complete systems if they have modeled everything that is possible with the existing FDM support. For Cockpit adding the fuselage fuel tank and guage, a few missing placards, the arm rest, the map bag and improved texturing would pretty much get it a 5. For some aircraft it may never be possible to get the FDM rating high enough to get more than a 2 or 3 simply because the data needed to do that is not available. These aircraft will never be able to get beyond an early production status unless the author finds a source for the needed information. Hal -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rating System Redux (was Re: Flightgear-devel Digest, Vol 61, Issue 12)
On Thursday, May 26, 2011 06:31:13 AM Stuart Buchanan wrote: On Thu, May 26, 2011 at 9:45 AM, Vivian Meazz awrote: Thanks for addressing the points that were hammered out over on the IRC channel. I think the modified system could work. Just a few points remain: There is no penalty for including systems, such as an AP, where none existed on the original. There's not an explicit penalty. but I think Hal has addressed this in the notes for the System criteria: Ignore systems not present on the aircraft IRL. If the real aircraft doesn't have a system (e.g. autopilot), the FG model shouldn't have either and if all systems in the real aircraft are modeled then it scores a 5 even if it is a very simple aircraft. I'm not sure how much of a problem this is. If someone chooses not to disable the generic autopilot for a vintage aircraft, it will have no effect on pilots who choose to fly realistically (they simply won't use it). On the p51d-jsbsim I have added a tuned autopilot but it is only available by using the menu system since the real thing (IE. my model is as it would have been in 1945) would not have one. But it is VERY useful for test flights so it was worth the effort to create it. I don't think this should result in a reduced Systems score unless it is exposed in the cockpit. So I agree with Stuart. If the system is exposed in the cockpit, then it is covered by the rating for accuracy of cockpit - a KAP140 in the Sopwith Camel would obviously not be worth a 4 or 5 cockpit rating. I don't think it's unreasonable for vintage aircraft to have access to a radio, for example. A modern pilot flying a vintage aircraft would carry a hand-held. I agree with this and as others have pointed out it depends on what you are modeling - IE. how the aircraft was back in the day or how it might be used today. These are really two different aircraft or at least two differenet configurations. The use of shaders etc. may or may not enhance the realism of the model and in some cases could be used inappropriately. This is a subjective assessment, and perhaps could be removed from the points system. Livery support is not necessarily an enhancement - it is not appropriate for all models. We're talking here about the difference between a 4 or 5 External Model rating, where we're trying to differentiate between a good external model and one that is as realistic as possible. I think we should differentiate between them if possible, but I'm struggling to think up some objective criteria. Photo-realistic? model resolution of 5cm? Setting up for liveries appears to be a significant non-trivial task although I have not looked into it in detail. If the model is intended to be of a specific aircraft as it existed at a particualr point in time then liveries make no sense for that model. On the other hand a particular aircraft may have a long history and using liveries would make it possible to model the same aircraft at different points in it's history. Perhaps we end up providing subjective criteria, or some additional guidance in this case? I'm not clear if you are awarding points for underwing stores and the like. Hadn't thought about that at all. I've added it to the criteria for a 4 rating. I would treat these as just another system. I think the systems catigory is a difficult one because of how much difference there is between very simple aircraft (think sailplane) and a very complex one (think Concorde). This makes it very difficult to have a rating system that results in similar scores for aircraft that have proportionally complete systems but that are of very different complexity. I am not sure how to improve this but I think it is important to keep it simple. We have additional features such as co-pilot/RIO over MP, Wingmen, Formation Control, Tutorials, Aircraft Specific Help, Contrails, Vapour Trails, and there are probably some I missed. Contrails Vapour trails should probably be covered by the external model, I think. I could add them (along with tyre smoke) as criteria for a Model 5 rating? I don't have a good answer for the other items. Some are nice-to-haves that enrich the simulation experience but don't impact simulation of flight itself, but others (such as a co-pilot) are more important for multi-crew aircraft. And finally - the points system could award a high status to a poor model - there are no points awarded for the accuracy or the fidelity of the 3d model. E.G there is at least one model with afterburners modelled where none existed. I've updated the external model to include the world Accurate for ratings 3-5. Of course, we're trusting that aircraft developers are going to apply the rating criteria accurately to the best of their ability. Oh and, finally finally - the model with the highest score might be so good that the framerate means that it
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 12
On Wednesday, May 25, 2011 01:28:39 PM Stuart Buchanan wrote: On Wed, May 25, 2011 at 9:19 AM, I wrote: On Tue, May 24, 2011 at 6:37 PM, Hal V. Engel wrote: I used it for the P-51D and found the system to be easy to use and it took all of perhaps 10 to 15 minutes to create ratings for the four areas that get scored and then create the entries in the *set.xml file. The system is easy to use and for less advanced models should only take perhaps 5 minutes to do. More advanced models take a little more effort but the system is clearly not burdensomeness for aircraft authors to implement. The real issue is to get a consensus with in the aircraft author community to use a standardized rating system like this and I don't think this has happened yet. Once there is wide spread agreement on something like this it should fall into place fairly quickly. One thing that might be stalling this is that there is currently no published description of the proposed system (I will call it Stuart's system) available other than searching this email list and a few things on the forum. At one point Stuart said he would create a document that covers his system but this has not happened yet and the only way to find it is to search the archives and even then the information is spread over a number of emails. Making things even more confusing there is a wiki page on this subject http://wiki.flightgear.org/index.php/Formalizing_Aircraft_Status which does not cover Stuart's system but rahter a totally differnt system. In fact the system proposed on the wiki is more complex and has no details on how the ratings would be made unlike Stuart's system. The details on how to rate various things is one of the key aspects of Stuart's system along with it's relative simplicity. Perhaps we can get the wiki page so that it reflects Stuart's system? Thanks for the poke. I completely forgot to write this up. I'll try to do this today, though it needs a proper name. This is done. I've gone ahead and replaced the article completely with the rating system described in December. Now I'm off to rate all the aircraft I maintain! -Stuart Thank you. This is a good starting place and more detail can be added if there is any confusion on how to use the system. I think it should be extremely difficult to get a 5 in any catigory and in any area where we have examples of models that have gone well beyond what is needed to score a 5 I think we need to set the bar higher. I would like to suggest that the FDM catigory be changed slightly to reflect what we now know can be achived with our FDMs. Flight Dynamics Model 0: None, or using FDM from other aircraft 1: JSBSim Aeromatic or YASim geometric model used without tuning. Flaps modeled. 2: FDM tuned for cruise and climb configurations 3: FDM matches PoH in 90% of configurations 4: FDM very closely matches PoH and most known test data. This includes fuel consumption, glide performance, stall speeds, time to altitude and other performance charaterisics 5: FDM models out of normal flight envelope characterisics IE. stalls, spins and compressibility/transonic effects (if the aircraft can reach transonic speeds). Hal -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 12
On Monday, May 23, 2011 04:18:46 PM Pierre Mueller wrote: Although this should give you a list of aircraft that have been tagged as production quality it may miss some aircraft that are actually of very high quality and some of the listed aircraft may not be truly production quality. In fact looking at the list of production aircraft from my installation I would say that some of these are not true production quality. In addition the --min-status=production parm does not appear to work on my new GIT install as it lists all of the installed aircraft (over 300 of them). FGRUN also shows the aircraft status on the Select an Aircraft screen. Thanks, I didn't see the little box under the list yet. But it is a bit hard to browse through this big list to find the more attractive aircraft Getting the list by the good ol DOS-box was a bit easier- still a big list as you said... Another way to locate more developed aircraft is to check to see how much space the aircraft uses on the file system. In general the bigger the aircrafts directory the more developed it is. For example, the p51d (81.1 meg - use the jsbsim version), MiG-15 (70.3 meg) and IAR80 (53.8 meg) all have very big aircraft directories and are highly developed although I don't think that any of the authors consider them to be complete yet.Using --min-status=production should include the IAR80 in it's list but not the p51d-jsbsim (which has a status of early production) or the MiG-15 (which has no status information). Thanks for the hint There have been long threads here and on the forums about the issue of helping users locate the higher quality models. So this is a long standing and significant issue. There was a rating system that was proposed here that would have made it simple for aircraft authors to produce a consistent and verifiable status for their aircraft. The system set a very high bar for the higher status ratings. Status ratings in this system could be alpha, beta, early production, production and advanced production. Using this system the p51d-jsbsim model gets an early production status as did the c172p.Taking the p51d-jsbsim up for a spin (pun intended) will give you an idea how well developed a model under this system needs to be to get a production or advanced production rating. Unfortunately it appears that only a few of the models are actually using this system. Hal So whats so difficult to use this rating system? Regards P.M. I used it for the P-51D and found the system to be easy to use and it took all of perhaps 10 to 15 minutes to create ratings for the four areas that get scored and then create the entries in the *set.xml file. The system is easy to use and for less advanced models should only take perhaps 5 minutes to do. More advanced models take a little more effort but the system is clearly not burdensomeness for aircraft authors to implement. The real issue is to get a consensus with in the aircraft author community to use a standardized rating system like this and I don't think this has happened yet. Once there is wide spread agreement on something like this it should fall into place fairly quickly. One thing that might be stalling this is that there is currently no published description of the proposed system (I will call it Stuart's system) available other than searching this email list and a few things on the forum. At one point Stuart said he would create a document that covers his system but this has not happened yet and the only way to find it is to search the archives and even then the information is spread over a number of emails. Making things even more confusing there is a wiki page on this subject http://wiki.flightgear.org/index.php/Formalizing_Aircraft_Status which does not cover Stuart's system but rahter a totally differnt system. In fact the system proposed on the wiki is more complex and has no details on how the ratings would be made unlike Stuart's system. The details on how to rate various things is one of the key aspects of Stuart's system along with it's relative simplicity. Perhaps we can get the wiki page so that it reflects Stuart's system? Hal -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 12
On Saturday, May 21, 2011 11:11:50 AM Arnt Karlsen wrote:
On Sat, 21 May 2011 17:04:33 +0100 (BST), Pierre wrote in message
379675.56250...@web29801.mail.ird.yahoo.com:
Hello,
...looks like you fell into that same trap yourself. ;o)
I'm not a English native speaker, but luckily I'm able to communicate
without Google translate.
But yes, I had trouble to understand what Mr. Baranger is really
meaning.
I was actually refering to the sentence that he added another
aircraft and started to make two others and want to give much
pleasure(?). He seems to be quick adding aircraft- are they are
really all developed further and being usuable later?
In the whole context it sounded to me that a realistic aircraft, as
discussed here, wanted by those 1-2 person aren't a pleasure.
Maybe a misunderstood.
..the whole conflict is a product of misunderstandings.
Best cure is write in your own language if you need
translation programs to read or write in the English
language more than once a week.
..the important ones to review, are those meant for inclusion into
the release candidates, e.g. 2.0, 2.2, 2.4 etc, pull them with e.g.
git checkout -b releases/2.2.0 origin/releases/2.2.0 for both SG
and FG, and you'll find far fewer and far better aircraft. ;o)
http://wiki.flightgear.org/Building_Flightgear_-_Debian
http://wiki.flightgear.org/Scripted_Compilation_on_Linux_Debian/Ubuntu
http://wiki.flightgear.org/Building_FlightGear
Thanks, I will take a look!
...yup, is why and how this is a development project. ;o)
Welcome aboard.
I read in the forum that the GIT-version(?) is actually the
developement version of FGFS and includes all aircraft in
developement.
..there is a non-development version of FG? ;o)
Everything is here so anyone can see _how_ the
buggy ones fail, and try fix them.
So if there is a release they will be add to the
Download page, am I right?
..if somebody puts it there, yes. ;o)
I expected a far smaller number of
aircraft in developement and of course I didn't expect that all
aircraft will be usuable as they are in developement. But not that
high number! That are about 200-300 aircraft altogether I guess,
which will hardly be usuable.
..define useable, newbie, then consider
the developer bait context. ;o)
As a newbie it looks like for me quantity stands over qualitity...
*blush*
How many new aircraft are added each year? How can I see which
aircraft has been developed more than other, which aircraft are more
realistic?
..try fgfs --show-aircraft --min-status=production
..--min-status={alpha,beta,early-production,production}
Allows you to define a minimum status level
(=development status) for all listed aircraft
Although this should give you a list of aircraft that have been tagged as
production quality it may miss some aircraft that are actually of very high
quality and some of the listed aircraft may not be truly production quality.
In fact looking at the list of production aircraft from my installation I
would say that some of these are not true production quality. In addition the
--min-status=production parm does not appear to work on my new GIT install as
it lists all of the installed aircraft (over 300 of them).
FGRUN also shows the aircraft status on the Select an Aircraft screen.
Another way to locate more developed aircraft is to check to see how much
space the aircraft uses on the file system. In general the bigger the
aircrafts directory the more developed it is. For example, the p51d (81.1 meg
- use the jsbsim version), MiG-15 (70.3 meg) and IAR80 (53.8 meg) all have
very big aircraft directories and are highly developed although I don't think
that any of the authors consider them to be complete yet.Using --min-
status=production should include the IAR80 in it's list but not the p51d-
jsbsim (which has a status of early production) or the MiG-15 (which has no
status information).
There have been long threads here and on the forums about the issue of helping
users locate the higher quality models. So this is a long standing and
significant issue. There was a rating system that was proposed here that would
have made it simple for aircraft authors to produce a consistent and verifiable
status for their aircraft. The system set a very high bar for the higher
status ratings. Status ratings in this system could be alpha, beta, early
production, production and advanced production. Using this system the p51d-
jsbsim model gets an early production status as did the c172p.Taking the
p51d-jsbsim up for a spin (pun intended) will give you an idea how well
developed a model under this system needs to be to get a production or
advanced production rating. Unfortunately it appears that only a few of the
models are actually using this system.
Hal
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 12
On Saturday, May 21, 2011 04:24:38 PM Arnt Karlsen wrote:
On Sat, 21 May 2011 14:31:17 -0700, Hal wrote in message
201105211431.19074.hven...@gmail.com:
On Saturday, May 21, 2011 11:11:50 AM Arnt Karlsen wrote:
..try fgfs --show-aircraft --min-status=production
..--min-status={alpha,beta,early-production,production}
Allows you to define a minimum status level
(=development status) for all listed aircraft
Although this should give you a list of aircraft that have been
tagged as production quality it may miss some aircraft that are
actually of very high quality and some of the listed aircraft may not
be truly production quality. In fact looking at the list of
production aircraft from my installation I would say that some of
these are not true production quality. In addition the
--min-status=production parm does not appear to work on my new GIT
install as it lists all of the installed aircraft (over 300 of them).
..browsing the list archive, I see mention of argument order
mattering, i.e. fgfs --show-aircraft --min-status=production
being different to fgfs --min-status=production --show-aircraft,
has this changed?
I used
fgfs --show-aircraft --min-status=production
which did not work. So as a test I tried
fgfs --min-status=production --show-aircraft
and that worked and it produced a list of 15 production aircraft. This did
not include the IAR80 perhaps because it sets statusproduction/status in
IAR80-base.xml rather than in IAR80-set.xml?
FGRUN also shows the aircraft status on the Select an Aircraft
screen.
Another way to locate more developed aircraft is to check to see how
much space the aircraft uses on the file system. In general the
bigger the aircrafts directory the more developed it is. For
example, the p51d (81.1 meg
- use the jsbsim version), MiG-15 (70.3 meg) and IAR80 (53.8 meg) all
have very big aircraft directories and are highly developed although
I don't think that any of the authors consider them to be complete
yet.Using --min- status=production should include the IAR80 in
it's list but not the p51d- jsbsim (which has a status of early
production) or the MiG-15 (which has no status information).
There have been long threads here and on the forums about the issue
of helping users locate the higher quality models. So this is a long
standing and significant issue. There was a rating system that was
proposed here that would have made it simple for aircraft authors to
produce a consistent and verifiable status for their aircraft. The
system set a very high bar for the higher status ratings. Status
ratings in this system could be alpha, beta, early production,
production and advanced production. Using this system the p51d-
jsbsim model gets an early production status as did the c172p.
Taking the p51d-jsbsim up for a spin (pun intended) will give you an
idea how well developed a model under this system needs to be to get
a production or advanced production rating. Unfortunately it appears
that only a few of the models are actually using this system.
Hal
..it's also a matter of opinion, some developers are _very_
critical of and demanding on their own work, which is good
for FG release quality but bad for those lofty plans of
release schedules, is why I advocate having the release
dictator play with git until (s)he finds git commit
combinations (s)he likes, and release those on the spot.
I think a better plan is to have a defined release schedule that includes
things like feature freeze dates and use of branches for the releases. Not
too hard to do once things are setup and it injects some disipline into the
process. But it does take some effort to get this type of thing going as well
as someone willing to be a strong release manager.
But the issue here is not really a release management issue but more of a
documentation issue. Besides those aircraft authors/developers who are very
critical of thier own work are not the ones who have held up the release
schedule nor are they the ones who are causing the issue with poor
quality/incomplete aircraft models.
Hal
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Different cockpit layouts for one aircraft- the best way?
On Monday, May 09, 2011 06:53:33 AM Heiko Schulz wrote: Hi, Some aircraft types has different cockpit layouts like having different avionics, autopilot system or glascockpit vs. steam cockpit. Mostly the operator can select what he prefers. Another possible use case is a model of a specific aircraft that has been around a long time in order to make the cockpit correct for various time periods. For example the P-51D is a surviver aircraft now named GunFighter. This aircraft has had various paint schemes over the years but I suspect that the avionics installed and verious other systems have also changed over the years. In fact I know this is the case since I have seen photos of the current cockpit and it is significnatly different from what is was like when it left the factory in 1945 as a typical P-51D-25-NA and I am fairly sure that there are other variations over the years for this aircraft. This applies to the Ec135 helicopter I still work on (an aircraft is never be finished) in real life as well. The operator can choose between the full glascockpit and the one with conventional analog instruments. As I can see this isn't covered yet on FGFS. The PA24-250 uses two -set.xmls to have two different version regarding the autopilot. So it is the only aircraft which allows to have two different panel layouts. For the Ec135 helicopter I would like to create the two available different cockpit layouts. I found out that condition-bindings (condition.../condition) even work for modelpath.../path/model. That would allow me to have just the high- and lowskid version by two set-files linking to the two different fdm to simulate high and lowskids, and let change the cockpit version by tags set up in each livery.xml. Or by an entry in the menu, per key-command etc. I tried it today, loading time for the whole panel together with all instruments is under one second for me which surprised me in a positive way. As FGFS luckily offers many ways to get to a certain point, I wonder if there is maybe a better way or there are some things I did not yet considered. Any thoughts and recommendations out there? Kind regards Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html --- --- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing behavior of a JSBSim piston engine
On Sunday, April 24, 2011 05:41:43 PM Ron Jensen wrote: On Sunday 24 April 2011 15:00:41 Pavel Cueto wrote: Hello to all I'm developing with a friend the PZL M18B Dromader in JSBSim, doing this first with aeromatic generated data; and now, we are mixing them with real aircraft data from very reliable sources. However, the engine behavior seems very different in numbers compared with what we expect from it: Engine: ASz-62IRM18 Max.RPM: 2200 / Min.RPM: 550 Constant speed propeller snip Volumetric efficiency VE controls how much air goes through the engine at a given RPM. You can use it to fine tune fuel flow at a given manifold pressure/rpm setting. Its partner, BSFC, is the amount of power the engine produces per unit of fuel consumed. Use it to tune the power produced. Both are on the property tree under /fdm/jsbsim/propulsion/engine/ so you can control them at run-time. For an example of how to do this at run time have a look at the Systems/Propulsion.xml file for the p51d. The supercharger model used by JSBSim assumes a turbo charger so the power and fuel consuption curves are incorrect for an engine driven supercharger where more horse power (and fuel) are used to drive the supercharger. Using functions to set VE and BSFC at runtime gives you a way to get fuel consumption and power curves close to correct but it does take a lot of effort to get these functions tuned. snip How can i to adjust the cooling factor to avoid engine overheating? The latest code has two properties that can be set in the xml file. Cooling factor can also be controlled at runtime via property tree under /fdm/jsbsim/propulsion/engine/cooling-factor. cylinder-head-mass controls how fast the engine heats up and cools off. So if you have a '5-minute' limit on a power setting you can adjust this value so the engine just starts to overheat at the end of the given time frame. cooling-factor controls how much 'air' flows over the engine to cool it. Raising the value makes the engine run cooler. This can be used to simulate cowl flaps, for example. For an example of how this might be used the p51d uses this in an autopilot (PID controller) to simulate the automatic cooling system doors of the P-51D. For manual cowl flaps this should be fairly easy to setup since you would only need to do some tuning to figure out the cooling-factor for the closed and open cowl flaps and then write a simple function to vary the cooling-factor with the clowl flap control position. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing behavior of a JSBSim piston engine
On Wednesday, April 27, 2011 09:10:28 AM Ron Jensen wrote: On Monday 25 April 2011 12:10:26 Hal V. Engel wrote: snip The supercharger model used by JSBSim assumes a turbo charger so the power and fuel consuption curves are incorrect for an engine driven supercharger where more horse power (and fuel) are used to drive the supercharger. The supercharger in JSBSim is not very good, but it is engine driven in that the pressure directly varies with engine RPM unlike a turbocharger which varies with mass flow rate and exhaust temperature. The model just does not consume any power. At some point I would like to add a supercharger and turbocharger ability or add functionality to simulate an arbitrary boost device... I knew the model was not correct for an engine driven supercharger (IE. no power consumed) so I assumed that it modeled a turbocharger. And as is often the case with assumptions I was wrong. The key is that the model does not consume any power. For an engine driven supercharger power consumed is substantial and goes up with altitude (assumes the same manifold pressure) and some superchargers change drive gear ratios and higher gear ratios consume more power. For example the Parckard V-1650-7 (the engine in the P-51D) uses almost 200 more HP to drive the supercharger in high gear than in low gear at full take off MP. And this makes it important to use VE and BSFC runtime functions to correctly model the HP consumed by the supercharger otherwise the power and fuel consumption curves will not be correct. The problem is particularly accute in aircraft with a very wide performance envelope like the P-51 and it may be a minor issue for a crop duster. Using functions to set VE and BSFC at runtime gives you a way to get fuel consumption and power curves close to correct but it does take a lot of effort to get these functions tuned. snip snip this should be fairly easy to setup since you would only need to do some tuning to figure out the cooling-factor for the closed and open cowl flaps and then write a simple function to vary the cooling-factor with the clowl flap control position. Learning to use JSBSim stand-alone greatly simplifies this kind of tuning. It allows you to make multiple, identical runs while varying only a single variable at a time. Ron I have not tried using JSBSim stand alone yet. It would definitely make testing things that require repeated testing for tuning purposes faster since it would eliminate things like start up, take off and climb out overhead which can be very time consuming when testing from with in FG. On the other hand this will not allow testing for anything that has a Nasal component. I try to limit the use of Nasal but there are some things where is is nessary. Also in this case (IE. tuning cooling-factor) it should be possible to do this in a single FG test flight since you can vary the cooling-factor manually to test which values result in climb outs that do not over heat (too much) and cruise/decents that do not over cool the engine. For the cooling-factors settings used in the P-51D it took me perhaps an hour of testing in FG to settle on the range of values to use. Hal -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] P-40B WAS: Using native OSG 3D models - is it possible?
On Sunday, March 20, 2011 12:07:35 AM Michael Sgier wrote: Oh good. I've sent that below to the author. Should be pretty simple but as I'm new to fgfs i'd appreciate any help with this project.--- Hello I've heard your plane could be integrated into Flightgear under the GPL licence? If yes, I'll have a look at it and send you a huge thank you from the FGFS community. Without licence restrictions I might even do a x-plane version, but I suppose that's not what you would want, right? I've done a PC-12 so I'm familiar with Blender/X-Plane but however FGFS is new to me. http://x-plane.sgier.com/309.jpg Let me know if that's ok for you? Kind regards Michael Sgier He already has the following on his web site for the P-40B. You may use this model as the base for your airplane in any flight simulator (Flight Gear, x-plane, etc.). I just require that your model should be free (non-commercial), and in a comment you should mention, that it was based on my work. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Using native OSG 3D models - is it possible?
On Saturday, March 19, 2011 12:01:19 AM Michael Sgier wrote:
Yes, i wanna know as well, because x-plane also uses armatures. In Blender
for X-plane i only enter a dataref name like battery_on etc. This would
make aircraft conversions much easier and fast.
A nice book...i guess I'd need to wait for the english version...
On the forum thread one post says that using an on-line transalation engine
works OK. All of the screen shots are of Blender with an English UI.
but as i
already finished a PC-12 for X-Plane, I probably move on :-)Hal are all
downloadable *.blend files free to use or have any copyright?
If you go to the web site it should have a statement about all of the models
being free to use in FG and it's projects. The author of the models (and
ebook) was told when asking for permission to use these that FG needed these
to be GPL compatible so he is aware that these will end up under GPL if they
are used in FG.
I also
remarked that Gimp has troubles with text as *.png. Therefore I mostly use
PS 7 on Wine. BTW is someone working on integrating the current x-plane
apt format?
--- On Fri, 3/18/11, Hal V. Engel hven...@gmail.com wrote:
From: Hal V. Engel hven...@gmail.com
Subject: Re: [Flightgear-devel] Using native OSG 3D models - is it
possible? To: flightgear-devel@lists.sourceforge.net
Date: Friday, March 18, 2011, 8:39 PM
#yiv1446985333 p, #yiv1446985333 li {white-space:pre-wrap;}
On Friday, March 18, 2011 07:08:14 AM S Andreason wrote:
Hi Hal,
Oh yes, it is possible. But not easy.
Hal V. Engel wrote:
I have been able to get a AC3D export but of course all of the
armature stuff is gone and all I have at that point is a static model
that can not be animated.
The export process from Blender may not be the problem. _If_ each limb
is correctly defined separately, and a child of the parent limb, then
the hard part is generating the _xml_ file that defines the center of
rotation of each limb's connection, and how it rotates. Each limb needs
between 1 and 3 axis properties.
Take a look at the animated walker in the Bluebird aircraft.
Stewart
http://seahorseCorral.org/flightgear_aircraft
Sorry I should have been clearer. I didn't mean to imply that the AC3D
export was not working. Rather only that all it created from this
armature based model is a static model that had very limited posibilities
for animation. You are correct that if ..each limb is correctly defined
separately, and a child of the parent limb.. for non-armature animation
that the export would likely work OK.
The model I am looking at only has one mesh for the body including arms,
hands, fingers, figer tips, thumb, legs and feet. This mesh is drapped
over a set of armatures (bones) and it is designed to be animated by
moving the bones with that mesh following them (IE. no visiable seams).
AC3D has no support for armatures as far as I can tell so this imformation
is lost on export and I end up with a mesh that is the shape that the
model was posed in when it was exported.
Inside of Blender I can pull, push and/or rotate the bones to pose the
model in extreamly precise ways even down to changing the grip of the
hands to fit around controls. The exported AC3D model can be made to fit
very nicely into the cockpit but the only thing that can be animated is
the head because it is a seperate mesh from the rest of the model.
Inside of Blender the posing process is actually very elegant as all of
the bones know how they are connected and everything moves together as it
should when one part of moved. That is if you rotate the forarm the hands
and fingers follow along with no need to move them seperately. I am not
sure (I am new to this 3D stuff) but it seams to me that the same types of
transformations should happen when the bones are animated in sim/game (IE.
move the hand with the stick and the fingers, finger tips, thumb, forarm
and upper arm should follow automatically). But maybe I'm wrong.
The walker model is much like the existing modern pilot that is part of the
P-51D. Very unnatural and complex to animate and with seams at the joints
that are visible.
The OSG docs I have looked at indicate that it supports armature based
animation. So in theroy if I can get the armature based blender pilot
into a correct OSG 3D file then it should be possible to animate it and
the animation should be fairly elegant. But it appears that the Blender
OSG exporter is broken. It also appears that no one has tried doing
armature based animation with any file format from with in FG yet. So I
don't even know at this point if this will work with the correctly formed
3D files. What I am really trying to get at is:
1. Will this work from with in FG?
2. If so how do I get well formed armature based 3D files that will work
with OSG out of Blender (I don't care what format it is as long as OSG
Re: [Flightgear-devel] Using native OSG 3D models - is it possible?
On Saturday, March 19, 2011 09:53:52 AM Vivian Meazza wrote: Stewart wrote -Original Message- From: S Andreason [mailto:sandrea...@gmail.com] Sent: 19 March 2011 15:35 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Using native OSG 3D models - is it possible? Hal V. Engel wrote: The model I am looking at only has one mesh [...clip...] drapped over a set of armatures (bones) [...clip...] AC3D has no support for armatures as far as I can tell so this imformation is lost on export If it is only one mesh, then that says it all. Correct. That technique is new, and not supported by AC3D. Inside of Blender the posing process is actually very elegant Yes, Blender is more advanced, and I would say since aircraft are not organic and flex thus, it has not been a priority for the fg developers to focus in this direction. Only Detlef and myself have put effort into getting any body animations, from which other piloted aircraft and carriers have benefited. (Correct me if I'm missing something, Vivian) The walker model is much like the existing modern pilot that is part of the P-51D. I forget which pilot was version 1, but the current walker came about after Detlef and I improved the pilot. Very unnatural and complex to animate and with seams at the joints that are visible. I know, it is looking old already, but it is better than nothing. I hope someone else will feel inspired, and be talented enough to pick up where I left off. Not quite - I animated the pilot in the Hunter and Seahawk way ahead of that. I have a crudely jointed model. But it just takes too long to adjust, and I was hoping that we might do it in a more professional manner. We nearly got there under PLIB, but there were some fundamental bugs we couldn't overcome. That thread of development just got lost in the cut over to OSG. I think there is something built-in to OSG, but we never got around to porting it to FG. Along with all the other things we didn't do with OSG. Google Summer of Code might have addressed one or more of these things, but I think the deadline was missed again this year. Vivian GSoC sent out acceptance/rejection letters to mentoring orgs yesterday. I am one of the Admins for an orginization that got accepted so I will be doing GSoC paper work this week end. It takes a lot of prep work to get things ready for GSoC so it is easy to not get things ready in time. But it would have been great if FG had been able to leverage GSoC to get some specific things done. Hal -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Using native OSG 3D models - is it possible?
On Friday, March 18, 2011 12:50:02 AM Detlef Faber wrote: Am Donnerstag, den 17.03.2011, 13:33 -0700 schrieb Hal V. Engel: On the forum there was a thread about an ebook on using Blender to create aircraft models. The web site for the ebook included a number of models and one of these was a WWII USAAF pilot that is very nicely done. The creator of these models has given permission to use these models in FlightGear without any restrictions. A link would be nice. Sorry, Here is a link to the forum thread: http://www.flightgear.org/forums/viewtopic.php?f=4t=11210sid=be965cf355c646bb6e77cebf5a5dca9c It has a link to the site with the ebook and there is an easy to find link there to the models including the pilot model. The pilot is built using armatures so that he can be animated but of course FG/OSG does not support native Blender files. I have attempted to use the OSG and COLLADA export scripts to create a file that is supported but the resulting files are not handled correctly by FG/OSG. Have you looked at the Bluebird Pilot and Walker Animation System? Maybe this could be used in this case. I suspect that there are issues with the Blender export since using osgviewer to view the export also has major issues. I see messages like: $ osgviewer pilot-wwii.osg LinkVisitor links 3 for Thigh.R LinkVisitor links 3 for Calf.R LinkVisitor links 3 for Foot.R LinkVisitor links 3 for Thigh.L LinkVisitor links 3 for Calf.L LinkVisitor links 3 for Foot.L LinkVisitor links 3 for Pelvis LinkVisitor links 3 for Neck LinkVisitor links 3 for Head LinkVisitor links 3 for Arm.L (looks good to this point but) RigTransformSoftware Bone Jacket not found, skip the influence group Jacket RigTransformSoftware Bone Shoes not found, skip the influence group Shoes RigTransformSoftware Bone Trousers not found, skip the influence group Trousers RigTransformSoftware Bone Shoes not found, skip the influence group Shoes RigTransformSoftware Bone Trousers not found, skip the influence group Trousers ... (look broken to me and so doe the next set of messages) 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found So the exported file is clearly an issue for OSG. I have not been able to make the COLLADA export work at all. With a COLLADA 1.3 export I get an empty file and an error message about a script failure. With the COLLADA 1.4 export I get a file but osgviewer will not load it because Warning: Could not find plugin to read objects from file pilot-wwii.dae. Do I need to change the way OSG is built or do I need to get a COLLADA plugin from some other place? I have been able to get a AC3D export but of course all of the armature stuff is gone and all I have at that point is a static model that can not be animated. So my questions are: 1. Is it possible to use and animate a model with armatures in FG/OSG assuming the 3D file is correctly formed? 2. If so what 3D file formats are best? 3. And how do I get a viable export from Blender? Hal - - Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Using native OSG 3D models - is it possible?
On Friday, March 18, 2011 07:08:14 AM S Andreason wrote: Hi Hal, Oh yes, it is possible. But not easy. Hal V. Engel wrote: I have been able to get a AC3D export but of course all of the armature stuff is gone and all I have at that point is a static model that can not be animated. The export process from Blender may not be the problem. _If_ each limb is correctly defined separately, and a child of the parent limb, then the hard part is generating the _xml_ file that defines the center of rotation of each limb's connection, and how it rotates. Each limb needs between 1 and 3 axis properties. Take a look at the animated walker in the Bluebird aircraft. Stewart http://seahorseCorral.org/flightgear_aircraft Sorry I should have been clearer. I didn't mean to imply that the AC3D export was not working. Rather only that all it created from this armature based model is a static model that had very limited posibilities for animation. You are correct that if ..each limb is correctly defined separately, and a child of the parent limb.. for non-armature animation that the export would likely work OK. The model I am looking at only has one mesh for the body including arms, hands, fingers, figer tips, thumb, legs and feet. This mesh is drapped over a set of armatures (bones) and it is designed to be animated by moving the bones with that mesh following them (IE. no visiable seams). AC3D has no support for armatures as far as I can tell so this imformation is lost on export and I end up with a mesh that is the shape that the model was posed in when it was exported. Inside of Blender I can pull, push and/or rotate the bones to pose the model in extreamly precise ways even down to changing the grip of the hands to fit around controls. The exported AC3D model can be made to fit very nicely into the cockpit but the only thing that can be animated is the head because it is a seperate mesh from the rest of the model. Inside of Blender the posing process is actually very elegant as all of the bones know how they are connected and everything moves together as it should when one part of moved. That is if you rotate the forarm the hands and fingers follow along with no need to move them seperately. I am not sure (I am new to this 3D stuff) but it seams to me that the same types of transformations should happen when the bones are animated in sim/game (IE. move the hand with the stick and the fingers, finger tips, thumb, forarm and upper arm should follow automatically). But maybe I'm wrong. The walker model is much like the existing modern pilot that is part of the P-51D. Very unnatural and complex to animate and with seams at the joints that are visible. The OSG docs I have looked at indicate that it supports armature based animation. So in theroy if I can get the armature based blender pilot into a correct OSG 3D file then it should be possible to animate it and the animation should be fairly elegant. But it appears that the Blender OSG exporter is broken. It also appears that no one has tried doing armature based animation with any file format from with in FG yet. So I don't even know at this point if this will work with the correctly formed 3D files. What I am really trying to get at is: 1. Will this work from with in FG? 2. If so how do I get well formed armature based 3D files that will work with OSG out of Blender (I don't care what format it is as long as OSG understands it)? Hal -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] File sizes in fgdata, clean up needed?
On Friday, March 18, 2011 09:50:50 AM HB-GRAL wrote: Hi all Today I checked the current fgdata/Aircraft folder for sizes. It’s about 4,3 GB here. Nice. Now some statistics (and this is no critcs on aircrafts of course, I like all the development and improvements a lot!): We have 372 aircrafts in the directory. 22 of this aircrafts have more than 30 MB and this 22 aircraft gives 1,1 GB of the aircraft folder. Number One is p51d with 104.5 MB (!). 50 MB in the models folder comes from GIMP .xcf-files and from Blender files (.blend). Do we distribute this files uncompressed? i. e. compressing .xcf to .gz will give a 1,2 file instead of a 4,3 MB. I think 12 MB vs. 43 MB. Number Two is 767-300 with 82,2 MB. I. e. this one comes with widely used .wav-sounds in the cabin ;-) This sounds, or better short loops, take 17,3 MB here. One livery (VRN.png) takes 6.3 MB. Number three is MiG-15, a really nice one, with a lot of instruments, and it seems like every byte is used here. I am looking deeper into the files and I see a radio-tune.wav which has 3.5 MB for 10 seconds of sound and 10 seconds of silence ;-) Some models like IAR80 have liveries with 13 MB .png-files. Totally we distribute 18 blender files with the directory. This is only 16,4 MB. Not much. But we distribute also 310 MB of original GIMP files. Some of this files are .gz already, when I .gz the rest I get another 100 MB, or in other words I get two MiG-15 or another p51d. Cheers, Yves I think Yves has several good points. First many of these advanced models have working files that are not actually used when the model is being flown in sim. The p51d GIMP files and blender files are two examples. Now there are valid reasons for these to be source controlled. For example the gimp files in the p51d/Models directory are complex multi layer files that are intended to make working with the resulting textures easier and they do indeed do that. Reading Yves comments I think one of the things he hionted was not so much that these working files made GIT bigger but that that they made the distribution size to users bigger and really served no purpose for users other than wasting disk space and bandwidth. This is a valid concern at least if the size of these working files is significant and in some of these case they are. A look at p51d/Models clearly shows that the three big space users are (in order of the highest space useage) the working files mostly in the form of high resolution multi layer textures, 3D models and the actual textures. In the case of the p51d all 3D models are AC3D files and many of the textures except some newer ones are *.rgb files. These are not the most compact formats and changing these could reduce the size of the model significantly but the 800 pound gorrila is still the working files. In the case of the p51d, and I suspect that this is true for most models, the working files could be located anywhere in the file system tree. And perhaps it makes sense to have a directory with a standard name that is used for these types of files that is always excluded (somehow?) when regular user gets a copy but is included for GIT clones. In the case of the p51d this would cut the size of the distributed copy almost in half. The 3D and texture parts of the p51d are now fairly far along and will not grow too much more even though there is still 3D work that needs to be done. It's size will only grow by perhaps 10% as it 3D model and FDM are finalized. There may be other models that get implemented for more complex aircraft that could result in significantly larger models. I suspect that the 100 meg p51d to 310+ meg IAR80 sort of represents the size range we will be seeing for really advanced highly detailed models with a few really careful modelers being able to bring these numbers down to lower levels while achiving the same effective level of detail like the Mig-15 does. I really think we are only seeing the begining of a period where are will see more efforts to take existing models to the next level and where we will start seeing new additions that enter GIT already in a very advanced state. As this process unfolds we will see many more models that approach the size of the ones listed by Yves. We don't want to discourage that work but if we can create a set of best practices we can perhaps help those working on this stuff create these highly detailed aircraft while using less space for the files needed to support this work. Hal -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
[Flightgear-devel] Using native OSG 3D models - is it possible?
On the forum there was a thread about an ebook on using Blender to create aircraft models. The web site for the ebook included a number of models and one of these was a WWII USAAF pilot that is very nicely done. The creator of these models has given permission to use these models in FlightGear without any restrictions. The pilot is built using armatures so that he can be animated but of course FG/OSG does not support native Blender files. I have attempted to use the OSG and COLLADA export scripts to create a file that is supported but the resulting files are not handled correctly by FG/OSG. I suspect that there are issues with the Blender export since using osgviewer to view the export also has major issues. I see messages like: $ osgviewer pilot-wwii.osg LinkVisitor links 3 for Thigh.R LinkVisitor links 3 for Calf.R LinkVisitor links 3 for Foot.R LinkVisitor links 3 for Thigh.L LinkVisitor links 3 for Calf.L LinkVisitor links 3 for Foot.L LinkVisitor links 3 for Pelvis LinkVisitor links 3 for Neck LinkVisitor links 3 for Head LinkVisitor links 3 for Arm.L (looks good to this point but) RigTransformSoftware Bone Jacket not found, skip the influence group Jacket RigTransformSoftware Bone Shoes not found, skip the influence group Shoes RigTransformSoftware Bone Trousers not found, skip the influence group Trousers RigTransformSoftware Bone Shoes not found, skip the influence group Shoes RigTransformSoftware Bone Trousers not found, skip the influence group Trousers ... (look broken to me and so doe the next set of messages) 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found So the exported file is clearly an issue for OSG. I have not been able to make the COLLADA export work at all. With a COLLADA 1.3 export I get an empty file and an error message about a script failure. With the COLLADA 1.4 export I get a file but osgviewer will not load it because Warning: Could not find plugin to read objects from file pilot-wwii.dae. Do I need to change the way OSG is built or do I need to get a COLLADA plugin from some other place? I have been able to get a AC3D export but of course all of the armature stuff is gone and all I have at that point is a static model that can not be animated. So my questions are: 1. Is it possible to use and animate a model with armatures in FG/OSG assuming the 3D file is correctly formed? 2. If so what 3D file formats are best? 3. And how do I get a viable export from Blender? Hal -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear timing over network
On Wednesday, March 02, 2011 11:32:46 AM Curtis Olson wrote: Coming from the unix perspective, xntp is a pretty good tool for maintaining a very accurate real time clock setting on your PC. If you run this on all your machines they're real time clock should be *very* close to in sync. Then things like --timeofday=noon should work well. This is something that can be set remotely via the telnet interface. Curt. On Wed, Mar 2, 2011 at 6:58 AM, Harry Campigli wrote: I am looking to time sync 3 machines running FG over the network and would like to sync the sim times to one master machine. I have them all on nfs but it seems thats not quite the trick. So what ever time the master is working on, be it from command at start, or selecting for example noon on the gui menu, the others follow. I see in sim timing properties there are lots of values in the property tree, And I see system timing also comes via sim gear. Do is anyone familiar with the code know which is the root time source on the property tree? The one I can forward to the slave machines. And i guess i will need to stop the slaves from trying to overwrite this value locally. -- Regards Harry ntp is very good at keeping clocks in sync with the actual time or with a specific machine. You should probably setup one machine so that it keeps it's clock synced to one or more external time servers via ntp and also acts as a time server on the local network. Its clock will be within perhaps 2 to 5 milliseconds of the actual offical time depending on how carefully you select your time servers and on how good or bad your network connection to the outside is. This could be improved by using a local reference clock such as a GPS receiver to be with in a few microseconds and some setups like this can be as accurate as 50 nanoseconds. Then set up the other computers to use the local time server via ntp. This should keep all of the clocks synced to within perhaps 5 to 10 microseconds of the local time server once things stabilize. If you use external servers for time keeping on all of the machines about the best you will do is to keep the machines synced to within perhaps 5 to 10 milliseconds plus you will generate more external network trafic than you need to. The above assumes *nix machines. For Windows machines about the best you can do is to keep the time within about 10 milliseconds of the external server(s). As an example of what is possible on a Linux box here is what my machine currently reports: $ ntptime ntp_gettime() returns code 0 (OK) time d119250f.15aa6088 Wed, Mar 2 2011 12:20:31.084, (.084631361), maximum error 298591 us, estimated error 309 us ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset -0.104 us, frequency 101.576 ppm, interval 1 s, maximum error 298591 us, estimated error 309 us, status 0x2001 (PLL,NANO), time constant 4, precision 0.001 us, tolerance 500 ppm, This is using a Motorola Oncore UT+ GPS as a time source with ntp and Linux kernel version 2.6.36. As you can see the clock is off by slightly more than 0.1 microseconds (IE. 104 nanoseconds) when I ran this. The Oncore UT+ is a special purpose time keeping GPS. Hal -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Use of included xml files from Instruments-3d/* from an aircraft located outside of $FG_ROOT
On Sunday, February 13, 2011 11:30:05 PM ThorstenB wrote: On 14.02.2011 07:58, Hal V. Engel wrote: When working on this from an aircraft that is not located in $FG_ROOT (IE. my clone of fg-data using fg-aircraft=my fgdata clone/my aircraft) I was getting file not found errors. At first I though that perhaps I had a typo or something similar in my code but after looking things over very carefully I couldn't find the problem. So as a test I modified the aircraft-set.xml for the same aircraft in $FG_ROOT and tested with it and it didn't have the problem. I did some more testing and found if I run the aircraft from my development copy of fgdata it works but only if the xml file I am including in the aircraft-set.xml file is located in the same tree as the aircraft. So it does not find it in the $FG_ROOT directories like it should based on how the fg-aircraft stuff has been explained. Is this a bug or I am not understanding how this should work? It should work - and does for me. But remember the fg-aircraft option does not support multiple fgdata clones. Neither should you give it the path to a specific aircraft directory. You need to provide a directory path, which contains one or multiple aircraft sub-directories. It should look like this: --fg-aircraft=/home/foo/bar/MyAircraftRepository and /home/foo/bar/MyAircraftRepository should contain directories like /home/foo/bar/MyAircraftRepository/747-400 /home/foo/bar/MyAircraftRepository/P51-D /home/foo/bar/MyAircraftRepository/AH-1 ... Otherwise, post some more details on what your command-line and the directory structure of the separate aircraft repo looks like. And yes, as discussed on the list before, the fg-aircraft option requires better checks and error messages, since more people have had trouble with providing the correct directory structure (especially since incorrect structures seem to work at first - but then really don't). cheers, Thorsten I keep a current copy of fgdata at $FG_ROOT which is currently located at /usr/share/games/FlightGear. I have my cloned copy of fgdata located in ~/Sources/fgdata. My fg-aircraft setting looks like this: fg-aircraft=$HOME/Sources/fgdata/Aircraft/p51d Since I want FG to pick up the p51d specific files from the fg-aircraft directory and everything else from $FG_ROOT since $FG-ROOT is synced to the version of FG I have installed. But I guess that I was using this incorrectly and I just tried it using fg-aircraft= $HOME/Sources/fgdata/Aircraft/ and things worked but now it is picking up the stuff in Instruments-3d from the fg-aircraft tree rather than $FG_ROOT. This will actually make thing a little easier for managing the sources. Sorry for the noise. Hal -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Use of included xml files from Instruments-3d/* from an aircraft located outside of $FG_ROOT
I starting working on making the SCR-522C radio functional and ran into a problem. Looking at other devices in Aircraft/Instruments3d to see how I could initialize the device I found that the kma20 does this by using a initialization xml file that is included from the aircraft-set.xml file. So I copied how it was doing things. When working on this from an aircraft that is not located in $FG_ROOT (IE. my clone of fg-data using fg-aircraft=my fgdata clone/my aircraft) I was getting file not found errors. At first I though that perhaps I had a typo or something similar in my code but after looking things over very carefully I couldn't find the problem. So as a test I modified the aircraft-set.xml for the same aircraft in $FG_ROOT and tested with it and it didn't have the problem. I did some more testing and found if I run the aircraft from my development copy of fgdata it works but only if the xml file I am including in the aircraft-set.xml file is located in the same tree as the aircraft. So it does not find it in the $FG_ROOT directories like it should based on how the fg- aircraft stuff has been explained. Is this a bug or I am not understanding how this should work? Hal -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender question?
On Thursday, February 10, 2011 01:24:32 PM Curtis Olson wrote: I have a hopefully quick question. I've generated a 3d model mesh in ac3d format. I'm doing this from a perl script and I posted some pictures and details of the actual model here: http://www.flightgear.org/blogs/curt/uas/misc/3d-modelling-with-perl/ My script just generates the left half of the model. I assumed I could just import this into blender, duplicate the half and mirror it and produce the whole model. I'm new to blender, but I managed to duplicate the side and mirror it and the mesh looks perfect. My problem is that when I export the full model, the mirrored half is black from the outside. When I look inside of it, it's shaded properly. It appears that when I mirrored the surface, the face ordering didn't change so the mirrored half is inside out. I've been trying every possible face/normal/edge option I can find in blender and haven't been able to figure out how to get my faces back the right way. The original half of course looks just fine. It's probably something super simple, but I've googled and haven't found the right set of keywords I guess. Is there an easy way to get all my faces the right way so both sides of my model are right side out and look correct? Thanks, Curt. First you need to make sure that the surfaces are single sided. At that point the part that is black from the outside should become transparant from the outside. Then you need to flip the normals for those faces. You might be able to do this by using normals recalculate outside in edit mode. When you are in Edit mode in the 3D part of the display you should be able to activate the buttons menu in the other part of the screen and it will allow you to turn on displaying the normals vectors in the 3D screen. This will let you know for sure which way the normals are pointing. Hal -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
On Sunday, February 06, 2011 01:13:28 PM Torsten Dreyer wrote: I have checked your code and it breaks the previous behaviour for JSBSim. Your code is overwriting JSBSim values during initialization, I would rather do it the other way around and make JSBSim overwrite FlightGear default values. Especially because the capacity of all the tanks is now set to zero instead of using the FDM model definition. Enclosed is a patch that restores the normal behaviour : fuel capacity, level and density are set after the values defined in the aircraft JSBSim XML definition. Ouch - that was my bad. I only initialized JSBSim properties from FlightGear properties which didn't work if tanks are only defined within the JSBSim config file. Your patch turns this the other way round. I tried to combine both versions and set JSBSim properties from FlightGear properties if they exist and create the FlightGear properties from JSBSim properties if not. Looks good for me with the p51d-jsbsim, the c172p and the SenecaII. Thanks for the fast bug-report and the solution! Torsten Did you test the P-51D drop tanks to make sure these work OK? The unusual thing it does is to prevent the drop tank contents from being non-zero unless the tank is currently in place. This is to prevent the pilot from using the Equipment -- Fuel and Payload menu to put fuel into a non-existant drop tank. This should be tested just to make sure it is still working. Hal -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgdata merge request for p51d
I just put in another p51d-jsbsim merge request. This merge mostly affect the exterior 3D model. It now has much improve textures with seams, rivets and access panels. Some changes were made to the nose area of the 3D model to make the line smoother. This also includes some minor improvements to the cockpit models. I also corrected the fuel tank setup so that it will be correct when the fuel density patch is applied. The merge is to the master branch but I think this should also go into the 2.2.0 branch. Hal -- 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
[Flightgear-devel] Incorrect conversion used for lbs to gallon of fuel
A thread was opened on the forum about how the C172P appeared to be incorrectly calculating the amount of fuel in gallons based on the weight of the fuel. It appears that the conversion is using 6.6 lbs/gal when it should be using something close to 6.0. That is /fdm/jsbsim/propulsion/tank[n]/contents-lbs divided by /consumables/fuel/tank[n]/level-us_gal == 6.6 I also had an issue with this for the p51d-jsbsim model and I had to use 6.6 as the conversion factor when setting up the fuel tanks in order to get /consumables/fuel/tank[n]/level-us_gal to report the correct amount of fuel. What is really strange is that /consumables/fuel/tank[n]/density-ppg = 6.0. Is this a bug or is there some other issue that aircraft developers need to be aware of to get this to work correctly? Hal -- 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] MSVC and C99
On Monday, January 24, 2011 07:54:53 am Geoff McLane wrote:
On Sun, 2011-01-23 at 16:50 +0100, ThorstenB wrote:
On Sun, Jan 23, 2011 at 3:44 PM, Geoff McLane wrote:
And I am not so sure MSVC even zeros static variables,
unless specifically set to NULL/0, unlike as suggested
for gcc, thus say :-
static char * cp;
void func() {
if (cp == NULL)
cp = malloc(val);
can also be a problem...
It'd still be interesting to know if MSVC really doesn't comply with the
rule above - this could certainly be a source for several MSVC-specific
FG issues (just guessing here...).
cheers,
Thorsten
Hi Thorsten,
I do not know if the developers of MS VC tools
make any effort to conform to C99 or not, but
this wiki :-
http://en.wikipedia.org/wiki/C99
categorically states, as of MSVC10 (2010), a
resounding red flagged _NO_!
MSVC has never had c99 support and I have seen stuff on Microsoft support site
that says that they do not intend to have c99 support. But I have not tested
this with newer versions of MSVC since I now use GCC for all platforms.
And there are other cases I know about where
MS has chosen to do its own thing, as far as it
can... ;=))
At the moment do not have access to my machine
with MSVC9 and MSVC10 installed, so can not
immediately check them, but checking MSVC8,
neither __STDC__ nor __STDC_VERSION__ seem
defined by the compiler...
Whereas, in a quick Ubuntu test, I can see gcc
(4.2.4) defines at least __STDC__.
And in some quick test compiles with MSVC8,
several static variable examples I tried all
seemed to be NULL/0, but maybe that more
represents the relative pristine initial
memory state, when I start the machine...
But, like you, I would prefer to see explicit
initializations, and am sure, over the years,
I have seen this static value error now and
again...
And as stated, see it all the time with class
instantiation...
So it seems, good cross-platform code would
make sure _ALL_ are specifically initialized.
Regards,
Geoff.
---
--- 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
--
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] FGrun and --fg-aircraft
On Friday, January 21, 2011 05:25:27 am Alan Teeder wrote: -- From: Frederic Bouvier fredfgf...@free.fr Sent: Friday, January 21, 2011 11:52 AM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] FGrun and --fg-aircraft Yes, that's true. For a reason I don't know, I missed that one. For the moment, fg-aircraft is not used in the aircraft chooser. -Fred Thanks for the reply. At least I know that it is not another of my stupidities. ;-) Alan This was confusing for me at first. What I have done is to use --fg-aircraft to point to the specific aircraft I am developing so that it pulls everything from $fg-root except for the one aircraft in $fg-aircraft. So on my linux box I have the following settings in fgrun --fg-root=/usr/share/games/FlightGear --fg-scenery=/usr/share/games/FlightGear/Screnery --fg-aircraft=/home/heng/Sources/my-fgdata/Aircraft/p51d With this setup only the p51d stuff comes from $fg-aircraft and all other aircraft and shared files are pulled from $fg-root. This allows me to keep everything in sync with the GIT fgdata main line in $fg-root so that I don't have to worry about anything in my development clone other than the aircraft I am working on. Isn't this how this is intended to work? Hal -- 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] Building FlightGear under Vista
On Sunday, September 05, 2010 10:30:06 am Frederic Bouvier wrote: 2) I'd like the aircraft to start up at the end of the runway, all ready for takeoff. Can I do that? You need to press the 's' key to start the engine. There should be a property to have the engine started but I don't know which one. If you know it, you can start fgfs with the --prop:/property/to/start/engine=true Doesn't this depend on the aircraft? Some aircraft will not run without certain conditions being in place. For example the JSBSIm P-51D needs to have the fuel pump turned on, the fuel cutoff in the on position, the mixture in run or full rich and the mags turned on among other things to run. A quick search on-line found a number of references to setting /engines/engine[0]/running=true to have a running engine. I just tested setting the above property with the JSBSim P-51D and it was not running when flightgear started. This is not surprising because it had no fuel and the ignition was off at that point. The startup procedure for the JSBSim P-51D is documented in aircraft help where there is a complete set of check lists including one for the start up procedure. Hal -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Building FlightGear under Vista
On Monday, September 06, 2010 09:29:50 am Jon S. Berndt wrote: Like this? git pull git://gitorious.org/fg/fgdata.git ?? Which branch should I specify? Jon No from the root directory of your local copy just git pull and git will handle updating anything that needs it. -Original Message- From: Jon S. Berndt [mailto:jonsber...@comcast.net] Sent: Monday, September 06, 2010 11:26 AM To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Building FlightGear under Vista Hi Jon, If you don't do local changes updating is as easy as cd:ing into fgdata Done. (and the respective source repositories) How do I do this? and type 'git pull'. JB --- --- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel --- --- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim - how to model piston engine exhaust thrust?
On Friday, September 03, 2010 01:49:46 am thorsten.i.r...@jyu.fi wrote: In the end, there are hundreds of things you don't know - friction in the exhaust tube for example... its geometrical shape (exhaust velocity isn't actually a constant - there's some spatial profile to the velocity field)... turbulence when the exhaust airstream enters ambient air... and so on. In fact things like this can be very difficult to quantify. With regard to tube shape early RR Merlin engines (meaning before 1943) had ejector exhaust stacks that were designed by RR. At around that same time that RR was doing their testing on these ejector exhausts NACA was doing experiments on exhaust stack shapes with Alison engines to maximize exhaust jet thrust. The NACA configuration was later compared to the RR configuration and there was about a 60% increase in the exhaust thrust/reduction in profile drag over the RR configuration. The Spitfire V that was used for these tests had a 6 MPH increase in top speed with the NACA stacks compared to the RR stacks. Later Merlins all had the NACA stacks because of the increased thrust/reduced drag. In the paper on these tests NACA wrote that they could not quantify how much of the speed increase was due the thrust and how much was due to profile drag if any. Another example is that similar engines (same displacement, manifold pressure and RPM) with a mechanical super charger vs. a turbo (think super charged vs. turbo'ed Alison engines - IE. P-40 vs. P-38 configurations) are likely to have significantly different exhaust thrust because the turbo has used a significant amount of the energy in the exhaust perhaps to the point where the thrust is too low to worry about. The point is that the same exact aircraft with the same engine with two different sets of exhaust stacks had a 6 MPH difference in top speed with exactly the same amount of air and fuel being pumped through the engine. Which means that this speed/thrust difference can not be accounted for by a thermal dynamic formula. This leads me to think that having a good generic formula that gives a good approx. of the shape of the exhaust thrust curve along with a constant to tune the thrust levels to the engine/exhaust system in question should work. Hal -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] stall/snap/spin behavior in JSBSim CVS
On Thursday, August 26, 2010 06:21:16 pm Jon S. Berndt wrote: From: Hal V. Engel [mailto:hven...@gmail.com] Since I have started using FG GIT with it's newer versions of JSBSim I have noticed that the behavior I had created with the stall/spin function was much more pronounced and today I had a closer look at this. With current versions of FG and JSBSim even with my stall/spin function removed I am seeing a very pronounced tendency to drop the left wing at the stall and this now acts much like it did in FG 2.0 with my stall/spin function included. Although I think the effect is more pronounced with a tendency to snap to the left when doing high G maneuvers that was not there with my function and FG 2.0. It appears that there has been some work done on JSBSim to get more realistic stall/spin/snap behavior. Is this correct or am I imagining things? Here are my thoughts about what I am seeing. 1. This is a step in the right direction that should result in a immediate improvement to the stall/spin/snap behavior for most existing models. I can't think of anything we've done that would have had this effect. We have been making some bug fixes, and architectural changes, and so on. I guess it's possible that something we did may have fixed an error, which resulted in better performance. I'm glad things got better, though! Jon I did a quick test with the pc7 and it did not exhibit any tendency to snap or spin. It mushed straight ahead. So I concluded that this was something in my model. Turns out that I forgot that I had two functions related to stall/spin and I needed to work on both. Sorry for the noise. Hal -- 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] stall/snap/spin behavior in JSBSim CVS
In the process of working up my JSBSim FDM for the P-51D I had added some functions to make the behavior at stall more realistic. In FG 2.0 before adding these functions were added the stall was like a (very fast) trainer - a straight ahead mush but it would drop a wing if enough rudder was added at the stall. Basically what I did in the stall/spin function was to increase yaw forces to the left as the alpha angle reached the stall point. Since I have started using FG GIT with it's newer versions of JSBSIm I have noticed that the behavior I had created with the stall/spin function was much more pronounced and today I had a closer look at this. With current versions of FG and JSBSim even with my stall/spin function removed I am seeing a very pronounced tendency to drop the left wing at the stall and this now acts much like it did in FG 2.0 with my stall/spin function included. Although I think the effect is more pronounced with a tendency to snap to the left when doing high G maneuvers that was not there with my function and FG 2.0. It appears that there has been some work done on JSBSim to get more realistic stall/spin/snap behavior. Is this correct or am I imagining things? Here are my thoughts about what I am seeing. 1. This is a step in the right direction that should result in a immediate improvement to the stall/spin/snap behavior for most existing models. 2. My stall/spin function was actually a very crude attempt at this and I had intended to revisit it to make it more generalized. One issue is that it always drops the left wing regardless of the beta angle. In an aircraft like the P-51D there is almost always some beta angle (in this case it almost always has a little beta to the left since the fin has a 2 degree angle to the AC centerline) and in most cases this will result in the left wing dropping during a stall but I don't think it should always drop the left wing regardless of the beta angle. I think it should drop the left wing if the beta angle is to the left and it should drop the right wing if the beta angle to the right with perhaps a slight tendency to favor dropping the left or right wing depending on the direction of rotation of the prop and/or some other factors. 3. I think the current setup has too much tendency to drop the wing but this likely depends on the aircraft being modeled. Perhaps some kind of property can be exposed so that those creating models can control how strong this is. That is a C172 should only drop a wing in a very deep stall with a significant (larger) beta angle but a WWII fighter or an air racer should drop the wing earlier in the stall with much smaller beta angles. Those creating models need some way to control this so that this can be tuned to the aircraft being modeled. Hal -- 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] Crash with new p51d-jsbsim
On Monday, August 16, 2010 08:14:04 pm Ron Jensen wrote: On Monday 16 August 2010 20:56:17 Jon S. Berndt wrote: Hi Hal, Would you elaborate on the error in CDde? It looks like the same CDde used in most aeromatic aircraft so if there is an error in the P51d we (still) have an error in many jsbsim aircraft. Thanks, Ron It's probably the situation where if the elevator has a negative deflection, that is multiplied against the CD and you get a negative drag. Jon The version on gitorious has the elevator wrapped in absolute tags so there shouldn't be a negative drag problem. Ron I was getting negative values in spite of the abs /abs tags. So there appears to be something wrong with the abs tag at least with the version of stuff that is in FG git right now. This was easy to fix by using a table like this: table independentVarfcs/elevator-pos-norm/independentVar tableData -1.01.0 0.00.0 1.01.0 /tableData /table But the abs tag problem needs to be fixed. Hal -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim - how to model piston en gine exhaust thrust?
On Monday, August 16, 2010 08:59:38 pm Ron Jensen wrote: On Monday 16 August 2010 21:19:35 Ron Jensen wrote: On Monday 16 August 2010 20:58:44 Jon S. Berndt wrote: What's your second thought? O.k. third thought. An FCS function (so it will work in current flightgear) applied by external forces at the correct area... I'm working up an example of this idea now.. The following code is built around a 1700 hp engine pushing 67 inHg as an example. It seems to work in FlightGear but hasn't been extensively validated. Keep the direction vector normalized if you adjust that... Ron Paste the channel below into your flight_control section channel name=exhaust thrust fcs_function name=aero/function/engine-exhaust-thrust function product propertypropulsion/engine/power-hp/property value0.000588/value !-- 1/1700 hp to nomalize engine/power-hp -- property propulsion/engine/map-inhg /property value0.0149/value !-- 1/67 inhg to nomalize engine/map-inhg -- value 70 /value !-- 70 lbs of thrust at full power and map -- /product /function output external_reactions/exhaust-thrust/magnitude /output /fcs_function /channel And then add an external_reactions section between flight_control and aerodynamics: external_reactions force name=exhaust-thrust frame=BODY location unit=IN x 96.5 /x !-- this is the CG for the example aircraft -- y0.0 /y z-9.0 /z /location direction x1.0 /x !-- straight down the aircraft longitudinal axis -- y0.0 /y z0.0 /z /direction /force /external_reactions This seems to be working. A few comments. The 70 lb thrust figure was for an early merlin spitfire (IE 1938) with about 1200 HP war emergency power and with the pre NACA exhaust pipes. The spitfire used in the NACA tests in 1942 had a Merlin XLV engine which would have made it a mark V with 1470HP. So for a 150 octane V-1650-7 (with NACA exhaust pipes) that a late model P-51D would have been using the exhaust thrust at max power (1940 HP at 81 inHg) should be closer to 200 lbs. I am a little confused about why you include engine HP in the thrust function. For super charged engines there is a considerable amount of power used for driving the super charger (probably about 150HP on low blower and about 350HP on high blower at 67 inHg for this engine) so this would result in lower exhaust thrust on high blower. But the exhaust thrust (at the same RPM) should be the same if not higher at higher altitudes for a given manifold pressure. If my memory of physics is correct the thrust should be proportional to: V^2 x M Where V is the velocity of the ejecta and M is the mass of the ejecta. The amount (or mass) of ejecta should be the same per engine revolution at a given manifold pressure. This makes me think the function should be using RPM instead of HP. In addition I think altitude comes into play as well since it seems logical to me that the velocity of the ejecta would be higher at higher altitudes. That is lower exhaust back pressure should result in higher exhaust gas velocity but I don't know if the velocity increase is enough to worry about. But it is squared so even a small change in the ejecta velocity could be a significant factor. I think the location of the force should be about where the center of the engine is located since this is approx. where the exhaust stacks are located. I changed my local version to use RPM instead of HP and adjusted things to better reflect the V-1650-7. I also moved the location of the force. This is what I am now using: channel name=exhaust thrust fcs_function name=aero/function/engine-exhaust-thrust function product propertypropulsion/engine/propeller-rpm/property value0.00079365079/value !-- 1/1260 to nomalize engine/propeller rpm -- property propulsion/engine/map-inhg /property value0.01234567/value !-- 1/81 inhg to nomalize engine/map-inhg -- value 200 /value !-- 200 lbs of thrust at full RPM and map -- /product /function output external_reactions/exhaust-thrust/magnitude /output /fcs_function /channel external_reactions force name=exhaust-thrust frame=BODY location unit=IN x 36 /x !-- center of engine -- y0.0 /y z0.0 /z /location direction x1.0 /x y0.0 /y z0.0 /z /direction /force /external_reactions Hal -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___
Re: [Flightgear-devel] Crash with new p51d-jsbsim
On Sunday, August 15, 2010 12:05:23 pm Stuart Buchanan wrote: On Sun, Aug 15, 2010 at 3:04 AM, Hal V. Engel wrote: The crash-detect freeze channel code was lifted from one of Dave Culp's models. But I never got around to actually using this code or figuring out what it does. So the freeze channel is basically dead code and should be removed. I will remove this in the next merge. Rather than commenting out the crashed channel way don't you try commenting out the freeze channel since it doesn't do anything at this point and is the likely cause of the issues you are having. Yes, that did the trick. I hadn't noticed that previously I'd commented out the crashed, impact-ground and freeze channels. If the freeze channel is dead code I can remove it from git if you wish. I'm still getting ocassional segfaults, and a segvault on exit, which suggests that there are some other uninitialized properties, but for now I'm a (very) happy flier. -Stuart Stuart, I've got some other things in the oven for the P51D JSBSim model. Among other things I found a significant error in one of the drag functions, CDde, and this cascaded changes to other areas to get things working the way they should. I will be pushing these changes into my fgdata clone on gitorious in the next week or so and then will be requesting that those changes be merged into fgdata. So it would probably be better to just wait for that code to be merged in the main fgdata repository since this does not seg fault for most users for some reason. Also if you find any clues about other uninitialized properties please pass them on so that I can look at the model to see what is going on. Hal -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] JSBSim - how to model piston engine exhaust thrust?
For the P-51D model I would like to model the thrust created by the exhaust system. On the real thing this is about 10% of the thrust created by the engine under at least some circumstances. Early tests done with the Spitfire in the late 1930's produced about 70lbs of thrust (about 70HP) and a gain about 10MPH in top speed when the first test set of Ejector exhausts were installed. An early spitfire Merlin would have been around 1000HP. Later the NACA tested an improved set of NACA Ejector exhausts on a similar spitfire and they got another 6 MPH increase in the top speed. The NACA version was used on most WWII Merlins including the Packard built engines that were used on the P-51B/C/D/H. Currently JSBSim does not model the thrust created by the exhaust system as far as I can tell. I tried using a set of rockets to model this since it seems to me that this should act like a rocket whose throttle setting is proportional to the relative manifold pressure (IE MP/max MP). But I couldn't get this to work as the rockets would not fire up no matter what I did. Has anyone done something like this? If so could you let me know where I can find the model so I can have a look at it. If not does anyone have any idea how this could be setup? Hal -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash with new p51d-jsbsim
On Saturday, August 14, 2010 02:13:13 pm Stuart Buchanan wrote: On Sat, Aug 14, 2010 at 9:50 PM, Stuart Buchanan wrote: So, I suspect the problem is in these properties that are being used in switch statements without a default value, but I don't know enough about JSBSim properties to be able to set a sensible default in the right place. Commenting out most of the crashed channel in Systems/crash-detect.xml appears to solve the problem. -Stuart The crash-detect freeze channel code was lifted from one of Dave Culp's models. But I never got around to actually using this code or figuring out what it does. So the freeze channel is basically dead code and should be removed. I will remove this in the next merge. Rather than commenting out the crashed channel way don't you try commenting out the freeze channel since it doesn't do anything at this point and is the likely cause of the issues you are having. The crashed channel is what stops the sim if an impact is detected or the airframe is over stressed. There is also a nasal script that detects things like exceeding VNE by too much for too long that also sets /fdm/jsbsim/systems/crash-detect/crashed so that the switch in the crashed channel can halt the simulation. I had one other user report having problems with the crash-detect code. He was also seeing seg faults. But this does not happen on my machine so I have not been able to trace down the cause. Thanks for digging into it and locating the probable cause. Please let me know if removing the freeze channel fixes this problem for you. Hal -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash with new p51d-jsbsim
On Wednesday, August 11, 2010 02:10:07 pm Stuart Buchanan wrote: Hi All, I'm getting consistent crashes with the new p51d-jsbsim. Backtrace below. My simgear and flightgear source are up to date (as far as I can tell). Anyone else seeing this? -Stuart Just to follow up. I am not running current GIT of FG. My copy is GIT as of about 3 weeks ago and I am not seeing this issue. The JSBSIm P-51D is doing some things that are a little unusual and that push the limits of what can be done in JSBSIm. So it is more likely to run into things that cause crashes than most models. It appears that it is crashing when it tries to do something with a switch. You might want to try bisecting to see which commit is causing the problem. Hal setStores Program received signal SIGSEGV, Segmentation fault. 0x009ba8ba in SGPropertyNode::get_int (this=0x100e3740) at props.cxx:370 370 return (static_castSGRawValueint*(_value.val))-getValue(); (gdb) bt #0 0x009ba8ba in SGPropertyNode::get_int (this=0x100e3740) at props.cxx:370 #1 SGPropertyNode::getDoubleValue (this=0x100e3740) at props.cxx:1219 #2 0x005bce52 in JSBSim::FGSwitch::test::GetValue (this=0x101cca50) at FGSwitch.h:164 #3 JSBSim::FGSwitch::Run (this=0x101cca50) at FGSwitch.cpp:169 #4 0x0055425d in JSBSim::FGFCS::Run (this=0x10172810) at FGFCS.cpp:215 #5 0x0051bbe5 in JSBSim::FGFDMExec::Run (this=0x101887e0) at FGFDMExec.cpp:331 #6 0x0051bc58 in JSBSim::FGFDMExec::RunIC (this=0x101887e0) at FGFDMExec.cpp:347 #7 0x0053abfb in JSBSim::FGTrimAxis::Run (this=0x7fffd0054080) at FGTrimAxis.cpp:406 #8 0x00539707 in JSBSim::FGTrim::DoTrim (this=0x7fffd0053f90) at FGTrim.cpp:262 #9 0x00501177 in FGJSBsim::do_trim (this=0x10290f80) at JSBSim.cxx:1166 #10 0x00501be2 in FGJSBsim::update (this=0x10290f80, dt=value optimised out) at JSBSim.cxx:501 #11 0x004e7258 in FDMShell::update (this=0xd22aca0, dt=value optimised out) at fdm_shell.cxx:162 #12 0x009f645d in SGSubsystemGroup::Member::update (this=0xd1b41f0, delta_time_sec=value optimised out) at subsystem_mgr.cxx:339 #13 0x009f83c8 in SGSubsystemGroup::update (this=0xddcf68, delta_time_sec=value optimised out) at subsystem_mgr.cxx:177 #14 0x009f624a in SGSubsystemMgr::update (this=0xddcea0, delta_time_sec=value optimised out) at subsystem_mgr.cxx:432 #15 0x00431a8a in fgMainLoop () at main.cxx:164 #16 0x0047b9a2 in fgOSMainLoop () at fg_os_osgviewer.cxx:200 #17 0x00432899 in fgMainInit (argc=2, argv=0x7fffe318) at main.cxx:664 #18 0x0042fe1e in main (argc=2, argv=0x7fffe318) at bootstrap.cxx:243 (gdb) print _value Cannot access memory at address 0x88 --- --- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash with new p51d-jsbsim
On Thursday, August 12, 2010 07:24:36 pm Ron Jensen wrote: On Thursday 12 August 2010 18:52:28 Hal V. Engel wrote: On Wednesday, August 11, 2010 02:10:07 pm Stuart Buchanan wrote: Hi All, I'm getting consistent crashes with the new p51d-jsbsim. Backtrace below. My simgear and flightgear source are up to date (as far as I can tell). Anyone else seeing this? -Stuart Just to follow up. I am not running current GIT of FG. My copy is GIT as of about 3 weeks ago and I am not seeing this issue. The JSBSIm P-51D is doing some things that are a little unusual and that push the limits of what can be done in JSBSIm. So it is more likely to run into things that cause crashes than most models. It appears that it is crashing when it tries to do something with a switch. You might want to try bisecting to see which commit is causing the problem. Hal In yesterday's standalone JSBSim the p51d aborts because some properties are being used without being declared. Try the attached patch to the p51d.xml and see if it works any better for you. Ron ( I tried sending the whole file but it errorred out for being too many kbytes.) diff --git a/aircraft/p51d/p51d.xml b/aircraft/p51d/p51d.xml index 5a264c9..00eb3a3 100644 --- a/aircraft/p51d/p51d.xml +++ b/aircraft/p51d/p51d.xml @@ -665,6 +665,9 @@ Hal V. Engel hven...@astound.net outputgear/gear-pos-norm/output /kinematic /channel +property/controls/gear/brake-left/property +property/controls/gear/brake-right/property +property/controls/gear/brake-parking/property channel name=Brakes The above is a little confusing I think. It appears that this patch is for the p51d.xml file but p51d.xml is the YASim xml file. This probably needs to be applied against p51d-jsbsim.xml instead. I see that GIT was last synced with JSBSim CVS Aug 3 and the sync before that was on July 16. I am running a build from about July 20. So it looks like it is time to for me to rebuild FG to get the latest JSBSim code. I tested the above patch applied to p51d-jsbsim.xml with my older version of GIT and it did not cause any issues for me. I will include it with the next merge of the P-51D. Hal --- --- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash with new p51d-jsbsim
On Thursday, August 12, 2010 07:24:36 pm Ron Jensen wrote: On Thursday 12 August 2010 18:52:28 Hal V. Engel wrote: On Wednesday, August 11, 2010 02:10:07 pm Stuart Buchanan wrote: Hi All, I'm getting consistent crashes with the new p51d-jsbsim. Backtrace below. My simgear and flightgear source are up to date (as far as I can tell). Anyone else seeing this? -Stuart Just to follow up. I am not running current GIT of FG. My copy is GIT as of about 3 weeks ago and I am not seeing this issue. The JSBSIm P-51D is doing some things that are a little unusual and that push the limits of what can be done in JSBSIm. So it is more likely to run into things that cause crashes than most models. It appears that it is crashing when it tries to do something with a switch. You might want to try bisecting to see which commit is causing the problem. Hal In yesterday's standalone JSBSim the p51d aborts because some properties are being used without being declared. Try the attached patch to the p51d.xml and see if it works any better for you. Ron ( I tried sending the whole file but it errorred out for being too many kbytes.) diff --git a/aircraft/p51d/p51d.xml b/aircraft/p51d/p51d.xml index 5a264c9..00eb3a3 100644 --- a/aircraft/p51d/p51d.xml +++ b/aircraft/p51d/p51d.xml @@ -665,6 +665,9 @@ Hal V. Engel hven...@astound.net outputgear/gear-pos-norm/output /kinematic /channel +property/controls/gear/brake-left/property +property/controls/gear/brake-right/property +property/controls/gear/brake-parking/property channel name=Brakes I just tested with this change against a fresh GIT build of FG and simgear. Worked OK. Hal --- --- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT and FGDATA
On Saturday 07 August 2010 11:45:04 am Vivian Meazza wrote: Alan Teeder wrote -- From: Alasdair ali...@btinternet.com Sent: Saturday, August 07, 2010 10:47 AM To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Cc: vivian.mea...@lineone.net Subject: Re: [Flightgear-devel] GIT and FGDATA On Fri, 2010-08-06 at 07:59 -0600, dave perry wrote: I am not seeing the slowdown. I just ran a simple script that updates simgear, flightgear source, and fgdata. I would estimate that the git pull origin run in fgdata took about 3 minutes. This performance has been typical for me. I ran System Monitor (F12) during the fgdata pull and the data rate was between 96 and 100 KB/s and the memory usage was constant. I connect via Earthlink dsl. Dave P. I experience much the same as Dave. A git pull in fgdata is no big deal.Here is the output from a little test i just ran : pull started Sat Aug 7 10:32:03 BST 2010 === New directory is /opt/FlightGear/fgdata From git://gitorious.org/fg/fgdata 33b8fe6..74ec1cd master - origin/master Updating 33b8fe6..74ec1cd Fast-forward Aircraft/737-300/Models/contrail.xml | 216 +- Aircraft/C130/Models/main.xml | 33 + Aircraft/Concorde/Concorde-set.xml |8 +- Aircraft/Concorde/Models/Concorde_ba.xml | 21 + Aircraft/Concorde/Models/Effects/contrail-new.xml | 142 + Aircraft/Concorde/Models/Effects/contrail1.eff | 156 + Aircraft/Concorde/Models/Effects/contrail2.eff | 151 + .../Concorde/Models/Effects/contrail_dummy.xml | 11 + .../Concorde/Models/Effects/contrail_shader1.xml | 35 + .../Concorde/Models/Effects/contrail_shader2.xml | 35 + Aircraft/Concorde/Models/Effects/smoke.png | Bin 0 - 6482 bytes Aircraft/Concorde/concorde-submodels.xml | 28 + Aircraft/Concorde/concorde-subsubmodels.xml| 66 + Aircraft/Concorde/concorde-subsubsubmodels.xml | 67 + Aircraft/Concorde/concorde-subsubsubsubmodels.xml | 64 + Aircraft/Short_Empire/Models/Interior/interior.ac | 8138 +--- Aircraft/Short_Empire/Models/Interior/interior.xml | 312 +- .../Short_Empire/Models/Interior/spar_panel.xml| 10 +- Aircraft/Short_Empire/Short_Empire-set.xml | 25 +- Aircraft/Short_Empire/Short_S23.xml| 59 +- Aircraft/Short_Empire/Systems/fuel-system.xml | 20 +- Aircraft/Short_Empire/Systems/short-empire.nas | 11 +- 22 files changed, 8171 insertions(+), 1437 deletions(-) create mode 100644 Aircraft/Concorde/Models/Effects/contrail-new.xml create mode 100644 Aircraft/Concorde/Models/Effects/contrail1.eff create mode 100644 Aircraft/Concorde/Models/Effects/contrail2.eff create mode 100644 Aircraft/Concorde/Models/Effects/contrail_dummy.xml create mode 100644 Aircraft/Concorde/Models/Effects/contrail_shader1.xml create mode 100644 Aircraft/Concorde/Models/Effects/contrail_shader2.xml create mode 100644 Aircraft/Concorde/Models/Effects/smoke.png create mode 100644 Aircraft/Concorde/concorde-submodels.xml create mode 100644 Aircraft/Concorde/concorde-subsubmodels.xml create mode 100644 Aircraft/Concorde/concorde-subsubsubmodels.xml create mode 100644 Aircraft/Concorde/concorde-subsubsubsubmodels.xml === pull ended Sat Aug 7 10:32:40 BST 2010 fgdata git pull took 0 mins 37 seconds === My connection is BT Broadband, nominally 12 Mbps, but actually 7,616 Kbps. My machine is based on a 2x AMD Athlon(tm) 7450 Dual-Core Processor with 2 GB mem. Kind regards, Aasdair I have just done a very quick and successful fgdata git pull using Cygwin. The results were similar to Alistair´s above. Cygwin git also threw up some errors in my Simgear directory that Totoise git (even using the Diff and Check for Modifications options had not found.) From now on I will keep away from Tortoise git. MySys git-bash shell works as well - and saves the complications of cygwin. Mind you - I'm beginning to work up a method which uses the bits of tortoise-git that do work and use git-bash for those that don't. I have been using Cola GIT http://cola.tuxfamily.org/ as my GIT GUI front end on my Linux box and it works nicely. Start up is a little slow when opening a fgdata archive but other operations seem to be fairly fast. It is a python system and there are install instructions for Windows located here http://cola.tuxfamily.org/install.html. I have not used it on Windows so I can't comment on how well it works there but I think it is worth having a look for Windows users. Hal Hal
[Flightgear-devel] JSBSIm drop tanks
I am working on a model that has drop tanks. Recently I built FG GIT so that I could test against the latest code and also so that I could use new features to enhance my model. I noticed that this has a menu for Equipment - Fuel and Payload that allows the pilot to adjust how much fuel is in each fuel tank. I don't remember this being in 2.0 but I could be wrong. In any case I have an issue with this in that it allows the pilot to add fuel to the drop tanks even if these tanks are not installed. This could be because I have my tanks mis- configured or perhaps I need to set some additional properties to tell this system that the tank does/does not exist at that moment. This is a JSBSim model. What is the correct way to configure drop tanks in a JSBSim model so that this works correctly? Hal -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup problem
On Sunday 25 July 2010 10:19:46 am Stefan Seifert wrote: On Sunday 25 July 2010 18:38:45 fiers...@zonnet.nl wrote: I second that. As the matter of fact I stick to nVidea for all machines over the years, because I feel that nVidea should be rewarded for their support of Linux and ATI should be punished for not taking Linux seriously. On the other hand, I'm running a system with 100% free software thanks to AMD's releasing of documentation for driver writers for ATI cards. And my ATI card with its free drivers allowed me for the first time in many years not only to run FlightGear but also good video performance, desktop effects in KDE and usable performance with anti aliased fonts which is something NVidia never managed to do for me (some known problems with their drivers which never got fixed). Times change. Stefan To follow up the situation with AMD/ATI X11 support has changed dramatically since ATI was purchased by AMD. I think punishing AMD for the past sins of ATI is unfair and counter productive. AMD appears to be bending over backwards to rectify these issues and has made tremendous progress including the support of open source driver developers, where AMD is far better than Nvidia, and on the quality of their closed source driver. Before AMD ATI was really doing a bad job with X11 support and this left AMD with a lot of work to do to fix these issues. More remains to be done but this is something that requires a long term effort to fix and I think AMD is doing about as well as can be expected. Hal -- 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] JSBSim P-51D merge request
On Monday 19 July 2010 01:39:43 pm Anders Gidenstam wrote: On Mon, 19 Jul 2010, Hal V. Engel wrote: Are there any plans to update JSBSim in FG GIT? Hi again, Erik did that just a few days ago (on the 16th) :) Cheers, Anders I did some testing against GIT/next. It's not very stable yet so it crashed more often than I did. But I was able to get two things working that did not work with 2.0. I have added support for tail wheel locking/unlocking. This should now work like the real thing (IE. Locked when the stick is back and free swiveling when the stick is forward). It did work on my system. The Fuel selector now works and all tanks including the drop tanks are working at least on my system. I have added these changes to the merge request. Hal -- 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] JSBSim P-51D merge request
On Monday 19 July 2010 03:11:04 am Anders Gidenstam wrote: On Sun, 11 Jul 2010, Hal V. Engel wrote: This is a large merge that is a significant enhancement to the existing P-51D but it is still a work in progress and much remains to be done. At the moment I am not able to spend much time working on this but it is far enough along that I think it belongs in the FG mainline so that it can be tested against 2.1 and hopefully released with 2.1. I intend to keep working on this as time permits and my intention is to eventually make this the most complete and most accurate model in the FlightGear hanger. Hi Hal, Lovely aircraft! One thing I discovered after a few botched landings is that the crash detection system doesn't set /sim/crashed. I think it ought to since that is the standard crash indicator in FlightGear. It is easy to add as the following diff shows: index 312f0ce..bd2e03f 100644 --- a/Aircraft/p51d/Systems/crash-detect.xml +++ b/Aircraft/p51d/Systems/crash-detect.xml @@ -56,6 +56,7 @@ output/sim/freeze/clock/output output/sim/freeze/main/output output/controls/engines/engine[0]/cutoff/output +output/sim/crashed/output /switch /channel It is also easy to update the merge request - I have tried it on some of mine. Thanks Anders. I have made this update and it is now part of my gitorious fgdata clone and also part of the merge request. PS. For those who want to try the p51d before the merge request is accepted and aren't that familiar with git here are the steps to get Hal's branch: git fetch git://gitorious.org/~hvengel/fg/hvengels-fgdata-p51d-jsbsim.git master:hvengel/p51d-jsbsim git merge hvengel/p51d-jsbsim I would encourage others to test this since any feedback I get will be used for additional improvements. The model does some unusual things that push the limits of JSBSim particularly the propulsion systems and related controls. There are also some things that don't work correctly because of bugs or missing features in the version of JSBSim that is part of FG but that have been (presumably) fixed in JSBSim CVS. These include: Fuel tank switching is currently broken and the engine will only run on tank[0] (left internal wing tank). The engine gage cluster(s) give wrong oil pressure, oil temperature and coolant temperature numbers. JSBSim has some fixes related to this that do not totally fix this but are none the less improvements. The tail wheel is currently always locked to the rudder. On the real P-51 series the tail wheel would swivel if the stick is forward of neutral but lock with the stick back. JSBSim CVS has a fix that will allow for this to be correctly modeled and it should only take a fairly simple fcs_function to implement. Are there any plans to update JSBSim in FG GIT? If you have push access to fgdata it might be advisable to create a separate branch for this so that you don't accidentally push these changes. (As far as I have checked they don't interfere with anything - but if we want to keep the gitorious merge request function functional it might be better if whoever merges this contribution use that procedure instead). Having this pushed into a branch of the main FG repository for later merging into the FG mainline would be fine by me. This will allow wider testing and also allow others to work on this branch. On the forums I had an exchange with another P-51D developer who has his own copy that he is working on. For the most part we are working on different things (he is adding livery support and a bombable enabled AI model - I am working on improving the FDM, the cockpit, controls and the overall weapons systems) although there is some overlap (both have machine guns and are bombable). The other developer expressed an interest in using GIT to get his work into the FG mainline and I think his work would be a good adjunct to the update I am proposing. But it was also apparent that he had no idea how to go about doing this. There was a poll on the forums asking users what they thought was the area in FG that needed the most work and by far the item with the most votes was improving the existing models. The more that can be done to encourage collaboration on and contributions to the existing models the better it will be for dealing with this apparent shortcoming. It would be really helpful to users thinking about working on an existing model to have documentation on how to go about this process. I have worked as a developer on other open source projects as well as commercial systems so I had a pretty good idea how to go about this but many users do not have this kind of background and have no idea how to get started. Btw. local finger trouble with git can easily be adjusted using git rebase, see this very useful site for more information: http://www-cs-students.stanford.edu/~blynn/gitmagic/ch05.html
[Flightgear-devel] JSBSim P-51D merge request
I put a merge request into gitorious yesterday to merge the JSBSim P-51D changes I have been working on into the FG mainline. The merge request http://gitorious.org/fg/fgdata/merge_requests/10 has lots bullet points describing what the merge will do. But these only touch the highlights and there are far to many little details about the merge to be able to spell them all out. The YASim model is for the most part unchanged but it will benefit from some of the work done on the JSBSim model. Specifically the fuselage texture is improved and so are the main landing gear models and these are shared with the YASim model. The YASim and JSBSim models can live side by side and many of the enhancements that have been done to the JSBSim model should be fairly easy to back port to the YASim model if someone is interested in doing that work. This is a large merge that is a significant enhancement to the existing P-51D but it is still a work in progress and much remains to be done. At the moment I am not able to spend much time working on this but it is far enough along that I think it belongs in the FG mainline so that it can be tested against 2.1 and hopefully released with 2.1. I intend to keep working on this as time permits and my intention is to eventually make this the most complete and most accurate model in the FlightGear hanger. This merge is not exclusively my work as Guillaume (his moniker on the FlightGear forum) is responsible for the improved landing gear, the rudder peddles, and the cooling system exhaust doors on the dog house. Also I have made tarballs available of various versions of this and these have been downloaded and tested by numerous users (perhaps 60 or 70 downloads total over the last 3 or 4 months) who have provided lots of feedback. That feedback was used to improve the model and was very valuable to this work. Hal -- 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
