Re: [Flightgear-users] Query about Scenery Load
senthil kumar wrote: Hai, I am using flightgear-0.9.4. In code, I would like to change the location of Runway. How can I do it? I am not sure whether I understood you correctly, but airports/runways are not defined within FlightGear's source code: airports are placed within the scenery which is then rendered within FlightGear - so whenever you want to change the scenery you'd want to modify the scenery and not FlightGear's source code - at least as long as your desired modification is already supported ;-) Boris send via Free-Mail http://www.inetmx.de 52 MB Postfach / Spam- und Virenfilter ++ WERBUNG + inetsolutions.de ISP / Qualitätshosting Networkservice http://www.inetsolutions.de ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] ~
Erik Hofman wrote: David Megginson wrote: Erik can tell me what I mistranslated when he has a chance to reply. Impressive, very well done! I agree, how did David manage it that easily ? I mean, obviously I was having more problems than David and it's certainly more straight-forward to translate between Dutch - German (I guess Erik would second that) than it is doing the same for English - Dutch: David, did you use an online translator, or do you know any language that's close to dutch or did you really only guess by the words and the syntax ? - Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-users] Re: contacting a/c manufacturers to ask for their permission to use Perf. data within FlightGear
Ampere K. Hardraade wrote: Perhaps I should just come to you for help in getting permission next time? =P well, it should not be that difficult - asking alone doesn't hurt: I think it depends only on the way how you ask questions ... On a serious note, may be it will help if there is a person who can ask the aircraft manufacturers for data using FlightGear's name? ...for that purpose one could compose a general inquiry that serves as boilerplate for specific manufacturers Companies like Airbus and Boeing are giant coporation. They probably don't have time reading E-mails sent by individuals (said so on their website too). By that remark they are trying to make clear that it is not a good idea for individuals to try to contact Airbus/Boeing for every question that comes to their mind, and that makes of course sense - otherwise they would receive hundreds of such eMails each day ... however an inquiry like the one above would certainly be something that needs attention from Airbus, so it would ony depend on sending it to the right people/department at Airbus/Boeing (etc.) Additionally, you could make clear that you are contacting the corresponding aircraft manufacturer on behalf of the FlightGear project, describe the project, its background - its open source nature and they are likely to listen. I don't think the chance of me successfully obtaining data regarding their aircrafts will be too good. I don't know - it really depends on the way how you are asking, in the case that I mentioned as an example I wasn't asking for freebie data either, I was merely asking them for their permission to extract data from purchased materials and use that ... But you will really need to explain how the data is going to be used, so you would for example need to explain FlightGear's modular architecture and how various flight dynamic models can be fed with such data to emulate an aircraft's flight characteristics. So, it's probably prudent to split up your general inquiry into smaller inquiries - ask them first whether they would be okay with FlightGear developers using performance data from (old) AOMs that were - for example - purchased on ebay ... And then you can still later on ask them if they were also willing to make the corresponding data directly available. - which would of course require more efforts on their behalf - generally, such companies have often times a positive attitude to inquiries of such type IF the only effort that is needed on their side is giving permission ... as soon as you asking them to really spend time on actually doing something for you, things are getting complicated. Also, a key to your success might be to clearly state that your inquiry is NOT urgent, that way they are more likely to actually look into it and the possibilities they have to help you - after all you aren't creating any revenue for the corresponding aircraft manufacturer and there's certainly more important stuff they need to get back to. So, in one of these cases it took 3 weeks before I received a corresponding response - but at least I got what I needed ... - Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Running FG with no GUI
Magdalena Bugajska wrote: Is there a way to run FG without graphics? You will need to provide more details about what it is that you want to do, if you only need to have access to a flight modelling application, you could decide to use any of the FDMs that FlightGear uses. Running FG itself without GUI isn't possible as far as I know - simply because the GUI code is too tightly connected with all the other code. However, depending on what exactly you need to do you might be able to disable the GUI output - if that's what you want to do ... - Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Problem with windows FlightGear v0.9.6
p.llosas wrote: Hi, Thanks for your reply. Your trick to make the FlightGear v0.9.6 win32 executable work, by launching two applications works for me too. Why this happens it's really a mistery for me. These descriptions sounded soo interesting that I just tried to run FG under Windows myself: I didn't have any of the described problems, on the other hand I was only using a version of Win2k - with the latest service packs installed ...so I am not sure whether the described behaviour might be specific to any particular version of windows -i.e.: What versions are you using, is there anything else common with those platforms where these problems occur ? --- Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Proprietary information (was Re: [Flightgear-users] How to build a plane from scratch...)
David Megginson wrote: On Mon, 01 Nov 2004 11:46:05 -0400, Enrique Vaamonde [EMAIL PROTECTED] wrote: I understand the implications of using copyrighted or propietary information to create a model, however I am just using this information as reference for my work and intend to keep it that way. That sounds entirely reasonable. One could of course still contact Boeing/Airbus (or any other a/c manufacturer for that matter) and ask them for their explicit permission to use performance data (taken from the AOM) within FlightGear, I have also recently contacted a company and asked for a similar permission, and it turned out not to be a problem at all ... So, I would generally recommend not to be shy to ask - if you give a general description of the project and needs, as well as possibly the motivation for the inquiry you are unlikely to be rejected - at least that's the experience that I have made. Even though, asking for data to be made available under the GPL is a whole different matter in most cases :-/ Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Problem with windows FlightGear v0.9.6
p.llosas wrote: There is no other particular hardware. I have installed many kinds of different software and I have never experienced this kind of behaviour. Sorry if you mentioned this already somewhere, but: does this problem also occur if you do not start FlightGear by using fgrun, but rather by starting fgfs(.exe) directly ? For example, what happens if you change to FlightGear's directory and execute: fgfs [enter] (Just trying to figure out if this problem is specific to fgrun or also happens with fgfs directly) Thanks --- Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Problem with windows FlightGear v0.9.6
p.llosas wrote: I've tried to run directly fgfs from cmd but unsuccessfully. I get the message: Base package check failed ... Found version [none] at: \FlightGear Please upgrade to version: 0.9.6 Hit a key to continue... (I had defined manually the paths D:\Prog...\FlightGear; D:\Program..\FlightGear\bin\win32) You'll have to manually specify the FlightGear environment variable $FG_ROOT - pointing at the directory where your base package resides. I think you can optionally also specify the base package location by using a specific parameter for fgfs - something like: fgfs --fg-root=C:\Programs\...\FlightGear whereas the last parameter should be the location of your base package try using fgfs --help --verbose in order to get a comprehensive list of possible parameters. -- Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Impressive flying
Ampere K. Hardraade wrote: We recall the famous Sioux City crash of a DC-10 (UAL Flight 232) in 1989 was flying that way and they barely made it to the runway, forget about go-arounds and safe landings. In fact, that particular flight had kind of a significant influence on the outcome of the events with said DHL flight in Iraq, the Captain of the DHL flight remembered Cpt. Al Haynes' decision to use assymetric thrust to control the aircraft (= gimli glider) - I seem to recall to have read (about a year ago) that the DHL captain even attended a specific presentation by Cpt. Al Haynes, where he spoke about the crash and his experiences controlling an aircraft without hydraulics. - Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Impressive flying
Boris Koenig wrote: Ampere K. Hardraade wrote: We recall the famous Sioux City crash of a DC-10 (UAL Flight 232) in 1989 was flying that way and they barely made it to the runway, forget about go-arounds and safe landings. [...] Al Haynes' decision to use assymetric thrust to control the aircraft (= gimli glider) Ooops, sorry: that () was the wrong one in this context - the Gimli Glider was an another piece of impressive flying that ended in Canada on a military airfield and not in Sioux City - but their problem was also related to a loss of hydraulics, specifically because of a lack of FUEL (metric conversion problems ...) -- Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Texture sizes (was Re: New Livery for 747)
Paul Surgeon wrote: Hence the need for FlightGear to have a way of adjusting all these things (preferably from inside FG). shouldn't be a problem to start using specific nodes within the property tree for that case, it would probably not even be involved to first add _support_ (only) for it - one could still adapt the corresponding functions/methods laters to actually support more than what's currently possible. We cannot expect one size to fit all which is more or less what we do at the moment. Yes, there are a couple of things we can tweak at the moment such as the model density in the scenery based on distance. About 6 weeks ago I did also make some very similar suggestions - mainly about enabling the user to dynamically modify the complexity level of the scenery, possibly even rule based - so that the complexity level is (optionally) decreased at cruise altitude and increased at lower flight levels or during an approach. Basically, by implemeting such a mechanism one could also support to allow users to create and use _profiles_ - something which is also supported by FlightGear's commercial counterparts, like MS FS or X-Plane, which both also allow dynamic modification of such parameters. As much as everyone loves using the command line for setting parameters what happens when we can't pass enough parameters via command line because we hit the limit on how much the shell can handle? On my Linux box it's not much of a problem but whats the limit in Windows? Windows is indeed a bit picky about the length of command lines, however there's still the fgfsrc.system file that could be used to theoretically pass an abitrary amount of parameters to FG - but I still second what you said: it would definitely be nice to be able to modify such parameters at runtime/ on the fly :-) -- Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Win 32 executable
francisco.rinaldo1 wrote: Hi, all I´ve been succssesful in doing a filghtgear cygwin executable. Is it possible to make a win32 executable using cygwin?. Actually, that's exactly what you did - with Cyg*win* ;-) If you mean that you want to have a standalone exe, that does not depend on Cygwin you'll need to use another compiler, however not all compilers seem to be supported - that's probably also what Vivian referred to. If you have got access to any of the more recent MS VC++ version (respectively .NET) you will probably be able to build FG, anyway. The problem about using other compilers is mostly not only certain features not being supported, but also getting the makefile stuff ported ... A project as large as FlightGear has dozens of Makefiles with hundreds of different settings in them, so if you are going to build FlightGear using an unsupported compiler, you'd essentially have to take care of such subtleties by yourself. But why do you want to build your own version ? Why don't you use any of the pre-built packages ? If it is because you want to make your own changes to the sources, then using Cygwin should be perfectly okay ... If it is the case could anyone give any tip? Personally, I'd firstly try to use MingW32 - it's based on GCC, but still a Windows compiler, however recent experiences seem to have shown that there are some limitations that can turn out to be a major hurdle ... On the other hand, it's probably quite some time ago that someone *really* tried it - maybe you are lucky and some of the former problems are now vanished :-) In any case keep us updated ;-) -- Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Re: approaching airport
John Pearson wrote: using dme seems easy enough, but its a pain to have to open the internal property browser and browse to /radios/dme to see the distance. Well, normally, you'd simply set a nav radio to the correct frequency and then check the DME readout - but if that's not an option for whatever reason you could either permanently poll that value automatically and print its value to the console by running a simple nasal script, or you could bind such a nasal statement to a specific menu item in menubar.xml. There are certainly more ideas, it really depends on what exactly you want to do, and why. However, usually I'd simply go for the nav radios - Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Re: approaching airport
John Pearson wrote: bah, nevermind... it only does it if i'm really close (i was going from snohomish to seatac). DMEs are certainly modelled to be as real as it gets, DMEs / VORTACs and all other navaids do have a limited range in real life, too - so depending on your exact needs you could do some great circle calculation using the GPS coordinates from the property tree in order to get the distance to an abitrary point on earth. You could then display that value in the console, or directly within FG ... Maybe you can tell us in more detail what it is that you want to do, we can certainly find an acceptable solution for such an apparently trivial problem ;-) - Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Re: approaching airport
John Pearson wrote: How would I normally determine the distance from a waypoint? depends on the type of waypoint and the navigation equipment in your aircraft, if it's a navaid such as a NDB or VOR you could do some simple time/distance checks, e.g. by flying with a 90 (45/30) degree relative bearing offset from an abitrary navaid in order to see how many degrees bearing change (an angle) will be covered in a certain amount of time - based on your groundspeed you can calculate your distance to the corresponding navaid. A simple example: ( a bit tought without drawing ...) o magnetic heading = 035 o relative bearing = 060 = the navaid is to your right side = you correct your heading so that the rel. bearing becomes approx. 85 degrees, so you turn 20 degrees to the left = then you note down the amount of time it takes until the relative bearing is increased to 095 degrees based on the bearing change by 10 degrees you can do a time/distance calculation, like: (time to station in minutes) = (stopped time in sec) / (bearing change) If it took 80 seconds for a 10 degree bearing change to take place in the above example and we were travelling at a groundspeed of 120 kt that would mean: distance to station in minutes = 80/10 distance to station in minutes = 8 Which means, it would take 8 minutes at 120 kt to get to the station. And that comes down to (120/60) *8 = 16 miles distance. Hope everything's correct ... How exactly you determine the bearing change depends however on the type of navaid, or rather instrument that's in use - an ADF or RMI is pretty straight forward, as the relative bearing can be easily obtained, a VOR instrument is a bit more involved, as you need to manually change the OBS. If you can really easily determine the distance from a certain waypoint depends also on the type of waypoint, so for example nowadays many waypoints are not marked by conventional intersection or merely navaids, but are rather determined by imaginary fixes based on GPS coordinates. So, you cannot really use any waypoint in a normal aircraft, waypoints that are specific to GPS or RNAV equipment are mostly meant to be used only by airliners that have the corresponding systems ... If you want to practice some of the basic stuff that can also come in handy during your real flight training you should google for instrument flight / instrument navigation or instrument interpretation tutorials, some of the more advanced tutorials like the ones at http://www.navfltsm.addr.com/index.htm are pretty accurate if you take into account that they are actually only meant to be used for gaming purposes. But there are numerous other webpages and forums that offer such tutorials, some of them run by aviation enthusiasts, others by aviators themselves - for example, some very good stuff can be found at: http://www.stoenworks.com/Aviation home page.html (that webpage is run by a former commercial pilot, who's now retired and seems to be really into flight simulators) In order to visualize some of the illustrated techniques you could also use a very popular free web applet: http://www.visi.com/~mim/nav/ Also, if you are going to attend flight training, anyway you might want to have a look at http:/www.pprune.org - where you can find numerous professionals and thousands of archived postings which cover pretty much any question topic that could come to your mind, I'm sure you'll find it a very informative resource ! -- Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Outa the box and outa sight
Innis Cunningham wrote: Also thanks to those involved in the speed increase.Havn't seen frame rates over 100 fps since 9.1. Has anybody really been able to achieve a framerate of *100* FPS ?? I am a bit surprised - what kind of hardware is/was involved, cause in one (gaming) machine I am using a very recent graphics adapter that doesn't give me much more than 15-20 FPS with FG if I am lucky. Only an old ATI Rage 128 gives me a really playable framerate (approx. twice that much), the only drawback being then is that there are some graphical problems with that sort of card (as previously reported discussed on the devel list). So if some of you really achieve that kind of framerate, I'd love to hear what hardware you're using - or what else may be different for your system (don't tell me now about wireframe mode, though) -- Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] classifying development status of aircraft extending fgrun
Ampere K. Hardraade wrote: On October 20, 2004 10:05 pm, Boris Koenig wrote: Ampere K. Hardraade wrote: One of the problems, as I pointed out earlier, is that the download size of the base package is a bit on the huge size. fully agreed, that's something most people seem to complain about - on the other hand it's fairly small to be honest - if you compare it to other simulators like MSFS, X-Plane etc. - so having a full simulator by downloading less than 100 MB data, sounds okay to me. FlightGear targets people who want to get something for free, while MSFS and X-Plane target people who are willing to pay. Therefore, you can't really compare FlightGear to the latters. well, somehow you folks permanently try to convince me that you cannot compare opensource projects with closed source projects - and on the other hand exactly that is done all the time... if not by the developers themselves (who nevertheless indicate to aim to outscore the commercial competitors one day) then by every new user who OF COURSE will make comparisons with previous experiences. On the other hand, you're of course true that the companies behind products like MSFS or X-Plane *target* commercial users, I'd assume that the non-commercial user community (=those who didn't pay) is significant for either project, too - particularly for MSFS this is very true. For people who just want to check out FlightGear, their mentallity is to download the executable, run it for five minutes, and delete it if they are not sastisfy. probably a good point, but then the whole process of compiling the thing is even more problematic than the big download in the first place !? If the download is too big, or the time for download takes too long, this group of people are going to get discourage, and FlightGear can potentially lose these new players as consequence. Okay, then one would need to think about creating kind of a preview or down-stripped version that contains only working stuff - preferably with a certain scenery already available and a handful of finished aircraft. Something like this could probably result in a significantly smaller package. 100MB is okay for me because I have broardband. But even so, I still think the download is too big, because it still takes time and 90% of the aircrafts that it contains are aircrafts that I don't fly. probably true, but one would need to determine what types of aircraft are interesting for the majority of people/users AND what aircraft can actually be used without problems - otherwise one might very end up packaging only stuff that some of us think should be integrated and leave out other aircraft that might appeal to others anyway. [...] The patch doesn't really solve the issue: people still have to download the entire base package when they first run FlightGear. That's of course true - and I didn't mean to imply anything else - it's only meant to provide a viable alternative for those who want to upgrade (or even down-grade) Beside, how many players do you think actually know about the patch? I am not sure about that, but I am confident that the patch will be added as an option to the official FlightGear download page as soon as there's been some experience made about the whole patching thing. We've talked about that already on the devel list. And I can understand Erik's objection or rather fear that patching might create a whole new bunch of problems the developers would then might have to face every now and then. On the other hand, the tardiff pages are quite extensive about the whole patching process and it would not take very long to add some advise about how to deal with unsuccessfully patched FlightGear base packages. So, I am not sure if it's such a good idea to simply stop packaging unfinished aircraft. You are correct; as a modeller, I do want my aircrafts to appear in the base package so that people can appreciate my work. That's what I figured, too However, forcing them to download my aircraft(s) isn't right. Well, I wouldn't call it forcing - the policy to integrate any new aircraft seems to me rather like some sort of artifact from the early beginnings where everybody was glad that a contribution was made - and I understand that it's somehow tough to declare now certain requirements in order for future aircraft to be considered for the base package. It may even be counter productive, and I certainly don't want that to happen. yes, this is a bit of a two-sided problem - both scenarious could probably become counter-productive. An alternative is to set up a section at FlightGear.org for aircraft downloads. I think it was Chris Metzler who brought up a similar idea some time ago - to set up a webpage for additional FlightGear-related downloads, which wouldn't necessarily have to consume Curt's resources - while all this was back then about scenery in general, it's certainly something that would fit together with some kind of Aircraft Repository - on the other hand that idea
Re: [Flightgear-users] Flyable aircraft
Hi everybody ! Sorry to bring this up again - Just catching up on the hundreds of postings on both lists ... and I wanted to add the following: Jon Berndt wrote: Yes, I've made an attempt in the JSBSim config file format to include a done-ness specifier for the FDM: Beta, Alpha, Release, UNRELEASEABLE, etc. IMHO, probably ONLY Release models should be in the base package. I agree with much of what has been said so far - concerning the reputation of FlightGear suffering from various incomplete aircraft ... at times it's really hard to tell what's the cause of a problem, whether it's your hardware, the simulator or a particular aircraft ... So, I like the above idea, even though I don't think that it's necessary to remove immature aircarft, rather one could try a compromise - provide additional maturity flags within each aircraft's XML definition file, for example: experimental pre-alpha alpha pre-beta beta okay/working That way we would have one additional tag within the XML file, like: maturityalpha/maturity And would thereby enable the *user* to choose what kind of aircraft he/she wants to use. So, while the usual parameter --show-aircraft would currently display ALL available aircraft, we could have an additional parameter like: --min-maturity-level=beta to return only those aircraft in the base package that match the corresponding criteria. This would of course only be optional - but I think it could really reduce some of the frustration new users encounter when first trying out FG. So, one would end up having a definable maturity level for aircraft, in order to address the issues concerning too much realism it might be a good idea to also enable users to adjust the realism level on demand - this is something that other simulators offer, too - and it has been discussed on the devel list before ... One could still ship ALL aircraft, but prevent new users from trying unfinished aircraft and drawing false conclusions. Probably, it would not even be a bad idea to make --show-aircraft return by default only relatively mature aircraft instead of all the experimental stuff that's in the base package ? If that idea is accepted I would not mind taking care of the corresponding changes that make FlightGear return only aircraft meeting particular maturity requirements, frankly spoken simply because I was going to change one or two similar things, anyway - e.g. I wanted to be able to tell whether a particular aircraft is part of the base package or not, that's why I suggested some time ago to provide an additional tag for that purpose, too. -- Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Good Manual ?
Sorry, found another posting that I felt forced to comment on ;-) Ampere K. Hardraade wrote: Boris was writting a tutorial part of FlightGear, but there haven't been any word about it. http://flitetutor.sourceforge.net Right, to some extent at least: Josef won't find anything usable there - on the one hand because it wasn't meant to become a tutorial in itself, rather it was supposed to provide a general framework for tutorials/CBTs *WITHIN* FG, on the other hand the actual coding - because it is done using Nasal, requires various changes to the FlightGear sources itself (hooks-fgcommands), so BEFORE much of the actual scripting stuff can be implemented, various modifications within FG sources need to be finished, approved for committed to CVS. So, yes: it's still something that I am working on every now and then ;-) Also, I haven't heard back from Erik concerning the patches that I sent to him several weeks ago - so it's still also a matter of relying on the grace of some people - which wouldn't be the case if one could simply use a plugin-mechanism ;-) (I don't seem to get tired to mention this!) Anyway, to provide some general info: I've made about a handful of fgcommand additions, so that Nasal can now for example dynamically modify the menubar, so this enables Nasal modules to self-register themselves within the menubar - e.g. there's no need to manually edit the menubar.xml file to add a certain command that's stored in a particular Nasal module. Rather, one would manipulate the menubar structure within the property tree and and the run a fgcommand to make these changes take effect based on what the fgcommand encounters in the prop tree. Also, using these changes that export the menubar to the property tree makes it possible to have different menubars loaded and enable/disable these on demand, this would probably come in handy if FlightGear keeps using plib for the GUI part, simply because plib doesn't yet feature sub-menus and the FlightGear menus seem to be growing with every new release, so using a simple nasal command one could change the menubar on demand - as a workaround. Additionally, loading/saving XML files using said new fgcommands is now somewhat 'possible' using property tree nodes as either the source for a new XML file or alternatively as a target (location) for a parsed XML file - even though the saving part is still a but 'buggy' (doesn't work in each case). The scripting side of things (Nasal) is growing slowly, too - it's currently a bit more than 30 kbytes of Nasal source ... (a lot of comments, though) - mostly dynamically created populated GUI elements placed in functions. Don't expect anything to be made available within the near future, though - there isn't yet much logical functionality and it wouldn't work without the new fgcommands in your version anyway - that's why I decided not to use CVS or whatever at this stage ... So even now it's essentially like working with two different versions of FG :-/ As soon as the basics have been completed and committed I am going to make a preview available and update the webpage. ...don't hold your breath, though ;-) -- Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] GPS DISREGARD LAST EMAIL
louis holleman wrote: On 28 Sep 2004 at 13:14, Erik Hofman wrote: You are aware of the fact that you need the base package matching the binary, don't you? If they don't match then don't expect too much help in solving the problems. Erm, yes and no like I said: running the 0.9.5a installer file appearently refused to install some needed files. The DOS box upon program launch told me file missing but disappeared too quick for me to check out WHICH file. try running the installer directly from a DOS prompt ? The 0.9.4 installer did a good job, at least it gave me a running program. so you used the old installer to mix the current executable file with the old base-package ? Now there raise two questions: can I run the 0.9.4 installer again and next change the fgfs.exe for the 0.9.6 one or does 0.9.6 require 0.9.5 to be installed previously? these files should be self-contained - you do not need to have any previous files, actually it should be preferable NOT TO have any old files at all, indeed this may be your exact problem - at least the base-package should be a problem then. If so, I need to fetch a 0.9.5 installer which does a good job first. The one I got from the FG site didn't do a good job, and I've tried twice... (and let me make it clear that didn't do a good job resulted in a failing program. Nothing during installation told me something went wrong). wow, that sounds indeed interesting ... if possible it would be useful to have details about any errors that occur or where exactly the installer stops doing the good job ;-) Have you now also overwritten the old base-package with the latest one ? What does you $FG_ROOT/data/VERSION file say ? type $FG_ROOT/data/version depending on whether you corrupted your current base package, I would simply rename that directory and try to run a CLEAN install. Probably you have all the files, anyway ? So, try to rename the existing stuff, so that nothing gets deleted - and then re-run the installation, so that it does a CLEAN install. You might want to remove the binary manually. -- Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] GPS DISREGARD LAST EMAIL
louis holleman wrote: On 28 Sep 2004 at 15:40, Frederic Bouvier wrote: I don't know when 0.9.6 will be out ( is it ready ? ) but here are some guidelines if you want a proper system : 1. get the 0.9.6-pre1 base package at : ftp://ftp.flightgear.org/pub/fgfs/Shared/fgfs-base-0.9.6-pre1.tar.bz2 2. get the Win32 0.9.5 binaries at : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgfs-0.9.5-win32.zip 3. get the Win32 0.9.6-pre1 executable at : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgfs-0.9.6-pre1-win32.zip Decompress 1. 2. and 3. ( in that order ) somewhere in order to reflect your current flightgear tree. Then you will have all files in sync. If you try to run the 0.9.6 executable with the 0.9.5, or worse 0.9.4, base package, you are likely to encouter missing features that are solely in the base package. Fred, this is NOT what the main page on FG tells us. It tells us: [...] These were not generic install instructions, Frederic simply showed you a way to MANUALLY do what the installer would otherwise (be supposed to) do ... and this resulted in a failing program to run. To Boris: You might call this a silly way of expressing myself, but I call this an installer which won't do a good job. I cud also call it a wrecky installer. Sorry, Louis: no offense intended - I was only asking WHERE exactly something failed, I didn't mean to say you were using any silly expression - and obviously something was really broken, so you're phrasing was probably somewhat right, in that regard I would agree that the installer didn't do a 'good job' - but my first impression was indeed that you were mixing various packages ... and this would provoke errors, I think. Back to Fred. I followed your instructions. I extracted the whole bunch to D:/FlightGear, so my original installation onto C:/whatever/FlightGear would remain intact. After running fgrun.exe I found that all airports for the scenery stuff I have downloaded for the first try, which is on C: were listed too (and I didn't install them to the D: partition yet). I double checked, I did run D:/FlightGear/fgrun.exe.oh well. This *could* be because of your environment variable ($FG_ROOT) still pointing to the old location - you can verify this by running a simple set in the console (cmd.exe) and look what it says - to make sure that it points to the proper place you can simply overwrite that variable manually by running set FG_ROOT = D:\FlightGear\data ... But to make this a permanent change you should modify the FG_ROOT variable within the control panel or whereever you set it. Tried the Piper J3: DOS box telling me something wrong with a nasal file? OK, that's different from my earlier tries, I will look into it. Make sure that you are really using the proper (new) fgfs-base package for your new version. regards Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Re: at all helicopter enthusiasts1
Ron Lange wrote: If someone interested in: The EC130 is almost finished. Now I going to make the interior and texture... http://www.ron-lange.de/ec130_stage1.jpg This looks really amazing Ron ! Did you have any previous 3D modelling experience, or even using Blender in particular ? - Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Cow Scenery - Feature Request v.2.0 ; -) (was: Reserve airstrips)
Arnt Karlsen wrote: On Sun, 08 Aug 2004 17:36:05 +0200, Boris wrote in message [EMAIL PROTECTED]: Chris Metzler wrote: close up, however, we see that this cow is feeling a little boxed-in: http://www.speakeasy.org/~cmetzler/cows4.jpg well, Erik and his special relationship to animals ;-) ..naaa, you've never seen those wee 1 liter etc milk boxes in da shop? They come from these boxy Dutch cows. ;-) Oh, I see - sorry my fault ! If we now had a BugZilla running to collect bugs feature requests for FlightGear, I could now go ahead and requests cows to be running away if I'am at low altitude passing them @ 300 KT - also, after touchdown I'd love to be able to milk the cows !! When are these features going to be implemented ? P.S.: How about integrating squirrels and using the AI manager to make the cows more intelligent !! - Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] Compling CVS
Brett I. Holcomb wrote: This brings up a question. Is this the best way to do this - simply put WANT_AUTOMAKE=1.7 in my build script or is there a better way to fix it. I would guess it is the best way - don't know exactly, though. But the other options that would come to my mind for a workaround would involve using at least two different autotools versions during packaging - one configuration set for old autotools and one for the new stuff. Not really a good way ... Actually two questions G - what makes autogen so touch about versions and what does it take to fix it? I think, so far it doesn't really fix it, it's just that new versions address design issues, particularly with the usage of m4 macros etc. (like different macros using identical names) - that's also the reason why you'd usually receive many warnings when using a current autotools package with scripts that were generated by older versions (and macro sets) - e.g. you get to read numerous lines with stuff like Warning: underquoted definition of... So, what the autotools people finally want to achieve is to unclutter all this stuff, without having colliding namespaces anymore - but that takes of course some time. The whole issue is quite frequently brought up on different mailing lists, so maybe one could find some clarifying information on the autotools webpage - or in the autotools online book (http://sources.redhat.com/autobook/) good luck Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] FlightGear-0.9.5-pre3 base patch request
Hi, I've created a binary patch from pre2 - pre3 base package based on the 1.11 cvs revision, it's available at (approx. 1 MB): http://flitetutor.sourceforge.net/mlist/fgfs-base-0.9.5-pre2-TO-0.9.5-pre3.tgz Hope it works - as it is based on the 1.11 CVS revision there was quite a lot of cvs related stuff that probably did not exist in the actual pre2-release, so I simply removed the CVS related folders - if there are any problems, simply drop me a line - haven't yet deleted anything :-) But talking of being lazy, instead of hacking a perl file together it might have been a bit quicker to simply run a cvs update in your FlightGear folder ...even as modem user this would certainly not have taken much longer than 10 minutes I guess ;-) (okay, installing Cygwin on Windows might have taken a bit longer though) But on the other hand, that way more people - also those who are not cvs - literate- can benefit from base package patches and won't have to download 85+ megs just for some small patch. Regarding your script, I noticed that it might be useful if it wasn't a requirement to really untar all files within the archives to the harddisk, afterall it's a folder with ~250 megs - just for the comparison process. So, maybe this should optionally also be based on TWO archives to create the patch - having pretty much a standard diff then :-) (possibly using pipes extraction to STDOUT to save disk space) I am just mentioning this, because I originally intended to abuse a sourceforge ssh account for downloading building the patch files (faster connection and probably also multi-CPU over there), unfortunately sourceforge has a standard restriction of 100 MB for their home folders, so that was not an option. Talking of CVS, one might even extend your script in a way to selectively create binary patches based on the latest CVS revision and a set of custom checksum files, that way it should be even for a modem user quite feasible to create easily binary patches - without the need for much diskspace or bandwidth. Another small thing: the script seems to assume that every folder/file that exists in the archive serving as patch basis also exists in the updated version, hence you receive stat-errors if they don't exist. Boris ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-users] 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-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-users] FlightGear-0.9.5-pre3 base patch request
Hi ! Just checked out your script - I wouldn't mind creating the binary patch, but looking for the required pre2-base download on ftp.flightgear.org I couldn't find it anymore, if it's still there I would need to know WHERE to look, otherwise Curt might put it there again - or if anybody else still got the pre2-package, please tell me where it's available. I think the overall idea of providing binary patches for the base packages is a pretty good one, using Stewart's script one could even automatize building these patches and also offer these downloads on flightgear.org, I agree that it would be pointless to have everybody download a 85 meg file, just for some minor changes - so in the end, this might even reduce the traffic for the flightgear.org webpage. - Boris Stewart Andreason wrote: Could someone help make an upgrade patch for fgfs-base? I've posted a perl script at http://www.geocities.com/sandreas41/corral9.html to automate the sorting and binary diff work. I admit, I'm lazy. I don't want to wait another 9 hours to download base-pre3 over modem speeds. I can't imagine the differences to be that big from pre2 to pre3. Thanks Stewart -- Curtis L. Olson wrote: Stewart Andreason wrote: Hi Curtis, Is there any way to get a patch.tar.gz of only the differences from base-0.9.5-pre2 to pre3? Perhaps you could ask on our mailing list. If someone can come up with a pre2 - pre3 upgrade patch I can post it on the ftp site. Regards, Curt. ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
