ShuRugal

lol, i didn't even notice the age of the thread. For some reason, the forums notification function put this thread in front of me, and i lizard-brain responded without reading date stamps. As far as hardware to run the game.... I was running DCS in VR on a GTX-1070 all the way up until late 2021. I had to tune the hell out of it, but i was getting 40+ FPS reliably in helicopter mode, and 50+ in the mile-high club. Currently running a 3070, eyeballing a 4070 because 8GB of VRAM is starting to be an issue in terms of <profanity> just soaking up RAM for no reason (looking at you, VR Chat)

Using an encoder wheel is definitely another good option for pit builders to make a pull-handle that doesn't require special coding!

This community has had a serious issue with gatekeeping around hardware for as long as I have been a part of it. Really needs an attitude shift. Insisting that people NEED to buy the latest and greatest bleeding-edge kit to get the minimum level of usable performance out of the game is harmful to the community, not helpful. All it succeeds in doing is driving people away who cannot get the top-end hardware.

This would be an excellent addition to the filters - just add a table to the server advertisement which contains the number of slots total and currently open for each module. Then add a component to the client browser to let the user filter both by specific module as well as a filter to hide servers with no open slots the client can use.

If Eagle does not move on this (or does not move quickly) another option for simpit makers is to have the ejection handle not directly connected to a switch, but to a sliding cam with 3 lobes which activate a momentary switch as the cam is pulled past it. Three pulses on the switch, one motion from the user.

I feel like it probably fits within the spirit of some of the other options in the Voice Chat menu (there is, after all, a full Discord-style voice lobby function for people who care to use it), but at the same time i feel like ED may not feel particularly motivated to implement channel splitting, depending on whether or not the base elements required to support it already exist in the VC engine. I'd be all for it if they did, QoL features like this absolutely have a place in a serious sim, even though i wouldn't personally use it. I'm just saying that I feel like this is niche enough that ED might feel it is already adequately covered by having the visual indications of which radio is receiving both in the cockpit and in the VC overlay UI.

I love using the AAR light bars in VR. They provide a nice little groove for aiming my HUD compass tape at. Like a set of pistol sights. Oh, wait, you mean they are supposed to be illuminated???

I've never seen an aircraft com panel with the ability to split radios between ears IRL. I know that Air Traffic Controllers do this so they can work multiple sectors at once, but i've never heard of it in an aircraft. Certainly none of the radios on aircraft modeled in DCS have a balance knob. As far as knowing which radio you're receiving on, most DCS aircraft do have a visual indicator to show when they are receiving so that you can identify what radio a call came over.

https://www.ecfr.gov/current/title-14/chapter-I/subchapter-C/part-43#Appendix-E-to-Part-43 600 feet of error at 10,000 is nearly eight times the acceptable error, as spelled out in the Part 43 maintenance regulations.

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.