Re: [Flightgear-devel] Making a 3D Sea Harrier FRS.1
On Wed, 2003-10-15 at 22:19, Lee Elliott wrote: On Thursday 16 October 2003 01:21, Andy Ross wrote: Matthew Johnson wrote: Thought I'd take a stab at this, decided to try and make a 3D rendition of the Sea Harrier, especially since we have the Harrier in FG, but without a 3D model (I think it needs one!). So far I have started by looking for a plan that I can follow, but have only found a 3 view plan for the FA2 (upgraded version with HOTASS and new radar), anyone happen to know a 3 view plan of the FRS.1 version is hiding? Failing ever finding one, what options are open? Let me pop out of hibernation for a moment to respond to this. [Curt/Jim/Maik: I *am* going to try out the helicopter patches to YASim, I promise. Cursorily they look good, except for some high-level design issues that can be ironed out later via code motion. Feel free to commit them anyway, of course] I did the harrier flight model, and actually almost sorta got started on a 3D model to go with it. The harrier is actually quite difficult to figure out from a 3-view, honestly. Due to features like the negative camber wings, forward-slanted elephant ear intakes and protruding nozzles on the fuselage, it's very poorly represented by a single diagram. I looked through a *lot* of photos, and never did really come up with a good plan for how to do it in blender. Maybe your best bet would be to purchase a traditional plastic model, disect it, and use digital photos of that as your basis for 3D work. Andy Yes, this is quite a tricky one to model - I started on one too but stopped when I found out you were working on one as I didn't want to intrude on your patch, as it were. By all mean intrude on my patch, just want FlightGear to have its planes :). Plenty of planes to last quite some time (no Spitfire yet for instance...). The intakes and neg camber wing aren't too difficult to get around - I'd suggest doing the front fuselage as two sections, split at the intakes, and then join them together, to deal with the intakes. I can't actually see a problem with the wings. Main issue I am having right now is the cockpit area, just have not had it form correctly. Loading other planes, like the P51 has not really shown me enough to figure this out yet. The side nozzles were tricky though because they aren't just stuck on the sides of a smoothly curving fuselage. I had a lot of trouble trying to get a clear idea in my mind of the shape and curves of the fuselage in this region and stopped work on it before I'd figured it out. Ugh, you're challenged by this... Anyway, I have put the ac file up here: http://pwp.netzon.net/~stargoat/sharskel.ac Been using the pictures that were sent earlier :). Not sure if I can post them here (in a link of course). Matt ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] release warning
Curtis L. Olson [EMAIL PROTECTED] wrote: I'm going to push forward with some pre releases. I very much appreciate the documentation issues. Perhaps in a week or two or three if we are ready for an official release and the documentation isn't quite there, we could go ahead anyway, and then do a 0.9.3b release with updated documentation ... (?) That's o.k. for me. I'll spend some time on the manual during vacation next week - as long as my 'cohabitee' doesn't hurt me :-) Part of the problem from a release manager point of view is that if we wait for every loose end to be tidied up, [...] The problem with writing documentation is _not_ the necessity to have all ends fixed but to know about their current state. I usually spend many hours to figure out how some feature is _supposed_ to work and how it really works on different platforms. Not until I know what's the case I can document this feature. In many cases this involves questions to the developers on the list (and dozends of rebuilds), for example when features behave different on different platforms and/or with different settings. Curt, I don't want to shoot at you, I just want to make clear that it's nearly impossible to document a moving targed at a level that I expect documentation to be written. Probably Michael did a better job at this because he found a pragmatic way between quality and measure of the written manual, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Making a 3D Sea Harrier FRS.1
just want FlightGear to have its planes :). If you want me to, I can have a look whether there is a Harrier for MSFS/CFS that we could technically use (then we would have to ask for permission). Plenty of planes to last quite some time (no Spitfire yet for instance...). I think there is no high quality Spitfire I around, lets say of 5000 polys. Other sims might need it as well ;). Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OS-X binaries for 0.9.3-pre1
On Thursday, October 16, 2003, at 05:18 am, Curtis L. Olson wrote: Gene B. pointed me to a free windows setup.exe creator so I'm thinking we ought to bundle the windows version up with that (or something similar) for upcoming releases. I know Darrel Wassiler (who's probably lurking here somewhere) has already done similar work, but for my own amusement, I've been working on getting SimGear and FlightGear compiled as a framework (in the case of SimGear) and a bundle (in the case of FlightGear). This translates as 'relocatable, double-clickable end-user-application' for those who don't know OS-X packaging formats. It's not working yet (still fixing link errors), and I have a few patches to submit, but I'll keep playing over the weekend, so providing shrink-wrapped OS-X binaries for this release ought to be no problem. Darrel / Other OS-X people : I was thinking of doing something clever with the FG_ROOT detection, especially now FG supports multiple scenery directories, such as searching $HOME/Library/Application Support/FlightGear/ As a sidenote to all FG developers, it would be great if any part of the base package that normal users might want to expand can handle multiple paths : then I can locate the main base package, which is essentially static for a given release, inside the the application bundle (i.e invisible to the end user), and they can drop new aircraft / scenery / other extendable resource into a 'plugin' directory location as described above. But of course, that can wait till post 0.9.3 (and a minor beef-up of the path / directory functions in SG, I suspect) HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Version 0.9.3-pre1
Curtis L. Olson [EMAIL PROTECTED] wrote: There's still time to get new code and bug fixes in before the official 0.9.3 release so no need to panic (yet.) :-) Could we have a real feature freeze for at least one, better two weeks before official release ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Broken initialization on Reset
Hello, I'm still experiencing a bug that already lasts for quite some weeks. I run 'fgfs' with '--start-date-lat=2002:04:11:11:11:11' which gives me daylight whereever I intend to take off. After crashing the plane I'd like to restart my choosing 'Reset' from the 'File' menu - and I'm always getting sort of local time on the respective airport (which means I'm currently sitting in the dark on Vancouver International). This is a bit annoying and it renders the option useless for most users on Our World who stick to the base package scenery - except those on the American continent. Could someone explain in a few words how the initialization on Reset differs from the initialization on startup ? Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OS-X binaries for 0.9.3-pre1
Hi James, I know Darrel Wassiler (who's probably lurking here somewhere) has already done similar work, but for my own amusement, I've been working on getting SimGear and FlightGear compiled as a framework (in the case of SimGear) and a bundle (in the case of FlightGear). This translates as 'relocatable, double-clickable end-user-application' for those who don't know OS-X packaging formats. It's not working yet (still fixing link errors), and I have a few patches to submit, but I'll keep playing over the weekend, so providing shrink-wrapped OS-X binaries for this release ought to be no problem. Great job, just tell us when you did it! Regards, Tim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OS-X binaries for 0.9.3-pre1
James Turner wrote: As a sidenote to all FG developers, it would be great if any part of the base package that normal users might want to expand can handle multiple paths : then I can locate the main base package, which is essentially static for a given release, inside the the application bundle (i.e invisible to the end user), and they can drop new aircraft / scenery / other extendable resource into a 'plugin' directory location as described above. This sounds like an excellent idea! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OS-X binaries for 0.9.3-pre1
On Thursday, October 16, 2003, at 09:55 am, Erik Hofman wrote: As a sidenote to all FG developers, it would be great if any part of the base package that normal users might want to expand can handle multiple paths : then I can locate the main base package, which is essentially static for a given release, inside the the application bundle (i.e invisible to the end user), and they can drop new aircraft / scenery / other extendable resource into a 'plugin' directory location as described above. This sounds like an excellent idea! Heh, I'll take a look once I have a working binary, then. Packaging is a pet-peeve of mine, because installing and un-installing add-ons for MSFS and Fly! was such a chore. This is related to my desire of packaging each add-on as a zip / tarball, but that's going to have to wait until the PLIB model loaders are fixed not to access the filesystem directly. Anyway, just being able to search a list of places for Scenery and Aircraft will be a start, I have no idea which other pieces of the base package end-users might modify (nav-data maybe? but even then, probably not, if releases are every 6 months ... and most people don't care about having the most accurate AIRAC cycles) HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Hud bug or feature?
The hud zooms with changes in FOV (zooming the view). Can that be fixed? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hud bug or feature?
Jim Wilson wrote: The hud zooms with changes in FOV (zooming the view). Can that be fixed? No, if the HUD is added to a 3d cockpit of the F-16 this is the behavior one would expect. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Broken initialization on Reset
Martin, I believe that Durk Talsma may have been the one who set up these options. He may still be the only one that understands how they work or are supposed to work. FWIW, you can now do something like --timeofday=noon (or morning, or dusk, or dawn, etc.) which should do something similar to what you are trying to do with the --start-date-lat= option (which I never exactly understood.) Regards, Curt. Martin Spott writes: Hello, I'm still experiencing a bug that already lasts for quite some weeks. I run 'fgfs' with '--start-date-lat=2002:04:11:11:11:11' which gives me daylight whereever I intend to take off. After crashing the plane I'd like to restart my choosing 'Reset' from the 'File' menu - and I'm always getting sort of local time on the respective airport (which means I'm currently sitting in the dark on Vancouver International). This is a bit annoying and it renders the option useless for most users on Our World who stick to the base package scenery - except those on the American continent. Could someone explain in a few words how the initialization on Reset differs from the initialization on startup ? Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hud bug or feature?
Erik Hofman [EMAIL PROTECTED] said: Jim Wilson wrote: The hud zooms with changes in FOV (zooming the view). Can that be fixed? No, if the HUD is added to a 3d cockpit of the F-16 this is the behavior one would expect. Ah yes, didn't think of that. A couple of suggestions: 1). Default to the 2D HUD unless there's a specific aircraft level configuration parameter made to override it (e.g. for the F16 2D panel). 2). Use the default HUD design in 2D HUD mode. The one that currently comes up in 2D HUD mode now is not very useful. If we're only concerned about realism we should just ditch the HUD as a default feature. But if we leave it in it should work as it used to for the majority of aircraft without special configuration. Right now it just doesn't work. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Broken initialization on Reset
Hello Curt, Curtis L. Olson [EMAIL PROTECTED] wrote: FWIW, you can now do something like --timeofday=noon (or morning, or dusk, or dawn, etc.) which should do something similar to what you are trying to do with the --start-date-lat= option [...] Yep, I already knew that ;-) but we should decide wether it would be useful to keep buggy features or better remove them completely - (or at least mark them as broken, not only in the manual but also on the '--help --verbose' command line). BTW, not only '--start-date-lat' is broken, '--timeofday' is broken as well. As far as I remember the whole stuff broke when '--timeofday' was introduced - but I'm not shure about that. That's why I asked for explanation on the initialization routine. I believe some debate would be useful to solve that: My intention would be to have one single initialization routine that gets run whenever such sort of initialization is necessary. Obviously this is currently not the case here, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Turn coordinator broken
The turn coordinator appears to have been broken at some point today. I don't think it was me (hopefully!). Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Rotor.cpp, NONE,
Curtis L. Olson [EMAIL PROTECTED] wrote: Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim In directory baron:/tmp/cvs-serv7544 Added Files: Rotor.cpp Rotor.hpp Rotorblade.cpp Rotorblade.hpp Rotorpart.cpp Rotorpart.hpp Log Message: Initial revision. Maik Justus: First pass at helicopter support for YASim. Oh, _that_ one is really nice. Although the heli is really very well behaved (even with mouse any keyboard control I find it pretty easy to fly _and_land_) I'm shure that crash detection should definitely be the next step :-)) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Rotor.cpp, NONE,
Martin Spott [EMAIL PROTECTED] said: Curtis L. Olson [EMAIL PROTECTED] wrote: Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim In directory baron:/tmp/cvs-serv7544 Added Files: Rotor.cpp Rotor.hpp Rotorblade.cpp Rotorblade.hpp Rotorpart.cpp Rotorpart.hpp Log Message: Initial revision. Maik Justus: First pass at helicopter support for YASim. Oh, _that_ one is really nice. Although the heli is really very well behaved (even with mouse any keyboard control I find it pretty easy to fly _and_land_) I'm shure that crash detection should definitely be the next step :-)) Crash detection should be working. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OS-X binaries / OpenGL includes
First the good news : I have a 'shrink-wrapped', double-clickable FlightGear CVS-as-of-today binary working on the Mac. The bad news - boy is it slow! and big (which may be why it's slow, killing the CPU caches) I need to check what debug info and optimizations are being used, because simgear is coming in at 14mb compiled, and FG at 64mb! (that's including statically linked PLIB, but even still). On my 700Mhz, Radeon 7500 Mobility equipped iBook, i'm getting 2-3 FPS in the cessna's cockpit, and 4-5 in outside views, or 7-8 if I look away from the model. If i look directly down at the ground (from the tower view, i.e to remove fill-rate / polygon-rate limits as much as possible), I can just about get 19fps However, I'm getting a new laptop in a couple of days, will see how that improves things! Anyway, before I can start submitting patches, I need to agree a solution which, alas, affects everyone, thought it's entirely of Apple's making: the OS-X openGL headers are in 'different' places from every other OS. Essentially, on the mac, we need to do: #include OpenGL/gl.h instead of #include GL/gl.h For a myriad of reasons, this cannot be symlinked or worked around - the code needs to use a different file on OS-X. The prior solution which I did (and Curt agreed to, I think), was to make the header file name a #define, define it in config.h via autoconf, But this sucks, because it's easy to end up with the value not defined, which leads to a really odd error. Here's what I'm talking about: (in config.h or on the command line via -D:) #define FG_GLUT_H GLUT/glut.h (in the file using glut) #include FG_GLUT_H So, my proposed new solution, is to add 3 files to simgear (at the root, beside sg_inlines and so on): sg_gl.h sg_glu.h sg_glut.h These will all look like: #ifdef (__APPLE__) #include OpenGL/gl.h #else #include GL/gl.h #endif Then I will go through, and convert every reference to the open GL headers over to use these new headers. How does this sound? Acceptable? Hideous? HH James -- Morbo finds all humans pathetic ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Making a 3D Sea Harrier FRS.1
On Thursday 16 October 2003 07:20, Matthew Johnson wrote: On Wed, 2003-10-15 at 22:19, Lee Elliott wrote: On Thursday 16 October 2003 01:21, Andy Ross wrote: Matthew Johnson wrote: Thought I'd take a stab at this, decided to try and make a 3D rendition of the Sea Harrier, especially since we have the Harrier in FG, but without a 3D model (I think it needs one!). So far I have started by looking for a plan that I can follow, but have only found a 3 view plan for the FA2 (upgraded version with HOTASS and new radar), anyone happen to know a 3 view plan of the FRS.1 version is hiding? Failing ever finding one, what options are open? Let me pop out of hibernation for a moment to respond to this. [Curt/Jim/Maik: I *am* going to try out the helicopter patches to YASim, I promise. Cursorily they look good, except for some high-level design issues that can be ironed out later via code motion. Feel free to commit them anyway, of course] I did the harrier flight model, and actually almost sorta got started on a 3D model to go with it. The harrier is actually quite difficult to figure out from a 3-view, honestly. Due to features like the negative camber wings, forward-slanted elephant ear intakes and protruding nozzles on the fuselage, it's very poorly represented by a single diagram. I looked through a *lot* of photos, and never did really come up with a good plan for how to do it in blender. Maybe your best bet would be to purchase a traditional plastic model, disect it, and use digital photos of that as your basis for 3D work. Andy Yes, this is quite a tricky one to model - I started on one too but stopped when I found out you were working on one as I didn't want to intrude on your patch, as it were. By all mean intrude on my patch, just want FlightGear to have its planes :). Plenty of planes to last quite some time (no Spitfire yet for instance...). The intakes and neg camber wing aren't too difficult to get around - I'd suggest doing the front fuselage as two sections, split at the intakes, and then join them together, to deal with the intakes. I can't actually see a problem with the wings. Main issue I am having right now is the cockpit area, just have not had it form correctly. Loading other planes, like the P51 has not really shown me enough to figure this out yet. The side nozzles were tricky though because they aren't just stuck on the sides of a smoothly curving fuselage. I had a lot of trouble trying to get a clear idea in my mind of the shape and curves of the fuselage in this region and stopped work on it before I'd figured it out. Ugh, you're challenged by this... Anyway, I have put the ac file up here: http://pwp.netzon.net/~stargoat/sharskel.ac Been using the pictures that were sent earlier :). Not sure if I can post them here (in a link of course). Matt I'm afraid that link doesn't work for me:( LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/FDM/YASim Rotor.cpp, NONE,
On Thursday 16 October 2003 18:10, Jim Wilson wrote: Martin Spott [EMAIL PROTECTED] said: Curtis L. Olson [EMAIL PROTECTED] wrote: Update of /var/cvs/FlightGear-0.9/source/src/FDM/YASim In directory baron:/tmp/cvs-serv7544 Added Files: Rotor.cpp Rotor.hpp Rotorblade.cpp Rotorblade.hpp Rotorpart.cpp Rotorpart.hpp Log Message: Initial revision. Maik Justus: First pass at helicopter support for YASim. Oh, _that_ one is really nice. Although the heli is really very well behaved (even with mouse any keyboard control I find it pretty easy to fly _and_land_) I'm shure that crash detection should definitely be the next step :-)) Crash detection should be working. Best, Jim LOL :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hud bug or feature?
Jim Wilson wrote: Ah yes, didn't think of that. A couple of suggestions: 1). Default to the 2D HUD unless there's a specific aircraft level configuration parameter made to override it (e.g. for the F16 2D panel). 2). Use the default HUD design in 2D HUD mode. The one that currently comes up in 2D HUD mode now is not very useful. If we're only concerned about realism we should just ditch the HUD as a default feature. But if we leave it in it should work as it used to for the majority of aircraft without special configuration. Right now it just doesn't work. The HUD needs an overhaul, that's for sure. But different people seem to expect different things from the HUD. I for one would like the HUD to behave like a HUD. right now it partially does that. The 2d doesn't. What the HUD needs to do is translate the real positions (ladder for instance) into a smaller display by compressing it with the proper value(s). Right now the 2d HUD code doesn't do that. Next thing I really want to see in the modified HUD code is the ability to set the height, width and distance to the viewer so I can project the HUD information in the appropriate display region. There are quite a number of different HUD layouts (small, wide angle, different aspect ratios, etc.) I see no real solutions for the current code but to leave it like it is right now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Turn coordinator broken
David Luff wrote: The turn coordinator appears to have been broken at some point today. I don't think it was me (hopefully!). It could have been me, I'll take a look at it tomorrow. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Turn coordinator broken
Erik Hofman wrote: David Luff wrote: The turn coordinator appears to have been broken at some point today. I don't think it was me (hopefully!). It could have been me, I'll take a look at it tomorrow. Ok. I found it, it was me after all. It's fixed in CVS now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Helicopter: First Impressions
I've been been playing with Maik's most excellent helicopter model, now in CVS: fgfs --aircraft=bo105 I can (just barely) fly it -- I'll try hooking up my rudder pedals to see if that makes it easier. One thing I don't understand is that I get a lot of small, rapid fishtail oscillations, even when the controls are perfectly still and the forward airspeed is 60 kt or higher (i.e. I'm nowhere near a hover). Is this a reflection of a real aerodynamic effect in heli's, or is it something we need to hunt down? Let's all give Maik a round of applause for this one. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Making a 3D Sea Harrier FRS.1
snip Eeep, was working late http://pwp.netzon.net/~stargoat/Shar/sharskel.ac I'm afraid that link doesn't work for me:( LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Jsbsim-devel] moving the engine files
David Culp wrote: We're two files away from being able to distribute JSBSim aircraft in a single directory, the engine file and the thruster file. There may be a reason for keeping the engines and thrusters seperate that I don't know about. Here are a couple small code changes that will change the engine and thruster paths to $FGROOT/Aircraft/model/Engines/ . Curtis added a property which could be used to get the correct directory: fgGetString(/sim/aircraft-dir) Each JSBSim aircraft would need to have an Engines subdirectory to contain the engine and thruster files. This should not bee needed since it's name is different from the aircraft name after all (or easy to adjust). There is another problem which pops up at this moment, bot YASim and JSBSim use $FG_ROOT/data/Aircraft/aircraft/aircraft.xml making it very hard to add configuration files for bot FDM's for one aircraft. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Making a 3D Sea Harrier FRS.1
On Thursday 16 October 2003 20:59, Matthew Johnson wrote: snip Eeep, was working late http://pwp.netzon.net/~stargoat/Shar/sharskel.ac I'm afraid that link doesn't work for me:( LeeE Got it - needs a bit more work methinks;) (all I could see were the four profiles) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Making a 3D Sea Harrier FRS.1
On Thu, 2003-10-16 at 13:15, Lee Elliott wrote: On Thursday 16 October 2003 20:59, Matthew Johnson wrote: snip Eeep, was working late http://pwp.netzon.net/~stargoat/Shar/sharskel.ac I'm afraid that link doesn't work for me:( LeeE Got it - needs a bit more work methinks;) (all I could see were the four profiles) LeeE Needs a tad more lol. Once I get the cockpit right its then onto the other areas, but cockpit is not coming out very well at the moment. Doing seperate halves is probably the best way to go with this, any hints on best techniques for making a good cockpit? Thanks, Matt ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Jim Wilson [EMAIL PROTECTED] wrote: Martin Spott [EMAIL PROTECTED] said: Oh, _that_ one is really nice. Although the heli is really very well behaved (even with mouse any keyboard control I find it pretty easy to fly _and_land_) I'm shure that crash detection should definitely be the next step :-)) Crash detection should be working. O.k., I'll try tomorrow. I'm curious why it didn't get triggered today. BTW, for those who never flew a heli: If you chose to stand outside then take a position on the left behind the helicopter. This makes the first steps lots easier, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Making a 3D Sea Harrier FRS.1
Matthew Johnson [EMAIL PROTECTED] said: Needs a tad more lol. Once I get the cockpit right its then onto the other areas, but cockpit is not coming out very well at the moment. Doing seperate halves is probably the best way to go with this, any hints on best techniques for making a good cockpit? Do the exterior of the aircraft first. Then cutout/duplicate segments of the exterior surrounding the cockpit area. Take those duplicated polys and reduce them about 5% on all axes and then flip the normals so you now have interior surfaces. Then you can add a flat floor, panel, dash, seat, etc. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Making a 3D Sea Harrier FRS.1
On Thursday 16 October 2003 21:27, Matthew Johnson wrote: On Thu, 2003-10-16 at 13:15, Lee Elliott wrote: On Thursday 16 October 2003 20:59, Matthew Johnson wrote: snip Eeep, was working late http://pwp.netzon.net/~stargoat/Shar/sharskel.ac I'm afraid that link doesn't work for me:( LeeE Got it - needs a bit more work methinks;) (all I could see were the four profiles) LeeE Needs a tad more lol. Once I get the cockpit right its then onto the other areas, but cockpit is not coming out very well at the moment. Doing seperate halves is probably the best way to go with this, any hints on best techniques for making a good cockpit? Thanks, Matt Along with splitting the 3-view into separate top, side and front templates, and aligning them, if I have any x-sections I'll put them in the appropriate places and use them as guides. I tend to pick the widest or most complex x-section in the fuselage as a starting point and create a syrface from it, which I then extrude to the front and back of the a/c. After I've extruded a section I stretch/ re-scale it in the top and side views to match up with the 3-view templates and the profile, if one exists, at that point in the fuselage. This will give you the basic form of the a/c which you'll then have to fine-tune. I find I spend a lot of time in front/rear view when doing the fine stuff. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Helicopter: First Impressions
David Megginson [EMAIL PROTECTED] said: I can (just barely) fly it -- I'll try hooking up my rudder pedals to see if that makes it easier. One thing I don't understand is that I get a lot of small, rapid fishtail oscillations, even when the controls are perfectly still and the forward airspeed is 60 kt or higher (i.e. I'm nowhere near a hover). Is this a reflection of a real aerodynamic effect in heli's, or is it something we need to hunt down? This isn't happening here. How are you controlling the antitorque (rudder)? Maybe the problem is in the control input? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Helicopter: First Impressions
David Megginson [EMAIL PROTECTED] wrote: Let's all give Maik a round of applause for this one. Indeed ! I'd say: When dreams come true , Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
David Megginson writes: Martin Spott writes: O.k., I'll try tomorrow. I'm curious why it didn't get triggered today. BTW, for those who never flew a heli: If you chose to stand outside then take a position on the left behind the helicopter. This makes the first steps lots easier, There are still some problems we need to work out. For example, if you set the wind to 0 and turn off the engine, the helicopter still slides backwards and turns -- we'll have to figure out why there are forces acting on it. To test: fgfs --aircraft=bo105 [EMAIL PROTECTED] --prop:/controls/engines/engine/magnetos=0 This does not happen with fixed-wing JSBSim models. It also loops quite easily ... not saying that was the first thing I tried. How do you run the collective? How about yaw control? The rudder seemed to act more like an aerodynamic rudder ... not that I know anything about how a helo is supposed to fly ... Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Helicopter: First Impressions
Jim Wilson writes: This isn't happening here. How are you controlling the antitorque (rudder)? Maybe the problem is in the control input? I've tried it with two different controllers and seem the same effect -- furthermore, the control-position indicators on the HUD are not moving, suggesting that the flutter isn't coming from there. Are you sure that you don't see yaw flutter at all? Try cruising around for five minutes or so -- it always shows up for me. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
On Thu, 16 Oct 2003 17:15:02 -0400 David Megginson [EMAIL PROTECTED] wrote: There are still some problems we need to work out. For example, if you set the wind to 0 and turn off the engine, the helicopter still slides backwards and turns -- we'll have to figure out why there are forces acting on it. To test: fgfs --aircraft=bo105 [EMAIL PROTECTED] --prop:/controls/engines/engine/magnetos=0 This does not happen with fixed-wing JSBSim models. !? Why would it? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Curtis L. Olson writes: It also loops quite easily ... not saying that was the first thing I tried. How do you run the collective? How about yaw control? The rudder seemed to act more like an aerodynamic rudder ... not that I know anything about how a helo is supposed to fly ... Try this page: http://www.helicopterpage.com/ All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Jon S Berndt writes: On Thu, 16 Oct 2003 17:15:02 -0400 David Megginson [EMAIL PROTECTED] wrote: There are still some problems we need to work out. For example, if you set the wind to 0 and turn off the engine, the helicopter still slides backwards and turns -- we'll have to figure out why there are forces acting on it. To test: fgfs --aircraft=bo105 [EMAIL PROTECTED] --prop:/controls/engines/engine/magnetos=0 This does not happen with fixed-wing JSBSim models. Sorry, once again s/JSBSim/YASim/g. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] new FGSimTurbine configs
For those aircraft using FGSimTurbine engines (737, an225?, A320, F5, F16, T38, OV10, t6texan2, fokker50, fokker100) here are some engine configuration files edited to meet the new format. http://home.comcast.net/~davidculp2/newFGSimTurbines.tar.gz Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
David Megginson [EMAIL PROTECTED] said: Martin Spott writes: O.k., I'll try tomorrow. I'm curious why it didn't get triggered today. BTW, for those who never flew a heli: If you chose to stand outside then take a position on the left behind the helicopter. This makes the first steps lots easier, There are still some problems we need to work out. For example, if you set the wind to 0 and turn off the engine, the helicopter still slides backwards and turns -- we'll have to figure out why there are forces acting on it. To test: fgfs --aircraft=bo105 [EMAIL PROTECTED] --prop:/controls/engines/engine/magnetos=0 This does not happen with fixed-wing JSBSim models. In YASim a lot of this seems to have to do with weight distribution and gear location. In real life terms that sounds weird but it does make a little bit of sense. I've noticed if the CG is too far forward it'll creep forward, to far back and it'll creep backward. It's probably related to the gear compression code. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Helicopter: First Impressions
David Megginson [EMAIL PROTECTED] said: Jim Wilson writes: This isn't happening here. How are you controlling the antitorque (rudder)? Maybe the problem is in the control input? I've tried it with two different controllers and seem the same effect -- furthermore, the control-position indicators on the HUD are not moving, suggesting that the flutter isn't coming from there. Are you sure that you don't see yaw flutter at all? Try cruising around for five minutes or so -- it always shows up for me. Not at all. I've probably got an hour or more on it. Just took it for from SFO to the golden gate and then back to try and land in the football stadium. The tail rotor animation is a little off center, but that's it. Maybe this is related to cpu speed somehow. What I have noticed is that overspeed effects don't seem to show up (negative speed on the blades coming back should cause a stall) and if you get it up to far enough over 200 it seems as though it'll hold speed and altitude forever even with the collective all the way down. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Curtis L. Olson [EMAIL PROTECTED] said: It also loops quite easily ... not saying that was the first thing I tried. How do you run the collective? How about yaw control? The rudder seemed to act more like an aerodynamic rudder ... not that I know anything about how a helo is supposed to fly ... The collective is mapped to the throttle control, antitorque/yaw (tail rotor) to rudder, and cyclic (roll/pitch) to the stick. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hud bug or feature?
Erik Hofman [EMAIL PROTECTED] said: I see no real solutions for the current code but to leave it like it is right now. You didn't read my message. Most of our aircraft don't have HUDs in real life so it is only there for the convenience of the user. For these aircraft it doesn't have to behave like a real HUD because it isn't real. Can't we just default to the 2D? The ONE aircraft that needs the 3D could have a configuration parameter to initiate it. We don't have to make major changes now, but we should at least be releasing code that works, even if it is considered inadequate by some. The 2D hud works. Should I submit a patch? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hud bug or feature?
At Thu, 16 Oct 2003 23:45:29 - , Jim Wilson wrote: Can't we just default to the 2D? The ONE aircraft that needs the 3D could have a configuration parameter to initiate it. We don't have to make major changes now, but we should at least be releasing code that works, even if it is considered inadequate by some. The 2D hud works. Should I submit a patch? umm how about just adding --disable-hud3d or its XML equivalent to your local preferences Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Lee's TSR2
Curtis L. Olson [EMAIL PROTECTED] said: I just commited a bunch of updates to Lee's TSR2 (--aircraft=tsr2-yasim) It's a sweet flyer and nice looker. In the cockpit view you can hit P toggle a 2d panel on that probably isn't like the real thing, but gives you the info you need to do most IFR flying. Nice canopy animation (Shift-B) That looks really cool from inside. Actually I was confused at first when I started the sim and hit the parking brake because my throttle was on a little :-). and nice speed brakes (j/k). Also, it has really nice gear animation (both the suspention and the retraction sequence.) Nice gear compression animation too. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
David Megginson [EMAIL PROTECTED] wrote: There are still some problems we need to work out. For example, if you set the wind to 0 and turn off the engine, the helicopter still slides backwards and turns -- we'll have to figure out why there are forces acting on it. To test: fgfs --aircraft=bo105 [EMAIL PROTECTED] --prop:/controls/engines/engine/magnetos=0 You can avoid typing the wholöe line by simply clicking 'Reset' after the FG screen comes up - engine is off which means: I already knew that ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Helicopter: First Impressions
David Megginson [EMAIL PROTECTED] wrote: I've tried it with two different controllers and seem the same effect -- furthermore, the control-position indicators on the HUD are not moving, suggesting that the flutter isn't coming from there. Very different here. The indicators on the HUD were moving and the heli flies very calm. Did you recompile the stuff from scratch ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
