Re: [Flightgear-devel] Next world scenery build
Martin Spott wrote: fails in the end. After the 'standard' shapefile-based scenery has proven to work we can start tackling issues like the Great Lakes shorelines and such. The SRTM water body dataset seems to give some nice improvements on this front. It does need smoothing though, since all the points are the SRTM pole locations - so when viewed close up it's just made up a lots of perpendicular lines. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] simgear/flightgear SGSky thesky shared library compile problem
Juergen Tretthahn wrote: Hi all :) I have a little problem compiling/running fgfs build as shared lib variant. (Yes... i know... static is the prefered build way you/the devs use.. i still try to make my daily cvs debian packages the debian-standard shared way :)) The debian standard way uses an incredibly evil bodge to make a shared library. I'd suggest speaking to the debian package maintainer. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Modular / portable cockpit design
James Turner wrote: On 2 Dec 2005, at 00:32, John Wojnaroski wrote: Just a question of time and energy. The design issue is how to keep it portable so we can haul the gear around to shows like Scale4x coming up in Feb 06. Same problem with putting everything into a shell, fantastic for a fixed installation but kind of like the old story of the fellow who builds the 30 foot sailboat in his cellar I would talk to some exhibition set / theatre set people if you can (I am slightly involved in the tech side of an amateur theatre company) - generally such people have to produce stuff which is pretty cheap, pretty durable and which can be transported, assembled and taken apart pretty fast without lots of support equipment. As far as I can tell (I haven't worked on set myself), a lot of it comes down the finding sufficiently fancy pins / hinges / bolts / locks that you can have everything be modular (eg, the pedestal, main panel, glare shield), but still be rock solid when it's all set into place. Experience is a big factor in that... Google for Akers Barnes Cockpit. Made from MDF, just slots together. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles ( generally don't drop objects)
Melchior FRANZ wrote: Is the following behavior OK? Generate all objects from all FG_SCENERY paths until we found the first OBJECTS_BASE entry (including the other object entries in this *.stg file). Then read the matching Objects/ directory, too. But *then* stop scanning. That makes sense. That way you can have a tree containing just additional objects followed by detailed scenery, followed by default scenery all on your path. You'll get the objects, plus the most appropriate scenery for the area you're in. Certainly being able to place objects at sea is a huge improvement (I mentioned that this failed quite sime time back, but was unable to work out why). -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Autopilot
Steve Hosgood wrote: 3) It was broken in 0.9.8 but is fixed now. I *think* I may have tried it in 0.9.9 with the same results. Not sure. Can't check right now. It'll still be the same. The C172 doesn't use the generic autopilot code - it has a KAP140 autopilot model - which is controlled by clicking the buttons on the device in the cockpit. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D modelers
Josh Babcock wrote: I was also thinking that this community must have a treasure trove of airshow pics. Obviously most people won't want to put them up on airliners.net, but maybe we could have some sort of forum where we can post wanted ads and lists of planes we have pics of. Or we could just make a habit of being considerate like Innis and posting on the devel list :) You'll find most of my airshow and museum pics here: http://photos.stockill.org/g45.html There may be others scattered around that site. If people need somewhere to put pictures online then www.fotopic.net will give you 250MB of space to host them (disclaimer: I'm biased - this is where I work). I know the museum at Doncaster has a large number of aircraft, and cockpit sections on display (there's a list here: http://www.aeroventure.org.uk/mainexhibits.php ). If there are any that people are particularly interested in then if you can tell me what you want photos of, or what you need measuring then I can try to get you the info you need when I'm next there. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Release of v0.9.9 source code
Curtis L. Olson wrote: Hello everyone, FlightGear v0.9.9 is now final. The source code is propagating through to the mirrors. If you have built an 'official' binary version of FlightGear in the past, it would be great if you could build a binary for v0.9.9 as well. I'm going to make an 'official' v0.9.9 announcment in a day or two and I'd like to have precompiled binaries available for as many platforms as possible. The slackware package is now available at the usual place: http://flightgear.stockill.org.uk/ It currently *doesn't* contain fgrun, as I can't get a current cvs version to build, and the last release version was based on the older airport files, and therefore just aborts because it can't find its data. I just get the error below on the final link (have the requirements for fgrun changed since the last release?): g++ -g -O2 -L/usr/X11R6/lib -L/usr/lib -o fgrun wizard.o wizard_funcs.o advanced.o advanced_funcs.o AirportBrowser.o AirportTable.o Fl_Table.o Fl_Table_Row.o Fl_Plib.o Fl_Heading_Dial.o main.o io.o fgfsrc.o logwin.o settings.o util.o run_posix.o fgrun_pty.o -lsgprops -lsgxml -lsgmisc -lsgstructure -lsgdebug -lplibssg -lplibsg -lplibul -lfltk_gl -lfltk -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lm -lz -lutil main.o(.text+0x192): In function `main': /archive/Mirror/flightgear/FGRun-cvs/src/main.cxx:87: undefined reference to `Fl::lock()' run_posix.o(.text+0x53): In function `__gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar std::__uninitialized_copy_aux__gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, __gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar (__gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, __gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, __gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, __false_type)': /usr/include/c++/3.3.4/bits/stl_algobase.h:373: undefined reference to `Fl::lock()' run_posix.o(.text+0x89): In function `__gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar std::__uninitialized_copy_aux__gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, __gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar (__gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, __gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, __gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, __false_type)': /archive/Mirror/flightgear/FGRun-cvs/src/run_posix.cxx:87: undefined reference to `Fl::unlock()' collect2: ld returned 1 exit status make[2]: *** [fgrun] Error 1 make[2]: Leaving directory
Re: [Flightgear-devel] RenderTexture::BeginCapture(): Texture is notinitialized!
Vivian Meazza wrote: There should be no need to uncompress either file. Unless zlib support is missing somewhere. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Release of v0.9.9 source code
Frederic Bouvier wrote: Jon, you need to use fltk with multi-threading support. Thanks. All rebuilt, and it's now working. The package has been updated. (If version numbers are cheap, package revisions are even cheaper ;-) Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Stefan Seifert wrote: I'm sure you meant /usr/share/FlightGear/... and not /var. Makes more sense to me. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
Martin Spott wrote: Oliver C. wrote: Then we should definitely officially use /usr/local/games/flightgear/ or /opt/flightgear/ as $FG_ROOT on unix systems. I don't understand why the hell people should want to use /usr/local/games/ for FlightGear ? The slackware package puts the binaries in /usr/bin and the data files under /usr/share/FlightGear I *could* put the doc files in /usr/doc/Flightgear-$VERSION but since there are various references to them under FG_ROOT that's where I left them. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Martin Spott wrote: Several people did comparisons between VMAP0 data and reality and it looks like VMAP0 is not very accurate at all in this area. I expect that we an offer a guide to the community in the not so distant future that explains how people can improve the landcover data and submit these improvements. Please keep in mind that carefully altering landcover data might comsume a noticeable amount of time On the other hand you will be compensated by very nice visual effects, Also be very careful what you're using for source material - it's very easy to get caught up in copyright issues. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: A380 arrived in EDHI (Hamburg-Finkenwerder)
Curtis L. Olson wrote: How about a spyware popup ... Oh I see you just typed the word Paris, here are some great hotel + airfare combinations you might be interested in, and would you like me to search ebay for berets? No, not spyware - clippy :-) Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.0.9-pre3
Steve Hosgood wrote: Curt: if you've not done it yourself yet, the file data/Huds/Instruments/Default/runwayinstr.xml has duff permissions. The following files probably *shouldn't* be there: Aircraft/A-10/.#A-10cl-set.xml.1.6 Aircraft/c172/Models/.#c172p.ac.1.1 Aircraft/c172/Panels/.#default.xml.1.3 Aircraft/c172/Panels/.#c172-panel.xml.1.8 Aircraft/c172/Panels/.#c172-panel.xml.1.4 Models/Trees/.#deciduous-tree.ac.1.3 Scenery/Terrain/w130n30/w123n37/.#KSFO.btg.gz.1.2 -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 31, Issue 29
Buchanan, Stuart wrote: --- Steve Knoblock [EMAIL PROTECTED] wrote: I am unsure if I can help, I do hope to convert a model of the Cape May Light I made for MSFS for FG once I understand the tools. As a first pass, you could place a generic lighthouse (from http://fgfsdb.stockill.org/models.php) in the correct location by editing the the correct .stg file. Or just let me know where it is, and I'll add it to the database. Is there an organisation that manages lighthouses? (in the UK there's Trinity House, and the Northern Lighthouse Board). If so then it's possible they list all the lights they manage - that's then an easy addition to the scenery. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
Curtis L. Olson wrote: I am currently targeting the official v0.9.9 release for late next week (time permitting.) Is there any preferred version of OpenAL for this release? Just wondering if there's a recommended version for linking against for the binary packages. Also, is there an fgrun release planned to coincide with 0.9.9? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Martin Spott wrote: Yes, it _is_ nice to have an ensemble that represents the entourage of an airport or a city centre, but a single tower somewhere in the boonies that VFR pilots typically use for navigation is a valuable addition as well. Yesterdays addition was a set of wind turbines for Finland, with position data kindly supplied by Esa Hyytia - you don't even need to be able to model objects to help - positions for placing models that are already available are just as useful. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Josh Babcock wrote: Jon Stockill wrote: Martin Spott wrote: Yes, it _is_ nice to have an ensemble that represents the entourage of an airport or a city centre, but a single tower somewhere in the boonies that VFR pilots typically use for navigation is a valuable addition as well. Yesterdays addition was a set of wind turbines for Finland, with position data kindly supplied by Esa Hyytia - you don't even need to be able to model objects to help - positions for placing models that are already available are just as useful. Jon, Is there a way to tag a number of entries in the DB as a package? It would be nice to just be able to DL Baltimore or KADW instead of figuring out what the area is and then grabbing all the objects in that area. Currently the smallest area it's broken down to is one of the 10x10 degree scenery tiles. The biggest of these files is only 500k (the whole planet fits in a 4MB tarball), so I didn't see a need to break it down any further. If you're interested in just a specific area then drop me an email and I'll see about exporting just the area you're interested in (if you're just interested in seeing what objects are in a particular area you may find that entering partial lat/lon info into a search on: http://fgfsdb.stockill.org/objects.php Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Curtis L. Olson wrote: Jon Stockill wrote: Currently the smallest area it's broken down to is one of the 10x10 degree scenery tiles. The biggest of these files is only 500k (the whole planet fits in a 4MB tarball), so I didn't see a need to break it down any further. If you're interested in just a specific area then drop me an email and I'll see about exporting just the area you're interested in (if you're just interested in seeing what objects are in a particular area you may find that entering partial lat/lon info into a search on: http://fgfsdb.stockill.org/objects.php Jon, I see a distribution issue which I'd like to discuss. The object database lives in it's own separate tree. Right now to use your object database a person needs to add a set of models to their base package. Then they need to install the object tree. However, from my perspective, if I want to roll up a 10x10 chunk of terrain + objects I have a big problem. I need to either roll these two trees together in one big tree (which makes it hard to change or upgrade the objects.) Or I need distribute 2 tgz files (and the end user needs to download and correctly install 2 tgz files) for each 10x10 chunk. Would it make sense to make your object database (for the entire world) part of the official base package and put it all in cvs? If we want to leave these objects as user-add-on-after-the-fact entities, then it's ok how we are doing it now, but they add a *lot* to the flightgear experience so I would really like to make them part of the default some how without imposing an overwhelming burden on the end user to do extra complex downloads and installs by hand. I'm not sure I'm explaining the issues very well, but hopefully someone understands what I mean and can offer suggestions. It would be easy enough for you to include the latest version of the database when you built the scenery - the Terrain and Objects split works really well to make this relatively easy, and simple for someone to add the latest version of the objects before the next scenery update. If your scenery package were to have the following (example) structure in the tarballs: Objects/w010n50/ Objects/w010n50/w002n53 Objects/w010n50/w002n53/29.stg -- entries just for objects (Static scenery models would be included here) Terrain/w010n50/ Terrain/w010n50/w002n53 Terrain/w010n50/w002n53/29.stg -- entries for airports (Airport and terrain tiles appear here) roll the whole lot up in a tarball for w010n50 and it can be installed as a single package under your scenery directory. If anyone wants to update the models at a later date then they can just replace the Objects/ tree with the latest version. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Curtis L. Olson wrote: That might be what we have to do, but that implies a change in where scenery files are extracted relative to the scenery tree which would could cause a fair amount of confusion ... not that the current process is completely unconfusing ... It takes things back to how they were - you unpack everything directly in your scenery directory - the scenery tarballs then contain everything that should be below that. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Curtis L. Olson wrote: Jon Stockill wrote: Curtis L. Olson wrote: That might be what we have to do, but that implies a change in where scenery files are extracted relative to the scenery tree which would could cause a fair amount of confusion ... not that the current process is completely unconfusing ... It takes things back to how they were - you unpack everything directly in your scenery directory - the scenery tarballs then contain everything that should be below that. I have in mind the fgadmin utility which installs and removes scenery and knows where everything should go. That is going to require quite a bit of modification I suspect. Yes, it'd need to install the contents of the tarballs to ...Scenery/ rather than ...Scenery/Terrain Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
Innis Cunningham wrote: I would think we are better ploting our own course this may mean we are a bit light on to start off with but with people helping it would take no time at all. Lots of airlines provide timetables in PDF format - fed into pdftotext and parsed with a bit of perl we should be able to build up a reasonable amount of data fairly quickly. Worst case is the formatting is horrid and it all needs to be done by hand - it's still not gonna take forever if there's a few people involved. Is there any documentation on the current AI schedule formats anywhere? I'll have a look at a couple of timetables tomorrow and see what I can do. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tue, October 25, 2005 5:18 pm, John Wojnaroski said: The boards Curt refers to were specifically designed for a 747 simulator. They will read analog, discrete inputs, rotary encoders but are not designed to drive anything other than digital signals. Would need a bit more design and rework to handle the current loads of DC motors or servos, control, etc. (See earlier post) How about the analogue output boards on http://cockpit.varxec.net/ -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
Harald JOHNSEN wrote: I am not sure I follow you here, taxiway design have strict rules that you can find on the FAA site. I can assure you there are plenty of airfields out there that don't follow the rules. Many of the ones I've worked on have developed over the last 60+ years to become what they are today, and modifications over that sort of period results in some very strange layouts. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
Durk Talsma wrote: - buildings placement This can be done through a combination of .stg and xml files, but this has to be done either by hand editing, or by using a dedicated scenery editor. I'm not sure if fgsd would be able to do this. This would be the only interactive application that would allow this. See KSFO for an example. I haven't tried doing this myself, so I can't comment on whether it's easy to do or not. I tend to use areas of turf to represent buildings, they're identified by the size of the turf, which can easily be positioned and aligned. Then I have a script which strips out the appropriate lines, and produces the info for the scenery database. (I've actually just discovered a book in my local reference library which contains plans for a large number of standard RAF buildings. I should have them all online in a couple of weeks - unfortunately the book in question is reference only, so I'm spending my saturday mornings at the library with my laptop). Being able to define some simple vector diagrams which could be placed in taxidraw, and exported in the scenery format (in a similar way to how windsocks can be exported now) would be extremely useful). Just wondering what type of animations you were thinking of. We have support for moving aircraft now, but no ground vehicles yet, although this could be done using animation scripts. ISTR seeing mention of a function which allowed retrieval of ground elevation at arbitrary points. Would this make AI ground vehicles possible? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. esd or artsd would allow you to share the device. I suspect you'd need to start the sound daemon, then your comms s/w (which would need to use the device read/write), then flightgear (write only). -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Martin Spott wrote: IAXClient focuses on portability and I've already managed to build it on AIX, IRIX, Solaris8, FreeBSD and Linux - with neglectible programming skills ;-) It's very small and think it is worth being incorporated into FlightGear: quickstep: 18:00:28 ~/CVS/Asterisk/iaxclient du -ks * 28 COPYING.LIB 16 CVS 12 README 3180lib 1548simpleclient IAX is also NAT friendly (it runs a single udp port at each end, unlike SIP for example). -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A little emergency encountered inside FlightGear
Ampere K. Hardraade wrote: As a side note, I made it safely back to the airport, braked, and taxied to the tarmac. Those who have had trouble braking on large jets may want to hold Shift+B on touch down. Provided that Caps-Lock is off, holding Shift+B will toggle the brake between on and off states, thus preventing the nose wheel from sinking into the runway. Enabling Caps-Lock and hold B alone will also work. Antilock brakes simulated with key repeat - I like it :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Build problem with today's CVS update
William D. Earnest wrote: Hello, Updated my source copy this morning, including the endian patches. Several tries, including a full autogen.sh in simgear and flightgear, don't yield a full compile. Simgear compiles without error reported. Flightgear builds until it gets to the /FDM/ExternalNet directory. There the compile of externalnet.cxx includes simgear/io/lowlevel.hxx, which references simgear_config.h, and that is not found. I located simgear_config.h in the simgear/ directory here. Sounds like a path problem? I'm having the same problem here. While simgear_config.h can be found in the source tree it doesn't appear to get installed. Is this a problem in the simgear makefile (and simgear_config.h *should* be installed), or a problem in lowlevel.hxx (in that it shouldn't be referencing simgear_config.h) Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
Curtis L. Olson wrote: I have a question I'd like to toss out to the group for discussion/comment. What would people think of abandoning our mailing lists and converting over to online/web-based forums? I think you'll lose an *awful* lot of input. I'm really no fan of forums. Mail gets delivered to me. I can read it wherever I like. I don't need a net connection. With a forum you need to be online. Lots of forums still have problems with spam too. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
Ralf Gerlich wrote: Hi, Ampere K. Hardraade schrieb: I think you misunderstood. I was referring to the taxiways under map mode, not satellite mode. If you go in map mode, you will see that Google got some pretty accurate vector data for taxiways generation. Whoop, didn't see that. In that case: Yes, I misunderstood and join your inquiry ;-) The data comes from Navteq. Not really an option for us, as it would be horrendously expensive, then there's this: http://www.google.com/help/terms_local.html Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
Dave Martin wrote: On Friday 09 September 2005 18:36, Jon Stockill wrote: I've just finished downloading and processing all the data to get my scenery build system back up and running after a disk crash, it's building tiles for a test of the OSM roads at the moment. I'll grab some screenshots when it's done. I look forward to seeing that. Here's a couple of pics, the first is looking west over the gherkin, and the second is looking out over regents park. Generation time was over an hour for that tile on a 1GHz athlon (the resource limits in fgfs-construct needed a significant increase). Memory usage was ok at around 140MB. http://flightgear.stockill.org.uk/scenery/osmroads1.jpg http://flightgear.stockill.org.uk/scenery/osmroads2.jpg It shows up a few limitations in the source data. The road segments are currently all represented seperately and not tied into a road object, this results in lots of short roads, and visible breaks on the outside of corners. This will improve as the open streetmap system matures (it's still very early days). Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
Ralf Gerlich wrote: This looks quite detailed. I'm not that familiar with the London area so would you say that there is a considerable amount of smaller streets missing in there? You can see the source data here: http://www.openstreetmap.org/ there are roads missing, simply because the map is not yet complete, nor are they categorised. Once there's some more data, the segments are correctly joined into roads, and the roads are classified then we can be more selective about the roads we include in the scenery. Even with not so much detailed streets - i.e., leaving all the back-streets out and having only freeways and mainstreets processed - the generation of scenery takes substantially longer than for the standard data. I have no numbers on this, but having to raise the resource limits in fgfs-construct considerably is quite a good indication. Yes, the cpu limit was set as 120 seconds - I increased it to an hour and *still* had failures, so it's now set at 4 hours here just to be safe. One other problem that'll probably become more serious with more detailed street-data is that the comparatively small streets not only produce lots of small triangles on the streets themselves but also raise the number of triangles on neighbouring polygons by splitting them. (Currently fgsd crashes on loading some of the more full tiles - possibly because of the sheer number of triangles; I will investigate further on that when I get the time) I've not had that problem yet, but so far the data only covers a relatively small area. I currently do not have any solution for that and I know that there have been discussions before, but perhaps having more detailed scenery now may be a good reason for the experts here to reconsider this topic. We've just been discussing another problem on irc - the green texture isn't really appropriate for a city, but I left out the city areas since the texture it uses contains its own roads. I'm not really sure of a solution to this. This may be solvable by automatically snapping endpoints and recombining shorter segments into longer segments. It will be solved in future versions of the openstreetmap data - at the moment it just exports as lots of short roads with a start and end point, eventually these will be chained together to form longer roads. Anyway recombination will only partially solve the problem, as on an intersection only pairs of participating line-segments can be joined. Perhaps we need a better way of making polygons from lines, much like the v.buffer operation of GRASS (http://grass.itc.it/grass61/manuals/html61_user/v.buffer.html). At the moment I'l just converting the exported openstreetmap data to the tguserdef format, which I suspect is less than ideal. It may be worth having something that will be a bit more intelligent, and resolve some of these problems as it parses the data. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover
Martin Spott wrote: Herewith I appoint you to the future maintainer of OSM-data in our kindcover database :-) I should have kept my mouth shut :-) Do they log the changes in their database, do they offer any 'raw' interface ? The interface is explained here: http://www.openstreetmap.org/wiki/index.php/REST I used the map command to dump the data, then converted it to the tguserdef format in order to build the scenery, but a shapefile could just as easily be used as the intermediate format. This would make it easier for us to track the development of their dataset. Do they differenciate between different sized roads ? Not yet, although the intention is to have a key/value system which will allow the tagging of road types, names, numbers, etc. So the classifications will be available. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
Martin Spott wrote: Good evening, We proudly present the first export from the TerraGear landcover database or however you prefer to name it. The contents is exactly the same as the landcover data that has previously been used for scenery generation - at least this is the intention. Excellent - I'll give it a try. I'm also experimenting with some early data from openstreetmap.org to add accurate roads to scenery. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
Dave Martin wrote: Don't know why I didn't find openstreetmap.org when I was searching about for 'royalty free' mapping last week. Now that you've mentioned the site I'm all grins. Thanks very much Jon. :) There's anot a huge amount of data there yet, it's still in the very early stages, but if you own a GPS you could help change that ;-) I've just finished downloading and processing all the data to get my scenery build system back up and running after a disk crash, it's building tiles for a test of the OSM roads at the moment. I'll grab some screenshots when it's done. (The other good news is that now I have a working system again I'll be adding more stuff to the scenery database). -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
Dave Martin wrote: I think I can get access to a suitable GPS but with fuel prices at £1/litre I think I'm going to be dusting off my bicycle and getting some much-needed exercise ;) Inspired by the charity tube challenge a couple of weeks ago I'm currently considering making use of a day ticket on the local bus and train networks - could be a cheap way to cover a lot of distance, with the added advantage that I get to improve scenery local to me :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] crashes in GL
Vivian Meazza wrote: And SG? Before you tear your system apart, AJ has just reported similar symptoms over on IRC. He's just updated to CVS HEAD. Yes, both FG and SG from 7th July. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] crashes in GL
Harald JOHNSEN wrote: Jon Stockill wrote: Due to the death of the machine I was doing all my flightgear work on I'm currently trying to set up another machine so I can still build packages, but I've run into a bit of a problem. While my old packages work ok on this machine (it's not gonna win any awards for framerates, but it proves it works) the current cvs code segfaults on startup like this: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 18753)] 0x401861b2 in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1 (gdb) bt #0 0x401861b2 in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1 #1 0x401863f3 in glXCreateGLXPbufferSGIX () from /usr/X11R6/lib/libGL.so.1 #2 0x0846a17a in RenderTexture::Initialize (this=0x891d220, width=1, height=1075494657, shareObjects=false, copyContext=false) at RenderTexture.cpp:508 You are not supposed to have this width and height, in the bbcache.cxx code there is rt-Initialize(256, 256, true); This gets stranger and stranger. I rebuilt the code from scratch (suggested by Harald), and it still failed with the same error. So I deleted the whole thing, and checked it all out from CVS again - a completely clean start. Same error. Checked out the code on another machine, built it, runs ok. Copied the binary from the working machine to the problem machine, and now the error is back - same binary, different machines, different result - a segfault caused by an out of range value which is supposed to be hard coded. Tests so far have ruled out plib/simgear/flightgear version problems, and compiler problems (since the working binary fails on the problem system). Does anyone have any idea where I should be looking before I go completely insane? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] crashes in GL
Vivian Meazza wrote: No, but if it's any compensation, cvs has been broken under Cygwin since, well, I've tracked it back to around 7th Jul. For me it started when I downloaded a clean copy. Norman Vine's version is exiting as soon as the load sequence finishes, mine and a machine AJ is testing on hangs at the same point. At the moment the problem seems to be in Simgear, possibly in Harald's new GL stuff, but that's a very tentative diagnosis. Right now I can't see anything obviously wrong, and am really at a loss as to what to do next. The last known good seems to be 7th Jul - you might like to roll cvs (FG and SG) back to that point and see what happens. I'd be interested to compare notes I'll give that a try. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] crashes in GL
I rolled back cvs to 7th July, built flightgear, and still have exactly the same problem - I guess it's related to something on this system. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Custom scenery integration
Martin Spott wrote: Does osgPlanet allow for contour lines for elevation data instead of DEM's ? Do you have a suggestion how to convert the DEM's into a set of contour lines without creating horrible bloat or loosing precision ? The SRTM data is available in GeoTIFF format. gdal_contour (from gdal) can convert this to contour lines. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce Tricolori aerobatic jet
Dave Culp wrote: 3) Making a smoke model that merges well with the others. I've heard (on this list) that this may be a plib limitation. It may require the use of a different visual model, like billboards or particle fields. I'm sure someone has already done some work on particle smoke. ISTR seeing some screenshots a few months ago, but nothing more after that. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns inViewport
Paul Surgeon wrote: What a pity as I don't know of any good replacements and writing VOIP software is not a trivial task. So the only way it could work is if the creators of TeamSpeak released a GPL interface to their software? I guess text will just have to suffice. http://www.voip-info.org covers practically everything out there. Codecs, transports, servers. I'm sure there are alternatives to teamspeak, and failing that, there are tools to build something. The speex codec should certainly be able to provide voice comms while using a sensible amount of bandwidth. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
Robicd wrote: Of course, Melchior ... I know :-| But this solution doesn't fit to this specific problem. FlightGear will crash _before_ I know which http://www.flightgear.org/Downloads/aircraft/ I need to download! Some other idea? Will FGFS check/discard/revert_to_default network packets with not existing Aircraft identifications inside? It would make sense to default to using the glider model if the correct one can't be found. Otherwise anyone connecting to such a server with an aircraft they're developing presents the other users with something of a problem (ignoring the obvious DoS aspect if someone wanted to be malicious). -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
Erik Hofman wrote: Looking at the Multiplayer code I can see this code can use a good overhaul anyway. It needs to adapt the SGSubsystem style and use the AIModel code to display the models, which will also allow it to show up on the radar. It's probably not too much work to do since most of the current code could be reused. Other aircraft showing on radar would be excellent. I've been playing with the t38 refuelling scenario recently, and it's a lot of fun - definitely teaches you the value of minute stick and throttle inputs :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Custom scenery integration
Ralf Gerlich wrote: I don't see why we need to store elevation data for the whole world in the database anyway. I wouldn't think elevation data would be a typical subject for user-submitted modifications related to wide areas. If more detailed structures are desired than provided by the DEM data, corrective contour data for small areas could be stored in the database and be combined with the official DEM data, which could be stored outside the database. I converted a chunk of SRTM data to 10m interval contours, and overlaid this on an ordnance survey map (using mapserver) - the results are actually incredibly close - the 0 point of the two datasets is obviously slightly different, but the two datasets fit together remarkably well - Obviously I have no idea how good the data is for the rest of the world, but the UK data seems surprisingly accurate, which leads me to my question - is there really such a huge problem with our source data, or do we just need to be generating scenery with more polygons? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
Mathias Fröhlich wrote: Hey You're the man! That is it. Setting bits-per-pixel to 32 makes the models throw phantastic well looking shadows! At least for my box with the binary ati driver. After things going pop on my machine it's now back working - I dropped the nvidia driver back to the previous version, and now clouds and shadow are working quite happily. Although I have to say that I'm not convinced Harald is in league with the hardware manufacturers. Trying to fly along at 4fps is hard enough, but when you're busy looking at the shadows and going ooh, wow! it's practically impossible. I guess it's time to start saving for an upgrade :-) Fantastic work Harald. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: About 3D Clouds
Melchior FRANZ wrote: BTW: I just noticed that volumetric shadows work for me with Linux 2.6.11.7 + nVidia 6629, but not with Linux 2.6.12.2 and driver 7664. With the latter, the whole screen goes darker, and no other shadows are visible. But since the newer drivers lock the machine if RenderAccel is activated, switching back is a good idea anyway. I upgraded to 7664 a couple of days ago, fired the sim up, and the machine promptly overheated (it's been a bit warm here for the last couple of weeks) looks like the fan stopped on the graphics card, so that just died when asked to do anything. I swapped it for my old card (also nvidia) and noticed that runs with no shadows, but a darker screen as you describe - I put it down to the card being less capable, but I think I'll downgrade the driver and try again. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Hurricane
Vivian Meazza wrote: Have you seen the recent Aeroplane magazine? It has comprehensive series of articles on the Lightning: excellent source data. Keep at it - it just takes time - you can hijack most of the Hunter instruments for the interior. And if anyone wants real instruments there seem to be an awful lot of Hunter instruments on ebay at the moment - most likely due to the changes in the regulations covering flourescent paint. :-( -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Hurricane
Vivian Meazza wrote: Jon Stockill wrote Vivian Meazza wrote: Have you seen the recent Aeroplane magazine? It has comprehensive series of articles on the Lightning: excellent source data. Keep at it - it just takes time - you can hijack most of the Hunter instruments for the interior. And if anyone wants real instruments there seem to be an awful lot of Hunter instruments on ebay at the moment - most likely due to the changes in the regulations covering flourescent paint. :-( Another stupid EU regulation? Sounds like it - a friend at south yorkshire air museum was telling me that lots of museums are having to dump stuff because the regs make it totally impractical to keep them. The only loophole is for clocks and watches (so you can strap it to your wrist, but not put it in a display case or cockpit). As he said - extensive studies of people who spent upwards of 8 hours at a time sitting in front of such instruments has shown that they're losing teeth and hair, their remaining hair is turning grey, they have mobility problems, and some are dropping dead. Oddly enough the same can also be said of the control group. Yet more pointless regulation to protect us from nothing. If anyone finds themself near Doncaster though I can highly recommend south yorkshire air museum - they've got a lot of cockpits there, and I think there's always a few open so you can get in and have a really good look and take some nice pics. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Hurricane
Erik Hofman wrote: Jon Stockill wrote: As he said - extensive studies of people who spent upwards of 8 hours at a time sitting in front of such instruments has shown that they're losing teeth and hair, their remaining hair is turning grey, they have mobility problems, and some are dropping dead. Oddly enough the same can also be said of the control group. What was th test period, 60 years? He was hinting at WW2 bomber crews, who probably spent more time in front of such instruments than anyone else. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Hurricane
Josh Babcock wrote: Jon Stockill wrote: Yet more pointless regulation to protect us from nothing. It's not just the EU, I'm having this problem in the US. I tried to get a surveying compass with tritium illumination, and found that it's banned in the US as well. This is a big deal since electric illumination can seriously deviate a magnetic compass. I don't think you can get it for non-military gun sights anymore either. Grrr. Yet they happily sell these to everyone over here: http://www.cashncarrion.co.uk/?op=catalogue-products-nullprodCategoryID=19 It's insane. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Hurricane
Josh Babcock wrote: From the page: We can only ship the Glowring to UK addresses Makbe the UK is saner than the EU and US. Anyone over there want to let me order one to their address and *cough* illegally ship it to me? Clearly they're not that sane - they'll happily sell tritium keyrings to people, but items of genuine historic interest are destroyed because they glow. Someone has their priorities seriously screwed up. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll
Gerard Robin wrote: Sand MINE rolling-friction2.O/rolling-friction bumpiness0.1/bumpiness Sand FG rolling-friction0.1/rolling-friction bumpiness0.1/bumpiness That may make sense for a sea plane with floats, but it doesn't make sense for an aircraft with wheels landing on a beach strip. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Completely OT (but aviation related.)
Curtis L. Olson wrote: I was curious about the idea of removing the case from my Linksys WRT54G wireless router and powering that by battery. Supposedly it's running linux and is hackable, but I haven't played around with trying to hack into it yet. How much space do you actually have? Would a nano-itx or even mini-itx board fit? With one of those you could use a USB wireless interface, giving you flexibility to position it for best signal (radome style bulge under the aircraft? :-) Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Completely OT (but aviation related.)
Curtis L. Olson wrote: anything. I'm just going to move forward slowly one step at a time and ignore most of the bright ideas from the mailing list. :-) Probably a wise move :-) Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Jon Berndt wrote: Is the ground cache for the benefit of the FDM? The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just What I was curious about was if per-wheel contact point checking was being done when it doesn't need to be done - that is, when the aircraft isn't even close to the ground? I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problems with todays CVS
I've just updated and built todays CVS code, discovered a problem. Starting on runway 09 at EGNM with the default cessna the sim freezes a couple of seconds after the aircraft starts rolling. I don't think it's even travelled its own length. Menus are all still fully operational, and shift-esc puts the aircraft back on the end of the runway where the whole thing can be repeated - same freeze every time. Repeating this on runway 24 at EGXG exhibits exactly the same problem. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with todays CVS
Dave Culp wrote: well-loved no scenery below the aircraft ground cache message. I don't get it, I didn't see this behavior until after I committed the patches, when I noticed it once. Melchior has these patches also applied and didn't complain. Maybe this is something to do with OS, compiler, or video card? Slackware 10.0 gcc-3.3.4 nvidia fx5200 What's everyone else using? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Problems with todays CVS
Jon Berndt wrote: * Erik Hofman -- Monday 30 May 2005 18:22: I don't get it, I didn't see this behavior until after I committed the patches, when I noticed it once. Melchior has these patches also applied and didn't complain. And I first saw it when I tried to reproduce Jon's problem. Which worked. Seems like I do really somehow prefer YASim, at least always if I try to test stuff. (The bo105 may have to do with it.) YASim works. Only JSBSim doesn't. :-( Only the **C-172** doesn't? Or, any JSBSim aircraft? Same problem with the F-18 Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Martin Spott wrote: Melchior Franz wrote: Update of /var/cvs/FlightGear-0.9/data/Models/Airport In directory baron:/tmp/cvs-serv27845 Modified Files: beacon.xml beacon.ac Jon, are you going to update the respective entry in our database ? It's not in there. Though there are database entries for the objects in the base package just so everything ties up the model isn't actually stored in the database. So we've nothing to change unless the path or filename changes. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Melchior FRANZ wrote: For those who care: these changes to the beacon solve one of the recently discussed problems with hanging FDM: The beacon is a quite expensive structure. It consists of about 1000 vertices and 950 triangles, all on the same spot. When you fly over a beacon, the ground cache has to eat all these triangles, which makes the FDM stutter or even hang. Quite a waste of effort, for the fraction of a second that it takes to pass the beacon. With these changes most of the 950 faces are invisible to the ground cache. There's only a simple invisible pyramid instead for intersection tests. This does, of course mean that you can't fly between the rails through the beacon any more ... ;-) The rumour goes that fixes for the other crash/hang problems are already done, too, and will soon be applied. (And they work quite well so far. :-) Is this something that people should consider for any high poly structures then? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
Lee Elliott wrote: I have three version here 7174, 7167 6629. Both of the 7nnn exhibit the same problem and 6629 won't compile here. Drat! Which kernel version are you using? I'm on 2.6.11 here. Check the forum - there's a patch on there for 6629 with 2.6.11. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
Steve Hosgood wrote: Disclaimer: This is a toy. It's fun, and probably isn't too far wrong from modelling the real Colditz Glider. However, I've never even *seen* the Colditz Glider replica (in the Imperial War Museum now, apparently) far less flown it. So I don't know. It is - assuming it's not been moved it's right up on the top floor. There a few rather dark photos at the end of this collection: http://photos.stockill.org.uk/c1955.html If the original was anything like the rebuild then it really was a remarkable achievement. (Obviously with the rebuild they tried to stick to similar materials, but did have the advantage the Please try it and if you have any suggestions, I'll be happy to take them on board. I'm expecting complaints about the stall characteristics which are probably too savage, but then, hang-gliders stall hard, so why not this machine? There's no 3D model, sorry. Suggestions for how to do one, or (better) offers of help gratefully received! How much information do you have? Unfortunately I'm the other end of the country, so can't easily drop in to the war museum again, but I suspect they'll be the best source of info. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
Steve Hosgood wrote: On Wed, 2005-05-18 at 12:10, Jon Stockill wrote: Steve Hosgood wrote: Disclaimer: This is a toy [...] I've never even *seen* the Colditz Glider replica (in the Imperial War Museum now, apparently) [...] assuming it's not been moved it's right up on the top floor. There a few rather dark photos at the end of this collection: http://photos.stockill.org.uk/c1955.html Hmm - the thumbnails aren't displaying for me. It makes it very difficult to find the one I'm looking for. I bet you're running norton internet security aren't you :-) You'll need to fix your ad blocker. If the original was anything like the rebuild then it really was a remarkable achievement. (Obviously with the rebuild they tried to stick to similar materials, but did have the advantage the Unfinished sentence? Hmmm, possibly my mouse going a bit mad - I said did have the advantage of having new rather than recycled materials. I've got my copy of Colditz: The Latter Days that I've had since I was a teenager. It contains a basic plan and elevations of the plane, but no details of (say) airfoil shape. It does talk a bit about materials used though. I scrounged around the net and came up with some photos of the original machine and the replica both on the ground and in flight and one of the jubilant ex POWs jumping up and down in celebration. Nothing scientific though. I'll do it again and publish the URLs, but I've not got time right now. I've got just one URL to hand: http://www.fiddlersgreen.net/aircraft/WWII/colditz/info/info.htm The diagram on that page would give you a starting point. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
Steve Hosgood wrote: Wasn't aware I was running with anything much more than standard Mozilla defaults. I'll take a look sometime. Hmm, very strange - it's usually windows users that have a problem, and it's only certain versions of norton (I'm the sysadmin for that photos site btw - www.fotopic.net). And presumably they used proper tools, not home-made ones. I guess that depends what they were able to borrow :-) Yes, well, that's exactly what I *did* use as a starting point! The I meant a starting point for a 3d model. I'm not the worlds greatest 3d modeller, but if I get some time this weekend I'll try and make a start on that - it's a relatively simple shape, so possibly good for me learning a bit more about blender - I'm running into problems with the Grob 115 model I've started, mainly due to lack of skill in blender, but also due to a lack of detailed info. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider
Josh Babcock wrote: It doesn't look like it would be too hard to do a 3D model. Not having to do instruments would only make it easier. I would suggest making a custom HUD instead of grafting fake instruments onto the model. If there's interest I think I could hack out a pretty nice textured model in a few days. Go for it - I don't see my attempt being that quick :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FGInterface is beeing called without scenery below the aircraft
Mathias Frhlich wrote: Hi, Can you reproduce this? And, if yes, how? I can confirm this problem - it's rare, and I haven't been able to track down why it's happened, but the sim freezes in the same way as when the aircraft is crashed - the few times I've seen this the aircraft has been at a few thousand feet, with nothing to crash into though. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FGInterface is beeing called without scenerybelow the aircraft
Richard Bytheway wrote: Could it be if you fly over a 1° tile boundary? It seems rare enough that this could be the problem - an update results in the aircraft being exactly on a tile boundary. We know this causes problems for startup, I'll see if I can cause a deliberate fault like this - I suspect I could be doing a lot of flying up and down at small angles to the tile boundaries :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: City signs
Melchior FRANZ wrote: * Jon Stockill -- Sunday 15 May 2005 01:45: Just out of interest, how do you create position models through the telnet interface? This'd be really handy for testing models. You should read flightgear-users! :-) http://baron.flightgear.org/pipermail/flightgear-users/2005-May/010974.html BTW: my script is functional again, and shows the balloons over airports. Now I'll make the billboarding rectangles, and finally create text textures (dynamically generated by e.g. ImageMagick, and maybe cached) Ah, I see, it's not dynamic, which is why you put the markers over the 5 nearest airports - the models need to be pre-defined. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] City signs
Dave Culp wrote: I made a large (1000 meter) sign to place over the coordinates for Sembach and Enkenbach, Germany, because the scenery data for that area is not good enough for finding towns visually. http://home.comcast.net/~davidculp2/city_sign.jpg It would be possible to put these over lots of towns and have them switched on/off with a key binding. Is there any interest in that sort of thing being applied elsewhere, and on a large scale, amongst the developers? It's easy enough to do using the date from GNS (http://earth-info.nga.mil/gns/html/) the biggest quiestion is how to generate the signs - imagemagick could be used to generate a texture to add to a standard model (and an appropriate xml file could be created at the same time to select it) but that would result in insane texture usage. A better way may be to generate the letters seperately, and add those to the scenery (not unlike a variation on the hollywood sign). Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: City signs
Melchior FRANZ wrote: * [EMAIL PROTECTED] -- Saturday 14 May 2005 21:46: [http://members.aon.at/mfranz/marker.jpeg [60 kB]] Is all this neat stuff in CVS or the scenery data? 8-) No. And I never adapted it to the new airport database format. So it isn't functional at the moment. Maybe I'll fix it later (in some weeks months). One would only have to run fgfs like so then: $ city-names fgfs --telnet=5502 Just out of interest, how do you create position models through the telnet interface? This'd be really handy for testing models. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft Model: AC130-H
Ben Morrison wrote: Yeah, I gave up on trying to work with Blender because of its interface. One of my co-workers likes Blender but I think it is only because it is free. I will look at AC3D. I have a registered version of AC3D, and now prefer to work in blender - once you learn the interface it's just a lot nicer to use. The learning curve is a bit steep at first, but it's extremely efficient once you're used to it. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Re : Re: [Flightgear-devel] Manipulating 3D objects
Erik Hofman wrote: Keep in mind then, that scaling a object doesn't affect the texture. SO scaling down a building will also result in smaller floor heights so to speak (the number of floors remains the same). To overcome that problem we would need a texture-scale animation that and scale exactly the opposite to scaling the 3d model. Alternatively you design a building of the maximum height you want to represent, and simply sink it below the terrain to get the desired height. This is how the generic skyscrapers work in the scenery database. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Re : Re: Re : Re: [Flightgear-devel] Manipulating 3D objects
BONNEVILLE David wrote: Ok I see, maybe my example was too selective ;) Could you explain me how to scale a model ? Is it possible to scale it along the three axis ? thx Yes - see model-howto.html in the docs directory. The scale animation will do this. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D model
Innis Cunningham wrote: Hi Sam Sam Heyman writes OK so I have downloaded the trial version and yes, you can save files from it. However, when I try and load my .wrl file it says loading failed and nothing happens Do you know if CATIA .wrl is different to say standard .wrl? As Erik says you need to import files not open them in AC3D.After you have imported them you can then save them as .ac files.Also have a look at the list of files you can import under the File/Import drop down.If you cant convert to .ac or 3ds you maybe able to use one of the other formats that AC3D can handle. Failing that blender can export ac3d files, and also supports importing of a large number of file formats - you may be able to find a common format between blender and catia. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3d city
eagle monart wrote: hi everyone. there is afunction of importng 3d models into sceneries. is it possible to add a full city lets say NY; modeled in 3d primatives and covered by a textures. what type of graphics card we need? Yes, it's possible - start designing buildings :-) See http://fgfsdb.stockill.org/ for details. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: 60 years of Dutch liberation
Erik Hofman wrote: Hi All, Today we celibate the 60th anniversary of the liberation of our country after WWII. It will be delighting to see the smiling old faces of the Canadian, Polish, American and Australian veterans carried around in old army vehicles all around the country. It will also be an opportunity to see some preserved WWII aircraft, like the B-25, B-17, P-51, Spitfire, Beech-18 and Harvard. Consider this to be a salute to all those who helped free our country from oppression. I'm a member of my local RAF Association club - it really is an honor to enjoy a drink with the members there. Sadly due to falling membership they've just had to sell their club building, but have luckily found a new home with the local Territorial Army unit. Many of the items that were on the walls of the club have been given a new home (on loan) at my Air Training Corps unit. People can't go on forever, but their memories should. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New 3d clouds
Harald JOHNSEN wrote: - fog bug : ok I think I have not re-enable fog Sort of. The terrain seems to be hidden by fog at the appropriate range, but any objects appear to have infinite visibility, so they appear to float until the ground eventually comes into view beneath them. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New 3d clouds
Erik Hofman wrote: Hi, I have added the new 3d clouds code from Harald Johnson to CVS. The code is not yet perfect (the movements to the viewer needs some tweaking) but the effects are really nice. I hope we can figure out the problems and eliminate them because the results are even better than I had expected! Yes, it's slightly odd seeing the clouds appear/disappear (even when stationary - just rotating the view seems to cause the problem). However, the overall effect is fantastic - is there any way to see the precipitation model yet? Great work Harald! -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..any estimates on SW rendering?, was: World Wind as moving map display
Curtis L. Olson wrote: Arnt Karlsen wrote: On Sun, 17 Apr 2005 17:06:11 -0400, Chris wrote in message [EMAIL PROTECTED]: So I guess you'll be working on getting a GPL'd, general-use option available. ..not yet, I'm scheeming a renderfarm stunt; some new 2'nd hand HW shop here says they got 200 Celeron 850's handy, so that got me thinking about picking this: http://tldp.org/HOWTO/BogoMips/x29.html#AEN54 sweet spot for a wee while. ;o) ..now this 200 node farm would need about 40, 50 to 60kWe, which I would like to feed off a genset or 2 burning gas which I would make off pelletized sewer sludge in my trusty old thermochemical gasifier. ;o) ..now, a 320,000 BogoMips rig running on poo for half a day, oughtta be able to do flyable software rendering for FlightGear at 1600x1200? ;o) ..what else can I do with this stunt rig, make our new global scenery? How you going to keep that beast cool? If you put all those machines in a single room and turned them on, they'd probably melt through the earth's crust in an hour or two. :-) You'd need a second set of generators, twice as much sewer sludge, and an awful lot of aircon kit. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Was: Re: [Flightgear-devel] realistic scenery
Curtis L. Olson wrote: Arnt Karlsen wrote: ..Curt, I need an idea of how much cpu work, building the scenery, is. What kinda machine(s) did you use, and how long did it take to build the scenery? I haven't timed the latest builds real close, but figure if you throw a couple machines at it in parallel, it's going to take you at least a full 7 days (x 24 hours) to do the final assembly and crunching. This doesn't include any of the data prep work (which could take weeks if you start from scratch), nor does it include the airport model generation which takes a day or so. And of course this doesn't count any of the time you need to spend sitting down and sorting through tile build problems (or other bugs/missing features) that you haven't gotten around to looking at yet. That pretty much ties in with what I found last time I tried - 3 machines of assorted specs took about a week to generate the scenery tiles from the pre-processed scenery in the work directory. The real problem is the sheer volume of data you're working with. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] realistic scenery
Paul Surgeon wrote: On Tuesday, 19 April 2005 08:21, eagle monart wrote: i tried to used fgsd but terrains are made in triangles not in squares an it looks impossible to tile what you want . a It's impossible to tile textures properly in FG. FG uses an irregular triangle mesh and not square tiles like MSFS. Even if you managed to tile a texture across the mesh you would still end up with a mess around the edges of the texture where the triangles don't end on the edge of the textures. You would need to clip a texture into the mesh for it to work properly and in the process you end up with a grid or semi tile based system. :) Not strictly true. The contents of /src/Prep/Photo in the terragear source will (assuming it's not broken) allow you to drape a texture over the terrain - this will work for small areas of photo scenery - the problem being the lack of texture paging. This does of course require you to rebuild the appropriate scenery tiles from source data. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Weather - Clouds
Harald JOHNSEN wrote: Hi, I did some research on 3D clouds for some time and finaly got something not too bad. I've started to add that to SimGear this week end, here are the first alpha screen shots : http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-011.jpg http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-013.jpg I have alse some code nearly ready for rain, snow and lightnings. Nice :-) Are the additional effects just a whole screen effect, or are they tied to the cloud objects so that (for example) visibility is reduced below rainclouds. -- Jon [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New Navigation Legislation
http://www.metriccompass.com/ At least it's cheaper to update simulated instruments ;-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] My first solo ....
Martin Spott wrote: There's nothing better than flying, I couldn't agree more. Congratulations. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Lee Elliott wrote: Hello Jon, I was just wondering if you had done any updates/additions to your models. I thought I'd seen a couple of messages where you'd corrected a couple of things, like the orientation of the Humber bridge but I haven't been able to find them. I also noticed that a few objects seemed to be missing from the Models archive that I have e.g. tilburychimney.ac kingsnorthchimney.ac That was because I got sidetracked coding for the database, and working on an aircraft model - I added a bunch of chimney models last night - there are still a couple missing, but I need to find dimensions for them. I've been working on some code for placing electricity pylons, and hope to be able to do a mass update of these in the near future. I added a tower bridge model yesterday afternoon - that'll be positioned at some point today, and once that's done I'll run another scenery export. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Anyone using TomTom POI files for scenery
Curtis L. Olson wrote: jj wrote: I'd surely like to see an Observatory bulding (such as mine, see http://kingmont.com and ftp://kingmont.com for pictures of it). Jim, if you send the coordinates of your house to Jon Stockill, he can place a grain silo there in the object database. The silo should match your house structure to within a couple inches. :-) This is actually a legitimate landmark since it as at the top of a hill overlooking a lake. (Sorry I'd not commented earlier in this thread - I've been away at a trade show for the last few days, and I'm just catching up on email) ISTR seeing an observatory building in the base package - if nobody's used it yet it won't be in the database though - we could add that for you though :-) Regarding POI files - providing we can sort out the licensing implications I'm happy to write an import script to add them to the database in bulk. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Vivian Meazza wrote: Mathias would need to reply definitively, but I think so. Just by chance I have been fiddling with a model of HMS Hermes with a ski-jump, but I was going to remove it, and restore it to her strike carrier days. I served aboard her in her last commission as a strike carrier. I just discovered a selection of 3views on aerospaceweb.org (not particularly high resolution, but possibly enough to work from). Including one on this page: http://www.aerospaceweb.org/aircraft/bomber/buccaneer/ :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Vivian Meazza wrote: I'm not sure that the Nimitz version in cvs has cats. If it has, then don't forget that the Seahawk has differential brakes, and no nosewheel steering. I have a more detailed version available here: ftp://ftp.abbeytheatre.dynu.com/fgfs/Nimitz/ Warning: it's still under development, and some of the textures are HUGE. Have any object names changed from the previous version? I found I droped straight through the deck, the hangar below, and only stopped when I hit the water. The model does look *VERY* nice though (even from the inside ;-)) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Vivian Meazza wrote: Yes, make sure that this is in your ...Data/AI/nimitz-demo.xml file: solidElevator-3-Deck/solid solidDeck/solid In place of whatever solid.../solid appears there now. Ah, so I fell through the elevator then :-) That would explain the view of the hangar deck. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Mathias Fröhlich wrote: Hi, On Freitag 18 Februar 2005 17:30, Frederic Bouvier wrote: Are you sure your runtime librairies ( that seems to be compiled with gcc-2.95.3 ) match your compiler ? That is my impression too. It turned out there was an ancient version of GLU hiding in /usr/local - which hadn't caused any problems until now - eliminating that solved the problem. Right... where's that aircraft carrier :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Vivian Meazza wrote: Let us know how you get on. Melchior claims the first successful Seafire landing. Took off from KSFO, and nailed the seahawk to the deck on the first try, then couldn't work out how to get the thing onto the cat to launch. That secondary ASI comes in rather handy :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Vivian Meazza wrote: Well done. It was easier than I expected. ftp://ftp.abbeytheatre.dynu.com/fgfs/Nimitz/ Warning: it's still under development, and some of the textures are HUGE. I'll grab that and have a go tomorrow. That secondary ASI comes in rather handy :-) It was called the Deck Landing ASI :-) IIRC. Judging by some reports, the Seahawk was probably one of the easiest, if not the easiest, jet to deck land before the current era of auto-land etc. It's certainly easier than I expected - the approach speed is nice and low, and there's acres of deck to aim for - obviously you want to hit the bit with the wires, but at least you ca see what you should be aiming for. I've just had a thought presumably now the ground cache code has been added it would be possible to have a carrier with a ski jump for the harrier model? That opens up another interesting area of deck operations. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
Erik Hofman wrote: Frederic Bouvier wrote: Quoting Erik Hofman [EMAIL PROTECTED]: Are these generic buildings now officilally part of the database? I don't know if it is official, but they are in the database I downloaded recently. Cool, that would make the scenery much more realistic IMHO. I think the problem is that your models are not listed in the database then? If they where they would probably overwrite the default ones (provided they are located at _exactly_ the same location). They don't need to be *exact* as they're linked by ID, not position. I believe Martin Spott has this on his todo list. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
Erik Hofman wrote: BTW. Just for the sake of completeness, the models created by Unknown are all created by me: http://fgfsdb.stockill.org/author.php?id=1 Thanks - this is now updated. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Mathias Fröhlich wrote: Hi, On Freitag 18 Februar 2005 16:08, Frederic Bouvier wrote: I don't know if it is true for gcc, but with MSVC, rtti needs to be activated with a specific compile-time option otherwise the result is unpredictable. I see, this is the first usage of rtti in flightgear. But all those dynamic_casts here are more a 'be paranoid and double check to be really shure' than real application of rtti. So if this turns out to be the real problem we can remove them. gcc normally enables rtti by default. At least gcc 3.4.2 and gcc-4presomething I have installed on my fedora core 3. The gcc-2.95.3 manpage does not tell anything about that. But from the backtrace and the prehistoric gcc-2.95.3 sources I would think that the input pointer was zero which I cannot imagine to happen ATM. Hmm. It's actually GCC 3.3.4. I've just cleared everything out and started building it from scratch - I'll let you know if there's still a problem. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfault from todays CVS
Mathias Fröhlich wrote: From that backtrace: There is exactly one dynamic_cast in this function. In theory it should never happen that the argument to that dynamic_cast is zero. Since I cannot reproduce it myself, can you help me? Could you please apply the attached patch and tell me of some of thouse new cerr output lines triggers? After a rebuild (with your patch): (gdb) run --aircraft=hunter --airport=RCSS Starting program: /usr/bin/fgfs --aircraft=hunter --airport=RCSS [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 18031)] Failed to find runway 28R at airport RCSS [New Thread 32769 (LWP 18033)] [New Thread 16386 (LWP 18034)] [New Thread 32771 (LWP 18035)] [New Thread 49156 (LWP 18036)] Altitude = 18 Temp at alt (C) = 12 Temp sea level (C) = 12.0348 Altitude = 18 Dewpoint at alt (C) = 10 Dewpoint at sea level (C) = 10.0036 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 18031)] 0x0cdf665b in ?? () (gdb) bt #0 0x0cdf665b in ?? () #1 0x in ?? () #2 0x40142974 in __dynamic_cast (from=0xcdf6658, to=0x854ca9c typeinfo for ssgBase, require_public=139573480, address=0x0, sub=0x405d49d0 main_arena+16, subptr=0x38) at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 #3 0x0812233d in FGGroundCache::addAndFlattenLeaf (this=0xb060818, ty=4, l=0x5153f0a8, ia=0xcdf6658, xform=0xb0f0) at groundcache.cxx:159 #4 0x0812281f in FGGroundCache::putSurfaceLeafIntoCache (this=0xb060818, sp=0xb320, xform=0xb0f0, sphIsec=true, down=0xb2c0, l=0x5153f0a8) at groundcache.cxx:260 #5 0x08122d5a in FGGroundCache::cache_fill (this=0xb060818, branch=0x513ffc78, xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) at groundcache.cxx:337 #6 0x08122cf7 in FGGroundCache::cache_fill (this=0xb060818, branch=0xcc15720, xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) at groundcache.cxx:323 #7 0x08122cf7 in FGGroundCache::cache_fill (this=0xb060818, branch=0xcbd7be8, xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) at groundcache.cxx:323 #8 0x08122cf7 in FGGroundCache::cache_fill (this=0xb05c818, branch=0xc3b9b70, xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) at groundcache.cxx:323 #9 0x08122cf7 in FGGroundCache::cache_fill (this=0xb05c818, branch=0xcbb2a10, xform=0xb0f0, sp=0xb320, down=0xb2c0, wsp=0xb2d0) at groundcache.cxx:323 #10 0x08122cf7 in FGGroundCache::cache_fill (this=0xb05c818, branch=0x8ff0118, xform=0xb280, sp=0xb320, down=0xb2c0, wsp=0xb2d0) at groundcache.cxx:323 #11 0x08122cf7 in FGGroundCache::cache_fill (this=0xb05c818, branch=0x8ff0090, xform=0xb280, sp=0xb320, down=0xb2c0, wsp=0xb2d0) ---Type return to continue, or q return to quit--- at groundcache.cxx:323 #12 0x08123075 in FGGroundCache::prepare_ground_cache (this=0xb05c818, ref_time=0, pt=0xb3e0, rad=10.407214164733887) at groundcache.cxx:403 #13 0x08121068 in FGInterface::prepare_ground_cache_m (this=0xb05c178, ref_time=0, pt=0xb3e0, rad=10.407214164733887) at flight.cxx:796 #14 0x081b06c2 in YASim::update (this=0xb05c178, dt=0.81665) at YASim.cxx:202 #15 0x08051d6a in fgUpdateTimeDepCalcs () at main.cxx:167 #16 0x08052759 in fgMainLoop () at main.cxx:431 #17 0x08086232 in GLUTidle () at fg_os.cxx:114 #18 0x4009b1c0 in idleWait () from /usr/local/lib/libglut.so.3 #19 0x4009b8bb in glutMainLoop () from /usr/local/lib/libglut.so.3 #20 0x08054d1d in fgMainInit (argc=3, argv=0xb7e4) at main.cxx:958 #21 0x08051746 in main (argc=3, argv=0xb7e4) at bootstrap.cxx:192 I can't explain the gcc version reported there though, because: gcc -v Reading specs from /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/specs Configured with: ../gcc-3.3.4/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --target=i486-slackware-linux --host=i486-slackware-linux Thread model: posix gcc version 3.3.4 -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Segfault from todays CVS
Most likely connected to the ground-cache updates - as it only seems to affect yasim aircraft. (gdb) run --aircraft=hunter --airport=RCSS Starting program: /usr/bin/fgfs --aircraft=hunter --airport=RCSS [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 1938)] Failed to find runway 28R at airport RCSS [New Thread 32769 (LWP 1939)] [New Thread 16386 (LWP 1940)] [New Thread 32771 (LWP 1941)] [New Thread 49156 (LWP 1942)] Altitude = 18 Temp at alt (C) = 16 Temp sea level (C) = 16.0353 Altitude = 18 Dewpoint at alt (C) = 15 Dewpoint at sea level (C) = 15 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 1938)] 0x0ce8b760 in ?? () (gdb) bt #0 0x0ce8b760 in ?? () #1 0x40142974 in __dynamic_cast (from=0xce8b760, to=0x8548f9c typeinfo for ssgBase, require_public=139557448, address=0x0, sub=0xbfffee80, subptr=0xbfffee8b) at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 #2 0x081241cc in FGGroundCache::get_agl () #3 0x08121ac5 in FGInterface::get_agl_m () #4 0x081b21bb in yasim::FGGround::getGroundPlane () at netChannel.h:85 #5 0x081c1e6c in yasim::Model::updateGround () at Thruster.cpp:5 #6 0x081b140e in YASim::copyToYASim () at netChannel.h:85 #7 0x081b1048 in YASim::update () at netChannel.h:85 #8 0x08051d32 in fgUpdateTimeDepCalcs () #9 0x08052734 in fgMainLoop () #10 0x08086ec5 in GLUTidle () #11 0x4009b1c0 in idleWait () from /usr/local/lib/libglut.so.3 #12 0x4009b8bb in glutMainLoop () from /usr/local/lib/libglut.so.3 #13 0x08054d15 in fgMainInit () #14 0x0805175d in main () -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
