gospadin

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!)

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.

Awesome, I'm glad you're on the right track. Fundamentally, it breaks down to this (from what I can tell): 1) accelerate for takeoff (full AB) 2) apply light rudder with pedals 3) plane yaws (~1-2 degrees/second was my goal) 4) center rudder by centering pedals Once #4 occurs and the rudder is centered, the yaw of the airplane should cease. Any yaw moment built up from #3 should be almost instantly halted by the straight rudder. The tail on this plane is HUGE. Instead, I see that even after the rudder is centered, the plane continues to yaw for several seconds, causing swerving to start. I can confirm rudder is centered by watching the animation of the rudder. Anyway, i'm psyched you could reproduce it. Thanks for the module!

It's not just the compiled lua. Fundamentally, to lock and launch a missile you need support from the systems code. Their code (like the real jet) isn't setup to trigger a missile launch from the center pylon, so there's really no possibility to do that without RAZBAM's assistance.

local birth = LockOn_Options.init_conditions.birth_place Not sure it meets your criteria, but technically it's not "from the cockpit" per say. Test for "GROUND_HOT" "AIR_HOT" or "GROUND_COLD" --gos

Can someone explain why the plane continues to turn on the ground after the rudder has been centered? I don't understand the physics behind that.

I'd recommend you create a single thread in the Gazelle livery forum, and update your thread there as you make each update. That will bump it to the top, and that way your updates are all in one place.

Agreed. if nothing else you should be able to modify the knobs and listen, even in easy comms mode.

sweet