Thamiel

Remind me: you are still a single person and speak for yourself? Unless you are a major investor with x k$ (and ED is willing to let you do that because as an investor you always want to secure an investment of that magnitude) this increase will be marginal and not worth to speak of. So what you are "willing" to do is not really to increase your investment into DCS' future, is it?

Looks like the other way around: you are "willing" to pay because you purchased all the modules and maps and therefore are not willing to let that investment go down the drain?

Yeah, did that. There are still waco inputs from somewhere. Its not always reproducible either.

Experienced similar mixed axis settings after redefining my key bindings. My Warthog Trottle, normally bound to the collective, gives double input (Z and RZ). Separately defined, the now undefined RZ axis of the Throttle starts working on the pedals, superseding my TFRP pedal setting.

To add to the confusion, we are experiencing the same problem for two weeks now. Meanwhile, our CA-JTAC did a complete reinstall of his DCS software which solved the problem until he added his Reshade software. The results were reproducible.

Incompleteness is no excuse to go for something completely different. If it says JTAC on the box, i would like to have one inside. But this concept goes both ways: it is defined by a certain functionality and certain limits. A convenient pink rabbit hopping out of it would not be a suitable substitution even if he is planning the engagement for you or let you decide in which colour to dress. No, you dont. All ED can do by now is to build on top and to hope, the x+ year old foundations wont crack by the weight of it. That is why most updates eat up more and more system ressources. That is why they are so cautious and take so much time changing things in the core. They build on top. Going into the depths of the code is expensive and risky because it not only affects you but potentially all other devteams and their modules. For instance, one would think that by now well documented interfaces exist to manage and implement all radio based services (Radio, Radar, Tacan, VOR, NDB, LinkXY, JTAC,...) and their invariable restrictions (LOS, range, signal degradation,...) readily available to all third party developers. Still, bugs keep on coming in these areas. So I agree, there is not much left in the current AI-JTAC functionality to be salvaged, it is incomplete, it shows its age, it is an excuse of a JTAC. But it is running. There is no replacement for it because development would cost and risk more and generate less added value than what little we have now for sure. Otherwise, there would be on to it. Afaik they dont.

That is not a problem of the JTAC functionality, but of almost every aspect of the mission editor if you exclude .lua level. As far as the F-5 and M2k modules are concerned, a GBU is just another iron bomb and dropped as one. That includes the setup of the laser code by the ground crew. Of course, a JTAC on the other hand should be able to setup his designator accordingly (and many other things too). Again, its an economical approximation, it is incomplete, so what? And there is the major reason why this will never happen: its a running system. You dont change it by ripping out even one single root. This is not a well documented software package, it is the result of many devteams contributing and tinkering over many years. Otherwise, ED would not be months and years behind simple bugs like TACAN functionality or similar core issues used by the majority of modules. Why on earth would ED even think about quality if it doesn't pay?

Hired by the OOC mission builder, not the pilot. A JTAC doesn't even answer to the pilot. If anything, a CAS pilot delivers a service to the JTAC and subsequently its CO. Of course one can complain about the rudimentary implementation of the current AI-JTAC. As I said before, it was meant to give F-5s, M2000Cs, etc. the means to get their GBUs on a target (not chosen by the pilot). It was not meant to deliver a sitrep or to manage a nicely organized CAS stack. It wasn't even meant to give you a complete 9-line. I get it, one can complain about that. I might add, that the costs and ressources to implement all that functionality would probably outweigh the final results, so instead we are stuck with an economical approximation, but then again, you dont have to go with that. What you cant do is to build a redforce on the ground, complain about its strength and the impossibility to tackle it to your liking and therefore make demands/propositions to the devs to expand the functionality of an DCS aspect (said AI-JTAC) to make things easier just for you and regardless if that expansion could still be considered as an instance of its former role. To me, that looks like a purely self-serving argument.

Including turning it into a hired help?

Of course, but why should I? I couldn't care less about what you believe. Oh, you mean apart from the last 2.9 "feature" called spotting dots? Seriously, why are people always on the lookout to cut corners? Especially when they are responsible for those corners in the first place? 36 Iglas, really? You could easily generate the same deterrence with a fraction of those. But then again, I can understand how one would ask for an George/Petrovich observer to help in such an environment. Simple solution: Fly a family model.

You may choose to believe that. Based on the proposition, the headline "JTAC modernization" is a misnomer. It should read "alteration" instead. The AI-JTAC was never meant to to give the pilot full control about what to lase or attack. It was solely implemented to give those aircraft a possibility to drop their LGBs on target which do not sport a LANTIRN on their own. In that role, it is useful. Personally, I believe its not even possible to extend its functionality to that of an onboard Petrovich/George WSO without breaking basic simulation rules like that of the LOS. For instance, Target visibility and target aspect are ramnifications devaluing your proposal because in general the ground unit is less mobile and has a much closer horizon than the aerial asset. Correct me if I am wrong, but it occurs to me what you really want is a local TGP available without having to mount it on your wing. Your case study only proves that in DCS you can mount an oppositional ground force too strong to be overcome by aerial forces alone. I dont see this as a disadvantage in terms of game balancing. As a side node: my community aced such an objective some months ago just by swarming it with 100+ TALDs - also not a very realistic tactic, but fun it was.

But you realize that DCS is ultimatively a flight simulator and not a military planning tool? Clearly those are different demands.

Again, the JTAC is a facilitator trying to match the needs of the ground CO and the airborne capabilities he is stuck with. But before he spents time looking for it, he should determine if a solution is possible, if it is probable and what the costs will be. Otherwise, he works a semi-decidable problem for a long time getting frustrated with his failures while his CO (and the guys in the trenches) are waiting and most likely getting hammered as troops are in contact. If you roll out big momma as an objective, with every angle of attack covered as much as possible, even an professional JTAC might be overwhelmed with the SA and tactical implications involved as this situation unfolds. That is why he is not required to make strategic decisions. A JTAC does not command a battle of this magnitude. Doesn't mean that in DCS there is no need for a shift of command authority to airborne forces as DCS is a flight simulator after all. There may be even a RL based solution to that as it occurs to me that a JFO capable ground unit might fit that role quite nicely.

To my understanding, that would be a major shift of the JTAC role, normally a facilitator of air strikes on behalf of his CO. A pure CAS pilot has no authority to determine which target to attack or which weapon to use, although he may give some suggestions as to what he is capable of and what may be effective in a certain situation. Even in the FAC(A) role, targets (and times) are still chosen by the ground commander.

@Focha: Experienced that too. I had multiple triggers with similar conditions set up like yours to activate multiple mutual exclusive late activated convoys by "Part of Group in Zone". The first trigger defined in the trigger list fired after seconds of the mission clock w/o meeting one of his ORed condition. If I deleted this trigger and tried again, the next one on the list would reproduce the same behavior. Also, after leaving the mission, I had massive _[id] entries in the mission timeline, up to 4 entries per second / every second.