Re: [Flightgear-devel] Model animation documentation update
[EMAIL PROTECTED] wrote: I downloaded Blender 2.30, but this version has no ac3d file support. It seems that ac3d file support is still a missing feature in Blender and on the Todo list. Do you know any other free 3d editors that can read ac3d files? Blender 2.30 is ok for ac3d files. read : http://www.seedwiki.com/page.cfm?doc=ModelerAndSceneryBuilderDocumentationwikiid=2418wpid=0 -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest stupid helicopter trick
Hi, one think/thing added: Maik Justus schrieb: Hi, I try to explain my confusion: Lets think the heli is in forward flying and the rotor is spinning counter clock wise (seen from top, like the bo 105). Relative to air the rotor blades at the left side are slower and on the right side are faster. So they produce more force at the right side and less on the left side. Because of the gyroscopic effect the result is 90° shifted, so the blade will be up in front and down in back (flapping). The heli will rise the nose if you don't correct the cyclic input. (Up to this point I think I understood it.) m is the mass of one pointlike blade r is the radius to this mass (which vary with flapping and teetering) r0 the radius without flapping and teetering w (omega) the rotational speed of the blade a flapping angle The angular momentum ( m r w) is conservated. If the blade flapps up, r will be changed (r=r0 cos a, if we assume the hinge in the rotor center), so w has to be increased (that is what we know as teetering). If we assume a positive cone angle of the rotor (and this is the normal case) than the rotorblade will be faster in front position than in back position. And will produce more force in front position than in back position. And with thy gyro we have a roll moment, but to the right and not to the left as our helicopter has in real. It is very easy to run into more confusion. Lets think of a rotor system like the Jet Ranger has. The rotor can flap free around the center, so the only force to the mast is the centripetal force. The centripetal force is m r w w. Without teetering this force is m r0 w w cos a. If the rotor is tilted to the front and has a positive cone angle the blade will produce higher centripetal force in front position than in back position. A effective force to the rotormast pointing forward results. The CG is lower than the rotor head, so this result in a forward roll moment. ok. But what is the result of the teetering? If m r w is constant, than w must be w0/(cos a) (remember: r=r0*cos a). And the centripetal force is then m r0 w0 w0/(cos a), which means, that a forward tiltet rotor will produce an effective force pointing backward, which is obviously nonsense. In this calculation I forgot to split the centripetal force into a component along the blade (the only direction a force can attac) (which is F *(cos a) ) and at the flapping hinge this force has to be splitted into a component along the mast (the lift) and one perpendicular to it (which makes a rotational moment). the one perpendicular has a (cos a) factor, the parallel one a (sin a) factor. This results: r0 w0 w0 (cos a) for the component perpendicular to the mast and r0 w0 w0 (sin a) parallel to the mast. So teetering has no effect to the forces (in first order). Somehow I lost one (cos a) term in my older calculations which rides me into confusion, but now it seems to be clear to me. But the translational roll moment has still the wrong sign... Does someon know, if the Bell 206 (or the r 22) has this roll moment and how large is it? My only idea to solve this: The teetering hinge at every real heli is not in the rotor center. It is out of center. Every teetering angle produces a force to the blade which wants to reduce the teetering angle, so the change of w will be smaller (the missing angular momentum goes to the rotor mast). But if you look in detail into this, you find, that this is a osscillator, which is nearly in resonance. One solution is to think of a big damping constant, but the teeter hinge at model helicopters needs no damping. Maybe the damping can be explained aerodynamically? I don't know. Or is there a big error in this calculations? Confused, Maik a little bit eased, Maik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest stupid helicopter trick
Andy Ross [EMAIL PROTECTED] wrote: Maik Justus wrote: By the way: With this changes the heli is not anylonger parallel to ground (while hovering). It is tiltet to the left to compensate the tail rotor force. That sounds wrong to me. The *rotor* should be tilted, but the airframe is experiencing no net force and should be hanging straight down from the shaft. No, because the BO105 - contrary to the 'usual' Bell's for example - has a rigid rotor. Please have a look here: http://www.b-domke.de/AviationImages/Rotorhead.html#Eurocopter Or did I misunderstand your objection ? 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] TaxiDraw-0.0.5 available.
On 25 Nov 2003, at 23:56, Jon Stockill wrote: On Tue, 25 Nov 2003, David Luff wrote: Eliminated the bloody annoying flickering. I was going to ask if you could do anything about this - not good on the eyes - particularly when zoomed in, and a large percentage of the screen is flashing. In case anyone cares, TaxiDraw works for me using the CVS version of WxMac, on Panther (10.3) - I've had to hack a few things about, will clean them up and submit patches at some point. Thing is, I was only doing this to add Taxiways for EGPH (Edinburgh) and ... and ... it's already got them! So I'll have to find something else to do :-) One thing I'd really like is the ability to place some generic, rectangular buildings objects down, on the airports. Obviously this outputs to a totally different place to the runways.dat file so is there any chance of eventually rolling TaxiDraw into FGSD? (I assume the hard / complex work is the canvas and positioning code, so moving from wx to FLTK would be tedious but not especially difficult) The reason I mention is, I was about to add a couple of GUI features to taxidraw (like a list box to select airports by name instead of ICAO code), but I don't really want to invest brain-space learning WxWindows if I can avoid it. Not that I'm a fan of FLTK either ... Any ideas how this might develop in the future? HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On Wed, 26 Nov 2003, James Turner wrote: already got them! So I'll have to find something else to do :-) Ahaa, nice to have someone else working on additions for this side of the pond too. Just to avoid any overlap - the first batch I'll be working on are all the RAF airfields. If anyone has any requests I'd be happy to add them or move them up the list. One thing I've found *very* useful is the aerial photos on multimap - paste a load together to get full coverage of the airfield concerned, and then scale (to either 1px/ft, or 10px/ft, depending on the size of the airfield) - you can then use the measuring tool in the graphics app to get rough dimensions for taxiway segments, which speeds up the process considerably. One thing I'd really like is the ability to place some generic, rectangular buildings objects down, on the airports. Obviously this Agreed - even if it just output a bunch of points that could be added directly to the stg files. While we're coming up with ideas to keep David busy - Is there any way to set the priority of the taxiway segments, where several meet it'd be nice to be able to change the stacking - I'm guessing that genapts just processes them in order, so being able to bump a section to the end of the list should cause it to be drawn on top. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
James Turner wrote: One thing I'd really like is the ability to place some generic, rectangular buildings objects down, on the airports. Obviously this outputs to a totally different place to the runways.dat file so is there any chance of eventually rolling TaxiDraw into FGSD? (I assume the hard / complex work is the canvas and positioning code, so moving from wx to FLTK would be tedious but not especially difficult) The reason I mention is, I was about to add a couple of GUI features to taxidraw (like a list box to select airports by name instead of ICAO code), but I don't really want to invest brain-space learning WxWindows if I can avoid it. Not that I'm a fan of FLTK either ... Any ideas how this might develop in the future? This is something I would like to do, as time permit, or someone else do. It shouldn't be very difficult to draw OpenGL rectangles over the existing framework. It would benefit of having map or chart as an underlying overlay and placement aid. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On 26 Nov 2003, at 10:53, Frederic BOUVIER wrote: The reason I mention is, I was about to add a couple of GUI features to taxidraw (like a list box to select airports by name instead of ICAO code), but I don't really want to invest brain-space learning WxWindows if I can avoid it. Not that I'm a fan of FLTK either ... Any ideas how this might develop in the future? This is something I would like to do, as time permit, or someone else do. It shouldn't be very difficult to draw OpenGL rectangles over the existing framework. It would benefit of having map or chart as an underlying overlay and placement aid. Right, being able to include an aerial photo as Jon suggested, or a plan (as is available from the CAA, for major Uk airports), would obviously greatly ease taxi-way creation. I might see if i can get FGSD running on OS-X too, and then see how much work would be involved in moving some functionality around. HH James -- The lack of planning on your part does not constitute to an emergency on mine ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
I'll take the liberty of replying to you all at once... On 11/26/03 at 11:02 AM James Turner wrote: Right, being able to include an aerial photo as Jon suggested, or a plan (as is available from the CAA, for major Uk airports), would obviously greatly ease taxi-way creation. I've almost finished getting a 5 arc-second orange grid overlay working, which is the same as used on the CAA aerodrome charts available online (UK aip). I was also going to add functionality to call wget to get the Terrasever US aerial photos and use them as background - Terraserver terms of use specifically allows any use whatsoever of the images. I agree though that fgsd is ultimately the way forward in this area. Frederic BOUVIER wrote: This is something I would like to do, as time permit, or someone else do. It shouldn't be very difficult to draw OpenGL rectangles over the existing framework. It would benefit of having map or chart as an underlying overlay and placement aid. James Turner wrote: I might see if i can get FGSD running on OS-X too, and then see how much work would be involved in moving some functionality around. Yep, in the long run it would be useful to have the whole taxi-editing, scenery editing, and facilities editing all wrapped up in fgsd, which seems to be emerging as the de-facto, most sophisticated, FG scenery editor. In the short term its easier for me (and quicker to get the taxiway editing functionality going) to bang away at my own code, especially as a lot of it was already written in mfc ages ago, and porting to wxWindows turned out to be quite easy (I've got a generic undo/redo buffer already written in mfc to go in at some point), and some of the stuff I've learnt (such as how to eliminate the flicker) has been useful in some non-FlightGear wxWindows apps I'm also working on. Once FLTK 2.0 is released I'll have a good play with fgsd, in the meantime I'll try and code the functionality as generically as possible to make it easier for others to port if they want to. The only upside I can think of for the wxWindows version over an fgsd addition is that it doesn't need hardware openGL support to run smoothly, but realistically even most laptops should handle that these days. James Turner wrote something about the Mac It's great that you've got it going on the Mac - feel free to send me the patches, and there's plenty of other Scottish airfields!! and James Turner wrote: but I don't really want to invest brain-space learning WxWindows if I can avoid it. Not that I'm a fan of FLTK either ... How can you not be a fan of wxWindows? - the chap who started it lives in Edinburgh, and it uses 'colour' instead of 'color' ;-) On 11/26/03 at 10:45 AM Jon Stockill wrote: On Wed, 26 Nov 2003, James Turner wrote: One thing I'd really like is the ability to place some generic, rectangular buildings objects down, on the airports. Obviously this Agreed - even if it just output a bunch of points that could be added directly to the stg files. While we're coming up with ideas to keep David busy - Is there any way to set the priority of the taxiway segments, where several meet it'd be nice to be able to change the stacking - I'm guessing that genapts just processes them in order, so being able to bump a section to the end of the list should cause it to be drawn on top. It should be easy to output some points for the stg files, possibly with the correct format and with a placeholder for the name - I'll have a look at that. Up/down list - hmm, genapts rendering order had completely never occurred to me. I'll have a look at that - should be possible to have a pop-up list of taxiways, with the ability to move one up or down the order. Jon Stockill wrote: btw, I still needed to insert an extra space between the lat lon to keep genapts happy. Yes, you're right, I'll fix that in the next one. You could try replacing setw(10) with setw(11) in line 332 of airport.cpp - that should do the trick. And remember chaps, pressing 'w' will completely and silently overwrite your ICAO.dat file, so keep it backed up somewhere other than the working copy!!! (Putting the .dat file handling into the file open/save dialog should be easy - I'll have a look) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On 26 Nov 2003, at 11:44, David Luff wrote: I've almost finished getting a 5 arc-second orange grid overlay working, which is the same as used on the CAA aerodrome charts available online (UK aip). I was also going to add functionality to call wget to get the Terrasever US aerial photos and use them as background - Terraserver terms of use specifically allows any use whatsoever of the images. I agree though that fgsd is ultimately the way forward in this area. Sounds great on all counts :-) snip apps I'm also working on. Once FLTK 2.0 is released I'll have a good play with fgsd, in the meantime I'll try and code the functionality as generically as possible to make it easier for others to port if they want to. The only upside I can think of for the wxWindows version over an fgsd addition is that it doesn't need hardware openGL support to run smoothly, but realistically even most laptops should handle that these days. Yeah, personally I think we should be doing all our tools as plain GL / PUI with extensions, though using a real toolkit has advantages too, and it's pointless to waste time bickering about toolkits rather than actually getting useful tools written. So, I'll shutup :-) How can you not be a fan of wxWindows? - the chap who started it lives in Edinburgh, and it uses 'colour' instead of 'color' ;-) Because of the hideous macros for the event maps, for one thing. It's like a throwback to MFC. But, as I said, no futile toolkit bickering :-) And remember chaps, pressing 'w' will completely and silently overwrite your ICAO.dat file, so keep it backed up somewhere other than the working copy!!! (Putting the .dat file handling into the file open/save dialog should be easy - I'll have a look) This would resolve some of the Mac issues : the Mac version is running as a bundle, so it's CWD is '/' - my hacks are mainly changing paths so it can find runways.dat Being able to use the gzipped version would be nice, if the code isn't excessive. Maybe a simgear dependancy is they way to go, since at least some of the parsing code must already be duplicated HH James -- We are all in the gutter, but some of us are looking at the stars. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway progress
On 11/25/03 at 6:22 PM Jon Stockill wrote: With mouse control added, and the ability to directly edit the taxiway features I thought I'd have a try at something a bit more complex. I think this proves that Taxidraw is an extremely useful bit of software: http://flightgear.stockill.org.uk/scenery/ Now that looks *extremely* impressive. How many RAF fields are there in the FlightGear database as a rough guess? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On 11/26/03 at 10:08 AM James Turner wrote: One thing I'd really like is the ability to place some generic, rectangular buildings objects down, on the airports. Obviously this outputs to a totally different place to the runways.dat file so is there any chance of eventually rolling TaxiDraw into FGSD? (I assume the hard / complex work is the canvas and positioning code, so moving from wx to FLTK would be tedious but not especially difficult) A lot of it is (or should be) decoupled between screen and physical using ViewPointToXY, ViewPointToLatLon, LatLonToViewPoint, XYToViewPoint, XYToLatLon and LatLonToXY, where viewpoint is a screen pixel coordinate, XY is an orthogonal meters based local coordinate system (at the moment the simple ATC projection is used to convert to and from lat/lon, but any 'proper' projection could be used instead) and LatLon is of course in WGS84. By re-implementing those functions, a lot of the trouble would be over, and a lot of the rest would be a FLTK / wxWindows cut 'n paste the differences job. Maybe! The reason I mention is, I was about to add a couple of GUI features to taxidraw (like a list box to select airports by name instead of ICAO code), but I don't really want to invest brain-space learning WxWindows if I can avoid it. Not that I'm a fan of FLTK either ... Any ideas how this might develop in the future? HH James Well I'm not going to ditch it, but I agree that it would be logical to see it in fgsd as well. Philosophically, I think that fgsd is eventually going to end up becoming a complex, sophisticated tool, and I'll definately end up working either on it or with it one day. However, I don't think that that necessarily precludes the existence of a simpler tool that does a subset of the tasks, possibly with it's own individual slant on some aspects. Practically, at the moment I find it easier to get the taxiway editing functionality 'out there' by hacking at my own code. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway progress
On Wed, 26 Nov 2003, David Luff wrote: Now that looks *extremely* impressive. How many RAF fields are there in the FlightGear database as a rough guess? Probably somewhere around 50 - I'll get a list together. All the dispersal areas, and the changes made over the years make them rather interesting (if time consuming) to work on. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On 11/26/03 at 1:08 PM Jon Stockill wrote: On Wed, 26 Nov 2003, James Turner wrote: Right, being able to include an aerial photo as Jon suggested, or a plan (as is available from the CAA, for major Uk airports), would obviously greatly ease taxi-way creation. Hmm, that sounds useful - where can I find these plans? I think they're now at http://www.ais.org.uk with (free) registration required. They've got (had, anyway) the official CAA aerodrome charts online for almost all UK civil airports. (I made an offline copy a couple of years ago and work from that). Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] website
website Hello, 1.the design of the website is really good now, but I think we need a new logo. I´m sure there are enough people with painting skills among us. Just post some ideas or pictures! 2. There is a picture gallery on the website, but lots of screenshots are very old. I think I know the reason: nobody looks after it because it´s not easy. I think everybody should be able to see who FlightGear looks like, what kind of effects, aircrafts, scenery or cockpits are there. These things are very important to get new FlightGear users. But nobody can´t see such things in the gallery, everybody has to install FlightGear first. I think the solution is a dynamic gallery. There are lots of open-source projects, I´ve even installed a couple of them on my lamp at home and they are very useful. Just imagine all the developers (or even users) could upload screenshots of new aircrafts, effects or scenery. http://gallery.sourceforge.net/ very cool picture gallery that generates thumbnails automatically, there are lots of settings like size, description, comments or counter, you can upload pictures over the browser and you can even allow other users to upload pictures too. The difficulty is that you need PHP, MySQL database, NetPBM or ImageMagic (to generate thumbnails). http://spgm.sourceforge.net Simple Picture Gallery Manager you have to make thumbnails and to upload pictures yourself, but it requires only PHP. Curt, can you install such things like PHP, MySQL etc on the webserver? I think http://flightgear.sourceforge.net has already PHP support, hasn´t it? All the best, Ilja ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] website
Ilja, I people occasionally want to send new screen shots, please do. I have a script that makes them very easy to add to the gallery page. I can't promise that every submission will be posted on the web page, but if you submit a picture that looks good, or shows something interesting, or shows off a new feature, then it would be hard to say no. Regards, Curt. [EMAIL PROTECTED] writes: website Hello, 1.the design of the website is really good now, but I think we need a new logo. I´m sure there are enough people with painting skills among us. Just post some ideas or pictures! 2. There is a picture gallery on the website, but lots of screenshots are very old. I think I know the reason: nobody looks after it because it´s not easy. I think everybody should be able to see who FlightGear looks like, what kind of effects, aircrafts, scenery or cockpits are there. These things are very important to get new FlightGear users. But nobody can´t see such things in the gallery, everybody has to install FlightGear first. I think the solution is a dynamic gallery. There are lots of open-source projects, I´ve even installed a couple of them on my lamp at home and they are very useful. Just imagine all the developers (or even users) could upload screenshots of new aircrafts, effects or scenery. http://gallery.sourceforge.net/ very cool picture gallery that generates thumbnails automatically, there are lots of settings like size, description, comments or counter, you can upload pictures over the browser and you can even allow other users to upload pictures too. The difficulty is that you need PHP, MySQL database, NetPBM or ImageMagic (to generate thumbnails). http://spgm.sourceforge.net Simple Picture Gallery Manager you have to make thumbnails and to upload pictures yourself, but it requires only PHP. Curt, can you install such things like PHP, MySQL etc on the webserver? I think http://flightgear.sourceforge.net has already PHP support, hasn´t it? All the best, Ilja ___ 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.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On Wed, Nov 26, 2003 at 01:08:40PM +, Jon Stockill wrote: On Wed, 26 Nov 2003, James Turner wrote: Right, being able to include an aerial photo as Jon suggested, or a plan (as is available from the CAA, for major Uk airports), would obviously greatly ease taxi-way creation. Hmm, that sounds useful - where can I find these plans? If you can't find them online, try your local airfield/flying club. They'll probably allow you to photocopy their AIP for the airfield(s) you're interested in. All the best, Matt ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Nasal integration docs
* Andy Ross -- Wednesday 26 November 2003 05:30:
http://www.plausible.org/andy/fg-nasal.html
This and your examples (mouse handling, etc.) have totally
won me over! I've already written my first nasal script
$FG_ROOT/Nasal/bo105.nas
print(Loading bo105.nas);
rearpos = /controls/doors/rear;
rearstep = /controls/doors/rearstep;
setprop(rearstep, 0);
movedoor = func {
pos = getprop(rearpos);
step = getprop(rearstep);
#print(movedoor : , pos, : , step);
if (pos + step = 0 and pos + step = 1) {
setprop(rearpos, pos + step);
settimer(movedoor, 0.05);
} else {
if (step 0) {
setprop(rearpos, 0);
} elsif (step 0) {
setprop(rearpos, 1);
}
setprop(rearstep, 0);
}
}
togglereardoor = func {
pos = getprop(rearpos);
step = getprop(rearstep);
#print(togglereardoor : , pos, : , step);
if (pos == 0 or step 0) {
setprop(rearstep, 0.01);
} elsif (pos == 1 or step 0) {
setprop(rearstep, -0.01);
}
settimer(movedoor, 0.05);
}
print(Finished loading bo105.nas);
With the following added to $FG_ROOT/Aircraft/bo105/bo105-yasim-set.xml ...
input
keyboard
key n=67
nameC/name
descopen/close rear door/desc
binding n=0
commandnasal/command
scriptbo105.togglereardoor()/script
/binding
/key
/keyboard
/input
... I can now open close the back door with Shfit-C. :-)
m.
PS: I love Nasal.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Grass Runway Textures
On Tue, Nov 25, 2003 at 02:26:46PM -0600, Curtis L. Olson wrote: I believe they are currently directional. If someone came up with a really nice texture (or set of textures) we could probably do some work on the terragear end to optimize the runway creation code for that texture approach. I'll have a go, but I can't promise they'll be really nice ;-) All the best, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway progress
On 11/25/03 at 6:22 PM Jon Stockill wrote: With mouse control added, and the ability to directly edit the taxiway features I thought I'd have a try at something a bit more complex. I think this proves that Taxidraw is an extremely useful bit of software: http://flightgear.stockill.org.uk/scenery/ That last field is very impressive. I did notice that there are no curved corners in the taxiways like their are in the real thing. Is this on purpose? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Aw: Re: [Flightgear-devel] website
The FlightGear logo on the top of the website. Ilja On Wed, 26 Nov 2003 15:38:58 +0100 (CET) [EMAIL PROTECTED] wrote: Hello, 1.the design of the website is really good now, but I think we need a new logo. I?m sure there are enough people with painting skills among us. Just post some ideas or pictures! A new logo? Jon ___ 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
Aw: Re: [Flightgear-devel] website
Just all the best aircrafts, but I haven´t got a powerful machine. Curtis L. Olson [EMAIL PROTECTED] wrote: Ilja, I people occasionally want to send new screen shots, please do. I have a script that makes them very easy to add to the gallery page. I can't promise that every submission will be posted on the web page, but if you submit a picture that looks good, or shows something interesting, or shows off a new feature, then it would be hard to say no. Regards, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Aw: Re: [Flightgear-devel] website
On Wed, 26 Nov 2003 16:22:28 +0100 (CET) [EMAIL PROTECTED] wrote: The FlightGear logo on the top of the website. Yes, I know. I am familiar with it: I made it. :-) What don't you like about it? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest stupid helicopter trick
Martin Spott wrote: No, because the BO105 - contrary to the 'usual' Bell's for example - has a rigid rotor. Please have a look here: http://www.b-domke.de/AviationImages/Rotorhead.html#Eurocopter Well, that explains my confusion... I guess this just shows my helicopter ignorance. My belief had always been that such a configuration was impossible due to the bending moments along the blade, and that the articulated rotor was a necessary invention to make the idea of a helicopter work. Must have been propaganda. :) But the physics behind that meme is sound: there *are* very high bending moments on a rigid blade. To first approximation you're holding the whole aircraft up by the tips of the blades (the inner parts of the blade produce some lift, but not much; the outer portions are where all the force is felt). What is the rationale behind the decision to make them rigid on the BO105? The only advantage I can see is that you save a few axles and bearings, which are moving parts that can wear out. But you pay for it in extra stress cycles on the blade, so I can't see how this is a win. The articulation joints really aren't very complicated, especially compared with the cyclic control system which you have to have anyway... Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest stupid helicopter trick
Hi Andy, Andy Ross wrote: What is the rationale behind the decision to make them rigid on the BO105? The only advantage I can see is that you save a few axles and bearings, which are moving parts that can wear out. But you pay for it in extra stress cycles on the blade, so I can't see how this is a win. The articulation joints really aren't very complicated, especially compared with the cyclic control system which you have to have anyway... Andy It's the flight behavior. This rotor system works in a range from -5 to +5 g (maybe more on the positive side) (i.e. the bell jet ranger rotor works only at positive g ) and has a extremely fast reaction on control input. You can do acrobatics with the bo105 and it is much easier to fly than many other helicopters. Maik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Aw: Re: [Flightgear-devel] website
Jon S Berndt [EMAIL PROTECTED] said: On Wed, 26 Nov 2003 16:22:28 +0100 (CET) [EMAIL PROTECTED] wrote: The FlightGear logo on the top of the website. Yes, I know. I am familiar with it: I made it. :-) What don't you like about it? Maybe some folks aren't aware of the consolidated form of the logo with just the text and the flags that I remember seeing on the cafepress site. http://www.cafeshops.com/fgfs_gear.1609111 The current page head looks quite nice to me. If someone does a better one that's cool, but I certainly wouldn't agree we need a new logo. On the other hand, we _do_ need more scenery models and building textures for those with artistic talent. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway progress
On Wed, 26 Nov 2003, Gene Buckle wrote: That last field is very impressive. I did notice that there are no curved corners in the taxiways like their are in the real thing. Is this on purpose? It's because I've not got around to adding them yet - I'm just too impatient and wanted to see what it looked like - I'll be adding a few more segments to the curves, and filling in the corner sections. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On Wed, 26 Nov 2003 [EMAIL PROTECTED] wrote: If you can't find them online, try your local airfield/flying club. They'll probably allow you to photocopy their AIP for the airfield(s) you're interested in. David was right - they're available as PDFs on www.ais.org.uk - the site navigation is truly abysmal (it's all javascript) but I found what I was after eventually (I sholdn't have to read the source to find the relevant urls though). -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] the horizon
Since I enjoy seeing sunset twice, I performed an experiment in FlightGear: watching the sun set at the end of the runway, then taking off and climbing to bring the sun back above the horizon to see it set again. The problem is that the sun came above the horizon too quickly, and stayed above the horizon far too long from high altitude (say, thirty thousand feet). It turns out since only visible scenery is rendered, the scenery behind the visibility fog is simply not there to get in the way of the sun; so until the sun passes under the (possibly quite small) patch of visible ground below you, it will remain up well into the night. I am interested in incorporating a better horizon into FlightGear but am not sure how to approach the problem. I imagine a dynamic flat surface beneath the landscape that expands outwards to provide an intersection between one's line of sight and the curve of the earth: _ _/ (aircraft) / \ / \ / \ (line of sight to horizon) / === \ / ... ... \ ... ... - (a simple flat surface . . thrown in as a horizon) In this rough diagram, the equals signs represent the surface that is actually being rendered given the aircraft's height and the prevailing fvisibility; but as we see, it covers only part of what would be the visible earth beneath the plane. So I am suggesting the addition of the dashed line, which forms the rough disc where the pilot's line of sight would intersect the globe were we rendering it. This surface would need no texture, and indeed would not be itself visible, but would properly obscure the sun so that sunset for 747 pilots at 30,000 feet occurs just when it should. I am not proposing that the horizon disk account for any surface features - no need at this point to determine whether the Himalayas lie in front of the distant sunset and require the horizon-disc to be extended to account for them. But others might object to modeling visibility in such a way as to make surface features disappear from above; should an F-16 pilot at 50,000 feet really find himself looking down on a tiny patch of ground surrounded by a white featureless soup? It is possible that instead of my horizon-disc idea, we simply need a low-resolution version of our landscape that can be extended all the way to the earth's limb as viewed from a few miles up, providing F-16 pilots and other high flyers with a more realistic view of the earth from on high. -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
Jon Stockill writes: On Wed, 26 Nov 2003 [EMAIL PROTECTED] wrote: If you can't find them online, try your local airfield/flying club. They'll probably allow you to photocopy their AIP for the airfield(s) you're interested in. David was right - they're available as PDFs on www.ais.org.uk - the site navigation is truly abysmal (it's all javascript) but I found what I was after eventually (I sholdn't have to read the source to find the relevant urls though). The truly sad thing is that it used to be a good example of clear, easy to navigate, plain html, and that they must have spent good money f*king it up. Apparently it stuffed their servers when they first switched from plain to script based as well. Such is life... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: the horizon
As I continue to ponder my horizon ideas, I am driven to ask: is the FlightGear visibility code perhaps too naive? In real life, if you are ten miles up looking down on landscape with fifteen-mile visibility, do you really only see a little five-mile-radius patch? (And: is this what the current visibility model does, or have I just pushed it too hard and misunderestimated its sophistication?) -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Taxidraw Request
Is there any chance that a centreline could be displayed on the taxiway segments? It'd make lining up very small square sections a lot easier, rather than having to check the properties every time (if this isn't possible for all the segments is it possible for just the selected one?) (Taxiway segments in EGXI - 260 and climbing) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Concorde
Hi guys, We've just had a really lucky day in Bristol today, as far as weather goes. There were some dark clouds in the West, I think we wouldn't have seen much of Concorde's last flight if it had been half an hour earlier or later! Anyway, I took some pictures of G-BOAF on its last flight, here they are: http://onepointfour.dyndns.org/concorde/ These are probably unique because I took them from a rather special place... I hope you enjoy the pictures, and that you don't suffer much knowing there's one technical marvel fewer in our skies from now on. Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: the horizon
If I can give my opinion, 1 mile visibility sometimes looks like 20 mile visibility when your only a mere 3000 ft up in the sky ... It's a really a difficult subject this -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brandon Craig Rhodes Sent: 26 November 2003 08:53 PM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Re: the horizon As I continue to ponder my horizon ideas, I am driven to ask: is the FlightGear visibility code perhaps too naive? In real life, if you are ten miles up looking down on landscape with fifteen-mile visibility, do you really only see a little five-mile-radius patch? (And: is this what the current visibility model does, or have I just pushed it too hard and misunderestimated its sophistication?) -- Brandon Craig Rhodes [EMAIL PROTECTED] http://rhodesmill.org/brandon ___ 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
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On Wednesday 26 November 2003 10:45, Jon Stockill wrote: On Wed, 26 Nov 2003, James Turner wrote: already got them! So I'll have to find something else to do :-) Ahaa, nice to have someone else working on additions for this side of the pond too. Just to avoid any overlap - the first batch I'll be working on are all the RAF airfields. If anyone has any requests I'd be happy to add them or move them up the list. One thing I've found *very* useful is the aerial photos on multimap - paste a load together to get full coverage of the airfield concerned, and then scale (to either 1px/ft, or 10px/ft, depending on the size of the airfield) - you can then use the measuring tool in the graphics app to get rough dimensions for taxiway segments, which speeds up the process considerably. One thing I'd really like is the ability to place some generic, rectangular buildings objects down, on the airports. Obviously this Agreed - even if it just output a bunch of points that could be added directly to the stg files. While we're coming up with ideas to keep David busy - Is there any way to set the priority of the taxiway segments, where several meet it'd be nice to be able to change the stacking - I'm guessing that genapts just processes them in order, so being able to bump a section to the end of the list should cause it to be drawn on top. -- Jon Stockill [EMAIL PROTECTED] You said If anyone has any requests I'd be happy to add them or move them up the list. :) Not an RAF field but I've noticed that London Stanstead (EGSS) appears to have been sunk about 50ft into the ground... LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Aw: Re: [Flightgear-devel] website
On Wednesday 26 November 2003 15:37, Jon S Berndt wrote: On Wed, 26 Nov 2003 16:22:28 +0100 (CET) [EMAIL PROTECTED] wrote: The FlightGear logo on the top of the website. Yes, I know. I am familiar with it: I made it. :-) What don't you like about it? Jon giggle Sorry;) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxidraw Request
On 11/26/03 at 7:32 PM Jon Stockill wrote: Is there any chance that a centreline could be displayed on the taxiway segments? It'd make lining up very small square sections a lot easier, rather than having to check the properties every time (if this isn't possible for all the segments is it possible for just the selected one?) (Taxiway segments in EGXI - 260 and climbing) www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0p5b-preAlpha-src.tar.gz Just the selected one. 'g' toggles the grid btw, and 'x' toggles the centerlines. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Time to Refactor (was Re: [Flightgear-devel] Re: Nasal integration docs)
Melchior FRANZ wrote: This and your examples (mouse handling, etc.) have totally won me over! I've already written my first nasal script I haven't had time to play with NASAL yet, but now that it's integrated and people seem to like it, it's probably time to start refactoring FlightGear a bit. Originally, I defined actions using XML mainly because we didn't have a scripting language, but ideally, we should share up the labour like this: XML = declarative NASAL = imperative i.e. if we want to say this is X, we use XML; if we want to say do Y, we use NASAL. A drop-down menu is declarative, but the actions associated with each menu item are imperative, and could be NASAL code snippits. The keymap is declarative, but the actions associated with each keystroke are imperative, and again, could be NASAL code snippits embedded in XML. If anyone wants to start on some analysis and make a few suggestions, or even rewrite some code, you have my blessing (as if you needed it). XML is a great language for serializing data structures, but it's a lousy syntax for writing code, and I've never liked using it that way. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Time to Refactor (was Re: Nasal integration docs)
* David Megginson -- Wednesday 26 November 2003 23:03: If anyone wants to start on some analysis and make a few suggestions, or even rewrite some code [...] Not exactly what you meant, but I've written a syntax definition file for vim that displays nasal scripts with colored syntax -- for easier editing: http://members.aon.at/mfranz/nasal.vim (See :help new-filetype in vim for how and where to install it.) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On Wed, 26 Nov 2003, Lee Elliott wrote: You said If anyone has any requests I'd be happy to add them or move them up the list. :) Not an RAF field but I've noticed that London Stanstead (EGSS) appears to have been sunk about 50ft into the ground... OK, I'll have a look and see what I can do to fix it. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Model animation documentation update
Frederic Bouvier wrote: Blender 2.30 is ok for ac3d files. read : http://www.seedwiki.com/page.cfm?doc=ModelerAndSceneryBuilderDocumentation; wikiid=2418wpid=0 -Fred Thank you, those scripts work great. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
Lee Elliott worte: You said If anyone has any requests I'd be happy to add them or move them up the list. :) Not an RAF field but I've noticed that London Stanstead (EGSS) appears to have been sunk about 50ft into the ground... The same happened with EDGM. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Time to Refactor (was Re: Nasal integration docs)
* David Megginson -- Wednesday 26 November 2003 23:34: Great. Let me know when you have time to port it from vim to an editor. The other editor on my system that is capable of syntax coloring, is kate. But I rarely use it, so I won't bother. $ which emacs $ which vi /usr/bin/vi m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Time to Refactor (was Re: Nasal integration docs)
David Megginson wrote: Great. Let me know when you have time to port it from vim to an editor. :) There's already a nasal-mode.el, actually. It's attached; it's previously been hidden in the source tarball on the nasal project website. It mostly works. I did it by taking a chainsaw to awk-mode with a blindfold on, and trying to avoid changing the stuff that confused me. Elisp just isn't my thing. :) Andy ;; nasal-mode.el ;; ;; A major mode for writing Nasal code. ;; Copyright (C) 2003 Andrew Ross ;; ;; Based very closely on awk-mode.el as shipped with GNU Emacs 21.2 ;; Copyright (C) 1988,94,96,2000 Free Software Foundation, Inc. ;; ;; It should be sufficient to drop this into your Emacs site-lisp ;; directory (/usr/share/emacs/site-lisp on most linux distributions) ;; and add a line: ;; ;; (require 'nasal-mode) ;; ;; ...to your .emacs file. All files with a .nas extension should ;; then be associated with nasal mode automatically. I am *not* an ;; elisp hacker, though, so YMMV. ;; (defvar nasal-mode-syntax-table nil Syntax table in use in Nasal-mode buffers.) (if nasal-mode-syntax-table () (setq nasal-mode-syntax-table (make-syntax-table)) ; Operator characters are punctuation (modify-syntax-entry ?! . nasal-mode-syntax-table) (modify-syntax-entry ?* . nasal-mode-syntax-table) (modify-syntax-entry ?+ . nasal-mode-syntax-table) (modify-syntax-entry ?- . nasal-mode-syntax-table) (modify-syntax-entry ?/ . nasal-mode-syntax-table) (modify-syntax-entry ?~ . nasal-mode-syntax-table) (modify-syntax-entry ?: . nasal-mode-syntax-table) (modify-syntax-entry ?. . nasal-mode-syntax-table) (modify-syntax-entry ?, . nasal-mode-syntax-table) (modify-syntax-entry ?\; . nasal-mode-syntax-table) (modify-syntax-entry ?= . nasal-mode-syntax-table) (modify-syntax-entry ? . nasal-mode-syntax-table) (modify-syntax-entry ? . nasal-mode-syntax-table) ; Underscores are allowed as symbol constituent (modify-syntax-entry ?_ _ nasal-mode-syntax-table) ; Backslash escapes; pound sign starts comments that newlines end. (modify-syntax-entry ?\\ \\ nasal-mode-syntax-table) (modify-syntax-entry ?\# nasal-mode-syntax-table) (modify-syntax-entry ?\n nasal-mode-syntax-table) ; Square brackets act as parenthesis (modify-syntax-entry ?\[ (] nasal-mode-syntax-table) (modify-syntax-entry ?] ) nasal-mode-syntax-table)) (defconst nasal-font-lock-keywords (eval-when-compile (list (cons (regexp-opt '(parents me arg) 'words) 'font-lock-variable-name-face) (regexp-opt '(and or nil if elsif else for foreach while return break continue func) 'words) (list (regexp-opt '(size keys append pop int streq substr contains typeof) 'words) 1 'font-lock-builtin-face) )) Nasal-specific syntax to be hilighted.) (define-derived-mode nasal-mode c-mode Nasal Major mode for editing Nasal code. This is a C mode variant customized for Nasal's syntax. It shares most of C mode's features. Turning on Nasal mode runs `nasal-mode-hook'. (set (make-local-variable 'paragraph-start) (concat $\\| page-delimiter)) (set (make-local-variable 'paragraph-separate) paragraph-start) (set (make-local-variable 'comment-start) # ) (set (make-local-variable 'comment-end) ) (set (make-local-variable 'comment-start-skip) #+ *) (setq font-lock-defaults '(nasal-font-lock-keywords nil nil ((?_ . w) (provide 'nasal-mode) ;; Set us up to load by default for .nas files (setq auto-mode-alist (append '((\\.nas$ . nasal-mode)) auto-mode-alist)) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] website
Curtis L. Olson wrote: Ilja, I people occasionally want to send new screen shots, please do. I have a script that makes them very easy to add to the gallery page. I can't promise that every submission will be posted on the web page, but if you submit a picture that looks good, or shows something interesting, or shows off a new feature, then it would be hard to say no. Regards, Curt. I would also like to send some screenshots. How large should the screenshots be? PNG or JPG? And should i send the screenshot to you directly or to the flightgear devel mailinglist? Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Time to Refactor (was Re: [Flightgear-devel] Re: Nasal integration docs)
David Megginson wrote: Originally, I defined actions using XML mainly because we didn't have a scripting language, but ideally, we should share up the labour like this: XML = declarative NASAL = imperative Completely agree. Although it should be pointed out that there's significant gray area between the two extremes. Some of the existing commands (like property-adjust, with its handy wrap and clamp options) are simpler than the equivalent Nasal code for typical usages. Likewise, sometimes declaring your data in Nasal can save a lot of work interpreting that data on the C++ side. The mouse.nas sample was a good example of this. The whole idea of mouse mode cooked down to a literal object definition, where the methods were handlers for each event type. And the list of modes was simply a literal list dropped right there in the file. (Again, there's no point in replacing the mouse code, but if we were doing it from scratch...) But here's a question on a related subject. How do we handle declaration of Nasal code? The ability to write inline handlers is great, but limited to small functions. The ability to drop module files into the Nasal directory is great too, for globally useful code. But sometimes you have non-trivial code that is nonetheless context-specific. The obvious example (as Melchior pointed out to me this morning) is per-aircraft scripts. We don't to have to drop a c172.nas file into the global namespace if we're flying a bo105. My answer to this issue this morning was this: I'm thinking about a property-space configuration, where you could do something like: nasal import module-namebo105/module-name source-filebo105.nas/source-file !-- Either a file -- !-- Or inline source code: -- script[CDATA[ ...nasal source code... ]]/script /import /nasal And the Nasal subsystem would then step through all the /nasal/import entries it found in the property tree and load the appropriate modules at initialization. But unfortunately that doesn't work, because multiple definitions of the same property (/nasal/import, this case) from different files overwrite each other. I had been under the impression that they defined new indices (/nasal/import[1], etc...), but that only works from the same file. The requirement is basically that arbitrary PropertyList XML files be able to define Nasal code that will be found by the FGNasalSys object at initialization. I can see a few ways to do this, all ugly to differing degrees: + Hack at the SimGear property parser to understand the FlightGear (!) nasal subsystem and invoke the (Nasal) parser at (XML) parse time. No. :) + Hack at the property parser to support the add index behavior across files. Less ugly, but this might (probably will) break existing usage that expects to override the global property instead. + Write initialization code to walk through the entire property tree looking for nasal-import nodes. This isn't so bad to implement, and is easy to understand, but walking the tree just seems icky. It's also a mild encapsulation violation, since sub-trees might want control over their own nodes' interpretation. + Use a /nasal/unique-name convention instead. Then the FGNasalSys::init() method simply iterates over all the children of /nasal, instead of all the indices of /nasal/import. The only trick here is coming up with a truly unique name, which is trivial for the case of aircraft definitions (just use the aircraft name). This is probably cleanest. But it does have the disadvantage that only property files at the root of the property tree can define nasal code. The tree walker mechanism above works anywhere. Anyway, I thought I'd throw that out to the list before I start trying to code something. There just doesn't seem to be an obvious Right Thing for this problem. For the record, neither of the two latter solutions will be hard to implement. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] simgear SGSocket returning -1
Hi, I am trying to recieve a message using SGSocket::read. SGSocket::read returns zero bytes read until about the time I am expecting the first message to be recieved. From here on SGSocket::read returns that -1 bytes have been read from the socket. I have looked around (simgear docs, plib) and I cant find out what the -1 is supposed to indicate. Does anyone know? Seamus ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FG logo Slovenian flag
I was just thinking (actually would be proud:)) if someone could add our Slovenian flag to the FlightGear logo (Slovenia terrain in FG is becoming more and more closer to the RL and I am planning to do some extensive airport fixes to match the real ones as well). I also modeled the J-22 Orao, which was a Yugoslavian fighter though, but Slovenia was meant to have them too if Yugoslavia wouldn't have fallen apart first. So many connections between Slovenia and FG... hence, I'm from Slovenia! :) Here's a simple flag IMO big enough for the logo: http://en.wikipedia.org/upload/9/96/Slovenia_flag_medium.png - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear SGSocket returning -1
On Wed, 26 Nov 2003 16:59:53 -0700 Seamus Thomas Carroll [EMAIL PROTECTED] wrote: Hi, I am trying to recieve a message using SGSocket::read. SGSocket::read returns zero bytes read until about the time I am expecting the first message to be recieved. From here on SGSocket::read returns that -1 bytes have been read from the socket. I have looked around (simgear docs, plib) and I cant find out what the -1 is supposed to indicate. Does anyone know? On unix -1 indicates an error. The actual error code is in the external variable errno. Call strerror(errno) to convert errno to a string. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Time to Refactor (was Re: Nasal integration docs)
On Thu, 27 Nov 2003 10:24 am, [EMAIL PROTECTED] wrote: Message: 7 Date: Wed, 26 Nov 2003 23:46:18 +0100 From: Melchior FRANZ [EMAIL PROTECTED] Subject: [Flightgear-devel] Re: Time to Refactor (was Re: Nasal integration docs) The other editor on my system that is capable of syntax coloring, is kate. But I rarely use it, so I won't bother. You know, I've only just started using kate due to needing to edit xml files for FlightGear. The more I use it the more I'm quite impressed with it. Add the plugins, the regular expression editing, etc, it's pretty powerful. Nick ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG logo Slovenian flag
Matevz Jekovec wrote: I was just thinking (actually would be proud:)) if someone could add our Slovenian flag to the FlightGear logo I, for one, think it would be immensely cool if the flag bar grew over time. If any revisions are going to be done to the list, though, it should be pointed out that there's no maple leaf on the existing banner. Don't tell David. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear SGSocket returning -1
I output the error and I am getting: Transport endpoint is not connected The strange part is if I put '\n' at the end of the message and read with 'readline' the message is successfully recieved. Is this a problem with 'read'? Seamus On Thu, 27 Nov 2003, Bernie Bright wrote: On Wed, 26 Nov 2003 16:59:53 -0700 Seamus Thomas Carroll [EMAIL PROTECTED] wrote: Hi, I am trying to recieve a message using SGSocket::read. SGSocket::read returns zero bytes read until about the time I am expecting the first message to be recieved. From here on SGSocket::read returns that -1 bytes have been read from the socket. I have looked around (simgear docs, plib) and I cant find out what the -1 is supposed to indicate. Does anyone know? On unix -1 indicates an error. The actual error code is in the external variable errno. Call strerror(errno) to convert errno to a string. Bernie ___ 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
Re: [Flightgear-devel] FG logo Slovenian flag
Andy Ross writes: I, for one, think it would be immensely cool if the flag bar grew over time. If any revisions are going to be done to the list, though, it should be pointed out that there's no maple leaf on the existing banner. Don't tell David. I told Jon when he made the logo that if he put the flags on there, he'd have to be ready to add new ones any time it was requested. Here's an idea ... now that FlightGear is deathly quiet, I can't tell if FlightGear is doing anything when it is starting up or if my machine has hung. Maybe we could make a progress bar out of the flags of all the countries of people that have contributed to FlightGear. (?) It would take some coding, but it would be a neat effect. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG logo Slovenian flag
On Thursday 27 November 2003 01:25, Curtis L. Olson wrote: Andy Ross writes: I, for one, think it would be immensely cool if the flag bar grew over time. If any revisions are going to be done to the list, though, it should be pointed out that there's no maple leaf on the existing banner. Don't tell David. I told Jon when he made the logo that if he put the flags on there, he'd have to be ready to add new ones any time it was requested. Here's an idea ... now that FlightGear is deathly quiet, I can't tell if FlightGear is doing anything when it is starting up or if my machine has hung. Maybe we could make a progress bar out of the flags of all the countries of people that have contributed to FlightGear. (?) It would take some coding, but it would be a neat effect. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http:// www.flightgear.org Is there anyway to turn the console output back on? I've learnt quite a bit from looking at it and it's also helped me sort out a few problems. I understand the desire to make it quieter but I'd like it to be optional. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG logo Slovenian flag
On Thu, 27 Nov 2003 03:43:59 + Lee Elliott [EMAIL PROTECTED] wrote: Is there anyway to turn the console output back on? I've learnt quite a bit from looking at it and it's also helped me sort out a few problems. I understand the desire to make it quieter but I'd like it to be optional. --log-level=info Available levels are alert, warn, info, debug and bulk. alert is the new default. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear SGSocket returning -1
On Wed, 26 Nov 2003 18:04:50 -0700 Seamus Thomas Carroll [EMAIL PROTECTED] wrote: I output the error and I am getting: Transport endpoint is not connected From man recv ENOTCONN The socket is associated with a connection-oriented protocol and has not been connected (see connect(2) and accept(2)). If its the server side that is failing then accept() wasn't called or you are trying to read from the master socket. But see below... The strange part is if I put '\n' at the end of the message and read with 'readline' the message is successfully recieved. Is this a problem with 'read'? SGSocket::readline() and SGSocket::read() do act differently. For a server, readline() correctly handles the accept and reads from the new socket. read() also handles the accept but reads from the master socket. I'm not sure if this is intentional or if its a bug. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: the horizon
This really doesn't seem like such a difficult subject to me.
If one were to use a crude approximation of a flat plane drawn out to
intersect the ray from the eye to the sun, it would work, but...
If you want to be really clever, use a spherical or spheroidal
approximation to determine where the ray (vector) from the sun to the
eye intersects the earth (if it intersects). At this point, all you
really have to do is detect whether the ray from a few key points of the
sun (bottom, top, center) to the eye intersect the arc of the Earth.
Similarly, you can probably just use the spheroidal formulae's (which
I've noticed a bit of lately) calculations to do a possible trick. If
you calculate the tangent line from the sun's center to the Earth's
limbs, the absolute angle between either of these tangents (they'll be
equal) and the line between the centers of the earth and the sun will
represent the largest possible angle which the sun cannot be seen by
anything (since an angle smaller than this critical angle is behind the
earth). Obviously, if the eye is somewhere directly between the earth
and the sun, this calculation needs not be done. I have a nice little
picture with the diagram of what I'm referring to, but I don't know if
an attachment will work.
If it does, it's just a gif image. In the image, Theta is the angle
from the centerline of the sun to the Earth's limb. Alpha is the angle
from the sun's centerline to the viewer (a little airplane). The
centerline passes through the center of both the sun and earth.
Pseudocode:
{ If the absolute value of alpha is less than the absolute value of
theta, then check and see if the eye is between the earth's center and
sun's center (not directly on the centerline, just somewhere near it,
more or less check to see if the eyepoint is between the
earth-center-X-coord and the sun-center-X-coord). If it's within this
range, then the sun is visible if the user looks at it
} else {
if alpha is greater than theta, then the sun should be visible if the
user looks at it.
}
End pseudocode.
Not too shabby, but it probably has holes. I do know that the last time
I checked, FG will display the sun at midnight, especially if you fly up
high enough, even if the earth is actually in the way, as in directly in
the way.
JD
Danie Heath wrote:
If I can give my opinion, 1 mile visibility sometimes looks like 20 mile
visibility when your only a mere 3000 ft up in the sky ... It's a really
a difficult subject this
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brandon
Craig Rhodes
Sent: 26 November 2003 08:53 PM
To: [EMAIL PROTECTED]
Subject: [Flightgear-devel] Re: the horizon
As I continue to ponder my horizon ideas, I am driven to ask: is the
FlightGear visibility code perhaps too naive? In real life, if you are
ten miles up looking down on landscape with fifteen-mile visibility, do
you really only see a little five-mile-radius patch?
(And: is this what the current visibility model does, or have I just
pushed it too hard and misunderestimated its sophistication?)
--
A scientist claims in court that the reason he ran a red light is that,
due to his speed, the color was blueshifted till it appeared green.
Needless to say, the charges of running the red light were dropped and
he lost his license for speeding excessively.
inline: Earth Sun Airplane.gif___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
