Art-J

^ An old software product is an old software product, simple as that. There's only so much that can be done with it before rework stops being financially viable given time and human resource limitations. Noone's going to "take over" for the very same reason either. None of that rant you wrote makes much sense except for the current pricing part that I agree with fully. However, it's been ED's policy for quite a few years now to keep standard pricing of all oldest modules stable and high whether they're maintained or not so I wouldn't expect that to change anytime soon.

Poke @LeCuvier about axis slowing and modifiers. He's a local guru here for similar custom modifications, albeit keep in mind his .lua edits might not always pass IC for multiplayer usage.

Not sure about all versions of J79, but in the one I saw at museum, the first stage behind supporting struts was variable inlet guide vane stage - ie. it doesn't spin, only adjusts AoA of blades. So what you see on the video might be roughly correct, but I'm sure devs will chime in and reply.

The idea doesn't seem to make much sense, though, does it? Especially from ED's point of view (or any digital goods provider for that matter) Licenses are not physical in any way, shape or form, ED can generate nearly infinite number of numerical keys, so there's nothing to "return" to ED. Thus - they'd get nothing of value from you and why would they be obliged to hand you something (miles) for nothing? Licences do not expire either, so they cannot "die" in your account. If user doesn't plan to use chosen module anymore, he can just unistall it for good.

Absolutely, even later than the latest - 2.84.1 Have to admit now, though, that my observations are clearly outdated and based on comparisons made when Barthek was still actively supporting his mod, which was what, 2 years ago or so? I used to switch between his and yours a few times to decide which one I wanted to stick with and the difference in buildings and overall brightness was very obvious to me back then. It eventually became the primary reason why I decided to stick to yours in the end - I've never used Reshade for colour tweaking, was tired of changing gamma constantly between both mods and certainly didn't want to do it while switching from Barthek's Caucasus to stock Nevada and Normandy). Now that I think about it, didn't ED update Caucasus buildings in the meantime, or am I mis-remembering old patch notes? In either case, you're right - as seen below the difference nowadays is negligible in city areas. One more reason to stick to CGTC for me then

THIS. Barthek's mod is tweaked for gamma 2.5 + reshade and thus is overall darker. Lucshep's mod is tweaked for stock 2.2 I believe. I did consider mixing up files from both, especially using superior town and building textures from former on top of the latter, but it was obvious that simple file replacement method won't work, as the edges of Barthek's terrain texture tile won't match the tone of Lucshep's field tile and there will be sharp line betweek both greens. That would require some texture editing skills beyond my ability. There's another factor to consider: Barthek's more detailed and grainy field textures will make ground target spotting more difficult than Lucshep's ones to some extent, so mod choice also depends on what type of missions one usually flies in DCS. In either case, I also recommend just trying both for a few weeks. I eventually got back to CGTC, but both are good in their own right. EDIT - made some new comparisons today and had to change my impressions - see post below.

I see. Good to know. I'm not at my PC so couldn't test myself. Thanks!

^ Seems logical. If mission calls for certain version/modification of files to be loaded, but these files are not there on your friend's local PC, there's simply nowhere to load data from. I guess the question remains if weather he sees will reset to next default preset in chronological order, or to "no clouds" (old cloud system) preset. I think that should be easy to check even on your PC, though. Save mission with bandit's mod, exit the game, disable mod, reboot PC to clear any cached data, launch the game, load the mission again and see what clouds DCS decided to use (if any).

The need is not there. Left click and drag the lever (or put mouse cursor over it and scroll) to make it "stuck" in brake hold position. To make it "un-stuck" again just bump whatever key/button you use for brake. Granted, it's a workaround, and it would be nice to have an actual assignable pin lock indeed, just like in Mosquito, but it's better than nothing.

I understand annoyance. Such a practice is not unusual or strange though - dealer buys in bulk, so he gets much lower prices than individual client coming directly to producer and can keep them lower even after applying his margin. I saw it on daily basis when I worked in logistics dept of one of the biggest worldwide corporations offering equipment for fire safety, building automation and medical industry. We added a hefty "penalty" margins to any individual client invoices below certain value to "discourage" them from buying directly from us and push them to one of our dealers. Seemed a bit brutal and illogical at first to me, but made sense from order processing cost vs income point of view - when excel spreadsheets come into play, nobody gives a F about individual buyer feelings. Granted, that was orders of magnitude different scale of business compared to a flight sim hardware company in China, but I've noticed the same phenomenon years ago when I bought TrackIR - got it in one of popular US flight sim stores as it was much cheaper than in NaturalPoint store directly, and since cross-Atlantic shipment and custom costs were the same anyway, the choice was simple for me. In your case I guess it indeed comes down to dispatch time and whether it's worth premium. Can they really ship the base faster to you than to local dealers? We'll find out soon I guess. Keep us updated, please.

I've got mine on medium or high, don't remember. It's a different problem than one in F-5 and Mi-8.

"Sandbox Afternnon" mission by Nealius might be a good start:

Just remember that in order to use it, you have to first highlight the relevant device column in options screen (e.g. left click on column with Spitfire joystick commands, then hit the load profile button, then navigate to and select the old Spit joystick diff.lua file from backup location. Rinse and repeat for throttle column, keyboard, pedals, tracking device etc., ect.)

To each his own, but from my own experience I still believe using "load profile" button in control options screen to import old bindings from backup files is faster and easier way of getting the controls sorted on new PC / Windows than faffing around with creating new diff.luas and renaming them (or copying their contents). The bloody button is there for a reason, why not using it then. True, it only allows importing backup diff.lua files one by one (per each aircraft and each controller), which will require some extra mouse clicks, but it's still faster and more foolproof method in my opinion. No extra apps or batch files necessary either.

Sounds very much like other axis (most likely on other device) is bound to throttle lever as well. Unwanted, duplicate assignments are "normal" in DCS, double check axis option screen again and get rid of them.

Looks like build 8.1107 hasn't brought a fix for this issue, so... ... bump!

I did. TF-51D flies as it always had and its rudder works as it always had. No FM or rudder changes here, that's for sure. I do seem to recall someone reporting rudder issues when using keyboard, but that was already a few patches ago. If you use the new launcher, double check if it hasn't reset auto-rudder special option for you. Can't comment about F-16, 'cause I don't own it.

Also remember that only airbases assigned (in the editor) to the same coalition red/blue colour as you will respond. At least when using realistic comms, I don't remember if it applies to easy comms as well.

^ It certainly will. From dcs_updater's "point of view" a modified file is a modified file and has to be restored. With the script, however, shrinking these textures afterwards is finally not much more complicated for us than re-enabling mods in OvGME/OMM so at least that's a good thing.

You guys are overthinking it. As mentioned in the other thread ramping up by a longer press has already been a feature in stock, unmodded DCS for years. By short-tapping it's easy to roughly modulate braking force to 1/4, 1/2. etc. True, it's never going to be as good as fully analog input but it's sufficient to operate DCS warbirds safely, as I used to do for years before buying proper rudder pedals.

That happens every now and then (although 2.9.6 and 2.9.7 seem to be exceptionally bad in this aspect). As mentioned in other threads on this subject, use clear command on the "red" assignments, reboot DCS, only then reassign them as you wish. That should fix the issue.

Good to know. I've got opposite experience with much more recent releases. I guess they keep a couple of "big" build numbers on master server while dumping smaller, hotfix ones.

^ Keep in mind ED removes older builds from their servers after a couple of months, so reverting back to 2.9.5.xx will not be possible forever. If you want to keep it, while also trying out the latest version later, you better have both versions installed on your PC, or at least keep a physical backup of that whole 2.9.5 folder somewhere safe.

Rgr that, thanks. Will torture-test a little next time I have a chance. So far the only noticeable landing gear issue I found in 2.9.xx is: when one gear assembly gets torn off during collision with ground object after liftoff, there's an extra magic "ghost" assembly that shows up in gear well which should obviously be empty. A rare damage model or animation bug I presume, but I haven't bothered with reporting it, as it's most likely not going to be fixed anyway.

What do you mean by "from dead stop" exactly? As in - keeping one wheel locked while the plane yaws around it? I haven't experienced such a strut failure so far despite using toe brakes extensively to check reversed wheel animation bug. Not saying there is no issue, but I'd like to replicate it myself.