[Flightgear-users] TaxiDraw-0.2.2 released
TaxiDraw-0.2.2 is now released. Versions 0.2.2 and 0.2.1 fix several serious bugs in v0.2.0 - all users should upgrade. TaxiDraw is available from http://www.nottingham.ac.uk/~eazdluf/taxidraw.html Changes are as below: * 0.2.2 *** Version 0.2.2 fixes several serious bugs in the X-Plane format writer present in 0.2.0 and 0.2.1. All users should upgrade, since X-Plane format is becoming the default format for FlightGear in the very near future. * 0.2.1 *** Version 0.2.1 fixes several serious bugs in 0.2.0, and adds some feature refinements. All users should upgrade. Changes from 0.2.0: * Removed an undocumented option left over from early development testing where pressing 'Y' would silently move the selected taxiway to position 3 in the list. Ouch - how did that get left in? * Fixed a nasty bug where repeately viewing the properties of one taxiway could reduce either the length or width by one foot each time. This seems to have only occured on Linux, not Windows. * Improved the taxiway selection criteria where more than one taxiway is under the mouse-click location. Previously the highest taxiway in the list was selected. Now the criteria is that if one taxiway under the click point is already selected that will be selected again, otherwise that the smallest taxiway under the click point will be selected. This makes operations on small taxiway segments that are largly obscured by larger ones much easier. Additionally, taxiways are now selected preferentially to runways where an overlap occurs at the selection point. * Fixed the grid corruption bug which occured at certain projections and zoom values. * Moving runways and beacons can now be un-done, and will set the dirty flag. * Cancel now works for the runway and taxiway dialogs (previously data was transferred even if cancel was pressed). * Changing taxiway or runway properties through the properties dialog can now be un-done, and will set the dirty flag. * Constrained move now works for runways (when unlocked!). Pressing shift whilst dragging with the mouse will constrain a runway or taxiway to move only in the direction of its longitudinal axis - this was already implemented for taxiways but not runways. * The default editing units can now be set to meters if desired. This setting will be remembered between sessions. This is not recommended, since the data is saved between sessions in integer feet (as in the master databases), but since the foot has a significantly smaller resolution than meters this should work OK for those who really want to work in meters. * Runways can now be locked and unlocked from the edit menu, and the shortcut key to toggle the runway lock has been changed from 'U' to 'Ctrl+Shift+U' to make accidental unlocking harder. * Lighting preview can now be accessed from the View menu. * Fixed a gcc-2.95 compile error. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-users] Libraries containing aluinit
Hi, All Does anyone know in what libraries _alutInit and alGenBuffers are in? I think that is the reason i can´t build simgear. Regards___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-users] Re: [HTML] Libraries containing aluinit
* francisco.rinaldo1 -- Tuesday 19 October 2004 19:50: Does anyone know in what libraries _alutInit and alGenBuffers are in? http://www.openal.org/ m. ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-users] Libraries containing aluinit
Francisco Rinaldo wrote -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sent: 19 October 2004 18:50 To: flightgear-users Subject: [Flightgear-users] Libraries containing aluinit Hi, All Does anyone know in what libraries _alutInit and alGenBuffers are in? I think that is the reason i can´t build simgear. IF you have unzipped openal_cyg.tgz in the right place AND your path is correct, the 'make' command will sort it out for itself. Dont fiddle around: JFTFI Regards Vivian PS - if you don't need to use the source code for development the Windows binary will be a lot easier to install, and you'll probably get a better frame rate. ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-users] Scenary Question !!
I'm using FGFS v0.9.3 ... what is the scenery correct path on ftp server for this version ? How do I insert a new downloaded scenery into FG ? Thanks ! = Stefan Palade ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
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] Libraries containing aluinit
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of francisco.rinaldo1 Sent: 19 October 2004 21:32 To: flightgear-users Subject: RE: [Flightgear-users] Libraries containing aluinit HI Thanks a lot for your help and patience Openal_cyg i s in /usr/local and simgear is in /usr/local/source. I´ve followed exactly your instructions, tar xvfz openal_cyg in /usr/local, but it is not possible to finde the word alutInit in my system. I have only a really basic skill in C++, and I think that alutInt is a function, isn´t it? Regards P.S. I have FG working perfectly in my ssystem, but if i can compile the program I´m proud of it. De: [EMAIL PROTECTED] Para: FlightGear user discussions [EMAIL PROTECTED] Cópia: Data: Tue, 19 Oct 2004 20:16:11 +0100 Assunto: RE: [Flightgear-users] Libraries containing aluinit Francisco Rinaldo wrote -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sent: 19 October 2004 18:50 To: flightgear-users Subject: [Flightgear-users] Libraries containing aluinit Hi, All Does anyone know in what libraries _alutInit and alGenBuffers are in? I think that is the reason i can´t build simgear. IF you have unzipped openal_cyg.tgz in the right place AND your path is correct, the 'make' command will sort it out for itself. Dont fiddle around: JFTFI Regards Vivian PS - if you don't need to use the source code for development the Windows binary will be a lot easier to install, and you'll probably get a better frame rate. OK, let's do some checking: 1. You are trying to compile plib-1.8.3 with simgear-0.3.6 OR 2 You are trying to complile plib-20041012-FG and simgear-0.3.7 3. Does /usr/local/lib contain: libALut.a libopenal.dll libopenal32.a ? 4. Does /usr/local/include/AL contain: al.h alctypes.h alu.h alut.h alutypes.h alc.h altypes.h alut.bak aluttypes.h 5. Make sure that there are NO other file/directories called AL (./configure will find this, and then fail - possibly your problem) left over from trying to install from downloads other than from openal_cyg.tgz. 6. Does your .bash_profile contain: LDFLAGS=-L/usr/local/lib CXXFLAGS=-pipe -O2 -Wall -DWIN32 -DNOMINMAX -DHAVE_WINDOWS_H CFLAGS=$CXXFLAGS export LDFLAGS export CXXFLAGS export CFLAGS 7. If you compile the right version of plib and simgear, when you run ./configure you should see: checking for library containing alGenBuffers... -lopenal32 checking for library containing alutInit... -lALut 8. If this doesn't work either: A. delete the cygwin directory (EVERYTHING), and start over from a completely new install. No big deal - I've had to do it. B. Give up and use the Windows binary - I use that when not fiddling with source code. It does work, really, Regards, Vivian ___ Flightgear-users mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
