PFunk1606688187

I would think that given the recent revelations of as yet unexplained (but you can make a guess) malfeasance with respect to the Mig-21 and some of its backers' pledges that RRG would want to get on top of these extremely reasonable concerns. You can hate on big companies like EA or Valve, but when they take your money its usually pretty easy to get answers from them about stuff, even if its to say you can take your request for a refund and stuff it. When little guys have to lean on their devoted communities to secure funding well in advance of any meaningful delivery it always leaves a bad taste in your mouth to see that same community clamour for the most basic of respect for their need for information, not even just about the project but the state of their financial investment and corresponding benefits. I haven't pledged to this project but I am interested in it. I'm interested in all of the DCS third party projects and it will make me wonder some if I have to take into account possibilities of if not malicious, at least passively neglectful customer service that leads to at the very least a mild anxiety about the security of the promises you've been given. These are actual contracts between customer and seller. To break them is no small thing, even if to many of us it could be easily brushed aside as "just a few dollars" or similarly ignored by giving them the benefit of the doubt. Even if there are unforeseen issues the simplest and often more satisfying solution is for the party involved to just say "Oops, something came up, sorry guys, we're gonna have to change the timeline on this" or something. VEAO has done a great job of this. Its kind of like dating. Communication makes things so much easier, and a lack of communication turns you into a spiteful paranoid bastard. Bit of a rant, but not inflammatory I don't think. This does influence my bearing towards becoming a customer. I'm quite the fan of customer service, and ruthlessly unforgiving of poor iterations of it.

I would consider dynamic weather and no clouds a plus, given what the clouds tend to do to my frames. :ermm:

I'll try to remember to ask the A-10 maintainer that I know about that. In any case, regardless of which is meant to be the correct real-world behavior, for me understanding how to manipulate the LUA to achieve both would be valuable for the future as I tweak my current set up and one day, hopefully, construct some kind of home pit. Thanks again for your help.

You can fly with the RCtrl-Enter overlay open which might give you some better understanding of whats happening with your control inputs. Since its a new piece of kit for the company you should stay abreast of any driver updates as well.

Thanks, I'll give that a try tonight. :) EDIT. The test was successful. Observing the behavior of the Canopy Open switch now however sees it function the same as the Canopy close switch, ie. it only functions so long as you hold the key depressed, meanwhile merely clicking and releasing the corresponding switch in the cockpit causes the switch to automatically remain depressed until the Canopy is fully open. I wonder if this new behavior is actually more realistic than the original one... hmm. Could this Button 7 thing perhaps have something to do with it? In any case thanks alot. This has been exciting to explore. I'll post more if I get in trouble again.

They certainly are more robotic than in real life I'm sure, but a lot of that is on account of the fact that when the Ai is reading off numbers and words for targets its literally accessing individual sound files that involve saying a single number or word and so those when strung together will sound rather unnatural. That said, there are certain methods for passing on information over radios that call for unnatural ways of speaking, such as pronunciations like Tree instead of Three, Fife instead of Five, though ironically our robot JTAC doesn't do this. I know of no sound mods for the JTAC voice, though the nature of the files used lends itself very readily to modification; the files are in folders, not even compressed. Your best bet is to find some user made missions where tasking is assigned through full voice recordings provided by the community, like this one: Operation Bactria (MP COOP 14), Afghanistan CAS

I used to use a curve with my X52 in the A-10, then I set it to Zero and realized how limiting even a modest curvature can be to your control input. In particular the speed of inputs just feels sluggish with any curve. In my opinion using deadzone should be reserved exclusively for sticks with centering problems. I still use curve on my Rudder however.

Thanks for the help, I'll give that stuff a look. Just to clue you in, what I'm curious about is if this methodology could be used to overcome some of the default keybinding limitations with the A-10C. A good example is how the canopy switch works. In the clickable cockpit you hold the switch down to close but releasing before it seals leaves the canopy as it is when you released the switch. The controls menu entry for the canopy switch however is a simple Open/Close toggle that has none of the characteristics of the real switch. I wonder if this method could make it work as it ought to for a keybind. So far looking at the clickabledata.lua entry has left me with something not addressed in any of your linked posts. In the examples in your links the relevant controls used only one device_commands.Button, not 2, so I'm uncertain how to interpret this. It seems to me that already I should be able to use 0, 0.5, and 1.0 as the appropriate values, but I am otherwise unsure where to go from here. I wish I could help myself more here, but I'm far more competent replicating a defined process than hashing a new one out on my own, sadly. :no_sad: :dunno:

Its almost as if there's some sort of... economy at work... :huh:

If I wanted to try to use this solution elsewhere in my config for other controls in the future, how do I determine what the entries should be?

So, my preliminary tests show that this works. I'm able to change VHF AM Freqs using your borrowed entries and in game AI respond while TARS is showing the correct frequencies. However this has created a strange by-product: As you can see, all of my entries for the related radio are doubled. Is this expected or is it a product of my messy methodology? All I did was paste over the existing entries in my keyboard.lua for the related controls. This is what appears in my keyboard.lua now: Anything I should be doing differently? Would it be better if I had unbound my previous keys for the altered controls before making the lua changes?

Thanks. I'll give all that a try and see what comes of it.

Hate to break it to everyone but more stuff MAY be broken. #1 - HACK time: On the face of it it works fine, but it exhibits peculiar behavior. It appears as though the timer begins when you press HACK regardless of any other inputs, even if you enter no countdown time. To replicate the behavior do the following: -Press HACK -Enter any time in the Scratchpad -Press the Enter button on the UFC once to display the time to be counted down -Press Enter again to begin the countdown What you will see however is that your selected time has skipped ahead in the countdown by the number of seconds since you first pressed HACK, ie. if it has been 20 seconds since you pressed HACK a 60 second countdown will begin at 00:40 instead. Its still functional, you just have to enter the desired time first, turn off the HACK timer, then only press HACK when you want to start the countdown, at which point pressing Enter will reveal the timer's true progress. #2 - CDU Time Page: From the Nav page you can access the Time page. It has some limitations first of all. At LSK3 you can enter a time offset of 4 numbers that corresponds to HH:MM. There is no facility for altering the seconds. Default entry creates a positive time offset. Pressing the LSK again makes it a negative offset. Here's the bug. Every input appears to be doubled. If you enter 0001, which should add 1 minute, it instead adds 2 minutes. If the time is 12:00 then the offset time is now 12:02. If you enter 0100, which ought to add 1 hour, the time is instead 14:00. These are my quick observations, anyone feel free to prove them wrong. Its conceivable that this is how HACK is meant to function... though it doesn't rightly make a whole lot of sense to me right now, so I'll sleep on it. The CDU Time thing however can be nothing but a bug.

Its times like this that I really wish I understood LUA scripting.

And if those expectations are borne of Saitek's own ads? Quality issues and Saitek just go hand in hand, and that's to be treated as an absolute until its proven otherwise. The difference however is in where those issues crop up. None of the issues with respect to quality on any of my 3 Saitek X52s (yes I own 3 of them) inhibits their advertised function, not unless you count the progressive expansion of centre slop on my oldest stick. If OP's issues are borne of flaws in the product outside the norm then he has legitimate cause to complain to the manufacturer. All we need to do is figure out whether they're real issues or a case of Instructions-too-complicated-penis-stuck-in-HOTAS.

Used to do this all the time in IL-2 with printed maps... at night... in bad weather... uphill 8 miles in the snow.... I tell ya its good fun and you learn the real danger of complacency.

I long ago abandoned any other method than the above for my X52 mouse.

It appears as though all keybinds associated with both VHF radios are simply broken. I'm unsure if this is as true of the UHF radio.

Not relevant to the point at hand. In any environment the B-52 can survive so should the A-10. Therefore the whole slow non-stealth detractor can't be as serious a limitation as some think it would be.

If it really were that simple then the A-10 would have been obsolete long ago. If the enemy is inside small arms range then what? Ask the Marines to put down their rifles and start digging? What if all the fancy gear gets greased and the JTAC is wounded/unconscious/dead? Guy yelling on the radio "I need a gun run West of the smoke!" UAV Operator says "All I have are JDAMs Sir" Everyone keeps saying it'll be different, but I don't see how mk.1 eyeballs and guns and smoke will ever stop being relevant. Then why keep the B-52? They're talking about it being in service til the 2040s pete sake.

Hack time perhaps? Its part of the aircrafts systems for a reason, and it displays on the HUD. A-10C Manual, Page 254:

But you don't get it. There won't be any boots on the ground like this anytime soon, or so they're saying. :music_whistling:

I don't believe my question suggesting that either.

The thing is the F-35 is taking its time being implemented as a platform into the military's branches, but there's still the current aircraft to fill the gap. They obviously can't fill the entire gap or else the A-10 would've been retired a long time ago when all those aircraft were still there. If drones are the real answer to filling the hole left by the A-10, where is that development at? Is there even a priority put on it? I have heard a lot about a lot of different kinds of drones, but what is there being made right now, or will be available sometime soon, that can do something the A-10 can that all the other faster ground attack capable aircraft can't? If the Pentagon is saying they don't think the next 20 years will see a real American ground war again that kind of tells me they aren't really considering CAS a priority at all. Naturally the Army and the Marines are sitting there gong "oh good, so... ideas?"

The Hawk delay wasn't introduced by a dismaying announcement of a potential cancellation, followed by a total blackout of official forum presence. One was handled as a reassurance with clearly defined caveats, the other was a panic inducing stink bomb right into the middle of the confidence of already-paid customers. Misplaced optimism is not the answer. Patience is, but that needn't be laced with incongruous perceptions of events.