gospadin

Thrust tables in the SFM are organized by the intersection of altitude and airspeed. We can boost the throttle setting in this range to only help you below mach 0.3 or so, thus not affecting NoE flight. Thanks for the suggestion.

Yes, the F-18 simply has enough thrust, as does the Su-33. All my tests have been done with the default carrier model. indiadamjones gave the A-4 about 15,000 lbs of thrust from a standstill at low altitude + slow speed, and that's enough to get above the stall speed at MTOW by the time we reach the lip of the deck, if you roll from the left catapult to the nose of the carrier. It's a hack, but it works. The AI planes cheat and have a magical catapult that launches them.

Are you assigning it in the button assignment page or from the axis assignment page?

Landing on carriers works as well as any other carrier-capable plane in DCS. Tail hook is functional, plane traps just fine. We slide across the deck if brakes are off just like every other plane and helo in DCS. To get takeoff to work, since DCS doesn't have working catapults for player-flown aircraft, we've faked the thrust numbers at low altitude and airspeed to allow you to takeoff from a carrier if you're very careful. This unfortunately makes the takeoff runs in Caucasus a bit short (with any sea-level runway), but we haven't yet come up with another solution. SFM doesn't allow us to arbitrarily set thrust values. We also attached LN's MiG JATO bottles to our plane, and while they do shoot flames, they don't affect thrust in the SFM either. (Though it looked cool) If ED or one of the 3rd parties improve the core carrier mechanics and we're able to integrate with that, we will do so.

If that's the case, it would explain the behavior on the ground when we have a non-zero yaw deviation from the direction of travel.

I made a quick video to demonstrate the issue: At around 0:14, I apply left rudder. I then re-center the pedals about 1 second later. The plane continues turning sharper and sharper until it crashes, even though the rudder forces should be zero. Airport is Min-Vody, DCS:W stable 1.5.353279, 3 fuel tanks. [ame] [/ame] Edit: My (latest) hypothesis is that the thrust force in the flight model is actually pushing on the model behind the rudder, perhaps even at the nozzle, making tail & rudder completely ineffective. In fact, if it's pushing behind the rudder, then any yaw would become magnified, like throwing a paper airplane backwards. I'd expect the engine to be effectively pushing through the airplane's CG, which is well in front of the rudder. The tail & rudder should act like a weathervane and help keep the plane pointing in the direction of travel. The more the plane yaws, the more the airflow deviation from fuselage alignment should force the rudder (and thus the fuselage) back in-line with the movement vector. I found I could simulate this centering force by using the wheel brakes, which act as a pair of drags to balance any asymmetric yaw. The below video is taken with the same conditions above, and you'll notice i'm applying left rudder during the entire takeoff roll. Holding the plane straight with enough additional right brake to overcome the rudder, but a bit of left brake to provide some balance, was relatively easy (with occasional corrections). In all my tests with only a single brake, I crashed very quickly, but by adding the drag/resist force on both sides, takeoff wasn't too hard: [ame] [/ame] Edit #2: If I enable airbrakes during takeoff, the plane has even less yaw stability than without. This would imply that the airbrakes (in the middle of the wing) are similarly pushing backwards against airflow on a point significantly ahead of where the thrust is pushing on the plane, thus amplifying any yaw asymmetry when the nose and the travel vector don't line up.

Yup. By the time that model came around in the mid 80s, the electronics were WAY more advanced and much smaller.

By making sure no money changes hands, there can be no hard feelings from the community if we don't meet our goals, release later than expected, or the realism suffers because of design/implementation choices or lack of official data. This is also why we have only committed to SFM+SSM at this point, because we know it's achievable to some degree. We'd all love to take it further, but that's putting the cart before the horse, and we've seen too many efforts wither and die attempting too much at once.

We are creating our own SSM using the available lua api. A-10A is FC3, and as such has access to ED's more advanced systems APIs. (They created it themselves, it's an ED product). Some mods will re-use an existing avionics set from an FC3 airplane to keep things like radar, targeting, etc. but we chose not to do that, and instead build from scratch.

We have no choice in the SFM regarding nosewheel steering, per my earlier comment. Walleye and Maverick both require a locking capability, which the SSM cannot do. Most other mods who want to keep targeting capabilities use an existing avionics set from FC3. We chose not to do that, so that we could model our own cockpit and systems, but it means that we have to limit ourselves to non-precision weapons. If we find a way around this, awesome, but for now we don't see one.

Following this up, I was able to set < 1011 hpa in Caucasus, but when scrolling from 1010 to 1009, it briefly shows 1000 before flipping to 1009.

Thank you for your kind words.

For #1, SFM+SSM is 100% lua. You get a very limited set of environmental API calls, but you can implement as much or as little system code as you want. Full HUDs, etc. are possible. Weapon locking / designation doesn't seem to be possible, but we have some ideas to try. There are no SSM radios unfortunately either. If you switch to the EFM API, by compling a flight model in C++, you lose all the SFM+SSM assists and have to re-do everything from scratch. The ASM API documentation is only available to official 3rd party developers. For #2, that's the screen for the AN/APG-53A radar. We're still digging through the code to see what we can do with it. (Walleye TV mode is supported on the AN/APG-53B). We'd like to support it, but it seems even more unrealistic than the radar. For #3, it's taken us 7 months to get to today's update, so I'd say "we have a ton of work in front of us still" and leave it at that. It really just depends on whether we can keep our progress moving forward, and how much work we have to re-do. We've basically re-implemented everything at least 3 times so far. We're learning, but for example, it took 4 of us about two solid days to get the mach disc on the airspeed indicator to work accurately, as we had to tweak the model, the animation, the unwrap, the texture, and the code all in unison to get the right behavior. Tons of trial and error as we learn how modeling in DCS works. --gos

If people look close in the video, they'll see it. There's definitely a few easter eggs.

HoggitDev A-4E May 2016 Update It's raining gauges! After a bit of a lull in late March, we picked up some momentum again in April and May has been a hectic month for the team. There are two big changes this month. First, we've finally imported a draft version of our team-developed cockpit into DCS (thanks to Merker6!), and thus are now using that model instead of the placeholder we'd been using previously. With our own model, we've been able to start animating and connecting clickable gauges, as well as programming up the systems behind them. While the shapes and unwraps still need a lot of work (though we've been able to integrate plusnine's gauges), this has allowed us to learn how to build a DCS cockpit. Instrument panel with temporary unwrap while we work on functionality: With all of this work from Merker6, plus a lot of code and debug from gyrovague, kryb and myself, with a special contribution from uboats for the nav system, the following gauges and systems are now working in our A-4E: ILS glide slope support (fictional/hidden mode) Attitude and Direction Indicator (ADI) Standby Attitude Indicator Bearing Distance Heading Indicator (BDHI) w/ TACAN bearing & range (needle 2) and NDB bearing (needle 1) Fuel flow & Fuel quantity (internal and external via selector pushbutton, works accurately through refueling/defueling and tank jettison) Armament Panel (master arm switch, gun ready switch, weapon mode dial, and pylon selector switches) 8 day clock Barometric altimeter w/ Kollsman window & adjustment knob Radar altimeter w/ adjustable warning altitude AoA Indicator w/ cruise, landing and stall markings Vertical Speed Indicator G-meter Engine RPM & Temperature gauges Airspeed Indicator with Mach dial Flaps & Gear Indicator Panel Primary & Secondary electrical busses The second major evolution is in the external texturing. Jones and plusnine have finished the "huffer" model and textures, which appears automatically when the airplane is parked with the engine speed below idle. Further, plusnine has been putting a lot of time and energy into the effects layers for our external model, and combined with Kryb's model tweaks and bottom unwrap improvements, plus the beginning of the undercarriage and connector unwrap, our model is starting to look a lot more realistic in-game. I have a lot of work to do improving the liveries and we're constantly making improvements, but all-in-all it looks a lot better than two months ago. plusnine has also generated our first specmaps, to vary reflection across the salt-worn fuselages. The start of our A-4E "elephant walk": Additional animation includes nose wheel steering (rarely installed on the A-4E, but we can't do differential braking in the SFM so we're going to keep it), pilot head turning/position, canopy animation inside-and-out, and a working gunsight. Lastly, we've been tweaking the SFM and gyrovague was able to get our landing spoilers to work in the SFM through a neat trick. While they are modeled relatively simply, arming them will cause them to deploy automatically at touchdown, and they will shorten overall stopping distance by about 30%. Brake strength isn't something we can adjust in the SFM so landing rollouts are quite a bit shorter than actual, but it's still neat to get the spoilers working and feel their effect. Spoilers just before touchdown: Spoilers at touchdown: Finally, here's a link to a quick mission video that shows off most of the working systems: Part 1: Startup, Taxi and Takeoff (5 minutes) L1IpCbshPcs Part 2: Attack run on a convoy of trucks using Mk-82 Snakeye bombs. (3.5 minutes) x_d8Sr3Pyhk Part 3: TACAN navigation, approach, and landing. (5 minutes) ENP5ar2ikVk Thanks everyone, hope you're having as much fun as we are. Until next month! :pilotfly: --gos

I appreciate DCS being combat focused, but at the same time, the IFF panels for just about all modern military aircraft support Mode 3/A+C operation, which allows them to fit perfectly into the civilian ATC network. If people wanted to run civ+mil mixed servers, I'm 100% in favor of it. Ultimately DCS:W is the engine, and doesn't care about any specific plane. Let 3rd parties build any aircraft they want for DCS:W, civilian and military.

One other thing that wasn't obvious to me. If your collective hasn't "sync'd" at startup properly, you may be doing your startup with collective in the wrong position. If this happens (e.g. max collective/idle on an airplane throttle) your engine will over-temp due to the stress before it develops enough lift to move the helo. In Mi-8 and others, you'll see the lightness on the wheels/skids if you attempt a startup with non-zero collective, thus reminding you it's in the wrong position. In the Gazelle, however, the turbine just overtemps and explodes. Watch that N4 and if it gets within 1 large tick of the white region, you have something misconfigured.

I apply to both pitch and roll. 70% saturation pitch and roll, 80% saturation rudder, 100% saturation collective, no curves

You're convinced that translational lift is working properly?

non afterburning? do you have an example?

I don't Vne can be exceeded in level flight by any airplane or helicopter, short of extremely gusty winds as was mentioned by FlaminSquirrel. If it can, that's a pretty bad design.

Thank you guys for standardizing, really appreciate it. Reduces a lot of the frustration with multiple modules. Hopefully they can get to it soon (go go 2.5 merge!)

200 kts is probably really close to the design limits on the tires, you should be able to get airborne before that point.

I appreciate your enthusiasm for the community, but that's a silly guarantee to make unless you personally are writing him a check in-full for $3000. The world is full of "sure things" that failed for reasons none of us expected.

So do people who donate get the pack even if the total of $2000 is not reached? Or does it have to reach $2000 before anyone gets the pack? If the plan is the latter, seems like a kickstarter type setup would make sense.