gospadin

Ahh, okay, makes perfect sense now. Thx!

Looks cool. Certainly useful to measure as a reference so you can recreate the cockpit by-hand. That being said, I don't understand how this would be useful building in-game, since it seems like it'd be more work to remove the noise and fix the UV than just to create your own cockpit from scratch based on this measured scan. 2 million polys is no joke, and 800MB-1GB texture seems beyond our ability to run in the DCS engine at this time. Are you targeting the typical 200-400K poly with this model? or going for something finer?

Posted version 4 (OP updated) Added EL TORO and COYOTE, fixes for ST GEORGE (channel), VICTORVILLE (callsign), China Lake NAWS (beacon position), Fallon NAS (ID, channel, beacon position), Luke AFB (beacon position)

He was suggesting that if you had a publicly-readable version of your code on github, he could clone it and offer a patch/pull request.

can you PM me your change so i can include it in the base package? :pilotfly: Edit: does your change force it to match one of the existing frequencies in the mission editor? If so, i'll maybe make that available separately, for those willing to sacrifice realism for usability. btw I found a few typos that I need to clean up too. Also, FAA is disabling a bunch of the VORs, so more will technically become historical during 2016-2017. =\ thx! --gos

Navigation is calculated locally, so i believe everyone would need it.

cool, welcome back!

Which is exactly why our goals were set how they were set. :thumbup: Our earliest discussions last fall were investigation into what, exactly, we could do without SDK access. As to "easily" well... we're a bunch of schlubs, so we make everything 5x harder than it needs to be. Discovery, and re-doing things repeatedly is part of the fun of learning how to make a module. --gos

I totally understand. Ours will be ready as a free download if you change your mind.

Those should be a function of humidity and temperature.

Yup, and at this point we're not using the ASM API. We do have a number of systems already implemented that are "ASM-like" but those are all implemented via clever SFM+SSM hacks versus using the actual ASM API.

We changed our minds because adding the clickable cockpit proved to be something we could do without SDK access. Originally we had thought that the SDK was required, but it isn't. As Jack said, adding lua control devices is pretty straightforward. Early in the project we talked about other versions of the A-4, but ultimately settled on a late A-4E with the electronics hump. This makes it a little more realistic for us to include some navigation and countermeasures, which are relatively accessible features of SSM aircraft. It's a huge amount of work (~6 of us have been working in our spare time for about 9 months now) to do even a single version of the plane, so it's unlikely we'll add a humpless A-4C at this point. Regarding the A-4M, besides the model changes, the avionics in the A-4M cannot be modeled without SDK access, so that is out too at this point. We too would love for someone else to do a realistic EFM/ASM A-4, of any variation, and I'm sure we'd buy it on day one. Howver, until that occurs, we'll keep chugging along with our original plan. --gos

Also, the F-10 map can give you the altitude at a point. You can use this to simulate having a kneeboard map or chart that the pilots might have had.

Briefing would tell them, or they'd extrapolate from tables. Yes, accuracy is limited. Against soft targets like trucks, a Mk-82 probably needs to land within about 10m. Fragmentation bombs have a higher blast radius against soft targets, but less penetrating power. Note that your deviation is a function of the dive angle. At a 90 degree angle, your drop altitude doesn't affect the impact site (ignoring wind). Radar altimeters started to be a common thing in Vietnam I believe, possibly a bit earlier. Modern planes can use radar altimeters, laser rangefinding and trigonometry to determine target altitudes, or just use GPS if they have that capability or don't want any energy emissions.

Note also roll rate changes significantly based on the mass of the airplane. With no armament and low fuel, it's hyper maneuverable. With a full payload, it's pretty docile.

Specifically, I think you're not allowed to change the blade pitch by more than about 2 degrees per second. More than that will cause your generators to fail/reset or overspeed your rotor.

Unfortunately, ED's engine assumes Y = airborne. There's thus no way to model the Y-band TACAN ground stations in the USA.

This will be an even bigger issue for the upcoming F-14, hopefully ED fixes it soon!

wow that's awesome good luck!

help? no, not right now release window? sometime between next year and never sorry I cannot be more specific at this time, we are not yet at the halfway point even

it's basically identical to previous videos right now

The use in cockpit is unchanged... you have to enable power to the proper stations, enable master arm, select the correct weapon mode, and have 28V DC primary power... then you can press fire. I was specifically referring to how weapon payloads are defined. For example, this is our code to add racked loadouts for the Mk-82 and Mk-82SE: declare_loadout(rackme_a4e("Mk-82", 6, 0)) -- {Mk-82_MER_6_C} declare_loadout(rackme_a4e("Mk-82", 4, 0)) -- {Mk-82_MER_4_C} declare_loadout(rackme_a4e("Mk-82", 3, 0)) -- {Mk-82_TER_3_C} declare_loadout(rackme_a4e("Mk-82", 2,-1)) -- {Mk-82_TER_2_L} declare_loadout(rackme_a4e("Mk-82", 2, 1)) -- {Mk-82_TER_2_R} declare_loadout(rackme_a4e("Mk-82 Snakeye", 6, 0)) -- {Mk-82 Snakeye_MER_6_C} declare_loadout(rackme_a4e("Mk-82 Snakeye", 4, 0)) -- {Mk-82 Snakeye_MER_4_C} declare_loadout(rackme_a4e("Mk-82 Snakeye", 3, 0)) -- {Mk-82 Snakeye_TER_3_C} declare_loadout(rackme_a4e("Mk-82 Snakeye", 2,-1)) -- {Mk-82 Snakeye_TER_2_L} declare_loadout(rackme_a4e("Mk-82 Snakeye", 2, 1)) -- {Mk-82 Snakeye_TER_2_R} rackme_a4e() was modeled after the maverick setup code from the A-10. Makes our weapon loadout definitions a lot simpler.

At this time, I don't think so. Might want to PM some of the other modeling projects though, maybe they could use some assistance. Maybe poke your nose into reddit and volunteer, or onto one of the discord chat servers. Good luck.

A-4E July Update Hi everyone, just checking in... Progress has been slow in July, as most of the team have had vacations this month or been otherwise occupied with real life. Since the start of July, we've been integrating more animated cockpit elements (switches, levers, etc.) into the code as the cockpit modeling moves forward. Unfortunately, there's something weird where our SSM cannot override the drawing of the arresting hook animation, so we had to back out our changes relative to making the hook lever clickable, and just rely on the keyboard command. (It's still animated.) The landing gear handle and other systems thus far don't seem to have similar limitations, there just appears to be something special about the arresting hook. We also took the time to re-factor a lot of internal code to simplify weapon system setup, which makes it much easier for us to add new MER/TER racked weapons with minimal effort and fewer typos/errors. The electrical and hydraulic systems are coming along, along with the emergency generator properly powering the critical systems in the event of a primary generator failure. With the help of another modeling volunteer, we're in the process of adding more period-accurate weapons which would have been used either in training or earlier in the Vietnam war, such as the WW2-era AN-M30A1 (100lb), AN-M57A1 (250lb), AN-M65A1 (1000lb) and AN-M66A2 (2000lb) bombs, as well as the AN-M81 and AN-M88 fragmentation bombs. (ED already implemented the 500lb AN-M64, so we're just extending that line of weapons.) We hope to show these off next month in their finished state. On a related note, we found a photo of Rockeye cluster bombs mounted to an A-4E in 1966 onboard the Oriskany, so we've added Rockeyes (Mk-20) to our arsenal as well. We've also have added placeholder gun pods while we work on the 20mm Mk-4 cannon, and they are now integrated correctly with the weapon control panel. While the Mk-4 pods had a relatively high jam rate, the USMC used them to good effect in Vietnam, and with 2250 rounds available (750 rounds per pod) they're potentially quite useful in a CAS role against lightly armored targets. Attached is a screenshot of a USMC VMA-311 Tomcats A-4E loaded for bear with six Mk-82 Snakeyes, four Mk-20 Rockeyes, and a pair of LAU-10 Zuni rocket pods. --gos Edit: Decided it wasn't fair to post an update without at least 1 screenshot. =P

I'm almost (90%?) certain that the retaining ring on the Mk-82 SE fins is purely mechanical, and is always opened when the bomb is dropped. Edit: nevermind, I am wrong: http://navyaviation.tpub.com/14313/css/Mk-15-And-Mods-Snakeye-Fin-Assembly-34.htm Edit 2: There appear to be 3 modes, listed on page 36. Unretarded (no pilot option), Retarded (no pilot option), and Pilot Controlled based on whether the pilot energizes the tail fuse solenoid. --gos