Anyone here on SU6? Any issues with the mod?
Nothing I could attribute to SU6 specifically, I think.
One thing I noticed tonight is the float version in choppy seas will scrape its floats on the bottom, which is really loud. IIRC there is a variable you can adjust to increase the depth of the water. I believe the SDK states this should be about half the height of the plane in depth.
I’m using the Duke audio mod as well. If I flip the batteries, then disconnect them after only a second or so, I noticed I could still raise and lower the flaps, and hear the associated audio. This eventually stopped working, and the lever would move without the flaps moving or triggering any audio.
Thanks for the feedback!
I’ll look into that, thanks for the hint. I thought I had addressed this by removing one of the float-related audio events, but this might be a much better solution.
As far as I know, and maybe @JoseColme can confirm or correct this, all it needs to drive the flaps is hydraulic pressure. Next time you try this, watch the right pressure gauge on the center console. The flaps should stop moving when the reservoir is depleted. (They might keep moving for a bit, because it’s non-trivial to make them stop between detents.)
The hydraulic line on the flaps were designed to maintain pressure at a given flap position, but not move in case of a hydraulic failure. The pumps themselves are DC operated, so turning the battery off with generators off should turn the pumps off. Leaving the flaps at whatever position they were when the pump failure, or shutdown in this case, occured. So, you can move the lever, but the flaps shouldn’t move. And if no hydraulic fluid is passing through the lines, I would assume there shouldn’t be any sound. If a failure did occur, I think you could retract the flaps and the pressure in the lines would release. I’m not sure about that last bit.
I’d like to second @militaerpolicep how can I get a legitimate copy of the 2020 Twotter “after market” version?
I must confess I didn’t actually check to see if the flaps moved, so it’s possible that it’s only the audio cues being triggered.
I’m just having a quick play with max_water_depth now. I have it set to 20, pilfered from the BKSQ Caravan Amphib, and I still get that crunching sound. Currently only set on the DHC-100 float pax variant.
I spawned somewhere with 18kt winds, and I have found it very difficult to taxi away from the wind, after spawning inside a kind of harbour. The plane spins about its axis very quickly into the wind, even with those huge floats. No idea how realistic that is though, so take what I say with a huge pinch of salt. Asymmetric thrust is possible, but fiddly. I had to have the left engine just above full reverse, the right engine somewhat forward.
I’ll get a video uploaded shortly.
With water depth set to 20, it can do this.
Video of taxi in high winds. I would have assumed that with those floats there would have been more stability along its axis. It seems to pivot like a small rowboat. NB: see salt comment above. 
Video showing the scraping noises. Now that I look at it again, it seems more prevalent near the shore, even though depth is set to 20. No idea whether the sim simulates gradually reducing water depth near the shore.
In one situation, wind was like this, left engine was in full reverse, right engine was full forward, full left rudder, and I still couldn’t turn away from that wind.
I just noticed the wind has increased quite a bit though, so perhaps this is far above what the Twotter can handle. MSFS water never seems to do wind justice as far as water peaks are concerned.
As I was typing this, the plane had beached itself, and I am hearing what sounds like lots of tyre squeals, even though it doesn’t have wheels. Mismatch on audio cues from the Turbine Duke pack maybe? I just landed it on a paved runway, and when it came to a stop I hear the same continuous tyre squeal, even though I’m stationary, and have no wheels.
Also just noticed a very minor thing. The flap 40 indicator doesn’t actually line up.
Note that these are just my observations, and I am in no way requesting support for these “issues”.
Sorry for the wall of text.
I was so hoping for you to confirm my claim. 
Here’s my take: The electric pump under the cabin provides pressure to two separate damping accumulators, one for the brakes, and one for the flaps and nosewheel steering. The pump is not providing pressure to any system directly. The pressure gauges near the center console show the pressure in these accumulators, they don’t show the pressure of any individual system.
The intention by the Twotter designers was obviously to make it possible to land the aircraft safely after a failure of the (non-redundant) hydraulic system: you must be able to control the flaps, and, after touchdown, you must be able to steer to keep on the runway, and to come to a stop.
None of this needs electricity as long as the accumulators have pressure. All the cockpit controls for these systems are purely mechanical, including the flap levers. And you have a handpump that the copilot can use to keep the pressure up.
I believe I modeled all of this faithfully:
- The brakes lose efficiency if the brake accumulator is depleted. You might have noticed that the Twotter can roll a bit if spawned on a sloped apron, that’s because it initializes with empty hydraulic cylinders and it takes a moment for the chocks to be deployed. The chocks are supposed to hold the aircraft in place while hydraulic pressure is building. (If you’re quick, you can “watch” your invisible co-pilot cranking the handpump on the EFB Systems tab.)
I model the brakes (just like the nosewheel steering) based on changes, because that’s how hydraulic systems work. If you fully depress the brakes and leave them depressed, you just pay the cost in form of hydraulic pressure once while the brake pedals move down. Keeping them down does not constantly “consume” pressure (that’s why it’s another custom system, the sim thinks that holding the brakes should constantly cost pressure). - Nosewheel steering depletes the system accumulator quickly. You certainly heard the hydraulics sound playing constantly while you’re doing quick turns during taxi. Pressure is “consumed” whenever you change the direction of the nosewheel. Just maintaining any direction by holding the tiller (or, in our case, the rudder pedals) in position should not deplete the cylinder.
- And I believe the same behavior applies to the flaps: as long as there’s hydraulic pressure, the flaps can be controlled. Holding them in place does not cost anything, that’s the job of a valve that keeps the applied hydraulic pressure “in the flaps”.
I have little reference material for the details (“how much pressure does every degree of flap extension, or every degree of the nosewheel turning consume?”), so I had to calculate backwards from the little information the POH gives. I’m sure I got some details wrong, but, in principle, I believe the implementation is as correct as I can make it.
A few quotes from the POH:
The hydraulic system operates the wing flaps, nose wheel steering, wheel brakes and (if installed) the wheel-skis. The main components of the system are an electric motor-driven pump, an emergency hand pump, a reservoir, damping and brake accumulators, flap and nose wheel steering actuators, brake valves, and a flap selector.
The system is pressurized by the motor-driven pump and pressure supply is retained by the damping (system) and brake accumulators. Pressure is immediately available from the damping accumulator for operation of the flaps, nose wheel steering, and wheel brakes.
The emergency hand pump is provided for use in the event of failure of the motor-driven pump. It may be used manually to pressurize the accumulators or to operate the wing flaps and nose wheel steering directly.
The wing flaps are operated hydraulically by an actuator in the cabin roof through a system of push-pull rods, levers, and bellcranks, and can be selected to any desired setting within a range of 0° to 37.5° by a flap selector lever.
The indicator is operated by a spring and a cable which is connected to the flap operating mechanism.
If the leak is not in the braking system, sufficient fluid may remain in the brake accumulator to allow for 2 or 3 applications of brakes after landing. [Indicating that “2 to 3 applications of brakes” is what the brake accumulator can supply before it’s depleted.]
After landing, nose wheel steering should be used with caution. Large movements of the nose wheel steering tiller may deplete the hydraulic system pressure faster than the pilot can operate the pump.
Subsequent taxiing of the aircraft should be carried out slowly and with considerable caution. Large movements of the nose wheel tiller may deplete hydraulic system pressure faster than the pilot can operate the pump.
If the HYD OIL PUMP circuit breaker is open, operation of nose wheel steering, brakes, or flaps will quickly deplete the system accumulators and the hydraulic services will become inoperable.
So the one thing the mod doesn’t do right are the continuous flaps. I don’t think the sim supports continuous flaps, but I’m not sure. It’s way down on my todo list.
So, yeah. If you still think the behavior is incorrect, I need some evidence that is strong enough to override the POH.
Thanks for the report, the videos are especially helpful to nail down what’s going on.
I don’t think those are scraping noises. That’s Aerosoft’s “water touchdown” sound.
Had you tried the same in a previous release, you would be living in a room with padded walls now, because the sound would have played literally constantly. And the full-length (see below) outside version of this sound object also contains engine noise, so you would have heard the engines running all the time, even when they weren’t running.
I tried to mitigate this in .174 in three different ways:
- I removed one of the three touchdown sounds (I kept left float and right float, I removed the “center” effect).
- The sound was supposed to play only on touchdown, but MSFS2024 triggers it constantly, so I added a threshold (-300 fpm or something). Obviously, that threshold doesn’t work as intended in your video, bobbing on the water can still trigger it. It worked for me when I tested in calmer waters.
- I changed the sound from a loop to a one-shot that fades out quickly (you can clearly hear it fade out every time).
I can see why you would call it a scraping noise, because it clearly happens way more frequently when you’re close to the shore. At this time, I have no idea why that is.
As you demonstrated in the other video, the sim continues to trigger the spurious touchdown events even when you’re ashore, but now the “is in water” condition is no longer true, so a wheel touchdown is played instead.
This is, of course, all inherited from the base model. I’ll put it on my todo list, but it can take a while. I’m collecting float/amphib bugs for an overhaul at some point.
I know little about float planes, so I’m gonna need a lot of help there figuring out how we can improve the behavior. I won’t even try to comment on the pivoting and the weathervaning.
I can say that I’m planning to add an (optional) water rudder at some point, to make the float/amphib variants accessible for users that don’t have two throttle levers and thus have a harder time using differential power.
Working as intended and as IRL. Max flap extension is 37.5°.
I have a TQ so can use differential thrust okay. I just think in that scenario the winds were above the max demonstrated of 25kts, if I recall.
I don’t know if longitudinal stability on the floats, or whatever the variable is called, has any effect on wind, and weathervaning. I know it can affect how well the plane will turn in the water even without wind.
Next time I’m in that scenario, where it’s almost impossible to turn against the wind, I’ll fire up the Caravan Pro to compare behaviour.
And thanks for the flap clarification.
Oh, one more thing about the flaps: I concede that the flaps sound like an electrical motor drives them.
That’s because I don’t have the real flap sound. That has been on the Known Issues list forever (like, since the first release), and it has bugged me forever. The real flap sound would be purely mechanical and continuous while the flaps are moving. So 0° → 37.5° would be one continuous sound, not three consecutive sounds, one “per notch”, because the Twotter doesn’t have notches.
I didn’t check whether the TwotterX has a better sound, because I wouldn’t be able to distribute it anyway. (The TwotterX for FSX/P3D is still being sold by Aerosoft, so there is no wiggle room at all.)
Could you reference it if the user had that sound pack installed? I guess you can’t just pull single sound from the pack, and have to use the whole thing. It would be a shame to toss out the Duke sounds for a single sample.
You mean the TwotterX flaps sound? That’s a FSX/P3D add-on. So I would have to extract the audio on the user’s system from their TwotterX installation and add it as a wav file to the mod. Not impossible, but it seems like a lot of work and the result would be a fix that works only for a small group of hardcore Twotter fans.
edit: Just listened at the TwotterX flaps sound. Probably sounded okay to us ten years ago, but considering today’s standards, it’s not a worthwhile option.
edit: Oh, and, no, I don’t have to use the whole soundbank. I can load multiple Wwise packages and access any of their sounds. The main challenge is that the sim prefixes every sound object with the aircraft name, so the Turbine Duke sounds only become accessible after renaming them all inside a copy of the Duke’s Wwise bank. That’s why the install script has to copy the file and run xdelta on it.
There’s also the FSX era sound pack, one I bought shortly after the Aerosoft Twotter was released. I think it’s still on sale now. It’s on SimMarket.
No flaps sound in the demo video, only engine sounds.
I should probably remove the flaps sound altogether, at least while the engines are running. Or can you hear the flaps moving in this video?
Oh geez, I hadn’t seen this video before (it fell through my sieve because the engine instruments aren’t readable). Just watch the landing and take note of how much power the pilot has to maintain all the way to the ground with full flaps (runway length is 992m / 3250ft).
Yeah. I went through the EFB check list, and found for water landings flap 30 was working better for me than 20, otherwise I had to almost glide in, and the approaches always felt very flat. 30 felt better for me, and with a little more power as well. Those flaps are barn doors.
Spent some time playing around with my Streamdeck + XL, making use of the rotaries to build a cockpit light panel in SPAD.
When setting the potentiometer values, make sure to set appropriate constraints on the values set.
100
0
-1 or “Ark of the Covenant mode”
While I was there, I had a look at the landing light strength, which sitting on that lake, and later when slewing over to a nearby airport, it seems like they are pretty weak, and I couldn’t see that the mod tweaks those.
The default configuration for these are:
[LightAttributes.0]
Type=spot
Size=0.1
Range=500.0
Intensity=20.0
Softness=1
SpotInner=0
SpotOuter=30
Volumetric=100.0
ScatDir=0.5
According to the 2024 SDK, intensity is measured in Candela’s.
So 20 cendela is about 250 lumens, or about the same as your average fridge light it seems.
I did some digging, and found some replacement landing lights for a DHC6-100, and one example was a couple of 28V light kits, 100W PAR 36 for taxi, and 250W PAR 46 for landing:
https://kadexaero.com/wp-content/uploads/KADEX-Exterior-Lighting-Upgrades-for-Twin-Otter-1-1.pdf
The suppliers for 28V 250W PAR46 lights don’t seem to list their rating in candela or lumens, but if you believe Google these can range from a maximum intensity of 150,000 candela or even 300,000 candela. Compare that to the default value of 20!
Just found one, although it is not 250W, but the candela is listed, so a rating of 250,000 does not seem unrealistic.
AeroLED PAR46 Landing Light. 19,250 Lumens! - Knots 2U, Ltd.
I also notice that they have volumetric set to 100, even though the SDK lists this as either 0 or 1. From previous experimentation a value of one makes light cones visible in cloud/fog, but even slightly visible with no moisture in the air. Playing around with the light debugs you can get pretty good results, with a balance between actually lighting cloud/fog, and hardly being visible without, at 0.01. or 0.001.
I haven’t re-tested this yet, but sadly those values worked only when configured in the SDK debugs, and were ignored when the configuration was loaded at spawn in. That was several SU’s ago, so I think a re-test is warranted.
Just ran a quick test, setting intensity to 150,000, and range to 3500.
No idea how realistic that might be.
Compare that to the default taxi light, which I didn’t touch.
Luckily some websites showed images of their lights being shone onto buildings, and from that we might work out realistic inner and outer light cones.
It looks like the volumetric setting is still getting reset. I had it configured as 0.1, and on spawn in it was reset to 0. I don’t know if there is any way to set that dynamically after spawn in, but I assume not.
Thanks so much for the research! 
If you want to take it a step further: I’ll include whatever you come up with and we’ll collect feedback. The lights are perfectly calibrated when the number of people complaining that they’re too dark is roughly the same as the number of people complaining that they’re too bright.
As a general rule, most settings in .cfg files can’t be changed or overridden at runtime. Also, MSFS2024 is aware that the base aircraft is a MSFS2020 model, so it goes through compatibility layers which might affect the meaning and behavior of some of the settings; keep that in mind and don’t let settings that just don’t work as advertized drive you crazy. I have not looked at lights at all (with the exception of the annunciators), so that’s the only wisdom I can contribute at this point.
Sure, I’d love to help.
One thing I noticed, and I don’t remember whether this is a new thing or not, but the intensity I had set in the .fx file did not match the number presented in the SDK Lights debug window. I’ll check later, but the only thing I can think of is the config file is in Candela as per the SDK documentation, but in-sim its reporting in Lumens.
150,000 x 12.57 =1,885,500
But the number in the debug window I think began with a 4 and was much longer than that, which would make tweaking it fiddly until I can figure out what the conversation is. Setting to 1 will hopefully explain what that is.
I’m reasonably happy with range. SDK states that number is really used to restrict its range, and the sim would project the light based on other values, and Range is just to reign that in if it seems excessive. Hopefully some Twotter night take offs or taxis will illustrate something I can emulate.
Found this on Youtube and love it. I’m so focused on realism and systems and damage right now, I kinda forgot how much fun you can have just flying this thing.
@SnakeGaming1881 Is this your channel?
(Also, I learned that the hydraulics pump is firing much more frequently than expected for some users. I have an idea why, and I’m gonna address it.)