[Flightgear-devel] =Idea for a an Enhancement Hi ! I would like to have some feedback about an idea for a FlightGear based project that I recently came up with. As the idea is not that easy to describe with one or two
sentences, I was recommended to present the idea on a webpage and ask on the FlightGear mailing list for other opinions - and that's exactly what I am doing now. In short: I am thinking about the possibilites to create an interactive training/lesson addon for FlightGear to illustrate topics such as navigation concepts by using FlightGear as backend. You can find more details at http://flitetutor.sourceforge.net feedback for FlightGear based application concept required Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi ! I would like to have some feedback about an idea for a FlightGear based project that I recently came up with. As the idea is not that easy to describe with one or two sentences, I was recommended to present the idea on a webpage and ask for other opinions on the FlightGear mailing list - and that's exactly what I am doing now. In short: I am thinking about the possibilites to create an interactive training/lesson addon for FlightGear to provide on the one hand interactive help for FlightGear's most essential features but also -even more interesting: to interactively illustrate topics such as navigation concepts by using FlightGear as backend. This project should be based on two parts: a player (to be loaded/running within FlightGear) and also an authoring tool to enable easy creation of the training modules for the player. You can find more details at http://flitetutor.sourceforge.net I am currently mainly looking for answers to some of the following questions: - is there demand for an application like this ? - how many people would actually want to use it (if available) ? - how feasible would it be to implement such an application with FlightGear as backend ? and for the developers among you: - is there anything like a general API in order to interface with FlightGear (either externally or as a plugin) ? - has anybody experience with writing similar extensions for FlightGear ? - is there a way to directly access FlightGear's client area (e.g. via PSL) to display custom animations ? - and of course: would anybody like to join the attempt to turn that concept into something useful ? (it's gonna be a spare time project anyway) For simplicity reasons, and also in order not to disturb the mailing list that much, I did also set up a basic forum on the same webpage - just in case this should be more convenient for some of you (there is no need to register in order to post) Any feedback is appreciated - thanks in advance ! regards Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
If anybody of you doesn't yet know what this is all about, please check: http://flitetutor.sourceforge.net (please leave feedback using the poll) First: apologies for the broken mail - I guess mozilla tried to send it as HTML :-/ Erik Hofman wrote: Boris Koenig wrote: I am currently mainly looking for answers to some of the following questions: - is there demand for an application like this ? I think there is. The responses so far seem to confirm that, by now there are 3 people who have directly contacted me and who would be interested in supporting this project actively - though only one of them having experience with C++ development . This could particularly be useful for the first couple of lessons for a PC-ATD. That's exactly true, I've also thought about similar applications, and I was also contacted by a CFI who suggested many interesting features relevant to PCATD purposes - amongst them: - realtime flight monitoring (possibly on a 2nd station) - flight recording and - evaluation - dynamically setting situations (weather, comms, etc.) Just to mention a few features, now I do realize that some of these things would actually be beyond the scope of FliteTutor itself, as they are rather reasonable suggestions for FlightGear itself. So, is there any bug tracker- or feature request tool maintained for FlightGear ? The todo list on flightgear.org doesn't seem to contain any user suggestions either? It also reminds people that flying isn't easy (which in turn might make it more fun for some of us ...) Yes, but regardless of that, an enhancement like FliteTutor would bring an entirely new level of seriousness to FlightGear. Also it would definitely broaden FlightGear's potential areas of application - and set it once more aparat from other games. I think FlightGear (most than any other simulator) is perfectly capable for this stuff. That's actually what I hoped to read ... but somehow the lack of documentation really seems to cause new problems - while the potential of FlightGear is certainly enormous, the probability that this very potential is also fully exploited is currently limited by that no docs-problem. The only problem might be that it requires more work to get it done (if new code needs to be added). I said already, I don't have any experience developing with/for FlightGear, that's why I was looking for some good pointers here, unfortunately the only way to go seems to be to read the source - that's a bit discouraging, to be honest. But the end result will be precisely what you are aiming for, since everything is open and accessible. I see, you are also indirectly suggesting to dive into the code ? I was originally hoping to find at least some kind of API to be used within FlightGear, the sources for such an API would have also been okay, writing all this stuff from scratch is an entirely different topic if you aren't familiar with the architecture. Anyway - so far, I have spent about 2 hrs reading the source to get a clearer understanding - now I know that I need to read the SimGear sources as well ;-) - is there anything like a general API in order to interface with FlightGear (either externally or as a plugin) ? There are multiple ways to interface with FlightGear. You mentioned only two of these multiple ways: are there any others that you know of ? I don't have any particular prefernce, I would use any method if it isn't too tiresome. Using scripts (Nasal code) The Nasal stuff sounds rather promising, and I've also checked out the /Scripting/ sub-folder in the sources for the particular implementation of the Nasal engine. Hoewever, I do have some concern regarding Nasal - Don't get me wrong: I am very much in favour of using a standardized scripting interface for my purposes, I think that's a lot safer than having someone foreign to the code -like me- poke around in the original source during the attempt to add features. But I wonder how feasible it would really be to use an interpreted script language for potentially time-critical things such as parallel processing of animations. Also, in the same regard I've checked out the available Nalsa docs and read that Nalsa wouldn't be threadsafe, this might be problematic when it really comes to have a Nalsa script process simultaneous tasks. But of course I don't know anything about the details of its implementation within FlightGear. Is there any example code available ? I looked at the files in the base package, some of these seem to make use of Nasal - unfortunately it is not really self-explanatory what's going on behind the scenes. So if anybody has any pointers on Nasal-it would be appreciated. Maybe there are folks here who have more in depth experience with Nasal an who can provide a basic outline of its current abilities and pitfalls. Then there's also the problem that I couldn't find a way to directly execute
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
Erik Hofman wrote: Boris Koenig wrote: If anybody of you doesn't yet know what this is all about, please check: http://flitetutor.sourceforge.net (please leave feedback using the poll) Boris, Erik, ;-) First of all, the documentation for Nasal can be found here: http://www.plausible.org/nasal/flightgear.html ya, thanks for that - but this doesn't seem to be complete - even though it's better than having nothing ;-) I could now start to collect and write down all questions that I still have regarding nasal interfacing with FlightGear, but I think that wouldn't lead to anywhere, so please take a look at the offer I made at the end of this mail. Secondly, I really think you are making things too complex. To clarify that I will need to explain the basics of FlightGear some more. FlightGear way of doing things is breaking it up into small pieces. There is (for example) animation code that reacts on property changes. There is also a Flight Dynamics model (FDM) that (amongst other things) updates properties. There is a menu system that can display and alter properties. Then we have sound code that plays sound based on ... properties. Maybe you see a pattern evolve by now. Yes, thanks for that Erik, and you are probably right in saying that I am making things too complex. But this is because of my lack of familiarity with FlightGear and its subsystems. That's exactly why I am asking all these questions - and answers like the ones that you've given so far are really tremendously helpful. So I hope to know now for example that nasal's lack of threadsafety is unlikely to become an issue, as not nasal itself would handle things like animations but rather a specific subsystem - that nasal would only access to provide the necessary parameters - correct ? All subsystems are almost self containing. Most of the time they only read the values of some properties, and sometimes they alter other properties. This is FlightGear's way of communicating between subsystems. As I don't know -yet- how to access FlightGear's subsystems from a language like nasal, I am currently definitely likely to indeed -reinvent the wheel- in order to resemble the beviours and functionality that I need. I do want to prevent that as well ! That's usually the problem if you don't have the necessary information available. So, I do appreciate you taking the time to clarify things a bit more for me. Nasal can also read and modify properties but it can also be incorporated into the menu system. Would you mind letting me know, which source files are responsible for the menu-access (like adding/removing items) ? So that I can look up the exact usage ? Because my current set of goals would then be to really drop the C++/PLIB idea and try to give nasal a go: This combination would allow one to design a menu system that: 1. pauses displays a dialog and pauses the simulator. 2. waits for the user to confirm the dialog. 3. alters one or more properties (change view for example) 4. starts the simulator again. 5. waits for a certain property to change 6. goto 1. ...for the nasal attempt to work, I would like to start by creating a simple script file which, when loaded by FlightGear, would disable subsystems like terragen (that aren't necessary at the current stage for FliteTutor) and continue adding custom menus to the FlightGear menu, in connection with the necessary hooks to be called when selected. I would then like something like that to become the basis for my FliteTutor coding attempts in nasal. I think this is already most of what you are looking for. You are probably right, but I would still need to know, what specific subsystem/properties to access (and what parameters to provide) in order for example to be able to do things such as: - load/display an instrument at a certain screen position - alter that instrument's properties - set its properties in a way that allows animation Just to name a few things, I guess you know what I mean. Available for your needs without any code touched. thanks, that's exactly why I am asking all that stuff What might be necessary is to code some hooks into FlightGear to (for instance) disable out of the window view when a certain property is set to false. yes, that's what I meant by adding certain interfacing possibilities - I think I will get back to you, as soon as the basic functionality for FliteTutor has been put on the webpage, in order to see what might need to be added. I hope you start to see the potential possibilities already present in FlightGear *now*. Yes, thank you for that - but: Regarding the FlightGear subsystems, is there any documentation available OR would any of the developers mind to give me some insight ? (this might also be done privately, I really don't want to disturb this mailing list) In exchange I'd love to present the provided information in a graphical way, possibly using UML or any other means to create relational diagrams. We could even feed
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
...if you need pen-pals subscribe to a mailing list ;-) Erik Hofman wrote: Boris Koenig wrote: So I hope to know now for example that nasal's lack of threadsafety is unlikely to become an issue, as not nasal itself would handle things like animations but rather a specific subsystem - that nasal would only access to provide the necessary parameters - correct ? Hmm, well yeah. Sort off ... I'm not quite sure why you still want code to be thread safe. I've got the feeling we're not exactly talking about the same issue. Probably you are right, I was just referring to this as an example because when I first read about nasal a couple of days ago I was under the impression that you would directly use nasal to *animate* an instrument.So, doing something like that in parallel with other actions, like processing a message loop to wait for user events might have been a problem. What exactly are you trying to do, create a separate program that runs portions of FlightGear in a (sub)window, or do you want to use FlightGear (the user would indeed start fgfs then) and add a menu structure that guides the user while flying? Actually, neither the former, nor the latter: What I want to do is actually be able to use FlightGear -and its subsystems- as a backend for a basic presentation system for (aviation related) - CBT / learning purposes. Hence, I would need to have pretty much full access to most of the subsystems - either using an API or the integrated scripting language nasal. It wouldn't matter if FlightGear needs to be running directly or if only subsystems get called. I want to be able to make use of a subsystem - either by calling it directly or using means like those that are provided via nasal. As the FliteTutor webpages don't seem to be precise enough on that yet, I am going to give a more in depth example, I would definitely appreciate getting your views about that. Basically, the following would be an example scenario for a beta - FliteTutor learning unit using nasal: 1) Run FlightGear - optionally providing a nasal script file as parameter - OR load that script file from within fgfs as soon as FlightGear has booted and is running. == This nasal file should then perform the following actions: a) disable (or not even load during startup) all those FlightGear sub-systems that aren't required by that specific FliteTutor module - i.e. the rendering of the outside view, and disable the things like the panel view. What we would then basically have is an empty FlightGear window (so, not even a panel !) b) draw some basic GUI components such as previous/back-buttons in the empty client area at certain coordinates - these controls would serve the purpose to allow basic CBT-like navigation within FlightGear. Also it might be - depending on the lesson- necessary to draw other GUI elements such as checkboxes or dropdown menus at certain coordinates. (Originally, I had hoped to be able to use the PLIB GUI functions for that purpose, but if these possibilites also exist through nasal bindings, all the better !) c) register specific events for these controls to be triggered for certain actions (like button [next] got clicked = do: next page) d) load a specified gauge/instrument from the FlightGear base directory (e.g. a standard VOR) e) display that gauge/instrument at a a certain position on the screen, optionally also set custom dimensions (as it would be useful to have a really large view of an instrument in order to illustrate its workings) f) display certain text (explanations) at a certain position - probably either close to the instrument, in a specific textbody (GUI-element) or even rendered as a separate layer above the displayed instrument in order to explain the instrument itself. g) register a message handler loop, that waits for specific events to be triggered - e.g. to allow monitoring if a user follows the CBT instruction to set the VOR OBS to radial 290 or not - based upon this validation the script could give a warning or even hint. = At this point we would be able to dynamically illustrate the workings of a VOR indicator by either automatically animating the instrument and displaying explanations OR by displaying instructions for the user to use/interpret
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
good morning ! Oliver C. wrote: On Tuesday 13 July 2004 00:25, Boris Koenig wrote: It wouldn't matter if FlightGear needs to be running directly or if only subsystems get called. I would like to have it integrated into FlightGear, so that the user can start the lessons from FlightGear in the Sim/Game menu. yes, that's also something I'd like to see ultimately, and I didn't mean to imply that FliteTutor should be run externally - just the way the actual interfacing takes place wouldn't be that important to me. But as I said already: IF Nasal can be used/extended for my purposes, I would love to use it. Using Nasal would really simplify many things- e.g. you wouldn't even need to compile yet another package to get FliteTutor to work - also, and even more important: I wouldn't have to mess around with the FlightGear code ;-) The lessons could then be picked up in a separate list menu or a menu where the lessons are organized by the required skill level or training tour (basic flying, VFR flight, instrument flight etc.). yes, it's good that you mention this here - you are the 4th user so far requesting some kind of categorization for FliteTutor units to take place. And we've made already some drafts for potential categories, some of which comprise: The two global categories: GROUNDSCHOOL or FLIGHT TRAINING (the difference MAINLY being the variying demands for subsystems to be loaded/running) Both gobal categories would then contain categories named VFR and IFR to separate lesson units. We could then add general categories such as Instrument Interpretation to the relevant sub-menus. This would be where the final learning units get stored - probably using a title and a short description to be displayed in some kind of quick-browser to get an impression of the outline of a specific unit. But regarding this categorization thing there were really plenty of ideas, some of which even suggesting a user rating for each unit, so that users can provide direct feedback to an author of a FliteTutor lesson-I really can't complain that there are too few ideas for FliteTutor ;-) It seems to be mainly a matter of getting the thing rollin'... Unfortunately, people keep contacting me privately be email in order to make such suggestions instead of directly using the forum or at least this mailing list ;-) - hence, it's likely that many suggestions are repeatedly being made, but so far I've written everything down that I received. But I would like to ask you to post your ideas and suggestions in the forum - that way we have them in a central place and everybody could see what's been suggested so far-there's no need to register in order to post anything in the forum. Also, as I mentioned already on the webpages, I am going to add those features most frequently requested to the features section on the webpage. if you want me to, I can go into even further detail :-) A webpage with example screenshot drawings with these step by step explanations would be nice. :) Well, what do you expect: the FliteTutor webpages are not even 4 days old... Actually, I meanwhile have indeed been contacted by some users who would be willing to help FliteTutor become a bit more than just a vague idea-a lot earlier than I had anticipated. So, we are currently about to collect all feature requests and connect them to our own ideas imaginations - and try to get a working draft for a concept. But this may still take some time. I am also going to send a notification to this list as soon as the first detailed draft for a concept has been finished and when we've put it on the webpage. Particularly, in order to get some feedback about the overall feasibility of all this. But due to the various feature requests that I've received so far, we will have to concentrate mainly on those features that are realistic to be implemented easily into a first coding attempt - which does not mean that anybody should stop sending in utopic suggestions :-) (But please try to use the forum, it makes things easier) Anyway, I do intend to offer some graphical representation of the goals behind FliteTutor - actually, also in order to make the whole thing easier to grasp and to attract those people to keep on reading who don't like to read ;-) Well, I hope it's now easier to understand what I would like to achieve with FlightGear. Yes. Glad to see, but now tell me HONESTLY: how thorougly did you *really* _read_ the webpages ? :-) BTW, i like the idea very much. ;) yes, thanks - strange thing being though: people keep telling me how much they like the idea but fail to leave a vote on the webpage- well at least during the first 2 days, now the situation has already somewhat improved ;-) It would be also very nice, if FliteTutor could be used for in flight lessons. You are again requesting something that has already been requested, and I do wholeheartedly agree with you, but personally I consider it unlikely to be added to a todo list that soon, cause I think
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
Ampere K. Hardraade wrote: On July 12, 2004 08:44 pm, Oliver C. wrote: For example a voice of a pilot instructor could be played that explains what to do next, like turning to heading 230. May be we can also have dynamic responses during a lesson, where the instructor can tell you things like too fast, too slow, too high, too low, etc. This is -again- a request that has also been made by other users, I would really like to ask you to *use* the forum - that way everybody would be able to see what's been requested so far and we could even introduce polls in order to see what's important to the community. It will be a good idea if we can find a text-to-speech engine to do the voice instead of using recordings. Not only will this save us a lot of space, but it will also be more flexible. lol, that's weird: I just wrote exactly that 2 minuts ago :-) There are various speech-synthesis tools for unix, the mentioned festival being the most prominent one - though I am not sure if any of these could be easily used under windows, but it shouldn't be that much of a problem, because the Microsoft Speech SDK is fairly simple to use - and one could easily write an abstraction layer that could take care of the subtleties for each TTS-system - but also operating system. If I remember correctly the FreeTTS can also be used under windows- gonna have to check it out, though. Just checked google - looks pretty good: http://linux-sound.org/speech.html and festival can be found at: http://www.cstr.ed.ac.uk/projects/festival/download.html regards - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Hi again ! I am just about trying to add some test-hooks to FlightGear, but wouldn't like to have to rebuild the whole FlightGear build tree each time (~ 350 MB ), just for 2-3 added small test-functions, hence I came up with the following idea: How about adding a sub-directory lib to FlightGear/data/Nasal which could then keep plugins that implement external Nasal functions ? That way one wouldn't need to rebuild FlightGear itself in order for a certain feature to be added and you could even keep code separated, in addition one would not necessarily need to have the whole buildtree available in order to implement a specific function for Nasal. And you could still optionally import that plugin code natively into FlightGear-if you want to- it wouldn't make any difference in the end. One would only need to implement some kind of simple plugin structure and a simple mechanism to load all libraries in a specific subfolder and check whether they export a specific Plugin-function - if they do, these functions will be made available as Nasal Commands. One could even go further and use the same technique in order to implement external fgcommands for FlightGear. What do you think ? --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands toFlightGear by using Plugins ?
Richard Bytheway wrote: Running make should only rebuild the parts of the source that have changed, and any parts of the source that are dependent on parts that have changed. You will always have to do the final link (20-30 seconds), but it shouldn't hit too much else. Ya, thanks for that - I know, but it's still 350 megs stuff that I need to keep on the drive, just for some minor changes ;-) Sorry, if I wasn't clear about that. Erik Hofman wrote: Boris Koenig wrote: How about adding a sub-directory lib to FlightGear/data/Nasal which could then keep plugins that implement external Nasal functions ? What do you think ? I don't particulalry like the idea. I'de much rather concentrate on imporving a FlightSimulator than on extening a scripting language. I agree -that was actually the very reason why I suggested something like that: *I* would take care of the plugin thing, so that *I* could easily add new Nasal stuff - and so I wouldn't have to bother you guys too much with my requirements anymore ;-) That way the number of bindings to Nasal are as low as possible which nakes it easier to use. I agree again, but there are some things that I would need to be added to Nasal in order to really be able to use Nasal INSTEAD of doing things _primarily_ in C++. And meanwhile, I've really come to the conclusion that I like the scripting approach - IF it allows for some more flexibility (see my previous postings) I realize there might be a difference between people who want a scripting language to do everything they need and people who don't want a scripting language except for some very specific tasks. Well, don't get me wrong - _I_ don't want Nasal to do everything, it's just that YOU suggested using Nasal instead of C++. I don't want to make Nasal a fully bloated programming language, but from what I can tell so far, there are about 6-10 additional commands that I might need in order to really be able to absolutely drop the C++ approach and concentrate on Nasal. So, my motivation is NOT to make Nasal bloatware, just to add things like support for : - dynamic population of statically defined panels/dialogs - simple file I/O (could be easily handleld by FlightGear itself - More advanced hooking techniques in order to allow for some simple dragging and dropping of instruments/dialogs within the authoring component of my FliteTutor concept. Regarding the latter, imagine a simple dynamic panel dialog editor that would be written using Nasal - this could even be integrated into FlightGear itself, users would be able to create panels dialogs by doing some dragging and droppinig of pre-defined FlightGear objects and this stuff would then be saved in a standard XML file using PropertyList syntax. I am leaning towards the later (for FligthGear at least). Yes, I can see - and this really wasn't meant to suggest Nasal should become a Visual Basic pendant within FlightGear - rather just for simpler adding of new functions/fgcommands. -- Boris P.S.: I've added a screenshot section to the webpage (http://flitetutor.sourceforge.net) to show what I've done so far (STATICALLY, using XML files) and what I'd like to be able to do on the fly with Nasal. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airports and basic.dat.gz
Luca Masera wrote: Hi, I've compiled the CVS version of FlightGear but now I've a problem with the airports. The program, every 10 seconds, writes on the console the following message: cannot find KSQL in basic.dat.gz I've downloaded the CVS version of basic.dat.gz. I've also the latest scenery created and I've found that, instead, exists a file named KSQL.bgt.gz that, I think stores the airport data. Why this happens? How I can solve this (I've to remove the file KSQL...)? I can confirm that behaviour exactly - did also recompile OpenAL/SimGear/FlightGear from CVS yesterday. Besides there occured some OpenGL problems (weird graphics) which I could only solve by disabling some rendering options such as --disable-specular-highlight Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Erik Hofman wrote: Boris Koenig wrote: By the way, the addition of a plugin architecture has pushed all major flight simulators tremendously forward, I don't even mention stuff like Microsoft's FS, but I suggest to have a look at X-Plane: Since the author added support for basic plugins, there are numerous projects to interface with X-Plane, some of them concentrating on multiplayer stuff - others on specific things like integrated preflight-support. By saying this you imply to be looking at FlightGear in a much too commercial way. Sorry, you are definitely wrong, besides: there are not only commerical AddOns to X-Plane. I really don't have any commercial intentions. If the source is open there is little need for a plugin system. Well, I've heard that argument several times now - and of course you are right in saying that one COULD directly modify the FlightGear source code in order to incorporate some desired functionality. But do you really want to have to change the whole FlightGear code for some specific functionality ? To get back to the swiss army knife-example: I do think that example becomes legitimate when it comes to very specific requirements or ideas, the only alternative that remains then would be to create a branch of the original FlightGear source in order to add some specific functionality-something I would personally never consider... This is another point: How about people who have suggestions (possibly even a bit extraordinary) but who like these features to be OPTIONALLY being available in all FlightGear versions ? Speaking of myself now: while I pondered about the pros cons for a FlightGear enhancement such as the FliteTutor concept, I would have really love to be able to do this via some kind of plugin structure. This also for the very same reason that we can currently watch here: people feel differently about certain features, enhancements or suggestions. And I do understand this quite well. Let's consider the FliteTutor example again: IF I really start the first coding attempts,I will very likely have to add some commands to Nasal - and I really wouldn't hesitate to do this directly into FlightGear's source, BUT what we have then is ONE modified version with, that some people might still object against to integrate into the real branch. Frederic is right that a plugin system is actually in contrast with the GPL (FlightGear's license), that requires everything to be opened when using some piece of GPL software within your project. I don't think that would be a major problem, there's other opensource (GPL'ed) software that makes use of modular enhancements (aka plugins)- the most prominent example being the Linux Kernel itself, whose plugin architecture meanwhile supports licence-validation - i.e. a module needs to provide the licence under which it is available in order to be loaded (This is a kernel 2.65 addition I think). Now you could argue that you will be opening up the source of the plugin, but I'm not so sure about others. Okay, that's a point - a point that hasn't yet been made. Personally, I really wouldn't have any problems about releasing any sources - except maybe, because of their lack of elegance ;-) But I think one could really find a solution for that problem, e.g. either by really making a plugin provide the licence under which it is available - and deny those plugins access, which do not specify an acceptable opensource licence OR by selectively maintaining an internal list (within FlightGear) of plugins that FlightGear would load (because they are opensourced). -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airports and basic.dat.gz
Erik Hofman wrote: Boris Koenig wrote: Besides there occured some OpenGL problems (weird graphics) which I could only solve by disabling some rendering options such as --disable-specular-highlight That must be a driver bug. I've also thought about something like that, that's why I ran at least 5-6 other openGL software: there were not any problems with the software, but when I then restarted FlightGear, it seemed as if the openGL buffer would not have been emptied, because FlightGear displayed a screen of tuxracer - which I had run seconds ago,in order to test the openGL stuff. So, I am also about to think that there are some driver problems under certain circumstances, hence I will run the the FlightGear cvs version on another computer: but that's gonna require RECOMPILE :-/ The only thing --enable-specular-highlight does is enabling a hardware option (if available) that enables specular reflections on textured objects. well, I could disable it again and see if the same problems occur, and if they do I could see whether these are visible within a screenshot... Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Erik Hofman wrote: Boris Koenig wrote: Frederic is right that a plugin system is actually in contrast with the GPL (FlightGear's license), that requires everything to be opened when using some piece of GPL software within your project. I don't think that would be a major problem, there's other opensource (GPL'ed) software that makes use of modular enhancements (aka plugins)- the most prominent example being the Linux Kernel itself, whose plugin architecture meanwhile supports licence-validation - i.e. a module needs to provide the licence under which it is available in order to be loaded (This is a kernel 2.65 addition I think). I'm still not convinced that a plugin system would be such a great idea for FlightGear. Well, I am just making suggestion :-) The project has outgrown C and even C++ by using some clever subsytem architecture and by using the property tree. Well, regarding the clever subsystem architecture - is there any more detailed information available ? Also, I have browsed the property tree and read all the docs about the property tree that I could get my hands on, but didn't find any details regarding how to disable subsystems like the FlightDataModelling, (in order to provide some instrument familiarization there would not be any need for such stuff be running in the background) Adding new code is quite easy, but by introducing a plugin loader we would be put right back into the C world, using structures to pass variables around. I think you are probably right in saying that FlightGear is already extremely advanced, but adding features by the means of plugins could also be done using some kind of higher level mechanism. But okay, this isn't that important right now. As I mentioned above: I am merely making suggestions. Besides, most everything can be done in FlightGear without touching any code. Only special cases or additions need to be coded in C++. That's exactly why I would _actually_ love to use the Nasal approach, though things like XML-handling might still be necessary to be added. And I'm still not sure whether your flitetutor isn't outgrowing FlightGear's purpose. it isn't meant to do so - it's should be merely an enhancement Adding a basic, menu accessible Flight Tutorial is probably in line with the project, Currently, this would be ONE of the supported modes that FliteTutor should be able to work in. By the way: there doesn't seem to be PUI-PopUp menu supported within the XML resources: how likely is it, that things like these could be added ? but moving instruments around and even panel design within FlightGear is out of scope of the program I'm afraid. Yes,regarding that argument you are probably not entirely wrong, if you remember my original plans for the whole thing (which are also still available on the webpage, I think) you'll notice that I had originally planned to develop the authoring component using QT - OUTSIDE of FlightGear itself. Simply BECAUSE OF things like interactive dragging dropping of components. While the player would be integrated within FlightGear - possibly as a set of Nasal scripts. But again, things like dragging dropping of panels would already be one of the more advanced features and is not really considered realistic to be implemented in the near future. I would love to hear other opinions about that though. You are actually about to give pretty good reasons for a plugin architecture by implying that the FliteTutor concept is a bit too special - and as I mentioned above, I do somewhat agree with you, at least regarding these more advanced features - and I haven't even yet mentioned those other utopic suggestions that I received ;-) The options that I would be left with in such a case would really be mainly: - either grab, understand and modify the FlightGear sources in order to start a branch which supports the necessary additions (unlikely to happen !) - at least add dynamic Nasal extension support by the means of plugins in order to be able to call some more advanced Nasal commands So, my intention would definitely be to make this whole thing GENERALLY available - I certainly wouldn't start to create my own FlightGear version just for some learning stuff to be integrated. I wouldn't have a problem, creating the authoring part of the application as an external application - but THEN I would need to be able to load FlightGear resources (aircraft/images/panels). - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Erik Hofman wrote: Boris Koenig wrote: Well, regarding the clever subsystem architecture - is there any more detailed information available ? It's actually quite simple, you create a derived class from SGSubsystem and you have to define a small set of functions: Thanks for that (REALLY !) But actually I was really asking WHAT subsystems exist, how they are called (names, not programming !) and what their purpose is. I indicated already a couple of days ago, that I wouldn't mind writing some documentation, and I think these details are still missing, one could even present such information in a graphical way (as I mentioned already) Later, one could add the properties that affect a certain subsystem. I think this would really make for some good introduction into FlightGear developing, I would certainly find it easier to dive into the code if such things were generally available. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTuror (Was: Adding external nasal bindings fgcommands)
Erik: you are causing some trouble over here, actually I didn't want to
change the project's sourceforge name, but I appreciate you taking the
time to make even another suggestion ;-)
Erik Hofman wrote:
Boris Koenig wrote:
I wouldn't have a problem, creating the authoring part of the
application as an external application - but THEN I would need
to be able to load FlightGear resources (aircraft/images/panels).
Ok. Lets start a *minimal* list of items that really are needed for this
and skip the implementation part for now.
Okay, no problem - so you are now only talking of the Player
part, right ?
This is what I think what would be needed (feel free to add your ideas).
okay, then I'll write down those things that I'd like to be able to
do *interactively* using Nasal (i.e. don't want to rely on static files)
* A configurable, interactive menu system.
yes, this could easily be done by making the menu system available
via a set of nodes in a corresponding property tree.
*But this is currently NOT essential* - the menu(bar) itself is less
likely to be changed that often - compared to other GUI elements.
So, I would not even add it to the minimal list right now - but IF
it gets implemented it would make sense to add some kind of
Nasal function to globally register Nasal based addons, that way
I would not have to use a certain Menu named FliteTutor but rather
could register FliteTutor to be loaded within a menu called Addons
or something like that.
* The ability to load a set of sheets, one after each other.
right, I have looked into the sources and think that should be also
possible to be achieved using some specific node in a property
tree (I gave some examples in one of my last eMails).
What I am now using - for testing purposes is:
/addons/FliteTutor/player/pages
and
/addons/FliteTutor/player/currentpage
While the former is an object that contains all necessary properties
for a specific page, like:
pages[0]/position/x
pages[0]/position/y
etc.
And the latter property specifies which of the pages in player/pages
is currently being displayed and hence should be read from the prop tree.
(Since, I don't yet know how to save load this stuff using Nasal, I am
setting it up each time in order to have some stuff available)
* Be able to add the following to these sheets:
- Dynamic text at a static location (*)
...also DYNAMIC positioning - this could be also implemented using
a specific node in the property tree.
text = setprop(/subsystem/../createTextWidget,1);
setprop(text,position/x[0],100);
setprop(text,position/y[0],200);
and if possible, some simple formatting would also come in handy-
like 2-3 different font sizes, BOLD and UNDERLINED text:
setprop(text,font/format/size[0],LARGE);
setprop(text,font/format/bold[0],1);
This would probably already be sufficient regarding font handling.
- Static images (*)
yes, images won't get created on the fly, for any other dynamic
image based contents I would make use of animations.
But it would be useful if I could not only specify their
position in some XML file but rather do this dynamically -
I think I did also provide a pseudo (nasal) code example
in of my last mails.
Something like:
//Create Image
img = setprop(/subsystem/createImg[0],1);
//file
setprop(img,filename[0],sample.gif);
/*OPTIONALLY, it might be useful if I could directly provide a
binary or hex-encoded buffer to that function, in order to
enable storing of images WITHIN a XML file:
image type=JPEG name=drawing
0xFF,0xFF,0xFF,0xFF,0xFF .
/image
And load this then by doing the following in Nasal:
readXML = func {
// function to retrieve contents of a section within a
// particular XML file
}
data = readXML();
setprop(img,buffer[0],data);
Even though that's not particularly elegant,
it would enable EASY exchange of modules, since
these wouldn't have any external dependencies
but could rather store all resources (e.g. images,
sound) within a module, EVEN if these are binary.
*/
//Position
setprop(img,position/x[0],100);
setprop(img,position/y[0],200);
//Dimensions
setprop(img,dimensions/x[0],100);
setprop(img,dimensions/y[0],100);
- Animated instruments that react to actions of the user(*)
yep, as well as being animated by the player - for illustrative
purposes, but this isn't a problem I think, as I got an example to
work already.
But again, I don't want to rely on external XML files :-)
* Pop-up screens to guide a user.
right, I'm currently using a statically defined dialog with
a fixed width, what I considered being useful AND powerful
(also for FlightGear itself!) would be a template based
dialog
Re: [Flightgear-devel] Advertisements on the FG web site?
Good morining, just dropping in from one of the other timezones ;-) I've also got some thoughts regarding this whole sponsoring idea, and to be direct: I do have to admit that I wouldn't have any problems with such a model, actually it's just a couple of days ago that I talked to other FlightGear users about similar ideas - indeed, even exactly the one mentioned by Curtis: having a company that sells flight simulator peripherals advertise on FlightGear.org - or even: -*now*, I know you guys are going to call me a pervert: ;-) WITHIN each particular FlightGear release, so that discussion - while being held privately - it was caused by Curtis' mail regarding FlightGear financing. Among these ideas I also suggested to set up some kind of BugZilla system or anything else for that matter, that supports feature requests by users and directly link such a system to some simple donation system, that way it might be pretty easy for users to make small donations like $ 5.00 and assign or even SPLIT their donation to certain feature request, e.g. users would want to to be able to say: I vote for feature request X by giving 2 bucks of overall 5 bucks donation to it The developers could then see which feature requests seem to be most urgent and also (financially) SUPPORTED by the community. Of course this whole thing would still be only OPTIONALLY available, but I do think that something like that might work - in particular if you think about features that professional users might need. You could even go one step further by offering companies to make custom adjustments to FlightGear, maybe even offer manufacturers of simulator peripherals to add support for their hardware to FlightGear - either provided they give out some samples or simply financially support FlightGear. Getting back to the X-Plane example that I mentioned meanwhile in some of my posts: the author of X-Plane is doing a great job in that regard, by offering specific customization - the result being that X-Plane is now also used by some MAJOR aviation companies for _serious_ work. And now, I do of course remember the argument being made that FlightGear is not supposed to become everybody's swiss army knife, well I think as soon as there is financiall support involved it would be perfectly acceptable - in particular if parts of the necessary work could really be directly used for FlightGear itself, so that other users might benefit from it, speaking of adding support for certain simulator hardware, this would definitely be the case. I *suppose* FlightGear developers could also easily adapt FlightGear in a manner to allow more extraordinary features, this also to attract even another target audience - professional users. So, getting back to FlightGear, I do think it is quite a good idea to advertise for such companies or products which might directly benefit a FlightGear user, simulator hardware stores OR EVEN -manufacturers (!) are certainly in that range. And also I do agree that there should of coure be some previous experience with the hardware being offered BEFORE anything is recommended, just to make sure that people aren't buying stuff that e.g. isn't even supported under linux. Also, I like the idea of samples being sent in in order for FlightGear evaluation. Of course there should be remarks added to those products currently not being sufficiently supported by FlightGear, maybe based on the referrer id to the company's page or anything like that. But all visitors from the FlightGear pages should definitely get the necessary information, possibly they should really use the referrer information in order to display certain additional information. That way you could prevent users buying stuff (also with the motivation to HELP FlightGear)just in order to learn later that the stuff they purchased doesn't even work with FlightGear. THIS would of course be extremely frustrating and should be prevented by all means. So, if the said company itself is not willing to send out any hardware BEFORE there are purchasements being made, they should be asked to do the necessary examination and test the hardware themselves, in order to verify if there are any problems with certain hardware components. Getting even more extreme, one might ponder about offering that said company to integrate their webpage address or even company logo directly into some of the future official FlightGear releases. I am sure simulator hardware company would be interested in a deal such as that one. Also, I do remember that X-Plane itself displays CHPRODUCTS' and NVIDIA's internet addresses during startup...I would really doubt that the author doesn't get anything in return for that ;-) But I am not even talking about modifying FlightGear's splash screen in such a way, even though personally, I really wouldn't have any problems with anything like that at all - I understand that this is an opensource project and that there needs to be financial support: for an egoistic user it's all
Re: [Flightgear-devel] Advertisements on the FG web site?
Erik Hofman wrote: Boris Koenig wrote: Getting even more extreme, one might ponder about offering that said company to integrate their webpage address or even company logo directly into some of the future official FlightGear releases. No, No No. Never. This is not going to happen. lol, didn't like the idea that much either ;-) But on the other hand I followed the whole discussion about FlightGear financing and had to notice that most people simply tend to object against any suggestions that are being made, INSTEAD of making better suggestions themselves. I do understand that there are some strong feelings involved in the whole issue, but then again, I also see MANY of the other _BIG_ opensource projects really relying on such kind of income. And all this can still happen on a volunteer basis. So, please understand my views about that correctly: if it was my call, I wouldn't WANT to make the decision either, simply because of all the hassles AND also the potential change of perception, involved. But as a USER I perfectly understand that some kind of income needs to be made, either the one way or the other. Even if the the whole advertising idea should be dropped (which _I_ would not recommend: one should *FIRST* give the whole thing a try !), I would still suggest to at least set up a support/donation-specific set of pages on FlightGear.org - possibly even involving some kind of feature request bidding system (which I suggested in my last mail). While objecting against such changes is pretty easy (and I repeat again: I don't like most of the stuff either), one should take into consideration that the project itself might suffer by such decisions, simply because of the inflexibility of the decision makers or community in that case. Just think about the possibilites the FlightGear project could have if there was at least some kind of financial basis. SO, instead of taking my mail apart and telling me what's NOT going to happen it might be more helpful for the final outcome to make new suggestions - which in the end, might be helpful for the final outcome, *I* certainly wouldn't mind if FlightGear is being kept AD-free and all the idas I mentioned so far are ignored, IF anybody of YOU can make an even more acceptable suggestion it would be ALL THE BETTER ! (Just mentioning this because of some private mails that I've received meanwhile) ;-) - Boris - no affiliated with any simulator hardware vendor - :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Advertisements on the FG web site?
Erik Hofman wrote: Boris Koenig wrote: SO, instead of taking my mail apart and telling me what's NOT going to happen it might be more helpful for the final outcome to make new suggestions Not really. If you have spent the amount of money on FlightGear as I have done then you may make any suggestion you like. yes, I suppose that argument is indeed legitimate in your case, and probably that's true for most developers actively being involved in the FlightGear project. _But_ if you read the whole paragraph again, you'll see that I wasn't referring to you by that particular comment, but rather some folks who -OBVIOUSLY- have some very strong feelings about FlightGear and the opensource philosophy and consider my *ideas* the embodiment of the devil - some of them really seem to confuse the opensource philoshopy with communism ;-) Until then I may say what I like (and don't). Absolutely legitimate I think, even though some people tend to forget that this whole issue is not about unpopular views of a minority but rather about making unpopular decisions in general. The latter being something that most project leaders or even company leaders usually have to do on a daily basis, not because they like it - but because they need to keep the eye on the ultimate outcome of a project. I did already imply, that I personally would also love to see opensource projects in general not to have to rely on any external funds - but this is not that easily arranged. You would really have to start merchandising for FlightGear in order to create the necessary financial backbone. For now I would like to keep my suggestions for myself so maybe I can get some money back, actually, we are probably talking about the same things here, or at least a very similar motivation: decreasing the burden that's being put on some few people by a project like FlightGear. And this is also about financial issues, you seem to know that quite well from your own experiences. Having a paypal account myself, I probably really wouldn't mind to make a small donation every now and then. If I even had the opportunity to assign my donation to certain feature requests, it would be even better. instead of some bozo who just noticed the existence of our project This is really getting funny - I didn't expect to have that much fun here... (No I'm not referring to you in this case). Thanks, that's really nice :-) But back to the original topic: I haven't though yet about that point, but honestly don't think that there'll be ANY people -expect people- directly benefitting from such an arrangement, so talking of your new bozo: he would certainly have to put __*MUCH*__ work into FlightGear before being able to make legitimate claims in that regard. So, I really wouldn't worry about that point yet. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Advertisements on the FG web site?
Erik Hofman wrote: Somebody who types faster than he reads wrote: Thanks, that's really nice :-) In case you didn't notice it, I really wasn't referring to you. Well, thanks for the explanation - but I guess I understood you correctly :-) The only problem I have with you, is that you say too much (long posts) :-) Ya, I see - and somehow even gotta agree ... having meanwhile tried to summarize the Nasal extensions that I would *minimally* need, shows quite well that I really should stop sending these lengthy mails out :-) But hey Erik, you know what ? I'm gonna send you my mails as a tarball attachment ! :-)) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Advertisements on the FG web site?
Norman Vine wrote: Boris Koenig writes: Ya, I see - and somehow even gotta agree ... having meanwhile tried to summarize the Nasal extensions that I would *minimally* need, Hey I've got an idea ! I am listening ;-) Why don't you commission one of the FlightGear developers to write the extensions you seem to *need* and pay for it with advertisement revenue from your site :-) lol, it really seems that I am making a very commercially oriented impression on most folks here: Well, thanks for that idea, but on the one hand _I_ don't *need* a certain extension, but rather would like to be able to extend FlightGear itself in a way to make it useful for even a broader audience. On the other hand I mentioned already that I would probably be able to customize the original FlightGear sources myself, of course that would take some more time - but this is then also something I wouldn't want to do, because I was a) told it wouldn't be necessary to make many C++ changes myself, and then also that b)some of my additions would be unlikely to get accepted for an official release, simply because of objections against blowing Nasal itself more up. But, *if* I should really start implementing the stuff, I'd of course want the whole thing to be officially available within each FlightGear release. Also, you don't seem to have read the whole FliteTutor webpages: this is not about some kind of commercial idea, rather it's currently merely about a *CONCEPT* for a particular extension, that -should it achieve implementation level- would still be supposed to become opensource (see the FAQ). So, I don't have any financial intentions whatsoever, nor do I plan to put ads on the sourceforge webpage, and by the way I HIGHLY doubt that would create _any_ revenue at all - the most visitors (not hits) I've had there so far, were 50 on one day, currently I am at most at a dozen a day. So, taking all these into account the FliteTutor idea itself would certainly not put me into the position to make any significant (financial) contributions to FlightGear. ;-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Frederic Bouvier wrote: Norman Vine wrote: Perhaps merntion of this should be made as a 'dependenciy' then on http://www.flightgear.org/Downloads/source.html Sorry Norman, but I don't understand. FlightGear does not depend on fgrun. It is just in the Win32 binary package since 0.9.3 and probably in several Linux packages as a bonus. runfgfs and runfgfs.bat are still generated by configure in the source package. Anyway, the website could mention flightgear related projects but I presume there was not so much lobbying for this from their authors. If I remember correctly there IS a specific section on the webpages, at least that's what I think. Wait ... Ya, while it cannot be found under related projects those other projects are mentioned on the links page: http://www.flightgear.org/links.html I'd also suggest to separately maintain such a listing, this could be also done via some kind of basic CMS - if there aren't any other volunteers I really wouldn't mind to ocassionally update such a section. I think it's really a good idea to have a central place for all FlightGear related software, that way you would also make things easier for new users who are just trying to start getting familiar with FlightGear - they would only have to look in one place. We could add a small description with relevant remarks and have some small table for all the 2nd party stuff that there is. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some problems that I have ran into with the latest CVS
Jacek wrote: I don't understand morse code so can't compare anything. Regards Jacek S = ... F = ..-. O =--- :-) But regarding that matter, I had to notice that the speed of the morse code has somehow changed, also it's being played permanently it my cvs built during startup. Trying to mute it, doesn't work either - it only mutes the engine sound. While I think that it does make sense to separately mute things like engine radio/comms I would have actually expected to mute EVERYTHING by checking the heckbox in the sound config panel. Also, this sound config dialog also shows the same behaviour as all the other dialogs do most of the time: options that are changed while the game is PAUSED are ignored. --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] I just crashed FlightGear using a dialog definition file / Nasal
There seem to be some issues regarding the XML file processing and FlightGear's stability: # Nasal parse error: empty subexpression in command, line 3 # Failed to execute command nasal # Segmentation fault One problem seems to be related to using combo boxes with insufficient width - but I've encountered similar problems using other PUI controls via XML files, though not all leading everytime to a crash. Interesting though, the problem does not occur if there's only ONE value element specified for a combo box. Even though, I don't thing this is really critical - as only few users are ever going to create their own dialogs, I thought I should mention it here-this is just a downstripped example with only the combo box and a close button being present. I've attached a simple dialog file that shows the mentioned behaviour in my (2 days old) cvs build. You'll have to put the crash.xml file into FlightGear/data/gui/dialogs and add a simple dialog-show command to the menubar.xml file in order to call it - you can do this while running FlightGear, but you will have to reload the GUI (menu DEBUG) in order to reload the necessary bindings. Please report if anybody else encounters that problem. --- Boris ?xml version=1.0? !--Just a demonstration -- PropertyList namecrash/name x400/x y100/y width150/width height100/height modalfalse/modal combo x10/x y50/y !--The width seems to be critical-at least if there are strings to be added which are longer than that -- width10/width height25/height valuetest/value !-- The problem occurs with only one single value being specified -- valueanother test/value /combo button x10/x y30/y legendclose/legend bindingcommanddialog-close/command/binding /button /PropertyList___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Erik Hofman wrote: Innis Cunningham wrote: It is quite possible that the new graphics card/system is not set up for FG.I will have a play with it and see if I can improve the situation.I think anisotropic filtering is on. The point I was trying to make is people trying FG for the first time will be dissuaded from using it because of the poor performance. As you yourself said it is disappointing to spend money on upgrading only to find that the sim runs at the same speed if not slower. With the price of computer hardware getting cheaper all the time I would think most people who are going to use FG would have reasonably new hardware. Well, if we turn all that off, people start to complain that FlightGear looks like crap and will search for something else. At least now they start asking questions ... Then how about optionally offering to disable such things in the (advanced) rendering options dialog ? - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Richard Harke wrote: On Saturday 17 July 2004 07:08 am, Innis Cunningham wrote: I had a GeForce 2 Titanium with a PIII Xeon at 550MHz getting about 15 fps over SF Video card crapped out (even has a red LED come on to tell you it has crapped out) so I bought a Geforce FX 5200 Frame rate dropped to 4 in same circumstances. Occasionally up to 6. I already had plans to upgrade so I didn't panic New system is P4 at 3.0 GHz with 1MB cache AGP runs at 8x So now my frame rate is back to 15, though it does jump into the high 20's sometimes. Same copy of the executable in all cases. (CVS from mid Feb) This is rather disappointing, to be honest. I think there IS a point to it, because I've made very similar and *weird* observations, running on a pretty decent system with a nvidia card, you would get about 15-20 (the latter rarely) FPS, while taking the same CVS stuff to an OLD system ( 1 GHZ, 1 GIG RAM, ATI RAGE128) gives usually even more than these 20 FPS, as I am currently trying to summarize which subsystems I need and which of these can be disabled I have also made the following attempt: - disabling pretty much all rendering stuff - = now having an empty FG window - show the framerate THEN On my (decent) main system I keep getting not more than 30 FPS, while I do get around 50+ FPS with my old ATI RAGE 128 in such a mode on the other system. So, yes - I do think there are indeed some performance issues related to the openGL stuff. And I agree it's pretty disappointing to see the game @ 15 FPS on a system which usually provides up tp 80+ FPS in other games/openGL stuff. And I really don't think that FlightGear is making THAT much use of the GPU ?! Either it's really about some specific GPU options not being enabled or made full use of or there are some other _real_ problems ? Hence, it might really be a good idea to temporarily offer disabling of more advanced rendering features or even texture-rendering in general, personally I wouldn't care that much - and I agree with Erik, that most of the texture stuff gets pointless when you are IMC. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Erik Hofman wrote: This is the penalty for those who want eye-candy. If specular highlighting is supported it will be enabled an make FlightGear slower. I noticed some enhancements in the new rendering dialog, and would like to ask how feasible it would be to integrate even more performance-related options into that rendering dialog. (see my other posting) So, generally I am talking about the rendering options that one can already provide via command line. It might be really useful if you could change these while the game is running - just for every user to be able to achieve a reasonable frame rate, this is just because I also noticed some decrease in FPS with the latest CVS built - and would like to be able to find the best configuration directly within the game. We could even introduce some basic kind of rendering profiles, using comboboxes users could define their profiles and switch the profiles on the fly. Just a thought, though ... By the way: I noticed that the feature request/bug report options at sourceforge were being used at some time, is this still being maintained or at least looked at regularly ? Because, otherwise I would really suggest to separately install some kind of feature/bug database at flightgear.org - just drop me a line if you need help doing that. :-) --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I just crashed FlightGear using a dialogdefinition file / Nasal
Frederic Bouvier wrote: What do you want to prove with a field so narrow ? I don't want to prove anything, that was just an example - e.g. I encountered the problem when I created controls whose width was insufficient for the string to be displayed. And that's exactly what I pointed out with mail. that neither FG nor PUI are protecting themselves against negative values ? well, if you want to put it that way, but actually this was at most about a crash that I encountered frequently. By the way, yesterday it locked even up the whole system... Combo arrows are 16 pixels wide, so the input is -6 pixels . ( The width is not in characters but in pixels ) thanks for the explanation, but I was aware of that. And NO, this problem did not only occur with a width specification of = 16, but rather = 30/50 - the latter is unfortunately not permanently reproducable (that's why I chose to provide 10 and not the other values) The only reason why I actually posted this bug to the mailing list is indeed, that I don't think something trivial such as dialog definition should be able to crash the whole application. EVEN though the actual usage of such a dialog definition is pretty unlikely (as I stated before). And I think, I *did* mention that this is certainly not a critical bug, because few people will ever create their own dialogs and even less would use such values - but I found it by accident and NOT to prove anything, if I wanted to _prove_ anything I would now start to look for other problems related to this, for example in the panel handling stuff. height25/height valuetest/value !-- The problem occurs with only one single value being specified -- valueanother test/value No problem with either one or two values, when the combo width is set to 100. sure, but that wasn't what I asked :-) Don't have any problems with a width of 100 either ! You seem to get me wrong here , you know, I am not posting this because I was specifically looking for bugs in FlightGear, but rather because I wanted to create a SMALL combo box (width 50 pixels) for one of the dialogs that I am currently working on - so this all happend by accident. And as it seemed reproducable I thought it should be mentioned here - NOTHING more. regards -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RE: Help 3D model about FlightGear.
Innis Cunningham wrote: Hi All If John is using AC3D 4.0 then there is a problem using those models in FG.There is a crease statement that FG/Plib can't handle.So to get around the problem you either have to text edit all reference to the crease statement in the AC3D file (tedious) or build the model using AC3D 3.6 or earlier.I have gone back to building the models in 3.6. You could easily automatize these steps with one or two shell commands, but if the current workaround is to simply remove all references to crease, then how about simply accepting the crease statement programmatically but ignore it during execution ? This shouldn't be too much of a change ?! And that way one would at least have a hard-coded workaround, so no new problems with that issue and everybody could keep using AC3D. In the meanwhile the thing might be noteworthy within the FlightGear docs, though. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some problems that I have ran into with the latest CVS
Jacek wrote: Do you really distinguish those ... and ---? ;-) Well, to be honest only since just recently - there are some fairly decent morse code training applications available, so if you keep hearing the same stuff for an hour a day you start to get it one day ... But it's the same problem with a n ... As to the dialog check boxes I've just checked out a few: PAUSED morse engine is playing no is mutedyes show frame rateyes enhenced runway lightingyes Sun/Moon horizon effect yesclouds coverage yes time of dayno (yes=I can change to opposite state, no=I can't) yes, it's somehow a bit irregular - you CAN stop the morse code directly by unmuting everything and the re-muting the whole application (must not be paused then !), I guess the morse-stuff simply doesn't take the mute status into consideration yet - at least not during startup. Also, the properties dialog doesn't seem to get automatically updated (if openend !) when one changes the properties via the telnet/http interface. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I just crashed FlightGear using a dialog definition file / Nasal
Andy Ross wrote: Boris Koenig wrote: There seem to be some issues regarding the XML file processing and FlightGear's stability: #Nasal parse error: empty subexpression in command, line 3 #Failed to execute command nasal #Segmentation fault The XML you posted contains no Nasal script, so I'm at a loss as you how you are producing this crash... Sorry, as Frederic pointed out already the whole issue is not about Nasal itself or the XML-handling but rather a problem in PUI, I mentioned Nasal only because the error message above is exactly what you receive _mostly_ from FG when trying to deal with insufficiently sized controls. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Inserting Disturbances
sonny hammaker wrote: how about through a command line? start fgfs with the telnet daemon, that way it should be possible to easily access most of its internal properties via a simple telnet client - so you could then easily: cd environment/turbulence at set the corresponding values there. Alternatively, you could also give the intergrade httpd a try, this might be easier for people who are not familiar with CLIs. --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Inserting Disturbances
Frederic Bouvier wrote: sonny hammaker wrote: how about through a command line? --turbulence=value --wind=wind-desc-with-gust --random-wind see fgfs --help --verbose but these aren't meant for runtime control of the environment, are they ? Or is there some kind of IPC between running instances of fgfs ? I thought he wanted to have runtime control over these values. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender question for FG modellers: AC3D export and materials/textures?
Chris Metzler wrote: On Wed, 21 Jul 2004 10:18:25 -0400 David Megginson [EMAIL PROTECTED] wrote: Correct. Currently, the AC3D export scripts in blender do not export specular, and emissive parameters, and they probably do not handle diffuse either -- you have to add those back in by hand in the AC3D file. Ugh. Indeed, that doesn't sound like fun to do ... but Blender does have a pretty active community, and if I remember correctly things like file exporting/converting are done using a subset of Python as scripting language, hence one might be lucky mentioning these requirements within the Blender community, possible one could find someone who knows how to easily add the necessary options to the relevant Python scripts. Otherwise, you could also attach the native blender file and the exported AC3D file to your next posting, possibly one could automatize the task by writing some small shell script, but I really don't know how feasible that would be, also with regards to the original Blender file format :-/ But if the Blender people could really add the necessary functionality, Blender might have the potential to replace AC3D for most tasks, which wouldn't be that bad, because Blender doesn't cost money ;-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] create craters and smoke effect
CHANDRASEKHAR ACHALLA wrote: I was also wondering if flightgear already has the fire and smoke effects. I would appreciate if anybody has any ideas.. The crater/fire/smoke stuff sounds a lot like the feature suggestions that I read about a couple of days ago for a combat enabled version of FlightGear, also if I remember correctly Curtis posted some remarks about the whole combat issue at avsim.net - where some folks had requested such a combat version of FlightGear. The summary was, that most of the stuff _could_ be added to FlightGear even without directly intending to make it a war game in the end. Also, I do remember that there exists another project at sourceforge, based on FlightGear to add the combat relevant stuff to FG, but I really don't know if this is already in active development or how many developers are involved at all, but even if these folks are just about to make coding drafts you might be able to benefit from some of the source modifications or just ideas involved. Unfortunately, I don't recall the name of that project right now, I'd suggest to search for FlightGear and combat. Good luck Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
Frederic Bouvier wrote:
! if (!cur_fdm_state-get_inited() or
fgGetBool(sim/sceneryloaded)) {
^^
Are we silently migrating the code to Pascal ?
This doesn't compile with MSVC.
lol, GREAT :-)
don't know about MSVC++, but how about ios646.h ?
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]CVS: FlightGear/src/Mainfg_init.cxx, 1.104, 1.105 main.cxx, 1.171, 1.172
Frederic Bouvier wrote:
Boris Koenig wrote:
Are we silently migrating the code to Pascal ?
This doesn't compile with MSVC.
lol, GREAT :-)
don't know about MSVC++, but how about ios646.h ?
and why not
#define BEGIN {
#define END }
?
:-))
More seriously, does it brings us something we are missing
with || or ?
Well, I guess it probably wasn't noticed - don't worry: I would bet Erik
is going to change the stuff anyway ;-)
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fw: Scenery Designer
Hi ! Peter Larson wrote: I'm new here and am having problems with fgsd on Windows XP Pro. I've got a copy of AC3D and want to import an object and place it in fgsd, but it keeps crashing when I try to load the object. Am I missing a support application, or is there another issue on Windoz? Peter Don't know if this is relevant for your case, but there were some issues reported with the latest AC3D version using specific (new) statements (crease) that aren't yet supported by plib, the current workaround is to manually remove such statements from any AC3D files that you want to use with FlightGear - as fgsd is likely to also use plib in the same fashion, I'd recommend to check for any such unsupported statements in your AC3D file. If you were running Linux or at least cygwin I'd recommend to give automatically stripping the relevant stuff by using a shell script a try, but I think starting notepad and search/replace for occurences crease should also work to see if that's really the problem. In case you were already aware of this stuff and this is not your problem, I'd try to load some other AC3D file - just to verify if it's really not a problem with the AC3D file but rather the application itself. good luck - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTuror (Was: Adding external nasal bindings fgcommands)
Let's get back to this one :-) Erik Hofman wrote: Boris Koenig wrote: I wouldn't have a problem, creating the authoring part of the application as an external application - but THEN I would need to be able to load FlightGear resources (aircraft/images/panels). Ok. Lets start a *minimal* list of items that really are needed for this and skip the implementation part for now. This is what I think what would be needed (feel free to add your ideas). Anything else (remember, this is the *absolute minimum*)? Besides the things that I mentioned already in the original short ;-) reply to your message, I think the two most important things would currently be: - basic functionality to deal with XML files (using Nasal) - dynamic creation population/modification of controls/dialogs using Nasal Also, some more customization of the current PUI XML-bindings might be necessary, in order to be able to tailor dialogs/controls (i.e. transparency/movable flag) - Andy mentioned something like this already - if you take a look at the screenshot on the FliteTutor concept webpage, you'll notice for example, that the combo box in the upper left corner opens upwards, while it should -in this case- actually open downwards (otherwise the menu contents aren't visible anymore). Using PUI directly it's afaIk possible to specify such details - hence it shouldn't be too complicated to add a corresponding option to the XML-PUI layer. I would be willing to make the necessary modifications myself, also to add things like basic font formatting - would these changes then be accepted for the official CVS version ? You know, that's the actual problem I was having, also regarding the whole plugin stuff that I mentioned: making such modifications directly to FlightGear sources would always require these things to be accepted for FlightGear itself, while having a separate library taking care of this stuff wouldn't require any direct access to FlightGear in most cases, hence one wouldn't rely on a particular FlightGear release/build to be able to use a new function, which is actually not even part of FlightGear itself... Regarding the standard FlightGear menubar, I think it might be useful to optionally make it auto-hide/show - that way it would only be displayed if the mouse is in the corresponding area, and fade out as soon as the mouse leaves that area. In the end, I don't mean to blow up Nasal, but rather use some scripts as backend library to load display a set of pages - but of course this would still require some additions to the current command set. But I don't think this would be too dramatic, on the other hand adding a couple of new functions/bindings might also create new possibilites, one might even start to create things like a FMC based on Nasal. Hope this mail was short enough ;-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] --fog-fastest --fog-disabled - the latter w/o update below horizon ?
Chris Metzler wrote: On Sat, 24 Jul 2004 21:32:25 +0200 Boris Koenig [EMAIL PROTECTED] wrote: A couple of other things: I *did* search, but didn't find a way to directly set the heading of an aircraft if you want to position it in air - if it's there already, please tell me where :-) If it isn't it might be worth to be added ? What did you search? sorry, I was reffering to the Set Position dialog within FlightGear, not any command line options, I do know that you can set these manually or use directly the property tree, but I thought it might make sense to directly include that option within the corresponding dialog. And that's where I was looking for that option, because I thought it would make sense to be there !? Can you rephrase this? I can't figure out what it is that you're saying here. lol, simple: FlightGear knows of various airports that I can pick to start at, but these airports aren't all *visible* within FlightGear, so - even if I am sure that I am at the right coordinates I don't see a specific airport or rather runway layout. This happens also with standard airports that are selectable from the corresponding dialog. My assumption was hence, that the airports are currently bound to the scenery, as I don't have much additional scenery installed. That's why I thought that not all airports/runways might already be available. So the question is, whether that's true or if there's anything else wrong with my base package. I was a bit surprised to learn that, since I thought FlightGear uses X-Planes Navaids/Airports info - and X-Plane deals with scenery and airports separately, so it doesn't matter if I have the necessary scenery installed or not, because the airports, including the proper runway aligment will always be available, even if that means that KLAS 25 R becomes an island within the ocean ;-) Just tell me if you need even another version of this :-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: --fog-fastest --fog-disabled - the latter w/o update below horizon ?
Alex Romosan wrote: Chris Metzler [EMAIL PROTECTED] writes: Regarding the navaids discussion I'd like to know if airports are currently exclusively bound to the scenery, actually I was looking for some airports that FlightGear also finds, but didn't see any rwys - if airports should really depend on specific scenery to be installed, it might be worth to think about separating airports from scenery - at least the basics like runways etc ...or what else is the reason for not _seeing_ an airport which FlightGear actually knows of ? Can you rephrase this? I can't figure out what it is that you're saying here. the graphics part of the airports _is_ part of the scenery. FlightGear looks up the latitude and longitude and the position and heading of the runways (in runways.dat) but if the scenery is not there there are no graphics to be loaded so you get positioned over the ocean. Hey, thanks Alex - that's exactly what I wanted to know ... So, there's no way to have the airports/runways etc. available without installing the corresponding scenery ? Hmm, bu**er :-/ How about also separating the scenery from the actual airports data ? I will untar the archive and check if it's the same format as in X-Plane, if it is it should be possible to display basic airports even without having the necessary scenery installed. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 Model
On July 20, 2004 03:23 am, Jim Wilson wrote: Hmmm... that 777 Model page didn't mention a GPU. In any case, I gather from reading just the first paragraph on the OpenRT page you'd be looking at having plib utilize the OpenRT API in lieu of OpenGL's. I may be wrong, but from what I've read, openRT is indeed supposed to make use of a specific GPU - or alternatively a (cluster of) CPU(s) @ ~40 GHZ :-) But, there seems to be a project related to openRT that is dedicated to developing the necessary hardware: http://www.saarcor.de/ Seemingly, also a project of the same German university. Ampere K. Hardraade wrote: All I am saying is that it will be a good idea to look deeper into it instead of pushing it aside. After all, from what I have read on their site, the OpenRT library seems to offer some pretty neat capabilities that aren't in the current version of plib. plib makes use of openGL while openRT is a different rendering approach which doesn't utilize rasterization anymore - so I think Jim is right in saying that one would really have to drop the entire openGL approach to make use of something like that. I don't know the details, but I doubt that it would be really simple to convert to such a new approach, which wouldn't rely on openGL anymore. In the long term the openRT folks probably hope to replace the openGL implementation in many 3D applications with openRT, because it could provide a performance boost in many cases, particularly because it would no longer be necessary to process all graphics data just in order to determine which parts are really visible or not ... At the very least, we should keep this real-time-raytracing technology in mind. The idea of Microsoft come out with games that utilize real time raytracing while Linux has nothing equivilent is... freightening. I agree, the whole idea is extremely fascinating: Having had a look at some of the screenshots or even videos, the stuff seems really to be pretty amazing and powerful, but currently it's probably really a bit beyond the scope of any game, to care too much for openRT, simply because of the lack of hardware support, I think - be it a relevant GPU board or the 40 GHZ requirement for openRT :-) And then I am not even sure if there's really yet an OPEN implementation available !? As long as FlightGear keeps getting modularized even more, it should not be that much of a problem, to consider new technologies - even though this unlikely to become an issue within the next 3-5 years ;-) But on the other hand, at http://graphics.cs.uni-sb.de/RTGames you can read: We are very much interested in evaluating new ways for computer games and therefore like to cooperate with the gaming industry. Thus if you are in such a position, please send us an email mailto:[EMAIL PROTECTED]! So, now it depends if FlightGear is considered part of the gaming industry :-) But if the openRT developers are really also looking for opensource projects, it would probably be not that bad for FlightGear to at least indicate some willingness ;-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] --fog-fastest --fog-disabled - the latter w/o
Hi ! Martin Spott wrote: Boris Koenig wrote: --fog-disabled: http://flitetutor.sourceforge.net/mlist/fgfs-screen-fog-disabled.png Do you use an ATI Radeon with OpenSource DRI drivers ? This is an effect I have seen many times during major changes in the Radeon driver in the XFree86 pre-4.3 phase, While it is not a Radeon card, it is indeed an ATI (Rage 128) card - the driver is DRI (from the latest XFree release). Also, the problem seems indeed to occur only with the ATI card, the same settings do work on the other machine, otherwise I get less FPS with a current nvidia card than with the old ATI Rage128 :-/ Erik also mentioned that some of the problems that I previously described when I was using specific graphic card settings, are likely to be driver-related, but then: on the other hand I don't have any of these (or similar) problems on the same machine/config with other openGL software, regardless if I am running tuxracer, blender quake or whatever: everything looks normal. --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 777 Model
Arnt Karlsen wrote: On Sun, 25 Jul 2004 02:28:46 -0400, Norman wrote in message [EMAIL PROTECTED]: I am espescially interested in the profiling results from the newer higher end cards. i.e the GForce 4 class or equivalent cards ..which is the low end limit on ATI, 3dfx etc cards, that can do at least 1fps? I mentioned this a couple of times already, but the weird thing is really that I have personally achieved higher/better performance using an OLD card, rather than using my current nvidia accelerator on the main machine, I was just recently really about to change cards ;-) On the other hand, the old ATI R128 card achieves about 70-80 fps in 800x600 resolution under _windows_ running stuff like counterstrike. While running FlightGear (either under windows or linux) leaves me with only about 30-35 fps if I am lucky. Regarding profiling: what would be necessary to be done ? Are there _any_ profiler tools for 3D/openGL applications ? I know that there do exist some openGL related logging tools which can monitor the commands that the graphics adapter receives/processes, but don't have the slightest clue, how to really PROFILE an openGL app if you want to profile the openGL instructions. Don't even know if one could use gprof for such a purpose ? If there exist any libraries specifically aimed at profiling/debugging openGL applications, it might indeed make sense to optionally include such functionality in developer releases in order to first find the bottleneck on most configurations, and then be able to really address it. If I remember correctly, SGI did have some kind of openGL debugger, but don't know if there's any freely available stuff for these purposes, personally I certainly wouldn't care if I had to install another 50 meg package in order to have the necessary profiling capabilities, such a profiling feature could optionally even report its results automatically back to the FlightGear webpage, that way one could really get representative data. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 777 Model
Ampere K. Hardraade wrote: Be thankful for that 30-36 fps you have. I usually have about 6-9 fps. ='( Yes, as I said: I get pretty much the same with the new nvidia card, and regarding the ATI card, I did have to disable several options to come into the 20+ FPS range, but on the other hand I don't care that much for the eyecandy stuff, I'd rather have a smooth performance ;-) But if anybody knows how to profile openGL applications, I really wouldn't mind to install/configure the necessary stuff if that helps to track down the most essential problems and make FlightGear become smoother. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Tried the Spitfire
Vivian Meazza wrote: Matthew Law wrote If carb heating is on enrich the mixture over time until power is restored. The conditions are actually aircraft and engine specific, I think wow, I am just about to notice how much work some people spend on really resembling all the various aircraft subtleties properly ... didn't know that so far, would definitely recommend to create some kind of summary for each aircraft and place it as a textfile into each aircraft's folder. Many such things aren't that obvious, and even if they are it's interesting how these things are implemented or what workaround is being used to resemble a certain functionality. On the other hand such a detailed description of the implementation could also provide some insights for other user who want to create their own aircraft, or simply extend pre-existing aircraft. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear base package request --version parameter to fgfs
Hi ! As a user on the FG user list requested a patch from base package pre2-pre3 in order to reduce download size/time, I was looking for the required pre2 package, it doesn't seem to be available on ftp.flightgear.org anymore - so I decided to look what base package I am currently using in order to see whether I could simply tar my current base directory and use this as a patch basis, but there doesn't seem to be any version information included in the base directory either, nor does fgfs --version provide _any_ information at all, I think particularly the version information via command line should be added ASAP, possibly even directly available from within FlightGear. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear base package request --versionparameter to fgfs
Jon Berndt wrote: Hi ! As a user on the FG user list requested a patch from base package pre2-pre3 in order to reduce download size/time, I was looking for the required pre2 package, it doesn't seem to be available on ftp.flightgear.org anymore - so I decided to look what base package I am currently using in order to see whether I could simply tar my current base directory and use this as a patch basis, but there doesn't seem to be any version information included in the base directory either, nor does fgfs --version provide _any_ information at all, I think particularly the version information via command line should be added ASAP, possibly even directly available from within FlightGear. I think that's an excellent idea. I also think that fgfs --version should report the SimGear, JSBSim, YASim, etc. version numbers. yes, including not only the version of the FlightGear runtime but also of the FlightGear base package itself, which -as all of us know- might very well differ from the actual release version. For the latter to be easily implemented there should be some simple version file stored into FlightGear's base package root directory, this would not even need to be XML based, even though that would certainly not harm at all, if you take things like patches into account. Optionally, it might even make sense to provide some more detailed version information for debugging purposes, e.g. for stuff like the available plib/openAL libraries etc. That way, it would also become relatively easy to enable new users to track down potential problems caused by version conflicts because of old system libraries etc. Using fgfs --version one could provide general information about all relevant version information, more detailed and library-specific information could be provided by using something like fgfs --version=plib or fgfs --version=openal. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear base package request --version parameter to fgfs
Jim Wilson wrote: There are no pre-release tags, but you could probably do a cvs checkout by date if you wanted to be sure. yes, thanks for that - actually, that's also what I've come up with in the meantime, just checked the 1.11 revision out ... but a compressed download of the entire directory structure would certainly have been faster :-) Also there is -of course- quite a lot of CVS related stuff in the checkout. A couple of minutes ago I created the patch, don't know if it works though, as I don't have the actual pre2-release installed locally, will need to wait for feedback - posted the link to the users mailing list. This link to a cvs log shows the date/time that pre2 was finalized: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/version?cvsroot=FlightGear-0.9 Note that this log happens to refer to the file that contains the version number. It's called version and is located in the base package directory. Yes, sure - I did see that file (and also checked its contents) when I looked for version information about the base package, but it states only 0.9.4 - this even though I am _definitely_ using 0.9.5 *PRE*, so having at least the exact version information of the base package available would certainly make sense-including details about PRE-releases etc. But then, also not to have to rely on cvs-specific files which would not necessarily be available in a release version and hence won't be suitable to determine the base package version in general. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] create craters and smoke effect
CHANDRASEKHAR ACHALLA wrote: I was also wondering if flightgear already has the fire and smoke effects. Regarding my last reply on that topic I had a quick look at sourceforge for the specific name of the project that I mentioned. It's named FlightGear CombatZone - but, well that specific project is already pretty old and doesn't have any files published, nor does it have a real webpage: https://sourceforge.net/projects/fgcombatzone/ But on the other hand there are plenty of other opensource projects which already do what you seem to need, the first coming to my mind would be bzflag - a tank (combat) simulation which is also based on SimGear and makes already use of things like explosions, fire, smoke and collision detection: https://sourceforge.net/projects/bzflag/ I did some quick searches for other 3D projects in that category, but I think it would probably be really the easiest to look into the bzflag sources, on the one hand because that stuff is already SimGear based and hence it would probably be pretty straight forward to borrow some lines/fragments of code, and on the other hand bzflag has also an _incredibly large_ user AND *DEVELOPER* ( 50 !)community, so odds are good that your questions are answered pretty soon. If bzflag alone is not sufficient already, here are some other opensource projects that might be useful for your purposes and which can be easily found at sourceforge, while some of these don't yet have any files/source released, contacting the developers might help you anyways: __ 3D FX Function library is a set of functions that will make your programming life much easier. Already featuring lensflares, particle systems, explosions, etc, we hope to port to as many languages as possible. https://sourceforge.net/projects/dbdev/ An explosion simulator for 3D real time applications https://sourceforge.net/projects/explosion/ This project is a 3D engine developed in opengl. We want to develope a tool box with allows everyone to program 3D-demos using easy XML script. We need to program animation of 3d objects, humanoides, particle simulations, 2D/3D effects, transitions,... https://sourceforge.net/projects/cymagine/ VRGL, is a modified OpenGL runtime library for visual effects useful in virtual reality applications. It is intended for use with precompiled 3D graphics engines, like the one in Unreal Tournament 2003. https://sourceforge.net/projects/vrgl/ An OpenGL Framework to build graphic effects and demos. Focuses on speed and performance rather than compatibility and portability. Currently based on OpenGL, the framework is meant to support software rendering in the future. https://sourceforge.net/projects/glsilent/ C++ 3D graphics library for game developers, researchers, and students. It is a base of robust and high performance code common to most 3D projects. https://sourceforge.net/projects/g3d-cpp/ FreeSOLID is a library for collision detection of three-dimensional objects undergoing rigid motion and deformation. FreeSOLID is designed to be used in interactive 3D graphics applications. https://sourceforge.net/projects/freesolid/ OpenDynamics is a real-time 3D physics simulation core including collision resolution. A C library, it consists of modules providing linear algebra, newtonian dynamics, collision and contact resolution, some constraints, aerodynamics and explosions. https://sourceforge.net/projects/opendynamics/ The Phoenix Open Source Flight Simulator project is designed to create the ultimate base for combat flight simulators. Every piece will be designed as modular as possible allowing component switching and a great opportunity for community development. https://sourceforge.net/projects/phoenixosfs/ The Combat Simulator Project is an open source project started by flight sim enthusiasts eager for a serious hardcore flight simulator. https://sourceforge.net/projects/csp/ G3C provides the main features for 3D-game developers: 3D rendering engine based on openGL, collision detection, physical rules, p2p network... A game-sample will be avaible, binding a wargame, a flight simulator, a first person shooter, a MMOG... https://sourceforge.net/projects/g3c/ This library is an effort to provide a collision detection library for generic polyhedra. Its purpose is mainly for 3D games where accurate detection is needed between two non-simple objects. https://sourceforge.net/projects/coldet/ Interactive Dynamics Library - Indy C++ library for rigid body dynamics, specifically aimed at games. Project will hopefully support full collision detection, collision and contact resolving, springs, constraints, etc. https://sourceforge.net/projects/indy/ 3D Engine featuring : Particles systems, hierarchical animation, portal rendering, collision detection via BSPs, ISOSurfaces managing, NURBS, animated
Re: [Flightgear-devel] lights flaring on runways in FG
Chris Metzler wrote: On Thu, 29 Jul 2004 00:08:31 -0400 And I don't see any problem with the DC-3. I want to say that this is something odd about your drivers, but I'm too ignorant of this stuff to be sure. Is it only ATI people that see this stuff? Do all ATI people see this stuff Personally, I would say that while there do seem to be some issues specific to ATI cards, I cannot complain in general as the overall performance seems a lot better than using a better card, regarding ATI I've come to the conclusion that it's just a matter of disabling the right options to reduce the problems (like the mentioned lack of updates in specific parts of the client area) and to make the whole situation bearable. On the ATI issues I am going to download some other plib applications in order to specifically look out for similar problems but also performance, maybe it's really not that much related to FlightGear itself but rather plib ? That would at least make sense if I don't find _any_ plib app where I achieve more than 10-15 FPS with the nvidia card ;-) Regarding the idea to profile the openGL specific parts of FlightGear I have to say that I did download the mentioned software but to be honest: I wouldn't have the slightest clue about what to look for, so the best thing I could possibly offer is to log everything and make the logs available - but the evaluation of these logs would probably be a totally diffferent issue :-/ On the other hand I had a closer look at this openGL logging application and I think one might attempt to get representative results by adding the functionality to FlightGear itself (a debugging version) and try to run some basic flight data replay (or something similar to utilize openGL for a specific amount of time which should be available in all versions) on as many machines as possible. Maybe one could then find essential differences by comparing the collected logs ? (just guessing) Even though I did personally also consider running other (more performant) Windows openGL applications in order to see in what way they deal differently with the accelerator card, possibly it's really about enabling specific options on some boards ?! Boris P.S.: Sorry Erik for typing more than 5 lines of text :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear base package request --version parameter to fgfs
Jim Wilson wrote: Boris Koenig said: But then, also not to have to rely on cvs-specific files which would not necessarily be available in a release version and hence won't be suitable to determine the base package version in general. That's true. You are probably just too late this time around. Well, to be honest - that was NOT my idea, I just also thought the idea would be pretty good and didn't mind to create the requested patch. The actual idea and patch-script come from Stewart Andreason on the users mailing list: His current patch script requires a (to be patched) version of the FlightGear base root directory and an archive with an updated version of that directory tree. It then creates a diff of these two trees and that diff tree is then packaged into an archive - so you would normally only have to untar that said diffed archive into your old base package in order to obtain a recent base package. While the script itself looks pretty good and does seem to work, there are some minor things that could be improved, like being able to either use another directory/archive as source/target. Also, it doesn't yet seem to take those files/folders properly into account which need to be removed/replaced from the old release. It is an interesting idea having release to release patch files, but I am not sure what would be involved. Yes it could indeed turn out to be quite useful in general, one of the easier ideas would be to have checksums for each file/folder and simply store these checksums within a specific file in FlightGear's data root directory. This checksum file would then contain each folder/file (absolute position) with the appropriate checksum. A simple syntax might already be sufficient: file:/data/aircraft/whatever.xml chk:0f32e4f8a97c (optionally also file size) One would then use a shell script to take care of all changes within the CVS, either that script is executed automatically after each commit - or it is run by cron job. It would then simply create a detailed checksum list for each revision. In order to update a release the patch script would merely have to compare the local (old) copy of the checksums file with the latest version of the base package, that way it could track down all necessary changes. So, in order to create a patch file one would mainly need to: - download specific files from cvs - remove/replace specific files Basically, one would execute a stripped down cvs update - but of course this could also be web-based or use the viewcgi perl script to retrieve the files from CVS. So, all (new/changed) downloaded files would then be put into a corresponding patch archive. Additionally that script should take two other things into consideration, 1) all files/directories that should NOT be put into the release patch (i.e. CVS stuff) 2) also those files/folders that don't reside in the data repository, but also need to be updated/packaged into new base releases (the documentation/manuals would be such a case, cause they are stored separately). -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Taildragger takeoff and landing
Curtis L. Olson wrote: Erik Hofman wrote: Jon S Berndt wrote: On Thu, 29 Jul 2004 10:34:16 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: Ok, then how do you explain a frisbee that can curve either way, even though it's always thrown with the same direction of spin. And please include the coriolis effect in your explanation (now that it is implimented in JSBSim.) Thank you. :-) Gyroscopic stabilization and tilt. Which gets us to the one milion dollar question: Can you frisbee on mars? You can, but south of the equator it will break the opposite direction. I like it when people share their valuable experiences ... :-) So, the next time I'm there I'll be careful ! Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Back to the plugins discussion ... I am really about to get famous here for my unpopular views ;-) Andy Ross wrote: Boris Koenig wrote: Erik Hofman wrote: I'm still not convinced that a plugin system would be such a great idea for FlightGear. Well, I am just making suggestion :-) I think most of the criticism centers on the idea that, even if you had a nice plugin system available, it really isn't going to help you very much with doing extension development. I was specifically thinking of things that would currently require to directly modify the FlightGear sources, in many cases it would be very useful to have the possibility to load an application dynamically and run it *within* FlightGear, think of applications like atlas - if there was a plugin interface available, it could easily integrate completely into FlightGear and would not need to be running separately. Similar applications like flight planners or even applications that serve as flight management computers could also integrate natively into FlightGear. One of the easiest ways to provide a very basic plugin interface would first make sure to provide handles to FlightGear's client area and subsystems so that each module/plugin can easily use these to do specific things. This would not even be terribly complex and could still be pretty useful, e.g. a flight planner plugin would then simply need access to: - FlightGear's client area - FlightGear's Navaids data That way you could already draw your own GUI into FlightGear's window in order to display your flight planner tool which could then make use of all the necessary (navaid) data provided by FlightGear itself. Of course something like that could also be implemented using a scripting language, but more complex applications would probably be also more time-critical and would need to rely on threaded design. It doesn't change the existing Nasal or FGCommand interfaces at all, well, of course I was thinking of a way to enhance that functionality, it shouldn't be that much of a problem to load a library which exports a C function and a function name for Nasal and make that C function then available as a Nasal or FGCommand, but maybe I am wrong here - but even without knowing anything about FlightGear's/Nasal's internals, I could come up with a corresponding example in ANSI C within 30 minutes... So, even if this _is_ really a problem in FlightGear (which I can't believe) one might still fall back to good old C/C++ - which would probably be the case anyway when it comes to dealing with pointers for dynamic function import. and adds an extra layer of complication. This is of course true, but that extra layer is compared to the FlightGear sources itself pretty restricted and would not be really complex. One could start to add a very basic plugin interface at first. And it would be certainly _A LOT_ easier to document a simple plugin interface than writing all the documentation that's still missing for FlightGear. You won't need that much functionality in the beginning - things like access to most of FlightGear's subsystems would probably already be sufficient in the first place. That way a plugin could ask FlightGear to make use of a specific subsystem. The idea of a plugin comes from the commercial software world, where distinct entities (Microsoft and aircraft vendors, for example) need to ship software on different schedules. You're right - but plugins have other advantages that apply also to the non-commercial world, scenarios which you didn't yet mention, e.g.: You can easily incorporate new functionality into a project like FlightGear without having to make any code-changes or the need to recompile the whole application - you usually provide a generic and simplified set of methods to extend an application, this allows also those users who are not that familiar with the internals of a project to make meaningful contributions. This gets particularly interesting with functionality that's very specific and is not needed by every user - a functionality that might not even have the slightest chance to ever get accepted for an official release. So, basically the whole plugin idea is about _dynamic_extensions_ ! Even *opensource* projects make use of support for dynamic extensions, either by really using plugins (i.e. loading binary libraries) - or more widely spread- by using a powerful scripting interface to allow execution of custom scripts within the application context. The current way to make bigger -coding- contributions to FlightGear is to really dive into the sources and find the right place to integrate your stuff. Also, there really seem to be already things integrated which seem to me rather SPECIAL - e.g. things like GPS data processing. So, how many people (regular flightgear users) are ever going to make use of something like that ? Don't get me wrong, I think it's _great_ to have a lot functionality integrated, but on the other hand there are certainly good
Re: [Flightgear-devel] create craters and smoke effect
Arnt Karlsen wrote: On Thu, 29 Jul 2004 13:13:20 +0200, Boris wrote in message [EMAIL PROTECTED]: Maybe that saves some time or at least keeps you from re-inventing the wheel ;-) ..maybe. Executive summary from http://www.phoenixosfs.org/ ;-) BTW, interesting project but they don't seem to have written much code yet, rather they seem to be considering using FlightGear itself as backend for their combat simulator...on the other hand their project might also be of interest to the original poster exactly because of that ! And it was getting fun again: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec molestie. Sed aliquam sem ut arcu. Phasellus sollicitudin. Vestibulum condimentum facilisis nulla. In hac habitasse platea dictumst. Nulla nonummy. Cras quis libero. Cras venenatis. Aliquam posuere lobortis pede. Nullam fringilla urna id leo. Praesent aliquet pretium erat. Praesent non odio. ..please weed out the dead stuff on posting, Well, I *did* mention that I was merely looking for other projects which already make use of the features that were requested, I mentioned primarily bzflag - cause it is based on SimGear and all the other projects were just hits whose descriptions sound as if they might be useful if bzflag's sources alone should not be sufficient. Also, I did make clear that some of these don't seem to be under active development, amongst them a couple of projects which have concept docs anyway, and that (= ideas) was it what the original poster asked for. or if you find anything useable in the dead projects cvs trees, point us to the good stuff. I did not browse any CVS repositories, nor do I intend to do so now - *if* there's interest in any of these project at all, that's certainly rather a job for those who want to do the coding for that specific project/feature addon. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] create craters and smoke effect
Norman Vine wrote: Boris Koenig writes: I mentioned primarily bzflag - cause it is based on SimGear Hmm .. very interesting . as bzflag predates SimGear ... lol, don't tell me now that I was wrong ? could you please tell us your source of this information as I didn't see any mention of SimGear in a quick perusal of the bzflag source code I didn't check the source code, it's just that I installed (compiled) bzflag some time ago and was quite sure that SimGear was one of the requirements for bzflag to run, don't know if I am confusing things now, will have to check their webpage for that. Sorry in advance if I should indeed be wrong, though. (sometimes memory does not serve correctly ...) --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Chris Metzler wrote: [...] So what we discussed was a webpage/site which would (eventually) do for FlightGear what avsim.com/flightsim.com's file libraries do for MSFS. At least at first, it'd provide upload/browse/download capability. Even though I agree with Erik that it would make sense to keep everything in a central place I do also think that it should be easily possible for the mentioned user contributions to be added easily BY users - without the need for developers/project managers to take care of such things. So, I think the idea in general is pretty good, but regarding browser based file uploads there might be a problem when it comes to scenery packages: these files are usually pretty large, so it would be more realistic to provide anonymous FTP access for these uploads - also more convenient, I wouldn't want to wait for a large file to upload via browser without any status information at all... Eventually, it could also be a place to fetch useful scripts, programs, scenery-making tutorials, etc. As long as it would be running via some kind of CMS this would really be an advantage, as it could become a central repository for designers in general - be it scenery or aircraft. So that everybody could easily make direct contributions. Also, such a webpage could offer scenery download based not only on certain clickable areas but really based on certain towns/airports or even navaids. This would merely be a cross lookup between the navaids file and the actual scenery folders in order to determine which scenery package needs to be picked for a certain town/airport or navaid. One could even provide a flight plan in order to determine the necessary scenery downloads, I am not sure if TerraGear is using such an approach already, as I keep having problems with it ... It wouldn't necessarily require a chunk of Curt's time or hardware; No, as it sounds it would have the legitimation to become a separate webpage if necessary, probably one could even use a sourceforge project for that purpose...that way at least the resource problem would be solved ;-) it need not even be in the flightgear.org domain, although I think it'd be a good thing if it was (unfortunately, scenery.flightgear.org is occupied, hehe). Mat Churchill and I are both enthusiastic about such a scenery website. actually, it's not long ago that I sent an eMail to Curtis asking for other additions to the original FlightGear page that I suggested. I mentioned both of these already in previous postings on this mailing list, unfortunately there were not any reactions to these - absolutely contrary to the reactions to my usual posting ;-) On the one hand I suggested installing a bugtracker script and on the other hand a dynamic FAQ system. I did offer to take care of the installation/setup etc. - so it would not require much effort from other people in order to get these things done. So if Curtis should decide that he doesn't want to put something like that on FlightGear.org I would love to join your efforts so that we could put all these things on a different webpage, which should still be linked to from FlightGear.org - Curtis could set up a specific subdomain for exactly that purpose, so he would still keep his recource usage low(er). - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs aborted with the dc3
Ron Lange wrote: Thank you Durk! I hope that someone is making a patch of the final base package soon...;-) Just to get this straight: you'd need a patch from pre2 - 0.9.5 ? Is there anybody else who would like to see such a patch ? Arnt, for which pre-version do you need a patch ? Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Chris Metzler wrote: On Sat, 31 Jul 2004 10:17:48 +0200 Erik Hofman [EMAIL PROTECTED] wrote: I think that (now that we have a separate Objects directory) it is possible quite easily to add a command-line option to disable the static scenery objects. Fair enough. But with ground structures that are installable separately, it's possible for a user to pick and choose what to install. For example, someone could wish to see a set of landmarks in Paris, but not the buildings at Orly (wanting smoother framerates during landing/takeoff, but not caring so much when flying over the center of the city), or something like that. Regarding that particular issue it might even make somewhat more sense to add another option to selectively adjust scenery complexity for certain areas - that way, the scenery itself would be available, while its actual level of complexity could be customized for specific purposes at runtime, so I could decide for a high level of detail during approach/final segment while reducing scenery complexity on the enroute segment. As you mentioned this would not need to be restricted to certain phases of flight, but rather could really be specifically customized to certain sections during flight. So, this would be a bit more tweakable than the usual approach to decide for ONE specific detail/rendering profile, which usually is not changed during flight... So while I really like having the separate Objects directory, and agree that being able to toggle on/off the static scenery objects would be a good thing, I think being able to pick and choose what (non-random) static structures to install is *also* a good thing. yes, it would allow for some more flexibility My personal opinion would be to get everything at one place, preferably (but not necessarily) in a separate CVS branch at flightgear.org just like the world wide scenery right now. That would be easiest for everybody (and provides mirror sites). Browsing a CVS repository is possible, of course; but kinda ugly and more oriented towards developers than users. I don't know much about user-friendly CVS clients, especially for Windows. There are a couple I know of, but to be honest for a NORMAL windows *user* in general it cannot be considered user-friendly to require installing a cvs client. If you really want to keep using CVS for these purposes it might rather make more sense to look into more powerful web-frontends to CGI, as even a windows user :-) can deal with a browser, and wouldn't have to install any extra software, nor would a windows user require to get familiar with a new interface if a browser can be used for these purposes. As a workaround one might try to make CVS (via browser !) itself a bit more end-user-friendly by including things like screenshots in the repository (like in a specific folder named previews) - while this is certainly not what CVS is meant for, it would provide some convenience for users to really be able to tell what a specific scenery addon is all about and who are not really familiar with developer frontends. The other thing is that I think it'd be good to avoid putting any more work upon the existing developers (e.g. not asking Curt to take on more website work). yes, gotta agree on that one too, to be honest: being new to this mailing list my current impression is really that most of the developers are simply way too busy to take care of all the suggestions that keep being made by users, not necessarily talking of my own suggestions here: I've spoken to several people who have similar impressions, this is really not meant to be critique, but rather something you ought to think about: it seems to be a matter of fact, that the current infrastructure for the FlightGear project requires a lot of decision making of the right people (mostly Curt and the main-developers). So, while these people are - understandably - very busy new ideas which might benefit the normal user (usually, more than developers !) are not necessarily addressed properly. I don't mean to say that the project itself should be separated into parts, but rather some more of the responsibility should be shared, so that there's really less interaction by the main people required. Talking of the webpage, which currently seems to be maintained -also by means of - CVS, is such an example: if there was a simple CMS (content management system) running, the webmaster could assing different sections of the page to different people for maintenance. So, Curtis would not have to make changes to the page by himself, but could rather ask someone else to take care of things like updating the news section or whatever, this might even be done by a general request to the mailing list. That way even those users who are not familiar with CVS etc. could help keeping the webpage updated (adding downloads etc.) and they would not require to be familiar with any special software. Currently, all this seems really to be a pretty static solution which seems to
[Flightgear-devel] Re: [Flightgear-users] Re: FlightGear-0.9.5-pre3 base patch request
Erik Hofman wrote: Boris Koenig wrote: You're right in saying that most of the base package is unlikely to change THAT significantly, I think - so it would really make sense to provide means to upgrade from any base to the latest base version. You might get disappointed ... Erik, in order to determine how feasible it would be to even further extend tardiff.pl in one way or the other it would be useful to know what _major_ changes to the FlightGear base package are planned, or at least likely to occur within the near future, so things like structural changes but also file format changes (e.g. because of compression) would be interesting. Steven has meanwhile written a pretty advanced version of the original script that for example now provides means to determine if files/folders were moved or renamed within the FlightGear base package tree in order to reduce the resulting patch file's size. There do exist some other ideas, but many of these would be extremely specific and would only make sense in certain cases. So, what kind of likely changes come to your mind ? Thanks - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Re: FlightGear-0.9.5-pre3 base patch request
Sorry for cross-posting, didn't intend to do so, was probably caused because this topic comes originally from the users list. Erik Hofman wrote: Boris Koenig wrote: The most likely changes are updated (and new) aircraft 3d model related files. The rest is not very predictable. It comes as things go ... It might be useful if such changes could be documented - at least the more significant ones, do you usually make (detailed) cvs comments for these things ? Even though the structural changes can be easily tracked down by the script already, it might help if the other things would be mentioned somewhere. Updated or new files itself would not currently be a problem, rather changes in file formats (possibly caused by using compression on RGB files) would be more problematical. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Re: FlightGear-0.9.5-pre3 base patch request
Erik Hofman wrote: The most likely changes are updated (and new) aircraft 3d model related files. The rest is not very predictable. It comes as things go ... weird, this seems to be related to the mailing list application (pipermail ?) - I did indeed only send the posting to the devel-list, but it (as well as all replies to it !) shows up on the users-list as well, seems to be mailheader related, because it was a reply to another list ? - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs aborted with the dc3
Ron Lange wrote: Thank you Durk! I hope that someone is making a patch of the final base package soon...;-) then I'll get out of trouble. Hi Ron ! I haven't yet received any sources/links for the *original* (old) FlightGear (pre)-release packages, so the patch I am providing here now is based on the 1.11 revision from CVS, stripped off its CVS related folders files. The patch from 0.9.5-pre2 = 0.9.5-final (~1 meg) is obtainable at: http://flitetutor.sourceforge.net/mlist/base-patches/fgfs-base-patch-9.9.5-PRE2__0.9.5.FINAL.tgz *Note*: I cannot guarantee that this works, so you should at least make a _backup_ of your existing base package tree in order to prevent possible corruption (of course, if you still have the original pre2-release tarball you can easily recreate the original structure without any previous backups). Please let us know if there are any problems, but these would then very likely be linked to the fact that I don't have the original files available to create the patches. *IF* this should work without any problems, I could create the other requested patch files by using CVS checkouts as well - until I have the necessary feedback, the rest of you will have to wait, though. good luck :-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfsbase patch 0.9.4final = 0.9.5final (WAS: fgfs aborted with the dc3)
As the 0.9.4 release is still available via ftp from flightgear.org I created a patch from 0.9.4final to 9.9.5final, the patch has a total size of 23 MB (hey, still about only 1/4th of the actual download !) and can be obtained at: http://flitetutor.sourceforge.net/mlist/base-patches/fgfs-base-patch-9.9.4-FINAL__0.9.5.FINAL.tgz Please report any problems, since this patch is based on the official tarball from flightgear.org there should not be any CVS related problems, anyway: make sure to backup your existing data ! BTW, I forgot to mention that after extraction of the patch archive into your FlightGear folder you need to run a shell script in order to remove obsolete files, depending on your OS/platform this is either named remove.sh or remove.bat. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfsbase patch 0.9.4final = 0.9.5final (WAS: fgfs aborted with the dc3)
Arnt Karlsen wrote: On Sun, 01 Aug 2004 13:35:06 +0200, Boris wrote in message [EMAIL PROTECTED]: As the 0.9.4 release is still available via ftp from flightgear.org I created a patch from 0.9.4final to 9.9.5final, the patch has a total size of 23 MB (hey, still about only 1/4th of the actual download !) and can be obtained at: http://flitetutor.sourceforge.net/mlist/base-patches/fgfs-base-patch-9.9.4-FINAL__0.9.5.FINAL.tgz ..it's there allright, but you probably meant to _name_ it somewhat closer to FG practice? ;-) As long as I haven't yet received any feedback the name doesn't matter at all -because we are still TESTING the whole thing - as soon as we know definitely that these patches work as expected I would collect the stuff in a separate place anyway, maybe even ask Curtis to put these things on FlightGear.org to make it easily available to everybody - actually, patches would also be an advantage for FlightGear.org - regarding traffic. Please report any problems, since this patch is based on the official tarball from flightgear.org there should not be any CVS related problems, anyway: make sure to backup your existing data ! BTW, I forgot to mention that after extraction of the patch archive into your FlightGear folder you need to run a shell script in order to remove obsolete files, depending on your OS/platform this is either named remove.sh or remove.bat. ..put this in a README. There is no readme shipped with any base-package *patch*, except the standard files that are included in the fgfs-base package, hence an additional README included within the archive might even cause a naming conflict. The usage information is available on the tardiff webpage, Steven still plans to change some things - amongst them also the names of the standard scripts, which are likely to change to finish.bat and finish.sh instead of the current remove.bat(/sh). So, I would rather recommend mentioning such information on a separate webpage where the patches will be made available in the end, possibly even detailing the exact changes for each patch. Another feature I am currently investigating would be exe-stubs for tgz-archives under windows, that way the whole process would be even made easier for windows users, as one could really attach the patch archive to an extractor stub, which might then also automatically execute the finish-script. Actually it's pretty straight forward to attach exe stubs to ZIP archives under windows, if something like that could be realized for TGZ-archives it might really be an advantage. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs aborted with the dc3
Ron Lange wrote: Hmm...the only way to confirm a successful patch is to diff against the final base-package, but that is the case I try to avoid ;-) I forgot to mention that tardiff has meanwhile support for automatic creation/comparison of checksums, hence it should be possible for you to compare your current base package against the checksums of the full 0.9.5 release, you can retrieve the necessary files from the tardiff webpage: http://www.geocities.com/sandreas41/corral9.html More precisely the file with the checksums for 0.9.5final is at: http://www.geocities.com/sandreas41/data/fgfs-base-0.9.5.md5.gz So, basically this files contains hash sums of all files in the standard package, that way you can compare your local folder structure against the 0.9.5 release structure - details about that can be also found on the mentioned webpage. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs aborted with the dc3
Ron Lange wrote: Hallo Boris, Boris Koenig schrieb: More precisely the file with the checksums for 0.9.5final is at: http://www.geocities.com/sandreas41/data/fgfs-base-0.9.5.md5.gz I've just patched with this file and everything seems to be right. Alright, thanks for providing feedback ! Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..update script tardiff (or cvs) idea, was: fgfs aborted with the dc3
Arnt Karlsen wrote: On Sun, 01 Aug 2004 20:31:49 +0200, Boris wrote in message [EMAIL PROTECTED]: one other thing: I mentioned already that I didn't have the original pre-release available to create that patch, meanwhile Stewart Steven have released a patch that's based on the _original_ pre2-release, which *differs* from mine, you can get that file at: http://www.geocities.com/sandreas41/data/base-0.9.5p2-0.9.5.tar.gz ..ah, that means at least one of you guys has been a naughty boy and worked from something _other_ than an official FG release. ;-) Arnt, how about starting to actually *read* my postings - at least those that you reply to ? :-) I did mention _all the time_ that I didn't have the original (pre)releases available and hence decided to use a CVS checkout as reference basis for the patch. Having meanwhile had the chance to test it, it does seem work anyway, just more files being put into the folder - but I didn't really check it thorougly. Contary to that, the 0.9.4 final = 0.9.5 final patch is based on official releases, which I also mentioned ;-) As I said already: I would not mind creating such a patch chain, but first we would need to know whether things are working as expected and THEN I would still need access to the original pre-releases in order to create the necessary patch archives. ..another idea to test these; provide test scripts. I have bandwith and disk space and vacant cpus, but no time. that would then be very specific to FlightGear, and I think Steven Stewart are right in trying to keep things as general as possible, e.g. that way they can use that script for _many_ purposes, so it does have its justification outside the FG world. IF such an extension is considered a good idea by several users here, one could think about providing externals means for it. ..basically, something like for FG in FlightGear SimGear plib ; ;for V in 0.9.5 0.9.4 # etc for SimGear plib too ;do wget -c $FG.org/downloads/FG-$V.tar.bz2 ;tar jxvf $FG$V.tar.bz2 ;done # etc ;done so you are talking of an automated updater ? regarding that one really has to be careful, not everybody has a full GNU toolchain available, even though there are things like Cygwin they do significantly complicate things for novice users - or at least for those who are not really familiar with Unix. (I know that stuff like wget is also available as a standard Win32 compiled version, but it's not per default available on windows ...) diff -ruN $FG$V $FG$($V-1) diff-from-$FG$($V-1)-to-$FG$V md5sum diff-from-$FG$($V-1)-to-$FG$V bzip2 diff-from-$FG$($V-1)-to-$FG$V md5sum diff-from-$FG$($V-1)-to-$FG$V.bz2 # etc. ..the md5sums are neat to verify that we wind up with the same source tarballs, without having to build them. not sure about how much sense something like that would make, we will have to wait for other opinions, but it's gonna certainly be beyond the scope of tardiff. ..expanding on this idea, it is possible to have newbies use this upgrade script to update their old FG to the current, I really doubt, how feasible something like that would be for for newbies, I know a lot of windows users who would certainly not manage to make use of something like that - and as soon as you are a user of a unix-based OS the debate becomes pointless as you are likely to be somewhat more familiar with your system anyway and certainly would not care doing the required steps manually. first chking for their old FG, then fetch Boris' tardiffs tardiff itself comes from Steven Stewart Andreason - so it certainly was _not_ mine idea - just to clarify things and give credit where it's due. and patch up their FG install to the latest official FG, SimGear and plib. I think we'll really have to wait for other opinions, I really doubt that it would pay off - simply because the work that needs to be done would probably take relatively long compared to that group of users who might really make use of something like that, but that's my personal view ... ..at some stage, the official tarballs (or a cvs co to the latest cvs release tag) becomes more comvenient, so don't over-engineer it. ;-) I agree, I've talked to Steven Stewart about that and they also think that the current version is going to be the final version for the near future, maybe there'll be one or two small fixes but not many enhancements anymore. It might still become useful to add one or two small features when changes in the fgfs base archive require more sophisticated tracking mechanisms. The only thing that I can currently think of would be an addition to support simultaneous creation of ZIP archives, simply as there are a lot more common for winows and more familiar to its users so it might really make things simpler for those users... -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..update script tardiff (or cvs) idea, was: fgfs aborted with the dc3
A short message for Arnt ! Arnt Karlsen wrote: On Mon, 02 Aug 2004 08:18:00 +0200, Boris wrote in message [EMAIL PROTECTED]: Arnt, how about starting to actually *read* my postings - at least those that you reply to ? :-) ..heh, good catch, could looong length be an issue? ;-) in general I'd agree, but not all messages that I post here are that long - so maybe we could at least agree on reading what we are replying to ;-) and I think Steven Stewart are right in trying to keep things as general as possible, e.g. that way they can use that script for _many_ purposes, so it does have its justification outside the FG world. ..it (tardiff) does, and it looks good, so build on it. I'm currently thinking about Erik's idea to use the CVS timestamps for comparison purpose and to tell then which files have changed, that way it should be possible to determine differences between two CVS versions without the need to really check out both revisions. That way only the stuff that got really changed would be downloaded. IF such an extension is considered a good idea by several users here, one could think about providing externals means for it. ..in this meritocraty, _only_ those ideas that are _acted_ upon, prevails. ;-) yes, I've also come to the conclusion that this is somewhat true here ...ideas/suggestions only seem to be considered really as long as there is something ready ... so you are talking of an automated updater ? ..define automated. = to require as few user interaction as necessary for the updating process. The idea is the user should find an update script over at fg.org, and be able to update to the latest official release, and at least say Yes. ;-) I think we agree here (see above) regarding that one really has to be careful, not everybody has a full GNU toolchain available, even though there are things like Cygwin they do significantly complicate things for novice users - or at least for those who are not really familiar with Unix. (I know that stuff like wget is also available as a standard Win32 compiled version, but it's not per default available on windows ...) ..so test for it and haul it home where needed. ;-) what you are basically suggesting here is an automated install wizard tool - with the ability to retrieve dependencies ... people are working on similar projects, but they are usually pretty complex ... not sure about how much sense something like that would make, we will have to wait for other opinions, ..what suddenly stopped you from forming and voicing your own opinions here? ;-) Nothing, nor do I think that there would be a peaceful way to achieve something like that :-) I was just implying that it certainly does not make sense to put much work into it before several people have come to the conclusion that it might be useful, I still doubt that something like that could be really simple enough for *everybody* ...at least of you want to keep the application itself AND external pre-requisites simple. To be honest: implementing such an application for easy updating as a *shell* script is certainly not going to appeal to the majority of windows users, never forget: only few of the regular (windows) users are really familiar with a shell at all, so in order not see them freak out, one would have to use some graphical frontend, tcl/tk comes to my mind ... Then again everybody would need to have the necessary runtime stuff installed :-/ If you have a good suggestion, don't hesitate to tell me, cause I really think the advantage would be mainly significant if such a tool used (optionally) a graphical frontend... Hey, about integrating the necessary functionality into FlightGear itself, then we'll have a graphical UI :-)) ..I'd rather see them suggest useing tgz, if the idea is get Winzip working. okay, thanks for that suggestion - that's a good one, unix users shouldn't care either way and if it makes things simpler for windows users it should really be named that way, it's going to be added/changed in the next version :-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..update script tardiff (or cvs) idea, was: fgfs aborted with the dc3
Arnt Karlsen wrote: On Mon, 02 Aug 2004 16:08:52 +0200, Boris wrote in message [EMAIL PROTECTED]: A short message for Arnt ! ..Winston Churchill had a great way of having bureaucrats trim their language; it had to be readable without glasses, from across the room, on one sheet of paper, nailed to the wall. ;-) will have to send HTML mails out then, in order for the font size to be appropriate for you :-) Hope this one is short enough for you ! Hey, HOW about integrating the necessary functionality into FlightGear itself, then we'll have a graphical UI :-)) ..whenever pigs fly. Meanwhile, start with a set of shell scripts, and hide them from those chicken Wintendo users who clicks Graphical Upgrade Wizard, and show real people what's going on if they care to learn, it can run in the background, it'll first need to drag home the deps and compile and set them up, then FG itself. well, thanks for all these pointers to shell scripting howtos, but that shouldn't be the problem ;-) Actually, I rather consider the requirement for a GNU toolchain on windows (=Cygwin) to be the problem - and that's what would be necessary in order for the shell stuff to work, hence Steven's approach to use Perl for tardiff is certainly more convenient for the majority of normal users. Everybody who really managed to get CygWin to work, shouldn't mind using the shell for a simple command anyway, I think. ..I'd rather see them suggest useing tgz, if the idea is get Winzip working. okay, thanks for that suggestion - that's a good one, unix users shouldn't care either way and if it makes things simpler for windows users it should really be named that way, it's going to be added/changed in the next version :-) ..that was a joke, with GNU tools on a Wintendo, you don't need Winzip. ;-) _I_ know of course, but thinking of those folks who are not familiar with Cygwin it might indeed be a better way to use standard extensions that are by default recognized under windows - and if that's true for TGZ instead of TAR.GZ that's certainly worth to think about. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] modifying flight dynamics (WAS: Re: at all helicopter enthusiasts1)
The following is information for all those folks who need to _selectively_ read looong postings (Hi Arnt !) ;-) --- Topics in this posting: (Parsing instructions) 1) The first part is about Ron suggesting a specific FlightGear helicopter community. = Simply look for #-ROTARY-### 2) To the FDM folks: Part of this is about Ron suggesting to add support for dynamic manipulation of flight dynamics in order to allow rotary wing aircraft to lift cargo. = Simply look for ##-FDM-# 3) This is about the weather in Germany and Ron's swimming pool for his son = Simply look for #-WEATHER-### ___ LOL :-) ## #-ROTARY-### ## Ron Lange wrote: Boris Koenig wrote: It is quiet simple: either build some new hardware or modify existing. Mechanical everything is possible, depending only on your skills, the electric aspect is also fairly well documented, so everybody who wants may set up his own hardware. yes, I agree that it would probably be easier if such things were documented, but I doubt whether that would still be within the scope of FlightGear itself, on the other hand there was a suggestion to add a scenery specific page to the FlightGear community, I also indicated that I would be interested in such a page if my suggestions shouldn't be directly integrated into flightgear.org itself, so if the whole idea is kept general enough, one could provide some basic community portal that may then serve various purposes, e.g. on the one hand provide easy access to scenery and means to upload user contributions, on the other hand maintain a dynamic FAQ/documentation system about FlightGear and then possibly also a FlightGear hardware customization project :-) In the end you want to save rescue a virtual pilot after an accident ... well, you'd have to implement so many new things, hence I think it would be more realistic to rather implement some fixed scenarios which don't necessarily interact in a multiplayer fashion. As I mentioned in my first heli-posting I fly helis in MSFS a couple of years ago. This time I was about to found a VA for helis, which should be as realisitc as possible. If there's really some support integrated into a flight simulator for the stuff that you are thinking of, a virtual airline might indeed be interesting for those rotary folks ... ## ##-FDM-# ## There are (and now *seriously* ;-) many tasks for such a heli service, eg. powerline checking, agricultural deployment, transport etc, which can be done with all proceedings, ATC etc. In this context interaction with scenery objects (carrying with changed aircraft physics) would increase the simulation feeling IMHO. yes, I agree - thinking about these details now, I also think that the idea in general is really not bad, even though it's a pretty specific one, taking into account that all the necessary work would mainly benefit only a minority of FlightGear users - on the other hand it's insofar pretty interesting as something like this does not yet seem to exist and might really add a good portion of realism to FlightGear, I am simply afraid that the required work itself would not be ingsignificant. But one might begin to address these issues by collecting the ideas and requirements and try to find those things that are not too complex to get implemented into FlightGear, regarding the flight dynamics topic the developer's list has some people who are really familiar with the FDMs and who might hence be the correct people to talk to about the whole idea, so I'd suggest to post a follow up there, too. Talking of that specific feature, this would be mainly about allowing rotary aircraft to carry external loads - regardless if water tanks, cargo or means for resue operations. One would then need to approriately modify the flight model, taking into account the shape and weight of the object as well as its distance from the actual aircraft (pendular movement) in order to deal with aerodynamics/forces properly. Actually, creating the necessary graphical object - in order to display/attach it to the aircraft shouldn't even be such a task, so I would recommend to talk to the FDM guys on the devel list mainly about the modifications mathematically involved. As soon as the basic maths is clear it shouldn't be too problematic to modify the flight model accordingly, basically one could start very simple and provide the shape of an object using a matrix, in the beginning we'd simply assume the object to be massive (without any aerodynamic specifics on either sides like holes etc.) One could then specify the density or overall weight of the object in order
Re: [Flightgear-devel] FMC
Jim Wilson wrote: Harald said: - it's an external application because there is no need to put it in FG code and there would be some complication with the display and keyboard part ; It would actually be very nice to have a FlightGear subsystem for this. Even nicer if it was possible to configure features via an xml config file (since not all FMCs are exactly the same). You can still manipulate data through the property system. It should be very easy to use the NewGUI feature (xml gui) to present a display with buttons as well as pc keyboard input. Having recently thought about means to add FMC functionality to FlightGear myself I would agree with Jim here, there are really many different kinds of FMCs - some with pretty basic functionality and others providing pretty advanced stuff. So, having a basic subsystem as a backend and using XML files as well as possibly also some kind of basic skinning mechanism would certainly be a good approach for the whole FMC thing, since it would not be specific to a certain model or implementation but would rather provide a general dynamic framework for FMC creation/customization - pretty much like the current appraoch to define aircraft or panels. Regarding the GUI, this may be really mainly about adding support for skins and defining clickable regions and possibly different states of buttons - but I would not be that much in favour of using basic PUI elements for these purposes, this might be okay in the beginning but later there should be really support to load a skin and assign certain regions to certain functions/actions or simply events that can be dealt with by using Nasal. Most of the internal logics could certainly be very well handled using Nasal that then accesses the flight parameters via the Property Tree directly. The maths involved for the FMC calculations should also be possible to be realized using Nasal, I'd think - and then there'd still be the option of adding the more complicated stuff as a separate command. That way the CDU could be implemented using some basic skinning mechanism and defining those regions that are clickable and where Nasal should act and then there would need to be a general control for screen output, possibly defining some basics like fonts, rows/colums and available colors - as well as possibly some minor controls like LEDs to display a status information or anything like that. An approach like the one suggested by Jim would certainly have the potential to add many variations of FMCs simply because it would be mainly a thing of specifying the appeareance and logics using a XML file with some Nasal code. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: I know that it would have some advantages if the FMC were part of flightgear, however I tend towards an seperate program like Harald is planning. It could be easily networked so you could use an older computer with a small monitor to put the FMC/CDU on. The FMC program wouldn't even have to provide a text/graphics output necessarily. regarding the ability to easily network it, pretty much all necessary data for that purpose should already be available via the exported property tree, I'd think - of course using a separate machine for that purpose is an interesting idea for some users and one which would not be taken care of if one simply used FlightGear internal implementations exclusively... Of course, if there's running X11 on that other machine, FlightGear could still provide the graphics for such an externally displayed CDU via network without the need to explicitly be running on that machine :-) Would it work to have one node in the property tree that would contain the text on the CDU display ? This should not be problem I think, except maybe that CDUs usually have several lines/columns with individual text and the actual layout differs from CDU to CDU, so you'd rather provide a general node with sub-nodes defining what's getting displayed and where. Also, I'd personally consider it not a good approach to add these things statically to a node, rather they should be possible to be dynamically modified by users who really want to design their own FMC, be it logically or really visually. It should be very easy to use the NewGUI feature (xml gui) to present a display with buttons as well as pc keyboard input. How about the setup in a B747-400 with 3 CDUs (and AFAIR also 3 FMCs). For those building cockpits at home, having more than one CDU, each displaying different pages would be nice :-) IF there is a basic framework for FMCs/CDUs it shouldn't matter how many of these are being displayed, in general it would make use of the same resources, the only thing that would really change is the data/mode being used, so it would be merely a matter of creating several instances of an FMC data object [arrays] to be able to differentiate between all these different systems. That way, each CDU could display specific data. But I'd agree that an approach to add FMC/CDU support externally does have its justification when it really comes to those professional users who are building their own cockpits or simply those users that are using those expensive external standalone CDU units. On the other hand I think one has to ponder about the pros cons, and certainly it would be more of an advantage for the AVERAGE user to have a GENERAL xml-configurable mechanism to add support for FMCs/CDUs to FlightGear than having merely a way to code your own stuff by accessing the property tree via network. As long as its underlying interface is general enough and also accessible within the property node, external software for purposes like the ones you mentioned above, could still easily make use of the functionality provided by FlightGear, while the majority of users could use XML-configured systems. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: On Fri, Aug 06, 2004 at 01:54:06AM +0200, Boris Koenig wrote: Of course, if there's running X11 on that other machine, FlightGear could still provide the graphics for such an externally displayed CDU via network without the need to explicitly be running on that machine :-) x11 yes, but what if not OpenGL capable. well, in that specific example I was referring to the case where a secondy machine would running dedicatedly for the purpose of displaying a CDU for a FMS - so GENERALLY I would doubt that for the display of a CDU there's any openGL stuff necessary, I am not aware of any current CDUs that really make use of advanced graphics - most CDUs could be really implemented by using a simple alpha-numerical display mechanism without the need to really draw advanced graphics. That would exclude running anthoer flightgear instance on that machine. (I'm thinking about old cheap computers. Often those you can get for free) I see - but even though this was mainly only a thought.I really think that there's no need for any OpenGL requirements in order to display something as trivial as a CDU. Indeed, most of the graphics being displayed would be mainly non-active, such as for example the keyboard graphics - which at most _could_ be animated in very basic ways to indicate that a button's been pressed. The only thing that would really dynamically change during runtime would be mainly the screen component on the virtual CDU as well as some minor LED icons. professional users who are building their own cockpits or simply those users that are using those expensive external standalone CDU units. Or homebuilt cheap external CDUs :-) don't know about these, if you've any experience with these it might be interesting, maybe just for the sake of adding support to deal with that stuff, there's probably some basic specification using RS232 or USB for data exchange, I'd guess ? On the other hand I think one has to ponder about the pros cons, and certainly it would be more of an advantage for the AVERAGE user to have a GENERAL xml-configurable mechanism to add support for FMCs/CDUs to FlightGear than having merely a way to code your own stuff by accessing the property tree via network. Another idea I just had: Why not put all the general algorithms needed in an average FMC into a library (possibly as part of SimGear). Things like performance calculations, (access to) route databases, input validation (eg: airport code exists?, does this airport have a runway xxR?),routing calculations,... SimGear itself is rather meant to provide a generic framework for simulations - so, the things that you are mentioning would be rather specific to flight simulator applications hence it would certainly make more sense to directly integrate it into FG itself. On the other hand, I really think that it's mainly about having on the one hand the right data available and on the other hand doing the right calculation with that data. Most calculation can probably already be done using Nasal, there were some examples on the Nasal webpage at plausible.org using a maths function, IIRC. Using a dynamic - non library-based - approach, possibly utilizing Nasal for it, would probably be preferable if all the stuff is available within the Nasal scope, that way one could easily borrow fragments of code from other FMC implementations and add it to your own FMC. Also, this would not require any changes to the FlightGear core, but rather new additions to a FMC could easily be integrated using only a scripting language. So, you'd mainly want to have access to all the relevant data, the first thing that comes to mind would be functions to interactively retrieve data from the navaids/airports file in order to deal with those value accordingly, I don't think that Nasal can already retrieve such data !? In order to really determine what data and functions to access it would be necessary, one would first need to look into a FMC manual and find out what data sources are being used to compute the stuff, OR what -flightgear based data- could ALTERNATIVELY be used for that purpose. For example, one would certainly not want to create virtual GPS or IRS units in order to simulate behaviour such as mapshifts in the beginning. Rather, one could directly use the positional data for these computations. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: On Fri, Aug 06, 2004 at 01:37:11AM +0200, Boris Koenig wrote: Regarding the GUI, this may be really mainly about adding support for skins and defining clickable regions and possibly different states of buttons - but I would not be that much in favour of using basic Yes, and this would not depend whether the FMC in internal or external to fgfs. That's somewhat correct, one could certain re-use such code if it was general enough and could then optionally integrate it natively into FlightGear as soon as it's mature enough for that purpose. Most of the internal logics could certainly be very well handled using Nasal that then accesses the flight parameters via the Property Tree directly. The maths involved for the FMC calculations should also be possible to be realized using Nasal, I'd think - and then there'd still be the option of adding the more complicated stuff as a separate command. Yeah, Nasal seems to be a way to implement a FMC within flightgear. IF you really intend to link to SimGear (I read about it in the thread) you could still use Nasal even externally, as Nasal is not only a separate linkable lib available but also seems to be integrated into SimGear directly, so there's no reason to differentiate between a FlightGear based implementation and a SimGear based version I think. That way the CDU could be implemented using some basic skinning mechanism and defining those regions that are clickable and where Nasal should act and then there would need to be a general control for screen output, possibly defining some basics like fonts, rows/colums and available colors - as well as possibly some minor controls like LEDs to display a status information or anything like that. This is something you'd wanna have in both variants, FMC implemented inside of fgfs or outside as a standalone program. Maybe Harald can provide some more details about what he want to take into consideration and if there are any things that weren't yet mentioned in that thread. I guess the person who wirtes the software will ultimately decide. Right, but as soon as it's ready there shouldn't be any reasons for other people to add custom stuff, stuff which might not have been taken into account in the original version - a modular implementation would then of course come in handy. Or... how about implementing it outside of flightgear at first and then hooking it in when the code is somewhat stable? dito :-) I like the unix philosophy: for every task a seperate program that does only the one thing its designed for. ( make each program do one thing well) I know this is not always appliceable esp. for a flightsimulator, but it could be a good idea in this case. I don't even mention that this whole thread ultimately brings us back to the plugins discussion :-) --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: On Fri, Aug 06, 2004 at 02:34:07PM -, Jim Wilson wrote: ... waiting for a decent open source B744 FMC implementation :) I'd say that would not really that much depend on the availabilty of a FMC/CDU SDK but rather getting your hands on the right docs, as soon as these have been collected it should be much more realistic to that done, I think the idea is great - so, gathering all available information and determining what needs to be done is certainly something that could come in to actually develop the mentioned FMC SDK - because you could use a test implementation of a 737/747 FMS in order to determine the needs and architectural modifications required. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: On Fri, Aug 06, 2004 at 02:26:12PM +0200, Boris Koenig wrote: x11 yes, but what if not OpenGL capable. well, in that specific example I was referring to the case where a secondy machine would running dedicatedly for the purpose of displaying a CDU for a FMS - so GENERALLY I would I migth have misunderstood you. I thought you meant running the CDU in a slaved fgfs. no, I was rather suggesting to use some basic xserver-client mechanism to display graphics created and provided by FlightGear ON EXTERNAL hardware - without the need for that hardware to be sophisticated, using network compression there would not even be the need for much bandwidth, in particular if you take into account that it would be mainly the screen component of a CDU that needs regular refreshing, so much of the actual data transmission could be conditionalized. Ususally, homebuilt CDUs consist of a small LCD w/ TV or VGA interface, the pushbuttons and a piece of plastic resembling the CDU panel. Use an older PC to drive the LCD with a CDU/FMC software running on it (or remotely if using X11) is the latter really an already established mechanism, I was really under the impression for it to be a spontaneous idea :-) SimGear itself is rather meant to provide a generic framework for simulations - so, the things that you are mentioning would be rather specific to flight simulator applications hence it would certainly make more sense to directly integrate it into FG itself. If you look at some stuff in SimGear, you'll see that there are flightsim specific things... and if someone wanted to write a FMS procedure trainer, he could link simgeear in, but wouldn't need any flightgear stuff. AFAIR, Flightgear doesn't build any libs that are used by 3rd party programs. I see your point To me, SimGear seems the perfect for the kind of routines I mentioned. but see my previous post: using SimGear as a backend for the calculations there would not be a reason to drop the mainly Nasal based approach for the actual implementation of the logics involved - which would then have many advantages talking of flexibility. In order to really determine what data and functions to access it would be necessary, one would first need to look into a FMC manual and find out what data sources are being used to AFAIK FMCs (at least the ones used onboard Boeings) use airdata, IRS, and possibly GPS. They can control (nav-)radio tuning, ACARS... They interface with the autopilot, flight control computer and probably a bunch more. I also remember something about weightbalance. yes sure, that's the common sense knowledge that most of us have here, but actually there's still a bit more to it - which is probably easier to find if you really get your hand on a FMS (training) manual, actually that would be quite a sufficient source because you could design the whole FMS - page by page - after it. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: On Sat, Aug 07, 2004 at 12:51:02PM -0400, Ampere K. Hardraade wrote: I think newer Airbus aircrafts have CDU's that have a more advanced GUI. http://www.flug-revue.rotor.com/FRheft/FRHeft04/FRH0401/FR0401c1.JPG looks like the A380. Is the overhead panel really a screen ? It looks like a big LC Display... yes it is, but not in the actual aircraft - many of these preview pictures are based on computer generated images for media purposes, on the other hand there are also simulators being developed that cannot yet make use of the real hardware and hence seem to use a workaround - using a LCD (touchscreen) as the overhead panel does reduce development costs, you don't need to use -not yet existing- hardware but can rather display a basic representation of the controls that are supposed to be available and can easily integrate an interface with the rest of the simulator components, but there are more recent pictures of the A380 available at airbus.com. --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Ampere K. Hardraade wrote: It will be good if we can have some generic Graphic Interface for FlightGear. Not only can it be used on the CDU, it can also be used on other flight displays. So, you are also talking of script-able ways to implement basic animations or what exactly is it that you're talking about ? I would agree that pretty much most more advanced avionics could be easily implemented if there was some basic support to animate things. But if using Nasal for that purpose really slows down the sim, that's certainly not such a good option... Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Harald Johnsen wrote: Would it work to have one node in the property tree that would contain the text on the CDU display ? The 3D cockpit could listen for changes to this node and when one happens, update the CDU display in the 3D cockpit... I like this idea, the text could be use for the FG cockpit or for some external CRT CDU. It would not only be one line of text in most cases, but rather using one node for everything would make some basic formatting necessary to assign certain fragments of a string to certain locations on a CDU screen. Except that the 3D cockpit can't handle text display atm. The 2D panel can. Sounds like a feature request to me ;-) Using a dynamic - non library-based - approach, possibly utilizing Nasal for it, would probably be preferable if all the stuff is available within the Nasal scope, that way one could easily borrow fragments of code from other FMC implementations and add it to your own FMC. ... My first idea was to write everything in Nasal ;) But due to some limitations in FG I have decided to start with an external FMC. Okay, I see - I know that situation somehow myself, would you care to elaborate on the exact limitations and what would be needed to be added to Nasal/FG in order for you to be able to use Nasal for most of the logical implementation ? I think it would definitely make sense to address these issues, it's not long ago that I brought up a very similar topic, where the solution to the problem would finally mean to adapt the Nasal-FlightGear interface and add additional functionality, something that was quite controversially discussed here, so in that context it might very well help if you could individually address the shortcomings that *you* encountered to really show that there'd be also need by other projects/ideas to be able to use more features within Nasal than those that are currently available. Once it start to work I'll see how to make a buildin version. so, did you drop the Nasal based approach entirely because of the problems you mentioned above ? We are talking of an FMC but of course I wanted to redo at least the ehsi display (for the eye candy). Erik mentioned some time ago that it isn't yet really possible to do simple animations using Nasal in FlightGear, at least that's what Andy indicated when he was asked about that, I think. So, I doubt that there'll be an easy way really soon to simply create/animate a NAV display that would fit to a FMC using Nasal - simply because most of its modes require some kind of animations, which all differ from make to make. Now there is a few problems with 3D gauges : can't draw text, can't draw dynamic occurence of sprite/texture. Similar limitations with 2d gauges concerning the dynamic part. So I was thinking about draw to texture technique and some graphical api in Nasal to generate that kind of display... well, good luck: would also like to see something like that to be available, so there'd be already TWO FlightGear based ideas that might benefit from an extension to add basic animation support to Nasal - hey, doesn't this sound convincing ? :-) This would have delayed the ehsi too much. is there really that much lag involved when doing such things using Nasal - i.e. NO smooth animations ? So, you'd mainly want to have access to all the relevant data, the first thing that comes to mind would be functions to interactively retrieve data from the navaids/airports file in order to deal with those value accordingly, I don't think that Nasal can already retrieve such data !? It's not difficult to add a few interfaces to acces this data. nope, but very few people here seem to be in favour of extending Nasal in a way to add more enhanced functionality - I did make suggestions for similar interfaces, did also offer to take of such things myself, but ...didn't even get much feedback about what _might_ be added and what not. Even waypoints can allready be added just by touching the right property but the code in auto_gui.cxx is too restrictive about the type of wp one can insert. Also, you'd usually want to have an array of waypoints as well as the possibility to add inactive waypoints, i.e. setting a certain property in each WP if its active or not. And then there's of course the scenario that Manuel mentioned, where not only one FMC would need to available but rather 2 or even 3 FMC which act indenpendently from eachother, so accessing all the same properties in the first place would tie them together. Hence, you'd usually rather want to be able to determine what data actually feeds the FDM and what data is merely backup data of another running FMC. In order to really determine what data and functions to access it would be necessary, one would first need to look into a FMC manual and find out what data sources are being used to compute the stuff, OR what -flightgear based data- could ALTERNATIVELY be used for that purpose. FG has the needed databases for the routes (airports, runways, nav, airways).
Re: [Flightgear-devel] FMC
Harald Johnsen wrote: As I said before I don't have all the knowledge to build it enterely by myself so I will need a lot of feedback at the beginning (the fonctions of the fmc but also the look and feel). Besides projectmagenta.com that I mentioned in my last reply there's also another possible -free- source of information, Wilco's 767 PIC - they've put all the manuals for their simulations on their webpage for easy download, so fetch: http://www.wilcopub.com/downloads/767_FMC.pdf While this is of course not for the 737 or 747, the general stuff will apply in most cases anyway, at least the handling doesn't seem to differ too significantly. It's actually quite well illustrated and explains most things quite simple, of course it is mainly targeted at gaming people, but would certainly give a good basic introduction regardless of that, one could still read up on the more complex topics later on. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: http://www.fmcguide.com/ Sure, besides several other locations where you can PURCHASE such professional material, but I guess you aren't suggesting to really buy that stuff just for some basic mechanisms to be implemented, otherwise you'd probably be the first one to be asked for a corresponding donation ;-) Obtaining commercial training material would not be the problem ! But, I'd rather suggest that we continue to collect sources where the necessary information can be obtained free of charge, be it by browsing through various threads at forums like pprune.org, looking into other FMC software (demos) and their manuals or by simply copying the relevant stuff from the original AOM of an aircraft. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: On Fri, Aug 06, 2004 at 09:17:21PM +0200, Boris Koenig wrote: I don't even mention that this whole thread ultimately brings us back to the plugins discussion :-) I'm thinking more in terms of named pipes/fifo sockets... right, whatever comes to your mind that serves the ultimate purpose to enable dynamic extendability :-) But the costs are adding all the dlopen stuff. I don't know of platforms other than Unix/Win32 either, but talking of these two platforms it's not really that involved to load a library and execute a set of functions or passing parameters, that was not even considered a problem by other developers here - in the end one could even use a cross-platform plugin library in order to take care of differences amongst platforms, the first that comes to my mind would be korelib from thekompany.com, don't have any experience about Mac development, though- so don't know if that lib also works easily on a Mac. Not sure if the other platforms make it easier here. (I haven't followed the plugin thread) I wasn't preferring (binary library based) plugins in particular but rather the thread was about adding general means to dynamically extend FG, be it by using a more powerul scripting interface, using binary libraries or whatever. And that's something that could ultimately benefit various projects that would need to interface with FlightGear. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: On Fri, Aug 06, 2004 at 09:27:02PM +0200, Boris Koenig wrote: Use an older PC to drive the LCD with a CDU/FMC software running on it (or remotely if using X11) is the latter really an already established mechanism, I was really under the impression for it to be a spontaneous idea :-) No it wasn't an instantaneous idea. yes, it was (at least on my side) - don't forget, that it was me who initially brought that idea up in this thread, regardless of the obvious fact that you've already realized the whole thing :-) But I am really amazed, that it's already implemented exactly that way :-) I have a prototype CDU panel (made from paper, overhead transparencies and transparent contact paper). http://cockpit.varxec.net/panels/img/cdu_panel1.jpg in what graphics format did you design that panel ? I think Harald might be able to use a good template as a basis for a first skin. So, if you got that panel in some common graphics format available- preferably most of it as a vector image, one could easily use such an image as a template for a skin based CDU and would already have a usable basis for the rest of it. So, one of the first steps would be to load such a vector image, display it in a window and assign functions to clickable regions. Then another part of the whole panel would need to be defined as a screen region that can be updated. Check out X11GC, a x11-based glass cockpit software I'm working on. Thats whats gonna drive my CDU. But for the logic behind it, the FMC, it'd be nice to have a standalone program... :) yes, I see - looks indeed quite promising ! do you have any materials about FMCs/CDUs ? I sent already an eMail to Harald offering to exchange the stuff that I've got here. So, maybe you've also got anything that Harald might find useful ? the X11GC page: http://cockpit.varxec.net/software/x11gc.html so, then you are feeding FlightGear data to an application that then uses a xserver and then connect that to a client ? Well, Nasal doesn't fit too well in my standalone concept. I already have a scripting language integrated into my X11GC/PHCC* programs (They share some classes, and can be built into one binary). I use LUA, an embedded scripting language. http://www.lua.org/ Easy to learn and easy to integrate into your own programs :-) yes, I know lua - and have used it for some smaller things myself, and actually I am again looking into it ...but on the other hand FlightGear has already Nasal and speaking of my personal ideas, it would be really a bit pointless to use lua instead of Nasal simply because Nasal is not supposed to become everbody's swiss army knife. On the other hand, a Nasal based implementation of the logics could still work - either using the Nasal library itself or simply using the network for data exchange. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] openGL bindings for Nasal (was: FMC)
just adapted the subject to have the right people look into this thread ;-) Harald Johnsen wrote: We are talking of an FMC but of course I wanted to redo at least the ehsi display (for the eye candy). Erik mentioned some time ago that it isn't yet really possible to do simple animations using Nasal in FlightGear, at least that's what Andy indicated when he was asked about that, I think. I remember but I had the impression that they were afraid for the performance. Don't know about that, actually I thought it would be too complicated to get Nasal doing dynamic animations. Will have to check the threads, though ... But even if can extend those fonctionalities there will always be some cases that can't be handled. Lets call them owner draw gauges. How to draw them ? Boris says: PLUGINS *or* scriptable dynamic extensions :-) With pure opengl code in C. This is the first bottleneck. It seems stupid the have to build Flightgear to use a new gauge when someone release a new panel or new plane. I wholeheartedly agree ! [...] Now how do we draw in this texture ? In Nasal of course, with the appropriate graphic library. Not a pseudo opengl library because there is no more than perhaps 10 api to implement : draw a line, draw text, draw a texture, etc. I am prety sure we can pair this api to the existing draw code. I like the approach, actually the scripting language that Manual mentioned in this thread (lua) does also have openGL bindings, if I remember correctly it was called luaGL or something like that, so one might look into it, to see what could be useful for a NasalGL implementation as well. Having some basic scriptable openGL mechanism one could really start to create EASILY more advanced instruments - without the need to add a lot of stuff to FlightGear itself. And it would certainly benefit other FlightGear based ideas as well, Erik mentioned that he wanted to implement a weather radar, which would certainly also be a lot easier if it could be done using scriptable openGL dialect. But on the other hand, don't know how well such an approach would fit to the current way Nasal is being used/called in FlightGear. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Ampere K. Hardraade wrote: I think newer Airbus aircrafts have CDU's that have a more advanced GUI. http://www.flug-revue.rotor.com/FRheft/FRHeft04/FRH0401/FR0401c1.JPG Most current images seem really to be mainly computer created, but check out: http://www.airbus.com/MultimediaElements/139.jpg http://en.wikipedia.org/upload/b/ba/A380.flightdeck.750pix.jpg What's interesting though, is the integrated Chart-Database with LCD screens on either side of the cockpit ! Unfortunately, there were not any images of the A380's MCDU - but I did read that it's supposed to be controlled by a simple stick/mouse replacement ... I wonder, how easy this will be to be done in-flight, though :-/ But a multi-color display (well, at least tri-color) would certainly be a good idea for the CDUs of the future. I was talking about having a libary-like interface that can allow the user to implement basic and advanced animations really easily. Okay, I think we agree here - Harald suggested already a basic framework for it, so it might make sense for those instrument designers to also make some suggestions about what exactly might be needed in such a library. P.S.: Harald, you might want to check this page, too: http://users.pandora.be/B737/serv03.htm - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Erik Hofman wrote: Boris Koenig wrote: Most current images seem really to be mainly computer created, but check out: http://www.airbus.com/MultimediaElements/139.jpg http://en.wikipedia.org/upload/b/ba/A380.flightdeck.750pix.jpg What's interesting though, is the integrated Chart-Database with LCD screens on either side of the cockpit ! I think this is just the weather radar. I'm afraid you're wrong (I was referring to the latter image) - this seems actually like an airbus version of Jeppensen's electronic FlightBag - simply not relying on an external notebook anymore, but rather connected to the systems of the aircraft. Check airbus.com for it: it's supposed to enable the flight deck crew to easily display/use charts without the need to look them up in the big paper thing - which will still be available as a backup, though. Also, it's supposed to display a profile view (layered) ON the charts to improve situation awareness. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Back online
BTW, I'm also back ... so guys, prepare for another bunch of daily 100 kbytes messages :-) P.S.: Erik, I don't seem to have received a reply to my last eMail from you, just tell me if you need more clarification - otherwise some of the questions that I asked are still left open and I would like to get definite feedback regarding the probability for acceptance of my code modifications for the official CVS version - still aiming at adding CBT related funcitonality to FlightGear. Thanks Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] next release - ac that don't work
Giles Robertson wrote: Automatic gearboxes fail too often on the road, without much warning, for me to want one in a chopper. At least if a fixed wing engine fails you can attempt to glide. I've talked about that to a real helicopter pilot at our local club: Most real rotary pilots would tell you then that they'd much rather be autorotating down to the ground from 100 ft than glide from an altitude ten times that much in an airplane... Taking into account that your odds to find a reasonable spot to land are usually much better in a helicopter than in an airplane, this sounds convincing to me. On the other hand, the European (JAA) syllabus for the PPL now requires new students to be proficient in no-engine landings, where your instructor takes you to an altitude of say 1000 ft and shows you how to reach the threshold without engines. While it's certainly a good thing to be familiar with such a situation, the whole thing gets pointless if there isn't a runway, road or whatever ... So, I can understand the rotary folks who keep telling you that they feel a lot safer in their choppers in that regard :-) But then there are of course also limiting factors for the autorotation to work (e.g. altitude speed) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nasal'ing ...
Hi ! Two things: 1) I would like to be able to display a simple text string at runtime in the upper left corner of the screen using Nasal (in order to display simple in-flight information). I could imagine that something like this already exists, i.e. for displaying ATIS or traffic information during flight, is there a specific node within the property tree available to set such a message item dynamically so that's then displayed automatically ? That way one could easily use Nasal to display runtime info, one could also use such a feature to indicate things like that the game's been paused (which is currently not being displayed) And I hardly dare to ask: if such an item doesn't yet exist, would anybody mind such an addition ? 2) And: Is it possible to load a Nasal file while the game is running and execute it then ? I don't think there's any documented way to do it-a corresponding menu item certainly doesn't yet exist ;-) - at least I haven't seen anything like that, basically I would like certain scripts to be available/executed on demand, and not automatically be loaded/executed each time at startup (Nasal subfolder), that way it would be also easier to have multiple configurations running. Thanks -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal'ing ...
Hi ! Thanks for the answers so far, I was already playing around with the gui.nas file, will have to look into it in more detail in order to see how to get the positioning part done, though. I will get back to the original replies within the next days, but a quick question: is there any way to make FlightGear re-initialize the Nasal loading routines ? I'm referring to those files within the Nasal subfolder that are automatically being made available as modules, I have tried all items within the debug submenu - unfortunately, none of these would also make FlightGear re-load the files in the Nasal folder, hence I still have to re-start FG for each change that I make to files that are in that folder, which is pretty inconvenient. Is there any undocumented fgCommand that I could use to have FG re-initialize the Nasal interpreter ? If not, it would probably fit quite well into the debug menu :-) What do you guys think ? While at it, Andy: I've read on your webpages that you can directly pass Nasal code to the interpreter and execute it then using the parseAndRun() method. Where exactly (in the FG source) is the object instantiated for the interpreter ? I'm asking this because I would like to add some simple way of Nasal-console to FlightGear, not even necessarily within the GUI-part (even though that would also be very neat), but rather I would simply open another console in order to pass nasal commands at runtime. Having a simple interactive console would certainly also be useful for other purposes. I think this would particularly simplify the development process, at least for the testing/debugging part of nasal code ... (Maybe, one could even export a new node within the property tree named current-nasal-cmd in order to be able to pass commands via telnet - another node nasal-status could keep the result of an operation (error code, string ...).) Thanks - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FG-webpage addition (tardiff created base-package patches)
(I'm sending this directly to the mailing list, as I haven't yet received any replies from Curt himself, who's probably too busy anyway) As I mentioned already on the user-mailing list a couple of days ago, Stewart Steven Andreason have finished their tardiff script - a perl script that creates patch files for two different versions of tar-archives. This script has meanwhile been heavily modified, so that it should now be able to deal with most 'track-able' changes between two different versions of an archive, and thereby reducing the required download time, as only a patch needs to be downloaded and not the whole archive itself. This is interesting and relevant for FlightGear cause it enables easy creation of (usually) *SMALL* patch archives, so that users won't have to download a complete base-package (~ 90 MB) from flightgear.org if they want to upgrade to a newer (pre-)release. So far, the patch archives between two successive versions were usually approx. 2-5 MB in size - so this is indeed a significant reduction of more than 90 %. Of course, the exact size is likely to vary in the future, depending on the changes that are being made and whether tardiff itself is smart enough to track them down. But even the patch from 0.9.4(final) to 0.9.6-pre1 is 'only' about 25 MB- so less than 1/3 of the actual base-package download itself. QUESTION: Because of this obvious advantage (particularly for users with slow dial-up connections, but also for those among us who have broadband access, but don't like to wait... ) we would now like to know what the rest of you thinks about adding those tardiff based patches as an OFFICIAL alternative *directly* to the FlightGear webpage as option to the downloads section for FlightGear's most recent base packages. + As most FlighGear users probably won't want to run 'tardiff' directly, but would rather choose to only download the created patches for their respective fgfs-base directory, a sourceforge project was set up. Actually, the whole process of applying the patch is rather simple, it involves only: - determining what base package version you're using right now - download the correct patch for the latest fgfs-base package - backup your existing base-package (just in case ...) - apply the patch by extracting the patch-archive - running the final finish-script - (a unix win shell scrip) = DONE ! So, the plan is, to also provide future patches via that sourceforge project - this is a very straight forward process and takes less than 5 minutes. At: https://sourceforge.net/projects/tardiff you can find the project's sourceforge page, where the patches are also being made available - the homepage (including extensive documentation) can be found at http://tardiff.sourceforge.net - tardiff itself is general enough to be also used for other projects, too. So, ultimately this would not only reduce traffic for flightgear.org and its mirrors but it wouldn't even consume any resources on flightgear.org or its mirrors either. Thanks for your feedback. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG-webpage addition (tardiff created base-package patches)
Erik Hofman wrote: Boris Koenig wrote: Because of this obvious advantage (particularly for users with slow dial-up connections, but also for those among us who have broadband access, but don't like to wait... ) we would now like to know what the rest of you thinks about adding those tardiff based patches as an OFFICIAL alternative *directly* to the FlightGear webpage as option to the downloads section for FlightGear's most recent base packages. I find it a useful addition for modem users, but my only concern is that it will increase the number complaints about something not working while in fact their base package is somehow corrupted. While there were -so far- not any problems regarding something like that, I did also think about that possibility - that's why I would recommend to only release those patches that have been tested by running each created patch against the (old) base-package that it is supposed to patch, and directly compare the resulting (patched) folder structure with the one of the actual (original) base package, BEFORE publishing future patches. While it would be additional work, it can surely be automatized using a simple shell script [1], but we would at least make sure that the patch creates an identical folder structure. So, only those patches would be released. Boris [1]: patches could be checked for their validity by using the already created checksums of the original archive, possibly using the finish shell script. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBsim with Solaris8/Sparc and GCC-3.4.1
Jon Stockill wrote: On a similar toolchain related theme, I just upgraded a machine here to slackware 10.0, which uses autoconf-2.59 and automake-1.8.5, which caused all sorts of problems when attempting to compile current cvs versions of simgear and flightgear. Rolling back to autoconf-2.57 and automake-1.7.7 fixed the problem. If it's something we should be fixing at our end then I'll upgrade again and get more details, if it's an autoconf/automake problem then I'll just hold off on the upgrade until I know it's fixed. If you keep receiving errors/warnings about underquoted definitions in M4 macros, it's most likely really pretty much the same thing as with gcc: the autotools folks intend to become much pickier, too - so, in that case it's not really a FG issue but rather the new versions enthusiastically complain about macros that their old counterparts happily accept - so that kind of issues does not occur if you aren't up to date :-) If I remember correctly, there was also some info about that on the autotools page. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
John Wojnaroski wrote: Hi, The last month or so I've been working with adding synthetic speech and voice recognition to my 747 project. What type of project is that ? - (FlightGear related ?) The results have been quite good; unfortunately it's kind of hard to demonstrate or display the results. lol, right - except of course if you want to shoot a movie :-) But for those amongst us who have no local festival engine, it might be illustrative to hear some simple ATC phrases (generated by festival) for download, somewhere at http://www.cstr.ed.ac.uk/projects/festival/ you can find a link to a web-based interface to a festival engine, whose output will then be sent to your browser. Jim Brennan is preparing a corpus of messages and ATC phrases which will be used to create a LM (Language Model) for speech recognition and the synthetic speech voices come from a variety of sources -- most notably, the FestVox folks at CMU, MBROLA, and the OGI-Festival project at CSLU. Not that sure, though about the speech-recognition part, I simply think there are too many variables and limiting factors, to really make it feasible within the near future - maybe I'm simply being to pessimistic ;-) But of course speech synthesis just itself would already be advantageous to have. Both the ASR program and TTS program can run as applications (foreground or background) on a single machine interfacing with FG via the loopback IP address 127.0.0.1 or on additional machines connected via a LAN. ...or on tts.flightgear.org as an on demand stream-server, offering centralized speech synthesis even for users with slower machines ;-) Just wondering if there is any interest in adding this capability to FG. I think, definitely yes - TTS/speech synthesis-ideas have been brought up various times here, looking for TTS or directly festival within the mail archive returns threads like: http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg20744.html [OT:] (BTW: even without a locally installed search engine -several were suggested - for flightgear's mailing list archives on flightgear.org, it would be nice if the addresses to mail-archive.com could be added to http://www.flightgear.org/mail.html where you keep reading: There is currently no search capability [...]) But getting back to the old discussions: so there seems to be a great interest in it - pretty much most of FlightGear's counterparts are meanwhile equipped with basic TTS functionality, so why not FG, too ? About all that is required is a socket-type (IPC) interface to send the text string to the TTS application in the specified wrapper, and the TTS program (Festival) running in server mode to create an audio signal. I have recently looked into the IO handling stuff, as well as the ability to use xml-definable protocols , looks to me as if these two things could come in handy when it really comes to establishing a simple IPC mechanism for FlightGear - festival interaction. Maybe using a new node within the property tree that does not only hold the string to be processed, but also the respective rules that apply, cause one would need to define some kind of aviation specific dialect, in order to have festival speak special parts of a transmission using a separate rule, like for example a callsign, which shouldn't be spelled character by character, but rather converted to it's ALPHA-ZULU-equivalents. (Just as a simple example meant though ...) Of course it would later on also be interesting, to have festival bindings available within XML-configurable sound files, so that not only audio files can be played, but also speech dynamically synthesized on demand, thinking of the logical implementation of more advanced airliner mechanisms like the GPWS, it would certainly come in very handy to suddenly be able to make FlightGear 'talk' to the user, like Terrain Terrain Terrain ;-) In addition to interactive inputs, the TTS program will receive comm traffic from other AI controllers that produce communications with other model entities active in the simulation. The most frequently requested words/phrases could even be buffered either locally within FlightGear's base package directory (using a pre-defined buffer size), or indeed remotely as I suggested already above, that way one could actually create a rather comprehensive repository of common ATC chatter, and use a similar mechanism to that of terrasync, by rsync'ing such snippets on demand - in order to take care of different bandwidth, the ATC submodel might have to pre-request some files, though - so that they are available when needed. Installing, compiling, and configuring the TTS and ASR packages requires a little work, but it's not brain surgery. While the compiling packaging part is a no-brainer for the windows folks, one might ponder about offering statically linked versions of festival for most common other platforms and put 1-3 of these packages (including the proper configs and plenty of sounds) directly on the
Re: [Flightgear-devel] Nasal'ing ...
Andy,
Thanks again for your last answer, it was indeed very precise and
helpful - but I'm not yet even getting back to the last reply,
rather I'm facing a new problem and wanted to ask you for your
feedback - I have got the following scenario:
I don't seem to be able to access a method like gui.Widget.new()
from an object defined in another module, even though I _think_ ;-)
I'm doing the right thing, basically that is:
two .nas-files stored in /Nasal/ whose contents will be made
available as modules within Nasal.
Now both of these contain objects, for example:
#test1.nas:
bla = {};
bla.method = func {
print test1.bla.method() was called);
}
Now the other file:
#test2.nas
foo = {};
foo.method = func {
#Now I want to call test1.bla.method()
test1.bla.method();
};
The call to test1.bla.method(); does not seem to work
though, hence I thought this might something like a
namespace issue in C++ - do I have to use a special
notation in this nested example in order to actually
call the required function ?
Maybe, it's something terribly obvious ...
Thanks !
(wow, one of my shortest messages !)
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal'ing ...
Sorry folks, this going to be a longer one ... Andy Ross wrote: Boris Koenig wrote: Thanks for the answers so far, I was already playing around with the gui.nas file, will have to look into it in more detail in order to see how to get the positioning part done, though. Essentially, you can just set x and y properties on the top level gui object. Yes, thanks for that - actually I meant _positioning_ part - I have now decided to simply use \ns for that purpose :-) Regarding the positioning, I did only have to additionally provide my own x/y values to a copy of the popupTip function - without really looking much into the widget object itself. There is a Widget helper class in there that can take some of the tedium out of handling the raw property interface. See the code for the fuel/weight dialog (gui.showWeightDialog()), which uses this API. yes, thanks - I was going to ask you about that weight dialog anyway: isn't that what you are doing there exactly what I wanted to do when I asked about dynamically creating dialogs/dialog-elements using Nasal - instead of using the hard-coded XML-files ? I'm not sure if you remember, but some time ago I posted a screenshot of FG showing a XML gui file with various dialogs and controls that I created manually, here: http://flitetutor.sourceforge.net/include.php?path=content/content.phpcontentid=23 So, it seems like I can already create the dialogs itself - not sure about how well all of the controls are supported, though - (like, edit box, combo, buttons). But I did meanwhile play around with the mechanism that you used in that example, and I'm surprised to see that it _seems_ already quite possible to dynamically create a gui ... I haven't yet tried to create every PUI - control, but so far it's already extremely usable. Besides the fact, that combo boxes seem to be opened upwards by default - which is not feasible in some situations (e.g. look at the upper dialog on the screenshot) - so, an additional property like upwards/downwards might be useful - cause PUI itself allows such a specification already. Also, it seems to me that that the width property for combo boxes isn't being properly dealt with - even though I can (dynamically) create a PUI combo box control, the width value for that particular control does seem to be ignored - it's always displayed using a fixed width (no layouting applied !) - if you want me to send the corresponding code, just tell me. I will get back to the original replies within the next days, but a quick question: is there any way to make FlightGear re-initialize the Nasal loading routines ? Not currently. Adding it wouldn't be difficult, but the interaction issues can be very complicated. Existing Nasal code (loaded via the aircraft XML or other configuration) might be holding references to values in the the pre-existing modules. Okay, so then it would make more sense, to not only re-load the modules in /Nasal/ itself but rather also all the other stuff in order to circumvent potential problems ? So, basically I would also need to use void FGNasalSys::loadPropertyScripts() again, in order to load the Nasal scripts from the property files ? If those get used, you can end up in a situation where the old and new versions of the file are in use simultaneously. Likewise, think of timers registered by the old version that get run after the new one is loaded. but, this shouldn't happen if the other Nasal code gets reloaded, too - right ? But if you are careful about things and/or willing to troubleshoot this kind of issue, there's no reason it couldn't be done. I was actually not even looking for a really fool-proof way, rather it would already be perfectly sufficient not to have to re-start FG each time for every single modificiation to one of the Nasal-modules. So, I would not mind doing all the reloading again. Take a look at NasalSys::init() in src/Scripting/NasalSys.cxx. You'll want to extract the loop at the end (where it loads the files) and make it available as a fgCommand binding like nasal-reload or somesuch. Thank you ! That was as helpful as the source code itself :-) You'll want to delete the pre-existing modules first, of course (by doing something like globals.gui = nil;, either in Nasal or using the extension API). As I'm not really familiar with all the internals, the safest way would probably be, to simply 'nil-ing' all the modules manually using Nasal, instead of actually deleting the hashes within FG, I think. Also, what's the preferred way of implementing a basic event loop using Nasal, I've played around with this by using either a normal loop, or a timer - what's the best choice to poll a certain node from the property tree and act upon it assuming a certain value ? Basically, I want to monitor several nodes at once and call a function (that then changes other properties) as soon as a certain condition is met. - Boris P.S.: To the doc-maintainer(s): How about adding all the Nasal
Re: [Flightgear-devel] Nasal'ing ...
Andy Ross wrote: Boris Koenig wrote: 2)And: Is it possible to load a Nasal file while the game is running and execute it then ? Not currently. Adding it would actually be non-trivial, because (as in most similar languages) loading and running a script are the same thing. Being able to load a script from Nasal code is equivalent to running a recursive Nasal interpreter context, something that the current implemention doesn't support. So, if I really wanted to execute a script, I would really have to first nil'ing all existing nasal modules as well as the scripts from the property lists, in order to re-load then all of it INCLUDING the new file ? I suppose we could wire up an fgCommand that did a script load, which would work fine so long as you called it from a non-nasal context (keyboard binding, etc...). yes, actually I was not even (yet) thinking of loading one script from another one, rather I would like to have a way to load a particular script on demand, using a fgCommand linked to the menubar for that purpose would definitely be already sufficient. Fixing the interpreter to allow multiple contexts is definitely worth doing. This would also allow for a non-callback API, where a script could sleep for a bunch of frames and be woken up later on. This sounds at lot like the solution to a problem that I just mentioned: the event loop issue, so how are callbacks currently handled in Nasal ? -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
John Wojnaroski wrote: - Original Message - From: Boris Koenig [EMAIL PROTECTED] What type of project is that ? - (FlightGear related ?) See the FG Project webpage for details oh well, it's always the obvious ... :-) 3) One of the advantages of TTS (at least as I see it) is you don't have to create snippets or prestore anything. Sure, right - I was only referring to these (downloadable) snippets as a supplement for the whole thing itself, particularly for those users who won't set up a TTS, be it because they don't want to or it's simply not that easy, so for such cases it would be possible to use a centralized TTS that delivers the snippets on demand - of course that'd be pointless when you got a TTS running locally. One has the luxury of total and complete freedom to create any and all possible combinations of words within the established language model and create the audio in real time. 4) Speech recognition for converting audio to text is just about perfect. Well - you may be right, also getting the recognition rate sufficiently high is certainly less an issue for native speakers - except maybe Australians ;-) but for average foreigner it's quite an adventure to make a speech recognition engine recognize his/her English ;-) The trick, as you noted, is having the machine understand what was said... I'm going to think more about that later, but probably there are others, too who have ideas about how to realize the logics or troubleshoot certain problems for such a thing as a fully interactive scriptable ATC-TTS engine - so, maybe we can even come up with a draft for a -hopefully- working logical implementation of this whole thing. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] webpage update
[# 243] ;-) Norman Vine wrote: Boris Koenig writes: [OT:] (BTW: even without a locally installed search engine -several were suggested - for flightgear's mailing list archives on flightgear.org, it would be nice if the addresses to mail-archive.com could be added to http://www.flightgear.org/mail.html where you keep reading: There is currently no search capability [...]) Bah please try this link http://www.google.com/search?hl=enie=UTF-8q=Boris+site%3Aflightgear.orgbtnG=Google+Search Thanks for that one Norman - *really* helpful ! but: 1) This is _not_ about *my* postings ;-) 2) This is _not_ about *my* need for a search engine, I happen to store everything within my mail client,anyway... So, I mentioned this only because this is obviously a questions that comes up relatively frequently - not so much on the devel-list, but rather on the user's list, if you don't believe me Norman, check the archives ;-) Maybe you simply got me wrong, I certainly don't mean to be annoying by mentioning these things, or making offers such as setting up a dynamic FAQ system or BugZilla for Flightgear ... Rather, I just think these things are part of being user-friendly - you may admit it or not, but you folks are mainly *developers* - not really *users* (at least when it comes to FG): So your point of view is pretty likely to be different from that one of an average user, saying: what you consider ridiculous or rather self-explanatory may simply be _convenient_ for a *user*. And this does apply to MANY things, not only a webpage. I don't think I need to go into more detail, tell me though - if you want me to ;-) Of course updating such a section on a webpage would be simplified if the page was maintained by a simple CMS and not via CVS ... - where obviously only a minority of people has the access priviledges and _time_ to add things that others consider useful, you know - there were other suggestions, too - so I'm not the only one who likes to recommends one or two things ... Anyway - if I'm not terribly wrong you should have CVS access, so maybe you can afford the time to apply the enclosed patch ;-) Thanks regards - Boris --- mail.html Sat Sep 18 20:00:34 2004 +++ mail2.html Sat Sep 18 20:02:21 2004 @@ -100,11 +100,14 @@ FlightGear-FlightModel Archives/A LI A HREF=http://mail.flightgear.org/pipermail/flightgear-users; FlightGear-Users Archives/A - P + PP + You can search the archives by using: + LI A HREF=http://www.mail-archive.com/flightgear-devel%40flightgear.org/;Mail-Archive.com (flightgear-devel)/A + LI A HREF=http://www.mail-archive.com/flightgear-users%40flightgear.org/;Mail-Archive.com (flightgear-users)/AP LI A HREF=http://www.menet.umn.edu/~curt/lists/fgfs/;The Historic FlightGear mailing lists archives/A. - LI There is currently no search capability that I know of, but I - will investigate this. + !--LI There is currently no search capability that I know of, but I + will investigate this.-- /UL !-- Standard Footer Begin -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
Chris Metzler wrote: On Sat, 18 Sep 2004 07:22:46 +0200 Boris Koenig [EMAIL PROTECTED] wrote: [OT:] (BTW: even without a locally installed search engine -several were suggested - for flightgear's mailing list archives on flightgear.org, it would be nice if the addresses to mail-archive.com could be added to http://www.flightgear.org/mail.html where you keep reading: There is currently no search capability [...]) I thought everybody knew about Google. lol, this getting a really hot discussion ... Please don't get me wrong: I know about google, and so does probably everybody else here, probably even on the user's list. But it's not terribly obvious that you have to use google in order to search the archive, hence the previous comment was also somewhat misleading. Because one could easily interpret it as there is no such thing as a search function - while there are - as I and others mentioned - indeed python scripts that implement a full text search, and which could be used in order to add such a functionality directly to the archives stored at flightgear.org, but even without adding something like this directly, it would make sense to mention the possibility to use other services in order to search the archives - be it mail-archive.com or google, even though google is not really _meant_ to archive these mailing lists, I think ;-) Just use the site restriction site:flightgear.org or even site:baron.flightgear.org. Oh well, thanks for the google tutorial guys :-) -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ideas for a fully interactive ATC-TTS engine (was: A voice for FG)
Warning: Not everybody will want to read this rather long posting :-) ...now, this isn't that much about 'merely' a voice for FG anymore, but rather it's now pondering about potential ways to implement the logics for a mechanism that enables fully interactive ATC-interaction within FlightGear using a TTS (festival) for speech recognition as backend. John Wojnaroski wrote: Lots of good thoughts, ...even worse: while, I was initially under the impression that the whole interaction part (speech recognition - FlightGear) would be more than tough to achieve, I now can't stop thinking of what would be involved - maybe we can get a productive discussion going by sharing thoughts like the following: On the one hand one would need to categorize the possible contextual kinds of transmissions,like : - transmissions that require previous transmissions - transmissions that can be made anytime And then it matters of course also, what's the source of a transmission (atc/controller) - as you mentioned that you do not only want to EMIT instructions but also RECEIVE them using speech recognition technology, we will want to not only store potential ATC instructions, but also pilot requests. As very close attention has been paid to not overlap the phraseology of sender/receiver - respectively Pilot ATC, we would again be able to minimize the target dictionary, by simply comparing only against transmissions that are allowed to be made by pilots. This would then alrady be two properties of a specific ATC instruction, that way we could then already rule out those instructions that require (a non-existing) context, as well as transmissions that aren't allowed to be done by the pilot. Also, one would need to explicitly distinguish between transmission for VFR and IFR (flight plans), those that are not exclusive to either of the two simply get properties for both, VFR and IFR - hence, such transmissions would be valid for either type of flight. But during an IFR flight, we most likely won't have to compare against most IFR-only instructions. Generally, this would also assure that the phraseology is also physically separated and doesn't get mixed. Then, transmission should be separated by the phase of flight in which they _CAN_ occur, like: + pre-flight + departure + cruise + arrival + landing + after-flight (taxi ...)ing (Transmissions that can be made in more than one phase of flight, simply also have the other phases listed in their applicable phases definition.) That way, we can again separate a whole bunch of instructions from eachother, simply because you are unlikely to request a landing while you are on the ground :-) Likewise we do not need to compare against any taxi-ing instructions while in-flight, etc ... This of course requires that we (FlightGear) is aware of the current phase of flight. Okay, the current phase of flight could be determined using mechanisms, like the following: Preferably, we would be on an IFR flight plan - which would tell us everything related to the current phase of flight by simply watching the flight's progress and comparing the flight with what ATC expects us to do, but if we are VFR we usually won't have any flight plan, so we might have to guess - but guesssing can get pretty precise if we do it by means of exclusion: WHERE ARE WE: = at an airport ? = on the ground ? = on a runway ? ... WHAT ARE WE DOING: = what's the aircraft's current configuration (flaps, gear ...) = are we descending/climbing in the proximity of an airport ? ... So, ultimately we would have a chance of about 90% to be able to determine the flight's current phase of flight, which would finally mean that there's less recognition effort for the implementation of the ATC logics, since we simply know that certain instructions are not going to be expected/permitted. While this information alone does not save the TTS from doing its work, we (flightgear) would receive a string representation of what the TTS _thinks_ has been said. But since we would know that we are currently in-flight/on the ground (etc.) we won't have to compare against EVERY possible ATC instruction that the pilot may have given. That way we would significantly reduce the necessarry recognition efforts on our side of things, and would really increase the probability to find a matching instruction within the subset of allowable instructions. And even in cases where the TTS returns a string that cannot be matched against this allowable subset of transmissions, one would still have the possibility to either: - compare against the _whole_ set of instructions, to make sure that there's nothing else that matches. or - simply respond with a Say again ! :-) Of course, one could
