Re: [Flightgear-devel] Re: Release of v0.9.9 source code
On Saturday 19 November 2005 15:30, Erik Hofman wrote: Melchior FRANZ wrote: And finally, this is my TODO list: * try to get rid of a few more hardcoded dialogs, or at least make them accept gui colors Not that I explicitly stated no major updates to the *source* *code*. Removing code would be no problem (and neither would be putting an equivalent in the base package). Erik I agree with Franz Melchior. And my question is, why it is so essential to call the next version release 1.0? What's wrong with version numbers like 0.9.10, 0.9.11, 0.9.12 etc. until the above issues are fixed? I mean this is an Open Source Project, there's no need to meet a deadline and it's very unlikely that flightgear developers will loose there job when version 1.0 is not released in 1. quarter 2006. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Release of v0.9.9 source code
On Saturday 19 November 2005 16:35, Jon Berndt wrote: To turn the argument around, there's nothing to fear from calling it 1.0, either. I don't think so, in my opinion the status of version 1.0 will decide how many new contributers and public interest this project will get. In other words, my estimation is (when i look into my crystal ball :) ), that we will get more people that start contributing to FlighGear with things like creating 3d models and aircrafts when it's possible to switch aircrafts during runtime. When this isn't the case, people might think/say: OK, this looks nice, but i will wait with contribution until this issue is fixed,. or: Hm, i think i will give the project a next try when version 2.0 is out. On the other side we will get more attention even in none computer specific newspapers when the issues are fixed and people start to say: Wow, this is so perfect, this looks so great, what a wonderfull simulator... That's why we should be carefull about which version we call 1.0 In my opinion version 1.0 is an important release, it's not just a number. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [0.9.9] screenshots for flightgear.org
On Thursday 17 November 2005 18:37, Dave Culp wrote: On Thursday 17 November 2005 10:58 am, Melchior FRANZ wrote: IOW: This was intentional. :-P OK, but it still looks odd. BTW, very nice screenshots. If I may I'd like to include two screenshots showing FG capabilities that are also missing from the website. And one from Gerard, if he approves. This is my desktop wallpaper BTW: http://home.comcast.net/~davidculp2/A6_F8refuel.jpeg It is a very nice screenshot, but as far as i know the tanker isn't GPL and it is not a part of flightgear, so it's better to not use this screenshot. In my opinion, we should only show things, that are in flightgear. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
On Monday 14 November 2005 15:01, Stefan Seifert wrote: Vassilii Khachaturov wrote: On Mon, 14 Nov 2005, Stefan Seifert wrote: Buchanan, Stuart wrote: OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for *nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows. I'm sure you meant /usr/share/FlightGear/... and not /var. I thought /var because of the indeterministic size --- some folks will terrasync only a small local area, some will more... terrasync is another story, which is no problem through giving FlightGear two scenery paths. Additionally no one should run terrasync as root anyway, so it can't write to /var/share/FlightGear. terrasync users should have their own scenery directory in their homes or anywhere their user is able to write. Nine I agree. User data (like from terrasync) belong to ~./local/share/FlightGear or ~./flightgear/ When using the latter one, we could also start to put the .fgfsrc config file into ~./flightgear/ The preferenced.xml file should also belong there, because it is user specific and the user should allways be able to edit it. A system wide global installation should put the scenery into /usr/share/FlightGear/scenery or /usr/local/share/FlightGear/scenery (for a distribution independent installation) That's what FHS proposes/dictate. If we want to keep consistency like Curt proposes, then we should put everything into /usr/local/games/FlightGear/ The reason is, in /usr/local/games we can have our own directory for everything (data, scripts, binarys etc.,). In /usr/local/games/ there is no need to spread everything around over the system. BTW, an alternative to /usr/local/games would be /opt/ Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
On Monday 14 November 2005 16:06, Buchanan, Stuart wrote: I'm groping in the dark here as I'm not familiar with terrasync. Am I correct in thinking that someone using terrasync should have their terrasync data in a different directory from their directly-downloaded 10x10 scenery? If so, is the convention to name the directories as follows: $FG_ROOT/data/Scenery - standard SF bay scenery included in base package $FG_ROOT/Scenery - scenery downloaded in 10x10 chunks $FG_ROOT/WorldScenery - scenery downloaded by terrasync or is WorldScenery just a different convention for $FG_ROOT/Scenery? I suggest to remove the SF bay scenery in the corresponding 10x10 scenery file. This allows us to place the SF bay, which comes allready with the base package, in the main scenery folder like all the other 10x10 chunks. And when someone installs the corresponding scenery tile w130n30.tar.gz it won't overwrite the SF bay. What's your opinion about that? Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
On Monday 14 November 2005 16:58, Curtis L. Olson wrote: We can suggest different default locations of $FG_ROOT for different systems, but below $FG_ROOT we should use the same structure for all platforms. Curt. Then we should definitely officially use /usr/local/games/flightgear/ or /opt/flightgear/ as $FG_ROOT on unix systems. The ones who want have it the other way can change it on their own with the --prefix= command line option, but officially it should be clear for things like a binary installer or tools that want have access to the data in flightgear without the need of asking the user all the time where the flightgear data is. To make use of /usr/local/games/flightgear/ or /opt/flightgear/ by default we should change the configure script accordingly. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
On Monday 14 November 2005 18:05, Martin Spott wrote: Oliver C. wrote: Then we should definitely officially use /usr/local/games/flightgear/ or /opt/flightgear/ as $FG_ROOT on unix systems. I don't understand why the hell people should want to use /usr/local/games/ for FlightGear ? That's easy to answer: Because flying with Flightgear makes a lot of fun. :) Seriously, i can live with both directories. /opt/flightgear is fine too. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
On Monday 14 November 2005 19:07, Buchanan, Stuart wrote: --- Melchior FRANZ [EMAIL PROTECTED] wrote: Both are wrong, according to the FHS, and to common sense. The right path is /usr/local/share/ ... and guess what? It's already the default. So, What is FHS? It's the unix Filesystem Hierarchy Standard http://www.pathname.com/fhs/ where $FG_ROOT is the FG data directory, and can be anywhere anyone wishes (though I intend to reccommend c:\FlightGear for windows to avoid any whitespace issues) On windows the Flightgear folder definitely belongs into C:\programs\FlightGear That's the default place for all Windows applications. The folder C:\programs can be accessed via a windows system variable, and this is the right way to do it, because this is required for localized purposes. For example on a German Windows installation the name for C:\programs\ is C:\Programme\ Thus the system variable should be used, instead of a direct access to the folder name. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
On Monday 14 November 2005 18:47, Melchior FRANZ wrote: * Oliver C. -- Monday 14 November 2005 18:46: [/usr/local/games/FlightGear or /opt/flightgear] Seriously, i can live with both directories. /opt/flightgear is fine too. Both are wrong, according to the FHS, and to common sense. The right path is /usr/local/share/ ... and guess what? It's already the default. So, nothing to see here -- move along. Ok, i can live with /usr/local/share (for flighgear data) too. :) Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: OT: FYI, mac os x developers,
On Saturday 12 November 2005 21:48, Melchior FRANZ wrote: * Martin Spott -- Saturday 12 November 2005 21:33: You know as good as I do that by common practice encoded emails don't belong into mailing lists - Sure, just like HTML, top-posting, full-quoting, Yet it happens. I tell people once to follow the rules, but if they don't and don't have anything relevant to say, either, they simply end up in my killfile. Just a suggestion: Maybe it is a good idea to put some of the important rules on the http://www.flightgear.org/mail.html webpage so people can read them, before they subscribe to the mailinglists. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
On Friday 11 November 2005 01:43, Georg Vollnhals wrote: There was a review/test of FlightGear in linux user, November 2005, a very popular German linux magazin. Although they gave FlightGear 4 full pages, scenery on their cover CD and a lot of very usable hints aimed to flightsim beginners they complained about missing panels, missing instruments, missing Transponder (and a lot of other things like bad flightmodel ((due to missing stall characteristics)), missing structural damage, missing red and white-blackout, missing higher-level ATC, missing colleason detection ((they might have proved it with the ... objects)). Their last recommendation was not what we would like to see and we could say simply ignore it but a *lot* of linux user are reading this magazin and potentially flightsim interested people get the wrong impression by this review. :-( Here is the online version of this review: http://www.linux-user.de/ausgabe/2005/11/070-flightgear/ Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 0.9.9 scenery?
On Friday 11 November 2005 18:40, Curtis L. Olson wrote: As best as I can see from their site, they just interpolated through the voids. That generally works fine and is pretty much what we did for the current scenery, but when you are missing big chunks of things like the grand canyon or tops of moutains, then what? For the USA where we have an alternative data source, I filled in the voids from that data which is good for things like the grand canyon and rhode island that are missing huge chunk. Isn't SRTM data version 2 allready corrected manually? That's what i thought, when i heard sth. about SRTM v2. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Winter Textures - screenshot
On Sunday 23 October 2005 22:16, Ralf Gerlich wrote:
Hi,
Arnt Karlsen schrieb:
On Sat, 22 Oct 2005 11:27:56 +0200, Ralf wrote in message
I'd say we need different texture-names for lakes which freeze in the
winter and those that don't.
..aye. Delay lake freezing around river mouths and speed thawing there,
the currents. We want Artic ocean 'n bay 'n fjord freezing too? ;o)
Erm, ok...working on custom scenery all the time I forgot that the VMAP0
data does not give us this information. %-)
Does VMAP0 data has different data for salt water and freshwater?
If yes, then:
// Beginning Pseudocode
if (water==freshwater)
{
if (temperature 0 )
{
usetexture(freshwater_freezed);
}
else
{
usetexture(freshwater_unfreezed);
}
}
else
{
usetexture(saltwater);
}
This is not a perfect solution, but better than nothing in most cases. :)
Best Regards,
Oliver C.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
On Wednesday 14 September 2005 19:03, Curtis L. Olson wrote: I have a question I'd like to toss out to the group for discussion/comment. What would people think of abandoning our mailing lists and converting over to online/web-based forums? This is a great idea! I like forums and prefer them. Reasons why web based forums are better are: 1. They have a search engine. Old entrys are easier accessable, than 80 MB of mailinglist traffic that needs to be downloaded, updated, unzipped etc. 2. The Readably of a web based forum is better. 3. You can allways easily access all the data of a forum on every place. This is not allways the case with mailinglist. For example, when i get them via E-mail on computer 1, i can't read them on computer 2. 4. No spam. 5. No disturbing HTML messages. 6, The chance of quotes of whole messages (E-Mails) is lower. - People would only have to subscribe once and they could access all the *Gear forums. I agree. This is reason number 7. :) If we would like to move towards using forums instead of mailing lists: - Should we manage the forums ourselves on our own FG servers? Yes, this is the preferable way. - Should we use some other forum hosting service? No, we shouldn't if it is avoidable. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Custom Scenery for Lake Constance
On Wednesday 17 August 2005 20:12, Ralf Gerlich wrote: Hello, some time ago I posted that I had some project for custom scenery around Lake Constance in the most southern part of Germany going. Now that the legal issues are solved I'm proud to present the first comparison screenshots :-) http://web44.netzwerteserver2.de/196.0.html The standard scenery (on the left of the pictures) is from today. Very nice done. Looks great. Where can i download it? Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
On Saturday 30 July 2005 16:25, Dave Martin wrote: I don't know if anyone has brought this up yet but the 1.0-7667 driver from NVIDIA for linux breaks the drawn shadows as in they don't appear at all. This tested and confirmed on a FX5800U and 6600GT PCIE Dave Martin No, it works here. You just need to start flightgear in 24 bit mode. fgfs --bpp=24 Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] T38 and other aircraft xml files overwrite scenario settings
Today i found out, that using the T38 overwrites other scenario settings which are set in the preferences.xml file. The cause for that was the refuling scenario which was set in the T-38-set.xml file.That shouldn't be done that way. Scenarios should never be set in the aircraft's xml files. All scenarios that are set in the aircraft's xml files should get removed by default. At the moment scenarios are set in the following aircraft related xml files: Hunter/hunter-2tanks-set.xml: scenarioship_demo/scenario OV10/OV10-set.xml: scenariothunderstorm_demo/scenario T38/T38-set.xml: scenariorefueling_demo/scenario sgs233/sgs233-set.xml: scenariothermal_demo/scenario The reason to remove them is, that it's not a good idea to set them in the aircraft files when they overwrite other scenario settings that are set in the user specific preferences.xml file. Imagine that someone wants to use the sgs233 glider and fly around over the Alps. What does he do? He will create a new scenario demo file to have thermals over the Alps and activate this new scenario demo file, like it should be done in the preferences.xml file. But what happens when he starts flightgear and fly around over the Alps? He will not be able to notice the thermals over the Alps because the thermal_demo scenario that is set in the sgs233-set.xml file will overwrite every other scenario, including the Alps thermal demo scenario. Conclusion: It is bad behaviour to define scenarios in the aircraft xml files. And it is from an usability standpoint error-prone and a bad idea. Another reason to remove them is, when we take the sgs233 file again as an example: Why does someone want to have thermals over KSFO when he wants to fly over the Alps? That makes no sense. Scenarios allways depend on locations, but aircrafts are location independent. That's another reason why scenarios shouldn't be set in the aircraft xml files. Then i have another question: Is it possible to make flightgear be able to use more than one scenario demo file at the same time? This would be a nice feature, because it would allow us to make demo scenarios part of the scenery. Think about a ferry that allways drives from dover to calais and back, this could be made part of the scenery w010n50 as a local default scenery scenario. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
On Sunday 17 July 2005 16:55, Vivian Meazza wrote: Harald JOHNSEN I guess the first player will set the environment for all subsequent players, or would the server have some say in this? Such things should be allways done by the server to prevent cheating. How would the initial conditions be the same, since players enter and leave at any time? What would happen when the first player left the sim? That's why the server needs to control it. Then entering and leaving the server at any time isn't a problem. Would METAR data be updated? Could/should the server provide METAR data and time? Yes. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
On Sunday 17 July 2005 20:20, Vivian Meazza wrote: Oliver C On Sunday 17 July 2005 16:55, Vivian Meazza wrote: Harald JOHNSEN I guess the first player will set the environment for all subsequent players, or would the server have some say in this? Such things should be allways done by the server to prevent cheating. Does that imply we always use METAR? Should we have some choice if the real weather is unsuitable? What about turbulence? Should we be able to choose time of day? No, this does imply, that the server should allways have the control over the weather and time of day settings. This means, that the server is telling you if Metar or something else is used. How would the initial conditions be the same, since players enter and leave at any time? What would happen when the first player left the sim? That's why the server needs to control it. Then entering and leaving the server at any time isn't a problem. The first player could set the conditions, and then providing that these were updated at regular intervals, other players could also enter and leave at any time. Who is the first player when the first player leaves the server? That's why normally such things are set by the server administrator or by the users who have to vote for a change of the settings. In latter case we need a voting system. Would METAR data be updated? Could/should the server provide METAR data and time? Yes. Would this cause an unacceptable interruption in player positional data? When the METAR data gets updated all 15 min. there shouldn't be much overhead. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: gui theming
On Tuesday 12 July 2005 19:15, Ampere K. Hardraade wrote: On July 11, 2005 04:26 am, Melchior FRANZ wrote: Screenshot du jour (and my current style; more that just a test): http://members.aon.at/mfranz/fgfs_gui8.jpg [50 kB] m. That's so nice. I would have no objection if that is made default. Ampere I agree. It looks really great. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Short Reference Document error?
On Sunday 19 June 2005 13:50, Jon Berndt wrote: This short reference: http://www.flightgear.org/Docs/FGShortRef.pdf shows the rudder control on the numeric keypad as being the 0 and , (comma) keys. There is no comma on the numeric keypad. This is confusing. Then you have a keyboard with US layout. On my keyboard (German layout) there is a comma. So there's nothing wrong with it, it's just that every user has another kind of keyboard layout. ;) Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Short Reference Document error?
On Sunday 19 June 2005 22:20, Jon Berndt wrote: Aha ? In fact the notation in the cheat sheet _is_ correct and clear, why the hell do you want to break it ? It's just a matter of point of view an I assume there are _many_ FlightGear users out there that have a comma as a decimal separator - it's just that they probably don't live in the US. I think you are making a disingenuous assumption, here, on what I am saying. It IS correct and clear for*European*users, yes. All that I did to the PDF document was to add a _note_ in the appropriate section in brackets that says: [U.S. keyboards use . instead of ,] Are you opposed, in principle, to providing U.S. users with accurate information? I don't understand what's got you so hot about this. It's an international project. Let's be clear for everyone. Jon Maybe it sounded in your first letter like that you may be one of those Americans who allways try to make the USA the center of the world. We Europeans and people from other countrys don't like that it is offending, so i can understand Martin Spott's reaction. But now, that you made clear that this wasn't your intention and that you don't have this US center view of seeing the world i think it was just a misunderstanding between both sides. :) I like your proposion of adding a _note_ in the appropriate section in brackets that says: [U.S. keyboards use . instead of ,]. This is a very nice solution. We just need to make clear that Flightgear stays as international as possible. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New turbo/supercharger code
On Saturday 18 June 2005 01:09, Andy Ross wrote: mp-pascals: Is this needed? The standard so far for manifold pressure has always been inHg. Having lots of duplicate units around complicates things; we can always do conversions in the panel animations or Nasal code. In this case inch Hg is wrong, because it is not an SI-unit. Pascal (Pa) is a SI-Unit so that should be used in the base code. Conversion from none SI-Unit can still be done in nasal code. We should really try to use only SI-units everywhere in the base code. If this is not the case, we should start to correct that. boost-pressure-psi-gauge: This looks to have been hardcoded to sea level; it should be using ambient, no? Also, must the units be PSI, or can I change them to inhg? Both is wrong, the SI-Unit Pascal (Pa) should be used. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Opengl rendering
On Thursday 16 June 2005 20:34, Harald JOHNSEN wrote: I was thinking of using some pixel shader for one or two effects. This would be with the arbvp1 arbfp1 type shader. Of course I won't write them in assembler by would use Cg to produce the assembler source. The use or arb type program should limit the dependencies on standard opengl driver. The GLSL is part of OpenGL 2.0 and NVidia has allready OpenGL 2.0 compliant drivers for Linux and Windows. So OpenGL 2.0 with GLSL is IMHO the way to go. But before starting anything like that I first want to know if : 1) people have program shader capable cards (ie FX5200+ or ati9500+) No need to code lot of things if only 5% of the user can see them. Normaly a good percentage should have correct cards (or will have in the next 6 month) but I feel that some still use olders cards. I have a Geforce 4 Ti but that's not a problem, i can upgrade later when it makes sense. :) The only thing that is important for me now, is an option to turn it off and it must stay vendor neutral and crossplatform compatible. So, please don't use specific OpenGL Extensions that only run on specific hardware. Instead use only what OpenGL 2.0 offers in a neutral way. No need to code lot of things if only 5% of the user can see them. You can be sure, that i will be able to see it some day (in a couple of months - next videocard is allready planned). So this shouldn't hinder you. 2) you think it's a good idea to enhance a bit some visual aspect of Flightgear or you think that only simulation count and all the rest is useless eye candy ;) No, i like eye candy very much and see it as an important factor for flightgear beside the physic code and other things. So when you can improve it, then please, improve it. :) Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
On Thursday 26 May 2005 23:21, Frederic Bouvier wrote: I found that there are more dynamic libraries under Linux than under Windows, and that they are distribution dependant. If you can compile something statically, I am ready to put it on sourceforge for download. -Fred Ok, i tried first to compile a normal none static version, but i had the following problems. First, installing CGAL systemwide is a nightmare, so i decided against it to do that. I circumvented it by unpacking cgal in my home directory. Then i run install_cgal -i and built the CGAL Libraries. After that, i quit the installer and tried to install FGSD (CVS version) by using the following command ./configure --with-cgal=/home/oliver/CGAL-3.1 make Then i had an error message relating CGAL and the file compiler_config.h. I fixed it by creating a directory called CGAL in my fgsd directory. In this CGAL directory i created a symlink to /home/oliver/CGAL-3.1/include/CGAL/config/i686_Linux-2.4.27_g++-3.3.4/CGAL/compiler_config.h This solved it, i know this is a cheap hack, but it worked for me. :) After that i went back to compile fgsd. But now i get the following compiler error: make[2]: Entering directory `/home/oliver/x/src/cvs/fgsd/src' if g++ -DHAVE_CONFIG_H -I. -I. -I. -I.. -I/usr/X11R6/include -I/home/oliver/CGAL-3.1/include -I/home/oliver/CGAL-3.1/include/CGAL/config/ -DDRAW_WITH_TEXTURES -g -O2 -MT triobject.o -MD -MP -MF .deps/triobject.Tpo -c -o triobject.o triobject.cpp; \ then mv -f .deps/triobject.Tpo .deps/triobject.Po; else rm -f .deps/triobject.Tpo; exit 1; fi triobject.cpp: In member function `bool FGSD_TriangleObject::saveObject(const std::string, const char*, unsigned int)': triobject.cpp:1422: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [triobject.o] Error 1 make[2]: Leaving directory `/home/oliver/x/src/cvs/fgsd/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/oliver/x/src/cvs/fgsd/src' make: *** [all-recursive] Error 1 The used gcc version is 3.3.4. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
On Saturday 28 May 2005 00:18, AJ MacLeod (email lists) wrote: If you'd read the README you'd have seen a note to that effect; apparently 3.2 and 3.4 are OK, but 3.3 produce this error. No, I didn't read the README either, until after I'd found this out the hard way! Thank you for the info. Now i hope, that someone else can create such a static binary FGSD release, because I won't update my gcc version soon, because this is a big task and i do that only when i upgrade to the next version of my Linux distribution (in this case Slackware). Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
On Wednesday 25 May 2005 23:31, Frederic Bouvier wrote: Gerard ROBIN a crit : Wonderfull. You where using FGSD, does it mean you are working on windows. because on the linux side i could never make a compilation of that program. It is a long time ago i wondered to make sceneries of France in Provence. It is tricky but doable. Look at the release notes of version 0.3.0 on sourceforge ( click on the version in the file page ) BTW : Martin contributed an IRIX build -Fred What about offering static binary builds of FGSD for linux with everything included? This might increase the package size but is very easy to use. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
On Sunday 15 May 2005 16:21, Melchior FRANZ wrote: Only one thing is annoying, and others said that this is not the cloud code's fault: the cloud movements due to view banking. That's a pain in the butt. And flying through clouds was better in the old 3d cloud code: The new one drags the puff layers to the side like theater backdrops, which is a bit irritating if you have bad visibility already, and try not to crash into the landscape. ;-) Is it possible to combine the old and new 3d cloud code? In other words using the new 3d cloud code for large distances and the old 3d cloud code for close distances? Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Disabling the top menu
On Friday 29 April 2005 18:34, Ben Morrison wrote: Is it possible to hide the menu at the top of the screen? Yes, press F10. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] realistic scenery
On Tuesday 19 April 2005 22:52, Paul Surgeon wrote: On Tuesday, 19 April 2005 08:21, eagle monart wrote: i tried to used fgsd but terrains are made in triangles not in squares an it looks impossible to tile what you want . a It's impossible to tile textures properly in FG. FG uses an irregular triangle mesh and not square tiles like MSFS. Even if you managed to tile a texture across the mesh you would still end up with a mess around the edges of the texture where the triangles don't end on the edge of the textures. You would need to clip a texture into the mesh for it to work properly and in the process you end up with a grid or semi tile based system. :) How does X-Plane 8.1 solve that? A nice textured scenery on an irregular grid: http://www.global-scenery.org/ Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Anyone using TomTom POI files for scenery
On Wednesday 02 March 2005 11:14, Melchior FRANZ wrote: * Martin Spott -- Wednesday 02 March 2005 10:46: Your intention is clear, it's just that I don't share everyting of it. ... and you don't need to. Just keep the number of 512x512 textures as low as possible, especially for objects with reduced importance. Not everyone has a fast and cheap internet connection. Sigh ... What we need is support for texture compression in flightgear and textures that are stored in such a way, in other words a file format that uses and supports texture compression. Not using texture compression is a waste of video memory. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Friday 28 January 2005 05:14, Curtis L. Olson wrote: I'm told there is a way to do this with shaders, but plib/ssg doesn't support shaders. :-( Curt. What happended about Manual Massing's new alternative terrain engine? http://www.mail-archive.com/flightgear-devel@flightgear.org/msg29480.html Does it support shaders and does it get now integrated into Flightgear? As far as i understood, it is using its own scene graph so we would be independent from the plib library and this allows us to use VBO, shaders and multitexturing without the need to wait for an update of the plib library. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Friday 28 January 2005 18:20, Curtis L. Olson wrote: Oliver C. wrote: On Friday 28 January 2005 05:14, Curtis L. Olson wrote: I'm told there is a way to do this with shaders, but plib/ssg doesn't support shaders. :-( Curt. What happended about Manual Massing's new alternative terrain engine? http://www.mail-archive.com/flightgear-devel@flightgear.org/msg29480.html Does it support shaders and does it get now integrated into Flightgear? As far as i understood, it is using its own scene graph so we would be independent from the plib library and this allows us to use VBO, shaders and multitexturing without the need to wait for an update of the plib library. It's not that easy. The plib scene graph lib is woven throughout our code. 3d models of aircraft, 3d cockpits, all the animation code is hardwired into plib structures. Are there plans or better a planned release date when the missing features will get added into plib? We will look into Manual's new terrain engine, Nice to hear. :) but there again, he may have a few small areas available to fly in, but it's not just a drop in replacement that gives us the whole world. From what I've seen it does a nice job of drawing quality terrain. But it's unclear how well that will scale to the entire world. Certainly the data sizes to represent the whole world for this engine will be extreme. Probably 100x what our current approach uses. But this is because of the landsat textures. I was more interested in the engine itself. At the moment we use generic textures to cover the whole world. This approach is okay, because it allows us to keep the scenery data small. But the thing that is missing at the current engine is multi texturing. With multi texturing we could still use generic textures but the scenery would look more diversified because multitexturing allows us to add random distorting textures to the base textures, the result is more variety. MS does use the same approach at their FS2004, but we can't use this at the moment because plib and the existing FG engine does not (AFAIK) support multitexturing. The other nice things which the alternate Engine allows and are good to have are the imposter in the background, VBO rendering etc. So i was more thinking about using this new engine to render generic multitextured sceneries instead of large landsat images. But of course it would also be good to be able to use landsat images for selected areas like large cities. This is some *very* difficult stuff and we need to move slowly and cautiously to avoid breaking everything. I understand. Are there ways to follow the changes and engine integration? Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
The real problem is that it's hard to get detailed textures for the whole world (and storage hungry!!). What I'd like to experiment with later on is to let a classifier run over the globally available 28.5m landsat textures, and use the resulting classifications to generate missing detail at runtime. But first things first... There is a trick to create textures with a 15 m resolution based on landsat data: http://www.terrainmap.com/rm29.html BTW: Is it possible to use this classifier to create a new vector map with a larger landcover variety than Vmap0? Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Friday 28 January 2005 19:44, Curtis L. Olson wrote: Oliver C. wrote: Are there plans or better a planned release date when the missing features will get added into plib? You'll have to ask the plib people. Steve is very persnickety about this section of the code and I suspect he may not allow significant changes unless he does them himself, especially in the area of shaders. And he is another extremely busy person so who knows when that will ever happen. That sounds not so good. :( Are there alternative ways when this is taking to long like a special plib specially designed for the needs of flightgear? (in other word, a fork?) Be a bit careful here. I've seen a demo of Manuel's engine and it was extremely impressive. However, it was only for a very small area. It's unclear if he's put any thought at all into paging textures or terrain data in real time without pauses. I also don't know how he handles his coordinate system and if he suffers map maker distortion problems, or if he can maintain a seamless wgs-84 oblate ellipsoid earth? If he has all these things, then that's wonderful, he has done an impressive piece of work. I'm not trying to be critical here, I'm just pointing out that this is *very* difficult stuff. It's one thing to do a nice little demo, it's something else entirely to tackle all the issues of doing this in a full sim where you are trying to model the world seamlessly. I understand. Are there ways to follow the changes and engine integration? I assume when something is workable, it will be in CVS. Thank you for answering all my questions. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
On Friday 28 January 2005 02:18, Curtis L. Olson wrote: Tiago Gusmão wrote: Altough the billboard itself always faces the POV, you can still set the normal the way the real light would be pointing to, them set a diffuse light on the POV and enable backface culling. I suppose performance hit should be minimal for TnL hardware. The normal only affects lighting. Backface culling is done based on the winding of the triangle. You would still see the light from every direction. Regards, Curt. What about setting only one point at the beginning of the runway and then calculating an angel between it and the normal of the billboard. When the angel is 90° or - 90° the billboard is turned off when it is 90° or -90° then on. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OT: Open Source 3d video card
This might be very interesting for people who are looking for a new 3d video card with full open source drivers: http://kerneltrap.org/node/4622 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 January 2005 11:05, Erik Hofman wrote: Vivian Meazza wrote: Thanks for this explanation. Why does it only seem to work one way? The description 'enhanced lighting' is not particularly helpful. Oh, this is about enhanced (runway) lighting. That's a different story, I was talking about specular highlights which the original was talking about also. No, i was talking about enhanced runway lightning, this is what i get when running flightgear with this option: --enable-enhanced-lighting I was not talking about specular highlights. Why is it so expensive of frame-rate? This is very hardware and driver dependent. Some OpenGL features are just not implemented in hardware on some display adapters. The only consumer videocards we have today are from Ati and NVidia, do their newest models support this? If not, then we should move it to the advanced options. I also want to mention, that MS FS2004 has something similar, but without framerate drop, so there must be another way to display runway lights in such a way. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 January 2005 15:05, Dave Martin wrote: I've also been confused by the monumental frame drop that even the simple runway lighting can produce at airports such as EGLL. And I do have a fairly hefty system which has been known to run graphical behemoths like Doom3 at a fair lick. The obvious response from the 'non-programmers' perspective ie: 'user' is: Why on earth do these little dots bring my new Model-X video card to its knees? So what's the crack? ;) Dave Martin I assume that this feature is not supported by the hardware on the consumer video cards. So OpenGL falls back to software mode. That's why we get 1-3 fps here. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
--(en/dis)able-enhanced-lighting This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg Very nice. But i suggest to move the enhanced-lighting option into the advanced menu or at least adding a notice in brackets that tells the user that this option can lead to a large frame rate drop. Because this is what happens on a typical end-user computer when this option is activated. Here i get 1 fps at night when i activate this option on an Athlon 2000+ with a Geforce 4 Ti 4200 videocard, without it, i get 39 fps. End users tend to activate everything and then they wonder why FlightGear is running at 1 fps, that's why it is better to hide such options in the advanced menu. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Bugs in FlightGear when flying over the North Pole
Today i tried to fly over the geographical North Pole in FlightGear and found the following bugs. 1. There were some bugs with the scenery alignment, Just take a look at these pictures: Here we have a long ditch on the ocean floor. http://tinypic.com/view.html?pic=1fd2fq When we fly a little farther into the northern direction we have a big hole at around 88*58.502 N on the ocean floor: http://tinypic.com/view.html?pic=1fd2mt I also want to mention, that there is no ice visible at the North Pole. BTW: It would also be a good idea to have polar lights. 2. When reaching waypoint 90*00.000 N the sun plays crazy. I know, in winter it shouldn't be possible to see the sun at the North Pole at day time but because of the big hole in the ocean (see above) it was possible to see what happens with the sun. It flys around the center of my view point. This shouldn't happen, Maybe it is better to use a spherical model for the sun and stars instead of a sky dome or by making he sun the center of the 3d world (in other words using 3 coordinate systems instead of 2. One coordinate system for the sun as a center of the solar system, one planet coordinate system and one local coordinate system to avoid floating point precision problems) Is this technically possible? 3. When trying to fly straight over the North Pole (waypoint 90*00.000 N) the latitude co-ordinate freezes instead of counting backwards. And the longitude runs in a cycle trying to find the correct co-ordinate. So it was not possible to fly over the North Pole, the only thing that worked was to turn the ufo 180 degrees and fly back. Then i also have a question, what co-ordinates are used for the magnetic North Pole in FlightGear? Is this implemented? Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Licensing (was Re: [Flightgear-devel] Aircraft downloads)
On Wednesday 19 January 2005 22:28, David Megginson wrote: On Wed, 19 Jan 2005 21:08:38 +, Lee Elliott [EMAIL PROTECTED] wrote: While it can make things difficult, or even impossible, one can't force people to use a licence. One can't tell people what to do... I don't think anyone has suggested that, except to set it up as a strawman to argue against. The only suggestion I've seen is using the flightgear.org web site to promote only models that are GPL or freer. I think that makes sense -- think of the extra, free publicity as a carrot for the people who are willing to go open source or better. Yes, this is exactly, what i meant. People can use unfree licenses, but when doing this, it should not be advertised on the main flightgear.org website, at least not for free and not in a way that the visiter gets confused. They should look after their own way to do the advertisement. The flightgear.org website should not be misused for such none free addons. And when those people who want to distribute their none free addons really want some advertisement on the flightgear.org website, then they should pay for this. But the point is, the flightgear.org website shouldn't do this advertisement for free or near the other GPL'd addons. It should be clear for a visiter that such thing is an advertisement and not a part of the page. So a simple link would not be okay. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] v1.0 musings (was: Aircraft included in base package)
Personally i think it is too early for a 1.0 release. Here are some points why: 1. The gear problem, Jon Berndt allready mentioned it. On the ground the planes just don't feel good. 2. An in game GUI for every user (not only Windows users) is missing. This is IMHO a big must for a 1.0 production release. fgrun.exe is okay for the beginning or development versions but not for a production release. A production release should really have a menu that is running inside of flightgear as a part of flightgear and not as an outside application. Especially when we aim at end users. Sure, some will say that this is not necessary for a simulator, but end users will base their review and valuate it on that. 3. Another requirement for a 1.0 production release is a way to change the aircraft when flightgear is allready started. 4. If you want to reach the end user, you need a learn to fly interactive in game tutorial (how far is fligttutor progressed?). In other words, documentation is not enough for the marked today. Releasing flightgear 1.0 without a learn to fly interactive flying tutorial leads to a situation that users download flightgear, start it, don't know what to do. take a tour around San Francisco to see what flightgear has visually to offer and then delete it because they don't know what to do next. We should show to the users that there is a lot more possible than just only seeing flightgear as an eye candy city tour software. 5. A way to switch the airport from an in game menu when flightgear is allready started. It should also be possible to select an airport by country or city name. In my opinion we should delay the official FlightGear 1.0 release until the above is fixed. This would mean at least 4-10 more releases, so an estimated release date for a 1.0 release could be somewhere in 4th quarter 2006. Don't understand me wrong, but i don't want to see people complaining about the above missing features and saying that flightgear is crap because those things are missing. We should take in mind, that people, especially magazines tend to review and compare Open Source applications with the competition (X-Plane, MS Flight Simulator etc.) when the application reaches version 1.0, And a 1.0 version is the first and most important version number for a production release because people judge later versions on experiences they made with version 1.0. Any bad reviews because the above is missing are not good reviews. FlightGear has gone a long way, but imo it is still far too early for a 1.0 production release. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] v1.0 musings
On Thursday 20 January 2005 21:25, Frederic Bouvier wrote: Oliver C. wrote FlightGear has gone a long way, but imo it is still far too early for a 1.0 production release. Hey, there is a life after 1.0. Why not 1.1, 2.0 etc... Trying to reach the perfection the first shot is the best way to drag our 0.x forever that make feel that FG is still in beta and unusable for the mass. I partly agree with you, sure FlightGear shouldn't get another Duke Nukem Forever (a game, that will be released when it's done) but i consider a working inbuilt GUI (see Giles Robertson's message), a way to switch the aircraft and airport when flightgear is running as basic features which are a must have in a 1.0 production release. So if you ask: Is FG still beta or unusable for the mass. I would answer this with: Yes, it is. As long as the above features are missing. After your message I though about the idea of moving the gear problem and learn to fly feature to the 1.1 release, this might be okay, but the other above mentioned features really need to get into 1.0. For a 2.0 release i could see when i look in my crystal ball features like thermal lift support, working 3d clouds and Multitexturing and Vertex Buffer Objects (VBO) support, but the latter 2 features depend on plib 2.0 or a switch to another scene graph library. People will be happy to see FG progressing beyond 1.0 and will wait new versions with more expectations. I agree, but people could also see the 1.0 version as a beta version when there is no inbuild GUI or way to switch the aircraft and airport. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft downloads
On Wednesday 19 January 2005 17:25, Curtis L. Olson wrote: Durk Talsma wrote: Another thought: There are some other hangar pages out there like the ones made by David Culp and Wolfram Kuss. Would it be an idea to add a link to these pages at the bottom of the aircraft download page? Presumably we can't merge these pages due to licence incompatibilities... Sure, if someone can send me current links and if those pages are currently maintained, I'll definitely link to them from the aircraft download page. Curt. Personally i think that it is not a good idea to advertise aircrafts for FlightGear that are not free. Here's the reason why: Advertising none free aircrafts or scenery addons on the flightgear website could lead to a common behaviour that people tend to not release their aircrafts or addons under the GPL license when other more restrictive ways like simple Freeware licenses are possible and accepted. This has also many other disadvantages like: - you can't modify or correct the aircrafts, scenery addons etc. - aircrafts and scenery addons might get outdated or incompatible to newer versions of FlightGear - users are forced to collect their aircrafts and scenery addons from different places, which is a bad thing, because it is extremly cumbersomely and annoying. MS Flight Simulator people know what i am talking about. FlightGear should make use of the fact that it is open source, it allows users to get everything in one piece without the hassle to visit hundreds of different websites. - the amount of GPL'd flightgear data like aircrafts and scenery would grow slower when simple freeware addons are okay and linked to on the flightgear website. That's why i think we should refuse to advertise none GPL'd aircrafts and scenery addons for flightgear on the flightgear website. BTW: I saw that there is a GPL'd Boeing 707 and Raytheon T-6A Texan II on Dave's hangar website, could these two aircrafts be added to the main flightgear website and ftp servers? http://home.comcast.net/~davidculp2/hangar/hangar.html Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380 - Virtual Screen inside Flightgear driven by SVG commands?
On Tuesday 18 January 2005 08:21, Paul Surgeon wrote: On Tuesday, 18 January 2005 04:40, Ampere K. Hardraade wrote: On January 17, 2005 02:25 pm, Paul Surgeon wrote: We already have too many empty 3D models in FG without working FMCs, FMSs, ECAMs, NDs, etc. Paul It will be nice if you can implement these systems, perferablely by Nasal so that they can be flexible. Running Nasal code in the rendering loop to do tons of work would not be a very good idea in my opinion. I've looked through an A320 FCOM manual and it would take many thousands of lines of C++ to accomplish a half functional aircraft. I don't think Nasal is the tool for the job. What I would need to create a aircraft with glass cockpits is : 1. A way to code self rendering OpenGL intruments. i.e. The renderer loops through the intruments and lets them do their own rendering. 2. A central processing blackbox that contains all the logic for the aircraft that also get's updated in the rendering loop. The blackbox will simulate/handle the hydraulic and electrical systems, generate and feed the display data to the intruments, handle the logic for failures, receive input from all the simulated aircraft sensors and cockpit switches, etc. There are far too many aircraft specific systems than could ever be handled by FG properly. An aircraft like this is a simulation of its own. How would I model for instance the ECAM switching on an A340 at the moment? The switches are located on the center pedestal but the displays are on the center panel. Would I have to add them to the properties tree? How do I control the logic of those switches? If there is a failure I must be able to override those switch settings and display the failure without changing the position of the switch. Then the pilot must be able to acknowledge and override (yet again) those failures on the display. How do I tell the PFD or ND to display the ECAM screens? (This can be done on real Airbus aircraft) How do I close solenoid X if switch A is in postion Z but hydraulic pressure is between 1000 and 1500 psi and there is a failure on the blue hydraulic system? FlightGear cannot and should not ever have to handle all these aircraft operating procedures. 3. A generic communications bus that can be used to hook instruments/switches and the blackbox together. Using a handful of sockets is not a good way to do it and properties maybe be a bit messy and I would require hundreds of them. Unfortunately this is going to sit on the backburner for a long time as it's tons of work to implement, I'm already too busy with other projects and I doubt anybody else would be willing to tackle it in the near future. Paul Is it possible to implement a sort of virtual screen (like a texture but vector driven not bitmap driven) inside the Flightgear Window that can be put anywhere in the flightgear 3d world, for example inside of a cockpit as a instrument display. Flightgear should then offer this screen to outside applications and do the rendering but the commands what should be rendered is given by the outside application which are running outside of flightgear? The commands that are sent to flightgear should be simple 2d vector primitives, to make sure that this solution is flexible enough to display everything. FlightGear receives the 2d vectors primitives and put those on a virtual screen inside the FlightGear 3d world. For example a screen display in the cockpit. Doing it this way would allow to do the complexity of such glass cockpits outside of flightgear. And if we change atlas from bitmap to vector graphics we could just sent from atlas the 2d primitives that flightgear could than render on a virtual screen inside flightgear. As a 2d vector describing language we could use SVG. FlightGear then needs only a SVG parser that puts the visuals on a screen inside flightgear. There are allready SVG libarys available that do render SVG primitives in OpenGL, maybe we could use such a library instead of writing an own SVG parser. Take a look at this one: http://svgl.sourceforge.net/ What do you think about such a solution? Is this possible? Best Regards. Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sidewinder Precision Pro Patch
On Tuesday 18 January 2005 11:07, Erik Hofman wrote: Oliver C. wrote: Hello and Merry Christmas! i fixed the inverted view elevation setting for the sidewinder precision pro joystick because the view elevation was inverted under windows. I've committed this file to CVS after changing the NASAL'ified section to be two separate sections, one for UNIX and one for Windows. Erik Thank you, it works great now. But there is one problem. I found another bug, when I checked the complete config file today. This is my fault, sorry. I missed to fix a small error in my last patch for the shift button which was from days back, when i played around with the xml settings to test a fix for the invert view elevation bug. Here is the correction. I added a diff file to this email. button descGear Up./desc number unix8/unix windows9/windows /number repeatablefalse/repeatable binding commandproperty-assign/command property/controls/gear/gear-down/property value type=double0.0/value /binding /button Sorry for circumstance this was my fault. Could you apply this patch too? Best Regards, Oliver C. --- sidewinder-precision-pro.xml 2005-01-18 16:12:33.0 +0100 +++ ../sidewinder-precision-pro.xml 2005-01-18 16:15:01.0 +0100 @@ -259,25 +259,11 @@ windows9/windows /number repeatablefalse/repeatable - !-- -binding + binding commandproperty-assign/command property/controls/gear/gear-down/property value type=double0.0/value -/binding - -- - unix -binding - commandproperty-assign/command - property/controls/gear/gear-down/property - value type=double0.0/value -/binding - /unix - windows -binding - commandview-cycle/command -/binding - /windows + /binding /button ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sidewinder Precision Pro Patch
On Tuesday 18 January 2005 16:29, Erik Hofman wrote: Oliver C. wrote: I found another bug, when I checked the complete config file today. This is my fault, sorry. I missed to fix a small error in my last patch for the shift button which was from days back, when i played around with the xml settings to test a fix for the invert view elevation bug. This has been committed. Erik Thank you. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft downloads
On Tuesday 18 January 2005 22:05, Christian Mayer wrote: Hi, the web page is comming along nicely! There's one thing that could be added: when you click on the thumbnail a normal sized picture should open. It also would be great if there'd be a thumbnail of the cockpit for that plane as well. CU, Christian And some information data and text about the aircraft itself. This could be also usefull later for a in game menu. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft downloads
On Tuesday 18 January 2005 22:05, Christian Mayer wrote: Hi, the web page is comming along nicely! There's one thing that could be added: when you click on the thumbnail a normal sized picture should open. It also would be great if there'd be a thumbnail of the cockpit for that plane as well. CU, Christian One thing more, that i have forgotten in my last message. A way to filter the aircrafts on the webpage by their status, fdm and aircraft type. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Joystick configurationc hange (Was: Upcoming v0.9.8 release)
On Monday 17 January 2005 11:40, Erik Hofman wrote: Oliver C. wrote: In this case it depends on the following: Does a definition get not defined when a value is missing? Not anymore, I have committed a patch that ignores platforms that re not specified within the number/number section. This is a heads up for all joystick users: I have thought of possible problems with this, but the only one I could think of is when axis n= is defined for platforms that are not defined within the number/number section. !! This is bas behavior and should be corrected !! Sounds okay for me. But what about such a solution: axis descView Elevation/desc number unix5/unix windows7/windows /number low repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-pitch-offset-deg/property windows step type=double-1.0/step /windows unix step type=double1.0/step /unix /binding /low high repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-pitch-offset-deg/property windows step type=double1.0/step /windows unix step type=double-1.0/step /unix /binding /high /axis Could that be implemented? IMO it is cleaner and more intuitive. (intuitive because it was the first thing, that i tried by try and error to make the axis inverted. :) ) Or what about this one? binding commandproperty-adjust/command property/sim/current-view/goal-pitch-offset-deg/property step type=double windows-1.0windows unix1.0/unix /step /binding Is it possible to implement such a behaviour? Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Upcoming v0.9.8 release
On Sunday 16 January 2005 03:50, Curtis L. Olson wrote: Now that plib-1.8.4 is released, I'd like to push forward with the FlightGear v0.9.8 release. Does anyone have any changes that need to get put in before the release? Regards, Curt. Yes, i am waiting for the insertion of my joystick patch from 24 Dec. 2004: http://www.mail-archive.com/flightgear-devel@flightgear.org/msg28933.html If there's something wrong with this patch, then please tell me. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Upcoming v0.9.8 release
On Sunday 16 January 2005 13:13, Erik Hofman wrote:
Oliver C. wrote:
Yes, i am waiting for the insertion of my joystick patch from 24 Dec.
2004:
http://www.mail-archive.com/flightgear-devel@flightgear.org/msg28933.html
If there's something wrong with this patch, then please tell me.
Would this work just by defining two sections for the specific bindings,
like this:
axis
descView Elevation (Default)/desc
number
unix5/unix
/number
low
repeatabletrue/repeatable
binding
commandproperty-adjust/command
property/sim/current-view/goal-pitch-offset-deg/property
step type=double1.0/step
/binding
/low
high
repeatabletrue/repeatable
binding
commandproperty-adjust/command
property/sim/current-view/goal-pitch-offset-deg/property
step type=double-1.0/step
/binding
/high
/axis
axis
descView Elevation (windows)/desc
number
windows7/windows
/number
low
repeatabletrue/repeatable
binding
commandproperty-adjust/command
property/sim/current-view/goal-pitch-offset-deg/property
step type=double-1.0/step
/binding
/low
high
repeatabletrue/repeatable
binding
commandproperty-adjust/command
property/sim/current-view/goal-pitch-offset-deg/property
step type=double1.0/step
/binding
/high
/axis
Erik
The problem is, how do you define which section should be used by which OS?
That's why i added a new property.
There's also another solution by reading the assigned joystick button number
with a nasal script like this way:
Pseudo Code:
script![CDATA[
# invert Axis under Windows
if(Joystick Button Number == 7)
{
!-- Windows solution --
view.panViewPitch(-1);
}
else
{
!-- others --
view.panViewPitch(1);
}
]]/script
But someone on irc.flightgear.org told me, that this is more a hack than a
solution, so i decided to use the other solution by adding a new property to
the property system.
Best Regards,
Oliver C.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Upcoming v0.9.8 release
On Sunday 16 January 2005 21:07, Erik Hofman wrote: Oliver C. wrote: Would this work just by defining two sections for the specific bindings, like this: axis descView Elevation (Default)/desc number unix5/unix /number axis descView Elevation (windows)/desc number windows7/windows /number The problem is, how do you define which section should be used by which OS? If you look at the code above you see that one has only an axis number for unix and the other has only an axis number defined for windows. I was wondering if this is accepted by the current code already. Erik Now i understand what you meant. In this case it depends on the following: Does a definition get not defined when a value is missing? For example, when this is the definition: axis descView Elevation (windows)/desc number windows7/windows /number then what happens when FlightGear is started on a unix system? Does this definition get ignored or do we have an error because of a NULL assignment? axis descView Elevation (windows)/desc number -- NULL for a UNIX OS? -- /number Does anyone know more about that? Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Google adwords?
On Thursday 13 January 2005 23:45, Curtis L. Olson wrote: Here is a screen shot of about as unobstrusive of an add as I can configure: http://www.flightgear.org/~curt/tmp/fgfs-ads.jpg I don't like the place where this advertisement is set. The size is ok, but it should not be at the sidebar. I prefer it this way like in this example: http://tinypic.com/18ydn6 Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] I have a GMax 3D model, help me exporting to 3ds file format
On Wednesday 12 January 2005 16:19, Roberto Inzerillo wrote: Hi all, I made a little 3D model (representing a Villa in my city) with GMax but I can't export it to 3ds file format (basic GMax packet does not include that function). Does anybody have the 3ds export plugin, can you please convert it for me so that I import the model with proper lat/long/alt into the F.G. scenery set? Thx, Roberto I don't know about a 3ds export plugin for GMax, but what you could use now is a MD3 export plugin for GMax: http://mojo.gmaxsupport.com/Sections/Plugins.html After you have your 3d model in MD3 format you can import it in Blender www.blender.org with the MD3 import Script for Blender: http://www.icculus.org/~phaethon/q3/md3import/md3import.html In Blender you can then export it to the AC3D *.ac file format and use it for FlightGear. Hope that helps. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
On Wednesday 12 January 2005 00:12, Martin Spott wrote: ftp://ftp.uni-duisburg.de/FlightGear/incoming/ We will post some sort of submission guidelines soon - with 'soon' meaning as soon as automated database import works reliable. Just not to miss the chance for a short note, what we consider to make sense for being added to the collection. We need 1.) A 3D model - if not already present, 2.) one or more locations (lat/lon/orirntation) that apply to the model, 3.) a short description of the model and/or its author, 4.) a screenshot or at least a thumbnail - if available. This would be also very wise: 5.) an attestation that the contribution is put under the GPL license by the author and that he is entitled to do this. In other words to make sure that he is not using parts for his contribution like textures, photos, 3d objects etc. that is not his own work and incompatible to the GPL. Like things that are closed source, only freeware or under another incompatible license. This point is IMO important because for example in the MS Flight Simulator freeware-scenery community it can happen sometimes that some freeware projects are legally not okay. To prevent that the same happens in the flightgear world such an attestation would be usefull. People should know what they can do and what not, before they contribute their work. This is especially necessary in an area where work is often based on other data like maps (gis data), photos, textures etc.. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Is this usefull for flightgear/jsbsim?
In a german news page (http://www.pro-linux.de/news/2005/7690.html) i found an article about a software called OpenFOAM which was put under the GPL license a few days ago and can do the following: The OpenFOAM (Field Operation and Manipulation) software package can simulate anything from complex fluid flows involving chemical reactions, turbulence and heat transfer, to solid dynamics, electromagnetics and the pricing of financial options. I read the word turbulence and thought that perhaps this could be usefull somehow for flightgear or jsbsim but i am not shure about that, so i mention it here maybe you know it better if this could be somehow usefull for flightgear/jsbsim. Here's the website of that software: http://www.opencfd.co.uk/openfoam/index.html Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
On Tuesday 04 January 2005 11:37, Christian Mayer wrote: Oliver C. schrieb: | Could you change the file format from *.tgz to *.tar.gz? | | I ask because *.tgz is used by Slackware as a package format (it's a tar.gz | file with a install script in it) and this is leading to confusion | when you have Slackware *.tgz files and *.tgz files that are no Slackware | packages on your harddrive. | | So file endings called *.tar.gz would be much better than *.tgz. And what about *.zip? Linux can easily unzip those and Windows users have the unzipper already comming with their OS (when it is WinXP...) Yes, but *.zip is not a free format. Using *.zip would be like using *.mp3 instead of *.ogg 7zip or bzip2 would be acceptable, both are free like tar.gz. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
On Monday 03 January 2005 22:23, Curtis L. Olson wrote: Here's a preview of something I'd like to have working in time for the 0.9.8 release. As we go forward it would be nice to have thumbnail images for each aircraft. I've also included the ability to read a version string out of the aircraft-set file, and where one doesn't exist, they script will just use the current date (that the archive is assembled) as the version. http://www.flightgear.org/Downloads/aircraft.html Regards, Curt. Could you change the file format from *.tgz to *.tar.gz? I ask because *.tgz is used by Slackware as a package format (it's a tar.gz file with a install script in it) and this is leading to confusion when you have Slackware *.tgz files and *.tgz files that are no Slackware packages on your harddrive. So file endings called *.tar.gz would be much better than *.tgz. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Sidewinder Precision Pro Patch
Hello and Merry Christmas!
i fixed the inverted view elevation setting for the
sidewinder precision pro joystick because the view elevation was inverted
under windows.
This new script in the config file checks on what OS flightgear is running
by using a new flightgear property called /sim/operating-system and assigns
the according value to the view.panViewPitch nasal command.
The new flightgear property /sim/operating-system is set in the
options.,cxx file.
See the attached options.patch file.
Best Regards,
Oliver C.
--- alt/options.cxx 2004-12-25 00:22:56.0 +0100
+++ neu/options.cxx 2004-12-25 00:26:00.0 +0100
@@ -179,6 +179,33 @@
#endif
fgSetString(/sim/logging/priority, alert);
+// OS-Detection
+#if defined(WIN32)
+fgSetString(/sim/operating-system, windows);
+#elif defined( macintosh )
+fgSetString(/sim/operating-system, macintosh);
+#elif defined( unix )
+{
+fgSetString(/sim/operating-system, unix);
+
+/*
+#if defined(__linux__)
+ fgSetString(/sim/operating-system, linux);
+#elif defined(__sun__)
+ fgSetString(/sim/operating-system, solaris);
+#elif defined(__CYGWIN__)
+ fgSetString(/sim/operating-system, cygwin);
+#elif defined(__FreeBSD__)
+ fgSetString(/sim/operating-system, freebsd);
+#elif defined(__sgi__)
+ fgSetString(/sim/operating-system, irix);
+#endif
+*/
+}
+#else
+fgSetString(/sim/operating-system, unknown);
+#endif
+
// Features
fgSetBool(/sim/hud/antialiased, false);
fgSetBool(/sim/hud/enable3d, true);
?xml version=1.0?
!--
* Bindings for Microsoft SideWinder Precision Pro joystick.
*
*
* Axis 0: ailerons
* Axis 1: elevator
* Axis 2(Unix)/3(Win) (twist):rudder
* Axis 3(Unix)/2(Win):throttle
* Axis 4(Unix)/6(Win) (hat): view direction
* Axes 5(Unix)/7(Win) (hat): view elevation
*
* In game Name: Action: Button name on Joystick:Value:
* Button 0 (trigger): all brakes 0001
* Button 1: view-cylce 0002
* Button 2: elevator trim up0004
* Button 3: elevator trim down 0008
* Button 4: flaps upButton B0020
* Button 5: flap down Button A0010
* Button 6: left brake only Button C0040
* Button 7: right brake onlyButton D0080
* Button 8(Unix)/9(Win): gear up Shift Button0100(unix), 0200(Win)
$Id: sidewinder-precision-pro.xml,v 1.20 2004/11/08 00:29:00 Oliver Exp $
--
PropertyList
nameMicrosoft SideWinder Precision Pro/name
nameMicrosoft SideWinder Precision 2 Joystick/name
nameMicrosoft Microsoft SideWinder Precision Pro (USB)/name
axis n=0
descAileron/desc
binding
commandproperty-scale/command
property/controls/flight/aileron/property
squared type=booltrue/squared
/binding
/axis
axis n=1
descElevator/desc
binding
commandproperty-scale/command
property/controls/flight/elevator/property
factor type=double-1.0/factor
squared type=booltrue/squared
/binding
/axis
axis
descRudder/desc
number
unix2/unix
windows3/windows
/number
binding
commandproperty-scale/command
property/controls/flight/rudder/property
factor type=double1.0/factor
/binding
/axis
axis
descThrottle/desc
number
unix3/unix
windows2/windows
/number
binding
commandnasal/command
scriptcontrols.throttleAxis()/script
/binding
/axis
axis
descView Direction/desc
number
unix4/unix
windows6/windows
/number
low
repeatabletrue/repeatable
binding
commandproperty-adjust/command
property/sim/current-view/goal-heading-offset-deg/property
step type=double1.0/step
/binding
/low
high
repeatabletrue/repeatable
binding
commandproperty-adjust/command
property/sim/current-view/goal-heading-offset-deg/property
step type=double-1.0/step
/binding
/high
/axis
axis
descView Elevation/desc
number
unix5/unix
windows7/windows !-- axis is inverse in WinMe, please fix this --
/number
low
repeatabletrue/repeatable
binding
commandnasal/command
script![CDATA[
# invert Axis under Windows
if(getprop(/sim/operating-system) == windows)
{
view.panViewPitch(-1);
}
else
{
view.panViewPitch(1);
}
]]/script
Re: [Flightgear-devel] GUI Improvements was: Things to do to improveFlightgear
On Friday 17 December 2004 14:50, Norman Vine wrote: Matthew Law writes: Personally, I'd prefer to see a nice OpenGL based GUI like some of the other simulators and, dare I say it, games. With this method you can throw out native look and feel and just have a very nice looking functional user interface that works on any platform with OpenGL support. PUI PLIB's GUI can make much nicer looking interfaces then what is currently done in FGFS. Interesting, could you show us an example screenshot of a game that uses PUI in this way? Several commercial games use it for their GUI jsut for the reasons you described including at least one EA title What commercial games use PUI? Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
On Thursday 16 December 2004 10:38, Thomas Förster wrote: Am Mittwoch 15 Dezember 2004 14:48 schrieb Oliver C.: On Wednesday 15 December 2004 07:35, Paul Surgeon wrote: I hope we either drop PUI (plib's UI) or at least do a major upgrade to it. We use PUI in the menus at the moment and in my opinion the widgets look absolutely GHASTLY. What could we use instead of PUI? What gui library uses OpenGL? For integration with existing desktops it's possibly best to use their native libs. QT for example provides an OpenGL widget, so all of the gui (menu, dialogs) could be native QT Widgets. Also if the sim runs in the context of a GUI it will be easy to switch between them at startup, i.e. 'fgfs --gui-gnome' runs a GTK based GUI, whereas 'fgfs --gui-qt' runs a qt based one. Don't know about possible performance issues, though. :-( Using native none OpenGL GUI APIs for a in game menu ist not a good idea, this might be acceptable for a remote display menu but not for a in game menu. The reason is, that openGL GUIs allow to display the menu in game in front of the 3d scenery that's not possible with none openGL Guis because you need to switch from OpenGL to a 2d mode to display them. This is mainly a comfort, performance and usability issue. The other reason is, QT is not free on MS windows systems (only the X-Window version is under GPL) and GTK does offer OpenGL support only with an addional GTK OpenGL library which depends on 3 other gtk related librarys for OpenGL support, the next problem is that the OpenGL Window runs on top of the GTK window and not the other way. Using QT and win32 for each plattform makes no sense, we need a GUI API that is crossplattform compatible and runs directly in a OpenGL window. Gigi the library Dave proposed could do that job. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
On Thursday 16 December 2004 05:13, Ampere K. Hardraade wrote: A user may be able to access a lot of planes due to his/her experience points, but it will be necessary to pass the tests before he/she can truly unlock these planes. Similarly, a user may unlocked a lot of scenarios, but enough experience points must be gained so that the required aircrafts in some of the scenarios can be unlocked. Personaly i don't like it when features (especially things like airports or areas) are looked and require to do some other things first. But it would be ok to lock only the learn to fly lessons, so that everyone needs to fly each lessons in the correct order first. As for the Scenario Flight option, I think it will be better to include it within the Learn to Fly experience or the Quick Flight option, and leave the space for an option to the multiplayer menu in the future. I think there is enough space to put the multiplayer option below or above the Sceneraio Flight options. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
On Wednesday 15 December 2004 07:35, Paul Surgeon wrote: I hope we either drop PUI (plib's UI) or at least do a major upgrade to it. We use PUI in the menus at the moment and in my opinion the widgets look absolutely GHASTLY. What could we use instead of PUI? What gui library uses OpenGL? Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
On Wednesday 15 December 2004 00:02, Ampere K. Hardraade wrote: 2) Use a menu to select starting aircraft and airports. We should init the game with very minimum code and then present to the user a nice menu with the logo of FG and two scrollbars, one for the aircrafts and one for the airports. This data could be updated dynamically based on which aircrafts we have in the installation directory I have a similar idea as well, so do many other people. We should have a main menu that allows the user to select: - Start a game - Start a multiplayer game - Configuration - Quit Each option, except the last one, will lead to a new page. For example, the Start a game page will allow the user to pick the aircraft, choose an airport, select the weather, etc. The configuration page will allow the user to setup joysticks, change graphic settings etc. I can do a quick sketch if anyone wants to see my design. =P What would you think about the following options: - Learn to Fly - Quick Flight - Scenario Flight - Configuration or Settings - Quit The Option Learn to Fly should be an interactive in game tutorial that teaches a new user how to flight. Flitetutor might be here the ideal thing. flitetutor.sf.net This is imo a very important feature, because people who never learned to fly try flightgear and don't know what to do or how to fly. In the end this leads to the the situation that they use flightgear only to fly around and look at the scenery, after that they don't know what to do next, they get bored and uninstall flightgear. If they knew how to do vfr or instrument flight or could learn it they would have a new challenging goal. The option quick flight allows the user to just jump in, after the user has seleceted the aircraft, the airport and set the weather condition. The scenario flight could be a list of flights where the user chooses one scenerio. Each sceneraio is a task where the user needs to achieve a goal. Like flying with a cessna from Geneva to Milan over the Alps Or Flying from Miami to Havana at low fuel. etc. The rest of the options is the same you described before. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] User home
On Sunday 12 December 2004 18:29, Paul Surgeon wrote: What do people think about having a ~/.fgfs folder? I need a place to be able to read and write user data. .fgfsrc could also live in there too. I would prefer a folder called ~/.flightgear instead of ~/.fgfs. This is an usability issue because a folder that is called ~./fgfs is in my opinion too meaningless for the ordinary user. When we call it ~/.flightgear everyone will know what it is all about. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New Sidewinder Precision Pro Joystick settings
On Tuesday 09 November 2004 09:58, Erik Hofman wrote: Oliver C. wrote: This file has been committed. Thank you, but i think (after looking into cvs today) that you checked in another file, it is different to my one and doesn't have the fixes. I committed the one you sent to the list, except that I added the nasal bindings for flaps already. No, even if i consider your new nasal bindings this is not my file. I had completly other button bindings. Brake is still on button 1. Changing view is not available, gear is missing too, And the flaps and left and right brake buttons are still crossed like they were before and different on windows and linux. I also added some informations about the joystick assignment in my file this part is missing too in cvs. You must have changed and committed another file because this is in no way my one. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New Sidewinder Precision Pro Joystick settings
On Monday 08 November 2004 18:33, Erik Hofman wrote: To fix this we would need some sort of property to inverse the axis independly for windows and unix. If you know a way to do this feel free to fix this. You might want to take a look at the Saitek/X45.xml configuration file, especially the ones that use nasal in their binding. Ok thanks for the hint, I will look into that and try to fix it. This file has been committed. Thank you, but i think (after looking into cvs today) that you checked in another file, it is different to my one and doesn't have the fixes. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New Sidewinder Precision Pro Joystick settings
Hello, i modified the joystick settings for the Sidewinder Precision Pro joystick. Now all buttons and axis react the same way in unix and windows except for the view elevation binding which is on axis 5 in unix and 7 in windows. Here the windows axis is inverse, the unix version is not. This means if you move the hat down in unix you will look down if you move the hat down in windows you will look up. To fix this we would need some sort of property to inverse the axis independly for windows and unix. If you know a way to do this feel free to fix this. I also added some more button bindings. With button 1 you can now switch between the views, The brakes where moved from button 1 to button 0 because this button was unused and users who want to switch from MS Flight Simulator to FlightGear will like that too because the buttons are now used the same way on both sims. With the unused button 8 (shift button), you can now retract the gears. I also fixed the arrangement for the 4 buttons called A, B, C and D left to the stick. With button B you can now turn the flaps up and with button A down. With button C you can use the left brake and with button D the right brake. Before those changes the windows and unix bindings were different and somehow unordered (crossed). I tested this new Joystick settings in Windows Millenium and Linux Slackware 10 with Flightgear 0.9.6 for windows and the newest cvs version from today for Linux. The xml file with the new joystick settings is attached to this e-mail. Best Regards, Oliver C. ?xml version=1.0? !-- * Bindings for Microsoft SideWinder Precision Pro joystick. * * * Axis 0: ailerons * Axis 1: elevator * Axis 2(Unix)/3(Win) (twist):rudder * Axis 3(Unix)/2(Win):throttle * Axis 4(Unix)/6(Win) (hat): view direction * Axes 5(Unix)/7(Win) (hat): view elevation * * In game Name: Action: Button name on Joystick:Value: * Button 0 (trigger): all brakes 0001 * Button 1: view-cylce 0002 * Button 2: elevator trim up0004 * Button 3: elevator trim down 0008 * Button 4: flaps upButton B0020 * Button 5: flap down Button A0010 * Button 6: left brake only Button C0040 * Button 7: right brake onlyButton D0080 * Button 8(Unix)/9(Win): gear up Shift Button0100(unix), 0200(Win) $Id: sidewinder-precision-pro.xml,v 1.20 2004/11/08 00:29:00 Oliver Exp $ -- PropertyList nameMicrosoft SideWinder Precision Pro/name nameMicrosoft SideWinder Precision 2 Joystick/name nameMicrosoft Microsoft SideWinder Precision Pro (USB)/name axis n=0 descAileron/desc binding commandproperty-scale/command property/controls/flight/aileron/property squared type=booltrue/squared /binding /axis axis n=1 descElevator/desc binding commandproperty-scale/command property/controls/flight/elevator/property factor type=double-1.0/factor squared type=booltrue/squared /binding /axis axis descRudder/desc number unix2/unix windows3/windows /number binding commandproperty-scale/command property/controls/flight/rudder/property factor type=double1.0/factor /binding /axis axis descThrottle/desc number unix3/unix windows2/windows /number binding commandnasal/command scriptcontrols.throttleAxis()/script /binding /axis axis descView Direction/desc number unix4/unix windows6/windows /number low repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-heading-offset-deg/property step type=double1.0/step /binding /low high repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-heading-offset-deg/property step type=double-1.0/step /binding /high /axis axis descView Elevation/desc number unix5/unix windows7/windows !-- axis is inverse in WinMe, please fix this -- /number low repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-pitch-offset-deg/property step type=double1.0/step /binding /low high repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-pitch-offset-deg
Re: [Flightgear-devel] The Rant
On Saturday 06 November 2004 13:53, Innis Cunningham wrote: Hi All Just had a look on the seedwiki at the aircraft todo list. Who wrote that rubbish. Please do me a favour and don't call my work rubbish. How many 747's,737's,DC10 and the like have you seen with HUD's.So why is it considered to be a must on these aircraft.If we are going for realism then nearly all commercial aircraft do not have HUD's along with 99% of all other non military aircraft.So if we are more a non military sim lets put this HUD rubbish to bed. The aircraft todo list was created somewhere between Dec. 2003 and Jan. 2004 (later it was put on the seedwiki page) at that time those mentioned planes had nearly no cockpit instruments, so a virtual HUD was a must when you need to know your heading, speed and altitude. The HUD is also very practical when you are in an outside view. There's nothing wrong with removing the HUD from those aircrafts, but before that, please complete the 3d cockpits. Aircraft don't have lighting of one kind or another.Since as far as I am aware this is because FG currently has no such lighting and that night lighting can only be achived by using emissive material on objects we want to see at night.Is this not the way the 3D instruments are made to show at night.Please correct me if I am wrong. The fact that FlightGear doesn't have aircraft lightning support doesn't matter. When FlightGear is ready for aircraft lightning support this list can be usefull to complete the aircraft lightning of each aircraft step by step. So the rule is: First write everything down, that is a bug or missing and then remove it later when it is fixed. Jet blast not visible.Untill FG can model heat haze then on commercial aircraft this cant be modeled. Same rule mentioned above applies to here. Nozele doesn't change shape with thrust.Never saw one that did(other than the Concord(notice a pattern here)). Nearly all military jets do this. An example aircraft is the F16. The F16 in FlightGear can't do that at the moment. If you never saw a F16 in real life, you can also look at the F16 in the flight simulator Falcon 4.0, there this nozzle effect is visualized. Flaps move with reverse thrust.Maybe you can tell me what aircraft that happens on other than military. The thing what i meant with this are the speed brakes at the engines of the big airliners (747, 737 etc.) that are used when thrust is on reverse. The bad description is because of the fact, that my english is not the best, so if you can do better please fix this in the aircraft todo list. The textures are not quite right.If that is the case fix them if you think they can be improved and I will be the first to conratule you.But don't say that is a problem with the model or the way it flies. There was a texture problem on the 737 in some of the earlier FlightGear versions. This has been fixed in one of the later version but the aircraft-todo list wasn't upgraded. Please, if you fix some bug in FlightGear mentioned in the aircraft-todo list, then upgrade the aircraft-todo list too. And as everbody knows texture quality is governed by the size. And everybody knows that more eye candy can attract more volunteers for this open source project. There's nothing wrong with adding a couple of more textures to the aircrafts. Modern videocards have plenty of video memory (64 MB and upwards) and only a little amount is used by flightgear today. The only rule to abide is the correct balance between eye candy and performance. No pilot models in the cockpit.Since these models consume about 1000 vertex each which is about 3 3d instruments.Would it not be better to have the instruments than the eye candy. I think both are important and 1000 vertex more is not a lot for a modern computer with a modern graphic card. So if the todo list is to be realisitic should it not contain only the things that are missing on the real aircraft not a list of things that are neither available yet in FG (eg lighting) or never part of the real aircraft in the first place. An aircraft without a pilot can't fly. (No, you need more than an autopilot and where not talking about drones :) ) Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Linux joystick problem following recent plib js updates
On Monday 18 October 2004 05:44, Eric L Hathaway wrote: I'm running FlightGear on an old linux box (RedHat 7.3) For the first time in a few months, I tried out a freshly updated version of FlightGear this afternoon, with plib, SimGear, and FlightGear all pulled from CVS. I noticed that the hat switch on my venerable Thrustmaster FCS joystick wasn't working. I checked the 'js_demo' program that comes with FlightGear and found that it wasn't reading the joystick's name (in my case, Analog 2-axis 4-button 1-hat FCS joystick). The name was an empty string, and thus I was getting the default joystick bindings instead of those for my joystick. . Thanks, -Eric I have the same problem here with my Sidewinder Precision Pro joystick. And i tested it on Linux and Windows and this problem occurs on both platforms. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] VBOs - performance test results
On Friday 15 October 2004 22:04, Horst J. Wobig wrote: I just tried VBO's on my SuSE 9.1 nvidia GF2 MX driver 6111 and xfree86. VBOs are available but do not behave as expected. I get additional stuff rendered :-( Seems to be a bug in the driver when used with MX cards. Maybe it's just the GF2 MX. Now I'm curious how much improvement can be expected on other cards. If somebody wants to try it on his box: just fetch lesson 45 from http://nehe.gamedev.net. On windows this should compile without problems, on linux you need sdl. On my system I just had to untar it, then make and run. It tells you if VBO is available and the framerate with 32k triangles. With #define NO_VBO you can turn VBO off and check the difference. Horst Here are my results: With VBO enabled i get 150-195 frames/s With VBO disabled i only get 90-120 frames/s So VBO makes a difference of 60-75 more frames per seconds. I made this benchmark test on a computer with an Athlon Thunderbird 1 GHz CPU, 512 MB SDRam and a Geforce 4 4200 Ti with 64 MB videoram. The OS was Slackware 10 running a Linux kernel Version 2.4.26 and the NVidia driver version was 53.36. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Open Scene Graph
On Friday 15 October 2004 22:25, Roman Grigoriev wrote: Hi guys! Dlist can't solve the promplem IMHO The right answer is VBO I don't understand why you don't want to include this nice feature to flightgear All modern hardware support them. I wrote them year ago and Erik made a patch you've got really nice speedup when using VBOs Also I met in simgear/scene makefile fgsg maybe it be flightgear scenegraph? Meaybe you discuss it - plib is old we can make own scenegraph Instead of writing our own scenegraph we could switch from Plib to Open Scene Graph. Open Scene Graph is in active development and has a large user base, even commercial games use it. From the OSG introduction: Open Scene Graph is published under the Open Scene Graph Public License (a relaxed version on the LGPL) which allows both open source and closed source projects to use, modify and distribute it freely as long its usage complies with the OSGPL. The website: www.openscenegraph.org http://66.220.18.234/introduction/index.html And with osgSDL we could osg together with the SDL library where the latter one could be used for the rest, like input and such things. http://osgsdl.sourceforge.net/ Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ANN: TaxiDraw-0.2 Released
On Tuesday 12 October 2004 13:39, David Luff wrote: Unfortunately, Robin doesn't seem to have any data for download at the moment. Hence I've put the last set of X-Plane data up on my site *temporarily*. Please check back to Robin's site and download the updated data when available. Please report any bugs or annoyances with this version - Great work, but i have one wish. Could you implement a feature that allows to switch the given default dimension unit between feet an meter? For example in the taxiway propertie menu the length and width of a taxiway is given in feet, but personally i prefer meter because it is easier for me to visualise a dimension when it is given in meter. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Landsat 7 data for FlightGear
On Saturday 25 September 2004 06:18, Georg Vollnhals wrote: Hi all, it is a wonderful idea to improve FlightGear with satellite image derived textures, SRTM elevation data and a new grafic-engine as Manuel Massing [EMAIL PROTECTED] suggested. 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. Low-res satellite textures are an improvement to more reality-feeling but there are big limitations, too. Therefore I made a short demonstration what you can expect from 30m/pix (Bremen/Bremerhaven) and improved 30m/pix (Aosta) Landsat 7 data. One question, how did you do the color correction when merging the three visual channels (1 blue,2 green and 3 red) of the Landsat data together to get one real looking RGB truecolor picture? I allways get false color pictures. Do you know any tools that do the color correction automatically? Best Regards, Oliver C. ___ 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 ....
On Saturday 25 September 2004 20:38, Boris Koenig wrote: 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. There is one way how this could be done. And this would be to create our own full open source ATC network that is capable to speak to FlightGear and X-Plane and Microsoft's Flight Simulator. Because if this software is capable of connecting to all 3 flight sims, there is a chance, that a community for this ATC network will grow very rapidly. Of course, this will lead to a leaving of people at the other 2 ATC networks like VATSIM and IVAO when our ATC network allows to talk with FS2004 clients too, but this is their problem when they don't want to work with us now. Open source can be very powerfull, can't it? :) In the end this would become a totally new project That's the only problem, someone would have to do this work and write the software for such an ATC network and this wouldn't be a small project. nothing that could be run under FlightGear's umbrella easily, at least not if it's supposed to become 'successful' If it supports all 3 major flight sims and have software that can compete with the other ATC networks at the beginning, it will be successful on the long run . Because that's the thing real open source software can do best. just my 2 cents. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Another (3.). ATC online network
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/ Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Torque Network Library
On Saturday 25 September 2004 21:53, Boris Koenig wrote: 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. What do you think about this open source network library: http://www.opentnl.org/ http://sourceforge.net/forum/forum.php?forum_id=369903 It is a library created from the network code of the Torque Engine. The Torgue Engine was used by the famous and commercial multiplayer game Tribes 2 and this game had one of the best network codes out there for games and simulations. TheTorque Network Library is available under 3 licenses, one of them is the GPL, so it would be a library we could use for Flightgear. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBsim with Solaris8/Sparc and GCC-3.4.1
On Friday 17 September 2004 17:30, Jon Stockill wrote: Boris Koenig wrote: If you keep receiving errors/warnings about underquoted definitions in M4 macros, it's most likely really pretty much the same thing as with gcc: the autotools folks intend to become much pickier, too - so, in that case it's not really a FG issue but rather the new versions enthusiastically complain about macros that their old counterparts happily accept - so that kind of issues does not occur if you aren't up to date :-) That's exactly what I got. It was severe enough to prevent it from doing its job though, which is why I downgraded. Downgrading is not necessary, you just need to delete some files that where generated by the old autotools. After that FlightGear and Simgear compile without errors on Slackware 10 with the new autotools. It only gives some warning messages, but you can ignore them, Take also a look in the mailinglist archive, i had the same problems before there you can read how i solved it exactly. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] compilation of current cvs version fails
Hello, Today i tried to compile the current cvs version of flightgear and get the following error messages: make[2]: Entering directory `/home/oliver/x/src/cvs/flightgear/source/src/Main' g++ -DPKGLIBDIR=\/usr/local/share/FlightGear\ -g -O2 -D_REENTRANT -L/usr/X11R6/lib -L/usr/local//lib -o fgfs bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../../src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Replay/libReplay.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Traffic/libTraffic.a ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgroute -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructure -lsgenvironment -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm -lopenal -ldl -lm /usr/local//lib/libsgclouds3d.a(camutils.o)(.text+0x634): In function `CamMinMaxBoxOverlap(Camera const*, Vec3float const*, float const (*) [4], Vec3float const, Vec3float const)': /home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:165: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x676):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:166: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x6b4):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:167: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x6f2):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:168: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x71f):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:169: undefined reference to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' /usr/local//lib/libsgclouds3d.a(camutils.o) (.text+0x74f):/home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:170: more undefined references to `EdgeMinMaxBoxIsect(float const*, float const*, float const*, float const*, float*, float*)' follow /usr/local//lib/libsgclouds3d.a(camutils.o)(.text+0x8ac): In function `CamMinMaxBoxOverlap(Camera const*, Vec3float const*, float const (*) [4], Vec3float const, Vec3float const)': /home/oliver/x/src/cvs/SimGear/simgear/scene/sky/clouds3d/camutils.cpp:180: undefined reference to `GetMinMaxBoxVerts(float const*, float const*, float (*) [3])' collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 make[2]: Leaving directory `/home/oliver/x/src/cvs/flightgear/source/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/oliver/x/src/cvs/flightgear/source/src' make: *** [all-recursive] Error 1 Any ideas to fix this? I tried this on Slackware 10.0 with the current cvs version of SimGear, OpenAL and Plib. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compilation of current cvs version fails
On Saturday 24 July 2004 17:41, Curtis L. Olson wrote: I'd start by recompiling and reinstalling all of simgear ... if you've upgraded your compilers recently, code compiled with the new C++ compiler may not be able to link against code compiled with an older version. Regards, Curt. Thank you very much, that worked. :) I forgot to do a make clean in my SimGear CVS directory. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with autogen in SuSe Linux Pro 9.1
On Friday 23 July 2004 06:12, Dave Perry wrote: The warnings are explained. by running info as documented and are not an issue. Questions 1. Has anyone had a similar problem with SuSe 9.1? Yes, i did with Slackware 10.0. 2. Any ideas how to get past this? To solve that error just delete your autom4te.cache folders in all your cvs trees (plib, simgear, flightgear-source etc.) and do a cvs update -Pd and ./autogen.sh again. This should solve the problem. The other error messages like underquoted definition of AM_PATH_GSL are just warning messages, you can ignore that, developers shouldn't. This is because automake 1.8,x handles macro definition files a lot stricter, that's the reason why these warning messages come up. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problem with game menu when switching to wireframe mode
Hello, today i played around with the wireframe mode which can be activated in-game by starting flightgear with the option --enable-wireframe or by setting in the property menu /sim/rendering/wireframe to true. But when i do this the in-game menu gets useless because the fonts used in the in game menu get scarcely visible. To solve that, the in-game menu and its fonts shouldn't be affected by setting the wireframe mode to true. Can someone fix this? Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTutor = A FlightGear based interactive Training Concept
DISABLE background processing of the visual data. Simply because it isn't needed - If that's also done by stopping the view, then that's okay. It would be also very nice, if FliteTutor could be used for in flight lessons. For example a voice of a pilot instructor could be played that explains what to do next, like turning to heading 230. Then the pilot instructor points to the compass which gets in this moment highlighted by for example a box that is surrounding the compass so that the student pilot knows which instrument was meant by the pilot instructor. Or it would also be very usefull if an 3d objects like a runway could be highlighted with an arrow in the 3d scenery by placing a 3d arrow over the runway. Such a feature would also be very helpfull when the pilot instructor wants to teach the pilot student how to do taxiing on an airport or how to land on an aircraft carrier etc.. And for showing how to fly a special flight maneuver we could use transparent squares with visible borders that are placed in the air and describe the flight path that should be flown. BTW. to describe an instrument we could also display the cockpit of an airplane and then zoom the instrument (not the pilot view) to the pilot view by moving the instrument closer to the pilot view. Then the background (cockpit, 3d scenery etc.) could be faded out so that we only see the instrument on the flightgear window with for example a black or white background. After that we could continue with the steps Boris Koenig described above in his example. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile failing on Redhat 7.3
On Wednesday 07 July 2004 17:44, Jon S Berndt wrote: On Wed, 7 Jul 2004 15:30:14 - Jim Wilson [EMAIL PROTECTED] wrote: There doesn't seem to be support for the std::numeric_limits references added in the June update. Can we work around this? e.g.: In file included from FGFCSComponent.h:46, from FGDeadBand.h:40, from FGDeadBand.cpp:40: ./FGJSBBase.h:41:18: limits: No such file or directory From FGJSBBase.h: #include limits Looks like Mathias added this. It looks like it compiles under CygWin. It's present under IRIX, and it's also present under whatever Linux Mathias is using. Strange. In any case, the #include limits statement needs to be put in the correct #ifdef block, similar to the rest of the c++ headers. I had the same problem on Slackware 8.1. The problem was, that the STL library on Slackware 8.1 was too old. Updating the STL library should solve the problem. The easiest way to do this is off course by updating the distribution. ;) My question is now, does it really make sense to create a work around for this, isn't it better to update the STL library? IMHO the STL makes sense, it saves space, keeps the code clean, programmers don't need to invent the wheel a second time and you will need the STL anyway so why shouldn't we use it? Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Anyone read polish? Space-Island
On Friday 11 June 2004 14:22, Erik Hofman wrote: Curtis L. Olson wrote: Does anyone read enough polish to double check that everything these guys are doing is within the spirit of the GPL? http://www.allegro.pl/show_item.php?item=26723501 As far as I can decipher it (based on a number of words I do somehow recognize) it's just another magazine article that is quite positive about FlightGear. It seems to mention it is Freeware and talks a bit about the amount of scenery available. I wouldn't worry too much. BTW some days ago i found this website: http://www.space-island.de This website is from a company that offers flight simulator rides on their motion plattform simulators. They use for their B747 Power - Flights programme Flightgear as flight simulator. These screenshots should prove that: http://www.space-island.de/bildergallerie.html Now what i wanted to mention is, they note and thank nearly everyone on their website that helped them putting this project up but they don't mention or thank the flightgear community and developers at all: http://www.space-island.de/partner.html I am not sure but is this behaviour really okay from a GPL perspective? Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] keyboard mapping
On Thursday 27 May 2004 21:44, Jim Wilson wrote: Josh Babcock said: snip This leaves several keys totally unused, I would suggest reserving defyuDEFYU and their CTRL modifiers for aircraft and putting a note as such in keyboard.xml so people don't create conflicts in their local configs and also so that airplane builders will know what keys shouldn't step on their user's custom keyboard layouts. Lastly, while we're at it, get rid of any key bindings define in the code and put the mappings in keyboard.xml. I'm not sure if there are issues with doing that though. That will help with custom layouts a lot. Comments? Josh As a former advocate for this idea, I'd like to relate some reservations on the idea reserving aircraft specific keys. One question that comes to mind is how many things do we actually need an aircraft specific binding for? There could be a problem with duplicating functions, mapped to different keys for different aircraft. Just because something isn't universal to all aircraft doesn't mean we shouldn't just bind it with the rest. Most everything is not really unique. Certainly it'd be helpful to some day have a dialog for changing bindings similar to most any simulator or game. An effort well spent would be in coming up with a way to update bindings and save them in a user file, rather than forcing end users to hand edit an xml config file to modify bindings. If bindings were named with sensible names and then listed in a dialog with a scrollable window similar to the property browser, then the task would be fairly straight forward. But having a list of named bindings that changes depending on selected aircraft would needlessly complicate any effort such as this, especially for an end user. For this reason, and the consideration of true necessity, I think we should just put everything in the keyboard.xml until we use up all the bindings. At some point we'll just have to choose bindings or look for a more efficient way of handling something. (For some reason I keep thinking of emacs :-)) with resignation If there really is strong incentive to have aircraft specific bindings then I'd make the list very small. Start with the minimum that anyone needs (e.g. one key with and without shift and ctrl). If someone needs more than add another one. That's it. Put dummy bindings in keyboard.xml to reserve the key and document that it is aircraft specific. /with resignation I am no longer in agreement that reserving a block of them is a good idea. Best, Jim I agree with that. BTW it would be also very helpfull to have some sort of keybinding help window, that shows a list of all key bindings that are used or needed to control the currently chosen aircraft. This would make a lot things easier, especially for users that are new to flightgear. The key to show this keybinding help menu should of course be standardized and everywhere (regardless of which aircraft is currently chosen) available. I would suggest to use the F1 key for this task, because F1 is often used for such sort of help menu in many software products. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d audio and doppler shift
On Wednesday 28 April 2004 09:57, Erik Hofman wrote: It's even better. You can hook up your 5.1 amplifier and speaker set using ALSA: http://floam.ascorbic.com/how-to/alsa5.1 Erik Impressive, that worked, thank you for the hint: Make a ~/.openalrc, we are telling OpenAL that we want surround sound and we want to use ALSA instead of OSS. (define speaker-num 4) (define devices '(alsa)) (define alsa-out-device surround40:0,0) Now i have 5.1 surround too. It's outstanding, using OpenAL was IMO a very good decision. :) Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Todo List
On Sunday 11 April 2004 08:33, Erik Hofman wrote: Hi, I just noticed the just updated Aircraft Todo List at: http://www.seedwiki.com/page.cfm?doc=Aircraft%20Todo%20Listwikiid=2418wpi d=142747 Thanks, for having a look on the todo-list. I also sent this todo-list to the flightgear-mailinglist when i put it on the wiki page, but the mail was too big so i needed to wait for mailinglist moderator approval. Because keeping this todo-list up to date is a lot of work and because i can't know every thing about every aircraft everyone is welcome to correct or add entries to this aircraft-todo-list. There are a couple of issues for the F-16 which I want to address here: + f16 General Dynamics F-16 f16-3d General Dynamics F-16 w. 3d cockpit + Outside: - flaps are in wrong position by default after starting flightgear - flaps can't be triggered This is because flaps are flight computer controlled for the F-16. I suspect that about every (military) aircraft designed after the F-16 does have the same behavior. Thanks, i will correct that entry. - strobe and landing lights are not available They are and they are bound to the right properties, but the properties are not triggered by any key stroke. Ok. - there are no flaps when using reverse thrust There is no reverse thrust available. Thanks for the info, i allready thought about that issue but i wasn't sure if fighters do have such a thing. (The big airliners do have that) But what is with braking parachutes? Does a f16 have braking parachutes? 3d Cockpit: - no cockpit light at night available - rudder/stick control is available but not animated The stick in the F-16 really doesn't move at all (well it does move about 1 mm because pilots couldn't adjust to a non moving stick), but it is driven by the pressure pushed on the stick, not the movement itself. Thanks, i didn't knew that, i will correct this entry in the todo-list. - switches and levers available but can't be triggered with the mouse Don't expect that I will add the functions for all switches any time soon, there are just too many, and many of them have no use for a civilian flight simulator anyhow. Don't worry, some entries (like missing windscreen wipers etc.) are added to make sure that this issue is known for later fix in the near future. I think it is better to write every down, even if it is a very small problem or error. That will make sure that we don't froget it later. - no cockpit instruments available - cockpit is only barely textured I'm not sure there will be much texturing since using different colors is often enough for cockpits and it saves on texture usage. I don't think so, video Ram gets larger every year and someday flightgear users will want also have some eye candy and photo realistic cockpits and aircrafts. - no pilot present in 3d cockpit I'm still in doubt I like the idea of having a pilot in the cockpit. If there is one you want it animated (rudder, throttle and stick) like the Hunter (which is btw a very nice job), but when it's animated it isn't realistic anymore because then you would see the gear handle move without the pilot getting his hands from the throttle. Perhaps we will have someday some kind of skeletal animation system in flightgear for the pilot that makes such things, even triggering the gear handle easier to do. General: - engine sound in cockpit does not differ from outside engine sound - engines can't be turned off - hud can't be turned off Yes it can. Did you test using the new SDL code, that might cause this problem. For the source code, i used the cvs version before 1. April because i needed a working version and there were so many issues with the source code in the last view days so i abandoned using the newer source code. So this was not a version with SDL code. But the data directory with the aircrafts was up to date, i updated it on 9. April. - aircraft is not set on the correct elevation when starting flightsgear, lowest part of the aircraft is approximately 0.20 m below the ground Note, this is not to complain about this list, just to clarify some things and show that it's often not as simple as you would expect. Yes, i know, the same applies for the todo-list it should NOT be seen as a list of complains. It is just to make things easier like discovering things that wasn't thought about before when the aircraft was created or just to write down errors that where discovered by the users etc. I hope that list will help improving fligthgear and its aircrafts. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Todo List
On Sunday 11 April 2004 09:52, Vivian Meazza wrote: I've added a few comments to the entries for the Hunter and Seahawk. Thanks a lot. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: source/src/Main fg_os_sdl.cxx, 1.5, 1.6
On Thursday 08 April 2004 15:11, Jim Wilson wrote: You know with the huge vid memories and fast GPUs now, and the fact that LCD's are fixed resolution anyway, it won't be too many more years before mode switching will be a thing of the past! The problem with LCDs is, that their physical resolution is too low to allow a nice picture qualitiy at low or non native resolutions. The picture qualitiy is in this case bad, because of rounding errors when switching from a native to a low none native resolution. For example: If the native mode is 1280*1024 and you want to run 800*600, then this means that 1.6 pixels must simulate the 800 pixels in the witdh and 1.70666 pixels the high. 1.6 pixels is not a high value and it is not an integer value, you will have rounding errors. But now let's assume we have a LCD monitor with a very high native resolution of 3200*2400 then this allows the following resolutions nearly negligible or no rounding errors: 800*600 - 1/4 of the native resolution - whole integer numbers! 1600*1200 - /1/2 of the native resolution - whole integer numbers! 640*480 - 1/5 of the native resolution - whole integer numbers! So 3 none native modes on such a display that look perfect because you don't have rounding errors. Even none native modes that can't be displayed correctly look better because you have a lot more pixels available to compensate the rounding errors. For example for a mode like 1024*768 we have 3.125 pixels to compensate this 0.125 rounding error instead of only 1-2 pixels on todays LCD monitors. An we also should not forget the physical resolution grid is also a lot finer, so we won't notice rounding errors. The conclusion is, in future we still need and can use mode switching because the LCD monitors will have a higher resolution that can easily compensate rounding errors in none native modes. And the faster GPUs don't solve the problem of mode switching, because the new games do run slow on your 1.5 year old GPU so you will still need to run a lower resolution to get enough frames with your old GPU. This means you still need mode switching in future. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: source/src/Main fg_os_sdl.cxx, 1.5, 1.6
On Wednesday 07 April 2004 22:57, Curtis L. Olson wrote: So I still don't understand, is SDL unable to open a window covering the entire desktop but with no window decorations? Or can this be done? Or can support for this mode of running be built in and optionally enabled at runtime via some option or combination of options? I don't have an answer to this question, but you could ask this question on the official SDL newsgroup: gmane.comp.lib.sdl or the SDL mailinglist: http://www.libsdl.org/mailman/listinfo/ Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
On Tuesday 06 April 2004 20:16, Norman Vine wrote: Out of curiosity what can't you do today that would make FlightGear better because we are using GLUT that you would do differently today if we were using SDL and what exactly is it that would make FGFS better. Using SDL has many positive effects. 1. It is widely accepted, easy to use and even commerical companys do use it for their commercial games. This means also that there is a large user base that can jump in and improve flightgear. 2. (my favourite one) A very nice input and event handling system. It uses a virtual keysym to each key on the keyboard which map to some level to the operating systems's keyboard scancodes. So it is very easy to nicely support non US keyboard layouts plattform independet. You can also use the same input infrastructure to support joystick, mouse and other input devices the same easy way. 3. It can be easily used together with OpenAL as our default sound API and SDL sound as a backup system in the case OpenAL is not supported on other plattforms. IMHO OpenAL is a must, because it is crossplattform capable and allowes us to easily implement 3d sound in flightgear, doppler shift effects, attenuation and hardware sound accerlation (if the soundcard supports it). It is also very easy to use because it is rather similar to the way OpenGL works and is used. 4. SDL has its own portable threading API which is plattform independent. That feature could be very usefull. And much more. I think GLUT is dead, we should realize that and SDL seems to be the best solution today to replace GLUT. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Fullscreen to desktop switching?
Hello, is it possible to implement some kind of Fullscreen (Game mode) to Desktop Window switching? IMHO this is a necessary feature for Flightgear and should be on the todo list. I read on the mailinglist that someone is working on a de-glutification of flightgear, maybe this is the right time to implement such a feature now? FYI because it could be usefull: The typical key kombination in Games for a Fullscreen to desktop switching are the ALT+Return key under Linux. Nearly every commercial linux game does use this key kombination for this task. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fullscreen to desktop switching?
On Sunday 04 April 2004 20:53, Erik Hofman wrote: Oliver C. wrote: Hello, FYI because it could be usefull: The typical key kombination in Games for a Fullscreen to desktop switching are the ALT+Return key under Linux. Nearly every commercial linux game does use this key kombination for this task. Ever tried ALT+TAB, that works for me. Erik Wow, that's usefull, thanks. :) But we should anyhow implement such a ALT+Return key kombination because you can't switch the application with the ALT+Tab key into a real window mode. This means, it is still running in some kind of fullscreen mode and not in a window, what if you want to use the sim in another resolution in the window mode than in the fullscreen mode or when the resolution of the desktop mode is smaller then the fullscreen (game) mode? For example: desktop: 1024*768 fullscreen: 1600*1280 Or: desktop: 1024*768 fullscreen: 640*480 The Alt+Tab key kombination is also generally used for Window Manager/Desktop Environment specific things. KDE uses Alt+Tab for example to switch beween Applications, but you can't switch the Application from a fullscreen mode into a real Desktop Window mode with this key kombination. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-setting fuel levels at start-up
On Thursday 01 April 2004 18:56, David Megginson wrote: My Warrior has a mechanical fuel pump on the engine's accessory drive as well as an electric backup pump, which I turn on for startup and during takeoff and landing. In the worst case, I can always pump the primer by hand, though mine has lines into only three cylinders. Maybe this is a feature which should be put on the todo list. When the fuel pump is damaged (a fuel pump failure etc.) it would be a nice feature if you have to do this fuel pumping then mechanically by hand. We could for example simulate this mechanical fuel pumping by pushing a jostick or 2 keys left and right. Similar to some of the old computer sports game from the 80th. :) Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Outsider Opinion
On Sunday 28 March 2004 12:04, Melchior FRANZ wrote: I don't care at all for trademarks on our aircrafts. If a trademark holder has a problem with free advertisement, he'll tell and we'll remove and make sure that his company will *never* again be considered for the free sim. I don't think that will work that way. :( Today this works imho this way: They will admonish you and you will pay and be forced to remove it otherwhise you will pay a lot more, but you will pay. I know this is very pity and sad but this is the typical way it works today. :( You can see this everywhere. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Outsider opinion - really the last one
On Monday 29 March 2004 03:19, Arnt Karlsen wrote: ..I dunno your guys or FLY! licensing for users contributions like add-on planes, were you required to give up your copyrights? ..such an policy might deny you the right to put your own add-on FLY! planes into FlightGear, because you have given up your copyrights and transferred them to someone else. If he live in Germany or in some other European countrys this does not matter, because you can't transfer your Copyright to someone else in Germany (and some other European countrys). Such a contract would be voided by law. In other words a copyright holder remains the copyright holder. That's why the Free Software Foundation Europe invented the FLA as a workaround: http://www.fsfeurope.org/projects/fla/fla.en.html Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] applications for FGFS
On Friday 26 March 2004 10:15, Erik Hofman wrote: Alex Perry wrote: I've been looking for some new FGFS applications, compared to two years ago, but none seem to be public ... as far as the website is concerned anyway. Do any of you know of some that you just haven't mentioned on the list yet ? These are the ones I have collected in the past: FG Run: http://sourceforge.net/projects/fgrun/ FG Kicker (comparable to fgrun): http://users.pandora.be/ceppe/linux/fgkicker.htm FlightGear Airport Database (unmaintained now): http://www.stockill.org.uk/fgfs/ Pretty Poly Editor: http://prettypoly.sourceforge.net/ FlightGear Scenery Designer: http://fgsd.sourceforge.net/ Atlas: http://atlas.sourceforge.net/ FG Flight Planner: https://sourceforge.net/projects/fgflightplanner/ FlightGear Aviation Training Device: http://fgatd.sourceforge.net/ FG Multiplayer hacks/ideas: http://fg-server.sourceforge.net/ http://sourceforge.net/projects/fgcombatzone/ http://www.kbs.twi.tudelft.nl/People/Students/L.Otte/ http://www.aurora-solutions.co.uk/~cumulas/index.shtml Erik And Taxidraw, another usefull tool for Flightgear Development. http://www.mail-archive.com/[EMAIL PROTECTED]/msg19682.html Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
