Re: [Flightgear-devel] Re: Diamond Katana model
Worth a try ! Have you got any plans of the Katana ? Its very hard to find anything on the DA42 I emailed Diamond but had nothing back. Mat On Sun, 2005-07-17 at 22:46 -0400, [EMAIL PROTECTED] wrote: Hi, Mat, I'd love to get my hands on a twin turbo diesel with an all-glass panel, but right now the FAA thinks I should be flying an 80hp single. And my CFI thinks I should stay more to the middle of the runway when I touch down (never on the front wheel first), rather than tending to stay my usual ~15' to the left. Seriously, I have a pretty specific purpose in mind, here, since I really do need to find some way to remember the routine when flying the pattern and have to learn to stay on the centerline. I tried Flight Simulator 2k2, and found out quickly that it's a toy: the one Katana model I found feels NOTHING like the real thing. I've been watching the FG dev list for a while now and figured the models here would be closer, at least because the FDMs are being used in some reputable projects. Jon, I saw that you copied my original message into the JSBSim list before I had a chance to -- many thanks. -j -- Message: 9 Date: Sun, 17 Jul 2005 14:32:10 +0100 Subject: [Flightgear-devel] Re: Diamond Katana model To: flightgear-devel@flightgear.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain joe, sure you are not interested in a DA42 ? would love one of these in FG http://www.abacuspub.com/fsd/catalog/s609.htm Mat ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Diamond Katana model
joe, sure you are not interested in a DA42 ? would love one of these in FG http://www.abacuspub.com/fsd/catalog/s609.htm There was a project from diamond aircraft and microsoft about building a model for the Twin Star. http://www.diamond-air.at/de/press/pressarchive/50606.htm this page is in german, I don't think there is one in english. It - roughly - tells the story about both companies supporting two schools in austria in a building a model of the DA42 for FS2004. The files could be found here http://www.microsoft.com/austria/education/projekte.mspx It looks like they did a model for the DA40 180, too. I whish, they did this for fg... Torsten ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New super/turbo MP code is in
Peter Stickney On Friday 15 July 2005 06:45, Vivian Meazza wrote: Josh Babcock Vivian Meazza wrote: Josh Babcock ought to be asking for the turbo charger for the B29 now, but hasn't yet (perhaps he's now using JSBSim?). I've been unable to find much available on the web for the Wright R-3350. I'm doing some work on the aircraft carrier right now, but I've done some preparation for the turbo simulation. Nope, I've just been busy with animations and other non-fgfs stuff. I don't have much data on the R-3350-23, but I do have the pilot's manual and a lot of web sites. If someone is offering to help with the engines I would love it. I am available to give all the info I have. I don't really feel I know enough about engines to do this properly myself. If by 'someone' you mean me, then I guess I should help here. I need some thing to test my putative modifications to YASim on anyway. I need a few hard numbers, which perhaps you could give me or point me at a suitable web site/s: From a variety of sources, including the FAA Type Certificate Data Sheet E-218 (Wright Double Cyclone C18BA series) and the 1950 edition of Model Designations of USAF Aircraft Engines. 1. propeller gearing. 0.35:1 2. max manifold pressure. Now - that will depend on the specific rating. Exceeding the allowable boost for an RPM/Mixture combination is Very, Very Bad. (As in, as the P2V Manual puts it, Trouble is indicated by internal engine parts exiting teh exhaust stacks. 3. full throttle altitude which may also be described as the critical altitude. Military Power - 2200 HP/2800 RPM/ 44 Hg / SL-25,000' 15 Minute limit For the engine and turbosupercharger combination. Without the turbo - (Mechanical blower only), the ratings were: 2200 HP/2800 RPM/ 44 Hg /Sea Level 2200 HP/2800 RPM/ 42 Hg / 7,000'. Note the decrease in MAP as altitude increses. Wright Engines from teh late 1930s on were rated to a constant power, not a constnat Manifold Pressure. As altitude increased, Temperature and Back Pressure (Not relevant for the turbo) decreased, giving more power for a given MAP. MAP was decreased to hold constant power. 4. the rated HP and the rated altitude. Normal Power - 2000 HP/2400R RPM/ 42 Hg/ SL-25,000' Continuous (Turbo) 2000 HP/2400 RPM/42 Hg/ Sea Level 2000 HP/2400 ROM/41 Hg/ 4200' on the Mechanical blower only. 5. take-off HP. 2200 HP/2800 RPM / 44 Hg 6. Copies of the relevant pages of the Pilot's Manual. Post these somewhere that I can access/fetch. Particularly any description of the variable boost control. That was the FE's job. The supercharger system of a B-29, or any other turbosupercharged airplane worked like this: (Well, was supposed to work like this - Early B-17s and B-24s with the mechanical oil pressure driven turboregulators required more fiddling, but the electronic turboregulators used on later -17s, 24s, P-38s, P-47s, B-29s and subsequent airplanes did work like this) There was a potentiometer dial on the turboregulator control box that was calibrated from 0 to 10. This selected the amount of output. from the turbo system as a whole, 0 being no output. The turbos supplied air to the inlet of the engine's mechanical supercharger at slightly over sea level ambient (29.92 on a Standard Day). This was done to keep the turbo moving, so that it didn't freeze up due to poor lubrication at Sea Level. The engine's throttle was set to provide whatever power conditions were required, and as the airplane climbed, the tubo's Volume Control was tweaked to keep providing its sea level conditions to the engine's supercharger. The Turboregulator governed on the selected pressure rise (The Volume and turbo RPM and, often, bearing temperature. The Pilot of Flight Engineer had no indication, or control over the turbo except the potentiometer. As far as the engine was concerned, it was sitting happily at Sea Level the whole time. Once it had reached the point where the turbosupercharger/mechanical blow couldn't supply the proper power conditions any more, power dropped off normally. I don't know, but it sound like you could be making things a bit more complicated than they were. The Turbos were basically Black Boxes. There wasn't anything more to do with them but set them to the appropriate pressure rise let them go. Very helpful. I think you will find that the turbo pressure was controlled by the pilot, at least at critical point of the flight. While the pilot can regard the turbo as a black box, we need to know a little more about it so that the FDM can be set up correctly. This is the first reference that I have seen to a turbo/mechanical blower combination. I would be interested in seeing your source. This is for the R-3350-23? Thanks Vivian ___ Flightgear-devel mailing list
RE: [Flightgear-devel] New super/turbo MP code is in
Peter Stickney ... snip ... An addition/correction to my previous posting. Once it had reached the point where the turbosupercharger/mechanical blow couldn't supply the proper power conditions any more, power dropped off normally. Yes. That's known as the full throttle altitude or the critical altitude, and is important in setting up the FDM. As it turns out, the B-29's turboregulator control was a little bit different from what I described. The Volume Control governed off total system MAP. If you set the potentiometer to , say, '*8, it maintained the overall MAP until the turbo reached its limits. So, for example, you set the engines to Max Continuous, you wouldn't need to twiddle the turbos as you climbed from Sea Level to 25,000'+. Sorry if I cased some confusion, there. OK, all is clear. Zeno's Warbirds has, IIRC, a Realplayer movie on flying the B-29. That's a pretty good resource. An _excellent_ resource. Thanks for pointing us to it. Didn't show up on my Google search for B29. Odd for such a good site. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New super/turbo MP code is in
Josh Babcock As it turns out, the B-29's turboregulator control was a little bit different from what I described. The Volume Control governed off total system MAP. If you set the potentiometer to , say, '*8, it maintained the overall MAP until the turbo reached its limits. So, for example, you set the engines to Max Continuous, you wouldn't need to twiddle the turbos as you climbed from Sea Level to 25,000'+. Sorry if I cased some confusion, there. Zeno's Warbirds has, IIRC, a Realplayer movie on flying the B-29. That's a pretty good resource. True, though for some reason I have not checked it out. I do have the .ram file that points to the stream though. Also, note that to go past 8 on the turbo dial required opening a safety latch and per the pilot's handbook was not to be done for more than 2 min. which I think is the equivalent of the RAF WEP. I'm not sure what bearing this has on the engine modeling but at some point I should put in a nasal script to blow up the turbos after some extended period at settings above 8. I'll have to figure out what conditions would actually cause a failure though. Thanks to Peter's input, I think that: a. I now understand the operation of the turbo regulator b. Have the numbers to proceed. If we assume the critical altitude to be 25,000 ft with the boost at 0.8 (#8 on the dial), everything should fall into place. WEP (or combat power) should fall naturally out of this calculation. Failure - don't worry about the conditions :-). After about 5 mins or so, according to OAT, the rear row of the cylinders would overheat, leading to an engine fire which burnt through the firewall, causing catastrophic failure of the wing main spar. Should be easy enough to model! Apparently, this was not really cured until the up-engined version which was the B50. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Patch for fgjs.cxx and jsinput.[h,cxx]
Hello,
find attached a patch for fgjs.cxx and jsinput.[h,cxx] (current CVS).
The changes are:
- automatic detection of axis directionality, so that axis inputs are
appropriately inverted only when necessary
- fixed trim axis names for better understandability
- fixed signs for flaps up/down property increments
- button 0 was previously used for skipping axes and buttons in both
loops. Now button 0 can be assigned a binding (e.g., brakes). Instead,
moving any axis during the button-assignment-loop indicates skipping.
- The user is now told how to skip a control.
I have tested it with a Logitech WingMan Force 3D, but I don't see any
reason why it should not work for other sticks ;-)
Regards,
Ralf
Index: src/Input/fgjs.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Input/fgjs.cxx,v
retrieving revision 1.7
diff -u -r1.7 fgjs.cxx
--- src/Input/fgjs.cxx 25 Jun 2005 07:57:42 - 1.7
+++ src/Input/fgjs.cxx 18 Jul 2005 10:19:41 -
@@ -50,15 +50,18 @@
/sim/current-view/goal-pitch-offset-deg
};
+string axis_posdir[8]= { right, down/forward, right, forward,
forward, forward, left, upward };
+
+
bool half_range[8]={ false,false,false,true,true,true,false,false };
bool repeatable[8]={ false,false,false,false,false,false,true,true };
-bool invert[8]= { false,true,false,false,false,false,false,true };
+bool invert[8]= { false,false,false,false,false,false,false,false };
string button_humannames[8]= { Left Brake, Right Brake,
Flaps Up, Flaps Down,
- Elevator Trim Up, Elevator Trim Down,
+ Elevator Trim Forward, Elevator Trim
Backward,
Landing Gear Up, Landing Gear Down
};
@@ -76,7 +79,7 @@
bool button_boolean[8]={ false,false,false,false,false,false,true,true };
-float button_step[8]={ 1.0, 1.0, 0.34, -0.34, 0.001, -0.001, 0.0, 1.0 };
+float button_step[8]={ 1.0, 1.0, -0.34, 0.34, 0.001, -0.001, 0.0, 1.0 };
string button_repeat[8]={ false, false, false, false, true, true,
false, false };
@@ -379,7 +382,8 @@
for(control=0;control=7;control++) {
cout Move the control you wish to use for
axes_humannames[control]
-endl;
+ axis_posdir[control] endl;
+ cout Pressing a button skips this axis\n;
fflush( stdout );
jsi-getInput();
@@ -397,6 +401,7 @@
if (strcmp(answer,n)==0) {
control--;
} else {
+ invert[control]=!jsi-getInputAxisPositive();
if (usexml) {
writeAxisXML( xfs[jsi-getInputJoystick()], control,
jsi-getInputAxis() );
} else {
@@ -424,6 +429,7 @@
} else {
cout Press the button you wish to use for
button_humannames[control] endl;
}
+ cout Moving a joystick axis skips this button\n;
fflush( stdout );
jsi-getInput();
if(jsi-getInputButton() != -1) {
Index: src/Input/jsinput.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Input/jsinput.cxx,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 jsinput.cxx
--- src/Input/jsinput.cxx 10 Sep 2002 01:14:08 - 1.1.1.1
+++ src/Input/jsinput.cxx 18 Jul 2005 10:19:41 -
@@ -29,7 +29,7 @@
jsInput::~jsInput(void) {}
-int jsInput::getInput(void){
+int jsInput::getInput(){
bool gotit=false;
@@ -37,6 +37,7 @@
int i, current_button = 0, button_bits = 0;
joystick=axis=button=-1;
+ axis_positive=false;
if(pretty_display) {
printf ( +--\n ) ;
@@ -79,6 +80,7 @@
gotit=true;
joystick=jss-getCurrentJoystickId();
axis=i;
+ axis_positive=(delta0);
} else if( current_button != 0 ) {
gotit=true;
joystick=jss-getCurrentJoystickId();
@@ -102,7 +104,7 @@
ulMilliSecondSleep(1);
}
if(button_bits != 0) {
-for(int i=1;i=31;i++) {
+for(int i=0;i=31;i++) {
if( ( button_bits (1 i) ) 0 ) {
button=i;
break;
Index: src/Input/jsinput.h
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Input/jsinput.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 jsinput.h
--- src/Input/jsinput.h 10 Sep 2002 01:14:08 - 1.1.1.1
+++ src/Input/jsinput.h 18 Jul 2005 10:19:41 -
@@ -34,6 +34,7 @@
int button_iv[MAX_JOYSTICKS];
int joystick,axis,button;
+bool axis_positive;
float axis_threshold;
@@ -48,6 +49,7 @@
inline int getInputJoystick(void) { return joystick; }
inline int getInputAxis(void) {
Re: [Flightgear-devel] asymetric frustum
Hi Curt, I am one week late but here are the pics that I hope will help you to help me ;-) http://paxettepaxou.free.fr/fg/horizontal_fov.JPG [17 Ko] http://paxettepaxou.free.fr/fg/vertical_fov.JPG [19 Ko] http://paxettepaxou.free.fr/fg/horizontal_fov_front.JPG [17 Ko] http://paxettepaxou.free.fr/fg/vertical_view_front.JPG [14 Ko] http://paxettepaxou.free.fr/fg/horizontal_fov_side.JPG [19 Ko] http://paxettepaxou.free.fr/fg/vertical_fov_side.JPG [15 Ko] As I told you in my last mail, I have a cylindrical projection and the point of view is not centered in the cylinder. I have three asymetric frustums (vertically and horizontally asymetric). I really hope it will help you to help me. Thanks David That's the basic idea. You specify a larger virtual screen that has a symmetric frustum and then each display get's assigned a portion of the larger display. I realize this is probably not an industry standard way to do it, and this approach probably can't cover every possible screen configuration, but I needed something quick a few months ago, and this approach meshed pretty well with the existing code. I shold point out that there is some subtle wierdness depending on the size of your display so for example, let's say you have 5 forward displays. The center 3 are all parallel so they need to act as a single larger fov display. If you want to assign 30 degrees field of view to each of them, you would naturally pick a 90 degree field of view for the center 3 and give each display 1/3 of that. However, you can't just give the 2 edge displays an symmetric 30 degrees and have them match up. There is some subtle aspect ratio stuff going on there that causes problems. So what you'd need to do is setup the side channels as a 90 degree fov virtual display and give them 1/3rd of that, then they should match up with the center channels. At some point it would probably make sense to clean up the view pipeline to handle this better, but time and priorities are always the big problem. Regards, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: dynamically modifiable ASCII protocol separators
Michael Meyers wrote: Meanwhile, it might be a good idea to simply optionally include the code using #ifdefs - that way, the current code could remain in place/active and the new code would only be used if a corresponding #define is set, by those users who actually require it or want to use it. While I like the idea of having a binary generic IO protocol I won't include this patch anyhow since it is messing up the file pretty badly. It would be nice if you would follow the code style as it is already present in the file. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Ampere K. Hardraade wrote: I think it will be more flexible if the networking portion of FlightGear can be modified to exchange properties. For starter, the nodes /accelerations, /positions, and /surface-positions can be exchanged among users. Properties under /accelerations can allow one client to interpolate the position of others, thus eliminating jitters. I got started on something like this a few months back. Maybe I should work harder on it now that there is clearly demand for such a thing. It sent the position/orientation and 1st and 2nd derivatives as part of the position packet, and not as properties. Note that this isn't enough: another really important feature is proper time synchronization between the clients (not wall clock time, necessarily, but time of data validity). Otherwise network latency will cause skew, where different clients see different aircraft in different positions. This makes things like formation flight and dogfighting difficult. The other feature that sounded cool was automatically detecting the needed properties for animation from the aircraft model file during parsing. It requires some way of limiting the number of panel properties that are sent (I was thinking about doing it via the size of the animated object's bounding box), but should be pretty robust in practice. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Ampere K. Hardraade wrote: How about creating root-less nodes to act as seperated property trees for these aircrafts? This way, it will be easier to fool the animation files of these aircrafts into taking the proper values. Yes, exactly. They don't need to be rootless, just detached from the normal property scheme. Under /multipler/callsign/... for instance. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Could you give some examples ? The noshadow thing is usualy used to hide some artifacts caused by transparent geometry like windows, rotating propeler disk, paintings, etc, or to reduce the complexity of the shadow (virtual cockpit or other complex parts of the plane). Harald. Hello Harald, You could be interested on what i am doing about shadow animation in the coming condition shadow. == An aircraft don't cast shadow when agl-ft 450. animation condition greater-than property/position/altitude-agl-ft/property value450/value /greater-than /condition typenoshadow/type object-nameLysander/object-name /animation == Blend on an helicopter main rotor and rotor disc working correctly :we deactivate cast of shadow from rotor when rotor rpm100 (it must be tuned) animation condition greater-than propertyrotors/main/rpm/property value100/value /greater-than /condition typenoshadow/type object-nameRotor-Princ/object-name /animation == some moving Aircraft components could cast shadow according to their positions on the Aircraft. That is an exemple on a Naval aircraft the hook will cast shadow only when it is not fully retracted. animation condition equal propertygear/tailhook/position-norm/property value0/value /equal /condition typenoshadow/type object-nameHook/object-name /animation BTW: I discovered that many aircrafts have gear components or float components (seaplane) which are not hidden when retracted (no door). They only have to cast shadow when extended. Regards -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
Andy Ross wrote: Ampere K. Hardraade wrote: How about creating root-less nodes to act as seperated property trees for these aircrafts? This way, it will be easier to fool the animation files of these aircrafts into taking the proper values. Yes, exactly. They don't need to be rootless, just detached from the normal property scheme. Under /multipler/callsign/... for instance. Just like the AIModel objects ... Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Ampere K. Hardraade wrote: I just noticed that when one is inside an object, or the shadow volume of an object, then the shadow casted by that object is not visible. Here is an example: http://www.students.yorku.ca/~ampere/fgfs-screen-010.jpg Ampere It is because the viewer is inside a shadow volume, this breaks the so called zpass rendering. The solution to that is to use the zfail rendering for the concerned shadow volume. It's easy. What is not is to detect this situation in some efficient way and since the zfail rendering is a lot slower than the zpass we don't want to render too many volumes with zfail. It's on my todo list. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] asymetric frustum
BONNEVILLE David wrote: Hi Curt, I am one week late but here are the pics that I hope will help you to help me ;-) http://paxettepaxou.free.fr/fg/horizontal_fov.JPG [17 Ko] http://paxettepaxou.free.fr/fg/vertical_fov.JPG [19 Ko] http://paxettepaxou.free.fr/fg/horizontal_fov_front.JPG [17 Ko] http://paxettepaxou.free.fr/fg/vertical_view_front.JPG [14 Ko] http://paxettepaxou.free.fr/fg/horizontal_fov_side.JPG [19 Ko] http://paxettepaxou.free.fr/fg/vertical_fov_side.JPG [15 Ko] As I told you in my last mail, I have a cylindrical projection and the point of view is not centered in the cylinder. I have three asymetric frustums (vertically and horizontally asymetric). I really hope it will help you to help me. Hi David, I'm not sure I can give you the easy answer you are hoping for. Right now the FG code really isn't setup to do the arbitrary assymetric view frustums that you need. I think it would be doable with a few days work, but I would need to also come to a better understanding of the glFrustum parameters (which are still a bit of a mystery to me.) I'm really swamped with projects right now and don't have a lot of extra volunteer time to give. But if you are doing this as part of an Oktal project, perhaps we could discuss my consulting rates off line. :-) Here's one more thing to keep in mind. If you are projecting onto a cylindrical surface, FlightGear cannot prewarp the display to compensate for the curved surface. If you are doing edge blending you will have a big problem because your overlapping regions won't match. You will find that without (correctly) prewarping the displays everything will be distorted on the screen. Even if you can get the edges to match up, things will still be distorted. For instance, your horizon line will most likly droop in the center of the display and be higher at the joints ... kind of like a wire suspended by several pole's. I suspect you probably know all these things and have projectors that can do proper warping and edge blending, but if not, be aware that this will cause you huge problems if you don't account for the warping introduced by projecting onto a curved screen. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re:Overhaulling the networking code
We really need to look at an the best way of doing this. Once the multiplayer code is changed we will probably be stuck with is for the next few years. Getting it right is fairly important. We shoud consider what we want in terms of features, flexibility and numbers and then find the most efficient way of achieving it. While recycling code might be easier, remaking all of the code is a lot less restrictive. Both have pros and both have cons, it is would be nice if we could find the most beneficial way of doing it. Cheers, Mostyn Hi, this is a very good idea IMO. I was thinking about a very similar approach but never had the time and not yet the actual need to follow that. If you do something like that, you might take care for the MATHWORKS guys which use the network code like it is at the moment. So one will need probably some compatibility mode here. Greetings Mathias On Freitag 15 Juli 2005 23:34, Ampere K. Hardraade wrote: I think it will be more flexible if the networking portion of FlightGear can be modified to exchange properties. For starter, the nodes /accelerations, /positions, and /surface-positions can be exchanged among users. Properties under /accelerations can allow one client to interpolate the position of others, thus eliminating jitters. Properties under /position are basically what being exchanged right now. As to /surface-positions, the properties inside this node can allow one to see the animations of others correctly. To make this even more flexible, one can include a XML file under each aircraft's folder to specify what nodes/properties should be exchanged during online sessions. To cut down the amount of data being sent/received, a client only have to broadcast the above nodes once, and resend individual properties when needed. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Le lundi 18 juillet 2005 à 19:17 +0200, Harald JOHNSEN a écrit : Gerard Robin wrote: == some moving Aircraft components could cast shadow according to their positions on the Aircraft. That is an exemple on a Naval aircraft the hook will cast shadow only when it is not fully retracted. I am not sure I understand this example, or perhaps I presume that what is visible should cast shadows ;p Anyway the condition is available now. The old form without condition still exists. I have also made a few changes for tranparent objects. In the rendering dialog there is a new option near the aircraft checkbox. When enabled the rendering of the aricraft transparent parts is done *after* the shadowing code. In other words the transparent parts won't hide shadows as it should be. This is how things should be and this option should be enabled by default. But. We can agree that a window or a propeler disk is transparent but for the code a transparent part is a part that uses a transparent material, ie an alpha channel in his material or in his texture. In practice you will see that the new option will break shadows on a lot of aircrafts. Just don't use rgba textures where rgb would do the same ;) Harald. About the last exemple the hook retracted stay along, outside, close to fuse. Casting shadow in that position is not useful (I found the same with B-17F gears components) when we extend the hook it clearly appears and its own shadow could be nice to activate. Everything in order to spare CPU. I will try now your updates Many thanks. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin wrote: == some moving Aircraft components could cast shadow according to their positions on the Aircraft. That is an exemple on a Naval aircraft the hook will cast shadow only when it is not fully retracted. I am not sure I understand this example, or perhaps I presume that what is visible should cast shadows ;p Anyway the condition is available now. The old form without condition still exists. I have also made a few changes for tranparent objects. In the rendering dialog there is a new option near the aircraft checkbox. When enabled the rendering of the aricraft transparent parts is done *after* the shadowing code. In other words the transparent parts won't hide shadows as it should be. This is how things should be and this option should be enabled by default. But. We can agree that a window or a propeler disk is transparent but for the code a transparent part is a part that uses a transparent material, ie an alpha channel in his material or in his texture. In practice you will see that the new option will break shadows on a lot of aircrafts. Just don't use rgba textures where rgb would do the same ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New super/turbo MP code is in
Vivian Meazza wrote: Peter Stickney On Friday 15 July 2005 06:45, Vivian Meazza wrote: Josh Babcock Vivian Meazza wrote: Josh Babcock ought to be asking for the turbo charger for the B29 now, but hasn't yet (perhaps he's now using JSBSim?). I've been unable to find much available on the web for the Wright R-3350. I'm doing some work on the aircraft carrier right now, but I've done some preparation for the turbo simulation. Nope, I've just been busy with animations and other non-fgfs stuff. I don't have much data on the R-3350-23, but I do have the pilot's manual and a lot of web sites. If someone is offering to help with the engines I would love it. I am available to give all the info I have. I don't really feel I know enough about engines to do this properly myself. If by 'someone' you mean me, then I guess I should help here. I need some thing to test my putative modifications to YASim on anyway. I need a few hard numbers, which perhaps you could give me or point me at a suitable web site/s: From a variety of sources, including the FAA Type Certificate Data Sheet E-218 (Wright Double Cyclone C18BA series) and the 1950 edition of Model Designations of USAF Aircraft Engines. 1. propeller gearing. 0.35:1 2. max manifold pressure. Now - that will depend on the specific rating. Exceeding the allowable boost for an RPM/Mixture combination is Very, Very Bad. (As in, as the P2V Manual puts it, Trouble is indicated by internal engine parts exiting teh exhaust stacks. 3. full throttle altitude which may also be described as the critical altitude. Military Power - 2200 HP/2800 RPM/ 44 Hg / SL-25,000' 15 Minute limit For the engine and turbosupercharger combination. Without the turbo - (Mechanical blower only), the ratings were: 2200 HP/2800 RPM/ 44 Hg /Sea Level 2200 HP/2800 RPM/ 42 Hg / 7,000'. Note the decrease in MAP as altitude increses. Wright Engines from teh late 1930s on were rated to a constant power, not a constnat Manifold Pressure. As altitude increased, Temperature and Back Pressure (Not relevant for the turbo) decreased, giving more power for a given MAP. MAP was decreased to hold constant power. 4. the rated HP and the rated altitude. Normal Power - 2000 HP/2400R RPM/ 42 Hg/ SL-25,000' Continuous (Turbo) 2000 HP/2400 RPM/42 Hg/ Sea Level 2000 HP/2400 ROM/41 Hg/ 4200' on the Mechanical blower only. 5. take-off HP. 2200 HP/2800 RPM / 44 Hg 6. Copies of the relevant pages of the Pilot's Manual. Post these somewhere that I can access/fetch. Particularly any description of the variable boost control. That was the FE's job. The supercharger system of a B-29, or any other turbosupercharged airplane worked like this: (Well, was supposed to work like this - Early B-17s and B-24s with the mechanical oil pressure driven turboregulators required more fiddling, but the electronic turboregulators used on later -17s, 24s, P-38s, P-47s, B-29s and subsequent airplanes did work like this) There was a potentiometer dial on the turboregulator control box that was calibrated from 0 to 10. This selected the amount of output. from the turbo system as a whole, 0 being no output. The turbos supplied air to the inlet of the engine's mechanical supercharger at slightly over sea level ambient (29.92 on a Standard Day). This was done to keep the turbo moving, so that it didn't freeze up due to poor lubrication at Sea Level. The engine's throttle was set to provide whatever power conditions were required, and as the airplane climbed, the tubo's Volume Control was tweaked to keep providing its sea level conditions to the engine's supercharger. The Turboregulator governed on the selected pressure rise (The Volume and turbo RPM and, often, bearing temperature. The Pilot of Flight Engineer had no indication, or control over the turbo except the potentiometer. As far as the engine was concerned, it was sitting happily at Sea Level the whole time. Once it had reached the point where the turbosupercharger/mechanical blow couldn't supply the proper power conditions any more, power dropped off normally. I don't know, but it sound like you could be making things a bit more complicated than they were. The Turbos were basically Black Boxes. There wasn't anything more to do with them but set them to the appropriate pressure rise let them go. Very helpful. I think you will find that the turbo pressure was controlled by the pilot, at least at critical point of the flight. While the pilot can regard the turbo as a black box, we need to know a little more about it so that the FDM can be set up correctly. This is the first reference that I have seen to a turbo/mechanical blower combination. I would be interested in seeing your source. This is for the R-3350-23? Thanks Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org
RE: [Flightgear-devel] New super/turbo MP code is in
All the 3350s had this turbo/super setup. You can see it in some of these images: http://www.enginehistory.org/GjJBrossett/RAFCosford/Wright%20Cyclone%20R-3350%20cutaway.J PG http://www.enginehistory.org/GjJBrossett/RAFCosford/Wright%20Cyclone%20R-3350%20cutaway%2 0view.JPG http://www.saunalahti.fi/sariri/Img/UKRAFC05/Eng/slides/P2060078.html http://www.midwaysailor.com/eddiemiller/eddiemiller-761b.jpg ** Please ** trim your quotes. Also, for sending emails in text mode that include long links, you might try going to www.tinyurl.com and making shorter links to include in emails. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
We can agree that a window or a propeler disk is transparent but for the code a transparent part is a part that uses a transparent material, ie an alpha channel in his material or in his texture. In practice you will see that the new option will break shadows on a lot of aircrafts. Just don't use rgba textures where rgb would do the same ;) Harald. About the last exemple the hook retracted stay along, outside, close to fuse. Casting shadow in that position is not useful (I found the same with B-17F gears components) when we extend the hook it clearly appears and its own shadow could be nice to activate. Everything in order to spare CPU. I will try now your updates Many thanks. Hello Harald, Everything is working. The results are very nice. Your idea to introduce transparency is perfect that solve the ugly effects on propdisk and the hidden effect on shadows. Thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New super/turbo MP code is in
On Monday 18 July 2005 18:25, Josh Babcock wrote: All the 3350s had this turbo/super setup. You can see it in some of these images: URL's snipped No, actually, those are the turbocompounded TC18s used on later Lockheed Constellations, DC-7s, Most P-2 Neptunes, and most C-119s. The turbines that you see in the back are geared directly (Well, though a shock-dampening clutch) to the crankshaft, and contribute directly to the shaft horsepower available. There were 3 turbines, each fed by 6 cylinders. They contributed, at full power, 150 Shaft HP each, for a total gain of 450 Shaft HP.) They were completely independent of the supercharger, which was a normal gear-diven 2-speed single stage blower. In terms of running the engines, they were the same as any other mechanically supercharged big recip. There were 3 flavors of the R3350. One was the engine used on the B-29. It had a single-speed gear driven blower. The turbosuperchargers (The B-29 used 2 per engine - basically the same model used on the B-17 and B-24 - with twice the displacement, and about the same RPM, it needed twice the mass flow, and using the paired turbosuperchargers meant that they could deliver a working system without having to interrupt production) fed air at what were essentially sea level conditions to the engine's mechanical blower. The production versions peaked out at about 2200 HP, and a useful Full Throttle Height of around 25,000'. The second was a similar engine, with a 2-speed mechanical blower. This was mainly used on Navy Attack airplanes like the AD/A-1 Skyraider, and early models of the P2V/P-2 Neptune and the Constellation. They had a FTH in high blower of around 15,000'. The third model were the turbocompounds described above. They ended up being the ultimate in exacting teh maximum amount of power (In cruise) from an amount of fuel, with Specific Fuel Consumption down in the range of 0.3 lbs/Hp/hr. (A typical large recip would be around 0.5 lbs/Hp/Hr.) The Turbo Cyclones were Curtiss-Wright's shining moment, and their downfall. Turbo Cyclones powered nearly all of the successful 1950s airliners, and the Navy's patrol airplane inventory, and the Air Force's Troop Carriers. They sold a _lot_ of engines. But, in doing so, they completely buggered up their jet engine development, and when jets took over in the late 1950s, Curtiss-Wright had nothing to offer. Pratt Whitney, and later, GE, filled the need. During the 1930s and into the 1950s, turbosupercharged engines were really 2-stage supercharged engines. The engine itself always had a mechanical blower as its main stage, and the turbo fed air to that. It was an add-on that required a bit more ducting and plumbing, but didn't change the basic engine. But that's not the only way to do it. I've been preparing a series of articles on supercharging reciprocating engines. Is there any interest for me to pull some of it out and present it here? -- Pete Stickney ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] One bug with multiplayer...
On Saturday 16 Jul 2005 22:56, Paul Kahler wrote: On Sat, 2005-07-16 at 22:44 +0300, Vassilii Khachaturov wrote: On a side note, while testing the multiplay mode, robitabu on #flightgear irc and I have discovered the Instant Replay is also sent to all other players. Kind of a nice feature when you want to show people stuff, but also probably something you don't want all the time... :) That's pretty cool! it's pretty harmless though, isn't it? also, when people want to see others' action a lot, and one is lazy to do takeoffs/landings all the time, this can be a nice alternative to the boring AIs in single-player --- fly a nice circuit one time, and loop it via the network to the others. Is it possible to run FGFS as a screen saver? I think prerecorded flights would make a really interesting screen saver. At our local EAA meetings (chapter13) they sometimes do slide shows before the meeting and I always thought having FGFS up there might be cool. Either a screen saver mode or a really long recorded demo would fit the bill. Paul There's not a screen-saver mode, as such, but you could script an entire flight using nasal. It would be possible to set up an aircraft so that once FG was started with that particular aircraft, the a/c would take-off, fly around, manuevour and then land, without you having to touch anything. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New super/turbo MP code is in
On Tuesday 19 Jul 2005 02:02, Peter Stickney wrote: [snip...] But that's not the only way to do it. I've been preparing a series of articles on supercharging reciprocating engines. Is there any interest for me to pull some of it out and present it here? Here may not be the best place for articles or essays but I'd certainly be interested in reading about this topic. If you can put some stuff on-line somewhere and post a url I'd love to read it. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New super/turbo MP code is in
But that's not the only way to do it. I've been preparing a series of articles on supercharging reciprocating engines. Is there any interest for me to pull some of it out and present it here? -- Pete Stickney Hmm. This might be interesting for the next issue of the JSBSim newsletter, Back of the Envelope - even if it is not strictly JSBSim-related. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New super/turbo MP code is in
On Monday 18 July 2005 23:27, Jon Berndt wrote: But that's not the only way to do it. I've been preparing a series of articles on supercharging reciprocating engines. Is there any interest for me to pull some of it out and present it here? -- Pete Stickney Hmm. This might be interesting for the next issue of the JSBSim newsletter, Back of the Envelope - even if it is not strictly JSBSim-related. That sounds like a great idea. This would be extracted from stuff that I'm flogging to the Dead Tree Media, so I'm a bit leery of making it completely open, but something fairly restricted, like the Newsletter, should be O.K. There isn't a lot of easy to find information on these matters, and I'd like to help. FlightGear/YASim/JBSSim is a fantastic project, and if I can contribute, I'd be thrilled. Modeling reciprocating engines makes you appreciate jets. When you start chasing solutions, it gets very complicated, very fast, until you end up with something like the Late Epicyclic Models of the Solar System. I've been after it quite literally for more than a decade with my own sims. -- Pete Stickney ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
