ChickenSim

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 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.

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.

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.

This is the least sensationalist summary of customer confusion and dissatisfaction that I've read so far. My biggest concern since the beginning has been the lack of good faith on the part of RAZBAM. I know they are passionate about what they do and take pride in their product, but this has turned into a bigger issue than it started out as, stoked by both their own missteps at just about every corner and some irrelevant customer outrage. They either deeply misunderstand or are being intentionally dishonest about 1) why customers are upset, 2) the reasons they aren't modeling certain things, 3) to what extent those systems are or will be modeled considering it is "feature complete," 4) that constructive criticism and requests for truth are not insults or inherently offensive, and 5) the narrative behind their actions these past few weeks. They have even attempted to censor me here by claiming (inaccurately) that I was under NDA (which was thankfully rectified quickly). I'm willing to grant them the benefit of the doubt there with Hanlon's Razor, but it is not doing their image any favors. I sincerely hope the new CM can address these concerns directly, and in better faith than their predecessor or Prowler. I'd like to see them, and a better Harrier, come out the other side of this.

Want to offer a correction that Force Correlate isn't missing. It's not a feature of the 65F, the confusion stems from us currently having a 65G instead.

Decoy, Pardon us for assuming it was implied that a request for a statement from Prowler would address the concerns that were actually raised. This didn't. It addressed a strawman argument that further indicates a misunderstanding on Razbam's part (see my post a page ago). There was no real presumption that moving the module out of early access meant it wouldn't be worked on anymore, and yet that is the area Ron is focusing on in what appears to be an attempt to discredit or deflect the point that it doesn't yet meet the product description. What is it, if not hiding on Discord, when Ron posts replies directed to me personally with screencaps of my posts here, to "focus on the facts" and not on a narrative, in the one place I wouldn't even be able to see if not for others letting me know? Ron's not being "crucified," he is being asked to take responsibility and be honest. That you and Razbam conflate these things is concerning.

Prowler, This is a good step in the right direction as far as transparency goes, but it's not addressing the core causes for concern here, which I personally view as honest communication and managing buyer/owner expectations. You have yet to address what it is you mean by "feature complete." As one example, your product description page includes "highly realistic modeling of the aircraft systems including [...] - Environmental Control System (ECS)", a system that it's my understanding isn't modeled at all. My point is not that a detailed simulation of the ECS is a necessary feature of a DCS product. My point is that your statement that all your features are "complete" either isn't true or we have different definitions for (which ought to be made clear). This is another area that needs to be clear to customers. I'll reiterate, a fully functional ARBS/DMT, fully functional CCIP/AUTO modes, a fully functional HUD, and fully functional coordinate input system (MGRS/GRID) do not stick out to me as falling under this umbrella of systems that you aren't "allowed to" model. This is, again, being used as an unverifiable excuse to be unclear about the level of systems fidelity we should expect and from which systems. This is literally the point I was making in the message I sent on your discord, in which I was banned without a word as to why (sorry, "parted ways") for trying to bring to light this very issue in a constructive manner (sorry, "for disagreements"). We're now full circle. These are the "bare facts about bugs and missing features" that a lot of us have tried, and apparently still failed, to get through to you. There isn't a narrative here to push about you "saying this and acting that way" beyond what I decided to come clean about after you thought dragging my name through the mud was a good idea (and I hope people note that he's not denying it, simply calling it out of context). We aren't really asking for a page of deflections about the details of DDS and SVG or of reiterated bug reports. We're asking for a statement on the issues I just described if you're trying to repair the bad blood it's easy to dismiss as "toxicity." Nineline/BIGNEWY, I know you both are sensitive to these issues too, and were receptive to clearing these things up in the previous thread that got closed. I don't think we've had that level of resolution yet, and it would be useful to know if we're going to get it.

Decoy, please don't forget the primary reason you were hired in the first place. Something to do with Prowler having an outburst and threatening legal action against redditors? Please do not try to tell the community that the "new coder" Razbam hired was for any other reason than to pull the Harrier kicking and screaming out of EA. I actually worked with one in a side channel for a few months in 2019, because you guys told him to talk to me, to parse through bugs and inaccurate systems modeling (GPWS, Navigation, etc.) that needed to get fixed for certain tutorials to be able to get released. Not any of the long list of outstanding bugs from 2017. No, those weren't high priority enough to even put on the list. Just the ones that were needed to be able to finally get Harrier "done", and the only time Zeus wanted to hear about anything else was when enough people went unheard on the forums for so long about issues like the ASL or CCIP-to-AUTO modes that it suddenly warranted correction (and if I recall correctly, people were banned for complaining about those, too). I still remember when Zeus said in May 2018 that he wanted the Harrier out of early access by June, and was happy if only half the training missions would be done by then. Does anyone remember how many features were missing in June 2018? That was the standard they wanted to ship with. Seems to be a pattern here, and you can't lay it solely at the feet of the behavior of the people on this forum in the past 6 months...

That is plausible and I'm not saying it's not a possibility. My underlying point, however, is that Razbam has been making broad, generalized assertions such as "the CAS page isn't used anymore" and "the switch upgrade happened in 2011 and only on Plus birds", which are clearly untrue at face value (but very well could be, for certain units or bases). I'd be willing to give them benefit of the doubt if they made those claims with the same nuance you are making Nineline, but declarative statements that X does or does not happen, Y is or is not used, and Z happened on a certain date aren't passing the sniff test. I'm not trying to die on the Course Switch hill. I'm trying to illustrate a point that Razbam isn't being entirely truthful and they could claim their SME said literally anything to get out of implementing any system as described in the manuals we have. In this case, it's a knob that began getting changed in the 90s according to publications (presence in 2001 documents with no change bar, indicating it was actually published in an even earlier document). What other cases does this apply to?

Bignewy, RAZBAM SME alleges that the change was made in 2011. Both 2001 and 2008 NATOPS indicate switches in both II+ and NA aircraft, and other SMEs pre-2011 have confirmed the presence of switches in Harriers. Can we get clarification that this isn't simply another unverifiable excuse to avoid a change? A source document perhaps? Proof of existence of a SME at all? Thanks.

IRL it is a 35-lb. trip sensor. When I brought this to Razbam's attention back in December 2017, they told me they intended to include this as a button press or modifier (they mentioned something like their Mirage solution for a similar "hard stop" there). I do not know how much of the DECU, MFS, or JPTL systems are modeled or simulated in high fidelity, beyond what they should look like in certain regimes.

Nineline, What you posted is pretty concisely the crux of the issue. As these missing functions get categorized as merely Feature Improvements or Requests, they ought to be held against the Store page's claims that the product features qualify as - "realistic performance and flight characteristics of a Vertical Takeoff and Landing (VTOL) aircraft" that is missing aerodynamic properties described in the flight manuals like jetblast impingement; or - "Highly realistic modelling of the aircraft systems [...] that includes" things like the Environment Control System (not modeled at all to my knowledge), VREST Computer (minimally functional with placeholder values), Electrical Power System (minimally functional with entire panels non-functional), and Flight Control System (with an AFC that does not function as it should); or - "Realistic weapons, sensor, and defensive systems" which omit entire weapons like the advertised GBU-32 and GBU-54, or strictly do not model some employment modes or simulate some systems with any fidelity at all. It is really difficult for someone reporting a potential problem to make the determination themselves what isn't working as a result of improper (or lack of) modeling and what isn't working because of an error or bug. This is going to be a recurring thorn in the side of both RAZBAM and customers without transparency about what and how systems are modeled, what is or isn't functional (and isn't planned to be), and what customers should expect going forward.

Not important, but in point of fact the BIT page isn't classified. The lines were written in the script for Tutorial M02 and to this day have a big "NOT MODELED YET/NEEDS TO BE MODELED" flag on them, along with 15 other items from that mission alone including JPTL tests, igniters, MFS tests, fuel panel BIT, MPCD DAY/NGT and brightness function, UFC BRT function, DC Test, SAAHS logic testing, DP testing, RJPT/RHOV testing, and Antiskid testing. How many of these things have since been fixed from a single tutorial mission, I couldn't even begin to say. I'll try to use them to inform which functions are missing but some may legitimately be out of scope.

This does make sense and this isn't in dispute. What is in dispute is that an as-yet-undetermined amount of missing features and bugs are being swept under the rug using classification as an excuse not to model something appropriately, simply because the truth of this claim is almost entirely unverifiable but is often accepted as a sufficient answer out of hand. Actual missing features like dive-toss delivery modes, ARBS wind correction, and MGRS/GRID coordinate entry (nowhere near an exhaustive list), all subsets of "realistic weapons" listed on the store page for Mk 80 series ordnance and GBUs, aren't things that I think fall behind that curtain.

I got banned on their discord today for calling them out on their public excuse that the Harrier is feature complete, and that anything incomplete is either because the Harrier is so realistic that pilots have approached them asking them to fudge it or is merely a bug. For the record, that's a lie. I wrote their tutorials for them and I know that there was no design document or directive scope and I have about 3 years of experience dealing with their inability to take constructive criticism. @Nineline, please factor this into your guys' conversations with them. The issue isn't just that bugs have gone 3+ years without being acknowledged in some cases, or are being erroneously marked complete. There's a whole other element to this that they're actively trying to deflect by deleting messages and banning people (even contributors like me), and that is what constitutes "highly realistic modeling" of aircraft subsystems and what is considered "feature complete." The disparity between what they consider these things, what ED considers these things, and what the public considers these things is the problem. When expected or advertised features are missing and not merely broken, how can that be "feature complete"?

The 100 isn't probability of hit. It's physically how far into the release window you are.

What I mean is that before there wasn't necessarily any feedback indicating where the pilot should point the nose, if they were employing from a distance great enough that they couldn't easily visually identify the target in the first place. You greatly increase your odds of the weapon detecting the spot if it's launched directly toward the target and not offset an appreciable deal left or right. I don't know if the Huey had an organic markpoint system as it had never employed PGMs before this (to my knowledge), but CAS procedures required us to either read back the coordinates as they were entered in the system and shoot at those, or be tally/contact/captured the target or mark to employ on before obtaining attack clearance. During the day, it was difficult for the helos to do the latter and obtain a tally from X kilometers out, so we would coordinate some other kind of visually significant mark (like smoke) to give the pilots something to aim the ballistic reticle at from afar. At night, we could Sparkle and shoot the designator at the same time, so this was helpful.

New sights and software increase the effectiveness, but the weapon ought to be a bolt-on upgrade without other software requirements at a bare minimum. When we initially fielded APKWS and started doing offboard lases, the Hueys had no aiming cues at all. This meant our ideal usage was at night where I (the buddy laser) would be firing both the designator and the IR pointer at the target simultaneously, so they would have something to orient the nose on. Daytime employment was more complicated, and would often require an additional mark to give them a stake in the ground.

I'm not an HMI engineer so I couldn't tell you why, but that description is proof enough. Note that it says when the function is selected, it does the thing. It doesn't say it stops or arrests the thing when pressed back to NORM. Nor does it say it stops or arrests the thing when released, or only performs the thing when held down. I assume it is 3-position because there is auto-extension logic under certain flight regimes, and it would be technically inaccurate to have the switch in the IN position while it's automatically extending for whatever reason. In addition to that, I've confirmed with pilots what the appropriate behavior is. They "fixed" this at the behest of a bug report asking what the correct logic is, and didn't do their homework prior to jumping the gun.