gospadin

check PM in discord

You're looking for DAWS Weather: https://forums.eagle.ru/showthread.php?t=144855&highlight=DAWS+weather To my knowledge, nobody has integrated this with DAWS Save Mission or other features, so that the weather updates every few hours giving you a persistent environment (weather+ time of day synchronized) It would be nice if this could somehow be parameterized, and downloaded missions could be signed/hashed so that they didn't need to be re-downloaded every time you connect or the server changes maps.

Yes, I know what it'd be in real life. =P Hence my original idea to merge the cockpits, and just use animation parameters to hide elements depending on which weapons are loaded.

Slow and steady wins the race. Good luck! :thumbup:

5100 lbs of mavericks ... poor Ka-50

I think his point is that as you lower collective, rotor braking forces will decrease as blade AoA decreases, causing it to speed up if torque from the engine isn't also instantly decreased. Even with lightweight blades, I'd expect a slight lag if you alter collective too quickly. Edit: I do not possess any SA342 maintenance documentation, so I don't know what the expected behavior of their engine/rotor governing system would be, or if it even has one.

Can you take a picture of the patch? I'd love to see it. Also, it is possible he was assigned to a different squadron while at NAS Glenview? http://a4skyhawk.org/content/nas-glenview-0 If he was with MARTD (Marine Aviation Reserve Training Detachment) in late 1971 or early 1972, he might have been flying the A-4L which had the avionics hump, though it's possible the patch graphics wouldn't perfectly match the planes they were flying. --gos

Two comments on your basics picture above in post #11. First, it's not runway 210, though that's roughly the magnetic heading. It's runway 21. All runways have one or two digit identifiers, with optional letters for cases of parallel runways. L/R or L/C/R. When there are more than 3 runways with the same orientation, they'll add or subtract 1 from the runway number to distinguish them, as at KDEN. Second, both VORTAC and TACAN stations *should* be able to provide both bearing and range to military radios. Whether this works in-game is a different story. Civilian VOR/DME hardware should be able to get bearing from VORs, and both bearing and range from VOR/DME and VORTAC installations. (VORTAC installations also include civilian DME equipment) All four symbols can be seen here: http://image.slidesharecdn.com/doppler-vhfomnidirerectionalrangedvor-150401050339-conversion-gate01/95/doppler-vhf-omni-directional-range-dvor-13-638.jpg?cb=1446359186

I hope not. We are trying to keep him busy here. =P

Looks great, F1 will be a great addition. :thumbsup:

Very true. However, as it stands today, if you approach a threat and realize your 342L isn't going to work, you have to go back to spectator then hopefully switch into an empty 342M slot. Versus the ability to just fly back and re-arm.

Suggested enhancement: I'd love to see the Gazelle modules combined into a single SA-342. For the most part they share avionics besides the targeting capabilities. With EFM, weights could be adjusted. Alter the cockpit avionics using visibility arguments in 3DS, so that based on which weapons we choose to load on the pylons, the cockpit auto-configures itself when you re-arm. As it is, gazelle competes for already crowded spawn slots in multiplayer, and having 4-6 generic SA-342s available that could be configured however we choose, versus being forced to 1 or 2 of each variant hard-coded, would be a nice enhancement. --gos

Not sure, but I haven't personally seen another video out there. I'm sure the F-18 and Viggen will blow us away once the developers finally share details of their modules, but while we wait for preorder/release, it's fun to toot around in the mud in the A-4. :pilotfly: --gos

Just a little something we've been working on in October... the AN/APG-53A radar! s2SBQ5kdvSU

What I believe he means is that: Defense smoke ultimately makes units more visible, not less visible, because the terrain doesn't have enough resolution to allow hiding. Therefore, defensive smoke is the same as offensive smoke markers. You know the enemy is nearby them.

Historically, ED has updated their EDM plugin to work with newer versions of 3DS over time. I would suspect they'd be updating their plugin soon, since as you said, access to 2014 may become limited shortly for those without permanent licenses to the software.

Best of luck on getting your official 3rd party status! Would be awesome to fly a supersonic strategic bomber (and hopefully it'd nudge the map architecture further)

Thanks. I guess I am not sure then exactly what _limit = {0,1} is actually limiting, if not the range of values the parameter can receive. It seems to be more of a final filter provided to the code AFTER various engine calculations are done, versus a direct input limiter.

Quick question. We're animating some knobs, like a simple volume knob. I'm using default_axis_limited, with the range limiter set {0,1} which matches the animation of the control. My question is this: When we use this setup in clickabledata.lua, if I grab it with the mouse button and move it, everything works normally. However, if I use the mouse scrollwheel, it'll wrap past 0 and jump to the 1 position. The only thing I've found so far that "works" is to set the range to {-1,1} and issue a dev:performClickableAction() to set it back to 0 or 1 if it exceeds the range. Is this the "correct" way to do this? For reference, here's the current handler: elseif command == device_commands.tacan_volume then tacan_volume = value if tacan_volume < -0.5 then dev:performClickableAction(device_commands.tacan_volume, 1, false) -- bound check to fix wrap elseif tacan_volume < 0 and tacan_volume > -0.5 then dev:performClickableAction(device_commands.tacan_volume, 0, false) -- bounds check to fix wrap end and here's the control definition: elements["PNT_903"] = default_axis_limited("TACAN Volume", devices.NAV, device_commands.tacan_volume, 903, 0.0, 0.3, false, false, {-1,1} ) Every other variation of updatable and relative don't seem to behave as expected. Thoughts? (BTW, is there an explanation of exactly what updatable_ and relative_ do?) --gos

A-10C lets you reconfigure your bomb in-air via the DSMS, and change your laser code via the TGP configuration page. While useful for deconflicting during online play on the 104th, adjusting this feature in the DSMS is unrealistic, from what I understand.

I understand that. I was purely suggesting a similar sort of math typo.

If that's the case, could be they were calculating weight incorrectly from some weapons that have since been tweaked, or something similar like the "negative weight from the fuel in the left external tank" bug from a few months ago.

TAS vs IAS at 1500' won't be that big of a difference

Agreed. Every aircraft has strengths and weaknesses relative to the situation created. If you understand this, even in general terms, you (the mission designer) can give either side the opportunity to "win" an engagement.

Maybe this has already been rehashed a thousand times, but it's not the job of ED or module developers to balance modules for game-play. They should strive for as much realism as is possible. Balance ideally comes from mission designers creating a compelling balance between opposing forces. ED could help this process with a dynamic campaign, but even mission script authors and mission designers can do their part. Oh, enemy is flying an F-14 into this CAP zone? Spawn 8 hostile MiG-21s instead of 2.