Re: [Flightgear-devel] FlightGear for PSP??
Cool Idea, and after that I'd love to have fgfs on my IPod, it's internal disk ist large enough for the entire scenery and there is a linux implementation for it, too (www.ipodlinux.org). I think the graphics is a little poor... > I have a wild idea I hope no one kills me for! Its christmas and PSP > prices are a little lower (i think). How hard would it be to put > Flightgear on a PSP. People are already doing homebrew games on > those, ofcourse, not with very complicated graphics. But it could be > possible could it not?? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ouput Flight Envelope Chart?
Dai Qiang wrote: > Hello, > > Is FGFS is able to output the flight envelope chart, > according to the specific information defined in FDM > files, by traversing the property tree? I think you would be better of with scripted runs of the standalone version of the FDM. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
回复： Re: [Flightgear-devel] Ouput Flight Envelope Chart?
Hi Erik, Thanks for the reply. Would you please explain your point more detailedly? I cannot follow you :) - Qiang --- Erik Hofman <[EMAIL PROTECTED]>写道: > Dai Qiang wrote: > > Hello, > > > > Is FGFS is able to output the flight envelope > chart, > > according to the specific information defined in > FDM > > files, by traversing the property tree? > > I think you would be better of with scripted runs of > the standalone > version of the FDM. > > Erik > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > __ 赶快注册雅虎超大容量免费邮箱? http://cn.mail.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: 回复： Re: [Flightgear-devel] Ouput F light Envelope Chart?
Dai Qiang wrote: > Hi Erik, > > Thanks for the reply. > Would you please explain your point more detailedly? Well, if the only thing you want is to plot the flight envelope then it would be overkill to use a full featured flightsimulator. So it might be better to only run the FDM and feed it with the control data you want (like speed settings and surface positions). Then you could let the FDM generate a log file containing just the properties you want to plot. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems in the latest CVS version
On Tuesday 15 November 2005 16:17, Vivian Meazza wrote: > Hunter starts with the brakes on by default. It works here with cvs as of > this morning. OK, I can confirm Dai's problem. Using GCC-4.0.2 (as standard on the latest Ubuntu) there are no initially apparent problems compiling or running today's CVS, but starting on the carrier the hunter immediately starts "slipping" back along the deck despite the brakes being on. Machine is an AMD64 running the latest 32bit Ubuntu distro. This apparently does not happen on a similar setup running the 64bit version of the same distro, although I can't personally confirm that. It doesn't happen on my own 32bit AthlonXP Gentoo box either (with an older GCC - 3.4.4). Hope that narrows down the likely culprit a bit for someone... Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
flightgear-devel@flightgear.org
I've tried today the c172r from today's CVS, and had this effect - the magnetos/electrical switches panel seems rendered OVER the yoke, no matter how the latter is rotated/pushed, the panel still gets drawn over it. http://www.tarunz.org/~vassilii/fg/Images/c172r-switches-over-yoke.jpg for a screenshot. I'd also like to note that the plane seems unrealistically tail-heavy -- just like the c150 model, it gets pushed on its tail with neutral controls and pretty light (11kt) winds. Even when empty, it doesn't happen in real life, but if you add inside even a 50kg pilot, it's going to be absolutely impossible. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New segfault [bug] activating mini-panels (2d)
This problem affects 2d panels. With 2d panels you can have multiple
panel versions and switch between them with the 's' key.
Very recently FG has started generating a segfault whenever you type 's'
to toggle to a minipanel.
This can be reproduced by starting FlightGear with --aircraft=c172p-2dpanel
Once FlightGear is up and running, type 's' to switch to the mini
panel. FlightGear will immediate crash. (This was working fine up
until a week or two ago.)
The backtrace I get is:
#0 0x08435d2d in SGSubsystemGroup::Member::update (this=0xde5f2d8,
delta_time_sec=0.32501) at subsystem_mgr.cxx:236
#1 0x08435f80 in SGSubsystemGroup::update (this=0x979db9c,
delta_time_sec=0.32501) at stl_vector.h:462
#2 0x08435e56 in SGSubsystemMgr::update (this=0x979db94,
delta_time_sec=0.32501) at subsystem_mgr.cxx:297
#3 0x08051df2 in fgMainLoop () at main.cxx:495
#4 0xb7fccd20 in glutMainLoop () from /usr/lib/libglut.so.3
#5 0x08054a88 in fgMainInit (argc=2, argv=0xbf8f5bc4) at main.cxx:1007
#6 0x08050e50 in main (argc=2, argv=0xbf8f5bc4) at bootstrap.cxx:193
This indicates the crash is in simgear/structure/subsystem_mgr.cxx, line
#236:
void
SGSubsystemGroup::Member::update (double delta_time_sec)
{
elapsed_sec += delta_time_sec;
if (elapsed_sec >= min_step_sec) {
if (!subsystem->is_suspended()) {
subsystem->update(elapsed_sec);
elapsed_sec = 0;
}
}
}
The specific line of the crash is when the system checks if the
subsystem->is_suspended().
Does anyone have any ideas what may have changed recently to cause this
crash? This is a feature I use and need, I'm not just nitpicking the
random segfaults I see in FG.
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
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New segfault [bug] activating mini-panels (2d)
I did some more digging and tracked down the offending subsystem. I
will contact the developer off line and hopefully this will be a simple fix.
Curt.
Curtis L. Olson wrote:
This problem affects 2d panels. With 2d panels you can have multiple
panel versions and switch between them with the 's' key.
Very recently FG has started generating a segfault whenever you type
's' to toggle to a minipanel.
This can be reproduced by starting FlightGear with
--aircraft=c172p-2dpanel
Once FlightGear is up and running, type 's' to switch to the mini
panel. FlightGear will immediate crash. (This was working fine up
until a week or two ago.)
The backtrace I get is:
#0 0x08435d2d in SGSubsystemGroup::Member::update (this=0xde5f2d8,
delta_time_sec=0.32501) at subsystem_mgr.cxx:236
#1 0x08435f80 in SGSubsystemGroup::update (this=0x979db9c,
delta_time_sec=0.32501) at stl_vector.h:462
#2 0x08435e56 in SGSubsystemMgr::update (this=0x979db94,
delta_time_sec=0.32501) at subsystem_mgr.cxx:297
#3 0x08051df2 in fgMainLoop () at main.cxx:495
#4 0xb7fccd20 in glutMainLoop () from /usr/lib/libglut.so.3
#5 0x08054a88 in fgMainInit (argc=2, argv=0xbf8f5bc4) at main.cxx:1007
#6 0x08050e50 in main (argc=2, argv=0xbf8f5bc4) at bootstrap.cxx:193
This indicates the crash is in simgear/structure/subsystem_mgr.cxx,
line #236:
void
SGSubsystemGroup::Member::update (double delta_time_sec)
{
elapsed_sec += delta_time_sec;
if (elapsed_sec >= min_step_sec) {
if (!subsystem->is_suspended()) {
subsystem->update(elapsed_sec);
elapsed_sec = 0;
}
}
}
The specific line of the crash is when the system checks if the
subsystem->is_suspended().
Does anyone have any ideas what may have changed recently to cause
this crash? This is a feature I use and need, I'm not just nitpicking
the random segfaults I see in FG.
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
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New segfault [bug] activating mini-panels (2d)
Curt wrote: > I did some more digging and tracked down the offending subsystem. I > will contact the developer off line and hopefully this will be a > simple fix. It's much more enlightening if you embarass them publically. Unless it's me, of course. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New segfault [bug] activating mini-panels (2d)
Andy Ross wrote: Curt wrote: I did some more digging and tracked down the offending subsystem. I will contact the developer off line and hopefully this will be a simple fix. It's much more enlightening if you embarass them publically. Unless it's me, of course. I'll give them my usual 30 minutes grace period. Then I'll bring down the hammer. You hear that Dave, you only have 15 minutes now! 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] Re: [PATCH] CH Pro Yoke USB XML patch
And now comes the attachment... Sorry.
Vassilii
Index: ../data/Input/Joysticks/CH/pro-yoke-usb.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/Input/Joysticks/CH/pro-yoke-usb.xml,v
retrieving revision 1.19
diff -u -p -r1.19 pro-yoke-usb.xml
--- ../data/Input/Joysticks/CH/pro-yoke-usb.xml 22 Jun 2005 13:08:02 -
1.19
+++ ../data/Input/Joysticks/CH/pro-yoke-usb.xml 14 Dec 2005 20:17:06 -
@@ -4,6 +4,33 @@
CH PRODUCTS CH FLIGHT SIM YOKE USB
CH FLIGHT SIM YOKE USB
+
+ true"
+ ~ "\nto your joysticks.xml (the buttons/collective
control will still work then!)\n");
+ }
+ }
+ ]]>
+
+
+
Aileron
@@ -110,7 +137,7 @@
property-adjust
/sim/current-view/goal-pitch-offset-deg
-2.0
+-2.0
@@ -118,29 +145,25 @@
property-adjust
/sim/current-view/goal-pitch-offset-deg
--2.0
+2.0
-Fire Starter on Selected Engine(s)
+ false
+ Scroll in reverse through views.
nasal
- controls.startEngine()
+ view.stepView(-1)
-
-
-nasal
-props.setAll("/controls/engines/engine", "starter", 0)
-
-
false
- view-cycle
+ nasal
+ view.stepView(1)
@@ -221,31 +244,46 @@
- true
-
-property-adjust
-/controls/engines/engine[0]/boost
-+0.01
-
+ Decrease field of view.
+ false
+
+ nasal
+ 0) { reset_view(); } else { view_mod = -1; }
+ ]]>
+
+
+
-property-adjust
-/controls/engines/engine[1]/boost
-+0.01
+nasal
+
+
- true
-
-property-adjust
-/controls/engines/engine[0]/boost
--0.01
-
+ Increase field of view.
+ false
+
+ nasal
+
+
+
+
-property-adjust
-/controls/engines/engine[1]/boost
--0.01
+nasal
+0) { view_mod -= 1;}
+]]>
+
+
Index: ../data/joysticks.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/joysticks.xml,v
retrieving revision 1.34
diff -u -p -r1.34 joysticks.xml
--- ../data/joysticks.xml 24 Nov 2005 13:04:31 - 1.34
+++ ../data/joysticks.xml 14 Dec 2005 20:17:59 -
@@ -20,6 +20,7 @@
-->
+ false
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] CH Pro Yoke USB XML patch
Following Melchior's suggestions of not disabling the axis0/1 as somebody might want to fly a rotorcraft with the yoke nevertheless, I have modified the patch. Here's what it does now: > 1) it's really difficult to fly a helicopter with the yoke, > but one can make good use of the throttle as the collective. > If one wants to fly and use the mouse as the cyclic control, > it's impossible unless the yoke doesn't send the axis0/1 position > as aileron/elevator control bindings. Thus, the patched file > checks at startup if the "/rotors" property exists (thanks to Melchior > for the tip on what to check!) and then ruthlessly removes > the bindings at runtime. ...if the /input/joysticks/disable-cyclic-yoke property is set to true. Otherwise, it prints a message on the NASAL's stdout: Forcing cyclic control with your yoke. Change by adding true to your joysticks.xml I've also included a patch to the joysticks.xml to provide the default false (current behaviour); note that if somebody doesn't have the property node at all, it'll work as well. (I initially thought of using the menu for doing this (and have it disabled unless /rotors are present), but then I realized how annoying this must be for somebody who disables (or enables - depending on the default) this thing on every startup, and thus understood this should be a 1-time preference thing). > 2) the view pitch change is reversed so that the hat movement > now corresponds to one's head (view) movement (tilting it forward means > tilting your head forward) About this one I think the important thing is to be consistent about all the joysticks. I wonder how other joysticks with the hat thing are mapped? > 3) remap of some buttons: > #0: instead of firing the starter, this one cycles the views in the > reverse direction I think this is pretty safe to do along my patch, because starter is a pretty much one-time thing, whereas the view change is really handy to do while flying w/o removing the hands off the yoke. > #1: this one uses the nasal view cycle wrapper instead of the old > view-cycle command, thus we get the tip popup with the new view name > #8/#9: these get to work as x/X on the keyboard, and pressing them > together gives the same as Ctrl-X on the keyboard. For this, > I removed the /controls/engines/engine[?]/boost control bound to them Here I really don't know what to do, and would be happy to hear David's and Erik's opinion first of all, as those having priority over mapping this hardware. (Actually, I'd love their and others' input on everything else in the patch as well, but here I am telling in advance that I am at a loss). The aircrafts affected are b29 (but it has 4 engines which are not selectable individually w/o the keyboard, and the current binding was broken anyway for b29 as it only moves the 1st 2 engines' boost!) dc3 p51d Hurricane Spitfire For all the other aircraft the buttons remained wasted anyway. It would be possible to create an ugly "if" to just remap around these 5 aircraft (or maybe if the boost control is present), or if the original authors don't object, just change the default to what the patch proposes. Safe flying, Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] CH Pro Yoke USB XML patch
* Vassilii Khachaturov -- Wednesday 14 December 2005 21:41: > And now comes the attachment... Sorry. 1) You didn't even try the patch. I didn't either, but I see that it can't work. Hint: xmllint :-} 2) Polluting joysticks.xml with driver specific stuff is a no-go. Drivers need to be self-contained, and must not spread their internals elsewhere. (You can check in the nasal init block if the property exists, and if so, which value it has.) m. PS: I still don't like the whole idea. :-> ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear for PSP??
I thougt PSP was "Put in Sharps Pile" (sorry for not being more helpful...I'm not sure the PSP has the power to run FG at a decent frame rate) Bruce Dave Culp wrote: On Tuesday 13 December 2005 03:00 pm, bass pumped wrote: ... How hard would it be to put Flightgear on a PSP. ... You know you're getting old when you have to google PSP to find out what it is. I always thought it was Pierced Steel Planking. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d begin:vcard fn:Bruce Benneke n:Benneke;Bruce org:Benneke Computers email;internet:[EMAIL PROTECTED] tel;work:1 (306) 542-2891 version:2.1 end:vcard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] CH Pro Yoke USB XML patch
> 1) You didn't even try the patch. I didn't either, but I see that >it can't work. Hint: xmllint :-} I don't know how you see that, because I picked it off working tree. I tested after that with the new property set to false, true, and absent. If you mean the markup in the print statement, it's harmless as it's wrapped with a CDATA block. > 2) Polluting joysticks.xml with driver specific stuff is a no-go. >Drivers need to be self-contained, and must not spread their >internals elsewhere. (You can check in the nasal init block >if the property exists, and if so, which value it has.) I don't think it is driver specific --- since there may be other yokes, not just CH Products' one. Also, even if you say it should be a per-driver thing, I didn't understand which property do you suggest to check instead. > PS: I still don't like the whole idea. :-> What is so wrong? Asking the developers if the button defaults I propose are more sensible, or the idea of disabling the cyclic control via the yoke so that the rotorcraft flying is more real? or the way via which the disablement is customized even in the revised version? Constructive criticism welcome. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] CH Pro Yoke USB XML patch
oh, I see what you mean -- the closing tag in the joystick.xml file. Strange thing I didn't caught it while testing... Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] CH Pro Yoke USB XML patch
> oh, I see what you mean -- the closing tag in the joystick.xml file. > Strange thing I didn't caught it while testing... > I know what happened. First, I tested it without the joystick.xml change and it worked (yoke controls the cyclic). Then I put the "true" in, and it worked (yoke control of cyclic disabled). Then I changed it to what you have seen, and it still was controlling the cyclic, yet in the very startup (which had scrolled off my screen) there was an XML parser warning (which didn't harm the rest of the startup). V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] CH Pro Yoke USB XML patch
* Vassilii Khachaturov -- Wednesday 14 December 2005 23:13: > > 1) You didn't even try the patch. I didn't either, but I see that > >it can't work. Hint: xmllint :-} > > I don't know how you see that, + false ^^^ m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New segfault [bug] activating mini-panels (2d)
"Curtis L. Olson" writes: > Andy Ross wrote: > > > > >It's much more enlightening if you embarass them publically. Unless > >it's me, of course. > > > > > > I'll give them my usual 30 minutes grace period. Then I'll bring down > the hammer. You hear that Dave, you only have 15 minutes now! > Thanks Curt ;-) I suspect that this is due to my sneaky multiple inheritance of the special instrument from both SGSubsystem and FGPanelInstrument - subsystems seem to be somewhat less robust than panel instruments to some of the shenanigans that can go on with the panel operations. I already know that Ctrl-C (panel reload) breaks when a panel includes the KLN89 - I suspect that the mini-panel woes (never tested since I completely forgot about it) are a variation on the same theme. As an immediate fix, simply comment out the section in the C172 2d panel xml file. You'll be left with the GPS background and buttons, but without the working text. I'll give some thought to a more robust fix - it's on my TODO list anyway since the Ctrl+C problem became apparent. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ouput Flight Envelope Chart?
Thanks, Erik. It sounds great to me. :) --- Erik Hofman <[EMAIL PROTECTED]>写道: > Dai Qiang wrote: > > Hi Erik, > > > > Thanks for the reply. > > Would you please explain your point more > detailedly? > > Well, if the only thing you want is to plot the > flight envelope then it > would be overkill to use a full featured > flightsimulator. So it might be > better to only run the FDM and feed it with the > control data you want > (like speed settings and surface positions). > Then you could let the FDM generate a log file > containing just the > properties you want to plot. > > Erik > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > __ 赶快注册雅虎超大容量免费邮箱? http://cn.mail.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
