Re: [Flightgear-devel] ATC and radio signal attenuation
On Monday, September 05, 2011 20:01:29 Durk Talsma wrote: I'm a little pressed for time this week, so I have to keep my response a little on the short side. In essence, I think that this would be any extremely cool feature to have. Do you already have a working copy that you would consider merging with flightgear/next? If so, I would like to do so and give it a shot (after having tried it locally and after ensuring that everything works okay). So far, I only have one humble request, which is an option to conditionally disable it. Although I haven't really had the need to listen to distant stations yet, I can imagine that certain situations will arise where I need to be able to follow ATC messages across larger distances. Given that during the development cycle I would rather concentrate on debugging than on deciphering a radio message, I think that an option to conditionally disable ATC signal attenuation would be very welcome. Cheers, Durk Hi Durk, Yes I have it working, you can test it by cloning locally g...@gitorious.org:~kantooon/fg/kantooons-flightgear.git and building branch radio-att. To test, you need a) an airport with ground traffic when you start and b) some hilly/mountainous terain arround that will affect the signal. Given the fact that I don't have a signal strength instrument, I am printing to stderr various information about the signal. The code does make a difference between ground transmissions and aircraft transmissions, so don't be surprised if you can hear tower and can't hear the aircraft on ground. In the future, I would also like to differentiate radio equipment in large aircraft from small, portable, airband transceivers you can find on light craft. If any of you guys that are also pilots can provide me with ERP values for various types of transceivers, including ATC ones, this would be also very useful, since I am basing my current values on some estimations. Since the model does 40 MHz to 20 GHz, calculations for frequencies out of the civilian VHF airband will yield different results, including military airband and radar (establishing a link budget for a radar emission is a whole different issue though). It also can account for the type of terrain underneath (based on surface impedance values). It would be useless though for shortwave SSB radio, since propagation at those frequencies is different. However, in the current state it's kind of a hack job, being on top of FGATCController and all. As Torsten and Martin have mentioned, there could be multiple uses for this, navradio, voice comms etc., so I think making this a stand-alone radio subsystem is a must. I have started doing just that, but I still need suggestions from you on how to integrate this with the rest of the code. So far, I think exposing a receive_text() function to the ATC system, callable with the position of the sender, frequency used, message string, and type of transmission would cover the ATC/AI territory. This would be complemented with a transmit_text() for the pilot-ATC interaction. As far as disabling/enabling it, should probably be enabled by a switch like realistic radio on/off. Still regarding radio and ATC, I have a problem with the AI being told to switch to an arbitrary number freq by Ground after startup. After digging around, I had found what seems like an out-of-bounds array reading in dynamics.cxx : https://gitorious.org/~kantooon/fg/kantooons- flightgear/commit/c69c91769e15d550d8cff48aec09edbd2a562e7a This seems to happen when the airport has only one ground frequency. Could you please verify that my patch is correct? Cheers, Adrian -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Links for new FlightGear pilots
On 5 Sep 2011, Stuart Buchanan wrote: . One immediate question is how you see your changes being incorporated into to latex source code? Producing a nice PDF is quite important for a lot of people so I wouldn't want to lose that. On 5 Sep 2011, Peter Morgan wrote: . I still like Jomo idea of a flight school very much.. starting from the bottom up.. from a cadet to a commander, atc et all Certainly though, looking toward the future and more usage.. and more eyes.. we should plan for that, not only in printed media.. but in game help of ipods of a website browsing on an olde retired FG machine The main issue to consider is whether is actually a flight manual of now to fly an aircaft, or the simulation .. or both We'd need to make it original and copyrightable to every contibutor to make it 100% proof.. Thank you both very much for your interest and encouragement I have to admit: I did not yet look into the current release and update process of the getstart. Martin Spott mentioned that latex system about a year ago, but to that time I planned just a pure translation, and thus saw that as a minor problem for me. Especially I did not see a major dependency on a PDF-base for my German version. Till now I saw that relatively blue-eyed. Let me just outline my process-environment: One guy with NO budget and no records department, using a single PC running Ubuntu, all tools are Multiplatform, OS, no charge: - the HTMLs are made with KompoZer, a very nice and easy WYSIWYG HTML-editor - pictures are edited with GIMP - PDFs are made by: Open the *.html with LibreOffice Writer (former OpenOffice), convert the page-format to Landscape and push the PDF-button -- and that's it. -- see 2 examples of the output (just converted as is!): http://www.emmerich-j.de/Handbuch/EN/B3_intro.pdf http://www.emmerich-j.de/Handbuch/EN/B8_IFR.pdf On first sight those prints look pretty good to me. (The location/size of some graphics could be relocated/sized already in the source! Maybe even add header/footer or so - but all in all ??) I agree: That is a very-very cheap and dirty approach - I hope you can help me finding something more adequate - based on your experiences. I mainly hang on the following questions: 1) I am sure that most of our customers/users today rather read/search online in a WIKI and/or Forum - but I also see that some people still prefer a hardcopy to study. (Is there an additional requirement for a hardcopy for advertisement and or selling?) 2) What customers/users are we addressing? Till now I mainly address - the FGFS-newbies that want to learn - and the FGFS-users that want to look up or refresh some basics 3) Is the PDF just used for Hardcopies or also for Online-Viewing? - If just a Hardcopy the above primitive conversion could be tuned to be good enough -- but all the extended internal and external linking would be lost in the hardcopy! -- would we then need the old style Index at the end? That would be a major effort! - Or do we need Softcopy PDF's to distribute for local off-line viewing -- then all the links still show up correct - but look for a html file - not a PDF. So that links would have to be edited. Personally I would guess that would not be a big effort with todays find/replace possibilities. 3a) or would it be easier to distribute the Handbook as html in a subdirectory to $FG_ROOT/data/docs, instead of the now getstart.pdf? The security/copyright problems would not change, because everybody can copy also a central HTML via todays browsers! Those browsers even have no problem in directly printing the HTML (If e.g. a user wants only some parts of it printed)! Maybe (in some future) that manual could even reside (controlled) in the GIT and thus would be a compromise to the WIKI-process. Everybody could input at any time (in normal text) and the responsible guy integrates that into the Manual. Again: I have no experience in that area and look for help. One word to Copyright and so. After finding out how easy it is nowadays to just copy the HTML-source from a browser and change and sell it - I am worried what to do against it. Right now I guess I have some private protection as the originator. But surely I would like to put it (some day?) into the ownership of FlightGear. In some of the discussions here I noticed there are quite some lawyers around - maybe someone can advise what to do. (I hope such a document must not be GNU/GPL like: Free!). And no big hurry: I still have to review (links, spelling, wording,..)! End of the month I want to link it on may homepage - and am sure that will not be the end of my work! Thank You for Your interest joe -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your
Re: [Flightgear-devel] Links for new FlightGear pilots
Jörg Emmerich wrote: 1) I am sure that most of our customers/users today rather read/search online in a WIKI and/or Forum - but I also see that some people still prefer a hardcopy to study. From my perspective the difference between a Wiki and a Manual is not so much about the format of distribution, instead it's a matter of being more up to date in contrast to having a structured document whereas it would be preferred to have a structured document which is up to date :-) 3) Is the PDF just used for Hardcopies or also for Online-Viewing? Both ;-) BTW, given the fact how little support there is for building structured and consistent documentation for FlightGear I think it's really sad having two competing efforts, both targeting the same audience, instead of joining forces. More than a decade ago LaTeX was chosen as the source format for the Getting Started Manual for different reasons: First, the quality of typesetting in its formatted output on the printer or in PostScript/PDF was unchallenged in OpenSource land and it still is. As an additional feature LaTeX allows you to export the document into almost every format you could think of (and maybe even more), including but not limited to HTML and PDF. Last but not least, and this is a really important point, LaTeX allows you to maintain the document as if it were just source code. It's just plain text, it's almost as easy to write as HTML, it allows adding incremental changes, thus you don't have to load a large document just to fix a typo, it allows everyone to track these changes and submit their own changes and it allows easy versioning using the tools we already have. The Manual has been available via CVS and later via GIT for years - that's collaboration made easy for everyone who's concerned about it. you're guessing right: I'm seriously asking why we should drop our current Manual in favour of a different one which probably has the same amount of drawbacks, just different ones. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
On 6 Sep 2011, at 09:12, Jörg Emmerich wrote: Thank you both very much for your interest and encouragement No problem. It is great that someone is interested in the docs. Unfortunately I think you could have saved yourself a lot of effort if you'd posted 6 months ago :( As you'll see from my answers below, all the issues you raise have already been handled by The Manual. I really think you need to be thinking about how to integrate your changes with what we already have rather than reinventing the wheel. I have to admit: I did not yet look into the current release and update process of the getstart. Martin Spott mentioned that latex system about a year ago, but to that time I planned just a pure translation, and thus saw that as a minor problem for me. Especially I did not see a major dependency on a PDF-base for my German version. Till now I saw that relatively blue-eyed. I suspected that might be the case. Let me just outline my process-environment: One guy with NO budget and no records department, using a single PC running Ubuntu, all tools are Multiplatform, OS, no charge: So is the toolchain for the existing manual - completely free and multi-platform. - the HTMLs are made with KompoZer, a very nice and easy WYSIWYG HTML-editor - pictures are edited with GIMP - PDFs are made by: Open the *.html with LibreOffice Writer (former OpenOffice), convert the page-format to Landscape and push the PDF-button -- and that's it. -- see 2 examples of the output (just converted as is!): http://www.emmerich-j.de/Handbuch/EN/B3_intro.pdf http://www.emmerich-j.de/Handbuch/EN/B8_IFR.pdf On first sight those prints look pretty good to me. (The location/size of some graphics could be relocated/sized already in the source! Maybe even add header/footer or so - but all in all ??) I agree: That is a very-very cheap and dirty approach - I hope you can help me finding something more adequate - based on your experiences. Easy - use the toolchain we already have! I mainly hang on the following questions: 1) I am sure that most of our customers/users today rather read/search online in a WIKI and/or Forum - but I also see that some people still prefer a hardcopy to study. (Is there an additional requirement for a hardcopy for advertisement and or selling?) We don't sell a hardcopy of the manual but people do print it out, so it is a requirement. PDF fulfils this requirement for The Manual. 2) What customers/users are we addressing? Till now I mainly address - the FGFS-newbies that want to learn - and the FGFS-users that want to look up or refresh some basics That's about right and matches the manual. 3) Is the PDF just used for Hardcopies or also for Online-Viewing? It needs to be viewable online as it is delivered with the release and people read it on their computer. - If just a Hardcopy the above primitive conversion could be tuned to be good enough -- but all the extended internal and external linking would be lost in the hardcopy! -- would we then need the old style Index at the end? That would be a major effort! Indeed it was! The Manual includes a comprehensive index that we have kept up to date over the years. - Or do we need Softcopy PDF's to distribute for local off-line viewing Yes. We need both. -- then all the links still show up correct - but look for a html file - not a PDF. The Manual uses internal links. In the PDF they are links within the PDF, and in the HTML version they are HTML. Very simple. So that links would have to be edited. Not if you are using The Manual toolchain. Personally I would guess that would not be a big effort with todays find/replace possibilities. Yes it would. 3a) or would it be easier to distribute the Handbook as html in a subdirectory to $FG_ROOT/data/docs, instead of the now getstart.pdf? Is the Handbook the work you've done? If so - no. We would be losing a huge amount of function as detailed above, quite apart from any issues of content, grammar etc. Plus there is the whole area of long term maintainability. To be brutally honest we've already got a manual that represents a huge amount of work and maintenance and I would be loath to lose it. The security/copyright problems would not change, because everybody can copy also a central HTML via todays browsers! Those browsers even have no problem in directly printing the HTML (If e.g. a user wants only some parts of it printed)! Maybe (in some future) that manual could even reside (controlled) in the GIT and thus would be a compromise to the WIKI-process. The source Latex code, build tools etc are already under Git! (We have been working on this for a number of years!) Everybody could input at any time (in normal text) and the responsible guy integrates that into the Manual. We already have this and have integrated a number of people's changes over the years. The only issue we've had has been that
[Flightgear-devel] TaxiDraw
Hi All, Following up on the recent discussion about FlightGear's support program, I''ve been poking around in my old email archieve and found a note from David Luff, dated May 26, 2009. In this message, David is stating that among his projects for FlightGear, he's trying to finish the KLN89 code, has orphaned his AI code, and more importantly in this context: that he'd like to withdraw from TaxiDraw development, but was still willing to do one release. Since this is now more than two years ago, I decided to jump ahead and created a new TaxiDraw repository at gitorious, which you can find here: https://www.gitorious.org/taxidraw I've imported the complete revision history from CVS. At this stage, I haven't really made a desision about whether I should try to keep the CVS and gitorious projects synchronized, or whether we should abandon the CVS repository altogether. In the mean time, please have a look. Merge requests are enabled. Currently I m the only project member for the gitorious version, but would be happy to add more members. Cheers, Durk -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw
So shall we port it to QT then ? Im up for that.. gtk is a pain .. and much less pain with Qt... in my x-platform experience... pete On Tue, Sep 6, 2011 at 8:11 PM, Durk Talsma durkt...@gmail.com wrote: Hi All, Following up on the recent discussion about FlightGear's support program, I''ve been poking around in my old email archieve and found a note from David Luff, dated May 26, 2009. In this message, David is stating that among his projects for FlightGear, he's trying to finish the KLN89 code, has orphaned his AI code, and more importantly in this context: that he'd like to withdraw from TaxiDraw development, but was still willing to do one release. Since this is now more than two years ago, I decided to jump ahead and created a new TaxiDraw repository at gitorious, which you can find here: https://www.gitorious.org/taxidraw I've imported the complete revision history from CVS. At this stage, I haven't really made a desision about whether I should try to keep the CVS and gitorious projects synchronized, or whether we should abandon the CVS repository altogether. In the mean time, please have a look. Merge requests are enabled. Currently I m the only project member for the gitorious version, but would be happy to add more members. Cheers, Durk -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw
Durk Talsma wrote: I've imported the complete revision history from CVS. At this stage, I haven't really made a desision about whether I should try to keep the CVS and gitorious projects synchronized, or whether we should abandon the CVS repository altogether. I don't see why you should take the extra work to sync up both repos. First of all CVS is a PITA, compared to git and I don't see the benefit of further supporting it. Also, having the possibility of pull requests now on gitorious is a valuable improvement which might lead to the development of taxidraw gaining speed again. The same as with taxidraw should be done with terragear, which also lacks developer power and where quite some patches are scrambled over different places. Chris -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Emmerich.. maybe we need a new documentation plan.. so u start it in your mother tounge.. I thinks this agood idea as your have a determined mind and idea I think the best way is to write paragraphs in plain text and later we can all convert... This is better than tryiing to update the original as is a better plan.. IMHO.. at least u are movvayed to do this... and wish to help./// pete On Sun, Sep 4, 2011 at 4:31 PM, Jörg Emmerich j-emmer...@online.de wrote: Hi Gijs, thank you very much for that detailed and competent analysis in such a short time-frame. Let me comment the most difficult question first: Should it be a WIKI? My many links for further details see: WIKI... and also several articles from me in the FGFS/wiki should reveal me as a big believer in WIKI's, as well FGFS as also WIKIPEDIA. I even have extracted some parts of the current getstart.pdf and put them into the FGFSwiki (and just reffed them with a few words in the manual). And I do want to do more of those! That way I also hope to get the valuable WIKI-idea promoted to be used even more, which would get them more attention and thus more chances to get them updated in reasonable time-spans. On the other hand: I believe WIKIs have their very big advantage in unique details - not really in manuals! In my eyes each product does need a manual that explains the Basics to the customer and then shows him where to get more infos.(Yes: I belong to the people looking into the manuals when buying a PC, TV, Auto, etc.!). And that basics (in my eyes) should express the company's (i.e. FlightGears inner devel circle) involvement/direction/supervision! My concern is, that many small pieces may be able to replace a manual at the beginning - but over a longer timeframe they will change, specialize, and lose their connecting identities! See the Curtis opening problem! And also see todays WIKI: All the informations are there - often in multiple versions and/or with different focuses. They are fantastic for the guys knowing the basics and thus what to look for - but difficult to select what is needed by a newbie! Surely it will be a big effort for anybody to keep it updated to all future FGFS-changes! But I believe those are easier to control in one single document under the Development responsibility and a defined content in unique chapters - then when the content is distributed in many small pieces without defined ownership and/or responsibility. (Does anybody have the slightest idea how many WIKIS are affected by the latest 2.4.0 changes??) Based on that fear I tried to structure the Basics in some unique Chapters that contain more technical dependencies and those that are more for teaching and looking. So with a new version you do not need to update everything - and what needs to be updated is at one known location only - not distributed in many uncontrollable pieces! And still it would be relatively easy to convert that manual to WIKI - if needed! Right now I would vote against it! And yes, sorry: I have forgotten to mention the very useful forums - - I will correct that! One more hot item I would like to sell: Sidebars or drop downs I decided against sidebars because of: 1) I wanted that book to be without any need for executable, supporting sftw. like e.g. java (virus-prone) 2) I tried it with sidebars - but then it becomes again very confusing if headers are more than just one short word. I hate indexes like now in the getstart.pdf - where you have long headers going over several lines. I like my solution that allows long, ease readable titles -- and still have room for a nice picture to it! 2) There are still many customers with old tiny screens - I rather wanted that valuable side-space for big illustrations 4) Those top/sidebars become pretty much a standard for industries and business pages - I thought my way gives more the feeling of private pilot to private pilot (I just did not yet find a place for the beer-can!) So I came up with that top menu-bar that stays there all the time. From wherever you are in the text, you can always just select any part in the bar (including the current one) and have that index in an easy to read fashion. I know it is unusual and may be one more mouse-click - but I personally like that more private atmosphere. But I would like to hear more
Re: [Flightgear-devel] TaxiDraw
Christian Schmitt wrote: The same as with taxidraw should be done with terragear, which also lacks developer power and where quite some patches are scrambled over different places. Well, why did this happen ? As far as I can tell no patch submission was unheard. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
