Re: [Flightgear-devel] submodels proprty change
On Thursday 28 October 2004 09:45, Erik Hofman wrote: David Culp wrote: Hi Erik, I was wondering if the enable and path properties for the submodel system should be moved out of /sim/systems/submodels and into /sim/submodels instead. This will complete the migration out of the Systems code. Cvs is now updated to put the submodel code under /sim/submodels instead of /sim/systems and also (but more importantly) /systems/submodels under /ai/submodels. The latter is important for submodel configuration files. I have updated the ones already in the base package, but keep this in mind when creating a new one. Erik I've not been able to get get the ai submodels to work since this change. It seemed straight forward enough and I checked the changes to the Spitfire and F-16 but they don't seem to work now either. Looking in the property tree browser, I can't see any of the sub-model data - there's no sub-models branch in either /ai/ or /sim/ai/ The /sim/submodels/ branch is also empty. Are the AI sub-models in the Spitfire + F-16 still working for everyone else, or have I missed a parameter change again? :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] submodels proprty change
On Sunday 31 October 2004 16:10, Lee Elliott wrote: On Thursday 28 October 2004 09:45, Erik Hofman wrote: David Culp wrote: Hi Erik, I was wondering if the enable and path properties for the submodel system should be moved out of /sim/systems/submodels and into /sim/submodels instead. This will complete the migration out of the Systems code. Cvs is now updated to put the submodel code under /sim/submodels instead of /sim/systems and also (but more importantly) /systems/submodels under /ai/submodels. The latter is important for submodel configuration files. I have updated the ones already in the base package, but keep this in mind when creating a new one. Erik I've not been able to get get the ai submodels to work since this change. It seemed straight forward enough and I checked the changes to the Spitfire and F-16 but they don't seem to work now either. Looking in the property tree browser, I can't see any of the sub-model data - there's no sub-models branch in either /ai/ or /sim/ai/ The /sim/submodels/ branch is also empty. Are the AI sub-models in the Spitfire + F-16 still working for everyone else, or have I missed a parameter change again? :) LeeE I think I've managed to fix it... Sorry :) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] submodels - config file
David Culp asked: My submodel config file is not getting read at startup (I'm getting file not found). Is anyone using CVS FlightGear and Linux having this problem also? Thought I'd check before I go over the config file for the fiftieth time looking for an error. I'm getting the same warning in Cygwin, but then it works OK, so I've been giving it a good ignoring. I guess we ought to look into it though. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] submodels - config file
On Wednesday 27 October 2004 04:08, David Culp wrote: My submodel config file is not getting read at startup (I'm getting file not found). Are you getting file not found or No systems model specified for this model!? Is anyone using CVS FlightGear and Linux having this problem also? Thought I'd check before I go over the config file for the fiftieth time looking for an error. Are you using the generic config or a custom made? If you are using a custom config, you must remember to override the generic one by including it in your aircraft *-set.xml file. like this: sim ... systems pathpath/to/your/file/path /systems ... sim -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] submodels - config file
Is anyone using CVS FlightGear and Linux having this problem also? Thought I'd check before I go over the config file for the fiftieth time looking for an error. Are you using the generic config or a custom made? If you are using a custom config, you must remember to override the generic one by including it in your aircraft *-set.xml file. like this: sim ... systems pathpath/to/your/file/path /systems ... sim The submodel system has been moved away from the Systems code. It's now an independent subsystem of FG. I think the spitfire submodels are working because I get a crash due to a crease token, which implies the smoke submodel is being created. I'm getting an error that would indicate the config file is either not being found or cannot be parsed: Unable to read submodels file: /home/dave/FlightGear/data/Aircraft/FW190/submodels.xml Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] submodels - config file
David Culp wrote: Unable to read submodels file: /home/dave/FlightGear/data/Aircraft/FW190/submodels.xml Did you already load the file in your browser to see if it's XML compliant? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] submodels - config file
David Culp wrote: ... snip ... The submodel system has been moved away from the Systems code. It's now an independent subsystem of FG. I think the spitfire submodels are working because I get a crash due to a crease token, which implies the smoke submodel is being created. I'm getting an error that would indicate the config file is either not being found or cannot be parsed: Unable to read submodels file: /home/dave/FlightGear/data/Aircraft/FW190/submodels.xml If the Spitfire works (ish ... how about upgrading to a version that accepts the crease token?) it looks as if the problem might be in the /FW190/submodels.xml file Try replacing it with one known to be good (Hunter or Spitfire). Both those are in the Aircraft/.../Models directory. If that doesn't work, send the files to me and I'll give them a try on my system. BTW, how do I resurrect the USS Saratoga? Mathias and I are beginning work on arrester wires. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] submodels - config file
Never mind. I somehow got some DOS line endings in my file. Must have been a cut/paste from a DOS document. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] submodels - config file
On Wednesday 27 October 2004 15:09, David Culp wrote: The submodel system has been moved away from the Systems code. It's now an independent subsystem of FG. Silly me! I must have confused submodels with systems. I thought you where talking about systems. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
On 23 October 2004 21:22 Roy Vegard Ovesen wrote: On Saturday 23 October 2004 21:14, Vivian Meazza wrote: I've finally found time to revisit this problem. The FGFS is working fine with updates up to 15th Oct. Paths, etc. are good. I've updated and recompiled Simgear and Flightgear. Nothing else has been changed. Should work, right? Wrong: I get the following errors using the default aircraft: Object PanelInstruments not found Object ControlsGroup not found I also get these now and then. No instrumentation model specified for this model! I also get this: General Initialization === == FG_ROOT = /FlightGear-cvs/data Which is correct. The menu bar has also disappeared, so it would seem likely that the correct path is not being found. Problem solved, well not solved, more understood. Despite showing the path as: General Initialization === == FG_ROOT = /FlightGear-cvs/data In fact, fgfs is reading the old preferences.xml file in the path specified in fgfs.exe. That looks like a bug in the initialization process to me. This does not happen using fgrun under windows, which reads the correct preferences.xml. That led me down the wrong path yesterday. The menu bar re-appeared this morning, without my having done anything. I suppose recycling the power supply (aka switching off) did the trick. However, it enabled me to identify the problem very quickly. The fix is simple - put the new preferences.xml file in the 'wrong' path. A nuisance though, since it means that it is not trivial to go back before 15th Oct cvs for testing purposes. I don't know if it's worth any effort on tracing and fixing the bug, or just living with it. As usual, thank you for your help. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
I wrote some time ago: ... snip ... I've gone back to cvs update as of 15 Oct: all the aircraft work correctly. I conclude that this problem is caused by your new code. Unless you can confirm that the instruments work in all models in your location, or tell me exactly what I have to do to correct the situation, I strongly suggest that whatever has been done, be undone. I understand that you are frustrated, but IMHO the ability to configure instrumentation and systems is an improvement. I also think that going back to them being hardcoded is a step in the wrong direction. I agree, it's definitely the right way forward, I'll keep on trying. It's only frustrating because I have been looking at the problem at the individual aircraft level, and I don't think that the problem lies there. It must be a more general problem. And it's going to be a duh!! when I get there. I've finally found time to revisit this problem. The FGFS is working fine with updates up to 15th Oct. Paths, etc. are good. I've updated and recompiled Simgear and Flightgear. Nothing else has been changed. Should work, right? Wrong: I get the following errors using the default aircraft: Object PanelInstruments not found Object ControlsGroup not found No instrumentation model specified for this model! I also get this: General Initialization === == FG_ROOT = /FlightGear-cvs/data Which is correct. The menu bar has also disappeared, so it would seem likely that the correct path is not being found. However, it was before I updated. Checking, I find that /sim/systems/path contains 'Aircraft/Generic/generic-systems.xml' (unspecified). Correct, but should this be a string type? A quick cout check in systems_mgr.cxx shows that path_n = 0, so there's the problem. Possibly a problem in simgear/misc/sg_path.hxx? Unlikely, that hasn't been changed in months. So, it's not a duh yet :-). Any advice on what to check next? Can any other Cygwin user confirm my findings, or tell me what they have done differently? Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Saturday 23 October 2004 21:14, Vivian Meazza wrote: I've finally found time to revisit this problem. The FGFS is working fine with updates up to 15th Oct. Paths, etc. are good. I've updated and recompiled Simgear and Flightgear. Nothing else has been changed. Should work, right? Wrong: I get the following errors using the default aircraft: Object PanelInstruments not found Object ControlsGroup not found I also get these now and then. No instrumentation model specified for this model! I also get this: General Initialization === == FG_ROOT = /FlightGear-cvs/data Which is correct. The menu bar has also disappeared, so it would seem likely that the correct path is not being found. However, it was before I updated. Checking, I find that /sim/systems/path contains 'Aircraft/Generic/generic-systems.xml' (unspecified). Correct, but should this be a string type? You could try to explicitly specify it as a string type: path type=stringAircraft/Generic/generic-systems.xml/path in preferences.xml. Are you absolutely 100% sure that '/Flightgear-cvs/data/Aircraft/Generic/generic-systems.xml' exists? A quick cout check in systems_mgr.cxx shows that path_n = 0, so there's the problem. Possibly a problem in simgear/misc/sg_path.hxx? Unlikely, that hasn't been changed in months. The autopilot uses the exact same coding technique (that's where I copied and pasted from). And the autopilot does not explicitly set the type to string, so I have little hopes for my tip :-( So, it's not a duh yet :-). Any advice on what to check next? Can any other Cygwin user confirm my findings, or tell me what they have done differently? You could try to insert a cout in xmlauto.cxx, in the init method of FGXMLAutopilot, at least to confirm that path_n != 0 there. Maybe '/sim/systems/path' does not exist in the property tree when instr_mgr is trying to read it. You could try to set this property in the command line, I forget how to, but I'm sure you'll figure it out. Try to step through the code with a debugger. IIRC 'insight' should be available on Cygwin. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
Roy Vegard Ovesen Sent: 20 October 2004 00:32 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Submodels On Tuesday 19 October 2004 19:42, Vivian Meazza wrote: It's not obviously a path problem. My preferences.xml file was updated at 15:22 yesterday, and has the right paths to the new generic files. However, the properties relating to instruments are empty - hence broken instruments :-). But if they work for you, the problem must be local, so I'll keep looking. Since it's all the instruments the common factor is the electrical supply, so I'll start there. I would suggest that you try to create custom systems and instrumentation configuration files for your aircraft. Use the generic ones as a start. I think that you should remove the GPS instrument ;-) and maybe the nav radios. I have checked the path - I'm was the downloaded cvs data from 1522 Monday. I have re-downloaded cvs data and source this morning and recompiled. I've changed the hunter to use the generic files - it already has custom electrics and instrumentation - still the altimeter, ASI, climb-rate and turn and slip don't work. Hsi and directional gyro work, but they take their input from the 'wrong' place. In the property browser all the instrument values are undefined. The P51d instruments also don't work, in fact all the instruments I have tested don't work. I suspect the instruments generically don't work. Can you reconfirm that all the hunter/seahawk/P51 instruments work for you? And did you change anything in the hunter files? I've gone back to cvs update as of 15 Oct: all the aircraft work correctly. I conclude that this problem is caused by your new code. Unless you can confirm that the instruments work in all models in your location, or tell me exactly what I have to do to correct the situation, I strongly suggest that whatever has been done, be undone. Regards, Vivian P.S. I have wasted a day's work on this issue, and my teddy bear has now been thrown out of the pram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Wednesday 20 October 2004 12:03, Vivian Meazza wrote: I have checked the path - I'm was the downloaded cvs data from 1522 Monday. I have re-downloaded cvs data and source this morning and recompiled. I've changed the hunter to use the generic files - it already has custom electrics and instrumentation - still the altimeter, ASI, climb-rate and turn and slip don't work. Hsi and directional gyro work, but they take their input from the 'wrong' place. In the property browser all the instrument values are undefined. The P51d instruments also don't work, in fact all the instruments I have tested don't work. I suspect the instruments generically don't work. Can you reconfirm that all the hunter/seahawk/P51 instruments work for you? And did you change anything in the hunter files? I also updated from CVS this morning and all instruments still work, here. I guess that if all instruments and all systems in every aircraft were broken then a whole lot of other people would have noticed too. I have not changed anything in the hunter or any other aircraft. Try to run Flightgear with --log-level=info and look for these lines: Reading instruments from data/Aircraft/Generic/generic-instrumentation.xml Adding subsystem instrumentation Reading systems from data/Aircraft/Generic/generic-systems.xml Adding subsystem systems This is what you should get. If you get something like: No instrumentation model specified for this model! or Failed to load instrumentation model: , then something is wrong, obviously. When Flightgear is running try to browse to this property: /sim/instrumentation/path It should contain data/Aircraft/Generic/generic-instrumentation.xml if you are using the generic configuration, or if you are using a custom made configuration it should of course contain the path to that file. I've gone back to cvs update as of 15 Oct: all the aircraft work correctly. I conclude that this problem is caused by your new code. Unless you can confirm that the instruments work in all models in your location, or tell me exactly what I have to do to correct the situation, I strongly suggest that whatever has been done, be undone. I understand that you are frustrated, but IMHO the ability to configure instrumentation and systems is an improvement. I also think that going back to them being hardcoded is a step in the wrong direction. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
Roy Vegard Ovesen: Sent: 20 October 2004 13:31 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Submodels On Wednesday 20 October 2004 12:03, Vivian Meazza wrote: I have checked the path - I'm was the downloaded cvs data from 1522 Monday. I have re-downloaded cvs data and source this morning and recompiled. I've changed the hunter to use the generic files - it already has custom electrics and instrumentation - still the altimeter, ASI, climb-rate and turn and slip don't work. Hsi and directional gyro work, but they take their input from the 'wrong' place. In the property browser all the instrument values are undefined. The P51d instruments also don't work, in fact all the instruments I have tested don't work. I suspect the instruments generically don't work. Can you reconfirm that all the hunter/seahawk/P51 instruments work for you? And did you change anything in the hunter files? I also updated from CVS this morning and all instruments still work, here. I guess that if all instruments and all systems in every aircraft were broken then a whole lot of other people would have noticed too. That's the info I need: it's still got to be a local problem. Path looks the likely candidate. Everything looks like it's in the right place. I have not changed anything in the hunter or any other aircraft. Try to run Flightgear with --log-level=info and look for these lines: Reading instruments from data/Aircraft/Generic/generic-instrumentation.xml Adding subsystem instrumentation Reading systems from data/Aircraft/Generic/generic-systems.xml Adding subsystem systems This is what you should get. If you get something like: No instrumentation model specified for this model! or Failed to load instrumentation model: , then something is wrong, obviously. What is likely to be wrong? When Flightgear is running try to browse to this property: /sim/instrumentation/path It should contain data/Aircraft/Generic/generic-instrumentation.xml if you are using the generic configuration, or if you are using a custom made configuration it should of course contain the path to that file. I've gone back to cvs update as of 15 Oct: all the aircraft work correctly. I conclude that this problem is caused by your new code. Unless you can confirm that the instruments work in all models in your location, or tell me exactly what I have to do to correct the situation, I strongly suggest that whatever has been done, be undone. I understand that you are frustrated, but IMHO the ability to configure instrumentation and systems is an improvement. I also think that going back to them being hardcoded is a step in the wrong direction. I agree, it's definitely the right way forward, I'll keep on trying. It's only frustrating because I have been looking at the problem at the individual aircraft level, and I don't think that the problem lies there. It must be a more general problem. And it's going to be a duh!! when I get there. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Wednesday 20 October 2004 15:09, Vivian Meazza wrote: Try to run Flightgear with --log-level=info and look for these lines: Reading instruments from data/Aircraft/Generic/generic-instrumentation.xml Adding subsystem instrumentation Reading systems from data/Aircraft/Generic/generic-systems.xml Adding subsystem systems This is what you should get. If you get something like: No instrumentation model specified for this model! or Failed to load instrumentation model: , then something is wrong, obviously. What is likely to be wrong? If you get No instrumentation ... then FG is not parsing the instrument configuration file at all. If you get Failed to load ... then parsing has failed. I think that one of these two might be the reason for your problems. Either the config files never get parsed, or parsing of them fails. I would try to use a debugger to step through the code to see exactly what is happening. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
-Original Message- From: [EMAIL PROTECTED] [mailto:flightgear-devel- [EMAIL PROTECTED] On Behalf Of Roy Vegard Ovesen Sent: 19 October 2004 00:55 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Submodels On Tuesday 19 October 2004 01:00, Roy Vegard Ovesen wrote: On Tuesday 19 October 2004 00:10, Vivian Meazza wrote: OK, I've just updated cvs, and the inputs to some of my 3d instruments are now broken in the Hunter, Seahawk and Spitfire. How do I get them back? What instruments are not working, and what inputs do they use? Hunter/Seahawk: Altimeter, IAS, Mach, rate-of-climb, and turn-and-slip Spitfire: All of the above plus clock, attitude, and heading. I just tried the Hunter, and I noticed that some of the instrumentation properties where not as expected. They are all ok in the c172. I will look into this. I see that for the Hunter and the Seahawk the vacuum system is not working which leads to the attitude-indicator and the heading-indicator also not working. This is because the engines/engine[0]/rpm property is undefined for the engine on these aircraft. I would guess that this was also the case before systems and instrumentation became configureable. Back then the vacuum system was hardcoded to be driven by engines/engine[0]/rpm. There is no vacuum system on these aircraft. However, I suppose we could try to drive one off N1. Now that the vacuum system is configurable you might consider driving it with another property from engines/engine[0]/, so that you can use the instrumentation/attitude-indicator and instrumentation/heading-indicator insted of orientation/*. They still work here for the Hunter and Seahawk, and they worked before. However, when I built them originally the attitude-indicator pitch property wasn't working correctly, so I had to use orientation - which should still work. I'm sorry that my original posting was incomplete: I only noticed the problem late last night. You got the polite version :-) Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Tuesday 19 October 2004 09:47, Vivian Meazza wrote: What instruments are not working, and what inputs do they use? Hunter/Seahawk: Altimeter, IAS, Mach, rate-of-climb, and turn-and-slip When I checked the Hunter and Seahawk last night all these instruments worked. IIRC the Mach instrument is driven from velocities/mach, so it would _not_ be affected by the changes that I've made. Have you updated the base package? It includes changes to preferences.xml and the two generic systems and instrumentation configurations Spitfire: All of the above plus clock, attitude, and heading. Unfortunately I'm not familiar with the startup procedure of the Spitfire, so I haven't tried it. But again it looks like you forgot to update the base package. There is no vacuum system on these aircraft. However, I suppose we could try to drive one off N1. Are gyros driven by electrical engines then? If so it should be trivial to add a new instrumentation class where the gyro might be driven by an electrical engine. Some months ago I played around with a new gyro class that is driven from an arbitrary torque and uses air friction to slow it down. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Sunday 17 October 2004 02:18 pm, Roy Vegard Ovesen wrote: Hi all! I've not touched the new submodel.*xx sources yet because I want your opinion on how I should implement it into the other configurable systems. The existing configurable systems are the pitot, static, and vacuum systems. These are configured in one configuration file defaulting to Aircraft/Generic/generic-systems.xml. I would like to include the configuration of submodels in this file also, since submodels might be classified as systems. I think it would be best if the submodel system is moved out of the Systems directory altogether and made into a subsystem, like the AI manager. The only reason I put it with the systems originally is that I first used it to model a gun. It quickly became generalized to include smoke, contrails, drop tanks, etc., and an airplane can have many different submodels now. If Erik agrees, I can move it over. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
Vivian Meazza wrote: I think most gyros are electrical. Certainly in the 40's/50's. Really ? From what I've learnt electrically driven gyros are sort of a modern invention where aircraft manufactures tend to rely more and more on a working electrical system Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
Roy Vegard Ovesen wrote: Sent: 19 October 2004 09:54 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Submodels On Tuesday 19 October 2004 09:47, Vivian Meazza wrote: What instruments are not working, and what inputs do they use? Hunter/Seahawk: Altimeter, IAS, Mach, rate-of-climb, and turn-and-slip When I checked the Hunter and Seahawk last night all these instruments worked. IIRC the Mach instrument is driven from velocities/mach, so it would _not_ be affected by the changes that I've made. Have you updated the base package? It includes changes to preferences.xml and the two generic systems and instrumentation configurations Spitfire: All of the above plus clock, attitude, and heading. Unfortunately I'm not familiar with the startup procedure of the Spitfire, so I haven't tried it. But again it looks like you forgot to update the base package. I thought I had, but I'll recheck - it's probably a path problem. There is no vacuum system on these aircraft. However, I suppose we could try to drive one off N1. Are gyros driven by electrical engines then? If so it should be trivial to add a new instrumentation class where the gyro might be driven by an electrical engine. Some months ago I played around with a new gyro class that is driven from an arbitrary torque and uses air friction to slow it down. I think most gyros are electrical. Certainly in the 40's/50's. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
David Culp wrote: I think it would be best if the submodel system is moved out of the Systems directory altogether and made into a subsystem, like the AI manager. The only reason I put it with the systems originally is that I first used it to model a gun. It quickly became generalized to include smoke, contrails, drop tanks, etc., and an airplane can have many different submodels now. If Erik agrees, I can move it over. It's fine by me. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
Vivian Meazza wrote: Sent: 19 October 2004 10:34 To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Submodels Roy Vegard Ovesen wrote: Sent: 19 October 2004 09:54 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Submodels On Tuesday 19 October 2004 09:47, Vivian Meazza wrote: What instruments are not working, and what inputs do they use? Hunter/Seahawk: Altimeter, IAS, Mach, rate-of-climb, and turn-and-slip When I checked the Hunter and Seahawk last night all these instruments worked. IIRC the Mach instrument is driven from velocities/mach, so it would _not_ be affected by the changes that I've made. Have you updated the base package? It includes changes to preferences.xml and the two generic systems and instrumentation configurations Spitfire: All of the above plus clock, attitude, and heading. Unfortunately I'm not familiar with the startup procedure of the Spitfire, so I haven't tried it. But again it looks like you forgot to update the base package. I thought I had, but I'll recheck - it's probably a path problem. There is no vacuum system on these aircraft. However, I suppose we could try to drive one off N1. Are gyros driven by electrical engines then? If so it should be trivial to add a new instrumentation class where the gyro might be driven by an electrical engine. Some months ago I played around with a new gyro class that is driven from an arbitrary torque and uses air friction to slow it down. I think most gyros are electrical. Certainly in the 40's/50's. It's not obviously a path problem. My preferences.xml file was updated at 15:22 yesterday, and has the right paths to the new generic files. However, the properties relating to instruments are empty - hence broken instruments :-). But if they work for you, the problem must be local, so I'll keep looking. Since it's all the instruments the common factor is the electrical supply, so I'll start there. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Tuesday 19 October 2004 19:42, Vivian Meazza wrote: It's not obviously a path problem. My preferences.xml file was updated at 15:22 yesterday, and has the right paths to the new generic files. However, the properties relating to instruments are empty - hence broken instruments :-). But if they work for you, the problem must be local, so I'll keep looking. Since it's all the instruments the common factor is the electrical supply, so I'll start there. I would suggest that you try to create custom systems and instrumentation configuration files for your aircraft. Use the generic ones as a start. I think that you should remove the GPS instrument ;-) and maybe the nav radios. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Monday 18 October 2004 00:24, Vivian Meazza wrote: The ability to set a serviceability state for each submodel system would seem to be the correct approach, but if I understand your proposal correctly, it will end up in more files overall. Actually the systems and instrumentation configuration files are already in CVS. So my point of view is that integrating the submodels configuration into the already existing systems configuration file would result in fewer files. It seems to me that your point of view is that adding systems and instrumentation configuration files would result in more config files. Which of course is true, but as I said systems and instrumentation config is already there (and the won't go away ;-)). As a major user and part-author of the submodel system, I have no objections, A quick grep through the base package revealed that three aircraft use the subsystem: F16, Spitfire and Hunter. I will of course move the subsystem config to system config so that they don't get broken. but David Culp was the originator: his view might differ. You may wish to seek his approval before going ahead with this change. On Wednesday 08 September 2004 01:11, David Culp wrote: David Culp, is it ok if I modify the new submodel so that it can be configured in the systems.xml file along with the rest of the systems? Or do you have another plan for this? Sounds OK to me. Dave I'm not that an experienced programmer, so I am wondering if the vector of submodels approach has superior preformace compared to my approach. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
Roy Vegard Ovesen wrote: A quick grep through the base package revealed that three aircraft use the subsystem: F16, Spitfire and Hunter. I will of course move the subsystem config to system config so that they don't get broken. I have used the F-16 mostly as a demonstrator. I wouldn't mind much if they just disappear. I can always add the flares later. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
Vegard Ovesen wrote: Sent: 18 October 2004 09:26 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Submodels On Monday 18 October 2004 00:24, Vivian Meazza wrote: The ability to set a serviceability state for each submodel system would seem to be the correct approach, but if I understand your proposal correctly, it will end up in more files overall. Actually the systems and instrumentation configuration files are already in CVS. So my point of view is that integrating the submodels configuration into the already existing systems configuration file would result in fewer files. It seems to me that your point of view is that adding systems and instrumentation configuration files would result in more config files. Which of course is true, but as I said systems and instrumentation config is already there (and the won't go away ;-)). As a major user and part-author of the submodel system, I have no objections, A quick grep through the base package revealed that three aircraft use the subsystem: F16, Spitfire and Hunter. I will of course move the subsystem config to system config so that they don't get broken. but David Culp was the originator: his view might differ. You may wish to seek his approval before going ahead with this change. On Wednesday 08 September 2004 01:11, David Culp wrote: David Culp, is it ok if I modify the new submodel so that it can be configured in the systems.xml file along with the rest of the systems? Or do you have another plan for this? Sounds OK to me. Dave I'm not that an experienced programmer, so I am wondering if the vector of submodels approach has superior preformace compared to my approach. Having dwelt on this overnight, I think that there are advantages to the vector approach. It is more or less consistent with the electrical system. I briefly suggested separating the various sub-types of submodel during development, but Erik advised against IIRC. On the other hand, it would be nice to place the serviceability property where it more properly belongs: with each sub-sub-model. Unless there is a pressing need to change, or there are definite advantages, I would suggest that we leave things as they are for now. If we all agree, I'll look at moving the serviceability property once I have completed the Seafire (nearly there). V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
Vivian Meazza wrote: Vegard Ovesen wrote: Sent: 18 October 2004 09:26 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Submodels On Monday 18 October 2004 00:24, Vivian Meazza wrote: The ability to set a serviceability state for each submodel system would seem to be the correct approach, but if I understand your proposal correctly, it will end up in more files overall. Actually the systems and instrumentation configuration files are already in CVS. So my point of view is that integrating the submodels configuration into the already existing systems configuration file would result in fewer files. It seems to me that your point of view is that adding systems and instrumentation configuration files would result in more config files. Which of course is true, but as I said systems and instrumentation config is already there (and the won't go away ;-)). As a major user and part-author of the submodel system, I have no objections, A quick grep through the base package revealed that three aircraft use the subsystem: F16, Spitfire and Hunter. I will of course move the subsystem config to system config so that they don't get broken. but David Culp was the originator: his view might differ. You may wish to seek his approval before going ahead with this change. On Wednesday 08 September 2004 01:11, David Culp wrote: David Culp, is it ok if I modify the new submodel so that it can be configured in the systems.xml file along with the rest of the systems? Or do you have another plan for this? Sounds OK to me. Dave I'm not that an experienced programmer, so I am wondering if the vector of submodels approach has superior preformace compared to my approach. Having dwelt on this overnight, I think that there are advantages to the vector approach. It is more or less consistent with the electrical system. I briefly suggested separating the various sub-types of submodel during development, but Erik advised against IIRC. On the other hand, it would be nice to place the serviceability property where it more properly belongs: with each sub-sub-model. Unless there is a pressing need to change, or there are definite advantages, I would suggest that we leave things as they are for now. If we all agree, I'll look at moving the serviceability property once I have completed the Seafire (nearly there). Roy, Dave, Vivian, Erik One thing that is not clear to me, is what happens with the submodel stuff in a multi-display environment? Is there any facility for replicating and syncing these objects across multiple visual channels? Thanks, 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] Submodels
Curtis L. Olson wrote: Roy, Dave, Vivian, Erik One thing that is not clear to me, is what happens with the submodel stuff in a multi-display environment? Is there any facility for replicating and syncing these objects across multiple visual channels? Not yet, but I haven't forgotten about it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
Curt asked: Sent: 18 October 2004 15:47 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Submodels Vivian Meazza wrote: Vegard Ovesen wrote: Sent: 18 October 2004 09:26 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Submodels On Monday 18 October 2004 00:24, Vivian Meazza wrote: The ability to set a serviceability state for each submodel system would seem to be the correct approach, but if I understand your proposal correctly, it will end up in more files overall. Actually the systems and instrumentation configuration files are already in CVS. So my point of view is that integrating the submodels configuration into the already existing systems configuration file would result in fewer files. It seems to me that your point of view is that adding systems and instrumentation configuration files would result in more config files. Which of course is true, but as I said systems and instrumentation config is already there (and the won't go away ;-)). As a major user and part-author of the submodel system, I have no objections, A quick grep through the base package revealed that three aircraft use the subsystem: F16, Spitfire and Hunter. I will of course move the subsystem config to system config so that they don't get broken. but David Culp was the originator: his view might differ. You may wish to seek his approval before going ahead with this change. On Wednesday 08 September 2004 01:11, David Culp wrote: David Culp, is it ok if I modify the new submodel so that it can be configured in the systems.xml file along with the rest of the systems? Or do you have another plan for this? Sounds OK to me. Dave I'm not that an experienced programmer, so I am wondering if the vector of submodels approach has superior preformace compared to my approach. Having dwelt on this overnight, I think that there are advantages to the vector approach. It is more or less consistent with the electrical system. I briefly suggested separating the various sub-types of submodel during development, but Erik advised against IIRC. On the other hand, it would be nice to place the serviceability property where it more properly belongs: with each sub-sub-model. Unless there is a pressing need to change, or there are definite advantages, I would suggest that we leave things as they are for now. If we all agree, I'll look at moving the serviceability property once I have completed the Seafire (nearly there). Roy, Dave, Vivian, Erik One thing that is not clear to me, is what happens with the submodel stuff in a multi-display environment? Is there any facility for replicating and syncing these objects across multiple visual channels? They are AI objects, so as far as those are handled across multiple visual channels, so are submodels. But that begs the question ... perhaps Erik can help here? Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
Roy Vegard Ovesen wrote: Sent: 18 October 2004 09:26 To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Submodels On Monday 18 October 2004 00:24, Vivian Meazza wrote: The ability to set a serviceability state for each submodel system would seem to be the correct approach, but if I understand your proposal correctly, it will end up in more files overall. Actually the systems and instrumentation configuration files are already in CVS. So my point of view is that integrating the submodels configuration into the already existing systems configuration file would result in fewer files. It seems to me that your point of view is that adding systems and instrumentation configuration files would result in more config files. Which of course is true, but as I said systems and instrumentation config is already there (and the won't go away ;-)). OK, I've just updated cvs, and the inputs to some of my 3d instruments are now broken in the Hunter, Seahawk and Spitfire. How do I get them back? V. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Tuesday 19 October 2004 00:10, Vivian Meazza wrote: OK, I've just updated cvs, and the inputs to some of my 3d instruments are now broken in the Hunter, Seahawk and Spitfire. How do I get them back? What instruments are not working, and what inputs do they use? I just tried the Hunter, and I noticed that some of the instrumentation properties where not as expected. They are all ok in the c172. I will look into this. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Tuesday 19 October 2004 01:00, Roy Vegard Ovesen wrote: On Tuesday 19 October 2004 00:10, Vivian Meazza wrote: OK, I've just updated cvs, and the inputs to some of my 3d instruments are now broken in the Hunter, Seahawk and Spitfire. How do I get them back? What instruments are not working, and what inputs do they use? I just tried the Hunter, and I noticed that some of the instrumentation properties where not as expected. They are all ok in the c172. I will look into this. I see that for the Hunter and the Seahawk the vacuum system is not working which leads to the attitude-indicator and the heading-indicator also not working. This is because the engines/engine[0]/rpm property is undefined for the engine on these aircraft. I would guess that this was also the case before systems and instrumentation became configureable. Back then the vacuum system was hardcoded to be driven by engines/engine[0]/rpm. Now that the vacuum system is configurable you might consider driving it with another property from engines/engine[0]/, so that you can use the instrumentation/attitude-indicator and instrumentation/heading-indicator insted of orientation/*. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
Roy Vegard Ovesen wrote: Sent: 17 October 2004 20:19 To: FlightGear developers discussions Subject: [Flightgear-devel] Submodels Hi all! I've not touched the new submodel.*xx sources yet because I want your opinion on how I should implement it into the other configurable systems. The existing configurable systems are the pitot, static, and vacuum systems. These are configured in one configuration file defaulting to Aircraft/Generic/generic-systems.xml. I would like to include the configuration of submodels in this file also, since submodels might be classified as systems. The submodel is coded somewhat differently from the other systems (pitot, static and vacuum). The submodel class uses a vector of submodels to create several submodels. The other systems only have one system in it's class. The system manager (system_mgr.*xx) creates object instances of the system classes. So for the submodel one object instance is created and it contains all submodels, and for the others zero or more object instances are created. I am inclined to modify submodel.*xx to behave like the other systems, and to move the configuration of them from a separate file and into the systems configuration file. I can think of a few good reasons for doing this: * It makes sense to use the same philosophy for the systems. The instrumentation also uses this philosophy. * Fewer configuration files. * The submodels will become independent so you could for example make one not serviceable (jammed guns). If nobody has any objections I will of course go ahead and implement these changes as I have described. The ability to set a serviceability state for each submodel system would seem to be the correct approach, but if I understand your proposal correctly, it will end up in more files overall. As a major user and part-author of the submodel system, I have no objections, but David Culp was the originator: his view might differ. You may wish to seek his approval before going ahead with this change. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
