ChickenSim

Could be wrong about the Hornet, but I was under the impression that the original AGM-65Es couldn't be self-lased in real life. They required an offboard lase from a third party. This might play into why there's no supporting switchology for it in DCS on a mid-2000s USN Hornet. The Es are only able to be self-lased for gameplay reasons. It wasn't until the AGM-65E2/Ls came along (and I'm assuming some software updates for the aircraft themselves) that TACAIR could self-lase Mavericks.

The way it's written, that's what it sounds like, yes. There's a conflict between two manuals. When the EW page gets displayed, the logic counts it as "no EHSD displayed headsdown" and treats the next press of Sensor Select Switch Left as an initial actuation, bringing the EHSD up on the left MPCD. (1-37 TACMAN Vol I) This is at odds with the H4.0 explanation that the EW page is merely inserted as a third page in this revolving sequence. (23-48 2008 NATOPS) The real jet could be programmed with this "error" instead of counting Sensor Select Switch Left as a subsequent actuation when the EW page is displayed, I'm not sure. But I think that's what's happening.

That would fall under an "EHSD displayed headsdown" already, in which case SSS left is a subsequent actuation that alternates the EHSD between display modes on the MPCD it's already displayed on. It doesn't say it swaps the EHSD to the left display when you press the button, it only brings the EHSD up on the left display if no EHSD is displayed on either MPCD ("headsdown") in the first place.

A lot of what you're describing are the sorts of bad habits and deficiencies born out of low-intensity conflict that it used to be part of my job to study and help correct. Worrying about the ground unit not knowing where they were, or thinking that they had less situational awareness than supporting arms, would have been incredulous enough for us not to be major considerations. It gets pretty dynamic when you ramp up the complexity beyond one isolated patrol/outpost, one section of aircraft, and a drone. Include adjacent maneuver units, multiple forms of indirect fires, and both rotary and fixed wing (or multiple sections of each) in the same objective area, and achieving that level of combined arms requires stricter adherence to standardized procedures and techniques for fires integration/synchronization to be efficient, not inadvertently get in the way of the rest of the team, and mitigate tactical risks. At that level, I suspect we aren't even really talking about the same thing, since the airplanes and their CAS are only one tool in the fires toolbox (albeit an important one). I don't want to misrepresent your position, but it seems like you're coming at it from the reactionary angle of doing whatever works when you've ended up in a really bad situation (how did we get here to begin with?) and need to get out of that bad situation as quickly as possible (the A-10 in your example is great for that). Our angle was more proactive. Our concerns were keeping the entire toolbox shooting simultaneously, when and where they were requested to achieve a common mission. Anything that wasn't in service of this goal or prevented other fires contributors from doing their jobs (the A-10 in your example is great at this too) was cut out of the fire support machine. With this in mind, I see the CAS page's value as ensuring those weapons are going where they need to go, when they need to be there, while not shutting down other fires, and without the pilot needing to stare down into the objective area prior to beginning an attack.

Fri13, My previous post was simply to shed some historical context and explain why it's important for Razbam to cooperate rather than demonize the people reporting issues. It isn't necessarily reflective of contemporary Razbam (at least I hope not). It was up to them whether to push for a 2018 release, and through a combination of delays and changing quality targets they gave it two more years. While there are still plenty of missing features and frustrating bugs, that does count for something. I hope to see the same pace too.

Considering Prowler saw fit to try and publicly smear me directly, while lotting plenty of other people into the same group, lied to the community about the nature of my ban (check sig), and then lied to Eagle Dynamics to try and get posts pulled here claiming I was under an NDA, yes, I do have some words left to say. This isn't old dirt. This happened two weeks ago. Prowler already tried the trick of claiming the community was upset about something it wasn't, and now you are here saying that their own direct attacks were justified by a belief that it was the correct way to mitigate things, and to offer an insincere blanket apology for vague "issues" rather than the issue: Prowler's rampant dishonesty. So as CM, how are you planning on getting him to start telling the truth? I'm dying to know.

So to make sure I have this straight... You're saying that Prowler believed it was the best course of action to insult the community of volunteer contributors, you volunteered after the fact to represent the organization, and therefore that abrogates Razbam and Prowler from 1) directly addressing the wrong behavior itself and 2) taking responsibility at all? Am I understanding that correctly? It sounds an awful lot like nothing has actually changed then, although I appreciate that you'll at least answer community questions and may actually achieve your stated goal. Here's hoping honesty and transparency are part of it.

ELMO, you have nothing to apologize for, as Community Manager or otherwise. You weren't even on the team when Razbam went beyond banning people and started publicly attacking the character of myself and members of ED's staff. We're going to end up right back where we started if what you're considering "abuse of team members" extends to asking for the very honest clarification you're providing with this post, like it did with me. I agree that integrity is important. I may be wrong here, but I don't think it's harassment to ask that Prowler have some and offer this apology himself.

Harker, just some discussions in Discord. I'm only asking to head any misunderstandings off at the pass about what the things are despite what the airplanes call them.

That's correct. Can ED comment on whether this GRID entry is going to be in the described MGRS format from the NATOPS, or UTM format? I'm hearing rumblings that this is actually strictly UTM, in which case that's going to be a huge disappointment, or there has been a misunderstanding somewhere. Back during this timeframe, MGRS format was colloquially referred to as GRID or UTM in a lot of aircraft, but it was still functionally MGRS. For reference, 11S 767155 3599524 is a UTM grid coordinate. 11S QR 67155 99524 is the same location, based on UTM, in MGRS format (the jet calls this UTM). 2008 NATOPS, VII-24-23 - VII-24-32

For some of us, finding bugs or false simulated or missing systems was part and parcel to helping create a better finished product that other people can enjoy however they want. The training missions wouldn't be in a working state today if they weren't accompanied by hours of verification and validation that the systems we described were actually working as "intended." They wouldn't be released if they didn't get developed alongside an exhaustive list of functions that, based on the source materials, weren't working properly. Some of these outstanding submissions and requests date back to 2017. Remember, back then, their target for full release was Summer 2018. Razbam's quality target back then was not the same as it is today. It wasn't until Razbam saw and were impressed by the that they even decided that they would want to include BITs at all. I don't say this to be overly critical about not having BITs (I wouldn't say BITs are ever a necessary feature, they're just a pretty bow on a well-simulated system), I say this to be clear that the number of times I've encountered Razbam having no plan at all or flat-out misunderstanding the source material far outnumbers the times I've encountered Razbam understanding a system well enough to have a long-term plan in the first place. I'm not going to argue that this isn't a game, but you expect a certain level of competence and program management skills even from game developers. I certainly expected a level of professionalism where constructive feedback coming from a place of a shared desire to see a better finished product wasn't met with hostility, but that's what happened. I agree that planes between FC3 and full fidelity have a place in the DCS ecosystem. I just wish people didn't have to find out after they purchased a full fidelity plane for a full fidelity price tag that what they actually got was one of these middle fidelity products. They should be advertised and priced as such.

I think they recently "fixed" the gunpod depression angle, and this has me wondering if doing so rotated the 3d model with it.

I don't think there is officially any stance that information needs to be specifically declassified in order to incorporate it. Plenty of SME input based on experience doesn't neatly fall into a level of classification, including "unclassified" (which is still a classification, and is not the same as not having a classification at all). In other cases, it is de facto acceptable that a Developer can make up stuff that doesn't exist in reality for gameplay purposes. We wouldn't have an ATFLIR or A-10C II or any of these modules at all if they didn't often make stuff up or approximate it heavily for the purposes of presenting it to a player in the first place. In Razbam's case, however, "it's classified" is absolutely an excuse not to include something, and a bad excuse. Remember, "it's classified" is not the same thing as "we've been asked by [licensor] not to include [feature/system]." First off, I'm pretty confident they don't have access to information that would fall into a level of classification above unclassified (colloquially "classified" information). Second, neither of these are valid answers for the systems people would like to see reliably functioning at a basic level (ARBS, CCIP/AUTO, Grid entry, HPI, or even things that have nothing to do with the aircraft such as complete keybinds and a HUD that shows up at all graphics settings). These were the issues a lot of the subsequent outrage spawned from, not whatever Prowler made up about non-existent concerns that they wouldn't continue to fix bugs after release. It's being spun by Razbam as if asking for a reliably functional module, and for the developer to honestly explain in clear terms 1) how far they intend to model systems that we presume don't work reliably because they are placeholders, and 2) how they intend those systems to work without needing to reference the real-world manuals, is not only asking too much but is an offense worth trying to erase from the discussion.

The important thing for me is that you get the desired effect, and the player isn't left grasping for answers as to why something isn't working the way they thought it should work. Some kind of feedback loop is necessary. Without an up-front manual or clear explanation of how the systems are intended to work, players only really have two options: the source documents or exhaustive trial and error. Both of those options are going to produce a ton of bug reports and complaints, either because something doesn't match the source documents or they have no way of knowing whether issues they're coming across are anomalies or things actually aren't working properly. If the explanation players are given for how something is supposed to work doesn't match the experience players have when actually playing, then there's a clear issue with the feedback loop. This has little to do with rivet-counting, although there are plenty of people out there who appreciate attention to detail. It's about managing expectations, and ensuring that the way you say something will work actually does when people go do it. What happens behind the curtain matters very little if you can accomplish that. If you don't want users to go to the source documents to clarify whether something is accurate or not and complain when it isn't, stop making the source documents their primary source of information for how to play the game; construct your module, manual, and tutorials based on your design document (if one exists in the first place) rather than those source materials; and stop dishonestly claiming vague levels of fidelity that don't hold up to basic scrutiny.

Tea, Is this something you want to wait until after the next patch to address too? Because this onion can get peeled apart into about 10 distinct bug reports depending on testing. - RCIP not functional in a dive - BCIP not functional in a dive - GCIP not functional in a dive - No difference between RCIP/BCIP/GCIP (that has been tested yet?) - "ARBS" calculations always supersede other modes in a dive - "ARBS" functioning without a designation - "ARBS" calculating release parameters incorrectly plus AUTO modes, needing testing... It would be really helpful for ELMO to let us know if this is intended behavior that all of these things are happening in their "ARBS" feature, or if this is a heavily bugged/missing feature (both are indistinguishable from each other to the end user) that they are intending to correct, not just "request."

I think we're inadvertently reporting multiple bugs in one thread, because we're experiencing so many compound issues. I think that there is confusion because so many compound systems aren't functioning as intended. 1) Action/no action functionality is missing in general (TACMAN I, pgs. 1-205, 1-280 - 1-281, 2-44) You are supposed to be able to slew the TDC in all directions, while holding it down (action) or not (no action). Slewing in "action" or "no action" has different effects based on the particular sensor selected. 2) ARBS/TV no action slew, without a designation, isn't functional (TACMAN I, pg. 1-202) With no designation, "no action" slewing the ARBS/TV is roll-stabilized. Pressing the action button (either momentarily or holding it down and slewing) creates and ground-stabilizes the designation. After a designation exists, "no action" slewing is ground-stabilized, but has a lower slew rate than "action" slewing and is used for refinement. It isn't recommended to "no action" slew onto a target for designation. The recommendation is to ground-stabilize first by pressing the action button, or fly the VV onto the target and then press the action button, but the capability should still exist to perform a roll-stabilized slew prior to a designation existing. 3) Slewing the DMT LST pattern, with or without a designation, isn't functional (TACMAN I, pgs. 1-200 - 1-202) https://forums.eagle.ru/showthread.php?t=285875&highlight=action I know you are only supposed to report one bug per thread, but when compound bugs prevent you from being able to concisely test the other, or can be confused as each other, it's not really feasible here.

Well, I'll say that the goal is that the procedures are used even in combat. There are reasons for them, often written in blood. Like Klarsnow said many pages back, Type 2 BOC has been bread and butter for many years now, even in combat. More often than not using procedures at all, I'm familiar with less extreme normalizations of deviance, such as shortcuts taken for poor reasons ("Lines 1-3 N/A" is a USMC pet peeve). Obviously there are situations in extremis like you're saying, but I wouldn't characterize those as the rule. Your first posts here implied you'd never drop on something you can't confirm visually and must have your head outside the cockpit or it wasn't CAS, which isn't really representative of a lot of our versions of "what really happens" and is why a lot of folks have chimed in.

If ED's JTAC is modeled for SADL specifically, then no, Harrier shouldn't be able to receive digital CAS briefs. If ED's JTAC is modeled for generic datalink, there's no real reason to omit Harrier's ATHS. In either case, Harriers within a flight should be able to share CAS information digitally.

This provides more context, but your previous post is still not representative of the wider CAS mission set (which you completely understandably might be unfamiliar with). Type 1 BOT with visual marks is often to "go to" for multinational situations where language and cultural barriers might exist, since risks can be mitigated through visual assessment of the aircraft's nose position. While you may not hear a perfect 9 line on the radio all the time, that doesn't mean the pilots and controllers aren't mentally checking off their list of what needs to get satisfied to safely and effectively get the desired effects and "get the job done." There's a whole other world of "heads down" CAS out there in the Type 2/3 and/or BOC world that you may be dismissing out of hand because they are intentionally hesitant to do it when working with coalition forces. I'm not going to say "Cowboy CAS" where you're not using the procedures like you're describing doesn't happen, but I've read enough AARs where it and its proponents have gotten a lot of friendlies killed for really dumb reasons to ever advocate for it or count it as "CAS" and not just DAS or half-baked fire support. I think we're victims of equivocation here.

Shrike, I think he's copied those notes out of the Pocket Guide and simply specified whether they were implemented yet. For all we know without further testing, we don't even really have an ARBS yet, so it could be why a lot of these other modes are on the backburner.

Yeah, I chose go through everything but archival is a close second. Don't delete them. They're useful for referencing back, since work's already been done identifying and troubleshooting issues. Deletion will be perceived as trying to intentionally hide something.

Tea, It needs to be understood that if this is intended behavior as a crude implementation of ARBS, then both ARBS and RCIP/BCIP/GCIP are incredibly broken and none of them function at all. You're telling us that there is functionally no operational CCIP on the aircraft without the ARBS locked onto a target, which means something is wrong or misunderstood. That has to be a bug report in some fashion. Do we make an individual thread for each of the non-functional CIP modes? Do we need to report the ARBS as both doing the math wrong (the bomb obviously failed to hit, where if ARBS/CCIP were being used it should have) and operating at all times, even when we are specifically asking it not to? If you were trying to turn the radar off in the Hornet and all your missiles and cues were behaving as though your radar was still on (and also missing those targets), the radar is broken, not a "crude implementation."

Unfortunately I don't think you can get around it without being honest and transparent about these things up front. Heatblur has gone to great lengths with their "dev diaries" about things like the depth of the F-14's INS modeling or Viggen radar simulation. ED has also done this in the distant past when they began advertising the Ka-50 and made short videos on things like the effects of wind on individual rotors (both FM and the model), bullet ricochet, and others. These things help dispel confusion about what to expect when you use the module. Many people, myself included, wouldn't mind all that much if certain parts of the game aren't fully simulated. I find it a little silly that AG radar got as much attention as it did considering how little an impact it actually has on gameplay or real world usage. Much like GBUs in the game have highly abstracted flight models that "fake" their real apparent behavior, I imagine a lot of the ARBS functionality, or even the IR hotspot detector, could be similarly faked, and as long as it was clear to the user how it was faked and what functionality to expect out of it (the fewer apparent differences to how it ought to work, the better), there would be little cause for complaint beyond a feature request. Would it draw some criticism for not being "full fidelity"? Sure. Depending on the system in question this could be a bigger deal to some people than others. But would it clear the air and help reduce the number of messages on discord asking when it will get "added" or "fixed," put a dam on reporting bugs for things that won't be added or haven't yet been added, and better inform the customer about what they're getting when they press the Buy button? Also yes. Being intentionally vague or uncommunicative about things, or trying to cleverly code them to give the appearance of correct behavior while claiming it is high fidelity, or hiding what you can and can't do through obfuscation or dishonest reasons doesn't help anyone.

It's my understanding that posting passages, images, or specific references to manuals are disallowed, but page numbers, general references, and paraphrasing is fine.