[Flightgear-devel] Cygwin - Compile errors
This mornings' cvs fails to compile here under Cygwin with the following error: MIDG-II.cxx: In function `uint32_t read_swab(char*, size_t, size_t)': MIDG-II.cxx:31: error: call of overloaded `ulEndianSwap(uint32_t*)' is ambiguous /usr/include/plib/ul.h:334: note: candidates are: void ulEndianSwap(unsigned int *) near match /usr/include/plib/ul.h:350: note: void ulEndianSwap(int*) near match I have up-to-date plib, sg, and fg cvs versions. Since I don't need MIDG-II, I've fixed it locally by removing MIDG-II.cxx from the makefile. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Cygwin - Compile errors
Erik Hofman Vivian Meazza wrote: This mornings' cvs fails to compile here under Cygwin with the following error: MIDG-II.cxx: In function `uint32_t read_swab(char*, size_t, size_t)': MIDG-II.cxx:31: error: call of overloaded `ulEndianSwap(uint32_t*)' is ambiguous This should be fixed. Since I don't need MIDG-II, I've fixed it locally by removing MIDG- II.cxx from the makefile. What, again? :-) er ... as usual :-) Quickest way - and involves absolutely no thought. Thanks! Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] weird crash in sgMakeLeaf()
Hi all, I did some further analysis on this bug and I found that in line 237 of leaf.cxx texcoord = texcoords[ tex_index[i] ]; tex_index[i] is negative in the case of the crash. Specifically, the value in my case is 0x8000, which looks like a short-to-int-conversion problem. (Yes, the custom scenery is pretty detailed in some parts and yes, I'm working on a reduction of vertices as well ;-) IIRC there was a change to the scenery code from short to int some time ago. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A question regarding accurate taxiways information
Since FAA has airport diagrams in PDF format, would it be possible to extract taxiways information BTW, the tower and the beacon, if any, can also be extracted from it, as well as the windsocks, ILS hold lines etc. directly from a PDF file such as this http://204.108.4.16/d-tpp/0510/00375AD.PDF to produce taxiways usable in FlightGear? 1) by some kind of image processing following the Ghostview output. Of course, since the internal graphics is vector, it might be possible to infer more from various rendered resolutions. 2) Other approach would be to reverse engineer the original PS, if any, from the PDF --- I'm afraid it's not very gratifying... 3) Yet another approach would be to ask the FAA for the data source feed --- after all, this is U.S. government work that is in public domain. And, of course, this is only a US-related solution... Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Terragear-devel] Re: Terragear, 64 bit
Hello Jason, Jason Cox wrote: now if I can just get the land mass from e00 Which source did you intend to pick the data from ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] HUD fonts for Norman Vine
Norman, The problem is I need to change the font that is showing on my HUD to make it larger (and brighter). I cannot figure out where this is done. It seems to refer back to properties in some way, but I can't find where the lever is. If I change the sizes in the programs in Cockpit, nothing happens. If the program is not using the GL fonts, what is it using and how does one change one or more instances in the HUD? Thanks, Rex du Pont [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [fixed] weird crash in sgMakeLeaf()
Hi,
this patch should fix the bug.
Regards,
Ralf
Ralf Gerlich schrieb:
Hi all,
I did some further analysis on this bug and I found that in line 237 of
leaf.cxx
texcoord = texcoords[ tex_index[i] ];
tex_index[i] is negative in the case of the crash. Specifically, the
value in my case is 0x8000, which looks like a
short-to-int-conversion problem. (Yes, the custom scenery is pretty
detailed in some parts and yes, I'm working on a reduction of vertices
as well ;-)
IIRC there was a change to the scenery code from short to int some time
ago.
Regards,
Ralf
Index: simgear/io/sg_binobj.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/io/sg_binobj.cxx,v
retrieving revision 1.8
diff -u -r1.8 sg_binobj.cxx
--- simgear/io/sg_binobj.cxx 1 Oct 2005 11:41:59 - 1.8
+++ simgear/io/sg_binobj.cxx 11 Oct 2005 17:16:08 -
@@ -240,8 +240,8 @@
if ( nbytes buf.get_size() ) { buf.resize( nbytes ); }
char *ptr = buf.get_ptr();
sgReadBytes( fp, nbytes, ptr );
- int count = nbytes / (idx_size * sizeof(short));
- short *sptr = (short *)ptr;
+ int count = nbytes / (idx_size * sizeof(unsigned short));
+ unsigned short *sptr = (unsigned short *)ptr;
int_list vs; vs.clear();
int_list ns; ns.clear();
int_list cs; cs.clear();
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] HUD fonts for Norman Vine
The problem is I need to change the font that is showing on my HUD
to make it larger (and brighter). I cannot figure out where this is done.
It seems to refer back to properties in some way, but I can't find where
the lever is. If I change the sizes in the programs in Cockpit, nothing
happens. If the program is not using the GL fonts, what is it using and
how does one change one or more instances in the HUD?
The HUD uses PLIB Fonts these are *much* faster then the Glut Fonts
The code has been considerably reworked, albeit a long time ago,
since I implemented the PLIB Font mechanisms.
That said I believe you want to look at hud.hxx
class fgText {
void Draw(fntRenderer *fnt,int digits) {
HTH
Norman
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How does the weather work in FlightGear?
On Oct 10, 2005, at 10:26 AM, Ampere K. Hardraade wrote:On October 10, 2005 03:37 am, Erik Hofman wrote: Buchanan, Stuart wrote: FlightGear can fetch the current weather at yourstarting airport, or you can set the wind, cloudlayers etc manually. I don't know if the weatherconditions are global, or change as you fly todifferent locations. It interprets the data from the nearest METAR station. The data isfetched from noaa.gov.Erik In my opinion, it would be better if data from multiple nearby METAR stations is used instead of fetching data from only one station. I often fly with real-weather-fetch enabled, and the plane gets a huge jolt whenever the weather is updated. The change in the visual aspects is also too sudden. Using data from multiple METAR stations could avoid the above problems and allow us to have a smooth transistion in weather.AmpereThis is not as obvious as it would first seem. Some weather phenomena have very sharp transitions and some are gradual. So I don't think that "interpolating weather" is a trivial thing to do. For example a cold front is often a very well defined line with rain right along the front. In that case the weather right nearby is the best indicator and a METAR from 5 miles away could give a completely different story. Airmass thunderstorms are another example where very local weather is what matters. To make maters worse the METAR will just have temperature and wind, so you would have to look at a few different locations and times to figure out that a front has passed. And the local geography (mountains, lake effects, shore lines) can also be a significant issue.I am not saying that it could not be done, just that it would take some real thought and real understanding of weather phenomena for it to apply in the general case rather than just in a few specific case and make things worse other times. --Adam ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: (electrical) Flightgear-devel Digest, Vol 30, Issue 24
Steve Knoblock wrote: Can you point this dummy to where the nasal electical system or documents are? Sorry I have to make this quick, but the nasal electrical system is simply a nasal script that impliments the electrical system. There should be an example in the c172 folder ... look for something like c172-electrical.nas (or something similar.) The aircraft-set.xml file can reference aircraft specific nasal scripts so that's what you need to do to activate the electrical system. The nasal script is specific code to impliment a specific aircraft's electrical system, but the overall structure could be copied and adapted to new aircraft. But each aircraft will need it's own aircraft specific script. Other than that, the script just runs every frame and reads and sets property values appropriately. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS version/terrasync DB problem with UG25, LL62: crash(bo105)/strange(ufo)
When I start the CVS version at the UG25 airport with bo105 (yesterday's CVS data, the day before CVS sources), it core dumps on startup as follows: #0 yasim::Turbulence::getTurbulence (this=0xad2cee0, loc=0x4fea8008, alt=nan(0x40), up=0xbfffed60, turbOut=0xbfffedb0) at Turbulence.cpp:100 #1 0x081cfc13 in yasim::Model::localWind (this=0xa698c24, pos=0xbfffee90, s=0xbfffefb0, out=0xbfffeea0, alt=7.8685184e+09) at Model.cpp:537 #2 0x081cf4e3 in yasim::Model::calcForces (this=0xa698c24, s=0xbfffefb0) at Model.cpp:399 #3 0x081cca9c in yasim::Integrator::calcNewInterval (this=0xa698c28) at Integrator.cpp:176 #4 0x081c4e84 in yasim::FGFDM::iterate (this=0xa698c20, dt=0.0083377) at FGFDM.cpp:91 #5 0x081bf030 in YASim::update (this=0xa6984f8, dt=0.05080627835587) at YASim.cxx:212 #6 0x080575a5 in fgUpdateTimeDepCalcs () at main.cxx:170 #7 0x08058174 in fgMainLoop () at main.cxx:478 #8 0x0808cc75 in GLUTidle () at fg_os.cxx:114 #9 0x40410c67 in glutMainLoop () from /usr/lib/libglut.so.3 #10 0x0805ac76 in fgMainInit (argc=6, argv=0xb864) at main.cxx:1012 #11 0x0805703a in main (argc=1340768264, argv=0x4fea8008) at bootstrap.cxx:193 We are talking about the CVS preferences.xml here, w/o any real-world-wx-fetch. The core dump is always at the same place (pointers are different). If I do it with the ufo, it starts in some white warp space (cockpit view -- solid white around the aircraft, same w/chase etc.) and from the tower one doesn't see anything at all. The last released version just hangs if I start it up there --- the splash screen never goes away! Now if I take a UFO and fly from a nearby airport to UG25 (say, from UGGG), then one sees solid white instead of the runway --- broken scenery, or broken fgfs? See a screenshot of what I am talking about at http://www.tarunz.org/~vassilii/Images/fg/UG25-cutout.jpg A similar thing happens at LL62 (crash of the CVS version/cutout): http://www.tarunz.org/~vassilii/Images/fg/LL62-cutout.jpg I thought there some problem with the LETTERLETTERNUMBERNUMBER airport data scenery automatic generation, but, e.g. JY07 is all right. I'm running Debian Linux 2.6.8-2-686, NVRM version: NVIDIA Linux x86 NVIDIA Kernel Module 1.0-7174 Tue Mar 22 06:44:39 PST 2005 GCC version: gcc version 3.3.5 (Debian 1:3.3.5-13) Model: GeForce2 MX/MX 400 IRQ: 169 Video BIOS: 03.11.00.07.00 Card Type: AGP name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.3 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control client glx vendor string: NVIDIA Corporation client glx version string: 1.3 When I'm testing the CVS version, it uses the CVS simgear as well. All the other packages (plib, openal etc) are debian ones. HTH, Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] military etc airport beacon?
Does the airports source database include the military designation? If yes, then it would add to the realism to have the different beacons, e.g., military airfield == GREN/white/white (see http://www.faa.gov/ATpubs/AIM/Chap2/aim0201.html ). Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] README.multiplayer update
I've updated README.multiplayer to reflect the recent changes. I'm not addressing the released/cvs incompatibility issue in there, hopefully this is fine. Index: data/Docs/README.multiplayer === RCS file: /var/cvs/FlightGear-0.9/data/Docs/README.multiplayer,v retrieving revision 1.1 diff -u -p -r1.1 README.multiplayer --- data/Docs/README.multiplayer21 Aug 2004 08:57:29 - 1.1 +++ data/Docs/README.multiplayer12 Oct 2005 00:23:45 - @@ -54,19 +54,65 @@ is the sort of implementation that we ar visual simulator. -For use with a server (when one is created): - +For use with a server: +-- +Oliver Schroeder has created a server for multiplayer flightgear use. +The server acts as a packet forwarding mechanism. When it +receives a packet, it sends it to all other active players. +Future versions might be more scalable, only forwarding information +on the planes in the receiving player's vicinity. + +Check out the server homepage http://www.o-schroeder.de/fg_server/ +for the current status. You can either download the server for +some local use, or join the developers on the existing servers. + +Pigeon http://pigeond.net has created a web page monitoring +two such servers, showing the traffic in a Google map environment. +See http://pigeond.net/flightgear/fg_server_map.html. + +Options needed to enable multiplayer game with a server: Player1: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5500 +--multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002 --callsign=player1 Player2: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5501 +--multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002 --callsign=player2 -Playern: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5502 ---callsign=playern +... -The server would simply act as a packet forwarding mechanism. When it -receives a packet, it sends it to all other active players. +PlayerN: +--multiplay=out,10,serveraddress,5002 --multiplay=in,10,myaddress,5002 +--callsign=playerN + +Note that if every player using a particular server, such as one of those +listed on the Pigeon's page, needs to have a unique callsign, not +already in use on that server. + +If you are sitting behind a NAT'ting firewall, then you need to forward +the incoming traffic on the firewall outer (visible to the internet) +address arriving at the UDP port you use (5002 in the case above) +over to your private LAN address. In this case, use your PRIVATE LAN address +as myaddress. Example (if your private LAN address is 10.0.0.1, +in order to play on pigeond.net): + +fgfs --multiplay=in,10,10.0.0.1,5002 --multiplay=out,10,pigeond.net,5002 + --callsign=...UNIQUE callsign here... + +If you and the server are in the same address space (i.e., both have a public +IP address or both are on the same private LAN), you hopefully don't need to +mess with any firewalls. + +If you don't see other players playing on the same server in your flightgear, +check that you have followed the above router configuration guidelines. Check +that you don't have any LOCAL firewall running on your computer preventing the +flightgear network traffic flow. + +Finally, use ethereal(1) or tethereal(1) to capture the UDP traffic on the port +that you are using, and see if you observe both incoming and outgoing packets. + +It's a good idea to talk to the IRC channel #flightgear on irc.flightgear.org +while flying on one of the public servers. Also, it makes sense for every user +on the same server to use the same weather setup, e.g., the real weather +METAR feed, selected by setting to true the real-world-weather-fetch and +control-fdm-atmosphere properties. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] (electrical) Flightgear-devel Digest, Vol 30, Issue 24
Curt wrote: The nasal script is specific code to impliment a specific aircraft's electrical system, but the overall structure could be copied and adapted to new aircraft. But each aircraft will need it's own aircraft specific script. I'll add that there are probably several ways to do various mechanical/electrical system models. You may recall from Summer 2005 JSBSim newsletter an article about the L410 aircraft model done by Jiri Javurek. They use the JSBSim flight control components to model various systems in ways I had not considered before. For example (and this is old format - the current format in FlightGear CVS - JSBSim specification): FLIGHT_CONTROL NAME=l410 !--Stav baterii-- COMPONENT NAME=battery-all-ok TYPE=SWITCH TEST LOGIC=DEFAULT VALUE=0 /TEST TEST LOGIC=AND VALUE=1 /systems/l410/battery1-ok == 1 /systems/l410/battery2-ok == 1 /TEST /COMPONENT COMPONENT NAME=battery-one-ok TYPE=SWITCH TEST LOGIC=DEFAULT VALUE=0 /TEST TEST LOGIC=OR VALUE=1 /systems/l410/battery1-ok == 1 /systems/l410/battery2-ok == 1 /TEST /COMPONENT COMPONENT NAME=battery-all-ok2 TYPE=PURE_GAIN INPUT fcs/battery-all-ok GAIN 1 OUTPUT /systems/l410/battery-all-ok /COMPONENT COMPONENT NAME=battery-one-ok2 TYPE=PURE_GAIN INPUT fcs/battery-one-ok GAIN 1 OUTPUT /systems/l410/battery-one-ok /COMPONENT !-- specialni nasobne sbernice -- COMPONENT NAME=spec-turn TYPE=SWITCH TEST LOGIC=DEFAULT VALUE=0 /TEST TEST LOGIC=AND VALUE=1 /systems/electrical/outputs/bus28v 10 /systems/electrical/outputs/bus36v 10 /systems/electrical/outputs/bus115v 10 /TEST /COMPONENT COMPONENT NAME=spec-turn2 TYPE=PURE_GAIN INPUT fcs/spec-turn GAIN 1 OUTPUT /controls/switches/specbus_28v_115v_36v /COMPONENT etc. It's quite an impressive use of the components. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
