Re: [Flightgear-devel] Garmin GNS 530
Gerhard Wesp wrote: So, one would really need to define a corresponding network interface. This does already exist and is specified in the ``400/500 Series Flight Sim ICD.'', a proprietary Garmin document. It describes the RS232 interface of their _hardware_ simulator units. I guess Bill Stone would give it to interested parties even if they don't buy a simulator unit. Well thanks for the pointer, I am going to contact Garmin yet another time anyway: Another FlightGear user informed me yesterday that there IS already an application that interfaces the original (software) simulator unit with MS FS 200x - this seems to be based on FSUIPC and is called FSGarmin. Indeed, said company did even SELL the interface for about $ 40 US, until they went out of business about 2 yrs ago (?) But before they went out of business they made their software freely available - there's also a support forum for that software at: http://forums.avsim.net/dcboard.php?az=show_topicsforum=178 What surprised me is that Garmin didn't seem to know about the project. So I will gather more information why Mr. Stone didn't mention said project ... This supports rumours that I could find on the web about Micro$oft swallowing the company ... after all they also support some garmin GPS devices ;-) Even more interesting: FSAvionics.com (SimSystems) did even provide an interface for X-Plane some time ago, so depending whether we will be able to get in touch with the original developers it might be interesting to learn about ways to revamp the interface to work with FG. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] README.todo
Roy Vegard Ovesen wrote:
On Tuesday 23 November 2004 17:31, Boris Koenig wrote:
I haven't yet really played with 3D cockpits: what exactly would be
involved in adding such support ?
The support is already there: it is possible to set the view position at
runtime through the /sim/current-view/{x,y,z}-offset-m properties.
You can apply the patch to $FG_ROOT/mice.xml attached to this posting.
http://baron.flightgear.org/pipermail/flightgear-devel/2004-November/032316.html
Ya, thanks - I know, I did follow that discussion, I was merely
wondering where exactly the complexity comes in ;-)
So, whether it would require any significant code changes or whether
it would come down to time-consuming manual trial error means ;-)
What exactly would it make so
complex ?
Actually it is not complex at all, assuming that it is possible to configure
the mouse bindings individually for every aircraft. Then it would simply be a
matter of
* Run FlightGear
* Change the /sim/current-view/{x,y,z}-offset-m properties to find reasonable
values for the limits that the view should be allowed to move.
* Add a mouse binding to the aircraft *-set.xml (I assume) file with the found
min and max values.
* Repeat for every aircraft model. ;-)
I think it was Melchior who mentioned that the min/max values are
specific to certain aircrafts or rather cockpits ?
Taking into consideration that the a3c files are plain text and hence
readable for simple shell scripting, I wonder now whether suitable
min/max values can be derived from any *general* data that's preferably
available in most *.ac files: that way one could use a shell script:
- read in the corresponding data
- determine suitable min/max values
- automatically put the binding stuff into *-set.xml
Again: I don't know anything about cockpit design or 3D design in
general, I would simply *guess* that it should be possible to determine
the dimensions of a cockpit based on the *.ac file ...
Maybe I am making things too simple, though ;-)
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Magnetic Compass
Roy Vegard Ovesen wrote: On Tuesday 23 November 2004 18:05, Melchior FRANZ wrote: No, I take that back. Mouse properties are (like kbd * js bindings) fixed at the beginning. min/max can't easily be changed afterwards, and I don't feel like re-writing the whole input module. Better set the default to +/- 5m. You can include only the required axis bindings in your aircraft *-set.xml file, like this (for the default cessna): [...] This will override the settings in mice.xml, but it will only override the settings that are defined here, so all the existing modes in mice.xml are used. As I said earlier it will be a lot of work to do this to every aircraft model. Please correct me if I am wrong: - There are only two parameters that are a/c specifc: min/max ? - The tags for custom bindings remain basically identical ? If the above is true to some extent, my suggestion for a temporary workaround would be to use an external file that takes care of the bindings, but uses parameters taken from the property tree instead of fixed values: I have done something very similar when I needed to add support for dynamic layer positioning (to be able to use nasal code to re-position layers based on certain actions), by using a property child instead of a fixed value within the x/ or y/ tags. So, one could think about using one general bindings file that's included by the *-set.xml files - that way each aircraft could put its min/max values directly into the right location within the property tree. What do you think, am I still missing the point ? :-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
Durk Talsma wrote: [...] For this and other reasons, I'm currently leaning toward favoring having a separate set of low-polygon count models for AI aircraft. The basic idea would then be to have a directory looking like this: data/Aircraft/AI/ I like the idea of having such a low-polygon repository of standard aircraft files, however they would certainly not only come in handy for the AI traffic part but also for other things like multiplayer functionality. So in that regard it might be worth to think about providing some sort of standard folder for all components that might actually make use of such (reduced) aircraft files - so that this isn't specific to the AI component itself ? which then has subdirectories for each aircraft. Like data/Aircraft/AI/777 and within each directory there are subdirectories for various liveries for example: data/Aircraft/AI/777/American data/Aircraft/AI/777/KLM data/Aircraft/AI/777/United etc etc I think it sounds like a good idea, however I wonder whether *liveries* shouldn't be placed in some central location, specific to certain (fitting) aircraft models - independent of the AI stuff ? So that they can be found in some sort of default location and would hence be optionally available for either: AI traffic and/or user traffic or even other/future components. Then inside each of these livery subdirectories there would reside not only the texture files for the respective aircraft, but also all the traffic files for this aircraft. At least for the multiplayer functionality within MS FS it is nowadays a pretty common feature to allow users to pick a custom livery for their (online) flight - that would be another scenario where AI files would/could be accessed by NON-AI components. So, even without having such or similar support within the near future I would still vote for a central repository that contains the aircraft specific stuff such as the textures/liveries models for LOWPOLY aircraft - after all it would be merely a matter of adding another subfolder... That way those FG components that actually use the LOWPOLY stuff wouldn't need to fool around with the AI sub-directory. The traffic manager would then scan this directory and automatically load all the traffic files it would find here. This way, adding or removing AI aircraft would automatically adjust the amount of traffic generated. Any thoughts or ideas? My first thought concerning the last paragraph would be that it would probably come in handy not to statically use _all_ traffic files that are available within the AI folder but rather make this dependent on some simple property that allows adjustment of the AI traffic complexity and some other parameters. That way, one could have various traffic files without actually having to use them, one wouldn't even need to directly manipulate the files in that folder to control some basic options. Talking about low-polygon aircraft, it sounds like additional work for the aircraft maintainers to really maintain different models for the same aircraft types ? So I wonder what would be involved in artificially reducing the polygon count of an abitrary model at load/processing time, e.g. by using only a certain percentage of the 3D data and ignoring the rest ? If that logic isn't too simple one could still refer to the same (complex) polygon model but only use a subset of the data to render an accordingly reduced model ? - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Magnetic Compass
David Megginson wrote: I understand that there are USB devices that you can wear on your head to control the view in games, and those would probably work in FlightGear, but it would be hard to survive the ridicule from family, friends, and neighbours for wearing one. LOL, that would indeed be very amusing ... must probably look very similar to the BORG on Star Trek ;-) --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting data out of FlightGear
Erik Hofman wrote: Chuck Cole wrote: [...] Any help would be greatly appreciated. If someone could give me some instructions on building the projects myself, I should be able to debug myself, but again, Ive been unable to do so (Ive already gone through the Getting Started documents on the website, but nothing has worked). Currently there is a problem where different platforms, different OS's or even different compilers can get different output due to the fact that structs are used to send data across the network. This can create endian-problems as well as packed/unpacked struct problems. So to be safe you will need to use the same OS, and same compiler for both ends of the connection. This holds also true for most other structure-based interfaces: Depending on what data you need, it is safer to use the Property Tree interface (telnetd/httpd) to exchange data instead - which might require modifying the sources to actually export the required data in the first place. Unfortunately, using the current telnet interface wouldn't be all that efficient when it comes to permanently polling elements in order to check their values - this would create a traffic and processing workload: Because of that I made about 6-8 weeks ago some changes to my local version that allow registering event handlers via the telnet interface, which would be supposed to essentially allow you to use specific instances of telnet connections to register an event so that (network) traffic is only caused based on certain conditions. I haven't yet finalized everything,but it works to some extent - particularly the SGPropertyNodeListener thing wasn't all that obvious to do for me, that's why I am currently using a workaround. All this was mainly meant to be used for a private project, and it would certainly need some reviewing ... But if you think that something like that would be helpful for you, I wouldn't mind to send you my changes as diff patches. It might certainly come in handy for those people who don't want to fool around with the sources too much, but who would still like to use more advanced use of the Property Tree system via the supported interfaces. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Garmin GNS 530 (was: Quick report from AOPA)
This is something that I intended to post already weeks ago - it's likely to exceed the mysterious 1024 byte limit, though ;-) Curtis Olson wrote: A lot of people asked about GPS modeling which we (and FlightGear) really don't do a good job of yet. There are few flight simulators that really fully resemble a GPS unit well ... most of them (have to) make understandable compromises ... Compromises that FlightGear would probably also have to make, so as long as there is no 1:1 solution, it would probably mainly appeal to the gaming audience and not so much to the professional users. I know that Roy has started to work on some gps internals, but it would be cool someday to be able to mimic in flightgear the sorts of gps units people are putting in airplanes these days ... such as the garmin 430/530. ...and then Garmin's GNS series is probably the most advanced stuff !? Anyway, inspired by this, I contacted Garmin and talked to Bill Stone from Garmin's sales departement about different possibilities to support such an effort: Specifically, I was having their Garmin GNS 430/530 *simulator* units in mind, which are freely available on their webpage, i.e. at: http://www.garmin.com/software/simulators/TRAIN530.EXE (does also work fine under Wine - what a rhmye !) :-) Simulators like this one resemble pretty much most (if not all !) of the functionality that the real units have. They are meant to introduce and familiarize with the GUI and usage of the actual hardware units. The emphasis is put on the GPS units themselves of course and not so much on the flight simulator part, so there's only a very simple frontend that allows you to change things like speed, altitude etc. - not much more ! Everything else is mainly about the GPS unit itself... ...probably you're by now thinking exactly what I thought: I figured: if they make the applications (unit simulators) themselves *freely available*, why not ask them what they think about making the sources for that simulator available - in order to let projects such as FlightGear modify them so that they can be used as simulated GPS units WITHIN the simulator, or rather also externally, using data that's provided by a flight simulator such as FlightGear. ...still with me ? :-) However, while I was told that Garmin would *LOVE* to support such efforts, I was also told that this would currently not be an option, mainly because of two reasons: 1) Garmin can only afford to provide resources to projects that provide/create a direct revenue for Garmin and 2) the source code that is used for said simulated GNS units has to remain *closed source*, as it shares MAJOR parts of the source code with the original unit's software - which is also the reason for the high fidelity of the simulated units. I could understand these points and asked Mr. Stone to think about what would be involved in separating the current simulator's structure into two parts: the GUI frontend itself and the underlying software routines, provided by a separate binary library. My line of thought was: One would then be able to use a binary library based on the GNS simulators in order to resemble much of the original unit's functionality - the library would provide a generic interface that could be used by _any_ simulator. Taking into account the enormous level of fidelity of the original GNS simulators, that one would hardly ever be able to achieve by trying to *manually* resemble such an anvanced avionic device, I thought that being able to interface with such a library would still be a real advantage - regardless of the closed source nature of the actual software... However, I was again told that this would not be a feasible option: ...even if they were willing to provide access to the sources, because of the fact that the source code for the unit simulators is currently mainly 16-Bit and seems to run exclusively under WinDooze. So a cross-platform port of such a library doesn't seem likely. Personally, I would still consider it an enormous advantage if there was the possibility to use such a library - no matter, whether windows- specific, or not ... Anyway, since I anticipated already the most likely No I had also directly asked them for their permission to use Garmin photographs, screenshots and extracts from the (VERY extensive) manual(s) - you can take a look into the fine manuals at: http://www.garmin.com/products/manual.jsp?product=010-00182-11 this for the case where FlightGear users/developers would have to try to _manually_ re-create a basic working model of the unit. This is also where the manuals as well as the GNS 530 simulator would come in VERY handy: Simpy because this would create a situation where not only extensive ( 200 pgs) (and illustrated) documenation is available, but also a simulator provided by the manufacturer of the actual hardware unit to familiarize potential customers with the unit's functionality and
Re: [Flightgear-devel] Aircraft directory structure
Curtis L. Olson wrote: However, as things stand right now. We have oodles of references to stuff as ../../../Instruments/hsi.xml etc. If we move an aircraft one directory level deeper (or more) all those relative references break. :-( Well, this is then about relative paths, it could probably already be solved if one added support for standard paths such as $FG_ROOT. Which could mean that the path becomes: $FG_ROOT/Aircraft/Instruments/hsi.xml I think it would take 5 minutes to add support for -automatically defined- environment variables such as: - $FG_AIRCRAFT - $FG_INSTRUMENTS These could all be based on a properly set $FG_ROOT, that way one could simply refer to: $FG_AIRCRAFTS/c172/c172-set.xml or $FG_INSTRUMENTS/hsi.xml Dealing with such path specifications would mainly come down to looking for an initial '$' sign and stripping of everything behind the first slash in order to determine the real path. I'm calling for someone to take on the task of making aircraft more relocatable. If you are mainly thinking about the above problem and my suggestion for a solution is already sufficient, I wouldn't mind to send Erik a corresponding patch. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Garmin GNS 530
Curtis L. Olson wrote: Boris, I got about 20% through your message before I ran out of steam, sounds like you are somewhat related to Erik ;-) but if you talk to Bill again, why don't you propose that they keep their application closed source and proprietary. Having seen the commercial side of life just a bit, there are good reasons for these guys to be careful. I fully agree with what you are saying and if you had managed to get through 30 % of the message that I posted, you would have noticed that I suggested already exactly what you are mentioning: There is low life scum at every corner just itchinig to rip you off, and copy your software and hardware, and do it from some remote country with no laws against doing this. What would be great is if they could add an interface to their gps simulator so that we could send the position from FlightGear. They could keep their application completely closed and proprietary and safe from the scum of the earth, but it would give us enough functionality so that someone could run their simulator software on a 2nd computer and interface it with FG. So, I did suggest adding either a network interface to the simulator or alternatively splitting up the application into a binary library and a GUI part. To summarize what I posted already in the previous posting: they would love to support such an effort but simply cannot afford assigning the required resources for such a modification - simply because this wouldn't create any direct revenue for Garmin :-/ Also, from a programmer point of view you need to take into account that the whole task does not merely come down to feeding long/lat info into the stand alone simulator: The GNS530 is a highly interactive system, it interacts not only with the user/pilot - but also with various other aircraft systems... More specifically: com/nav radio, hsi, autopilot etc. The above would be MINIMALLY requied to actually be able to really use the simulator with FG (or any flight sim) So, one would really need to define a corresponding network interface. Indeed, I made already the corresponding suggestions for an interface - in order to illustrate what would be involved. I think we could come up with some reasons why that would make good business sense to Garmin, and would facilitate using their gps simulator in larger simulation environments where real pilots train, which would feed on itself and encourage these pilots to go out and purchase the same unit for their real airplanes. Well, I went on even one step further: I then mentioned that it would not even be all that unlikely for end users (flight sim people) to be willing to actually PAY for the possibility to really use such a high fidelity simulator with their flight simulator of choice: Personally, I wouldn't mind paying $ 20 US for such a piece of software - taking into account the very active flight simulator community, such a modification might indeed create SOME revenue for Garmin. Getting back to your above comment: indeed, Garmin Ltd. offers already a standalone GNS HARDWARE unit that can be used in fixed base simlators- exactly for that purpose. So from that point of view they might also fear the potential competition that they might create with a interfaceable software simulator of the unit. I didn't yet get detailed feedback about the other alternatives that I offered (some of which I didn't even yet mention on the list), so I will report back about any feedback that I'll receive. If you want to give me Bill's contact info (offline) I would be happy to give him a call and try my luck. Posting that info on the list is probably not a good idea - and taking into account that you keep mentioning your problem of keeping in sync with your inbox, sending you an eMail with that data doesn't really sound feasible either ;-) I would suggest that you take a look at Garmin's webpage for that information (should be there: he's responsible for the sales support and technical inquiries - just look for the name). However, depending on whether you really want to talk directly to him, it might be helpful for you to be up to date about our earlier exchanges. I could either forward all the previous exchanges to you by eMail or try to summarize the most important stuff (ideas offers). Or I could have the president of ATC flight simulators give him a call ... that might grab his attention a bit more??? Well, good luck about that - indeed you can assume that I sounded already pretty convincing ;-) What MIGHT be an option though, if ATC FS -as a company- offered to take care of the actual implementation for an interface ... Taking into account that you mentioned in your AOPA posting that the lack of Garmin GPS device support within FG was an issue on the recent AOPA convention, this might be feasible for them ??? -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED]
Re: [Flightgear-devel] Aircraft directory structure
Curtis L. Olson wrote: I think step #1 needs to be making aircraft relocatable. If I did get everything right, the major problem is that aircraft rely on instruments and other devices that reside in abitrary locations within the $FG_ROOT directory structure. As a workaround it might really be already sufficient to simply use a bunch of variables that simply refer to $FG_ROOT - that way there wouldn't be any messing around with relative paths - rather, FlightGear itself would simply look for a supported environment variable such as $FG_INSTRUMENTS or $FG_AIRCRAFT and would automatically return a corresponding such as $FG_ROOT/data/Instruments or $FG_ROOT/data/Aircraft. This is really no big deal and would essentially allow Aircraft to reside anywhere - right ? Alternatively, one could also decide to use the Property Tree to store the absolute paths, so that these can be dynamically modified at runtime - if necessary. Then step #2 and beyond could be coming up with an a useful/interseting categorization, organization, and filtering scheme. I think this would be mainly about providing additional tags that support specification of the type of aircraft, number of engines, the engine_type, possibly using also data such as weight, pax etc. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft directory structure
Giles Robertson wrote: That's much neater than what I suggested. How many of these variables do we need so that the directory for the a/c does not have to be a subdirectory of $FG_ROOT? I haven't yet really looked into aircraft design/development, so I cannot really comment on the paths that are frequently used... However, after having now looked specifically for various paths in the corresponding files, I think it would mainly come down to providing variables for the following subfolders: - $FG_ROOT/Aircraft (possibly also FDM specific ?) - $FG_ROOT/Aircraft/Instruments (as well as maybe .../Textures) - $FG_ROOT/Aircraft/Instruments-3d - $FG_ROOT/Sounds Folders that don't yet seem to be in use: - $FG_ROOT/Instruments - $FG_ROOT/Engine Probably, using variables for the Fonts and Huds subfolders would also come in handy ? However, as a workaround it might be a good idea to simply support an additional tag within aircraft XML-files that allows for dynamic variable usage, something like: path-alias variable$FG_HUDS/variable value$FG_ROOT/Huds/value /path-alias ...might alredy be sufficient and still allow every aircraft designer to use abitrary -unsupported- paths and variables, still maintaining path integrity. It will then very soon become obvious which additional folders might need to be made available as $FG_* variables by running a simple grep FG_ against all aircraft files. An additional advantage of such a path-alias tag would then be, that it could simply be supported within the preferences.xml file, too. That way any future support for new subfolders would merely come down to adding a corresponding path-alias entry to preferences.xml instead of having to manipulate to source code. What do you think ? - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft directory structure
Lee Elliott wrote: The downside would be that an installer/un-installer would become a necessity. I think that issue was discussed some time ago on the user list ? Probably, it would already be sufficient to simply package aircraft folders as tar archives in order to simplify installation ? If I am not wrong, FlightGear is already linked to libz.a - so basically it supports already dealing with compressed files, at least that's exactly what FlightGear is doing with the navaids database under $FG_ROOT/Navaids. So, it would be pretty straight forward to simply open an archive, look for a specific XML file that describes the aircraft/contents or rather look for the corresponding tags within an XML file such as *-set.xml and display the encountered information, so that the user can choose whether to install (=extract all its contents to a specific location) the (aircraft) archive or not. Actually keeping track of aircraft that are installed in non-standard locations (!=$FG_ROOT/Aircraft) would indeed require some kind of list with those locations that are already in use, so that FlightGear can also check for available aircraft there. Uninstalling is of course a whole different matter, at least taking into account that Aircrafts can theoretically have cross-references to other Aircraft's components - so one would want to preserve such dependencies... That's where RPM comes in ;-) At a minimum, only the paths need be stored, together with the classification tags, but who could resist the temptation of storing absolute a/c components... Well, using a clever loop, one COULD (optionally) make FlightGear validate its aircraft files automatically and make it check for aircraft definition files that are using relative paths instead of available variables for FlightGear's subfolders, so that these could be 'fixed'. Basically, FlightGear would recursively read in all files and check the resulting absolute path for all relative paths - IF a resulting path is equal to a supported short cut variable, it could replace the corresponding relative path. If a relative path doesn't match any pre-defined variables, one could at least change them in a way, so that they refer to $FG_ROOT - which would also result in maintaining dependencies regardless of the actual file's location. Something like that might in come handy anyway, when it comes to 'fixing' the current files ... Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal
Roy Vegard Ovesen wrote: On Thursday 18 November 2004 01:33, Boris Koenig wrote: sure, right - but putting nasal scripts into module tags like in other PropertyList encoded XML files isn't yet supported natively. Also, I don't think Vance wanted to link the Nasal script to a particular action ? I don't want to lecture Vance about how he should go about doing the InHG to mBar conversion, but I think that his Nasal script should _only_ be executed when the altimeter setting is changed. IMHO it would be simpler to use the scale tag. Sounds indeed very reasonable and less complicated if the conversion is the only thing he needs to be done. --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal
Roy Vegard Ovesen wrote: On Thursday 18 November 2004 16:53, Vance Souders wrote: I wish I had a clue about how to add text chunks to the 3d animation code :-| What exactly do you want to do ? Do you want to animate text ? If you only want to add text layers, then there are numerous examples in the instrument files - e.g. the ADF panel is a good example. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nasal?
Ampere K. Hardraade wrote: On November 16, 2004 09:56 pm, Curtis L. Olson wrote: Andy Ross wrote: Sure: http://plausible.org/nasal/flightgear.html This should probably move to the FlightGear site, I suppose. Ahhh, thanks for the url ... it's been too long since the last time I looked at nasal. I can copy it into the source/docs-mini/ directory. Looking through the webpages, I'm still having difficulties understanding how OOP is done on nasal. It's pretty straight-forward and there are even examples at plausible.org: http://www.plausible.org/nasal/sample.html - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Switching from 2D panel - 3D panel - 2D panel (was: Re: [Flightgear-cvslogs] CVS: data/Data/AI)
Giles Robertson wrote: This is probably unrelated, but with the 0.9.6 win32 binaries, if you start up with a large FOV (?90), then until you reset, 3d-cockpits are unusable. I can confirm something that seems related: if I switch from 2D panel mode to 3D panel mode and use the mouse to change the perspective, I don't seem to be able to switch back to the 2D panel mode without having to reset the current 'situation' - tried it with different panels, seems to be a common problem. Can anybody else confirm that ? Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] local build problems with latest CVS
Building yesterday's CVS version, I get the following errors (clean checkout): -8---8---8---8---8---8---8---8---8---8---8---8-- ../../src/Main/libMain.a(fg_commands.o)(.bss+0x0):/usr/local/include/simgear/props/props.hxx:336: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0):/usr/local/include/simgear/threads/SGThread.hxx:129: first defined here ../../src/Main/libMain.a(fg_init.o)(.bss+0x0):/usr/local/include/simgear/structure/callback.hxx:35: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Aircraft/libAircraft.a(aircraft.o)(.bss+0x0):/usr/local/include/c++/3.3/iostream:77: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Cockpit/libCockpit.a(cockpit.o)(.bss+0x0):/usr/local/include/c++/3.3/iostream:77: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Cockpit/libCockpit.a(hud_ladr.o)(.bss+0x0):flightgear/source.orig/src/Cockpit/hud.hxx:318: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Cockpit/libCockpit.a(panel.o)(.bss+0x0):/usr/local/include/c++/3.3/bits/stl_tree.h:288: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Cockpit/libCockpit.a(panel_io.o)(.bss+0x0): In function `SGPropertyNode_ptr* std::__uninitialized_copy_aux__gnu_cxx::__normal_iteratorSGPropertyNode_ptr const*, std::vectorSGPropertyNode_ptr, std::allocatorSGPropertyNode_ptr , SGPropertyNode_ptr*(__gnu_cxx::__normal_iteratorSGPropertyNode_ptr const*, std::vectorSGPropertyNode_ptr, std::allocatorSGPropertyNode_ptr , __gnu_cxx::__normal_iteratorSGPropertyNode_ptr const*, std::vectorSGPropertyNode_ptr, std::allocatorSGPropertyNode_ptr , SGPropertyNode_ptr*, __false_type)': /usr/local/include/c++/3.3/bits/stl_uninitialized.h:83: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Cockpit/built_in/libBuilt_in.a(FGMagRibbon.o)(.bss+0x0):flightgear/source.orig/src/Cockpit/built_in/FGMagRibbon.hxx:35: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/GUI/libGUI.a(gui_funcs.o)(.bss+0x0):/usr/local/include/c++/3.3/iostream:77: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/GUI/libGUI.a(mouse.o)(.bss+0x0):/usr/local/include/c++/3.3/iostream:77: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Input/libInput.a(input.o)(.bss+0x0):/usr/local/include/c++/3.3/bits/vector.tcc:223: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here ../../src/Model/libModel.a(panelnode.o)(.bss+0x0):/usr/local/include/c++/3.3/bits/vector.tcc:223: multiple definition of `color_nodes' ../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 -8---8---8---8---8---8---8---8---8---8---8---8-- - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] local build problems with latest CVS
Boris Koenig wrote: Building yesterday's CVS version, I get the following errors (clean checkout): [...] Please disregard this for the moment, it seems to be building now - obviously I had to explicitly specify the other SimGear version (keeping different versions of FG, SimGear etc. around). Will report back when things are working (or not). Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Switching from 2D panel - 3D panel -2Dpanel (was: Re: [Flightgear-cvslogs] CVS: data/Data/AI)
Curtis L. Olson wrote: Giles Robertson wrote: I think that's a result of the standard problem that if you move the view with the mouse in 2d panel mode, you can't see the panel, and it can be very difficult to get back to the original location; resetting resets the viewpoints back to normal, and the panel reappears. would it then be sufficient to reset the panel-location per default when switching back to 2D panel mode ? Do you get any actual graphical corruption (which is what I get - all triangles seem to be drawn to infinity - everything comes from a point at the centre of the screen) To be honest: I don't care for such problems anymore ;-) With the ATI Rage 128 that gives me a better framerate than my nvidia GeForce4 I keep seeing graphical corruption every now and then - but mostly it's either cockpit-specific (e.g. A320) or specific to certain environment settings, so I simply try to avoid using those features that seem to cause such problems. In mouse-pans-view mode, you can simply left-click to recenter the view, then you can get the 2d panel back. As it stands, the 2d panel isn't displayed when you pan the view. Thanks, I will try that - but I think it would make sense to recenter the view automatically when switching back to 2D mode ? - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal
Vance Souders wrote: I'm working on a new cockpit for the T6; the T6's altimeter displays barometric pressure in both inches HG and MB. I want to add a small amount of script that converts from the HG reading in the property tree to MB for the gauge (I need this for the texture translation). After looking at the docs, it's not clear to me where this code should reside. Can I put script code directly in the gauge's XML file (I've tried this and it doesn't seem to work)? Actually, the instrument definitions themselves cannot yet contain Nasal statements, at least that's what I learnt about 3 weeks ago when I made a quick stab at another new instrument, I was also somewhat surprised but found my assumptions confirmed when I looked into the source code - so, in that regard FG is currently somehwat inconsistent, because it doesn't seem to support Nasal scripts in any PropertyList file. As a workaround you could simply place that script into a separate nasal module and put that into the Nasal sub folder, so that it gets automatically loaded - you can then refer to the code in that module by using the file's name (without extension) to access functions/objects. For debugging purposes it might be helpful to use print statements in order to see whether a function is actually called. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] the ATC thing (was: Re: OT: Another FGFS PPL :-D)
Ampere K. Hardraade wrote: Speaking of multiplayer support, whatever happened to the online ATC thing? There's currently a group of 6 people who are collecting ideas and suggestions to come up with a protocol draft and a corresponding cross-platform library ... Some of the development has been slowed down because it was not entirely clear what cross-platform networking library should be chosen as the underlying system - simply because the Torque Network library isn't as cross-platform as most of us had initially expected. That's why some of us spend some time looking for viable alternatives and checking the possibilities of these out - however, it turned out that openTNL project would by far be the most versatile and usable one, also with regards to its pretty small footprint - compared to other cross-platform networking libraries like ACE or ICE that require either an enormous amount of build space and time or depend on numerous external libraries ... Anyway, meanwhile we got in touch with the developers of the OpenTNL project nd we were informed that the cross-platform limitations are caused by platform-specific assembly-macros - but it would currently be considered to port this over to a C++ template based approach. While I haven't talked to anyone on the ATC project for a couple of days now, my perception is that things are still 'progressing' to some extent - the problem being mainly the lack of (spare) time of the people who are involved - which probably sounds familiar to you ;-) Hope that cleared things up a bit Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nasal?
Andy Ross wrote: Curtis L. Olson wrote: Is there any documentation that explains how the nasal scripting system is integrated into FlightGear? I looked a bit, and can't find anything. Sure: http://plausible.org/nasal/flightgear.html This should probably move to the FlightGear site, I suppose. I suggested already some time ago that it would be nice to have all ;-) the Nasal docs available within $FG_ROOT/data/Docs ... As someone who had to 'learn' Nasal and how it interacts with FG I would have found it useful to have such info directly available within the base package - like all the other docs. Also, I assembled some simple howtos for myself about how to do certain things with Nasal, it would not be all that complicated to extend such a howto and possibly add some real life examples about FG-integration and make such files then generally available. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear on Mac OS X
Arthur Wiebe wrote: Another way to do it which is what I did was use the following command: locate plibfnt It returned: /fgfs/lib/libplibfnt.a /Users/myuser/FlightGear/plib/src/fnt/libplibfnt.a (s)locate doesn't really browse your file system, as 'find' would do - rather, (s)locate runs a query against a simple database, if that database is not in sync with your local file system, it can very well happen, that (s)locate returns results that don't resemble the actual situation on your hard disk, hence it is recommended that you either use 'find' directly or simply run a 'updatedb' in order to synchronize the database with your file system - which may take quite a while, depending on your file system structure. Also, you won't have to do a manual search for any references of 'load', you can easily use 'grep' for that, too - something like: nm library.a | grep -i font | grep -i load | less would return all results that contain a font AND a load reference, limiting the search in such a manner would probably also make the piping to less superfluous. Using some clever sed'ing could even take care of automatically comparing object file exports and library exports. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear on Mac OS X
Just a quick note as I am catching up on all this: Arthur Wiebe wrote: Now FlightGear itself is another story. I had to upgrade automake in order to run the autogen.sh script successfully. While I wouldn't consider this to be a very common problem, it would probably not be a bad idea to add a simple version check to the autogen script, something like `autoconf --version | grep $REQUIRED_VERSION` That way one could at least display a remark whenever the autotools package doesn't match the required version. But I am really not sure how many other people have had problems because of the autotools being out dated. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] X-Plane on Linux
Jon Berndt wrote: Looks like X-Plane is finally going Linux - not just the support apps, but the whole thing. I guess there's even a beta available. Anyone try it, yet? I think it's only a demo ? On the other hand the description of the upcoming v. 8.0 release sounds indeed VERY promising: http://www.x-plane.com/v8descrip.html So, I am about to download it - unfortunately the download is only offered as BitTorrent (shared) down-/upload so far: http://bt.markal.net/bt/torrents/XLIN800B15.tar.bz2.torrent Some of the changes or rather announcements sound really like damn good advertisement - what really surprised me when I read the changelog: ...it seems that Austin Meyer has just recently discovered the arts of OOP and using the STL with C++ - maybe I didn't get something right, but my impression is really that SO FAR, X-Plane was merely using procedural design :-O ? If that's true, it's even more amazing that he managed to write such a complex application using merely procedural techniques... Obviously, he was just recently shown how to do OOP - taking into account that Austin Meyer has written X-Plane for a long time all by himself, it's really amazing how a one man show can yield such astounding results. Now that X-Plane is not only becoming OOP but also other developers get involved, one can probably expect a lot of cool stuff from them within the near future. FlightGear is probably lucky because X-Plane isn't open source ;-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Plea for help: geometry/trigonometry problem
David Megginson wrote: On Wed, 3 Nov 2004 15:36:33 + (UTC), Martin Spott [EMAIL PROTECTED] wrote: Explaining in pictures is easier than dealing with single-line- equations :-) We'll see, Multiple, sequential equations are welcome as well. Anything, really ... Could you go into detail about what kind of compass/error we're talking ? Is it a conventional whiskey compass, so I assume no gyro driven instrument ? I mean how is it modelled or what is the cause ? That way it might be easier to come up with a formula/solution... My first VERY simple *guess* would be that it might be because of an imbalance in inertia of a compasses moving parts as soon as the pitch changes accordingly. --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] St. Elmo's Fire
David Culp wrote: [...] If I change the time-of-day to something darker the panel code darkens and redens everything, which ruins the effect. [...] That's exactly something I have also observed, in particular with self-illuminating instruments - something like a basic LCD or TFT shouldn't be subject to general panel darkening, as it has its own illuminiation - I looked into David's (Megginson) sources and it seems one would either need to define areas on the panel/screen that aren't darkened, or -preferably- (in my opinion) provide an additional parameter to layers that are not subject to panel-darkening. And for your St. Elmo's Fire it would probably be benefitting if you could add some diffuse effects, too - I think that's beyond the capablities of the current XML-instrument code !? My questions are: Can the instrument darkening/redening be turned off per-instrument? currently not - I'm afraid, at least that's the conclusion that I came up with ... Should we have a seperate screen-drawing subsystem that draws windscreen effects, like St. Elmo's Fire, rain, snow, glare? I like the idea - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] plib CVS compatibility
Arthur Wiebe wrote: I tried, the problem is that it doesn't build on OSX without fixing the source code in some areas, which I tried but it didn't work. The only way I could get it to build was to get plib from CVS which seems to work. If any FlightGear dependcy is taken from CVS it's often a good idea tosimply grab the other dependencies from CVS, too -in fact it is even a requirement for FlightGear(devel)/SimGear(devel). Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] List of FG materials and textures
Paul Surgeon wrote: Ok this is just a rough idea what do ya guys think? I think that a variation of what you described should be relatively straight-forward to do, at least to get some basic support for season-based textures going ...basically it sounds similar to what has been mentioned already in earlier discussions about this topic. So, one could still later on refine these things - however, while supporting the corresponding tags would be a no-brainer, one would still have to look into the current texturing code in order to be really able to assess how feasible it would ultimately be to get the thing easily done. Also, personally I would consider it more plausible to either provide the season(s) for a texture either as a parameter - or simply as a sub/child-node, instead of using a separate tag. But that's then probably really only a cosmetical factor ... But such a dynamic backend option would certainly be interesting to have. The ESRI data sets do also seem provide data for different seasons if I remember correctly, so one might even be able to use some of that for that purpose, too... P.S. Oops that took a few more lines to explain than I anticipated. :P I can reassure you, that your posting is certainly not the longest one this mailing list has seen - don't ask me how I come to know that ;-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Automake warnings
Paul Surgeon wrote: I noticed on my system and someone else's that when running autogen on SimGear or FlightGear one get's lots of automake warnings like this : acinclude.m4:28: warning: underquoted definition of wi_EXTRA_LDIR It does it with automake 1.8.3 and 1.9 It looks harmless to me but should we worry about it? it's not a FG-related problem, more about the (recent) autotools package becoming stricter with its macros, that's why NEW versions complain about macros definitions that don't fullfil the latest requirements - this behaviour was already brought up a couple of times here - and on the user list: http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26642.html http://baron.flightgear.org/pipermail/flightgear-users/2004-August/008341.html (You can find more ...) Additionally, you can find more information by googling for underquoted definition - you'll see that it is not really a problem right now. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Development of a virtual sports programme
Florian Schießl wrote: Hi, moin ! Thanks for the fast answer, that helps me. :) you're welcome :-) So, that way you could incorporate all information that is required - in case that you should need to use external variables, make sure to also check out the httpd/telnet interface (again: 'fgfs --help --verbose') in order to see how to start FlightGear in a manner so that it exports its property tree via either a web server or a telnet server. (Or even both) Can I change the values of the properties over this external connection ? I think that's exactly what I wrote: you can change/add properties quite easily - just give it a go: ./fgfs --telnet=port so: ./fgfs --telnet=5500 Would start up FlightGear using port #5500 for the telnet server. Then you can simply connect to FlightGear by using: telnet localhost 5500 As soon as you're connected you press once enter and then you'll have a basic shell that enables you to use certain commands, as well as fgcommands - in order to get a summary about what can be done simply type help [ENTER] And you'll see a listing of currently supported commands. You'll probably mainly want to use the set/get commands, though - possibly you'll also want to switch FlightGear into raw mode, so that it does not create any ir-relevant output: that makes it easier to use a script or program to parse FlightGear's responses, you can switch to the raw (data) mode by using: data [ENTER] In order to get a (full) prompt again, you can use: prompt [ENTER] And make sure to consult some of the docs under $FG_ROOT/data/Docs ! Some of what you want to do (XML dialogs, XML panel/instrument design, Nasal scripting, aircraft design) is at least acceptably documented - which is not the case for all of FlightGear's functionality/features, so, consider yourself lucky so far :-) For your project you would most likely have some kind of sensors attached to the body of the pilot ? These sensors will probably feed in data to some computer that processes then what kind of action/maneuver is intended - so you would basically first process the sensory input and then you could for example use the telnet interface in order to change FlightGear's internal values accordingly: set /path-to-value/speed-in-kts 10 or set /path-to-value/vertical-speed-in-fpm 50 Depending on how exactly you want to model the bird flight model, you could also directly feed these values into a FDM - if you should end up implementing that part of your project by doing some C++ coding you could simply access the above property tree paths by using something like: SGPropertyNode * bird_speed; bird_speed = fgGetNode(/path-to-value/speed-in-kts,true); Using methods of SGPropertyNode like getIntValue() or getStringValue() you could then retrieve the contents of a particular node and use these values then for your simulation. So I would first agree on what exact bird you want to model - and then I would probably not try to mathematically model a bird but rather split up the potential maneuver of YOUR bird so that you can feed in the maneuver directly ... I dont need a specific bird. The user should be able to steer easily but still using his muscles. It should be sports after all. The simulation is merely a motivation. Arnt brought up an interesting idea - pedals are pretty easy to deal with, because you could use a simple linear algorithm to determine the speed of your virtual aircraft - also it's probably going to become a lot easier concerning the underlying FDMs if you should decide to model a pedal-driven aircraft instead of a bird, that would actually create lift by moving it's wings upwards/downwards... So, depending on HOW static the outline of your project is currently, you might very well be able to save some time by skipping the bird idea and deciding to model a pedal-driven aircraft, as was mentioned before there was really such a thing and it did even fly :-) You would probably be able to find the general specs of that aircraft on the web, then you could create an aircraft model (3D) and start implementing the FDM logics - that way you should ultimately have to do less coding and thinking because you would mainly only add another aircraft to FlightGear - something which has been done dozens of times and works already quite well. For the hardware side of things you would probably only need some simple old bicycle, where you could simply use the dynamo (= the created power) to calculate how much thrust is created, that value would then need to be converted into the right format and fed into FlightGear/the FDM. Likewise you would only have minimal hardware requirements for the steering part, mainly you'd only need to make the handle also move in a forward/back motion - adding sensors for both axes sounds trivial, too. YES, it would propably be very interesting to meet a confused pigeon at FL350 :-) lol. :) I consider the confused pigeon to be the logo
Re: [Flightgear-devel] a sweaty pigeon at FL350 is a doomed pigeon ... (was:Development of a virtual sports programme)
[OT] Arnt Karlsen wrote: On Fri, 29 Oct 2004 23:50:01 +0200, Florian wrote in message [EMAIL PROTECTED]: I dont need a specific bird. The user should be able to steer easily but still using his muscles. It should be sports after all. The simulation is merely a motivation. ..get evil; model say a Gossamer Condor or whatever these pedal powered Channel crossing planes were called, _truthfully_, including the pedal power to power the sim computer at 300 - 450W or whatever it was. ;-) that sounds certainly like a lot of fun - I remember an expo some time ago where you were allowed to (try to) power a bulb, fan, radio or even TV by using merely pedal power ... Nobody managed to get the TV working, though :-) YES, it would propably be very interesting to meet a confused pigeon at FL350 :-) lol. :) I consider the confused pigeon to be the logo for the software.. ;) ..make it sweaty. ;-) ...at that altitude that sounds a bit nasty, or does it have anti-icing equipment onboard ? ;-) ...of course Erik's penguin could possibly be able to deal with the icing part, on the other hand how do get it up to FL350 - probably only by dropping it from something like FL1000 ? :-) At least we wouldn't have to care for the (lack of) lift anymore, I think a penguin's body would probably make for a good illustration of the lifted wing body concept ;-) -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Textures
Paul Surgeon wrote: Screen grabs here : http://surgdom.hollosite.com/flightgear/flightgear.html Do people want textures like this in FlightGear? I like it ! And I think such images would probably be nice to appear within the screenshots section, likewise for the recent 747 livery - it's all about impressing people :-) ...and still it would be good if one could find a compromise to enable people to customize such settings - so that you can choose what kind of textures to use. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] XML validation (was: submodels - config file)
Erik Hofman wrote: David Culp wrote: Unable to read submodels file: /home/dave/FlightGear/data/Aircraft/FW190/submodels.xml Did you already load the file in your browser to see if it's XML compliant? I would like to suggest adding an optional --validate-xml option to FlightGear, while this would be mainly used by developers, it could certainly reduce the amount of debugging efforts in that regard. During my instrument design efforts I noticed a couple of problems related to (accidentally) invalid XML files - e.g. FG starts happily (and that takes some time !) just in order to tell me *then* that there were parsing errors in some XML file ... What surprised me a bit: I couldn't even use the menubar after a parsing error in an instrument definition file ... (No, I didn't touch the menubar.xml file=) One would probably only have to tell expat to optionally validate the xml files that it is supposed to parse. We could agree on specifying different validation levels, so that one could optionally only validate the fundamental files like preferences.xml, menubar.xml or additionally also make FlightGear check all XML files within the Aircraft sub-folder of a chosen aircraft. What do you think ? And before anybody yells at me: As long as others also think that it might be useful, I would not mind looking into it. -- Boris P.S.: Is there any way to make FG reload its textures (i.e. panel/instruments) - I didn't seem to find one, and if I understood the sources correctly, each texture is only loaded ONCE, without the possibility to reload it ? If that's true, I would also like to see a new fgcommand to re-load textures: it's a bit awkward during panel/instrument design to have to restart FG only to see the changes take effect, I think the panel/instrument/aircraft desginers probably agree ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Development of a virtual sports programme
Florian Schießl wrote:
I make my master thesis about the development of a virtual sports game.
The user will be hanging in some sports machine. He can move his arms
and feet and fly like a bird. Sensors pick up the movement. He can fly
through a virtual reality that is represented on a computer display.
lol...when dreams come true - sounds like fun :-)
I develop the simulation software. I want to use Flight Gear as a basic
structure. I have some questions regarding your oppinions what the best
place or method for implementeing some features is.
I will pulbish everything under the GPL. And It will still be obvious
for the user that FlightGear is the basic software. I dont want do
change stuff in the source code of FlightGear, so that it is a real
addon.
There is currently no such thing as a plugin (sub)system, so I'm
afraid you will very will have to change a couple of things within
FG sources - either by doing it yourself or finding someone who
can help you to do that.
Your best bet would probably be to described very detailed what
you want to do so that you get pointers from the right people
into what sources you should look and what should be implemented
where/how.
But of course, for some features written code could be useful for
Flightgear. The property system seems to be very powerfull, but I havent
still found out all details. Maybe u can help me.
1. GUI question.
I want to have a startup that is in the middle of the screen where the
user can choose the scenarios he wants to do. I dont need the menu bar.
You can disable the menubar by checking the property path /sim/menubar -
where you can change the visible property in order to hide it.
The user needs to input some dates like weight, height, gender.
Can I start FlightGear with some start parameters that would allow that ?
IF I understood you correctly, then you need some simple GUI to allow
the user to enter specific values ?
You could make such values either available by using a command line:
--prop:name=value
for example:
--prop:/stoned-flying-bird/user/weight-kgs=150
or
--prop:/stoned-flying-bird/user/height-cms=120
or
--prop:/stoned-flying-bird/user/gender=metro
These values will the be made available within the property tree
using the specified path/node - so you can then access these
values within the prop tree.
Accessing them can be either done using plain C++ or using the
FlightGear's integrated scripting language Nasal that allows
you to use getprop/setprop functions in order to deal with the
property tree.
For testing purposes you can simply take any of the above command
line parameters, start up FG using them - and then check the
property tree by using the property tree browser: you'll see
newly created paths/values within the property tree.
If you'd prefer to use a GUI instead of the above command line
parameters in order to put values into FlightGear's property tree
you could on the one hand write a simple XML dialog with a couple
of edit fields and an okay button - or alternatively you could
also use Nasal (not really an advantage in most cases right now).
In order to check out how XML dialogs are implemented, check out
$FG_ROOT/data/gui/dialogs
where you'll find many XML dialogs - also there's documentation about
that under $FG_ROOT/data/Docs available.
2. Panels
I would need some panels that show stuff like burned calories or flown
meters. I also need to keep some kind of Highscore board. This should be
easy with the XMLs ?
Yes, you would create custom panels and instruments that are driven by
custom values from the property tree - so essentialy it might already be
sufficient to simply use two differently colored texture files (*.rgb
in SGI format) and transform them accordingly.
The actual calculations (kcal/hr etc.) could be done using a Nasal
script that you put into $FG_ROOT/data/Nasal - every Nasal file
that you put there is made available as a separate module.
So, you could have a simple function such as:
cal_consumption = func {
weight = getprop(/stoned-flying-bird/user/weight-kgs);
height = getprop(/stoned-flying-bird/user/height-cms);
age= getprop(/stoned-flying-bird/user/age);
gender = getprop(/stoned-flying-bird/gender);
BMI = weight / (height*height);
if (gender ==male) {
# do calculations for men
}
else if (gender == female) {
# do calculations specific to women
}
}
So, that way you could incorporate all information that is
required - in case that you should need to use external
variables, make sure to also check out the httpd/telnet
interface (again: 'fgfs --help --verbose') in order to
see how to start FlightGear in a manner so that it exports
its property tree via either a web server or a telnet server.
(Or even both)
3. I need a new flight model, that is similar to a birds flight model.
Is there something like it or can i bend one of the existing to
Re: [Flightgear-devel] GenAirports logic/process
Paul Surgeon wrote: Please don't tell me that the source code is self explanatory - not everyone has an IQ of 150 to understand what Curt coded or the patience to step through the code with a debugger. Heck, even I battle to understand my code when I see it a few months down the line. ;-) lol, the above passage would definitely make for a good signature !! :-) -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal multiple contexts (was: AI carrier)
Hi Andy ! Thanks for answering my Nasal inquiry several weeks ago, regardless of your vacation - Hope you've had a good time in Japan ;-) Andy Ross wrote: I'm honestly looking for something to get me back into FlightGear development. I can do the YASim integration if you guys have an interface ready for the ground velocity and arrestor wire position values. Personally, I would find it VERY useful if Nasal could run recursively, respectively with several contexts: I am now at a point, where timers simply won't work anymore for every case, and some other things that I wanted to do, like dynamically updatable GUI controls would also be easier to implement if there was a way to use a callback mechanism with Nasal or at least if I were able to call Nasal Nasal code from within Nasal scripts. I did look into your code, but to be honest: the odds to get it done seem to be A LOT better if you tell me what would be involved, I simply lack the understanding of how exactly you implemented all this. So I really don't know how long it might take to get that done. But even if you shouldn't decide to take care of that within the near future, I'd like to get some feedback about the feasibility of making Nasal run with multiple contexts, so that I can assess whether it makes sense to really dig into it or not. Thanks - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Instrument/Panel Design (zooming instruments)
Hi ! I was going to give implementing a simple transponder-like instrument a go, as there doesn't seem to be one yet (?) While I browsed through the Aircrafts folder in order to look into the file format I wondered whether it's also possible to specify an enlargement/zoom transformation upon mouse events. Particularly, I wanted to optionally make certain instruments zoom when I either move the mouse over a specific region or upon clicking on a hotspot region. Simply because it's partially kind of hard to really READ the instruments/panel - that way I might not have such a bad time when trying to actually hit a hotspot ;-) So, being able to optionally make instruments or panels zoom in would also increase the potential instrument density for the whole panel, while everything would still be comfortable to use ... If there is a way to zoom in on a certain event I'd like to get some pointers or even examples :-) Another question is whether it's currently possible to make FlightGear change its default cursor whenever the cursor passes over a particular hotspot region, so that it is more obvious that there IS indeed a functionality connected to a certain hotspot - I found it quite hard to tell where exactly it is that I need to click in order to make something happen ... --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument/Panel Design (zooming instruments)
David Culp wrote: Look at the T-38 or OV-10, which have a radar instrument that can appear in two different states. In one state it is minimized and looks like a button, and in the other state it is maximized. You could use the same XML code to make an instrument appear unzoomed or zoomed. Thanks David, I was hoping to find something like that - my next question would be whether I can parameterize the process of changing the dimensions of an abitrary instrument/panel by using a corresponding Nasal function - so that I don't need to manually implement the resizing functionality, but could rather simply provide a nasal function with the property path to the instrument that is supposed to be (temporarily) resized. The function itself wouldn't be the problem, rather I wonder whether each instrument's properties (dimensions, position etc.) are also made available globally within the property tree so that I could theoretically modify them using something like: setprop(/instrument/gauge/width,100); setprop(/instrument/gauge/height,100); So that I would ultimately only need to put this into a wrapper function that I can then call using the action tag. Also, is it (currently) possible to deal with mouseover-events using the XML files ? --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aerial images
Paul Surgeon wrote: When I fired up FlightGear a week ago I noticed that the textures looked very dry and brown to me. I thought San Francisco would be a lot greener and reckoned it was just the guys who created the textures. Tonight I was thinking of making some greener looking grass textures for the airports however when I did some searching around USA on Terraserver looking at colour photos (not BW) I saw that USA looks dry everywhere including places like Georgia, Washington DC and Chicago. I've yet to find a nice green photo. Do the aerial photo, surveyor guys pick the dry seasons to do all their work in or is USA really as dry as it appears on Terraserver? Seems a little odd to me and I'm curious. :) Is it that important at all ? I mean, it's like Erik said: usually the green areas aren't even green most of the time ... so, essentially green imagery wouldn't be suitable for other seasons anymore ... Unless of course one intends to apply some basic color-based filtering: Of course, having colorful imagery in the first place would theoretically enable you to try to approximate the color-changes per season based on the simulator settings, and possibly also country-/region specific profiles - maybe even based on contributing factors such as the relative position of rivers/lakes in the proximity ;-) One would then need to tell FlightGear in what season an image has been created, so that it can generalize spring, summer, fall and winter settings by deriving corresponding changes in color strength, and -density ... sounds a bit like rocket-science, doesn't it ? ;-) -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] [PATCH] classifying development status of aircraft extending fgrun
Paul Kahler wrote: I'm not big on XML (done HTML before) but this: maturityalpha/maturity doesn't seem right. I would expect something more like: modeltag maturity=alpha /modeltag You are right - and wrong, actually it doesn't matter at all, logically you are of course somehat right, personally I would also often use parameters where FlightGear uses separate tags, but on the other hand it's definitely easier the way it is done now, taking into account that an XML file is parsed recursively to be put into FG's global property tree. You'll notice that only very few of FlightGear's XML files really use parameters ... Where modeltag would encompase the whole model definition. Again, I'm not really familiar with just how bloated XML is supposed to be it's not XML's fault - it's just a matter of the exact implementation, look into any of the aircraft XML files, you'll see a lot of stuff that you'd normally expect to be a parameter of a tag rather than a separate tag, personally I did also consider this somewhat confusing in the beginning. but if this is how you define a property of something it seems more wasteful than I ever thought. you can do it either way, XML itself doesn't care whether you store data separately or as a parameter. An even more complex thing would be to allow: modeltag bunch of stuff... maturity = alpha less developed part of model /maturity /modeltag Again, I'm no authority and I don't even know if this second thing makes sense in this context. it's a matter of convenience - and also of habits, I'd say: FG offers the functionality to easily obtain a particular node, because that's exactly what FG is doing all the time, while doing it the other way would seem to make more sense, it would not be conventional in FG terms ;-) But again: this was just meant as a suggestion - in case that it should be accepted to become a temporary solution for FG, I'd recommend to let me refine it anyway - e.g. I was already told that the maturity levels wouldn't be adequate ;-) -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] [PATCH] classifying development status of aircraft extending fgrun
Ampere K. Hardraade wrote:
On October 20, 2004 10:05 pm, Boris Koenig wrote:
Personally, I'd hence still prefer getting everything and being able
to tell FlightGear what maturity level I require for all aircraft
minimally.
I'm sure your method of showing maturity of aircrafts will come in handy, but
we *really* have to drop that download size.
Well, everybody who wants to give it a try can now do so easily: I've
made a quick stab at it this morning, because I was messing around with
the corresponding files anyway.
After applying the attached patches (based on latest CVS) you should
have a new option available within your version that should also
show up using fgfs --help, the syntax is:
fgfs --min-maturity={level} --show-aircraft
whereas level can be anything between
pre-alpha,alpha,pre-beta,beta and done
Of course running something like
fgfs --min-maturity=alpha --show-aircraft
should not return any aircraft right now, as none of the
current aircraft definition files in your base-package is using the
required
maturity/maturity
tag - but you can easily give it a try by adding something like
maturityalpha/maturity
to abitrary aircraft ($FG_ROOT/data/Aircraft/.../*-set.xml) files.
The tag should be placed as a sub-tag within sim - so directly behind
the description tag would be just fine and straight-forward.
Essentially, this is a quick hack, but actually it could already turn
out to be useful:
At least as soon as most aircraft have been classified based on their
development status - that way one could easily modify preferences.xml in
the base package to make --show-aircraft use only beta or done
aircraft by default.
Everything can still be easily overriden - using either said new option
or directly by using the property node /sim/aircraft-maturity-level
Also, I would not mind extending the whole thing a bit to provide some
more information, possibly directly within fgrund was has been discussed
before - that way one could also provide a detailed description within
the aircraft selection dialog.
-
Boris
--- preferences.xml.origFri Oct 22 09:20:52 2004
+++ preferences.xml.new Fri Oct 22 09:10:41 2004
@@ -292,6 +292,9 @@
enabled type=booltrue/enabled
!-- scenarioaircraft_demo/scenario --
/ai
+
+ !--to provide a default value that shows ALL aircraft regardless of development
status--
+ aircraft-min-maturityall/aircraft-min-maturity
/sim
--- options.cxx.origFri Oct 22 10:05:12 2004
+++ options.cxx Fri Oct 22 09:43:11 2004
@@ -1333,6 +1333,7 @@
{nav2, true, OPTION_FUNC, , false, , fgOptNAV2 },
{adf, true, OPTION_FUNC, , false, , fgOptADF },
{dme, true, OPTION_FUNC, , false, , fgOptDME },
+{min-maturity, true, OPTION_STRING,
/sim/aircraft-min-maturity, false, all, 0 },
{0}
};
@@ -1683,9 +1684,29 @@
#endif
}
+//CHANGED: a simple function to return an integer depending on the position
+//of the maturity string within the array in order to determine the hierarchy.
+unsigned int getNumMaturity(const char * str)
+{
+//a simple char array to hold supported maturity levels (vectors would be overkill)
;-)
+//changes should also be reflected in $FG_ROOT/data/options.xml
+//$FG_ROOT/data/Translations/string-default.xml
+
+const char levels[6][10]= { pre-alpha,alpha,pre-beta,beta,done,0};
+
+
+for (int i=0; i(sizeof(levels)/sizeof(levels[0])-1);i++)
+ if (strcmp(str,levels[i])==0)
+ return i;
+
+return 0;
+};
+
+
static void fgSearchAircraft(const SGPath path, string_list aircraft,
bool recursive)
-{
+{
+
ulDirEnt* dire;
ulDir *dirp = ulOpenDir(path.str().c_str());
if (dirp == NULL) {
@@ -1720,28 +1741,60 @@
}
SGPropertyNode *desc = NULL;
+ //allow for specification of an additional maturity tag within the xml file
+ SGPropertyNode *maturity = NULL;
+
SGPropertyNode *node = root.getNode(sim);
if (node) {
desc = node-getNode(description);
+// if a maturity tag is found, read it in
+if (node-hasValue(maturity))
+ maturity = node-getNode(maturity);
}
char cstr[96];
+ //additionally display maturity information where it is available
+ char maturity_level[12]=;
+ strcpy(maturity_level,(maturity) ? maturity-getStringValue() : );
+
if (strlen(dire-d_name) = 27) {
- snprintf(cstr, 96,%-27s %s, dire-d_name,
- (desc) ? desc-getStringValue() : );
+ snprintf(cstr, 96,%-27s %s %s, dire-d_name,
+ (desc) ? desc-getStringValue() : ,
+ maturity_level );
} else {
- snprintf(cstr, 96,%-27s\n%32c%s, dire-d_name
Re: [Flightgear-devel] Re: [Flightgear-users] [PATCH] classifying development status of aircraft extending fgrun
Oops, I forgot to add the patch for options.xml
--
Boris
--- options.xml.origFri Oct 22 10:01:51 2004
+++ ../options.xml Fri Oct 22 08:50:27 2004
@@ -420,6 +420,42 @@
/option
option
+ !--in order to allow users to specify a minimum development status for aircraft,
+ this option requires the aircraft *-set.xml files to contain one additional tag
+ within the sim tag:
+
+
+ maturity/maturity
+
+ it should hold any of the following status strings: (may be subject to change)
+
+ pre-alpha - for all pre-alpha version aircraft
+ alpha - for all alpha version aircraft
+ pre-beta- for all pre-beta version aircraft
+ beta- for all beta version aircraft
+ done- for all aircraft that are (relatively) 'done'
+
+ ('all' is also supported, but simply bypasses the new stuff)
+
+Aircraft definition files that don't contain a corresponding maturity tag will
+still be dealt normally with, however they are not going to show up if the user
+provides a minimally required maturity level, the same applies for mis-spelt or
otherwise
+unsupported maturity levels.
+
+The revamped fgSearchAircraft() function in $FG_SRC/Main/options.cxx will now by
default
+look for a value within the property tree (/sim/aircraft-min-maturity) - this
node will hold
+the value that's provided via --min-maturity=level, in order to be able to rely
on a standard
+value for this node, it will by default be set to all, so that
fgSearchAircraft() can still
+easily deal with conventional aircraft definition files that do not contain the
new tag.
+
+--
+namemin-maturity/name
+arg{pre-alpha,alpha,pre-beta,beta,done}/arg
+descriptionstrings/min-aircraft-maturity/description
+brief/
+ /option
+
+ option
namefdm/name
argname/arg
descriptionstrings/fdm-desc/description
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw and choice of images from terraserver-usa
Chris Metzler wrote: [...] The Urban Areas/T=4 dataset is fabulous, btw -- it goes down to 25cm resolution (TaxiDraw fetches 1 meter resolution images, it appears). I'd recommend just changing fetch.cpp to T=4, and getting the highest resolution images available; but not all areas are covered by the better dataset. That's why I'm recommending tests -- try to fetch from the higher resolution dataset, and drop down to the lower-res one if the first fetch fails. LOL, sounds as if Chris has hacked terraserver.com to provide him with their payware imagery for free ;-) After all your attempts, it's now certainly VERY interesting to have a look at their logs ! Did you also try numbers greater than 4 ? :-) And I don't even mention what their logs are going to look like if Chris adds your brute force method of trying to look for available images :-) What a creative way to organize a distributed denial of service attack against a Microsoft server, really Chris, awesome !! ;-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SGPropertyNodes are making fun of me ! (fgcommands)
Hi ! Having added a couple of new fgcommands recently I was now going to refine some of the acceptable parameters, to allow more functionality. And since Erik said that there could only be ONE parameter of type SGPropertyNode be passed to a fgcommand, I was going to pass all other parameters as additional subnodes/values of that particular SGPropertyNode. However, somehow I'm screwing things up now - because this works only for a certain amount of nodes/values so far. Without splitting parameters up, the whole things works, but it's then of course a rather static solution - so I assume I simply didn't take the right approach to deal with (=get) the subnodes, basically I'm using constructs of the global pointer, like: globals-get_props()-getNode(...) as well as the hasValue/hasChild methods in order to obtain the values/childs of the SGPropertyNode pointer. (Erik mentioned already some time ago that using the global pointer wouldn't be the preferable way in most cases, but rather one should use helpfer function) But running the mentioned fgcommand directly via a simple commandmycommand/command binding in menubar.xml works fine, however as soon as I either start providing several parameters within one property node, OR as soon as I try to run the very same fgcommand using Nasal, the whole thing doesn't work anymore, the Nasal problem seems to be related to the calling format: fgcommand(mycommand,/path/within/proptree/); So, what's the correct way (method/function) to deal with the passed SGPropertyNode pointer in order to obtain the values of several (kown) subnodes within that pointer ? As I said: it works sporadically :-/ Let's say I have half a dozen of parameters, all stored as values or subnodes within the passed SGPropertyNode pointer, how do I actually obtain the contents reliably - so that it doesn't matter whether the fgcommand is executed directly via a command tag or using the Nasal interpreter ? Thanks - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Trim quotes
Jon S Berndt wrote: Would it be grumpy of me to suggest that we try a little harder to trim quotes when replying with quotes? I've noticed that there are several emails today with 100 to 200 lines of quoted material, followed by anywhere from a few lines to ten or so. Over time, this stuff builds up... I noticed that too, on the other hand it's still easier to cope with that than with those postings that quote without quote signs ... ;-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] Aviation weblog: Land and Hold Short
David Megginson wrote: I have had little luck finding aviation weblogs (they're all about rants about politics, ...how would you then call the following: http://www.megginson.com/blogs/lahso/medicals.html ? ;-) (just kidding) BTW: talking of healthy presidents: Pres. Bush Senior did even do a parachute jump on his birthday this year, he talked about that on Larry King Live, whereas Larry King himself wasn't allowed to jump because of his health condition... hype about technology, or complaints about teenagers' social lives), I am sure you could attract some readers here by talking about the time when _you_ were a teenager ;-) so a couple of weeks ago, I decided to start my own. So far, it's heavy on content on light on good looks, so it's probably a fair reflection of its author. lol, if you add some of that sort of humor to your weblog, you'll certainly be able to maintain a steadily increasing reader community ;-) It's just a couple of weeks ago that I stumbled across a weblog on xsquawkbox.net, because of the IVAO/VATSIM discussion here on the list, that particular blog is maintained by the author of the X-Plane application that interfaces with IVATO/VATSIM networks - while his blog was definitely political, too - it did make for some amusing reading :-) If anyone here is interesting in taking a look, there are two ways to get at it. The best way to read it (or any weblog) is to add the RSS syndication URL to your desktop or online blog reader: http://www.megginson.com/blogs/lahso.xml I've noticed that you've provided this kind of tutorial on your webpage, too - how about also recommending one or two decent RSS feed- readers ? :-) (Haven't yet used that functionality much myself) Anyway, some of this makes really for some good reading: http://www.megginson.com/blogs/lahso/thumb60.html So, if you intend to maintain that type of contents you could certainly attract some interested readers, I think. Probably not only for real pilots, but some of this would certainly also be interesting for the flying FG community. Also, you mentioned somewhere that you'd have collected some links with rules of thumb, how about providing some of these links in one of your future blogs ? And if I were you, I really wouldn't worry all that much about the layout/design part: I didn't have any problems whatsoever reading (all) pages - so it cannot be that bad ;-) -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.2 released
David Luff wrote: On 10/19/04 at 11:57 AM Chris Metzler wrote: I think that your idea to put a taxiway designator in the 'xxx' (bet this message gets flagged as spam now!) part of the record is an excellent one. The downside of course is that it would require X-Plane itself to understand it before it could be applied to the master dataset. I am not sure whether there's much communication ongoing between the two projects, anyway: David, as you might remember I recently also had some talks with the X-Plane folks because of the IVAO/VATSIM thing, Ben (the developer of XSquawkBox) also functions as a contractor for general X-Plane development, I am not sure whether I forwarded that particular eMail to you where he explicitly mentioned how grateful the X-Plane community is about various opensource tools that can (and are) also be used for X-Plane. So, based on that and on the mail exchanges I've had with him so far I am inclined to bet that he would probably not mind forwarding your request/recommendation to Austin Meyers (the X-Plane author). My impression is that the odds are looking good for such an inquiry ;-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VBOs - performance test results
Ampere K. Hardraade wrote: I'm afraid, you cannot expect people to purchase new hardware for an open source game to work ;-) Is new hardware really necessary? nope, it wasn't required - after all it is supposed to be software-raytracing and not hardware, but I *assume* without a corresponding hardware board your CPU would probably be abused as a GPU - almost exclusively ... The reason I brought the OpenRT topic up again is that (as far as I understand) it can run on most people's desktop. yes, but I somehow doubt that there would remain much idle CPU time - you'd probably at least need a dual-processor board - but again, I'm *guessing*. Probably, they wouldn't start developing prototype hardware boards: http://www.saarcor.de/ ...if the gains were not significant ? Now, if it can render a 350 million polygons model using a CPU that is slower than mine, then it should be able to handle FlightGear with ease. I am not so sure about that - in order to get representative data, one would need to have at least some simple tests available or maybe even a simple game that employs the software-based raytracing approach. On http://graphics.cs.uni-sb.de/RTGames/ there are various games mentioned, even screenshots are shown - and even very promising divx-videos - but there doesn't seem to be a simple demo for personal evaluation !? This might be the case because all these videos seem to have been created using clusters of a dozen or even more 1 GHZ machines ... Doesn't sound that feasible to me :-/ But that page is also where you can find the quote I mentioned: We are very much interested in evaluating new ways for computer games and therefore like to cooperate with the gaming industry. Thus if you are in such a position, please send us an email! Maybe they've got a mailing list ? Possibly they would provide you with more details if you contact them... But I doubt that it is the ultimate solution - there are certainly drawbacks, and it's not necessarily suited for any purpose, either. Otherwise it would probably already be a lot more popular !? --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OpenRT (was: VBOs - performance test results)
But, hell - yes, it does look damn amazing: http://graphics.cs.uni-sb.de/Dynamic/Images/chess.jpg http://graphics.cs.uni-sb.de/Dynamic/Images/dance.jpg http://graphics.cs.uni-sb.de/Dynamic/Images/kitchen.jpg taking into account that all this was created without conventional 3D hardware - the videos are even more impressive. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a vivid exampe for the guru syndrome (was: hi res screen shots)
Norman Vine wrote: I still sometimes wonder if those that post well meaning but uninformed suggestions have any idea .. Norman, that's gonna be my favorite in my collection so far ! :-) BTW, sgi.com mentions what I seemed to recall: http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=fwdb=manfname=/usr/freeware/catman/u_man/cat3/glutEstablishOverlay.Z Now, Norman: please enlighten me ;-) -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] another vivid example for the guru syndrome :-] (was: Buildiing/running the ATC network test)
[WAY OFFTOPIC !] Erik Hofman wrote: Boris Koenig wrote: leave it alone, then it's NOT your business, but rather the folks from opentnl.org should take care of such issues ... With such an attitude you might be better off subscribing to fgfs-users and not fgfs-devel. Thanks for that hint Erik - as always, I appreciate your opinion, indeed, you might remember: I'm subscribed to both lists ;-) And I bet I wouldn't have half that much fun if I were *only* subscribed to the user-list :-) Back to the TNL topic: there have been quite some lengthy (private) discussions about whether to really use TNL or not - because OF their current lack of cross-platform support. You couldn't know that - you chose to reply anyway, and the two of us know why you did so ;-) So far we didn't get our hands on docs about how to create these platform modules to make the TNL support other platforms, too - so the only thing that I said - like I did already do privately - was that we shouldn't concentrate too much on using the TNL if it finally turns out to be unfeasible to make use of the TNL at all - having *portability* as one of the major goals. Essentially, because it might turn out to be a waste of time in the end... Likewise, it could be considered a waste of time to respond to things where you aren't fully involved Erik, regardless of the valuable opinions that you want to share :-) So in this context, I'd like to remind you of a private mail exchange that we had a couple of weeks ago: NOW you *are* encouraged to interpret exactly THAT meaning into the above paragraph ;-) Also, please keep in mind that your advice doesn't logically connect very well to my actual recommendation, simply because it wasn't about FlightGear development, but rather about openTNL development. Two different projects, if I am not terribly mistaken ? Of course, I understand what you're basically trying to suggest, but don't let this become a flame war about software development philosophies in general - I was only saying that there's no good reason to REALLY concentrate on the TNL as long as some things haven't been ruled out. In that regard, please take into account that every minute spent on other (i.e. NON-FlightGear-) projects, is one potential minute less for the (FlightGear-) project itself :-) And I am very sure that you'll remember times when you found yourself pondering about similar thoughts Erik ? So, don't try to convince me that my thoughts are non-conforming with the attitude of developers in general - that'd be ridiculous, I think. Instead of having to watch *some* people here continually starting attempts to live out their guru syndrome and thereby repeatedly proofing HOW 'welcome' new potential contributors are to this project, it would probably be much more beneficial for the project itself if some of _us_ could agree to react in a much more laid-back fashion to things that they don't like to read... possibly even reacting in a way that doesn't suggest that we just passed puberty ? Some people here seem even to be literally WAITING for people to say/post something that they can *mis-interpret* ... It's somewhat sad, although this is pretty interesting from a psychological point of view ;-) Alternatively, we could agree to use private mail, instead of putting harm to the project itself by provoking immature debates publicly on the project's mailing list - making the project or rather the community of developers less attractive for other people. Maybe, we need to set up a flightgear-fights mailing list !? ;-) Not everybody may enjoy these debates as much as I do :-) Boris P.S.: Believe me folks, I know exactly what it feelks like - I've gone through all this, too - not necessarily on (public) mailing list, though. ;-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] hi res screen shots
Norman Vine wrote: Curtis L. Olson writes: If you select hi-res screen shot from the menu, that means the menu is active, and it is drawn on every tile (so if you are doing a 3x3 scheme, you would get 9 instances on the menu.) This is probably easier to figure out than my first problem, but for now you can turn off the menu, then telnet in and run the screen dump command remotely to work around this problem. I think you just have to hide the menu when first entering the hires-screen function. IIRC this is what was done prior to XML'izing the menu ops An alternative approach: render the menu onto a different layer, and simply exclude that layer within the routines that create the screenshots, that way one could use kind of a GUI layer for things like a menubar, which shouldn't be displayed within screenshots. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] hi res screen shots
Curtis L. Olson wrote: Frederic Bouvier wrote: Boris Koenig wrote : Norman Vine wrote: Curtis L. Olson writes: If you select hi-res screen shot from the menu, that means the menu is active, and it is drawn on every tile (so if you are doing a 3x3 scheme, you would get 9 instances on the menu.) This is probably easier to figure out than my first problem, but for now you can turn off the menu, then telnet in and run the screen dump command remotely to work around this problem. I think you just have to hide the menu when first entering the hires-screen function. IIRC this is what was done prior to XML'izing the menu ops An alternative approach: render the menu onto a different layer, and simply exclude that layer within the routines that create the screenshots, that way one could use kind of a GUI layer for things like a menubar, which shouldn't be displayed within screenshots. What are layers and how are they implemented in OpenGL ? I don't claim to really know about OpenGL in general, but my Win32 OpenGL book talks about emulating layers/overlays by splitting up the depth buffer to create the illusion of different 'layers' - which could then still be 'addressed' separetely - which sounds to me still as if it could be used to separate the menubar from the rest of FG !? As I said: I really don't know about OpenGL in general, even though I seem to remember to have read that glut itself would support some function of the name 'glutestablishlayer or anything like that ? Probably you guys know more about that ;-) BTW: this was meant as an IDEA, and I believe the approach to simply disable/hide the menubar is easier, too :-) Maybe there's a FG plugin for photoshop I hadn't heard of before? Curt, I appreciate it very much that my postings seem to be that entertaining for you, you might have even more 'fun' by getting back to one or two eMails that I sent you weeks ago ... - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
John Wojnaroski wrote: Hi But even then it won't compile on Solaris/Sparc: Just upgraded to GCC-3.4.2 oh well :-) and it fumed and fussed trying to build the TNL library on my P4. So it's not all Solaris/Sparc... leave it alone, then it's NOT your business, but rather the folks from opentnl.org should take care of such issues ... Don't have time left today to work it further, will have a go at it tommorrow let's collect the error messages and file a bug report/feature request. They haven't yet replied to my inquiry about creating new platform-specific networking 'modules' either ... - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] hi res screen shots
Curtis L. Olson wrote: These last couple weeks and months I've been getting hammered at work and at home. I've got a large and growing number of to-reply-to emails in my inbox. yes, you mentioned that some time ago - here on the mailing list My hope is that someday I'll get caught up, but I'm not sure how that will ever happen. :-( The stuff that takes the most time and thought to reply to is unfortunately the stuff that sits in my inbox the longest. I see, no problem - my comment was just meant as an encouragement - so if you should ever feel the desire to be really well entertained and there's nothing on TV, simply fire up your mail client and look for one of my mails - I promise: you'll enjoy them ;-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
Martin Spott wrote: John Wojnaroski wrote: Note: For now, you will have to install the TNL headers files by hand: the following script should work #!/bin/bash cd /usr/include mkdir tnl cd tnl [...] This could be easily solved by setting srcdir = .. in src/master/Makefile yes, even though a simple cp -R tnl /usr/include would have been okay, too ... But I think, we'll add a simple install target to that makefile and take of all that care within the makefile. and, what you'll have to do in any case, fix the include statement in the source files, for example src/master/masterInterface.h, to #include tnl/tnlEventConnection.h #include tnl/tnlRPC.h yes, right - I did change exactly that yesterday ... there are some other smaller changes, we'll upload a fixed set of files by tomorrow. But even then it won't compile on Solaris/Sparc: I wonder how they can claim cross-platform portability okay, that's indeed a bit weird ... BTW, what is the relation between the files you placed on OpenATC and the OpenTNL project ? From there I could download only a '1.4.0rc4' source code package, the version on OpenATC carries the version 1.4 and the OpenTNL website claims they already reached version 1.4.3. All this doesn't fit together, The openTNL headers/library sources on openatc.sf.net/test are merely a downstripped/reduced version of the actual sources, simply because John figured we wouldn't need most of the stuff ... -- Bori ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
Martin Spott wrote: Boris Koenig wrote: yes, right - I did change exactly that yesterday ... there are some other smaller changes, we'll upload a fixed set of files by tomorrow. Would you mind trying to compile with a recent version of GCC before you post new files ? I'm using 3.4.2 on Solaris and I have the impression that that one is pretty picky. If you tell me it 'survives' compiling with 3.4.2 on Linux it simplifies determining which changes are specifically necessary for Solaris, Hmm, the latest version that I have access to locally is: gcc (GCC) 3.3 - and actually, I wasn't going to recompile GCC ;-) I am not sure where exactly the TNL (lib) is incompatible with Solaris, but I guess that can only be fixed directly within the lib itself ... So, maybe you can resolve some issues by directly trying to build the STANDARD package from opentnl.org - possibly, there's even some info available specific to Solaris. The sources itself should actually not be too non-standard, John simply used the shipped opentnl examples to put a basic test framework together, so there's not even that much 'new' code ... Actually, pretty much all of it is simply derived from those examples. Let's see if the official version builds on Solaris or where exactly it fails. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
Martin Spott wrote: Boris Koenig wrote: So, maybe you can resolve some issues by directly trying to build the STANDARD package from opentnl.org - possibly, there's even some info available specific to Solaris. Huh ? I think: Features Multiple platform support * Windows 98, ME, NT, XP * Linux on x86 * Mac OS X says it all lol, Martin - I've got good news for you: quote The Torque Network Library runs on the Microsoft Windows, Mac OS X and Linux platforms. *A Microsoft XBox version is available seperately from GarageGames.com* and future support is planned for Sony's Playstation 2 platform. /quote Which essentially means: get an X-Box or Playstation 2 - instead of a solaris machine :-) Anyway, the following sounds rather encouraging: quote TNL compiles under either either Microsoft Visual C++ 6.0 or Microsoft Visual C++ .NET 2003 on Windows, XCode on Mac OS X and with makefiles and GCC on Linux. In addition, TNL is designed to be easily portable, with all platform specific code contained in a single module. /quote So far it seems to be somewhat X86 specific, which would explain why opentnl doesn't like to run on Solaris :-) I'll try anyway but it might take some time (which I usually don't have available ). I think people usually say don't hold your breath :-) I think they're running a mailing list, too - I might send them a short questions as to whether it's possible to make the opentnl run on Solaris EASILY, or not ... http://sourceforge.net/projects/opentnl -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
Martin Spott wrote: John Wojnaroski wrote: Hope this hasn't confused anyone. There is a file on the SF page called tnl_head.tgz. This is a tar file of the header files for the network test build. it is NOT the tar file tagged as *HEAD* on the OpenTNL website. That's pretty clear. I'm mostly confused because OpenTNL apparently doesn't meet the conventions of FlightGear concerning portability, Yes, it looks somewhat problematic right now, but otherwise it's not yet really a problem, as there hasn't been much code written as of now - we might have to check other open source multiplayer/networking libraries out, though. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
John Wojnaroski wrote: Suggest we take the positive road and make it work. From my perspective it looks d--- good and since it is open-source as well perhaps the TNL folks would be willing to work with us. Yes, I suggested already to drop them a few lines and ask them for their feedback, maybe there's even some information about what exactly needs to be done to make it compile on other platforms, too. But when it comes to cross-platform issues, I'll defer to the experts. I've sent a short note to 'our volunteer experts', so that they can check out what's possible and what isn't. There was an attempt to make FG multi-player, but that seems to have receded. I think the TNL library has a better foundation and capabilities... This WAS my impression, too -otherwise FG runs definitely on MORE platforms than the TNL, so that would currently be a pretty limiting factor, I simply didn't look really into it, because the TNL support exactly those platforms that I use mainly ... -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ATC Network Test
James Turner wrote: On 4 Oct 2004, at 19:17, John Wojnaroski wrote: A few details... Volunteers will get a package of software that contains the TNL libraries and a basic set of software to connect to the ATC net as a controller or pilot. Package will include ALL source code and make files for a Linux system. Sorry, I'm just not an MS type. However, it will build under Cygwin. I'm happy to test, and probably even get the code building on OS-X, since it should be very close to working already. That would be really nice, actually I offered yesterday to make it compile under Win32 - but I didn't have MSVC in mind, but rather I was thinking of using MingW32 (Dev C++) - I am not sure how many people are actually using it here, so if there's anybody here who could assist making it compile natively under MS VC it would be appreciated. John told me yesterday he would be about to downstrip the package, so all volunteers who can help make it compile on a different platform should inform him, so that the makefiles/sources can be modified accordingly. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ATC Network Test
Giles Robertson wrote: DevC++ has some problems; last time I tried, you couldn't build FGFS on it because of the number of files in the final link; (it can't process the command line - too long). yes, I see - but that would probably not be a problem when linking only a -compared to FG - relatively small application ? :-) This command line restriction is probably a windows-problem, and not related to MinW ... maybe it's worth to check out what's possible using GCC as a cross-compiler for Win32. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ATC Network Test
Arnt Karlsen wrote: On Mon, 04 Oct 2004 11:17:07 -0700, John wrote in message [EMAIL PROTECTED]: A few details... Volunteers will get a package of software that contains the TNL libraries and a basic set of software to connect to the ATC net as a controller or pilot. Package will include ALL source code and make files for a Linux system. Sorry, I'm just not an MS type. However, it will build under Cygwin. ..GPL? Url? John isn't yet 'releasing' anything, rather he asks for people who would be willing to participate in some field tests. John: I haven't yet had the time to get back to your other eMails, but concerning what you mentioned above, I would suggest to have me look into your makefiles or sources where necessary, so that we can adapt them accordingly - if I am not wrong, you shouldn't have made much use of anything unix/linux-specific so far, so at this stage of the process, it's certainly pretty straight-forward to make the configure/makefile scripts support windows/mac, too. Particularly because of opentnl's cross-platform nature. - Boris P.S.: I don't think it's necessary for me to mention that I would be glad 'to volunteer' :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Memory usage
Martin Spott wrote: Hello, after reading a LWN article I started playing with the memory ovcercommit switch on a Linux box. Later I wondered why I wasn't unable to run FG reliably anymore and ran a 'top' to see what's going on here. I noticed that FG appears to lock huge amounts of memory - and the X server as well. Can anyone confirm similar experience ? If you want to hear a strong opinion about Flightgear's memory management, simply run the following: # valgrind fgfs ;-) - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VATSIM/IVAO integration MCDU/FMC
Harald JOHNSEN wrote: You are right. I had this image on my HD and could not remember from where it came. shouldn't be a problem - particularly not if you still favor the skin-able approach :-) I am sorry. Now that you said from where it comes, its even more obvious that we can't keep it as we need gpl material. I think you may have misunderstood Jeroen: he seemed to be willing to make it available for FlightGear purposes ? :-) -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG as scenery generator/VATSIM
Jeroen Hoppenbrouwers wrote: Hi guys, Hi ! First post on the mailing list after lurking for a while. My name is Jeroen Hoppenbrouwers and I have been active for about five years in a niche of the flight sim world, the (very active) community around Aerowinx 747-400 Precision Simulator (www.aerowinx.com). This is an extremely detailed systems and IFR sim, with nearly no outside view. I wonder about two things: 1. Many people nowadays slave the Microsoft sim to PS1 to get a full outside view on a secondary system without having to fly the MSFS. This gives them best of both worlds. I wonder whether FlightGear at present time would be capable to fulfill the role of a scenery generator? Yes, I've seen such an interface for MSFS to be used with PS1, too... I think it is *theoretically* possible, basically one would need to disable the standard FDMs (flight dynamic models) and let PS1 export the corresponding values via some simple IPC/sockets mechanism - how is this currently done ? I'd believe, they use FSUIPC for that purpose ? So that FlightGear gets the FDM-speficic data from PS1 and FG serves only as visual frontend for what PS1 wants it to do - probably one would also need to fetch/use values that are responsible for values such as weather, date/time etc. - so that this is also reflected within the outside View of FlightGear. Probably, it would be helpful to know what the MSFS - PS1 app essentially exchanges between the rendering simulator and PS1 itself ... I don't remember the webpage of that application anymore, but certainly you do - if you could come up with a listing of variables/data that needs to be exchanged, I'm sure people here could tell you in more detail HOW feasible it would really be to adapt FlightGear and where exactly in the source code you have to modify things ... My current impression is that this might not even be SUCH a big issue, but I may very well be wrong :-) 2. I saw comments about VATSIM/IVAO floating by. Yes, this is currently a topic of interest for some people here, mainly not because of these two particular networks, but rather because of the desire to offer virtual ATC capabilties to FlightGear's users. I wrote a fully certified client for both networks that is built in such a way that connecting it to FlightGear should take an hour at most (www.hoppie.nl/sb747). It sounds interesting, indeed we are already in touch with with either of the two networks, VATSIM also indicated that they were interested to cooperate for FG-client, on the other hand they put their emphasis on CLOSED SOURCE collaboration... Would there be interest to do this and offer it to VATSIM/IVAO for re-certifi- cation (re-, as the base software won't change at all)? It's certainly an interesting option, I think. Portability is no issue as everything is in Tcl/Tk -- however we still suffer from the security by obscurity dogma of both networks, so I can't release all sources just yet. that's exactly the kind of problem we faced during our 'negotiations' with them ... But how can you use CLOSED SOURCE with TCL/TK ? Do you additionally use binary libraries ? (that's what we were suggested to do ...) --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VATSIM/IVAO integration MCDU/FMC
Jeroen Hoppenbrouwers wrote: If you browse my site, you might find other goodies that could be interesting for FlightGear. I won't do MSFS, so it looks like I'm stuck with you for a while :-) It was kind of an understatement so say you might find other goodies :-) There's really A LOT of interesting stuff on your page ! Some things even seem to be interesting for FlightGear !? You mentioned the SB744 extension for VATSIM/IVAO: Out of personal interest I'd like to know, what specific PS1-variables you make available to VATSIM/IVAO ? Simply because as you may have read, some people here thought about exporting the relevant FlightGear variables,too - so that they could interface FlightGear with such a virtual ATC network. Maybe you can share some details, that way it would be straight-forward, to asses how feasible something like that would be for FlightGear. Is it right to assume that the mentioned PS1 broker is essentially comparable to the FSUIPC DLL in Micro$oft's FS ? So, the list on your page merely lists the PS1 offsets ? http://www.hoppie.nl/ps1addr/list.html Concerning your ATC Robot project ( http://www.hoppie.nl/atcrobot/ ), it would be interesting to learn more about your plans and if this thing is likely to become PS1-specific, there was quite a lengthy discussion here approx. 1-2 weeks ago, about possible ways to incorporate something similar within FlightGear: http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26650.html Also, you mention another interesting project on your webpage: http://www.hoppie.nl/mcdu http://www.hoppie.nl/mcdu/compare.html Indeed, something very similar was some time ago mentioned for FlightGear: http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26056.html Harald has even created some preview screenshots of his FMC project: http://www.chez.com/tipunch/flightgear I don't know, how usable your project is already but: Do you think that parts of your MCDU project could be interfaced to FlightGear, too ? Or maybe only used for the implementation that Harald is currently working on ? Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG as scenery generator/VATSIM
Jeroen Hoppenbrouwers wrote: On Thu, Sep 30, 2004 at 10:49:33AM +0200, Boris Koenig wrote: My current impression is that this might not even be SUCH a big issue, but I may very well be wrong :-) If FG would have a socket somewhere that will eat control data for the position, attitude, and maybe some other variables to steer the virtual windshield camera around, this certainly should be easy. look into $FG_ROOT/data/Docs, specifically you'll find the following files of interest: README.introduction README.IO README.properties README.protocol This will give you some basic information about how FlightGear handles its variables. In summary pretty much anything can be made available within the so called property tree, which can be pretty much seen as some kind of file system-like hierarchy, that you can even literally browse - either by using the in-built telnet server or the httpd, both of which will give you a basic impression how FlightGear offers total freedom that simulators like MSFS can only achieve by loading external (binary) modules that pseudo-export the variables in use. So, in many cases interfacing with FlightGear does not even require code modifications as long as the required variables are already exported to the property tree - then you can simply use either the telnet or http server to remote-control FlightGear using the programming language of your choice, you've mentioned Tcl/Tk, it's actually not complicated to create a simple socket connection to the FlightGear telnet server to access/modify the exported properties. We don't want any panel in view, just the forward view (and some people some side views on separate machines). This isn't a problem either: you can modify the view at runtime, indeed there's even a separate 'view' node within the property tree - despite from that, you can also disable the panel view easily. But how can you use CLOSED SOURCE with TCL/TK ? Do you additionally use binary libraries ? (that's what we were suggested to do ...) From the start I used TclPro, which has the required capabilities. It can either compile Tcl source to a binary format and source this in instead of plain ASCII (but the users must install TclPro, which I hate); or it can wrap all Tcl source together with a virtual filesystem with other files into one single executable for a great many platforms. I chose the latter way since about January 2000 and VATSIM/IVAO never even blinked. Okay, I see - thanks for the explanation ! -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MCDU/FMC
Jeroen Hoppenbrouwers wrote: On Thu, Sep 30, 2004 at 02:54:21PM +0200, Boris Koenig wrote: http://www.hoppie.nl/mcdu Ready to be abused by any program that can open the socket. Connect a TELNET and off you go. sounds good :-) Windows-specific code: only the part that moves the mouse off the screen and the computer shutdown stuff. Easy to remove/bypass. I am considering to open the source now, as I am satisfied with it. So, this is also a Tcl/Tk app ? Harald has even created some preview screenshots of his FMC project: http://www.chez.com/tipunch/flightgear THE MCDU IS NO FMC! lol, did I say anything like that ? :-) I don't think so ;-) IT IS A MCDU! Read the page for the difference! Thanks - indeed, I think, I know about the difference :-) It's rather that the project I mentioned is about the (logical) implementation of a FMC, as well as a CDU for the interfacing part. But talking of correcting eachother or rather differences: Why do you call a Boeing 744 CDU a MCDU - which is actually the name for a Airbus specific implementation of a CDU, even with a different layout/keypad ? :-) Do you think that parts of your MCDU project could be interfaced to FlightGear, too ? Or maybe only used for the implementation that Harald is currently working on ? :-) It *is* ready, as it is the MCDU, and it's finished. I've had a quick look into http://www.hoppie.nl/mcdu/design.html Are there already any pre-made designs (logical implementations) ? I strongly believe that a FMC is a FMC and a MCDU is a MCDU, and should be implemented separately. Okay, I see - so you are basically feeding data from PS1 into your (M)CDU for the backend (FMC/FMS) logics ? - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Validating XML parser
Jon S Berndt wrote: I've been wondering about easyXML, if it can be modified to support validation against a DTD? it probably can - if I remember correctly there are even some suggestions for DTD's or rather SCHEMA's for FG around ?? Since it is built on top of eXpat - and I believe eXpat _can_ be compiled to provide validation - is this just a matter of proper compilation of the eXpat library? I think the toplevel wrapper in easyxml is currently simply not told to really care for any defined/existing DTD/SCHEMA ? I ask because it is becoming clear to me that, as I compose the new parsing logic for JSBSim config files - as well as the new config file format itself - I may need to provide error checking / validation functions as the data is read in. There are just too many opportunities to mess up the config file. A couple of days ago I talked exactly about something similar to another FlightGear user: FlightGear happily starts up even if there are XML errors in any of its files - this is not really a problem for files that can be re-loaded, but particularly files like menubar.xml can turn out to be a problem as soon as they contain non-valid XML, simply because the actual 'validation' or rather error-checking is done AFTER the GUI has started up - and not as part of the initialization - so, you may very well see FlightGear starting all its subsystems and then learn that there's some bug in a config file such as menubar.xml - which would ultimately mean that the menu is non-usable. :-/ It might make sense to think about optionally providing a parameter to fgfs (for developers ?) to pre-parse/validate the XML-based config files, so that fgfs would complain as soon as it encounters anything invalid. Ideally, this kind of thing would be done by a config file editor, but since there is no config file editor on the horizon, validation of a config file against a DTD becomes quite attractive. *IF* you have a DTD/schema for your XML dialect it is no problem to use any of the more advanced XML-editors and have it compare your XML against the corresponding DTD/schema - so, there's no need to really add it natively into FG or rather the parser if you only want to have validation while you're editing a XML file. IMHO, it simplifies parsing logic in the end application (in this case, JSBSim). it would probably make things easier, but as in most cases it would firstly require a valid DTD/schema to be available for your purpose - but then you should be able to use a validating EDITOR. Now, this raises another question: do general purpose (or configurable) XML application editors (open source or free, preferred) exist that could be used to author a JSBSim config file? I would have to look for open source/free linux tools, but I did use such validating editors under windows - everything was presented in some kind of treeview and it would complain if you use anything that isn't explicitly mentioned in the DTD/schema. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Validating XML parser
Jon S Berndt wrote: Now, this raises another question: do general purpose (or configurable) XML application editors (open source or free, preferred) exist that could be used to author a JSBSim config file? This is what a quick search on sourceforge brought up - I didn't check each package, though ! cross-platform (Java) https://sourceforge.net/projects/pollo/ https://sourceforge.net/projects/xdoc/ Windows: https://sourceforge.net/projects/xmldoctor/ https://sourceforge.net/projects/xmlec11n/ Boris P.S.: I must have been wrong regarding the FlightGear schema, there seems to be only one DTD in the root directory. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] separation of runways from scenery (was: UK Photo Scenery)
Manuel Massing wrote: I am not sure, but maybe we would also need special handling for runways, to handle incosistencys between terrain and runway elevation, or irregular terrain underneath the runway. If parts of the corresponding source code should be reviewed/adapted, it would be nice to see a separation taking place, between the actual SCENERY and the airports - I mentioned this some time ago: This is the approach that X-Plane takes: the scenery is OPTIONAL, but even WITHOUT ANY scenery the airports are still being displayed correctly - so, each airport's data, including navaids and runways isn't (only) defined within the OPTIONAL scenery, but rather the data is used to assemble standard scenery for each airport ON DEMAND, i.e. based on the runway alignment. So, there would be no need to really install any scenery at all if you simply want to fly to an airport that's not in your usual flying area - if you only want to practice a particular approach. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] coming up with ideas for an ATC protocol - just in case ....
Ampere K. Hardraade wrote: For FlightGear and X-Plane. There may be problems working with Microsoft's Flight Simulator as it uses a different airport database than us. X-Plane is meanwhile supported by a customized version of squawkbox - implemented via some kind of plugin ... So: X-Plane currently also flies 'WITH' MS FS 200x traffic on VATSIM. I don't know about the real differences between the two databases, but if VATSIM manages to combine the traffic, it cannot be all that hard - one might need to apply offsets to navaids/airports, to unify data ... --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PropertyList - XML files - where to find the sources
Erik Hofman wrote: Boris Koenig wrote: I have now looked into dozens of source files, but I don't seem to be able to find those files that are responsible for the XML handling, respectively loading parsing the PropertyList XML files, so I apologize in advance, but: what's the name of the classes that are used or rather where do I have to look for this stuff ? (I simply want to use FG's XML-handling capabilities for a specific function) Do you want to parse XML yourself, or rather read an XML file into a property tree? XML : SimGear/simgear/xml/easyxml.?xx Property Tree: SimGear/simgear/props/props_io.?xx Hi Erik ! I have meanwhile looked into the these files - should have known that this SimGear-specific and not FG stuff, though ;-) However, there are two new issues: 1) While it wasn't a real problem to use easyxml.cxx's readXML to simply copy a XML file's structure to a particular node within the property tree, there doesn't seem to exist a similar wrapper for WRITING XML files within easyxml.cxx - something like writeXML :-) I have made a quick stab at it, but to be honest it doesn't yet really work - anyway, is there going to be a simple XML wrapper for writing added, or do you want me to put that class into the fg_commands.hxx ? 2) While I as able to place a simple fgcommand within the fg_command.cxx file and added it to the array of commands at the end of the file, my impression is that I can only pass ONE parameter to any FGCOMMAND ? So, for the dynamic menubar it wasn't really a problem, because it only accepts a SGPropertyNode pointer, anyway. But what I'd like to do now, is export to commands from within fg_command that accept the parameters like stated before: fgWriteXML(SGPropertyNode * sourcepath,char* targetfilename); fgReadXML(SGPropertyNode * targetpath,char* sourcefilename); So, how exactly can I export a fgcommand that accepts these parameters ? Or is the only feasible way to copy the filename to another node within the property tree node, and simply pass both bits of information as ONE property tree ? P.S.: I did read the commend in the fg_command.cxx files about modules that can add new commands using: globals-getcommands()-addcom ... Is there some standard loop to do exactly this for NON-modules ? Or is using the array at the end of the file, the best way ? Thanks ! - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] PropertyList - XML files - where to find the sources
Erik Hofman wrote: Boris Koenig wrote: However, there are two new issues: 1) While it wasn't a real problem to use easyxml.cxx's readXML to simply copy a XML file's structure to a particular node within the property tree, there doesn't seem to exist a similar wrapper for WRITING XML files within easyxml.cxx - something like writeXML :-) Well, there is a writeProperties() function next to readProperties function in SimGear/simgear/props/props_io.cxx. If nothing else these functions could be copied or abused to do what you are looking for. yes, thanks - I noticed these functions, too - so do you want me to place a writeXML function within fg_commands directly, or put it into simgear's easyxml.cxx ? 2) While I as able to place a simple fgcommand within the fg_command.cxx file and added it to the array of commands at the end of the file, my impression is that I can only pass ONE parameter to any FGCOMMAND ? Yep, thats the _root_ node of the property subtree you will be working on. So, then I cannot add a simple fgcommand that accepts two parameters, but rather I would need to create a root node, that contains not only the subnodes for the XML file itself but also the filename and possibly other parameters ? Hmm, that would mean that I would also need to export copyProperties() as fgcommand in order to be able to create such a root node easily, or I might be able to recursively iterate through the XML file's properties and copy each node manually using Nasal !? Also, a new problem would then how I extract those parameters from the SGPropertyNode pointer that aren't mean to be used by a function that accepts these pointers, so I would then need to extract the String value of a certain node for the provided pointer, is the method GetStringValue() the correct one for that purpose ? Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] navaids *symbols* ?
Chris Metzler wrote: On Sat, 25 Sep 2004 00:27:47 +0100 Jon Stockill [EMAIL PROTECTED] wrote: There are already models for VOR/DME, TACAN, and ILS aerials in the Models directory of the base package. Yeah, I had fetched some VORTAC images off the web and had started to make a model for it in Blender when suddenly one appeared in the Models directory (and at KSFO). It could use some texturing though, and at some point it might be cool to have two flavors of these things -- when they're at airports, and when they're not -- so that the ones at airports can have e.g. checkerboard textures. Another thing I'd like to do at some point . . . I would love to see CHART SYMBOLS (2D is okay !) of each possible navaid added to fgfs-base, the kind of standard symbols that are used on Jepp charts or maybe others, cause I would like to fetch them from the base directory in order to display them within FlightGear on some kind of basic map, in order to illustrate navigational concepts. I have actually already looked for symbols online, but probably one would have to draw new ones, in order to be able to release them under the GPL - vector images would be also neat, so that they can be dynamically resized, without quality change. That way I could display stations and their relational position towards an imaginary aircraft. I have already looked into the source code, in order to add some new fgcommands that load/display images in a particular location on the screen ... but didn't yet find anything that looks appropriate, probably I will simply take the routines that load SVG instrument layers ...will just have to find the stuff :-) Also, I will have to ask some questions about how to DYNAMICALLY animate an instrument on demand - if anybody's got ideas, it would be appreciated :-) (This is all for the FliteTutor thing ...) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Landsat 7 data for FlightGear
Georg Vollnhals wrote: I use commercial data since a long time (DSat5) for FLY!II and X-Plane but as license agreements forbid giving it to the community I worked with low-res Landsat 7 data (and SRTM elevation data) and developed tools (Win32, Delphi) for improving picture quality, cutting and easy import into FLYII. Georg, a couple of days ago I posted a short comment about the latest version of D-SAT, where the normal version is available for about $ 40 US and another 'business version' for about $100 US: http://onlineshop.buhl.de/buhl?art=90 The (German) description for the second version explicitly states the right to export images and use them 'commercially'. So, I wasn't that sure whether it can be used for FG textures, or not ... I was going to ask them about that possibility within the next days, what I personally consider even much more interesting than the possible 'permission to use their PURCHASED software to create PRIVATE textures FOR YOUR OWN USE' would be about the part 'you're entitled to use it commercially' - because ultimately one could interpret this as if I am allowed to: 1) purchase the software, obtain all rights 2) export images 3) use them commercially 4) create textures - DERIVED from the exported images 5) sell my textures for $ 0.1 US per set of textures ;-) Even more interesting, the resolution: 45 cm/pixel or about 18 inch/pixel, if I remember correctly. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG users discussion on AVSIM.COM
Ampere K. Hardraade wrote: I have only read the first few posts, but I am already seeing a problem here: people seem to think that Flightgear only supports .ac3d for models. THIS IS NOT THE CASE! yes, I remember plib supporting various models ... But it's about convenience, I think: Micro$oft makes all that stuff easily available (meanwhile) - so if you install MS FS 2004, X-Plane or some other simulator you simply GET the tools that are necessary, often some documentation about how to do it, too. One can download a version of GMax (the same 3D modelling tool that is used for designing models for Microsoft's Flight Simulators), work on 3D models, than export them into .3ds format which FlightGear will accept. I was going to sign up on that forum anway, so I would not mind to post any clarifications that come up here :-) On the other hand, there are certainly many aircraft designers that would not mind making their models available for FG-use,too - so, browsing repositories like AVSIM certainly brings up MANY models, the most interesting ones - and those that are supported by FG, should probably be easily added, the FDM'ing is a different matter, though ... We really need to educate potential users that there are alternate methods for designing models for FlightGear other than the usual AC3D/blender approach. does the python script for blender - ac3d meanwhile support removing the (unrecognized) 'crease' statement, or is plib patched to ignore it ? Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Voice stuff
Just a couple of comments that didn't yet make it to the 'outbox' ;-) John Wojnaroski wrote: John writes: Thinking a bit about the folks playing in the virtual ATC world. Would be nice if FG could be included, might obviate the need for an AI system. Conversely, developing an AI/ATC system is good exercise for the brain muscle and provides a nice alternative for network-challenged machines ;-) David writes: Personally, I think both are important in the long term, but since I've started on AI/ATC I'll carry on with that for now. The security implications of coding networking code frighten me - I think my coding style might be a bit, erm, rough for that! Actually, I would not recommend to really invent something new, either - So in case that we should really need to do networking stuff: I would rather recommend to use any of the existing networking libraries for that purpose, that way one could mainly concentrate on really developing the *protocol*, there are numerous other projects that do already an extremely good job with the networking stuff, so why waste your time developing logics that others have finished already ... So, for FlighGear purposes, the Torque Network Library ( http://opentnl.org ) looks suitable, as it is cross-platform, GPL and despite from that I have personally done some smaller things using it, so it's really no rocket science - you can do everything in a very abstract way - additionally it is also under active development by a _group_ of developers, which is also the reason why the very same library is used by commercial applications/games. To be honest, personally I think that developing a protocol in itself is already challenging enough - taking into account that it should be efficient ...one shouldn't waste to much time with the low-level part (i.e. implementation) But all this may not even become necessary - maybe we can even use the VATSIM/IVAO networks :-) I just sent a question off, about what kind of variables/data the networks needs to fetch from FlightGear and in what format that data needs to be made available. I think, that way we can look into FlightGear property tree and determine, what's already there and what isn't yet. Depending on whether the protocol is natively integrated using plain old C++, or if it gets added by using the I/O protocol XML-based routines, making the data itself available should not really be such a problem, I would say ... Definitely a lot easier than doing the AI stuff :-) what we need is the Grand Unified Cosmic Controller Interface (GUCCI) o! (-10 points from Gryffindorf for bad punning) I sent an email off to the virtual ATC folks a few weeks ago (ivao and vatsim) regards hooking in my 747 sim; so far no response. Will be interesting to see if Boris hears back... What I learned so far: Squawkbox - the windows client for FS 200x simply fetches/puts data using the IPC mechanisms implemented via fsuipc from schiratti.com - so, essentially this software also uses a different set of common shapes for all aircraft, these shapes are then displayed for other traffic, within the simulator - so, basically all other traffic is referenced within the coordinate system, and depending on the type of aircraft, the squawkbox application seems to make the simulator display an appropriate 'shape' / with a special livery for each aircraft. You can find more out about this common shape library at: http://homepages.paradise.net.nz/seang1/csl/ However, this seems to superceeded now - there's a new approach, called: Multiplayer Traffic Library (MTL) essentially, it might already be sufficient to make other traffic available within the property tree, with default shapes - adjustable airspeed parameters and other stuff, that way the network protocol could simply change the variables of the corresponding aircraft using the prop tree. I also sent just an inquiry off to the vatsim folks about the currently used VoIP technology, so that we can decide what type of software might be used for FlightGear - depending on the protocols/compression that needs to be supported, there' certainly a lot of open source stuff. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ATLAS ? (navaids *symbols* ?)
David Megginson wrote: On Sat, 25 Sep 2004 10:34:05 +0200, Boris Koenig [EMAIL PROTECTED] wrote: I have actually already looked for symbols online, but probably one would have to draw new ones, in order to be able to release them under the GPL - vector images would be also neat, so that they can be dynamically resized, without quality change. That's not a bad idea, but here are a couple of others to consider: 1. put the symbols on a moving map display rather than the scenery itself; and To be honest, I wasn't going to place them within the scenery. This was just one idea for the whole FliteTutor thing, so that I can show simple animations, based on the aircraft's position in relation to a couple of navaids, shown on a planar map view. Of course the moving map idea is indeed interesting, too. This might be worthwile to consider for the Atlas developers: they would merely have to use FlightGear's navaids database and fetch the positions of navaids, and OPTIONALLY display their symbols at the corresponding position within the map. 2. put models of the actual navaid transmitters in the scenery. For what purpose ? :-) Do you mean to improve situational awareness, so that a 3D model of a VORTAC is displayed, including the current bearing within the outside view window ? Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ATLAS ? (navaids *symbols* ?)
Hey Robert: are you back ? [EMAIL PROTECTED] wrote: Quoting Boris Koenig [EMAIL PROTECTED]: 2. put models of the actual navaid transmitters in the scenery. For what purpose ? :-) Do you mean to improve situational awareness, so that a 3D model of a VORTAC is displayed, including the current bearing within the outside view window ? Or perhaps showing airspace types as colored mists. One of the problems a beginning pilot has is relating class B,C,D TFR's, and restricted airspace to points on the ground and the appropriate altitudes. A color coded terminal area could make transiting more obvious, interesting, and informative. I like this idea VERY much - Robert: please write down such stuff. Regarding the implementation, I would think that it would be necessary to apply a color filter to certain regions on the screen - possibly using particular shapes ... this would need to be based on altitude and positional information, btw: Robert do you know where airspace classification is made available ? --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] coming up with ideas for an ATC protocol - just in case ....
Arnt Karlsen wrote: ..what do we have right now? FG can be rigged to run as an ATC World Server now, right? lol, I don't even know about that :-) another evidence for the lack of documentation about FG :-/ We have xatc as a viable client to that FG ATC World Server, I haven't yet really played around with it - but personally I would prefer using a cross-platform toolkit, rather than relying on X - IF this is really meant to be used for FlightGear, it should at least compensate for all the weaknesses that the other major networks have - so it should preferably be possible to use it on any platform. we have FG itself, so we need to come up a protocol to help the other people squak FlightGearese, what else did I miss here? Arnt, without getting into too much detail about the recent discussions with the VATSIM/IVAO folks, I would really encourage you to think more about it and write down your ideas - currently, it doesn't sound that good for an opensource'd collaboration with either of the two networks, so if the latter remains a pre-requisite for *any* collaboration (which is my feeling), your ideas might very well become valuable ... Depending on what John David think, I'm going to summarize the so far received feedback later: some of it makes certainly for some good entertainment ... In the meantime, here are my pre-liminary thoughts about what data FlightGear needs to make available in order to become ATC-able (most of it is already in the prop tree): - position (altitude), speed (V/S), heading - aircraft category (wake turbulence class) - type of aircraft regarding its appearance, to pick appropriate models within other clients - currently set squawk code - currently set radio frequency probably there's more ... It's probably worth to add your own thoughts, so that there's a fallback plan - it's certainly easier to make a quick stab at the ATC integration, than it is to come up with the ATC AI part ... The major disadvantage would of course be that there's no integration with existing virtual ATC networks - so, there wouldn't be any existing ATC community to really 'drive' such a FlightGear ATC project ... and even if you could attract some people, because of its opensource nature: FlightGear does certainly not have such a large user community as simulators like MS FS and X-Plane have, so this is then another drawback for potential virtual ATC controllers. In the end this would become a totally new project - nothing that could be run under FlightGear's umbrella easily, at least not if it's supposed to become 'successful' - and it's only going to become interesting for the FlightGear FLYING community if there are really people who would do the actual controlling part. Making VATSIM/IVAO people switch to something like what Arnt suggested, would really require to incorporate so many new things ...just to make the change really feasible. This is certainly beyond the scope of a FlightGear ATC *SUB* project. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Landsat 7 data for FlightGear
Arnt Karlsen wrote: On Sat, 25 Sep 2004 10:42:34 +0200, Boris wrote in message [EMAIL PROTECTED]: The (German) description for the second version explicitly states the right to export images and use them 'commercially'. ..that is the precise legal meaning of Mit der Business-Version erhalten Sie die Lizenz zur gewerblichen oder freiberuflichen Nutzung.? no, rather like that: Purchasing the business version you'll obtain the license for commerical use the exporting functionality was mentioned in another paragraph, but it is NOT mentioned on the page for the non-professional version. .there are license texts for this version? not sure about that - one would probably have to FIRST purchase the product in order to be shown the EULA-confirm dialog :-) But I was going to send them an inquiry within the next days, anyway - so I may simply ask them to send me an English translation of their license, too ;-) So, I wasn't that sure whether it can be used for FG textures, or not ... I was going to ask them about that possibility within the next days, what I personally consider even much more interesting than the possible 'permission to use their PURCHASED software to create PRIVATE textures FOR YOUR OWN USE' would be about the part 'you're entitled to use it commercially' - because ultimately one could interpret this as if I am allowed to: 1) purchase the software, obtain all rights 2) export images 3) use them commercially 4) create textures - DERIVED from the exported images 5) sell my textures for $ 0.1 US per set of textures ;-) ..or publish your derived work under the GPL. ;-) lol, good point - I was just trying to make the point that I'm not so sure whether commercial use also means to give away for free ... but sure, if the latter is part of your business ;-) -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)
John Wojnaroski wrote: ATM VATSIM is running an event in SoCal with 24 controllers and 88 flights as of 08:15Z to be honest: I would have expected more people :-) I'm all for trying it. not yet so sure about that ... And it will take some time to build up a following. agreed ... At a minimum we will need a handful of dedicated volunteers who have experience as professional pilots and controllers or a working knowledge of ATC rules and procedures to act as experts and mentors for the rest of us. I would say, more people would be necessary in order to make it start: - AT LEAST the handful of people who know ATC stuff - AT LEAST a handful developers who have networking experience - ABOUT half a handful ;-) of people who know network security stuff - Minimally a handful of people who come up with an interface for MSFS Think about it: this is not an easy task, this would finally mean to COMPETE with the major networks - if you want an NEW (opensource'd) network to be(come) popular, you need to offer it for OTHER PLATFORMS, too - you must not restrict it to ANY particular platform or GAME (flight simulator). This would be about providing a viable alternative to the closed source networks. So, after all - if the ultimate GOAL is still to provide virtual ATC support for FlightGear, one has to take either the full step or simply drop the whole idea, simply because of the lack of a really significant user base for FlightGear, so it's unlikely that such a specific ATC for FlightGear-only-network would appeal to anybody at all. And then, the whole things gets pointless, because you could simply stop wasting your time and continue to think about AI ATC, which would ultimately be a better option, instead of having a FlightGear-only network, which may be used by 3 dozens clients ... And possibly 2-3 controllers. I'll be at the exit; so as you leave, if you would like to leave your name and telephone number we'll be in touch ;-) regarding the experts that would be required: this shouldn't be SUCH a problem, as they can probably be easily found in various aviation newsgroups/forums, also IVAO/VATSIM themselves provide forums, where you can often times find real controllers. And then there's a lot of freely available documentation available... I don't even think that developing a draft for a *protocol* would require much support by professionals, simply because it would be mainly technical - network related, not so much really specific to ATC and aviation. The data that needs to be provided for a protocol can be determined by looking at the mentioned networks, the user interface could probably also be resembled - so to some extent, their 'closed source' software might even help an opensource effort. It's more about common-sense, to really determine what needs to be done - and then also about implementing an efficient protocol :-/ I think, mainly developers, testers, and security people would need to be available, as well as developers that can do cross-platform development using low-level networking libraries. Of course, one might indeed look for an opensource library that serves as an abstraction layer for the whole OS specific part. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Another (3.). ATC online network
Oliver C. wrote: On Saturday 25 September 2004 20:38, Boris Koenig wrote: Making VATSIM/IVAO people switch to something like what Arnt suggested, would really require to incorporate so many new things ...just to make the change really feasible. There's also a third ATC online network, VATSIM and IVAO are not the only ones. The third one is called FLIGHTPROJECT international (FPI). It is newer and with about only 1 users a little smaller than VATSIM or IVAO but it is maybe a chance to ask them if they want to work together with FlightGear. Here's the link: http://www.flightproject.net/ yes, I did also stumble across FPI, but I read somewhere they were affiliated with Micro$oft directly ? I didn't verify that information, but to be honest, I didn't bother to mention them because of that ... But yes, you're right: BEFORE there are any efforts started, one should also talk to them, they might even be a bit more 'motivated' because of their situation in comparison with VATSIM/IVAO, so maybe they're even more willing to 'change' ;-) I will check their webpage tomorrow ...but even if they aren't affilliated with MS, I did also read they would so far ONLY suppport the MS FS ... :-/ - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 737 autoflight modeling
Jon S Berndt wrote: First of all, due to the unavailability of the actual flight management software, a guess would have to be made using reference material such as a flight manual. A quick search of the web indicates that flight manuals for currently in-service airliners are not simply given out. Security concerns have limited availability to those with a valid reason. Given that, I also wonder about how smart it would be to model such aspects of airliner operation too closely. *Personally*, I would NOT consider the latter a factor, simply because it will take a lng time for FlightGear to really become THAT _real_, regardless of what you might be able to achieve within the near future. This is for a fairly simple reason: there are numerous other products which do really a VERY DECENT job at resembling systems, behaviour etc. some of them are even used by real life pilots for training, e.g. Wilco's 767 PIC: http://www.wilcopub.com/support_767PIC.html ... while merely an *addon* to M$ FS 2004 - is said to be really realistic - even though it only runs within (and hence has to live with the limitations of) the Micro$oft flight simulator. You can even get their manuals - WITHOUT the software: http://www.wilcopub.com/extra_767PIC.html And this is just one example of MANY - there are others products such as Aerowinx PS1: http://aerowinx.com/ which is not even called a flight simulator but rather a procedure trainer, it resembles even all of the systems/components of a 744, so products like these are available to ANYBODY who's willing to pay the bill - with NO restriction WHATSOEVER ! Regarding your comment concerning the fear to possibly create software that might be used by 'terrorists': Without meaning to offend anybody, but I highly doubt that FlightGear will be able to compete with any of the mentioned more advanced products within anytime soon - even if one particular aircraft suddently gets a realistic autoflight system ... this is just ONE piece of a whole number of systems, so I WOULD DARE TO *GUARANTEE* that FlightGear is not going to be used for 'training purposes' within the next years - be it by authorized or non-authorized people ... A somewhat more realistic autoflight system would not even be close to what other products can do already - and I am not even talking yet of the really professional (CBT) stuff that airlines/flight schools use to train professional pilots And all this is still *available* - it's merely a matter of investing the money - you can go directly to shops like: http://www.aerosim.com/bizjet/biz_atrnsprt.htm ...and get whatever you want - Jeppesen doesn't seem to restrict access to their training materials either. (and there are soo MANY others !) Or purchase such products directly from the manufacturer: http://www.wicat.com/flight/other/introfms.htm http://www.wicat.com/flight/simstrns/md11fms.htm And even if some American companies now place restrictions on the access to such material, it's still available in pretty much any other country. (civil) airplanes aren't weapons by definition... it's a matter of how you USE things that defines whether you are using a weapon or simply a normal tool. On the other hand what you are bringing up here is indeed a hot debate that was particularly pushed because of 9/11 - after it became obvious that the terrorists also used flight simulators for their training ... If you're interested in these discussions and the opinions of the professionals, take a look at pprune.org and search for flight simulator - you'll find threads where people wonder whether simulators are getting too real because of the 9/11 attacks. And no, I don't think this going to happen that soon - and certainly not for FlightGear in particular, there are too many other shortcomings that FlightGear users seem to want to see addressed before: http://forums.avsim.net/dcboard.php?az=show_topicforum=198topic_id=260mode=full Also, regarding the whole terrorist issue that you mentioned: terrorists usually have the funding available to really use *professional tools*, so the 9/11 terrorists did not only fool around with a version of Micro$oft's flight simulator, but also attended REAL flight training, they even used fixed base sims... FlightGear is not going to become interesting for that group of people! So, ultimately a potential terrorist would much rather decide to book a 'normal' typerating course than bother playing around with FlightGear, typeratings are also easily available ... (okay, not in the US ANYMORE) http://www.pea.com/courses/gct.asp And then you can of course still get used materials on ebay ... That's where I got most of my AOMs - pprune itself is otherwise also a good source of information: http://www.pprune.org/forums/search.php simply use keywords such as autoflight lnav vnav FMA in order to find the relevant threads for your project. And what can't be found, can still be ASKED
Re: [Flightgear-devel] VIRTUAL ATC: a feedback from IVAO (A voice for FG)
Hi ! I have just received a reply from IVAO's 'chief developer' - as soon as he says that it's okay to post his reply to this list, I'm going to post the full text. However, in summary: they would support an opensource client for their network, PROVIDED that their rules are respected, ***BUT*** they DO NOT want to publish their protocol specs, because of security issues they had in the past, so what they're trying to do is to provide security by hiding the details of the exact implementation (pretty Micro$oft-like). I _interpreted_ their reply like that: they would provide a binary library that we could link 'our' client/FG to. But the protocol would still be theirs, and not known to us. I have responded saying, that we would actually prefer having access to some kind of protocol spec ... Additionally, I have recommended to get some discussion going, with several people involved - to see whether there can be any compromises made. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..protocols, ATC and interoperation, was: oops (wrong link)
Arnt Karlsen wrote: Both of these networks don't seem to be really interested in cross-platform development, so I really wonder whether these new versions will mean that the protocol is also going to change anytime soon... ..which lands us back to define our own. ;-) I am going to ask them about that, but: I have actually just a couple of minutes ago received a reply from the VATSIM people: I may have been wrong ... or at least my impression may not have been all that correct: they seem to be rather positive about the idea and also mention not to be windows-fanatics :-) I just got in touch with the author of squawkbox(.ca), as soon as I have talked to the others I would recommend to set up some (private ?) talks - possibly using eMail ... Private because they shouldn't feel forced to share 'internals' that they consider essential ... ..keep in mind, one of the reasons interoperation fails, is they keep their protocols secret. lol, but hey - I was asking very directly :-) I can understand their worries, too: imagine if that's the only way to keep your network kind of 'safe' - by simply not telling anybody how it works ... ..also remember there are many game sims out there, say Warbird, and some of these use secret protocols to have people pay for game access. ...the latter is for example something that VATSIMS EULA doesn't (seem to) permit ... ..other people reverse engineer these protocols, setup free servers but keep their source closed, such as wbfree.net . Apart from possibly the game fun, it is not clear to me what's in it for wbfree, it certainly is possiible to make use of such closed source schemes as, say, spammer infrastructure. ..with a published game server protocol, we make these people either adopt our open protocol, or risk scaring away their gamers business on, say, the uncertainty of closed source as spammer infrastructure. ;-) while I expected some of the reactions so far, I was also admittedly surprised to hear about some of the people involved being into the open source thing - so maybe the odds aren't all that bad. We will see, VATSIM didn't yet definitely say anything about 'closed source' protocol specs - so far this may seem like 2:1 for VATSIM ;-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)
Another thing: As I seem to be the only one so far, who's got in touch with them, I would not mind continuing the exchange to a point where things get specific, but I would appreciate some help concerning the things that we should get straight with them - I mean, I have already asked quite some stuff, but everybody has probably his/her own imaginations regarding a possible collaboration, so what I brought up so far is certainly far from complete, e.g.: - protocol should be open (?) - cross platform software - integration of VoIp software (?) ... ... So, why not collect these things and discuss the needs of the FlightGear project ? That way we can also determine what's acceptable and what's not. As soon as these things are clear, we'll see their *real* ;-) attitude. --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] UK Photo Scenery
Arnt Karlsen wrote: On Wed, 22 Sep 2004 18:58:16 +0100, Mat wrote in message [EMAIL PROTECTED]@mamaloucos.com: I just rang Europress publishers of the Getmapping high in the sky series (reminded by Boris's question). I spoke to Richard Charge their head of Sales. To be very clear this is different to what Boris was asking but still interesting, well at least for anyone interested in photo scenery for the UK. I have been asking Getmapping if it is permissible use for people to buy their CDs and then use the exported image in FG in a personal flight sim. ..wrong question; IMHO you should have said _GPL_ flight sim. With personal, open source, freedom etc thrown in for good measure to get him hooked. They have allowed freebee personal but closed source use, which isn't too useful for GPL Flightgear development. I think the question in itself is not even 'wrong' it rather resembles the low expectations of the person who asked ;-) And I can understand that point, too - ultimately it doesn't feel that good to ask for a freebie ;-) But I agree with Arnt that mentioning the kind of simulator / project and what kind of purpose their imagery would fullfil, so maybe one could really send a clarification eMail and re-phrase some of the wording, even if it's just to get a clear statement about whether the data could converted to FlightGear specific textures for scenery rendering. Something like this would of course not sound particularly attractive to a company that makes money, selling that very data. On the other hand, I could imagine that there's a better chance if you state clearly that FlightGear would not directly use their (viewer) program, nor would it directly use their image data, but rather the data would need to be converted into a separate format ... One could even offer them to show them how to do it exactly, that way they can make up their own mind and decide whether they permit derived work from their product to be releases under the GPL. Again, it would certainly NOT be wrong to mention the noble purposes of the FlightGear project, and that it can be used on most platforms, that it is meant to be free - and hence depends on these kinds of inquiries. So if you make sure that this is not a product that will be sold again, but rather that this whole thing is meant to remain free at all costs, they know at least that this is not some company trying to make money by using their data ... And one should still _mention_ the possibility to honor contributors by either mentioning them on the project's page in the contributor's section, or really adding some small about dialog where users can read Scenery imagery generously donated for GPL use by GetMapping or anything like that. In that context it might be worth to list some real life examples of COMPANIES that supported FlightGear in a SIMILAR manner, but I'm certainly less updated about such cases than you ... anyway, what comes to my mind is the company that donated audio sound recordings to be used within FlightGear. Of course, it would not harm at all to mention some other BIG names, and I've seen names like ARINC, NASA in the contributor's section etc. which *contributed* to FG in one way or the other, this can probably be used as an encouraging factor, too Personally, I think that your odds are a lot higher if you put it this way and also show the corresponding company that this is AN OPPORTUNITY. Regardless of the feedback that you will ultimately receive, I would not mind to send such inquiries to other companies that sell satellite imagery. He confirmed he has checked with Getmapping and that this is OK we even talked about the possibility of a discount for Flightgear users. I then got this email. Hi Mat, Following our conversation today I am happy for you to use High In the Sky products in conjunction with your Mesh / Flight Sim software. This on the basis that you do not re-engineer or alter the High In The Sky program code in the process and that the product will be used for Social and Domestic use only. ..such a _wonderful_ way of sayng No! to our GPL project. Or did he say Yes? What does he mean by Social and Domestic use only??? To be honest, I highly doubt that the person who replied did really understand what this is all about - looks a lot to me like a rather general response - so a refined inquiriy would probably be not such a bad idea. Tell them: FG Intro: - FlightGear is a free GPL'ed flight simulator - FlightGear can hence be used for pretty much any purpose GetMapping: - not the actual application will be used - The viewer application would not be modified - there's no reverse engineering involved Offer: - The FlightGear project offers them a CHANGE to become a supporter of this project - and they would would be OFFICIALLY mentioned - if this is not yet appealing enough to them ONE COULD STILL THINK ABOUT OFFERING THEM
Re: [Flightgear-devel] A voice for FG
Sorry for all those typos in that other posting... I'm simply not yet entirely awake :-) Ampere K. Hardraade wrote: If we are to do something similar, it will probably be a better idea to find several open source ATC-simulator development groups Well, I am not aware of *any* popular ATC simulators that are opensource AND multiplayer capable. At least not anything *really* popular - of course you can browse sf.net and find efforts like: http://sourceforge.net/projects/atcj/ http://sourceforge.net/projects/airtraffic/ http://sourceforge.net/projects/jatcsimdata/ http://sourceforge.net/projects/atcsim/ There are numerous other ATC projects, but these seem to be the only ones that actually made it to a file release. But this is not really anything that's really used by a majority of ATC simmers - nor can you really compare this stuff to stuff like Aerosoft's ATC Sim Even worse: it's not even trivial to make these projects combine their efforts, because every project seems to use yet another programming language/toolkit: you'll find a few C projects, several perl/python java solutions ... This is a pretty common opensource issue: create your own thing instead of putting time into other people's time ... The popular stuff (like Aerosoft's ATC Simulator: http://www.atcsimulator.com/ ) is commercial, but that company is only just about to work on the integration part for flight simulators (that's what you can read in their forums, at least). So they might indeed be interested to consider broadening their area of application and not limiting the possibilities to M$, otherwise the Micro$oft market in itself is of course already pretty interesting for them ... I will check out their forum and ask them about the multiplayer part and whether they would be interested to publish the protocol specification or rather develop a specific protocol to be used with FlightGear. But of course it's not really THAT attractive to make FG interact with closed source projects ... and let them code the multiplayer portion So far this is all based on squawkbox(voIP) stuff and the fsuipc.dll extension - an equivalent of the latter would probably not even be necessary as most data could be fetched from the property tree, so it would mainly be about specifying the protocol for the data exchange to the actual RADAR application IVAO/VATSIM use an application called ProController for that stuff, don't know whether it's open source or not, though. But a corresponding protocol might be implemented using the XML based protocol definitions - not so sure though about the UDP part, that's what these apps mostly use. as well as the interface that links Flightgear to their simulator. I agree, it would probably be worth it, to bring this whole discussion to the forums for ivao/vatsim. ivao has even its own software development department: http://www.ivao.org/softdev/ But to me it seems a lot like an entirely new project :-/ - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] dynamically modifiable menubar (was: /sim/navdb ?)
Boris Koenig wrote: Erik Hofman wrote: Generating a dynamic menu structure might be harder than you think, As you didn't yet reply to the ideas that I mentioned in this thread, I simply tried the approach that I described. And everything seems to work somewhat now - with the small exception that I don't trigger an automatic event when the corresponding property tree node changes, but rather I simply use a (new) fgcommand command to update the menubar using a PropertyList path (instead of the already available reload from file command), like this: /sim/menubar/menus/menu[0] I decided not to make this a specific general fgcommand that fetches the menu structure from a static location within the property tree, but rather I have kept it general enough to allow also for new menus to be created within any property path, so that the path /sim/menubar/menus can ultimately not only hold the reference to the ONE (default) menuBAR but rather it's now possible to also create other menuBARs dynamically, without the need to really touch the normal menubar, to make this possible I have introduced another node named: /sim/menubar/active-menu Which isn't yet logically bound, though ... But it should hold a (valid) number for any of the menus stored under: /sim/menubar/menus like: /gui/menubar/menus/menu[0] (the default) /gui/menubar/menus/menu[1] (an abitrary new menu) So that one could ultimatley store several menubars within that path and simply activate a specific one. I have a couple of questions, though - so far this is not yet entirely release-ready, as I didn't seem to be able to properly deal with the toplevel SGPropertryNode pointer 'global' manually. So, while I am able to get a pointer to /sim/menubar using something like SGPropertyNode * targetpath; targetpath = globals-get_props()-getNode(/sim/menubar/); I didn't yet really get how to manipulate the nodes manually, I did look into the doxygen docs at SimGear.org, but I am not sure whether I have to call the method setStringValue() or use fgTie() to add another node. So let's assume I have the mentioned targetpath variable and now I want to add another subnode (directory) named menus - so that this can hold then the actual structure that's currently simply dumped into /sim/menubar How do I do that correctly ? Also, I as an additional feature I was thinking of adding the funcitonality to auto-hide the menu after a pre-defined amount of time, so that it disappears automatically if the mouse is not in that area, and appears again when I move the mouse to the upper screen area. I was thinking of adding two additional values to the path: /sim/menubar called: /sim/menubar/auto-hide [BOOL] (true/false) /sim/menubar/auto-hide-delay[int] (seconds) Now, this in itself is not a problem - I did also find the corresponding hide/show methods within menubar.cxx, what I would need to know now, though - which methods can I use to monitor the current mouse position - so that I can call the hide/show methods accordingly ? Thanks again Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] UK Photo Scenery
Erik Hofman wrote: Boris Koenig wrote: Arnt Karlsen wrote: On Wed, 22 Sep 2004 18:58:16 +0100, Mat wrote in message I have been asking Getmapping if it is permissible use for people to buy their CDs and then use the exported image in FG in a personal flight sim. ..wrong question; IMHO you should have said _GPL_ flight sim. With personal, open source, freedom etc thrown in for good measure to get him hooked. They have allowed freebee personal but closed source use, which isn't too useful for GPL Flightgear development. I think the question in itself is not even 'wrong' it rather resembles the low expectations of the person who asked ;-) And I can understand that point, too - ultimately it doesn't feel that good to ask for a freebie ;-) He rightfully didn't ask for a freebie. After all it's a commercial product created by thousands and thousands ours of real flights to photograph the whole of the UK. if you take another a look at my posting, you'll notice that I understand that point very well :-) I was just replying to Arnt's comment, that seemed to recommend asking for a GPL'ed 'freebie', respectively the permission to purchase their data and use the created scenery then for future FlightGear releases (?) What he did ask however is if it would be possible for someone to *buy* their CD and use it for personal use in FlightGear, which is granted. right, I agree it's nice to KNOW that you are *allowed* to do it, otherwise only few people would really ever care to ask at all, particularly if you purchased the application anyway and don't intend to publish/package anything, but rather want to use the stuff privately ... There's a German saying: no reason to feel offended if you don't know about it ;-) And I'm not even saying that I generally share that attitude, but it actually shows that this is about a PERMISSION to use something that you have already purchased - not really an entirely new possibility, okay maybe a 'legal' one :-) This is really great from the publishers and should be taken for granted! ...not... ? I agree, it is indeed a nice gesture to be officially allowed to use their data privately with FG - Even though I don't know what the stuff costs, otherwise you are of course right and one should think about mentioning that possibility and a corresponding HOWTO to the webpage. Maybe Mat can provide some insight about the price of the data and the process to convert the data to FG textures ? Anyway, I am going to give this also a shot and contact some companies that provide aerial/satellite image data, could anybody here provide the details concerning the requirements that need to be met for an image to be suitable to be used as a texture for FlightGear ? Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
Giles Robertson wrote: Beware being like Sony. Invent a new protocol that is better and more efficient and flexible, and still nobody will use it, though, on the other hand, nobody uses Sony's protocols (ATRAC-3, Betamax), because they are eyeballed with patents. and despite from that: this would not only be the protocol, this would also comprise developing multiplayer server software that's capable of linking major versions of flight simultor software AND different ATC networks, so this is truly an effort for a whole new project, I'm afraid. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Good news :-) [ linux atc sim pendant to proController available ! ]
But there's also some good news in this whole discussion: this morning I had an eMail in my inbox from Richard Smith who told me he would have written a linux based version of IVAO's ProController some time ago because he didn't want to run Windows just for playing with IVAO - he called it 'xATC' - you can take a look at his webpage in order to try check it out: http://www.theforest.plus.com/ More precisely in the 'unix' downloads section: http://cgi.theforest.plus.com/index.php?content=2page=1plen=10system=2 The direct download is: http://www.theforest.plus.com/software/xatc-1.0b.tar.gz And a man page can be found at: http://cgi.theforest.plus.com/index.php?content=2page=1plen=10system=2man=9 He told me, that even though his application is currently copyrighted he would be willing to make the sources available, even for the case that not the actual application itself should turn out to be very useful, we might still have some interest in the (obviously telnet based) protocol. I think this is indeed quite an interesting thing - if he's okay with that, one could even attempt to rewrite parts of it/enhance some of the functionality, so that his project becomes the basis for a new FlightGear - IVAO effort - so one would then try to incorporate the right protocol exports into FlightGear's XML based protocol definitions. And one of the first steps would ultimately be, to see whether FlightGear flights can made to be shown up on his xATC application. This would already be a significant step into the right direction. And this would already be quite a success, I think ! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] PropertyList - XML files - where to find the sources
I have now looked into dozens of source files, but I don't seem to be able to find those files that are responsible for the XML handling, respectively loading parsing the PropertyList XML files, so I apologize in advance, but: what's the name of the classes that are used or rather where do I have to look for this stuff ? (I simply want to use FG's XML-handling capabilities for a specific function) Thanks - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG-webpage addition (tardiff created base-package patches)
Erik Hofman wrote: Boris Koenig wrote: But there's another thing in this context - it's about the VERSION file in $FG_ROOT/data not containing pre-release tags, I think Jim Wilson mentioned a couple of weeks ago that this is supposed to be like that, this however causes a problem for those users who want to apply a patch for their corresponding fgfs-base version: in order to make the process really idiot-proof it would be very helpful if you guys could either decide whether to add pre-release tags to the version file I think there have been versions around where the version number in the base package was actually something like 0.9.4pre2 Maybe, I don't know - it's just that some general convention would be useful, particularly regarding the patch applying howto for tardiff: http://tardiff.sourceforge.net/applying-patches.html#tardiff-apply So, if you say that future VERSION files will also specify whether a particularly package is a PRE-release, it would already be sufficient. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
David Luff wrote: On 9/21/04 at 4:02 PM Jon Stockill wrote: Those demos are based on festival 1.4 - the prerelease of 2.0 includes a synthesis module called multisyn, which is a great improvement on the older modules. http://flightgear.stockill.org.uk/testing/atis.wav contains the synthesised text of an atis transmission using one of the multisyn voices. Wow, that is *so* much better than the output from Festival a few years ago. The Read back... and Advise the controller... you have ... sections near the end sounded wrong, but apart from that it was very good. I would imagine that there might be ways to input phonetic and prosodic hints to sort out known difficult phrases. right, that's what the sable stuff is all about - you can use certain parameters to influence speech output, additionally you can also provide festival with a separate file that lists the relevant vocabulary that it is supposed to speak - this is a lot like sphinx would work, where you can also provide some kind of dictionary with words, that should be recognized, the ultimate option seems of course the modelling of domain specific language models, which is described in closer detail here: http://www-2.cs.cmu.edu/~awb/papers/ICSLP2000_ldom/index.html http://www.ling.ohio-state.edu/courses/materials/795X/festvox/festvox_10.html But that sounds to me pretty involved - at least the work to verify the computer's work, even though a 'guess rate' of more than 50 % (as shown in the example scenario) is already pretty encouraging. One would have to think about a way, to use one common dictionary for both - the speech synthesis, as well as the speech recognition engine, if that's then based on original phraseology files, it should already be pretty close. I played yesterday around with sphinx (the recognition engine) and actually it does even a pretty good job at guessing those words that it doesn't know. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
John Wojnaroski wrote: - Original Message - From: David Luff [EMAIL PROTECTED] This all sounds very exciting, especially the encouraging results from the voice recognition stage, and the fact that Jon thinks that Festival 2 is sounding pretty good. Could you send me the code you've got so far for sending strings across to FG? Actually, there are three parts --- the ASR that converts speech to text (that runs on my laptop) and sends the text string over the LAN to the AI app that analyzes and generates a response and sends the text over to the festival engine (TTS) for conversion back to audio. I'll send along more details via private mail and attach the tar files. What approach do you currently use to simulator the 2nd and most interesting ;-) part ? on the decoding of the speech to text-strings only so far, or have you actually started on logically decoding the text strings for ATC-AI? This is the part I'm currently in deep thought about. Working on the speech to text and text to speech ends, the middle ATC/AI is the really tough part. yep, since the day you posted your idea I've also been playing around with festival locally - and to be honest, I just used nested switch statements so far for the textual recognition part - but hey, that's also a (simple) state machine ;-) , simply because it's really getting pretty abstract without using some kind of more advanced AI mechanism/library, I've just looked into libs that support basic FSM's - but in most cases a finite state machine would be also a pretty static solution :-/ So, you'd have to create at state machine definition file, and have a pre-processor then compile this into C++ source code - hence this would be compile-time static, but one would really need to resemble a basic state machine manually using classes that access XML files, in order to keep things dynamic, and in order not to have to recompile the AI-part for each new phraseology item. I am just about to check boost.org for templates that might be suitable for the FSM modelling part. If anybody knows about C++ libs/templates for dealing with state machines, it might certainly be interesting to look into that option. Otherwise, there are numerous simple editors for the creation of finite state models, that one could use to create a basic framework - but taking into account that this is not only about recognition of a message, but also about properly dealing with the parameters it's getting really abstract - basically one would nett pretty much a pendant of what SABLE is doing for festival, for the recognition engine, too. Have you ever looked at www.vatsim.org or www.ivao.org ? I have, and I know people who are 'active virtual controllers' there ... A different approach using real actors to create a virtual world. ...and they'd tell you it's not only a different approach it's also a different MOTIVATION - they don't do it because they are interested in FLIGHT SIMS, but rather they are ATC enthusiasts - so it's not about 'acting', but rather they seem to enjoy virtual controlling as much as others enjoy virtual flying ... But, alas, it's all MS based... well, actually not really - at least the protocols are meanwhile open and there are several attempts ongoing to establish some kind of cross-platform tool, I think one can even find several projects like that on sourceforge. The only problem is not so much the ATC client/server part, which is so far mainly about a simple VoIP tool, but rather the real issue is multiplayer integration *and* simulator data fetching - of course Micro$oft is leading in the multiplayer area - and fsuipc does the rest: there are thousands of people who fly online using Microsoft's sim each day - compared to those other minorities that use different simulators, and even *different protocols*. So even if a flightsimulator like FG had already serious multi-player capabality it would certainly not be that simple to make FG interact with all those version of M$ FS200x. If it was only for the client tools that are used by the pilots controllers, this whole thing would be a lot easier, but since there needs to be basic multiplayer functionality, as well as data extraction from the simulator (for the virtual radar screens), it's indeed somewhat restricted right now to software like Micro$oft FS. Flight simulators, as well as ATC simulators have been around for quite a while, the latter of course with not such significant success, but it's getting more popular each day because the fun factor is increasing, simply because of technologies like TTS/ARS - meanwhile ATC'ing is not merely about using the keyboard mouse and doing abstract thinking, anymore - , but rather you can now use products like Aerosoft's ATC simulator, that make use of TTS/ARS in order to make the whole thing more playable. So, they are now trying to combine both worlds - which of course makes sense, but is not really THAT trivial. -- Boris
