Re: [Flightgear-devel] Getting data out of FlightGear
Martin Spott wrote: Just my personal view, Please forgive me all those typos, it's a bit early in the morning, 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
On Mon, Nov 22, 2004 at 02:55:15PM -0600, Curtis L. Olson wrote: What's wrong with network byte order? Nothing, I guess. Doesn't define floating point representation, though. What's wrong with ASCII? Cheers -Gerhard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Garmin GNS 530
So, one would really need to define a corresponding network interface. This does already exist and is specified in the ``400/500 Series Flight Sim ICD.'', a proprietary Garmin document. It describes the RS232 interface of their _hardware_ simulator units. I guess Bill Stone would give it to interested parties even if they don't buy a simulator unit. Extend the interface with knobs, buttons and light sensor, and you have an ICD for a software interface. Cheers -Gerhard -- Gerhard Wesp o o Tel.: +41 (0) 43 5347636 Bachtobelstrasse 56 | http://www.cosy.sbg.ac.at/~gwesp/ CH-8045 Zuerich \_/ See homepage for email address! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear Compile error - related to openal
Vivian Meazza wrote: Dale E. Edmons wrote [EMAIL PROTECTED] wrote: Hi, all, I encountered a compile error when make the simgear-0.3.7 for FlightGear-0.9.6. I am working with Cygwin in windows 2000 and I have plib and Zlib done. ... snip ... Got to /etc/ld.so.conf and see if it has /usr/local/lib or whereever you installed openal. Edit the file if the directory entry is not present. Then try doing ldconfig and see if it works. I updated my SimGear, PLIB, and OpenAl from CVS and recompiled them all and I had no problems. (I'm running Debian Linux testing branch.) This may well work for Linux (although I think it should work right out of the box) but AFAIK will not work for Cygwin. OpenAL has not yet been formally implemented with Cygwin, hence the need to download and install the special version I mentioned earlier. My browser was scrolled down and I didn't see your reply before I hit send. Guess I need new glasses. Oops, I'm wearing my new glasses. Oh boy. Dale Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
Gerhard Wesp wrote: On Mon, Nov 22, 2004 at 02:55:15PM -0600, Curtis L. Olson wrote: What's wrong with network byte order? Nothing, I guess. Doesn't define floating point representation, though. Ah, this gives me a hint. There are functions called htond() and htonf() in the following files (these functions really need to be moved to one place in SimGear): native_fdm.cxx native_ctrls.cxx native_gui.cxx I don't think these functions are ever tested within FlightGear. This would be the first thing I would check. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] openal wind.wav: correct pitch?
When Curt introduced OpenAL to fgfs, he wrote[1]: | 2. The plib sound system was set to play at 8000 hz no matter what the | sample was recorded at. So a 22000 hz sample wouldn't play at the right | pitch by default. We compensated in our sound config files for this by | offsetting the pitch by 22000/8000 to get the sound back in the right | range. However, that means that with OpenAL which handles this | correctly, some portions of our sound configs will need to get | retweaked to make the pitch correct again. Most sounds are fine, it's | just a few of them where there is this issue. Since a while I noticed that the wind sound is much too much pitched up for my taste. And indeed, wind.wav has been sampled at 22kHz: $ file wind.wav wind.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit, mono 22050 Hz Has this ever been considered? I don't think so. (I remember that I changed the wind pitch in the bo105 sound config, but this would then only be an ugly workaround.) Is our wind sound still waiting for a proper fix (resampling or changing all sound configs)? Or is anyone else happy with it!? m. [1] http://baron.flightgear.org/pipermail/flightgear-devel/2004-April/027549.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Magnetic Compass
On Tuesday 23 November 2004 01:16, Alex Perry wrote:
From: Boris Koenig [EMAIL PROTECTED]
David Megginson wrote:
I understand
that there are USB devices that you can wear on your head to control
the view in games, and those would probably work in FlightGear, but it
would be hard to survive the ridicule from family, friends, and
neighbours for wearing one.
LOL, that would indeed be very amusing ... must probably look very
similar to the BORG on Star Trek ;-)
There are two different things here.
Normally, for gaming, people want to keep their head stationary
(in linear dimensions) and look in different directions (angular).
What people are talking about here is wanting to keep their
direction of gaze (fixed object) but change their point of view.
The former is easily addressed with a simple magnetic compass module,
to figure out which way you're looking, and a head mount display so
that the screen is always located in the correct direction (in front).
The compass module is usually integrated into the HMD and so not really
a source of looking 'odd', at least compared to the HMD unit itself.
However, the compass module doesn't work when the user wants to be able
to move their head and still look in the same direction. For example,
to lean forward in order to read the tiny little numbers on the altimeter.
For that, you need to track the position of the head, not direction,
so you really want a different kind of sensor to address that need.
You don't need a HMD either, since the instrument panel doesn't move.
There are sensors for this, for example by putting ultrasonic ranging
transducers on your head and on the four corners of the monitor,
but nothing I'd really recommend to you as being a marvellous solution.
Assuming there is a network socket that is providing the 3D position
of the nose (for example) of the user with respect to the monitor,
how hard is it to get FGFS to slew the camera/viewport relationship ?
The properties for the camera/viewport
are: /sim/current-view/{x,y,z}-offset-m. So it should be quite easy.
I've attached a patch to mice.xml that lets you move the camera/viewport with
the middle mouse button pressed in mouse view mode. Useful for looking at the
compass head on.
--
Roy Vegard Ovesen
Index: mice.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/mice.xml,v
retrieving revision 1.16
diff -p -u -r1.16 mice.xml
--- mice.xml 24 Jun 2004 14:45:48 - 1.16
+++ mice.xml 23 Nov 2004 12:33:33 -
@@ -208,7 +208,7 @@ current mode for each mouse is held in t
!-- Mouse left/right motion --
x-axis
-!-- No buttons pressed: move the view position left or right --
+!-- No buttons pressed: rotate the view left or right --
binding
condition
and
@@ -228,6 +228,25 @@ current mode for each mouse is held in t
wrap type=booltrue/wrap
/binding
+
+!-- Middle button pressed: move the view position left or right --
+binding
+ condition
+ and
+ not
+property/devices/status/mice/mouse[0]/button[0]/property
+ /not
+ property/devices/status/mice/mouse[0]/button[1]/property
+ /and
+ /condition
+ commandproperty-adjust/command
+ property/sim/current-view/x-offset-m/property
+ factor type=double1/factor
+ min type=double-0.5/min
+ max type=double0.5/max
+ wrap type=boolfalse/wrap
+/binding
+
/x-axis
!-- Mouse up/down motion --
@@ -252,6 +271,25 @@ current mode for each mouse is held in t
max type=double90/max
wrap type=boolfalse/wrap
/binding
+
+!-- Middle button pressed: move the view up and down --
+binding
+ condition
+ and
+ not
+property/devices/status/mice/mouse[0]/button[0]/property
+ /not
+property/devices/status/mice/mouse[0]/button[1]/property
+ /and
+ /condition
+ commandproperty-adjust/command
+ property/sim/current-view/y-offset-m/property
+ factor type=double-1/factor
+ min type=double-0.5/min
+ max type=double0.5/max
+ wrap type=boolfalse/wrap
+/binding
+
/y-axis
/mode
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: openal wind.wav: correct pitch?
* Melchior FRANZ -- Tuesday 23 November 2004 13:20: (I remember that I changed the wind pitch in the bo105 sound config, but this would then only be an ugly workaround.) Too humble. Actually, this would have been a correct fix. It's just the question if I go the new numbers right. And if all sound files should be fixed the same way then, or the wav file replaced instead. Or is anyone else happy with it!? Should have been: is *everyone* else happy with it? m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Magnetic Compass
* Roy Vegard Ovesen -- Tuesday 23 November 2004 13:41: I've attached a patch to mice.xml that lets you move the camera/viewport with the middle mouse button pressed in mouse view mode. Useful for looking at the compass head on. Very cool. There are two problems, though: I can move my 'head' down very far (below the bo105's floor), but I can hardly move it up. And the possibility to restore the original position on middle mouse click is lost. (I tend to keep that patch applied anyway. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Garmin GNS 530
On Tue, 23 Nov 2004 09:50:14 +0100, Gerhard wrote in message [EMAIL PROTECTED]: So, one would really need to define a corresponding network interface. This does already exist and is specified in the ``400/500 Series Flight Sim ICD.'', a proprietary Garmin document. It describes the RS232 interface of their _hardware_ simulator units. I guess Bill Stone would give it to interested parties even if they don't buy a simulator unit. Extend the interface with knobs, buttons and light sensor, and you have an ICD for a software interface. ..ah. How about Garmin's competition? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Garmin GNS 530
Gerhard Wesp wrote: So, one would really need to define a corresponding network interface. This does already exist and is specified in the ``400/500 Series Flight Sim ICD.'', a proprietary Garmin document. It describes the RS232 interface of their _hardware_ simulator units. I guess Bill Stone would give it to interested parties even if they don't buy a simulator unit. Well thanks for the pointer, I am going to contact Garmin yet another time anyway: Another FlightGear user informed me yesterday that there IS already an application that interfaces the original (software) simulator unit with MS FS 200x - this seems to be based on FSUIPC and is called FSGarmin. Indeed, said company did even SELL the interface for about $ 40 US, until they went out of business about 2 yrs ago (?) But before they went out of business they made their software freely available - there's also a support forum for that software at: http://forums.avsim.net/dcboard.php?az=show_topicsforum=178 What surprised me is that Garmin didn't seem to know about the project. So I will gather more information why Mr. Stone didn't mention said project ... This supports rumours that I could find on the web about Micro$oft swallowing the company ... after all they also support some garmin GPS devices ;-) Even more interesting: FSAvionics.com (SimSystems) did even provide an interface for X-Plane some time ago, so depending whether we will be able to get in touch with the original developers it might be interesting to learn about ways to revamp the interface to work with FG. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
From: Lee Elliott On Thursday 18 November 2004 21:03, Martin Spott wrote: Lee Elliott wrote: um, yes - the TSR-2 probably isn't the best a/c for carrier stuff. The FDM needs really an overhaul because the take-off performance isn't right - it currently lifts off at a lower speed if reheat isn't used :( - and it was designed to have a good stol performance, [...] It was designed for ?? STOL performance ? _These_ small wings !? Oh man, I must have missed a lesson ;-)) Martin. Yeah - and rough strips too. I believe the STO was achieved by extending the nose gear strut to increase the initial AoA. Not only would this provide more lift over the wings, it would also result in a useful down-thrust component from the engines, especially when afterburning was used. I also believe the main gear was designed to tolerate less than perfect strips. Don't know for sure but a braking parachute might have been planned too. LeeE The TSR2 also had blown flaps for short and rough take offs: http://patter.mine.nu/tsr2-2.htm Richard This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Magnetic Compass
On Tuesday 23 November 2004 14:18, Melchior FRANZ wrote: * Roy Vegard Ovesen -- Tuesday 23 November 2004 13:41: I've attached a patch to mice.xml that lets you move the camera/viewport with the middle mouse button pressed in mouse view mode. Useful for looking at the compass head on. Very cool. There are two problems, though: I can move my 'head' down very far (below the bo105's floor), but I can hardly move it up. And the possibility to restore the original position on middle mouse click is lost. (I tend to keep that patch applied anyway. :-) I only tested it in the default cessna where max and min limits of 0.5 meters from the origin seemed reasonable, you can imagine what happened when I tried the A320 where the initial y-offset is way above 0.5 meters :-(. Perhaps the movement limits should be aircraft specific, any volunteers ;-) Restoring the original position with the _middle_ button? I'm only familiar with restoring the orientation with the _left_ button. I guess that it would be possible to also restore the position with the left button, but I think that restoring the orientation only is actually quite usefull. I've also noticed that the position sometimes jumps to it's min or max position, this seem to happen when the cursor wraps from from one edge of the screen to the opposite. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Magnetic Compass
* Roy Vegard Ovesen -- Tuesday 23 November 2004 15:51: I only tested it in the default cessna where max and min limits of 0.5 meters from the origin seemed reasonable, you can imagine what happened when I tried the A320 where the initial y-offset is way above 0.5 meters :-(. Perhaps the movement limits should be aircraft specific, any volunteers ;-) volunt.. WHAT?!? ... Having this settable per aircraft would be nice. Restoring the original position with the _middle_ button? I'm only familiar with restoring the orientation with the _left_ button. Whoops, OK. (As an excuse: I do normally reset the view direction with my js -- even have two separate functions there. Was so excited about the new mouse functionality, that I got this wrong. Sorry. Cancel the second complaint, then. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Magnetic Compass
* Roy Vegard Ovesen -- Tuesday 23 November 2004 15:51: I only tested it in the default cessna where max and min limits of 0.5 meters from the origin seemed reasonable, Should have tried the FA-18A. Completely unusable there. You immediately end up between the pilot's legs and there's no way to get back up. But can go further down and watch the scenery through the open front wheel bay. Resetting fgfs doesn't help either. But once fixed this feature will be very useful. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Magnetic Compass
On Tuesday 23 November 2004 16:30, Melchior FRANZ wrote: Should have tried the FA-18A. Completely unusable there. You immediately end up between the pilot's legs and there's no way to get back up. But can go further down and watch the scenery through the open front wheel bay. Resetting fgfs doesn't help either. But once fixed this feature will be very useful. Yes, that's what happened in the Airbus too, and it should also happen to any large aircraft. You can easily fix this by making the min and max values in mice.xml greater. I set them to -10 and 10 meters respectively for both x and y axes, I guess that should be enough for most aircraft. Setting these limits to reasonable values (inside the cockpit) for every aircraft would be, as you can imagine, quite a labourous job. Maybe someone over on the users list would be willing to have a go at it? Every so often I see users that ask how to contribute. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Magnetic Compass
Melchior FRANZ writes: * Melchior FRANZ -- Tuesday 23 November 2004 17:14: I'm volunteering already No, I take that back. Mouse properties are (like kbd * js bindings) fixed at the beginning. min/max can't easily be changed afterwards, and I don't feel like re-writing the whole input module. Better set the default to +/- 5m. Can't you just load the properties that you want and then call reinit() on the whole FGInput subsytem Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] README.todo (was: Re: Magnetic Compass)
On Tuesday 23 November 2004 17:31, Boris Koenig wrote:
I haven't yet really played with 3D cockpits: what exactly would be
involved in adding such support ?
The support is already there: it is possible to set the view position at
runtime through the /sim/current-view/{x,y,z}-offset-m properties.
You can apply the patch to $FG_ROOT/mice.xml attached to this posting.
http://baron.flightgear.org/pipermail/flightgear-devel/2004-November/032316.html
What exactly would it make so
complex ?
Actually it is not complex at all, assuming that it is possible to configure
the mouse bindings individually for every aircraft. Then it would simply be a
matter of
* Run FlightGear
* Change the /sim/current-view/{x,y,z}-offset-m properties to find reasonable
values for the limits that the view should be allowed to move.
* Add a mouse binding to the aircraft *-set.xml (I assume) file with the found
min and max values.
* Repeat for every aircraft model. ;-)
--
Roy Vegard Ovesen
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Magnetic Compass
* Norman Vine -- Tuesday 23 November 2004 18:19:
* * Melchior FRANZ writes:
Mouse properties are (like kbd * js bindings)
fixed at the beginning. min/max can't easily be changed afterwards,
and I don't feel like re-writing the whole input module. Better set
the default to +/- 5m.
Can't you just load the properties that you want
and then call reinit() on the whole FGInput subsytem
What I had: {x,y}-offset-{min,max}-m settings for each view
(only really defined for cockpit view, but settable for the
others as well). Aircraft specific settings in the bo105 config,
and changes to src/Main/viewmgr.cxx that would copy the correct
settings to /view/current-view. mice.xml used property aliases
that pointed there. It all worked, except that the mouse didn't
care for the changed properties.
re-init-ing js/kbd/mice with every view change should have worked,
but isn't that a bit too expensive? And even if only the mouse
parts were re-init-ed, this sounds like a work-around, rather than
a solution.
m.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Magnetic Compass
On Tuesday 23 November 2004 18:05, Melchior FRANZ wrote: No, I take that back. Mouse properties are (like kbd * js bindings) fixed at the beginning. min/max can't easily be changed afterwards, and I don't feel like re-writing the whole input module. Better set the default to +/- 5m. You can include only the required axis bindings in your aircraft *-set.xml file, like this (for the default cessna): input mice mouse n=0 !-- Mode 2: view mode -- mode n=2 !-- Mouse left/right motion -- x-axis !-- No buttons pressed: rotate the view left or right -- binding condition and not property/devices/status/mice/mouse[0]/button[0]/property /not not property/devices/status/mice/mouse[0]/button[1]/property /not /and /condition commandproperty-adjust/command property/sim/current-view/heading-offset-deg/property factor type=double-360/factor min type=double0/min max type=double360/max wrap type=booltrue/wrap /binding !-- Middle button pressed: move the view position left or right -- binding condition and not property/devices/status/mice/mouse[0]/button[0]/property /not property/devices/status/mice/mouse[0]/button[1]/property /and /condition commandproperty-adjust/command property/sim/current-view/x-offset-m/property factor type=double0.75/factor min type=double-0.5/min max type=double0.5/max wrap type=boolfalse/wrap /binding /x-axis !-- Mouse up/down motion -- y-axis !-- No buttons pressed: tilt the view up and down -- binding condition and not property/devices/status/mice/mouse[0]/button[0]/property /not not property/devices/status/mice/mouse[0]/button[1]/property /not /and /condition commandproperty-adjust/command property/sim/current-view/pitch-offset-deg/property factor type=double-180/factor min type=double-90/min max type=double90/max wrap type=boolfalse/wrap /binding !-- Middle button pressed: move the view up and down -- binding condition and not property/devices/status/mice/mouse[0]/button[0]/property /not property/devices/status/mice/mouse[0]/button[1]/property /and /condition commandproperty-adjust/command property/sim/current-view/y-offset-m/property factor type=double-0.75/factor min type=double-0.4/min max type=double0.4/max wrap type=boolfalse/wrap /binding /y-axis /mode /mouse /mice /input This will override the settings in mice.xml, but it will only override the settings that are defined here, so all the existing modes in mice.xml are used. As I said earlier it will be a lot of work to do this to every aircraft model. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] README.todo
Roy Vegard Ovesen wrote:
On Tuesday 23 November 2004 17:31, Boris Koenig wrote:
I haven't yet really played with 3D cockpits: what exactly would be
involved in adding such support ?
The support is already there: it is possible to set the view position at
runtime through the /sim/current-view/{x,y,z}-offset-m properties.
You can apply the patch to $FG_ROOT/mice.xml attached to this posting.
http://baron.flightgear.org/pipermail/flightgear-devel/2004-November/032316.html
Ya, thanks - I know, I did follow that discussion, I was merely
wondering where exactly the complexity comes in ;-)
So, whether it would require any significant code changes or whether
it would come down to time-consuming manual trial error means ;-)
What exactly would it make so
complex ?
Actually it is not complex at all, assuming that it is possible to configure
the mouse bindings individually for every aircraft. Then it would simply be a
matter of
* Run FlightGear
* Change the /sim/current-view/{x,y,z}-offset-m properties to find reasonable
values for the limits that the view should be allowed to move.
* Add a mouse binding to the aircraft *-set.xml (I assume) file with the found
min and max values.
* Repeat for every aircraft model. ;-)
I think it was Melchior who mentioned that the min/max values are
specific to certain aircrafts or rather cockpits ?
Taking into consideration that the a3c files are plain text and hence
readable for simple shell scripting, I wonder now whether suitable
min/max values can be derived from any *general* data that's preferably
available in most *.ac files: that way one could use a shell script:
- read in the corresponding data
- determine suitable min/max values
- automatically put the binding stuff into *-set.xml
Again: I don't know anything about cockpit design or 3D design in
general, I would simply *guess* that it should be possible to determine
the dimensions of a cockpit based on the *.ac file ...
Maybe I am making things too simple, though ;-)
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Magnetic Compass
Roy Vegard Ovesen wrote: On Tuesday 23 November 2004 18:05, Melchior FRANZ wrote: No, I take that back. Mouse properties are (like kbd * js bindings) fixed at the beginning. min/max can't easily be changed afterwards, and I don't feel like re-writing the whole input module. Better set the default to +/- 5m. You can include only the required axis bindings in your aircraft *-set.xml file, like this (for the default cessna): [...] This will override the settings in mice.xml, but it will only override the settings that are defined here, so all the existing modes in mice.xml are used. As I said earlier it will be a lot of work to do this to every aircraft model. Please correct me if I am wrong: - There are only two parameters that are a/c specifc: min/max ? - The tags for custom bindings remain basically identical ? If the above is true to some extent, my suggestion for a temporary workaround would be to use an external file that takes care of the bindings, but uses parameters taken from the property tree instead of fixed values: I have done something very similar when I needed to add support for dynamic layer positioning (to be able to use nasal code to re-position layers based on certain actions), by using a property child instead of a fixed value within the x/ or y/ tags. So, one could think about using one general bindings file that's included by the *-set.xml files - that way each aircraft could put its min/max values directly into the right location within the property tree. What do you think, am I still missing the point ? :-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] README.todo
On Tuesday 23 November 2004 19:46, Boris Koenig wrote: I think it was Melchior who mentioned that the min/max values are specific to certain aircrafts or rather cockpits ? Taking into consideration that the a3c files are plain text and hence readable for simple shell scripting, I wonder now whether suitable min/max values can be derived from any *general* data that's preferably available in most *.ac files: that way one could use a shell script: - read in the corresponding data - determine suitable min/max values - automatically put the binding stuff into *-set.xml Again: I don't know anything about cockpit design or 3D design in general, I would simply *guess* that it should be possible to determine the dimensions of a cockpit based on the *.ac file ... The object names inside the *.ac files could be anything, so I guess it would be very hard to determine what objects and also what vertices that is supposed to be the cockpit. I think that a better approach is to look at the default position of the viewpoint. This is defined in the *-set.xml file like this: !-- position the pilot viewpoint and angle -- view internal archive=ytrue/internal config x-offset-m archive=y-0.18/x-offset-m y-offset-m archive=y0.30/y-offset-m z-offset-m archive=y0.36/z-offset-m pitch-offset-deg-12/pitch-offset-deg /config /view Now if we assume that a pilot is able to move his head say 0.5 meters in every direction, we simply add and subtract 0.5 to the default position, and there you have your limits. Of course you could argue that a pilot with his/her but on the seat is not able to move her/his head very much it the up direction. Maybe I am making things too simple, though ;-) Or too hard ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Magnetic Compass
On Tuesday 23 November 2004 00:16, Alex Perry wrote: From: Boris Koenig [EMAIL PROTECTED] David Megginson wrote: I understand that there are USB devices that you can wear on your head to control the view in games, and those would probably work in FlightGear, but it would be hard to survive the ridicule from family, friends, and neighbours for wearing one. LOL, that would indeed be very amusing ... must probably look very similar to the BORG on Star Trek ;-) There are two different things here. Normally, for gaming, people want to keep their head stationary (in linear dimensions) and look in different directions (angular). What people are talking about here is wanting to keep their direction of gaze (fixed object) but change their point of view. The former is easily addressed with a simple magnetic compass module, to figure out which way you're looking, and a head mount display so that the screen is always located in the correct direction (in front). The compass module is usually integrated into the HMD and so not really a source of looking 'odd', at least compared to the HMD unit itself. However, the compass module doesn't work when the user wants to be able to move their head and still look in the same direction. For example, to lean forward in order to read the tiny little numbers on the altimeter. For that, you need to track the position of the head, not direction, so you really want a different kind of sensor to address that need. You don't need a HMD either, since the instrument panel doesn't move. There are sensors for this, for example by putting ultrasonic ranging transducers on your head and on the four corners of the monitor, but nothing I'd really recommend to you as being a marvellous solution. Assuming there is a network socket that is providing the 3D position of the nose (for example) of the user with respect to the monitor, how hard is it to get FGFS to slew the camera/viewport relationship ? I've got stuff lying around at work here that is fairly cheap and can be made to do the sensing job, so it'd be interesting to try it out ... I had a bit of a go at something along the lines of moving the viewpoint in the Comper Swift. The design of the a/c meant that the wing was directly in front of the eyes (in early models of the Swift the altimeter and airspeed indicator were set into the cut-out in the trailing edge of the wing around the cockpit) so it was necessary for the pilot to lean out to either side to get a view directly ahead. As the Swift didn't have flaps I re-mapped the key bindings to move the cockpit view sideways - when I get around to updating it I'll use Nasal to handle it. Anyway, when I also get around to making the 3d instruments for the cockpit, the viewpoint change should work with the 3d instruments, one of which, iirc, was a horizontally mounted mag compass that cantilevered out from the panel. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Magnetic Compass
On Monday, 22 November 2004 22:37, Boris Koenig wrote: David Megginson wrote: I understand that there are USB devices that you can wear on your head to control the view in games, and those would probably work in FlightGear, but it would be hard to survive the ridicule from family, friends, and neighbours for wearing one. LOL, that would indeed be very amusing ... must probably look very similar to the BORG on Star Trek ;-) There is also a program called Cam2Pan that uses a standard webcam to track facial movement WITHOUT needing to stick anything weird on your head. Of course it's closed source, proprietary and only runs on Winbloze. From all the reviews I've read about it it evidently does not work as nicely as TrackIR3. BTW : The reflective stickers that TrackIR uses can be stuck to anything including a cap or microphone boom. If you want to stick it on your forehead and forget it there when you go to the shops is your problem! :) I think some sort of head tracking device would be great in FG especially with the 3D cockpits. Using a mouse and yoke/joystick at the same time is a bit tricky. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Magnetic Compass
On Tuesday 23 November 2004 19:55, Melchior FRANZ wrote: Sure, but that's yet another ugly hack. I'd prefer a *solution*. I don't use a standard mice.xml, and I would really hate if every aircraft designer messes with mouse settings and overwrites my stuff. What's next? Aircrafts overwriting my carefully chosen joystick settings? No wait, that's already done in (the otherwise beautifully) b1900d ... I really thought that overriding defaults from preferences.xml was a good solution. *-set.xml is used to override all kinds of other stuff, including keyboard and joystick settings, so why not override mouse settings too!? -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Magnetic Compass
* Roy Vegard Ovesen -- Tuesday 23 November 2004 20:39: I really thought that overriding defaults from preferences.xml was a good solution. *-set.xml is used to override all kinds of other stuff, including keyboard and joystick settings, so why not override mouse settings too!? Aircrafts aren't supposed to override all sorts of setting -- only theirs! For example, even if preferences.xml says that the flaps shall not be lowered by default, the aircraft may *of course* override that. (Who owns the flaps?) There are other groups of properties that are not owned by the aircraft. I would not accept that an aircraft config file changes the weather or the daytime. That's world stuff. Nor would I accept if one changed sim stuff (e.g. the rendering method) or hardware stuff (mouse/joystick). One aircraft, for example, tried to disable the atc and ai-model subsystems. No need to mention that this was thrown out. As a workaround I'd rather set min/max to 2 or 3m for all aircrafts. And the ideal solution would be to let the input system really *use* properties, not just to read them once at startup and never look at them again. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Data/AI
On Tuesday 23 November 2004 13:59, Richard Bytheway wrote: From: Lee Elliott On Thursday 18 November 2004 21:03, Martin Spott wrote: Lee Elliott wrote: um, yes - the TSR-2 probably isn't the best a/c for carrier stuff. The FDM needs really an overhaul because the take-off performance isn't right - it currently lifts off at a lower speed if reheat isn't used :( - and it was designed to have a good stol performance, [...] It was designed for ?? STOL performance ? _These_ small wings !? Oh man, I must have missed a lesson ;-)) Martin. Yeah - and rough strips too. I believe the STO was achieved by extending the nose gear strut to increase the initial AoA. Not only would this provide more lift over the wings, it would also result in a useful down-thrust component from the engines, especially when afterburning was used. I also believe the main gear was designed to tolerate less than perfect strips. Don't know for sure but a braking parachute might have been planned too. LeeE The TSR2 also had blown flaps for short and rough take offs: http://patter.mine.nu/tsr2-2.htm Richard Thanks for posting that link - interesting reading - saved:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft directory structure
Here are my suggestions: In the aircraft's directory (meaning directory such as $FG_ROOT/data/Aircraft/MD11/), there should be a directory named textures where all the textures for that aircraft reside. This should allow the aircraft's home directroy to stay organized as more liveries are added. This directory should be the location in which all textures are located unless the developers specify a different location (using Erik's code). For the engines, placing them in a central location will not only allow us to reuse the engine dynamic file, but it will enable us to reuse the 3D models and animations as well. This is great since some aircrafts, namely: different type of airliners, share the same types of engine. Time can be saved as the developers won't have to worry about anything regarding the engines except their locations. It will also save the modellers from creating duplicating copies of the same 3D model (and I don't mean copy and paste here). Since some aircrafts do not share engines with other aircrafts, or due to situations where the default engines in the central directory do not satisfy the needs of a particular project, the developers may want to create their own engine model and dynamic file. Therefore, the developers should have the final say as to where the engine files are located. The solution should be that the central directory is a default location in which FlightGear looks for engine files, unless the developers provides an alternate directory. An alternate solution would be the opposite: FlightGear will look at the central location if no matching engine specifications is found in the Engine folder within the aircraft's home directory. Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] AI Aircraft Models
Hi Folks, Following up on Curt's question about the aircraft directory layout, I would like to bring up a slightly different but related issue, that of aircraft models for use in AI traffic. Over the past summer, we've had to deal with many inconsistencies that were related to the AI traffic manager subsystem using aircraft models that were not included in the release version of the base package. While given the experimental status of the traffic manager at the time, we reached an acceptable solution of not using traffic based on aircraft that are not in the base package, in the future, this is undesirable. Another thing I noticed is that when the AIModel subsystem loads multiple copies of an aircraft, separate copies of each model are loaded each time, instead of referencing to the already loaded copy in the ssg scene graph. Having multiple copies of a polygon heavy AI aircraft led to severe memory problems on my system. For this and other reasons, I'm currently leaning toward favoring having a separate set of low-polygon count models for AI aircraft. The basic idea would then be to have a directory looking like this: data/Aircraft/AI/ which then has subdirectories for each aircraft. Like data/Aircraft/AI/777 and within each directory there are subdirectories for various liveries for example: data/Aircraft/AI/777/American data/Aircraft/AI/777/KLM data/Aircraft/AI/777/United etc etc Then inside each of these livery subdirectories there would reside not only the texture files for the respective aircraft, but also all the traffic files for this aircraft. The traffic manager would then scan this directory and automatically load all the traffic files it would find here. This way, adding or removing AI aircraft would automatically adjust the amount of traffic generated. Any thoughts or ideas? Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
Durk Talsma wrote: [...] For this and other reasons, I'm currently leaning toward favoring having a separate set of low-polygon count models for AI aircraft. The basic idea would then be to have a directory looking like this: data/Aircraft/AI/ I like the idea of having such a low-polygon repository of standard aircraft files, however they would certainly not only come in handy for the AI traffic part but also for other things like multiplayer functionality. So in that regard it might be worth to think about providing some sort of standard folder for all components that might actually make use of such (reduced) aircraft files - so that this isn't specific to the AI component itself ? which then has subdirectories for each aircraft. Like data/Aircraft/AI/777 and within each directory there are subdirectories for various liveries for example: data/Aircraft/AI/777/American data/Aircraft/AI/777/KLM data/Aircraft/AI/777/United etc etc I think it sounds like a good idea, however I wonder whether *liveries* shouldn't be placed in some central location, specific to certain (fitting) aircraft models - independent of the AI stuff ? So that they can be found in some sort of default location and would hence be optionally available for either: AI traffic and/or user traffic or even other/future components. Then inside each of these livery subdirectories there would reside not only the texture files for the respective aircraft, but also all the traffic files for this aircraft. At least for the multiplayer functionality within MS FS it is nowadays a pretty common feature to allow users to pick a custom livery for their (online) flight - that would be another scenario where AI files would/could be accessed by NON-AI components. So, even without having such or similar support within the near future I would still vote for a central repository that contains the aircraft specific stuff such as the textures/liveries models for LOWPOLY aircraft - after all it would be merely a matter of adding another subfolder... That way those FG components that actually use the LOWPOLY stuff wouldn't need to fool around with the AI sub-directory. The traffic manager would then scan this directory and automatically load all the traffic files it would find here. This way, adding or removing AI aircraft would automatically adjust the amount of traffic generated. Any thoughts or ideas? My first thought concerning the last paragraph would be that it would probably come in handy not to statically use _all_ traffic files that are available within the AI folder but rather make this dependent on some simple property that allows adjustment of the AI traffic complexity and some other parameters. That way, one could have various traffic files without actually having to use them, one wouldn't even need to directly manipulate the files in that folder to control some basic options. Talking about low-polygon aircraft, it sounds like additional work for the aircraft maintainers to really maintain different models for the same aircraft types ? So I wonder what would be involved in artificially reducing the polygon count of an abitrary model at load/processing time, e.g. by using only a certain percentage of the 3D data and ignoring the rest ? If that logic isn't too simple one could still refer to the same (complex) polygon model but only use a subset of the data to render an accordingly reduced model ? - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
