ShuRugal

stationary drogue connector on the ramp, of course. Just extend the probe, taxi up into it, and start filling!

Had to bump this thread five times over the course of two months before it was acknowledged and reported to the internal team. There is absolutely a need for a more robust bug report ingestion and tracking process. It shouldn't even be possible for a bug report to go completely UNNOTICED for that long.

You're wasting you time. There are certain users on these fora who have nothing better to do than tear down other people for daring to suggest that their is any room for improvement with ED's products. Just block the Gollum and save your energy for interacting with someone who's interested in being useful, instead of people who only want to be obstructions.

JSTARS would be amazing. I feel like Eagle would have to rebuild the AFAC/JTAC feature set from the ground up to support it, though. Not that this would be a bad thing.

https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/ifr/ https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/vfr/ For anyone who wants the charts and routes those intersections are part of.

I feel like this is selling short the fact that they have kept them flying and fighting successfully for sixty years. The IRI has some serious problems, but a lack of resourcefulness is certainly not among them. I don't think there are any other powers in that region which could have kept such a complex fighter in service for so long while under total embargo.

oh look, someone else who likes strawman arguments. <profanity> off.

You may choose to present an argument which dispels that belief. Or at least stop presenting arguments which reinforce it. You're not going to, because then you'd have nothing left to post but you may. Are you an English teacher now? Is that your objection? This feature shouldn't be implemented because Your Royal Majesty, the King of the English Language, has decreed that I, your unworthy subject, have chosen the wrong word to present my case? Weird how you keep thinking that this is only about giving pilots the ability to act as battlefield commanders, even though i've already specifically pointed out that there are non-pilot player slots in this game which could make use of the functionality i have described. It's almost as if you're ignoring the inconvenient parts of my replies so that you may continue to object. It's also weird how you keep objecting to the idea of players deciding for themselves what to attack. Have you ever actually played this game? that's 90% of the combat gameplay, players running around aimlessly looking for things to attack, and then attacking them. Especially air to ground. Seriously. Hop into multiplayer, any server running an A2G focused mission. 90% of the player base is running around like chickens with their heads cut off. Half of them have so little SA that they repeatedly blow themselves up on the same SAM every sortie. Perhaps you would like to propose removing the control stick from the cockpit of every module, since it enables this pilot-directed attack mindset you so abhor? oh, and here i was thinking it was implemented in order to give mission designers the ability to add real-world procedures into their missions. Here I was, thinking that it was also implemented in order to solve the problem I have just described for you of players attacking <profanity> at random whenever they can finally spot it. It's weird, though. They implemented all these other features for JTAC, like the ability for it to mark targets with smoke. And the ability for it to ask you to use weapons which lack PAVE sensors. You should probably phone up Matt Wagner and let him know about this mistake they made, adding all this functionality to their JTAC which does so much more than they "solely implemented" it to do. Yes, you have quite thoroughly demonstrated the narrow scope and restricted reach of your ability to cogitate. No need to brag about it. 1: Where did i ask for the AFAC to sit inside your cockpit for you 2: what the <profanity> are you smoking? this complaint is very close to making no sense as an actual sentence in English. It certainly has no relationship to anything I am proposing. Sticking definite articles ahead of random nouns doesn't suddenly mean anything you are saying is correct. Since you wanted to start off playing English Teacher, allow me to deduct three marks for your incorrect spelling of "ramifications". You clearly believe yourself to be better, how about you start proving it? As far as the actual substance of what you are saying here, please imagine that I am wearing my best "Nicholas Cage talking to an idiot" face as I say the words "Yes, that's the desired functionality." The DCS JTAC/AFAC will already only direct the player to engage targets it can see. The mission designer must already take care to place it in range of the units it will be instructing pilots to attack. None of that would change with my proposed update. Consider yourself corrected. You are so wrong that it is difficult for me to imagine that you have arrived at this conclusion at all. I can only barely follow the logic, and I am stil 90% certain you're just a troll. To address the 10%: What I want is a tool to give players in a complex mission better situational awareness without having to turn on labels, and without having to build the mission with a red smoke generator on each enemy position, and without having to line all the units up neatly in open fields. Incorrect. The mission I have built can be completed a number of ways. In testing, I have so far cleared by myself in the following aircraft: AH-64D - 4 hours to clear F-15E - 3 hours to clear F/A-18C - 6 hours to clear (bird just doesn't carry enough weapons to clear large missions solo, spent most of that time transiting to the rearm site and back) Running through it with a wingman, two Apaches had it clear in about an hour and half, which is roughly what I was targeting when I designed the mission. Two Hornets cleared it in about two hours. Regardless, you are incorrect. The objective of the air forces in this mission absolutely can be cleared using only player aircraft. I will reiterate, in the hopes that this time I won't be wasting the efforts of my flexor digitorum, that the desired intent is to allow the players to SKIP certain targets which they may not actually need to kill to accomplish the mission. As I have already noted (and you have already ignored), the primary objective (or rather, one of them) of the mission which inspired me to make my original post in this thread is NOT "go kill all the things", but rather "go kill REDFOR anti tank units to allow the BLUFOR tanks to do their jobs" It is not necessary for the players to kill all the air defense units... UNLESS they cannot engage the armor those air defenses are protecting without first dealing with the air defenses. That decision is what I want to leave up to the players on each iteration of the mission. The need to make that decision during the mission is what drives the need for the AFAC/JTAC to be able to be told "no, move on to the main objective" or "hey wait, actually we need eyes on those SHORAD units". The need for that flexibility is a realistic need. Depending on the aircraft, munitions, and pilots available in theatre, such a mission might require complete suppression of enemy air defenses, or it might require only partial suppression. Personally, all you've managed to convince me of is that you can't come up with any actual objections to my proposal. With the sole exception of "I just don't like it", all of the objections you have raised so far appear to be, at best, intentional misunderstandings of what I have explained so far. Several of them are obvious straw-man ('you're asking for JTAC/AFAC to be George!'), slippery slope ('players will just self direct all over the place!'), and false induction ('it will just break the simulation!') fallacies. I expect this will be the last time i bother replying to you. You might prove me wrong by coming up with an objection which doesn't rely on intentionally misrepresenting me, which doesn't boil down to "but players might USE that feature!", and which is actually coherent. But I doubt it.

greetings, I am trying to write an F10 radio menu item to initialize a CTLD JTAC: local subR1 = missionCommands.addSubMenu('Root SubMenu') local subN1 = missionCommands.addCommand('JTAC Activate', subR1, ctld.JTACAutoLase, { 'JTAC1', 1688 }) The above adds a radio menu command, but when i select it, the JTAC does not activate, and i see the following error in my DCS.log: ERROR SCRIPTING (Main): [string "C:\Users\SHURUG~1.DRA\AppData\Local\Temp\DCS.openbeta/~mis00003F1D.lua"]:5996: Parameter #1 (group name) missed when i open that temp file and navigate to the relevant line, i find the CTLD command i want, which makes me think that the parameters/arguments are not being passed: function ctld.JTACAutoLase(_jtacGroupName, _laserCode, _smoke, _lock, _colour, _radio) When i use a trigger command 'do script' in the mission editor to call: ctld.JTACAutoLase('JTAC1', 1688) the JTAC activates as expected. I'm sure i'm doing something wrong, but i have no idea what. test1.miz

what even is your point anymore? I have presented a clear use case where it makes sense for a player, in some kind of role or another, to be able to command the JTAC to change targeting parameters. You're arguing with me purely for the sake of being contrary.

Look, I don't give a crap whose responsibility you frame it as, there is currently no capability within the DCS JTAC/AFAC for ANYONE, be that a player in a jet or a player in the Mission Commander slot, to give it new target priorities in an organic and dynamic manner. That's. Not. Realistic. It doesn't matter who would ultimately be making the call and telling the FAC/TAC crews to redirect the air power to a different target, that is a thing which DOES happen, and which the current DCS JTAC/AFAC routine doesn't support. That's a problem which needs to be addressed. You want to get your panties in a twist over it not being realistic for the pilot to be the one to make the call? Fine, you write your missions so only the game master slot can do it.

The problem is the way that is currently implemented in DCS does not give much room for missions to unfold dynamically. The DCS JTAC/AFAC routine is firmly stuck in a 2011 single-player-limited-scope-missions mindset. With the current implementation, it is very difficult for a mission designer to put together a complex mission which allows multiple paths to completing the objectives, to include a varying number of multiplayer slots filled using varying platforms. For example: I've been working on a SEAD mission designed to give my squadron a workout with layered air defenses in support of a ground offensive. the base ground scenario has REDFOR defenders with entrenched ATGM vehicles in a position which the BLUFOR armor units must take in order to complete the mission. The Red ATGMs are sufficient in number and ambush position to at least mutual-kill the Blue armor. The Red ATGM units are defending an SA-5 battery, which is the "story objective" of the mission. The SA-5 site is defended by an SA-10 battery. SHORAD is provided by half a dozen SA-19's salted in mutually-supportive positions all positions have at least 1-2 Igla MANPADS (about a full battalion's worth, scattered around the other units) In the mission, I currently have provided slots for the AH-64, Ka-50, F-15E, F-16, and F/A-18. The ultimate objective is to allow the Blue armor units to sweep and seize the SA-5 and SA-10 positions. To this end, players will almost certainly need to suppress the SA-5 and SA-10 so that they can engage and destroy enough BTRs to allow the blue armor to succeed. But beyond silencing the -5 and the -10, how the players choose to prosecute the mission is going to be variable, dependent upon the choice of platform and skill level. In some iterations, I am seeing players choose to kill only the -5 and -10, then to remain above the reach of the -19s and drop JDAM and PAVEWAY munitions into the red armor positions. In others, the players need to also take out some or all of the Tunguskas so that they don't snipe the helicopters. Going even deeper into the weeds requires taking out at least SOME of the MANPADs, because nothing in DCS can survive making a low-level strafe or bombing pass on 36 Iglas in a five mile radius. So, the JTAC/AFAC needs to be flexible with the needs of the air support. The "ground commander" in real life is not going to instruct air units to attack positions they will die before defeating (well, not unless he's Russian), but also will probably not want to waste time killing every single SAM in the theatre (as DCS players are wont to do). With the current implementation of the DCS JTAC logic, getting this flexibility is a positively Sisyphean task. It's hard enough to get the damn thing to actually talk to players when it only has one group its assigned to target. Getting it to switch between groups on the fly has proved to be an absolute fucking nightmare.

Can this be a thing? Some of the aircraft modules are flat out impossible to read labels/indicators in VR (F14 and Mi-24 being the biggest offenders for me personally). I know that there are community mods for this, but they are a PITA to keep track of, and they stop working at random with some updates. it would be nice if we could have officially supported VR cockpit skins as another localization option.

What are YOU citing for "all projectiles are spin stabilized"? This is patently untrue for most guided munitions. Spin stabilization is only required for projectiles which fly on a ballistic course. The reason this is required is to average out yawing/pitching forces induced by any irregularities on the surface of the projectile, so that it will actually follow a ballistic course and not go arcing off towards the side with the most drag. PAVEWAY and JDAM munitions do NOT use spin stabilization, as the spin would fight the guidance inputs and require the fins to correct more (thus inducing more drag and shortening the range) in order to hit the target. While these bombs are gravity-driven, they do NOT follow pure ballistic trajectories. For certain types of seeker, spinning will actually render the guidance invalid. The AIM-9 is a perfect example of this: versions prior to the AIM-9X, all the way back to the original model, have/had gyroscopically driven "rollerons" on the rear fins to cancel out ANY rolling motion and maintain the roll attitude of the missile in the same orientation as launch so that the seeker head could work properly. The only spinning guided munitions you will find are very cheap SACLOS guided missiles, where the spin is used to allow the missile to have only one moving control surface, or rockets which have had laser-guidance packages installed. In the case of SACLOS missiles has drawbacks, such as the missile being slow to change course, which are acceptable in a SACLOS missile, because the possible maneuver cone of the beam is very small and a properly launched missile should make only minimal course corrections. In the case of 'guided rockets', the drawbacks of the spin are acceptable because of both the short intended range of use and the low cost of making this modification by only slapping on a seeker/guidance head.

except for when it flat out refuses to work. I finally gave up and will just use CTLD until Eagle implements something better.

this sounds like it's probably the same issue as the tpod on fixed wing modules needing to be switched off and on again after a reloading.... I bet the "repair" function is being treated as "remounting" the FCR, so the "new" FCR thinks it is turned off.

I understand if this is not considered a high priority, but being able to operate cockpit switchs and buttons by poking them with my VR fingertip (rather than having to use the laser-mouse mode) would be a massive QoL improvement. I prefer not to use laser mouse mode if I can at all avoid it. I find fingertip interaction to be more immersive, faster to use, and more intuitive to remember.

This comment makes it sound like you think ED cannot do both. The people who work on flight modeling and the people who work on AI logic are probably not the same people, this work can be done in parallel.

Yes, that's exactly the problem. The DCS JTAC doesn't care what your laser codes are, he wants you to use his. That's both impossible and unrealistic.

Here comes a track, same issue. I'm having problems with some vehicles on the move seeing targets through trees and buildings and stopping to engage because of it.... In the attached track, there are two groups of blue armor. One moves up the road to attack the beach which is defended by some BTRs and a Neustrashimy. The blue ground forces start shooting at the ship as soon as they are in max weapon range, completely ignoring the intervening forest. The ship shoots back, completely ignoring (and knocking down) the intervening buildings. The second group is moving on an airport defended by a mix of BTRs and BMPs. I have set the BTRs and BMPs in ambush positions, except they keep getting ambushed buy the blue forces, who see them through the trees as soon as they are in range and commence firing. This is making it very hard for me to "tune" the ambush enough to force the players to actually destroy the BTRs so that blue can capture the airfield. I originally set this up with only BTR-RDs, expecting that an overwhelming fusillade of ATGMs would be enough to knock the blue forces out.... except that everyone starts shooting through the trees at max range and makes it impossible for me to get the desired concentrated surprise fire. Unrelated: AI "on road" pathing logic seems incredibly bad. I notice units randomly swerving off the road to drive through buildings, blowing past corners and making circles forever, weird <profanity> like that. AI-SHOOTS-THROUGH-TREES-BLDGS.trk

The current implementation of the JTAC feels rather dated, given some of the newer changes and module releases. The JTAC feels very restrictive when trying to use it in anything more than a very tightly pre-planned (from the mission editor) manner. I have run into multiple situations where the JTAC/AFAC wants me to do something i flat out cannot do. For example, when carrying both radar and laser hellfires, JTAC will request radar hellfires to kill a specific target. I've had situations where the bombs on my jet have one laser code set on the ground, and JTAC has another programmed in the mission editor. JTAC will often offer me a target which makes no sense given the mission or threat picture, such as asking me to kill a T-90 when there are active Tunguskas or TORs between me and the tank. Or, alternately, asking me to kill a SAM which is nowhere near the target I am wanting to kill. I think there are three major QOL changes that would help make the built-in JTAC feel a lot more useful in the current state of DCS: 1: Ability to select targets from a list in the JTAC Menu. Have the JTAC offer me a list targets he can see, the same way George does, and I choose the target. 2: Ability to tell the JTAC what weapon I will use instead, in the event that his default request is not appropriate for the situation. 3: Ability to tell the JTAC what laser code he should use, so that if my bombs/missiles are hardcoded, I can tell him that.

Having a great deal of difficulty getting the AI to engage targets successfully with cruise missiles. Main Problems i have run into on various iterations: When using 'attack unit' or 'attackgroup', the AI will only fire one missile per target, no matter how many missiles were set in "release quantity" Missiles fired by the AI often fly into the ground or start 'dancing' and fly off in a random direction When missiles are fired in salvos, the AI does not fire a 'tight' salvo, AI aircraft will fire one or two missiles, then start maneuvering violently before firing the rest, resulting in an extremely strung-out salvo. I partially solved the first problem by switching the group to "ground attack" and giving them the "bomb" task. This exposed the third problem. In the attached track, i "solved" this problem by setting up a flight of four hornets to fire a total of sixteen missiles. But between the missiles crashing into the ground, flying off into space, and being so strung out that red Tunguskas had the leisure to pick them off one by one, only three missiles survived to target when i was recording this track. AI-CANT-USE-CRUISE-MISSILES.trk

Having a lot of difficulty getting the FCR to acquire targets. I finally put an invisible apache in my mission to test with, and i found that I am only able to detect targets when two conditions are both met: 1: the helicopter must be high enough to see the entire target and the ground around it. even a slight obstruction of the target's wheels/tracks prevents detection 2: the radar elevation must be in manual mode with the angle set as far UP as the scale indicates. even when those two conditions are both met, target detection is unreliable. I have a track attached showing first a great deal of no targets found, then when i finally do detect one with the FCR, it is only one, even though there are dozens of vehicles around it and within the scan zone. fcr-weird.trk

www.army-technology.com is not a US DoD or DoA affiliated entity. They are not a credible source for the technical capabilities of US military hardware at the level of detail being discussed here. The article you are citing appears to be this one: https://www.army-technology.com/projects/apache/?cf-view That article provides no source for this claim.

would be nice to have an option to easily toggle between flat and VR rendering from the main menu and mission editor. I currently use a separate shortcut with the --force_disable_VR flag for doing serious mission editing.