[Flightgear-devel] An idea...
Hello, Can be that I did not find and that that already exists :-[ . But it would be possible, in the property of FlightGear, to have a flag who indicates which launched version (Plib or OSG) ? Thus, the planes, scenery etc... could be automatically adapted to the version. Something like: condition equals propertysystems/version/plib/property valuefalse/value /equals /condition Best regards. Emmanuel -- BARANGER Emmanuel http://helijah.free.fr http://helijah.free.fr/Pack_3D http://helijah.free.fr/flightgear/flightgear.htm http://helijah.free.fr/flightgear/H4-Hercules.htm http://helijah.free.fr/flightgear/hangar.htm - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An idea...
On jeu 20 septembre 2007, BARANGER Emmanuel wrote: Hello, Can be that I did not find and that that already exists :-[ . But it would be possible, in the property of FlightGear, to have a flag who indicates which launched version (Plib or OSG) ? Thus, the planes, scenery etc... could be automatically adapted to the version. Something like: condition equals propertysystems/version/plib/property valuefalse/value /equals /condition Best regards. Emmanuel Yeah, which could be a nice answer, to some multi versions models like Catalina. However, which depends on the delay of the delivery of the 0.9.11 release. If the delay is short, and that 0.9.11 release the last with PLib only, that new Property will not be very profitable. Every CVS data being OSG only compatible. Cheers -- Gérard - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An idea
It seems however that version only OSG are not yet really on the agenda. Much will keep a version 0.9.10 or 0.9.11 to see 0.9.1, all using Plib, for still some time. But much would like or will like to have access to planes CVS. Is thus necessary it to prohibit to them simply because they wish to have a stable version. That was right to help those which do not place their planes in the CVS to remain compatible with all the versions and to prepare the future more easily. OSG is really very well, but certainly not yet for immediately. Then to prepare as much most simply possible. The addition of a simple Boolean value in the properties should not surely hustle all the code of FG ;) but the work of the creators of planes except CVS would be simpler and easier to integrate in the future. Now if the idea is bad, I incline myself ;) Best regards. Emmanuel -- BARANGER Emmanuel http://helijah.free.fr http://helijah.free.fr/Pack_3D http://helijah.free.fr/flightgear/flightgear.htm http://helijah.free.fr/flightgear/H4-Hercules.htm http://helijah.free.fr/flightgear/hangar.htm - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend 2007
On 9/17/07, Durk Talsma [EMAIL PROTECTED] wrote: This is just a quick note to remind everybody that FlightGear is intending to have a booth at the Dutch FlightSim event FSWeekend, organized November 3 4 at the aviodrome in Lelystad. As it looks right now, Martin Spott and I will be organizing the booth, and we are currently still looking for some volunteers for assistance. If you are around and would like to make a contribution to flightgear, this might be your chance. If you're interested, feel free to contact me either on or off list. What kind of assistance do you need? -- Csaba/Jester - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Scenery file formats: SRTM elevation data source
Hi all, This is my first submission to the list, but I've been around for a while. Not sure if this is the correct list to post about this; if not, please, let me know and accept my apologies. I've been able to successfully build FlightGear without much pain - just a couple of tweaks, as I'm working on a Windows XP / Visual Studio 2005 Express environment, and everything runs fine. However, I've tried also the TerraGear package, a completely different story. My interest is not just to compile it, but to update my FlightGear scenery with more accurate data. Specifically, I'm trying to improve the terrain elevation data and the surface textures to make them more realistic around my area of interest (north-west of Spain). I've got elevation data from SRTM Data (http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp), which gives you data for a relatively large area into one unique file. It's a very convenient source, as they have already done the hard work for filling voids with interpolated elevations. As this is not the same source TerraGear is programmed for, I was planning to reprogram the file interface section in order to adapt it to my source. After several attempts and many hours trying to compile TerraGear, I have finally made it for the chop utility. However, as the data file is different from the one used in the original implementation of hgtchop, I will need to modify the code. For that reason, I ask you some specific information I'm not able to infere from the code: What is the size (lat-long) of elevation files generated by the original code? Is it important to maintain the exact same size for the rest of the scripts/utilities to run properly? If the size is important, should it be an exact number of data points or an exact physical coverage of earth? And, finally, is there any document/readme with the intermediate and the final scenery file formats? This would help me a lot, although I know I could get this info from the code itself. By the way, I have also tried the FGSD (Scenery Designer), but I'm not able to make it work; it does start, but no way to import FG scenery data without a crash. Thanks a lot in advance, David -- David Pérez-Piñar López [EMAIL PROTECTED] Grupo de Tecnología de la Señal Universidad de Vigo http://www.tsc.uvigo.es http://www.tsc.uvigo.es/ 986 812683 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery file formats: SRTM elevation data source
David Pérez-Piñar López wrote: Hi all, This is my first submission to the list, but I've been around for a while. Not sure if this ichs the correct list to post about this; if not, please, let me know and accept my apologies. I've been able to successfully build FlightGear without much pain - just a couple of tweaks, as I'm working on a Windows XP / Visual Studio 2005 Express environment, and everything runs fine. However, I've tried also the TerraGear package, a completely different story. My interest is not just to compile it, but to update my FlightGear scenery with more accurate data. Specifically, I'm trying to improve the terrain elevation data and the surface textures to make them more realistic around my area of interest (north-west of Spain). I've got elevation data from SRTM Data (http://srtm.csi.cgiar.org/SELECTION/inputCoord.asp), which gives you data for a relatively large area into one unique file. It's a very convenient source, as they have already done the hard work for filling voids with interpolated elevations. As this is not the same source TerraGear is programmed for, I was planning to reprogram the file interface section in order to adapt it to my source. This page: http://topofusion.com/3d.php Has details on converting GeoTIFF files to USGS ASCII DEM files. Once converted you should be able to use demchop to process the resulting file. Jon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
On Wednesday 19 September 2007 22:45, Jon S. Berndt wrote: Check this out. Serious simmer: http://mysite.verizon.net/antonioe/index.html Jon I have seen far more serious simmers. :P Ampere - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
Ampere K. Hardraade schreef: I have seen far more serious simmers. :P Ampere That basically translates as: We really want some pictures of that! All of that guy's sim is MSFS-based with third party add-on instruments, and all of the monitors on his desk are run from a single PC. If FG is going to be used in home cockpits (Which I REALLY am in favor of) we need some way to get the instruments currently in FG out in an external application, which can run a 2D panel on a separate monitor. FG of course already has the possibility of exporting data over the network and linking copies for visuals (--external-fdm) but I'm not sure to what extent all of the instruments will follow in the slaved FG copy. The most important instrument you will have to run offboard except the basic six are engine gauges, radio and possibly map navigation. Making a decent (preferably OpenGL, vector-based) framework for FG panels would be a good development step, and it need not neccesarily be in the FG branch. As long as it follows the FG spec for the current instruments it will work, and we might be able to add XML-based vector artwork for glass cockpits later (SVG instrument rendering, anyone?). We could borrow some ideas from ARINC661 here. The project would be similar to X-Panel, already developed for X-Plane, so PanelGear might be a suitable name? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
