Float plane help!!

[Johan_Dees 84]

Hi,I am making the FDE for an old 30's 4 engine floatplane, and ran into a problem. I hope someone has an idea?The settings are right, weights, propellors, engines, fuel etc.Flies like a dream, lands perfectly, all ok!But, a takeoff in the MS glue water remains a problem.At full power, and MTOW, nothing happens, she wont move an inch. Looks like its glued in the water.When I increase the power scalar eventually she takes off.Contact points:[contact_points]//wheelspoint.0= 1.000, -15.000, 0.000, -6.960, 1574.000, 0.000, 0.690, 0.000, 0.390, 2.500, 0.560, 5.000, 5.000, 0.000, 0.000, 0.000point.1= 1.000, 28.910, -7.000, -6.960, 1574.000, 0.000, 0.690, 0.000, 0.200, 2.500, 0.780, 5.000, 5.000, 2.000, 0.000, 0.000point.2= 1.000, 28.910, 7.000, -6.960, 1574.000, 0.000, 0.690, 0.000, 0.200, 2.500, 0.780, 5.000, 5.000, 3.000, 0.000, 0.000//floats fuselagepoint.3= 4.000, 15.000, 5.000, -5.50, 2200.000, 0.000, 0.000, 0.000, 0.800, 2.500, 0.980, 0.000, 0.000, 0.000, 0.000, 0.000point.5= 4.000, 15.000, -5.000, -5.50, 2200.000, 0.000, 0.000, 0.000, 0.800, 2.500, 0.980, 0.000, 0.000, 0.000, 0.000, 0.000//tail sectionpoint.4= 4.000, -15.000, 5.000, -4.0, 2200.000, 0.000, 0.000, 0.000, 0.800, 2.500, 0.980, 0.000, 0.000, 0.000, 0.000, 0.000point.6= 4.000, -15.000, -5.000, -4.0, 2200.000, 0.000, 0.000, 0.000, 0.800, 2.500, 0.980, 0.000, 0.000, 0.000, 0.000, 0.000//floats left/rightpoint.7= 4.000, 3.000, -31.000, -5.250, 2200.000, 0.000, 0.000, 0.000, 0.800, 2.500, 0.980, 0.000, 0.000, 2.000, 0.000, 0.000point.8= 4.000, 3.000, 31.000, -5.250, 2200.000, 0.000, 0.000, 0.000, 0.800, 2.500, 0.980, 0.000, 0.000, 3.000, 0.000, 0.000point.9= 4.000, -3.000, -31.000, -5.250, 2200.000, 0.000, 0.000, 0.000, 0.800, 2.500, 0.980, 0.000, 0.000, 2.000, 0.000, 0.000point.10= 4.000, -3.000, 31.000, -5.250, 2200.000, 0.000, 0.000, 0.000, 0.800, 2.500, 0.980, 0.000, 0.000, 3.000, 0.000, 0.000//scrapespoint.11= 2.000, 1.160, -57.000, 12.000, 1574.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 5.000, 0.000, 0.000point.12= 2.000, -40.000, 0.000, 15.000, 1574.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 9.000, 0.000, 0.000point.13= 2.000, 15.000, 0.000, 5.000, 1574.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 4.000, 0.000, 0.000point.14= 2.000, 1.160, 57.000, 12.000, 1574.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 0.000, 6.000, 0.000, 0.000See anyone a problem here?Johan[A HREF=http://www.phoenix-simulation.co.uk]Phoenix Simulation Software[/A]-----http://www.people.zeelandnet.nl/johdUnofficial PSS Website

[Guest _FSAviator]

Greetings Johan,Microsoft's attempt to implement realistic surface tension effects for hydroplanes backfired and turned into the well known viscous water bug. The chances of solving your problem by variation of contact points alone are likely to be poor. Obviously you cannot alter the dynamic volume displaced, but you can alter the wetted surface area of the volume of displacement, by changing the dimensions of the hulls and the number of dynamic hulls encoded. The visual model and the necessary hydrodynamics are not related.In any event you should encode a minimum wave state. 'Surface Bobbing' which you induce by variation of the oleo spring values, and their (lack off) damping, translates into a dynamic 'bobbing' effect, (the current wave state), that reduces the surface tension. However it is often necessary to encode an unrealistic minimum wave state to overcome the 'static viscosity' bug.Before attempting other solutions to the 'problem' two questions arise.1. Could the real aircraft take off in a flat calm with no headwind at the weight in question? Many hydroplanes could not take off at any weight in a flat calm. The surface tension was too great. 2. Are you sure you have encoded realistic screw pitch, airscrew efficiency, and thrust conversion efficiency, at zero advance ratio, (the static thrust case)?If yes to both then the next step is to experiment with 'super efficient' and therefore unrealistic airscrew code, confining the super efficiency to the relevant pitch range. If the screws were f/p you may need to encode them as c/s and create the relevant super efficient pitch range, ensuring that the pitch range in question is only accessed at speeds below Vunstick. There is no need to provide the end user with pitch selecting mechanisms. The process is the same as coding a 1930s automated variable pitch, (but not constant speed), screw. The aircraft in question may have had these?You may need to reset the airscrew low speed theory limit.Power is not relevant to this problem or its solution. Power should always be realistic, else unrealistic power will also be available in flight. It is lift and thrust that your dynamics lack, not power. They may already be correct, and reflecting the inability to depart whilst becalmed, but that may nevertheless preclude the ability to taxi out of wind in MSFS due to the static viscosity bug.Once you have enough thrust to taxi remember that if your lift slope is wrong below Vunstick that will cause inappropriate sinkage and hydrodynamic drag. Double check that the mean wing incidence is correctly coded. It is more important than usual since hydroplanes do not 'rotate' they must 'unstick' with AoA = AoI. Floatplanes will respond correctly to 'rocking' in MSFS, but that requires the end user to employ the required technique.In any event you will find it easier to control lift v IAS, than to control thrust v IAS (at constant power). If you are unable to provide the necessary code the end user has two remedies anyway. They can use Doug Dawson's freeware aircraft launching FSUIPC linked plug in. This provides an automated headwind, either in lieu of the energy for a catapult launch, or the missing headwind for hydroplane take off from becalmed water. Your panel maker should be able to set the minimum wind state for the included panel by using appropriate parameters for the relevant gauge within the panel.cfg. See the relevant documentation in the plug in download and the relevant threads in this forum a few months ago when it was being developed.You may be adding 'unreal' ability to depart in a flat calm. See (1) above.Whether the process is automated via a plug in and the panel.cfg, or supplied manually by the end user, the built in headwind component must be set to a relevant fraction of Vunstick. The headwind provides the lift necessary to reduce sinkage to the point that the wetted surface area you encoded in the contact points is sufficiently diminished to allow the hydroplane to taxi from rest using only static thrust.Since the user may logically wish to taxi downwind, neither of these sledgehammer solutions is as good as 'super efficient' airscrew code confined to the relevant pitch and advance ratio ranges. However there is no guarantee that you will be able to defeat the low speed theory limit of MSFS with super efficient airscrew code. It depends on the aircraft in question. Eventually either your panel maker, or the end user, may have to supply IAS > 0 via a minimum headwind component. From then on the encoded lift slope becomes relevant even when groundspeed is zero.FSAviator

[Johan_Dees 84]

>Greetings Johan,>>Microsoft's attempt to implement realistic surface tension>effects for hydroplanes backfired and turned into the well>known viscous water bug. >I noticed that.. damn MS>The chances of solving your problem by variation of contact>points alone are likely to be poor. Obviously you cannot alter>the dynamic volume displaced, but you can alter the wetted>surface area of the volume of displacement, by changing the>dimensions of the hulls and the number of dynamic hulls>encoded. The visual model and the necessary hydrodynamics are>not related.>Also found that out, but will try on the wetted surface.>In any event you should encode a minimum wave state. Eh??>>'Surface Bobbing' which you induce by variation of the oleo>spring values, and their (lack off) damping, translates into a>dynamic 'bobbing' effect, (the current wave state), that>reduces the surface tension. However it is often necessary to>encode an unrealistic minimum wave state to overcome the>'static viscosity' bug.>Ah, good idea, will play with that and see what happens.>Before attempting other solutions to the 'problem' two>questions arise.>>1. Could the real aircraft take off in a flat calm with no>headwind at the weight in question? >As far as I could find, it can do that, its a flying boat, and notan float plane.>Many hydroplanes could not take off at any weight in a flat>calm. The surface tension was too great. >>2. Are you sure you have encoded realistic screw pitch,>airscrew efficiency, and thrust conversion efficiency, at zero>advance ratio, (the static thrust case)?Currently using the defaults, what suprisingly gave good results when flying. Wouldnt change there much.>>If yes to both then the next step is to experiment with 'super>efficient' and therefore unrealistic airscrew code, confining>the super efficiency to the relevant pitch range. If the>screws were f/p you may need to encode them as c/s and create>the relevant super efficient pitch range, ensuring that the>pitch range in question is only accessed at speeds below>Vunstick. There is no need to provide the end user with pitch>selecting mechanisms. The process is the same as coding a>1930s automated variable pitch, (but not constant speed),>screw. The aircraft in question may have had these?Couldnt find information on that yet, but why altering them when the water is the actual problem? >>You may need to reset the airscrew low speed theory limit.Something I havent thought off, will play with that too.>>Power is not relevant to this problem or its solution. Power>should always be realistic, else unrealistic power will also>be available in flight. It is lift and thrust that your>dynamics lack, not power. They may already be correct, and>reflecting the inability to depart whilst becalmed, but that>may nevertheless preclude the ability to taxi out of wind in>MSFS due to the static viscosity bug.>>Once you have enough thrust to taxi remember that if your lift>slope is wrong below Vunstick that will cause inappropriate>sinkage and hydrodynamic drag. Double check that the mean wing>incidence is correctly coded. It is more important than usual>since hydroplanes do not 'rotate' they must 'unstick' with AoA>= AoI. Floatplanes will respond correctly to 'rocking' in>MSFS, but that requires the end user to employ the required>technique.Taxi is no problem, when she moves (with gining a tad more more in the power scale) it all goes well, just to get her going is the pain..due the water..Will double check the wing.>>In any event you will find it easier to control lift v IAS,>than to control thrust v IAS (at constant power). >>If you are unable to provide the necessary code the end user>has two remedies anyway. >>They can use Doug Dawson's freeware aircraft launching FSUIPC>linked plug in. This provides an automated headwind, either in>lieu of the energy for a catapult launch, or the missing>headwind for hydroplane take off from becalmed water. Your>panel maker should be able to set the minimum wind state for>the included panel by using appropriate parameters for the>relevant gauge within the panel.cfg. See the relevant>documentation in the plug in download and the relevant threads>in this forum a few months ago when it was being developed.>>You may be adding 'unreal' ability to depart in a flat calm.>See (1) above.>>Whether the process is automated via a plug in and the>panel.cfg, or supplied manually by the end user, the built in>headwind component must be set to a relevant fraction of>Vunstick. The headwind provides the lift necessary to reduce>sinkage to the point that the wetted surface area you encoded>in the contact points is sufficiently diminished to allow the>hydroplane to taxi from rest using only static thrust.>>Since the user may logically wish to taxi downwind, neither of>these sledgehammer solutions is as good as 'super efficient'>airscrew code confined to the relevant pitch and advance ratio>ranges. However there is no guarantee that you will be able to>defeat the low speed theory limit of MSFS with super efficient>airscrew code. It depends on the aircraft in question.>Eventually either your panel maker, or the end user, may have>to supply IAS > 0 via a minimum headwind component. >As it is now, taking off is no problem at all, even climbing away and so. Its just the first 1 knot of speed that seems impossible, like an anchor was dropped out. :-)>From then on the encoded lift slope becomes relevant even when>groundspeed is zero.>>FSAviatorI will test further and let you know, and thanks a lot for the tips.Johan[A HREF=http://www.phoenix-simulation.co.uk]Phoenix Simulation Software[/A]-----http://www.people.zeelandnet.nl/johdUnofficial PSS Website

[Guest CX001]

Interesting, my Spruce Goose model has the exact same woes. Johan, that wouldn't happen to be the PILOTS B-314, would it? If it's something else that's even better cause it's probably a S-42, S-40, one of the Short empire boats, or Martin 130.

[Johan_Dees 84]

No B, but and S indeedd.. good catch..Johan[A HREF=http://www.phoenix-simulation.co.uk]Phoenix Simulation Software[/A]-----http://www.people.zeelandnet.nl/johdUnofficial PSS Website

[Guest _FSAviator]

Some further clarification. This is a back to basics thing. All that matter are the weight, lift, thrust and drag (WLTD) vectors when velocity V = 0. In MSFS hydrodynamic and hydrostatic drag are proportional to the volume (and mass) of water displaced and hence to W minus L. So if you make an object bob, at the moment of minimum displacement, T is potentially > D, even if it is less on average, and the aircraft may begin to move. Afterwards it should continue to move if you encode rising airscrew efficiency v TAS (rising T). It seems you already have adequately rising T, but the value of T at TAS = 0 (the static thrust) is inadequate.You require T > K.(W-L)Since you have the problem T < D when TAS=0 you must reduce D or increase static T. If you increment L with a headwind at constant W that reduces D and creates potential for T > D. If you are not willing to supply a headwind via a plug in then........<<>><>The values are in TBL 511 and TBL512 of the air file. It sounds as though you may need to do no more than increase the existing zero values at the current full fine pitch, but others may need to create a super efficient pitch column in the look up tables. Suppose the screws are 15 degrees pitch at static full fine and reach 16 degrees at Vunstick when running at real world TOGA MAP and rpm at SL in ISA. You may need a super efficient column for 15.0 followed by a realistically efficient column at 16.0, then the current columns at 20, 25, 30, etc.The defaults are prone to having unrealistic values throughout to compensate for the inability of the AI engine to vary screw rpm. They are anyway not encoded to cope with the static hydroplane case.<>The water is causing the drag. For the aircraft to move you must create T > D at V=0 which is the same thing as creating;T > K.(W-L) at V=0Increasing static T will solve the problem regardless of wave state (dynamic bob) and wind vector. It is therefore the optimum solution, but if you cannot increase static T, for whatever reason, you must reduce D instead. The easy way is to increase L via a headwind (plug in) whose parameters are controlled from the panel.cfg. The TBL404 lift slope must be coded to deliver sufficient lift at the plug in encoded headwind value. You should ensure that your aircraft has at least the real mean AoI encoded as an offset in TBL 404 since a significant headwind may fail to assist if you have encoded AoI=0 in TBL 404 with the consequence that AoA=0 for a self levelling flying boat floating on calm water. Provided current CG is not 0,0,0, dynamic bobbing varies the AoA as well as the sinkage, and so doubly increases the momentary possibility of T > k.(W-L) whenever CL maximises, provided CL>0 (there is a headwind vector).>>Christopher, in MSFS TBL 400 controls the maximum vertical displacement achieved by Ekranoplans, but TBL 400 cannot augment CL for surface effect until CL > 0, so all of the above is relevant to Ekranoplans, and therefore in my sceptical view to the (fully loaded) Spruce Goose. >FSAviator