[Flightgear-devel] [BUG] menu entry Location/Select Airport from List non-functional
The menu entry Location/Select Airport from List doesn't do anything. (Haven't had time to fix that yet and I'm away for about three weeks.) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Jsbsim-devel] Re: Simplot compilation fails
On Fri, 20 Aug 2004 15:58:29 +0200
Steven Beeckman [EMAIL PROTECTED] wrote:
I've checked the latest CVS snapshot from SimGear.org, and even there
I find 2 readXML-methods in easyxml.hxx, so that won't be the
problem. I've commented out the readXML-method with 3 arguments in
easyxml.hxx, which seemed to solve the overloading problem.
So in main.cpp the code looks like this:
ifstream inputfile(argv[2]);
if (!inputfile) {
cerr Could not open autoplot file argv[2] endl endl;
exit(-1);
}
plotXMLVisitor myVisitor;
readXML (inputfile, myVisitor);|
Unfortunately, compiling gives this:
|[EMAIL PROTECTED]:~/JSBSim/JSBSim/utilities$ g++ *.cpp
-I/usr/local/include/ -L/usr/local/dislin/ -ldislnc -o simplot
main.cpp: In function `int main(int, char**)':
main.cpp:69: could not convert `inputfile' to `const std::string'
/usr/local/include/simgear/xml/easyxml.hxx:377: in passing argument
1of `void readXML(const std::string, XMLVisitor)'
|
Calling readXML with argv[2] instead of inputfile gives (again) an
undefined reference about the readXML-method (still commented out the
one with 3 arguments). Any ideas how to solve this problem?
Yes, calling readXML() with a char* would not be good - wrong type.
However, I am using this form in two applications, and compiling under
CygWin, with no problem (this is from a different application that
simplot):
ifstream inputfile(argv[1]);
if (!inputfile) {
cerr Could not open XML file argv[1] endl endl;
exit(-1);
}
FGXMLParse myXMLFile;
readXML (inputfile, myXMLFile);
It seems as if your compiler is choking on the first argument of
readXML() not being a const reference to a string. I'm not sure how to
solve this. I'll cross-post to flightgear-devel - someone there may
have a clue.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Jsbsim-devel] Re: Simplot compilation fails
On Fri, 20 Aug 2004 09:37:29 -0500 Jon S Berndt [EMAIL PROTECTED] wrote: to solve this. I'll cross-post to flightgear-devel - someone there may have a clue. Jon Disregard this - I goofed. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Channel input frequency
Curtis L. Olson wrote: What I would like to do with the FG/SimGear is, that I could use the created scenery and could input LAT,LONG,ALT,HEADING,PITCH,ROLL,YAW from serial port and make the engine (SimGear??) to position the camera with those parameters. I did this with MSFS 2000 + FSUIPC interface with VisualBasic, but it is a bit too slow. You may want to develop your own custom protocol module to minimize (optimize?) the data you are sending but that is pretty straightforward. Once you do that you can have FG grab new data off the serial port as fast as your machine can render it. (You can specify the rate in hz you wish to poll the serial port (or any other input channel.)) That remind me something I saw recently : the socket channel, and I guess others, obey to the Hz parameter even in read mode. So, when you start fg with --telnet=5501, it default to 5hz and you can only update properties at that rate. It this case, an external program was moving an airplane model that was put in the /models/model/... property hierarchy and we were surprised to see the model doing big jumps although the external program was pushing property updates as fast as it could. There was no data congestion though because every 5Hz, the telnet server was reading and processing all available data at that time. The problem was solved by providing 30Hz to the telnet server. So, is it a wanted behavior ? One could think that an input channel might process data as soon as they arrive on the port/socket. I could try to cook a patch if it is something we want to change. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] FDM from file broken?
I've looked into this further and it seems that FGNative::process() fails when reading in FDM data from the file. Process() calls io-read(...) asking for a 1704 byte chunks from the input file. After one or two successful 1704 reads, io-read(...) returns indicating that it couldn't read another 1704 bytes from the file and FGNative::process() dies. This happens even though the total numbers of bytes read from the file are no where near its total size. Unless I've set something up incorrectly, it looks like this functionality is broken. Does anyone know if this is a known issue? Replay functionality is very important to me, so if it's broken I'll take the time to fix it; I just want to make sure it's not something I've set up incorrectly. Also, I'm running FlightGear on Windows XP. Thanks, Vance -Original Message- From: Vance Souders Sent: Thursday, August 19, 2004 3:53 PM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] FDM from file broken? I saved out FDM information using -native=file,out,120,flight1.fgfs. When I try and read it back in using -native=file,in,120,flight1.fgfs --fdm=external, the aircraft just sits there. It looks like FGNative::process() is pulling data out of the file. Any ideas on what might be causing this? I'm using the latest source code release (0.9.5). Thanks, Vance ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FDM from file broken?
Vance Souders wrote: I've looked into this further and it seems that FGNative::process() fails when reading in FDM data from the file. Process() calls io-read(...) asking for a 1704 byte chunks from the input file. After one or two successful 1704 reads, io-read(...) returns indicating that it couldn't read another 1704 bytes from the file and FGNative::process() dies. This happens even though the total numbers of bytes read from the file are no where near its total size. Unless I've set something up incorrectly, it looks like this functionality is broken. Does anyone know if this is a known issue? Replay functionality is very important to me, so if it's broken I'll take the time to fix it; I just want to make sure it's not something I've set up incorrectly. Also, I'm running FlightGear on Windows XP. It could be that process() is reading the entire file the first time. This makes sense in the context of a net connection where you want to grab all pending messages and just use the most recent one, but doesn't make sense in the context of a file obviously. file should be special cased, but perhaps it's been overlooked for the native protocol? 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: bo105 + patch
Alex Romosan wrote: Melchior FRANZ [EMAIL PROTECTED] writes: * Alex Romosan -- Saturday 07 August 2004 01:19: as a matter of fact it does seem that european helicopters behave differently from american ones. Yes, you are right, sorry. I was slightly pissed, because if felt as if you needlessly dragged my country into the matter, only because we didn't agree on technical ground, as if you wanted to say that Austrians (unlike US citizens) do probably not understand much of helicopters. :-) i am not a us citizen and never will (even though i live in the us now) :-) i thought the same might apply to the collective. OK. It doesn't, as others have meanwhile explained. Anyway: I wasn't aware how difficult the bo is actually to fly with just the keyboard. Accidently, I installed fgfs today on a computer at a Red Cross office (for the people on duty to make time pass faster), and it took me *quite* a while to even lift of. (We don't have a js there ... yet.) I'll try to submit a fix tomorrow. I insist on the throttle being inverted on the js, but the keyboard is a different matter. There'll certainly be a viable solution. how about we just reverse the PageUp and PageDown keys (and also add the 1 and 2 key bindings) and get the helicopter to start with the throttle at 100% so it doesn't just take off on you when you start the rotor. this way nothing will change for the joystick users, and for those of us who use the keyboard the bindings will make more sense (up will make the helicopter go up and down will make it go down). what do you say? Sorry again :-] don't worry, it happens. --alex-- You know you can change your own keyboard settings however you like to override the default ones that come with fg, right? Just make your own ~/.fgfs/keyboard.xml file and put whatever changes you want in there. The pull:up/push:down convention on joysticks is pretty univesal, and the keyboard binding follow that. I don't think anyone would ever agree to change it in the defaults, but you're completely free to make permanent changes to your own setup. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] FDM from file broken?
I think I might have goofed... I compiled simgear without __MINGW32__ defined. I'm in the process of recompiling the lib; I'm pretty sure that's what was tripping things up. Thanks, Vance -Original Message- From: Curtis L. Olson [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 12:20 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FDM from file broken? Vance Souders wrote: I've looked into this further and it seems that FGNative::process() fails when reading in FDM data from the file. Process() calls io-read(...) asking for a 1704 byte chunks from the input file. After one or two successful 1704 reads, io-read(...) returns indicating that it couldn't read another 1704 bytes from the file and FGNative::process() dies. This happens even though the total numbers of bytes read from the file are no where near its total size. Unless I've set something up incorrectly, it looks like this functionality is broken. Does anyone know if this is a known issue? Replay functionality is very important to me, so if it's broken I'll take the time to fix it; I just want to make sure it's not something I've set up incorrectly. Also, I'm running FlightGear on Windows XP. It could be that process() is reading the entire file the first time. This makes sense in the context of a net connection where you want to grab all pending messages and just use the most recent one, but doesn't make sense in the context of a file obviously. file should be special cased, but perhaps it's been overlooked for the native protocol? 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Loading an XML file using EasyXML
Can someone tell me what the process is once a file has been opened and is being parsed by EasyXML? What do the callbacks do ... what is the standard procedure for reading in the attibutes and elements and data? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] .flightgear file format ?
Hi all, on holiday at the moment, but still watching the list. have been looking at kflog and the zaurus version cumulus. Have rigged a quick nmea recorder using a haicom cf gps reieverplugged into my zaurus c700 kflog has an import function for files with a .flightgear extension. Does anyone know what protocol is used to write a these .flightgear files ?. I'm assuming something along the lines of --protocol=file,out,1,kflog.flightgear for protocols I have tried nmea, native, garmin and fgfs fgfs doesn't seem to exist, with native and garmin kflog complains of no flight data and with nmea kflog doesn't complain but there appears to be no flight. Any info appreciated. Mat ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Loading an XML file using EasyXML
On Freitag, 20. August 2004 18:48, Jon S Berndt wrote: Can someone tell me what the process is once a file has been opened and is being parsed by EasyXML? What do the callbacks do ... what is the standard procedure for reading in the attibutes and elements and data? See: http://www.simgear.org/doxygen/easyxml_8hxx.html It is a quite neat implementation. And I think that using integrating this provides is a good chance to seperate configuration data from state data. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Loading an XML file using EasyXML
On Fri, 20 Aug 2004 20:55:18 +0200 Mathias Fröhlich [EMAIL PROTECTED] wrote: On Freitag, 20. August 2004 18:48, Jon S Berndt wrote: Can someone tell me what the process is once a file has been opened and is being parsed by EasyXML? What do the callbacks do ... what is the standard procedure for reading in the attibutes and elements and data? See: http://www.simgear.org/doxygen/easyxml_8hxx.html It is a quite neat implementation. And I think that using integrating this provides is a good chance to seperate configuration data from state data. Yes, I've seen that page. I've written (now) two applications that use the EasyXML class, and it is a very nice (and Easy) class to use. With the plotting application, it was not too difficult to use it (even if I did so incorrectly). There was one class that was subclassed from XMLVisitor, and it included all the plotting parameters I needed. However, in the case of JSBSim, there are now several classes that read in data from the configuration file (FGFDMExec does the initial read, and hands off the config file handle to other classes to let them read in their own data). The Aerodynamics, MassBalance, Aircraft, Output, etc. classes currently all read in their own data from the configuration file. Today, I have written a class that parses JSBSim format config files. Within the callbacks I simply echo the information read from the files. Currently, FGXMLParser (the name of the potential new class to replace FGConfigFile) can parse the config file, but then the question is: what do I do, now. Remember, currently in JSBSim each file reads in its own data as the config file class encounters the relevant sections in the config file. With FGXMLParser we have callbacks - this is philosophically different from FGConfig File. So, my question is: What is the philosophy behind loading various classes with their own data from the config file using EasyXML callbacks? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Loading an XML file using EasyXML
Jon S Berndt wrote: So, my question is: What is the philosophy behind loading various classes with their own data from the config file using EasyXML callbacks? You could store the data into a property tree and let every subsystem scan it's own directory. This tree could be detached from the main tree and could be removed safely after initialization is done. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Loading an XML file using EasyXML
On Freitag, 20. August 2004 21:10, Jon S Berndt wrote: So, my question is: What is the philosophy behind loading various classes with their own data from the config file using EasyXML callbacks? This kind of xml parsers is designed to build a 'tree' of objects representing the data stored in the 'tree' of the xml file. Thus this kind of parsers fit very well for the property /tree/ example Erik mentioned. But also an aircraft is built like such a tree. The top node is the aircraft itself. This one has a flightcontrolsystem, some object containing the aerodynamic properties of the aircraft, a list of engines, a list of undercarriage elements and so on. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] FDM from file broken?
Well, it still doesn't work. I tried exporting and importing a flight using -native... with the released windows binary and it exhibits the same behavior as the source release. -Vance -Original Message- From: Vance Souders Sent: Friday, August 20, 2004 12:30 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] FDM from file broken? I think I might have goofed... I compiled simgear without __MINGW32__ defined. I'm in the process of recompiling the lib; I'm pretty sure that's what was tripping things up. Thanks, Vance -Original Message- From: Curtis L. Olson [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 12:20 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FDM from file broken? Vance Souders wrote: I've looked into this further and it seems that FGNative::process() fails when reading in FDM data from the file. Process() calls io-read(...) asking for a 1704 byte chunks from the input file. After one or two successful 1704 reads, io-read(...) returns indicating that it couldn't read another 1704 bytes from the file and FGNative::process() dies. This happens even though the total numbers of bytes read from the file are no where near its total size. Unless I've set something up incorrectly, it looks like this functionality is broken. Does anyone know if this is a known issue? Replay functionality is very important to me, so if it's broken I'll take the time to fix it; I just want to make sure it's not something I've set up incorrectly. Also, I'm running FlightGear on Windows XP. It could be that process() is reading the entire file the first time. This makes sense in the context of a net connection where you want to grab all pending messages and just use the most recent one, but doesn't make sense in the context of a file obviously. file should be special cased, but perhaps it's been overlooked for the native protocol? 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Loading an XML file using EasyXML
On Fri, 20 Aug 2004 21:40:28 +0200 Mathias Fröhlich [EMAIL PROTECTED] wrote: On Freitag, 20. August 2004 21:10, Jon S Berndt wrote: But also an aircraft is built like such a tree. The top node is the Some aircraft are even built OUT OF trees. ;-) aircraft itself. This one has a flightcontrolsystem, some object containing the aerodynamic properties of the aircraft, a list of engines, a list of undercarriage elements and so on. Erik's approach might work. I will have to play with the parsing to see different approaches, and how they might work. Thanks, Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Loading an XML file using EasyXML
Erik Hofman wrote: Jon S Berndt wrote: So, my question is: What is the philosophy behind loading various classes with their own data from the config file using EasyXML callbacks? You could store the data into a property tree and let every subsystem scan it's own directory. This tree could be detached from the main tree and could be removed safely after initialization is done. I think Jon wants to preserve the current JSBsim syntax and not use the property syntax. However Jon, you can have a look at the readProperties functions here http://www.simgear.org/doxygen/props__io_8hxx.html that will show you a non trivial use of readXML to retrieve the property tree. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Loading an XML file using EasyXML
On Fri, 20 Aug 2004 22:01:43 +0200 Frederic Bouvier [EMAIL PROTECTED] wrote: I think Jon wants to preserve the current JSBsim syntax and not use the property syntax. -Fred Well, perhaps. The thing is, certain items that would be parsed from the configuration file, such as landing gear, aero coefficients, engines, and flight control components, are _instantiated_ when they are read from the config file. The parsing process does not simply read property values and assign them. The configuration of the specific simulation is formed. Also, the interest is in allowing each class to extract its own values from the config file. That makes it a little trickier. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
