Re: [Flightgear-devel] proposed 1.9.1
- "Tim Moore" a écrit : > There has been a flurry of bug fixes in the last few days. I want to > review the > state of the maint branches in the simgear and flightgear git > repositories and > suggest that they would now be a good source for a 1.9.1 bug fix > release. I've > been fairly conservative and have been only checking fixes into those > branches > that fix reported or potential bugs. > Reminder: > git-clone git://repo.or.cz/simgear.git > git-clone git://repo.or.cz/flightgear.git $ git-clone git://repo.or.cz/simgear.git remote: Counting objects: 9905, done. remote: Compressing objects: 100% (2188/2188), done. remote: Total 9905 (delta 7696), reused 9835 (delta 7653) Receiving objects: 100% (9905/9905), 3.93 MiB | 296 KiB/s, done. Resolving deltas: 100% (7696/7696), done. Initialized empty Git repository in I:/Devel/fg-maint/simgear/.git/ Initialize simgear/.git warning: remote HEAD refers to nonexistent ref, unable to checkout. and indeed, the simgear/ directory is empty This is with git under Windows. What is going wrong ? -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP Liveries for Boeing 737-300
Gijs de Rooy wrote: "we have to discuss if it's really helpfull to put 26 liveries for one plane in CVS" My two cents... For a select few aircraft models which are very, very popular in the real world (including the 737 of course, but also the C172, 747, B1900, others in other "categories"?), I think it would be "fun" to include a larger number of liveries, so that users all across the globe can feel a sense of familiarity or identity with the aircraft, with which they may have had some real-world contact. For the less popular models I agree that just a few are more than sufficient. Of course, a model's popularity *within FG* should probably factor in there a little as well...?? Just musing... -R. Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Terrain errors report
There are several huge and very unnatural walls in the Himalayas, both running NS and EW. I'll give the line of latitude or longitude that the wall runs along, and the end coordinates of the walls: (1) e86.250 (NS), from n27.875 to n28.000 The above wall is capped on the north by an east-west wall: n28.000 (EW), from e86.196 to e86.348 (2) Another wall is farther west: n28.625 (EW), from e83.250 to e83.500 The above wall seems to pick up again a bit farther east: n28.625 (EW), from e83.700 to e83.875 (3) And a final one: n28.750 (EW), from e83.375 to e83.500 There are also several large flat areas, for which I'll give an approximate centre point: (4) n28.550, e84.297 (5) n28.550, e83.830 (6) n28.670, e83.394 There are others too, but my guess is that whatever causes one of these anomolies probably causes them all. The data is dated October 28, 2008. Brian -- Brian Schack 19 Xǔchāng Street 2Fphone: 2381 4727 Taipei 100 fax:2381 2145 TAIWAN -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] is gimp sgi rgb handling broken or not?
Look at Models/Airport/fbo.rgb. OSG under valgrind, chokes on row #52. entry in the start offset table @0x02D0: 0x2200 entry in the length offset table @0x12D0: 0x0207, means last byte in row at 0x2200+0x0207-1=0x2406 data @0x2200: 0xFE means, copy 0x7E bytes, we got 0x007E pixels. next code @0x227F: 0xFE means, copy 0x7E bytes, we got 0x00FC pixels. next code @0x22FE: 0xFE means, copy 0x7E bytes, we got 0x017A pixels. next code @0x237D: 0xFE means, copy 0x7E bytes, we got 0x01F8 pixels. next code @0x23FC: 0x86 means, copy 0x06 bytes, we got 0x01FE pixels. next code @0x2403: 0x01 means, make 1 copy of next byte, we got 0x01FF pixels. next code @0x2405: 0x01 means, make 1 copy of next byte, we got 0x0200 pixels, scan line complete. next code @0x2407: 0x00 means end of scan line. *BUT* this is already 1 byte outside of the length! It isn't consistent, either. The length for the preceding row #51 includes the terminating zero in the count properly (start offset @02CC: 0x2CCC, length @0x12CC: 0x01EE, last byte according to table: 0x2CCC+0x01EE-1=0x2EB9, terminating zero indeed @0x2EB9) OSG loader notices the completed scan line (but not before attempting to read the next code), so normally no harm is done. The only possibility of a crash would be if the input buffer is at the very end of the heap, so reading the extra byte would result in a segfault. One more reason to convert everything to png, and another couple of hours wasted on an irrelevant bug. Next up are 2 reports in the nasal interpreter, that's gonna be fun :) PS: I don't really understand why the last 2 pixels were not merged into the preceding 6. -- Csaba/Jester -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug reports... weather, and ILS...
Thanks guys :) On Thu, Jan 15, 2009 at 5:43 AM, Rob Shearman, Jr. wrote: > Lukas Mesani wrote: > "Man.. just btw, > we respect your work... Citation rulez :) > > cya" > > I second that, Syd :) I just figured out how the autopilot works and now > it's even MORE my favorite ;) > > Cheers, > -R. > > Robert M. Shearman, Jr. > Transit Operations Supervisor, > University of Maryland Department of Transportation > also known as rm...@umd.edu > > > > -- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear/props/Makefile.am breakage
On Fri, Jan 16, 2009 at 1:55 AM, Curtis Olson wrote: > > Ok, I wonder if --with-osg is failing in some way. I'd be interested in > seeing the output of your configure run, and if you are doing that, you > might as well include the config.log Hm, now I have re-run configure and it has set up the LDFLAGS properly. Don't know why it hasn't done so before. Though I have done this in my release build now, I didn't want to mess up the debug build :) I will check that later as well. Sorry for the noise. Back to valgrinding :) -- Csaba/Jester -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear/props/Makefile.am breakage
On Thu, Jan 15, 2009 at 6:47 PM, Csaba Halász wrote: > On Fri, Jan 16, 2009 at 1:22 AM, Curtis Olson wrote: > > On Thu, Jan 15, 2009 at 6:14 PM, Csaba Halász > > wrote: > >> > >> On Thu, Jan 15, 2009 at 10:56 PM, Curtis Olson > >> wrote: > >> > > >> > For instance, what is LDFLAGS set to in your Makefile in that > directory? > >> > >> I use --with-osg argument to configure. It should figure out the > >> proper -L option from there, shouldn't it? > > > > Right, and all the "-L" arguments should be added to LDFLAGS in the local > > Makefile in that directory. So I was hoping you would report the value > of > > that variable. This would help us determine if --with-osg did the right > > thing for you or not. And if it looks like LDFLAGS has the correct > options, > > it would be interesting to double check the OSG directory just to make > > certain that the requested library is living there. > > LDFLAGS = -L/home/hcs/src/inst/sg-dbg/lib -L/usr/X11R6/lib > > Which is interesting, because that's the path I am going to *install* > it to. So why add that? I believe the --prefix= path is always added. This is a convenience because often times you end up installing the prerequisites in the same --prefix location. Configure arguments were: --with-osg=/home/hcs/src/inst/osg > --prefix=/home/hcs/src/inst/sg-dbg --with-jpeg-factory Ok, I wonder if --with-osg is failing in some way. I'd be interested in seeing the output of your configure run, and if you are doing that, you might as well include the config.log > ~/src/inst/osg/lib$ ls -l libOpen* > lrwxrwxrwx 1 hcs hcs 20 2008-11-19 19:37 libOpenThreads.so -> > libOpenThreads.so.11 > lrwxrwxrwx 1 hcs hcs 23 2008-12-30 04:41 libOpenThreads.so.11 -> > libOpenThreads.so.2.3.1 > -rw-r--r-- 1 hcs hcs 127456 2009-01-15 17:52 libOpenThreads.so.2.3.1 > Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] initialize interpolate_elapsed in Environment/environment_ctrl.cxx
Another uninitialized variable caught by valgrind.
--
Csaba/Jester
Index: src/Environment/environment_ctrl.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Environment/environment_ctrl.cxx,v
retrieving revision 1.63
diff -u -r1.63 environment_ctrl.cxx
--- src/Environment/environment_ctrl.cxx 8 Jan 2009 21:11:53 - 1.63
+++ src/Environment/environment_ctrl.cxx 16 Jan 2009 00:48:33 -
@@ -336,6 +336,7 @@
same_station_interval_sec( 900.0 ), // 15 minutes
search_elapsed( .0 ),
fetch_elapsed( .0 ),
+ interpolate_elapsed( .0 ),
last_apt( 0 ),
proxy_host( fgGetNode("/sim/presets/proxy/host", true) ),
proxy_port( fgGetNode("/sim/presets/proxy/port", true) ),
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear/props/Makefile.am breakage
On Fri, Jan 16, 2009 at 1:22 AM, Curtis Olson wrote: > On Thu, Jan 15, 2009 at 6:14 PM, Csaba Halász > wrote: >> >> On Thu, Jan 15, 2009 at 10:56 PM, Curtis Olson >> wrote: >> > >> > For instance, what is LDFLAGS set to in your Makefile in that directory? >> >> I use --with-osg argument to configure. It should figure out the >> proper -L option from there, shouldn't it? > > Right, and all the "-L" arguments should be added to LDFLAGS in the local > Makefile in that directory. So I was hoping you would report the value of > that variable. This would help us determine if --with-osg did the right > thing for you or not. And if it looks like LDFLAGS has the correct options, > it would be interesting to double check the OSG directory just to make > certain that the requested library is living there. LDFLAGS = -L/home/hcs/src/inst/sg-dbg/lib -L/usr/X11R6/lib Which is interesting, because that's the path I am going to *install* it to. So why add that? Configure arguments were: --with-osg=/home/hcs/src/inst/osg --prefix=/home/hcs/src/inst/sg-dbg --with-jpeg-factory ~/src/inst/osg/lib$ ls -l libOpen* lrwxrwxrwx 1 hcs hcs 20 2008-11-19 19:37 libOpenThreads.so -> libOpenThreads.so.11 lrwxrwxrwx 1 hcs hcs 23 2008-12-30 04:41 libOpenThreads.so.11 -> libOpenThreads.so.2.3.1 -rw-r--r-- 1 hcs hcs 127456 2009-01-15 17:52 libOpenThreads.so.2.3.1 -- Csaba/Jester -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear/props/Makefile.am breakage
On Thu, Jan 15, 2009 at 6:14 PM, Csaba Halász wrote: > On Thu, Jan 15, 2009 at 10:56 PM, Curtis Olson > wrote: > > On Thu, Jan 15, 2009 at 3:54 PM, Curtis Olson wrote: > >> > >> On Thu, Jan 15, 2009 at 3:18 PM, Csaba Halász wrote: > >>> > >>> "Fix linkage of test programs with OpenThreads." > >>> > >>> Well, it now doesn't compile for me. It adds -lOpenThreads, but > >>> merrily ignores the --with-osg configure option. > >> > >> What's your compiler error message? I don't see an obvious problem from > >> looking at the files. > > > > For instance, what is LDFLAGS set to in your Makefile in that directory? > > I use --with-osg argument to configure. It should figure out the > proper -L option from there, shouldn't it? Right, and all the "-L" arguments should be added to LDFLAGS in the local Makefile in that directory. So I was hoping you would report the value of that variable. This would help us determine if --with-osg did the right thing for you or not. And if it looks like LDFLAGS has the correct options, it would be interesting to double check the OSG directory just to make certain that the requested library is living there. > But of course I managed to compile it, I just reported it so it > doesn't go unnoticed. > If it is intended behavior, then it is fine with me. Well, if a broken compile is intended behavior, I'm not sure who would intend it to be that way! :-) > Then again, all > the test and utility stuff should be a separate makefile target, IMHO. > For example, in FG only the tests require glut. Or all these things could be ported to OSG, but no one has quite gotten around to it. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear/props/Makefile.am breakage
On Thu, Jan 15, 2009 at 10:56 PM, Curtis Olson wrote: > On Thu, Jan 15, 2009 at 3:54 PM, Curtis Olson wrote: >> >> On Thu, Jan 15, 2009 at 3:18 PM, Csaba Halász wrote: >>> >>> "Fix linkage of test programs with OpenThreads." >>> >>> Well, it now doesn't compile for me. It adds -lOpenThreads, but >>> merrily ignores the --with-osg configure option. >> >> What's your compiler error message? I don't see an obvious problem from >> looking at the files. > > For instance, what is LDFLAGS set to in your Makefile in that directory? I use --with-osg argument to configure. It should figure out the proper -L option from there, shouldn't it? But of course I managed to compile it, I just reported it so it doesn't go unnoticed. If it is intended behavior, then it is fine with me. Then again, all the test and utility stuff should be a separate makefile target, IMHO. For example, in FG only the tests require glut. -- Csaba/Jester -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG ocean water shader / water region issue.
On vendredi 16 janvier 2009, Martin Spott wrote: > gerard robin wrote: > > So, before to spend some time to try to develop any water shader, it > > would be better to invest time to try to get a consistent sea surface. > > Go ahead, > Martin. :) :) :) thanks for the authorization -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG ocean water shader / water region issue.
gerard robin wrote: > So, before to spend some time to try to develop any water shader, it would be > better to invest time to try to get a consistent sea surface. Go ahead, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG ocean water shader / water region issue.
On vendredi 16 janvier 2009, Martin Spott wrote: > James Turner wrote: > To the current state we have a coastline around each 'isolated' > continent or island which is either made from a single closed polygon > (which could be GSHHS) or from the outline around a couple of adjacent > polygons (VMap0 political boundaries). To get an overview, please check > here: > > http://wiki.osgeo.org/wiki/Geodata_Repository#PostGIS_serving_vector_data > > This coastline is the basic factor for a simple principle: Everything > inside this coastline is counted as ground, the entire area outside the > coastline is "Ocean". The same principle applies to lakes - just in the > reverse order: Everything inside the lake shoreline is water. > > So, even if our STRM elevation grid would indicate some sort of > elevated ground outside our coastline, it's going to get clipped out > due to the given principle. In contrast, if there's no elevation data > for an area inside the coastline, then the ground is still going to get > extended in accordance with the coastline but at sea level. > There's a nice example for these corner cases if you approach RWY 24 at > TNCE in the 1.0.1 Scenery. > > I'm proposing a similar but somehow opposing schema (talking is cheap ;-) > Let us have the seabed modelled using bathymetry data, clipped against > the same coastline which we're using to clip the ground elevation, > limit the maximum 'elevation' of the seabed to the elevation of the > respective coastline, which is presumably at MSL for all ocean > shorelines - or the individual elevation of the respective lake. > Probably limit the seabed elevation to a few centimetres below to allow > for some nice waves > I don't see any reason why and how this approach would set KSFO under > water. > > > Also, is global (even crude) coastal bathymetry data available? > > Yes, I even had a copy of global bathymetry data on my local disk few > years ago, but lost it due to sort of a crash (well, the data is still > sitting there, but I have to re-assemble the partitions before I'm able > to read it). > > Cheers, > Martin. I did not understood everything about the content of that topic, since the technical which is involved is "flying" over of my low know how. I would like only say ( again , because said before) that the coastline which is close to my favorite area , the French coastline on Mediterranean sea, was better with the 9.8 scenery. It is sure that the last version is mostly better than the 1.0, however it is not so right than it was with the old 9.8 version. I understand that making the scenery is a very difficult work. From the data which which are freely available it is difficult to get the same quality that we can have now with google 3D or IGN (France). In addition to it, i worry that we are not able to get the right connection from the generic sea tile to the coastline tile ( difference of level) So, before to spend some time to try to develop any water shader, it would be better to invest time to try to get a consistent sea surface. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear/props/Makefile.am breakage
On Thu, Jan 15, 2009 at 3:54 PM, Curtis Olson wrote: > On Thu, Jan 15, 2009 at 3:18 PM, Csaba Halász wrote: > >> "Fix linkage of test programs with OpenThreads." >> >> Well, it now doesn't compile for me. It adds -lOpenThreads, but >> merrily ignores the --with-osg configure option. > > > What's your compiler error message? I don't see an obvious problem from > looking at the files. > For instance, what is LDFLAGS set to in your Makefile in that directory? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG ocean water shader / water region issue.
James Turner wrote: > I think part of the problem is that you (Martin) have looked at this > too much, and the rest of us (except Curt) not so much. Can you > explain for people like me the pipeline you propose to assemble the > data (i.e what pieces of the final result come from what source, and > how), and how that would fit together at runtime? To the current state we have a coastline around each 'isolated' continent or island which is either made from a single closed polygon (which could be GSHHS) or from the outline around a couple of adjacent polygons (VMap0 political boundaries). To get an overview, please check here: http://wiki.osgeo.org/wiki/Geodata_Repository#PostGIS_serving_vector_data This coastline is the basic factor for a simple principle: Everything inside this coastline is counted as ground, the entire area outside the coastline is "Ocean". The same principle applies to lakes - just in the reverse order: Everything inside the lake shoreline is water. So, even if our STRM elevation grid would indicate some sort of elevated ground outside our coastline, it's going to get clipped out due to the given principle. In contrast, if there's no elevation data for an area inside the coastline, then the ground is still going to get extended in accordance with the coastline but at sea level. There's a nice example for these corner cases if you approach RWY 24 at TNCE in the 1.0.1 Scenery. I'm proposing a similar but somehow opposing schema (talking is cheap ;-) Let us have the seabed modelled using bathymetry data, clipped against the same coastline which we're using to clip the ground elevation, limit the maximum 'elevation' of the seabed to the elevation of the respective coastline, which is presumably at MSL for all ocean shorelines - or the individual elevation of the respective lake. Probably limit the seabed elevation to a few centimetres below to allow for some nice waves I don't see any reason why and how this approach would set KSFO under water. > Also, is global (even crude) coastal bathymetry data available? Yes, I even had a copy of global bathymetry data on my local disk few years ago, but lost it due to sort of a crash (well, the data is still sitting there, but I have to re-assemble the partitions before I'm able to read it). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [BUG] size of MP position message depends on architecture
Tim Moore wrote: > Stuart Buchanan wrote: >> Csaba Halász wrote: >> >>> On 32 bit system, sizeof(T_PositionMsg) = 196. On 64 bit system it is >>> 200, due to extra 4 bytes padding at the end. >>> >>> To make matters worse, in the assembled MP packet this message is >>> followed by property values. >>> Assuming the padding bytes are zero, a 32 bit receiver should be able >>> to process packets sent by a 64 bit machine, because it skips over the >>> unknown id of 0. I am puzzled how it even works the other way around. >>> >>> I also don't understand the reason for the padding. > The xdr_data2_t elements are 8 bytes long and must be 8-byte aligned on > x86_64; > see http://refspecs.freestandards.org/elf/x86_64-abi-0.95.pdf . Therefore the > whole structure must be 8 byte aligned. >> It's been years since I looked at the MP code, but IIRC the XDR spec requires >> padding so that each value is a multiple of 4 bytes in length. I remember >> having >> to put in some code to add padding when writing string values for the MP chat >> function. It's entirely possible that there's an ancient bug lurking there. > > The bug was introduced when the message format was changed to support > optional > properties. It's in the plib-based release too. > > This is a serious bug, definitely worth fixing. To make it more interesting, > the > padding inserted on x86_64 could contain garbage that makes it look like a > real > property. As I see it, the best plan is to add the padding to the structure > and > explicitly zero the padding. Then, add some defensive code to see if the > padding > in a received message is 0; if it is not, then verify that the property list > is > well-formed if we start decoding from that word. If it isn't, then assume > that > the message was sent by an old 64 bit client with properties starting 200 > bytes > after the beginning of the position message. I've checked in a fix that changes the message size and should decrypt messages from old FG copies. Tim -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear/props/Makefile.am breakage
On Thu, Jan 15, 2009 at 3:18 PM, Csaba Halász wrote: > "Fix linkage of test programs with OpenThreads." > > Well, it now doesn't compile for me. It adds -lOpenThreads, but > merrily ignores the --with-osg configure option. What's your compiler error message? I don't see an obvious problem from looking at the files. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] simgear/props/Makefile.am breakage
"Fix linkage of test programs with OpenThreads." Well, it now doesn't compile for me. It adds -lOpenThreads, but merrily ignores the --with-osg configure option. -- Csaba/Jester -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP Liveries for Boeing 737-300
"syd adams" wrote: > IMHO , I think maybe 2-4 liveries could be included with cvs aircraft , but > another site to download extra liveries , similar to the aircraft download > page ... Someone has to feel responsible for managing this site, ensuring that the liveries are consistent with the corresponding aircraft either from CVS, from the official aircraft download page or from both sources. According to my personal experience with getting "administrative workflows" introduced into the FlightGear project I'm uncertain wether such an attempt is going to pass along without major difficulties. Simply check the size of the different aircraft directories and compare that to the size of the livery package as proposed by Gijs - I doubt that the required overhead is worth the trouble. The CVS (or whichever) repository serves well as an 'authoritative' home for add-ons like these liveries - because users will complain early when things break. Once you start spreading these add-ons over too many different places, you're going to face what I'd call a maintenance hell because everyone is going to create his private spin-off Just look how fast this "UnitedFreeWorld" site turned into a site where people drop their garbage - and forget about it. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP Liveries for Boeing 737-300
* Csaba Halász -- Thursday 15 January 2009: > How about we work out a way to transfer liveries (and maybe whole > models) over MP? As long as I can turn it off, I don't have a problem with it. But I think it's a rather bad idea. First, because lagging and freezing is already bad for loading aircraft from the local disk. Loading 3 MB textures over network while flying won't make that better. And then, I suspect that most of these textures would be (rather infantile) "personalized" liveries. Then you get 737 with skulls and bones logos and all such "cool" things. Or swastikas. But to each his own. m. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP Liveries for Boeing 737-300
On Thu, Jan 15, 2009 at 6:18 PM, Melchior FRANZ wrote: > * Stuart Buchanan -- Thursday 15 January 2009: > [+26 liveries] >> My view is that they should be kept with the aircraft. > > Of course, liveries should generally be kept with the aircraft. > But how many? Do 50 liveries for an aircraft make sense? Or 100? > 200? Liveries are quickly made but can be quite big. Cheap in > terms of developer resources, and expensive in terms of disk > resources. I for one prefer quality to quantity. (Except when > it comes to food, of course. ;-) > > People probably choose their favorite livery, and for the rest > of the time, the other dozens of liveries just lie around. > You can find a favorite in 10 liveries as well. How about we work out a way to transfer liveries (and maybe whole models) over MP? -- Csaba/Jester -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP Liveries for Boeing 737-300
IMHO , I think maybe 2-4 liveries could be included with cvs aircraft , but another site to download extra liveries , similar to the aircraft download page ... cheers -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear crahs
I'm using Flightgear via CVS, synced just minutes ago. If I start up at KBUR (Burbank, CA) after a few seconds I get the following error message just moments after the outside view is presented, followed by a hard crash: AI local traffic Cessna-three-oscar-sierra cleared to taxi... ERROR - unable to find path to runway theshold in ground.cxx for airport KEMT Unknown exception in the main loop. Aborting... Possible cause: Resource temporarily unavailable KEMT is near KBUR. This does not appear to be a problem if I start up somewhere else far away from KEMT. Also, this is a reliable crash. It happens every time I startup at Burbank (KBUR) ... it's not a random, once in a while crash. The file generating the last output before the abort is ATCDCL/ground.cxx Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP Liveries for Boeing 737-300
* Stuart Buchanan -- Thursday 15 January 2009: [+26 liveries] > My view is that they should be kept with the aircraft. Of course, liveries should generally be kept with the aircraft. But how many? Do 50 liveries for an aircraft make sense? Or 100? 200? Liveries are quickly made but can be quite big. Cheap in terms of developer resources, and expensive in terms of disk resources. I for one prefer quality to quantity. (Except when it comes to food, of course. ;-) People probably choose their favorite livery, and for the rest of the time, the other dozens of liveries just lie around. You can find a favorite in 10 liveries as well. m. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP Liveries for Boeing 737-300
Gijs de Rooy wrote: > I've collected 26 liveries, put them in one file and added the livery > selection > dialog. Melchior asked me to put this on the mailinglist, as we have to > discuss > if it's really helpfull to put 26 liveries for one plane in CVS. At the > moment we > have around 130 liveries (click) available throughout the net. We should have > one place to collect them all (if that's CVS or not, I don't care). > > The file is attached to this mail. I have put all the textures in .png format > as it > saves us a lot of space. Now all the liveries together are only 6 MB instead > of > 14.5, with .rgb. Disadvantage is that they don't work on the older versions... > > Please let me know what you think. My view is that they should be kept with the aircraft. I also think that AIrcraft should be separated from the base data in CVS. At present the CVS data repository is huge, and most of that size is due to the number of aircraft we have. Checking out a new copy of the data currently takes hours, and is only going to take long as the number of aircraft inevitably increase. Splitting out a new Aircraft repository would also allow us to relax our CVS commit policy - so aircraft developers would have CVS commit rights for their own aircraft. Of course, there will be some pain involved, but I think we're going to have to do this at some point, and the sooner we do it, the easier it will be. -Stuart -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] MP Liveries for Boeing 737-300
Hi, I've collected 26 liveries, put them in one file and added the livery selection dialog. Melchior asked me to put this on the mailinglist, as we have to discuss if it's really helpfull to put 26 liveries for one plane in CVS. At the moment we have around 130 liveries (click) available throughout the net. We should have one place to collect them all (if that's CVS or not, I don't care). The file is attached to this mail. I have put all the textures in .png format as it saves us a lot of space. Now all the liveries together are only 6 MB instead of 14.5, with .rgb. Disadvantage is that they don't work on the older versions... Please let me know what you think. Download: http://flightgear.oxyhost.com/downloads/aircraft/737-300.zip Thanks, Gijs PS: For those that I didn't reached, happy new year ;) _ De leukste online filmpjes vind je op MSN Video! http://video.msn.com/video.aspx?mkt=nl-nl-- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/threads SGQueue.hxx, 1.9, 1.10
On 15 Jan 2009, at 15:23, Martin Spott wrote: >> Commit Benoit Laniel's patch which converts more SimGear pieces to >> use >> OpenThreads primitives directly. > > Woohoo, great - better late than never ;-) I'm going to push through some other cleanup in the next few days, so that the SimGear threads module will be mostly unused. I'm not sure if I can actually remove it, since I don't know what other SG-using code makes use of the thread primitives. James -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/threads SGQueue.hxx, 1.9, 1.10
James Turner wrote: > Update of /var/cvs/SimGear-0.3/source/simgear/threads > In directory baron.flightgear.org:/tmp/cvs-serv977/simgear/threads > > Modified Files: > SGQueue.hxx > Log Message: > Commit Benoit Laniel's patch which converts more SimGear pieces to use > OpenThreads primitives directly. Woohoo, great - better late than never ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight sim protocols?
? ?. wrote: > Take a look at http://cigi.sourceforge.net/, it is open source protocol > proposed by Boing As stated on the respective website, CIGI is not much of a 'MultiPlayer' protocol, in contrast: "CIGI is an open simulation protocol for communication between a host device and IG." Instead, I'd lobby for familiarization with "VirtualAir", an effort which aims at integrating FlightGear with HLA-compilant simulation frameworks via the CERTI "RunTime Infrastructure": http://virtualair.sourceforge.net/ As far as I can tell, VirtualAir is not yet ready for general consumption - the project is still quite young, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gyro compas drift
On 01/14/2009 09:49 PM, Alex Perry wrote: > Laser gyros do indeed behave the way that the wiki page describes. > Mechanical gyros, such as you find in light aircraft, have other drift > sources that are considerably larger than the diurnal one. And, since > the aircraft tend not to move far from their home latitude, there is > an attempt by mechanics to adjust the gyro for zero net drift rate (on > average). I think there are at least three issues on the table: a) Apparent temporal wander (d/dt) [called "diurnal" above] b) Apparent transport wander (d/dφ) c) Actual erratic drift. > The purpose of implementing the drift in FlightGear is for operational > realism, more than scientific accuracy, and therefore the drift value > is designed to make the gyro compass be inaccurate if the light > aircraft pilot does not reset it regularly. That's mostly about talking about item (c). Actually, in the existing code, the drift rate is carefully calculated to be equal to the earth's rotation rate. It's not some wild guess that "5 degrees every 20 minutes is about right". The hypothesis that it is a buggy attempt to account for temporal wander is very much alive. Meanwhile, there is no attempt to model transport wander, as you can verify by looking at the code and/or by flying over the pole. If you want to fly the stock c172p this time of year, I suggest flying over the _south_ pole since there are still no interior lights or instruments lights in the c172p. If you fly over the pole, the heading indicator card spins 180 degrees in a fraction of a second. It's hilarious. > If you want to include > the sin(lat) term, be sure to add a flag so we can distinguish between > the laser and mechanical variants. a) It would be easier -- and much better -- to include the sin(lat) term and then to include a latitude-nut property which could be set appropriately. Then anyone who wanted to null out the (d/dt) term could do so ... and could also properly model the effects of taking the aircraft away from its native clime. b) As for transport wander, rather than keeping track of the "heading" of the gyro, as is done now, it would be much nicer to keep track of the physics. I'm hoping this would be pretty easy. Keep track of the gyro axis as a vector in x,y,z space, and project it on to the axes of the aircraft, and voilà! Can some FDM guru tell me how to obtain the quaternions and/or the vectors that specify aircraft orientation? I see lots of examples where instruments etc. refer to the Euler angles (yaw, pitch, and roll) but not much in the way of quaternions or vectors. I found some code in Main/viewer.cxx that constructs quaternions from yaw, pitch, and roll, but that's ugly and not the sort of thing you would want to do near the poles. It also requires calling a passel of transcendental functions at frame rate. JSBSim has a thing called GetTec2b which looks promising, but the other FDMs don't, not by that name anyway, which means instruments shouldn't depend upon it. Should we perhaps add this to the incipient FDM spec? c) Modeling the erratic drift by a constant rate is adequate for some purposes, but it would be more fun to make the erratic drift more, well, erratic. In Real Life it is sensitive to pitch and bank angles ... so during cruise you get complacent and start trusting the gyro, but then when you start maneuvering during the approach, it goes to pot. The magnitude of the erratic drift should be controlled by a parameter ... not by a compiled-in constant that pretends to be a constant of nature. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug reports... weather, and ILS...
Lukas Mesani wrote: "Man.. just btw, we respect your work... Citation rulez :) cya" I second that, Syd :) I just figured out how the autopilot works and now it's even MORE my favorite ;) Cheers, -R. Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug reports... weather, and ILS...
Man.. just btw, we respect your work... Citation rulez :) cya On Wed, 2009-01-14 at 12:13 -0800, syd adams wrote: > > > On Wed, Jan 14, 2009 at 7:13 AM, Rob Shearman, Jr. > wrote: > Hello all -- > > Using 2208-01-11 CVS build flying the Cessna Citation Bravo on > Windows Vista with NVIDIA 6100 GeForce 405... > > Lately I have noticed that the glideslopes seem to be > uniformly wrong or inoperable somehow. This changed within > the last couple of builds. Previously, when on final, the > visual glideslope indicators would essentially match up with > what the ILS was telling me. However, now it seems as if the > ILS is pegged high (indicating I am too low) while the visual > indicators are all white (indicating I am too high). > > Also, this has possibly been going on quite some time now > (since I started reporting NaN bugs on my medium-haul > flights), but in many cases, the METAR doesn't change the > active wind and cloud settings unless I actually look at the > METAR (Environment --> Weather Scenario). As soon as I close > the dialog box, the clouds change, the KIAS moves suddenly, > and the plane may rock side-to-side gently for a moment or > two. *RARELY* I will notice the weather settings change on > their own during flight, but it seems as if *USUALLY* it > doesn't do so unless I look at the METAR. > > Cheers, > -R. > > Robert M. Shearman, Jr. > Transit Operations Supervisor, > University of Maryland Department of Transportation > also known as rm...@umd.edu > > > This might be partly my fault , I changed the neelde animation because > it was pointed out that it was too insensitive , but now it has a very > narrow window to operate in , and the ealier discussions and the > manual don't jive so I'll look into it some more . The changes I > made were about a week or so ago. > I haven't looked at the instrumentation/nav/gs-needle-deflection while > flying to see if the behaviour has changed there yet... > -- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > ___ Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight sim protocols?
? ?. wrote: > Take a look at http://cigi.sourceforge.net/, it is open source protocol > proposed by Boing thanks - actually that protocol is defined by Simulation IOT Standards Organization, http://www.sisostds.org/ - very exciting stuff! -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight sim protocols?
Take a look at http://cigi.sourceforge.net/, it is open source protocol proposed by Boing - Original Message - From: "Ákos Maróy" To: Sent: Thursday, January 15, 2009 10:31 AM Subject: [Flightgear-devel] flight sim protocols? > Hi, > > I have an overall question, which is related to FlightGear as well. I > wonder what flight simulator network protocols are already in existence, > and what their intended usage is. > > I see the VATSIM and IVAO networks - I guess they both define their > respective protocols? > > Are these protocols to be used in an ATC-like environment, where > position updates every few seconds are sufficient? Or are there > protocols which would allow for, say, formation flying, where positions > for planes close-by would be updated much more frequently? > > Are there available implementations / libraries for these protocols, > maybe open source? Does FlightGear has its own implementation of these? > > > Akos > > -- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [BUG] size of MP position message depends on architecture
Stuart Buchanan wrote: > Csaba Halász wrote: > >> On 32 bit system, sizeof(T_PositionMsg) = 196. On 64 bit system it is >> 200, due to extra 4 bytes padding at the end. >> >> To make matters worse, in the assembled MP packet this message is >> followed by property values. >> Assuming the padding bytes are zero, a 32 bit receiver should be able >> to process packets sent by a 64 bit machine, because it skips over the >> unknown id of 0. I am puzzled how it even works the other way around. >> >> I also don't understand the reason for the padding. The xdr_data2_t elements are 8 bytes long and must be 8-byte aligned on x86_64; see http://refspecs.freestandards.org/elf/x86_64-abi-0.95.pdf . Therefore the whole structure must be 8 byte aligned. > > It's been years since I looked at the MP code, but IIRC the XDR spec requires > padding so that each value is a multiple of 4 bytes in length. I remember > having > to put in some code to add padding when writing string values for the MP chat > function. It's entirely possible that there's an ancient bug lurking there. The bug was introduced when the message format was changed to support optional properties. It's in the plib-based release too. This is a serious bug, definitely worth fixing. To make it more interesting, the padding inserted on x86_64 could contain garbage that makes it look like a real property. As I see it, the best plan is to add the padding to the structure and explicitly zero the padding. Then, add some defensive code to see if the padding in a received message is 0; if it is not, then verify that the property list is well-formed if we start decoding from that word. If it isn't, then assume that the message was sent by an old 64 bit client with properties starting 200 bytes after the beginning of the position message. We could bump the protocol number, but I notice that that has never been done, even when the format of the position message changed :) That would mean that people running plib FlightGear wouldn't see new clients, which is probably unacceptable. Tim -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight sim protocols?
Holger, > I must say (for myself!): if they won't open the protocol I am not > interresting in taking part with an OpenSource flight simulator. yes, totally valid point > So it is not only a problem of the protocol. I think the most simulators > behing IVAO or VATSIM are commercial ones (M$) and those companies might > not allow to use or exchange information about their landscapes. I think > they even won't talk with us... there are also third-party X-Plane clients for these. While X-Plane is commercial, these clients are for free (even though closed source). they must have gotten the protocol details somehow... Akos -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight sim protocols?
Ákos, Ákos Maróy wrote: > Holger, > >> This question pops up from time to time. In fact I wrote a similar mail >> some years ago :-) > > :) > >> As far as I know: they have closed protocols and you have to sign a kind >> of NDA to take a look inside. > > I see :( So no chance of having open source implementations either? I must say (for myself!): if they won't open the protocol I am not interresting in taking part with an OpenSource flight simulator. But even when opening the protocol there are several problems to fix, e.g. different landscape information, setting the environment, ... So it is not only a problem of the protocol. I think the most simulators behing IVAO or VATSIM are commercial ones (M$) and those companies might not allow to use or exchange information about their landscapes. I think they even won't talk with us... >> There is a multiplayer protocol which you can use for this. Also there >> is a radar application in development but I don't know the actual state. >> >> Charles Ingels and myself are working on a module for real radio >> simulation realized through VoIP/Asterisk. The current state is that we >> are working hard on version 3. Version 1 was just a test, 2 was working >> until my server crashed but had some problems. Now we are trying to do >> everything right and hope to get it running for Linuxday 2009 in Berlin. > > Is the Linux Day in June? 24th - 27th June 2009, see http://www.linuxtag.org/2009/ >> Perhaps you take a look at http://sourceforge.net/mail/?group_id=583. >> This is the archive for this list and there was a big thread some weeks >> ago which may give you answers to your questions. > > Thanks! You`re Welcome! Holger > > > Akos > > > -- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- +++NEUE ANSCHRIFT+++NEUE ANSCHRIFT+++NEUE ANSCHRIFT+++NEUE ANSCHRIFT+++ # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Alexanderplatz 1 E-Mail: wi...@dfn.de ## ## ## ## ### 10178 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight sim protocols?
Holger, > This question pops up from time to time. In fact I wrote a similar mail > some years ago :-) :) > As far as I know: they have closed protocols and you have to sign a kind > of NDA to take a look inside. I see :( So no chance of having open source implementations either? > There is a multiplayer protocol which you can use for this. Also there > is a radar application in development but I don't know the actual state. > > Charles Ingels and myself are working on a module for real radio > simulation realized through VoIP/Asterisk. The current state is that we > are working hard on version 3. Version 1 was just a test, 2 was working > until my server crashed but had some problems. Now we are trying to do > everything right and hope to get it running for Linuxday 2009 in Berlin. Is the Linux Day in June? > Perhaps you take a look at http://sourceforge.net/mail/?group_id=583. > This is the archive for this list and there was a big thread some weeks > ago which may give you answers to your questions. Thanks! Akos -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight sim protocols?
Hi, Ákos Maróy wrote: > Hi, > > I have an overall question, which is related to FlightGear as well. I > wonder what flight simulator network protocols are already in existence, > and what their intended usage is. This question pops up from time to time. In fact I wrote a similar mail some years ago :-) > I see the VATSIM and IVAO networks - I guess they both define their > respective protocols? As far as I know: they have closed protocols and you have to sign a kind of NDA to take a look inside. > Are these protocols to be used in an ATC-like environment, where > position updates every few seconds are sufficient? Or are there > protocols which would allow for, say, formation flying, where positions > for planes close-by would be updated much more frequently? There is a multiplayer protocol which you can use for this. Also there is a radar application in development but I don't know the actual state. Charles Ingels and myself are working on a module for real radio simulation realized through VoIP/Asterisk. The current state is that we are working hard on version 3. Version 1 was just a test, 2 was working until my server crashed but had some problems. Now we are trying to do everything right and hope to get it running for Linuxday 2009 in Berlin. > Are there available implementations / libraries for these protocols, > maybe open source? Does FlightGear has its own implementation of these? Perhaps you take a look at http://sourceforge.net/mail/?group_id=583. This is the archive for this list and there was a big thread some weeks ago which may give you answers to your questions. Regards, Holger > > > Akos > > -- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- +++NEUE ANSCHRIFT+++NEUE ANSCHRIFT+++NEUE ANSCHRIFT+++NEUE ANSCHRIFT+++ # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Alexanderplatz 1 E-Mail: wi...@dfn.de ## ## ## ## ### 10178 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] flight sim protocols?
Hi, I have an overall question, which is related to FlightGear as well. I wonder what flight simulator network protocols are already in existence, and what their intended usage is. I see the VATSIM and IVAO networks - I guess they both define their respective protocols? Are these protocols to be used in an ATC-like environment, where position updates every few seconds are sufficient? Or are there protocols which would allow for, say, formation flying, where positions for planes close-by would be updated much more frequently? Are there available implementations / libraries for these protocols, maybe open source? Does FlightGear has its own implementation of these? Akos -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
