Super Grover

I thought that to give you more context, I could share an example of what is the level of detail at which we work when we model and code the aircraft. Let's consider the AN/ASA-32 Automatic Flight Control System, on which I worked together with @Cat107. In one of the documents published by NASA and publicly available, you'll find this formula: We managed to identify the resistors and capacitors responsible for that 0.5 damping factor - and actually, it's not precisely 0.5, but if you round it to one decimal digit, it will be. However, we don't model separate RC elements in the code, and we represent them as a single 'canceller' component with a transfer function - just converted to a discrete one - as in the diagram. This yaw rate canceller, together with a pitch rate canceller, and multiple other (electronic) devices such as servos, synchros, amplifiers, relays, switches, rate gyros, accelerometers, and power supplies, forms what is designated as AN/ASA-32. I think the step between an RC element and individual resistors and capacitors is where we want to draw the boundary of our component simulation. Finally, as I wrote in another topic that is now gone, we are open to sharing the tech with our current and future partners, which also includes benefiting from access to the constantly growing library of components.

The answer to the question is a bit complicated. Currently, there are no servos in the HUD code, but this is because the HUD code is one of the oldest parts of the simulation and requires upgrading to the latest standards. However, we try to implement individual parts, as shown in the diagram, including individual servos, whenever possible and if it adds any value to the simulation. It also means that the HUD will be upgraded to this standard sometime during the EA period. It's worth mentioning that since all our modules will eventually share a common library of components, any updates will be automatically available to all of them. This means that whenever we improve the simulation of a servo, such as adding more details or new failures, all devices in all aircraft using that servo will get automatically updated. This effectively means that our plan is to keep the modules updated with the latest technology even beyond the early access period.

@hermes7226, thank you for your feedback. We don't access any input device directly - every input we receive comes from the DCS API. I mean that, from our point of view, every joystick axis is the same. Could you send us your log file from the F-14 with your vjoy, please? Have you informed Eagle Dynamics about the issue? Of course, if there is any type of bug preventing you from using your vjoy, we will do everything we can to fix the issue.

As previously mentioned, a separate development report is required to fully cover the system of wear, damage, and failures. However, I would like to address some points to clarify potential misunderstandings. Firstly, when we began the F-4E project, we decided to establish a stable foundation that could be shared across all Heatblur modules. As a result, we plan to transfer new features to older products, starting with the F-14. However, this process may take some time. Secondly, we aimed to create a flexible and extensible system that could be developed and maintained for several years. We even considered future potential base simulation platform development scenarios and ensured that we could utilize their full potential in our product. This means that there are some features that cannot be implemented in DCS currently but may become available later, even beyond the early access period. One of the key features is the ability to save and restore the state of each component and the entire aircraft at any point. Yes, this means that persistent airframes in various forms are technically possible. However, we need to better understand how to blend it with gameplay features for the best user experience before we can promise anything. Our aim with these systems was to create realistic, immersive, and entertaining experiences for all users, whether they are casual or hardcore. We considered all use cases, including those in the competitive scene, and welcome feedback to ensure our products are enjoyable for everyone. Each feature comes with various settings to allow you to adjust them to your liking. Now, let's move on to the technical details, which I have listed to make it easier to follow. We use general terms like 'wear', 'condition', 'property' and 'failure' to abstract information about the aircraft. Still, their precise meaning is interpreted at the level of each component individually. As mentioned in the trailer, the F-4E is a collection of thousands of components. Each component is unique and has its own set of properties. Two components at the same level of wear will be slightly different. Some examples of how those properties can manifest in the aircraft: two tachometer gauges may have different accuracy; two pumps may have somewhat different effectiveness; pressure at which a check valve opens and closes will be different from valve to valve; etc. Each component accumulates wear independently. The rate at which it wears out may depend on various factors, such as extreme forces or temperatures. Each component has an assigned condition/quality. This value represents the combined quality of manufacturing, materials used, and maintenance. Component properties are affected by wear and condition. Wear and condition can be assigned per airframe by the mission creator. Components may fail, and each component may fail in multiple spectacular ways. Failures are an additional layer to the wear layer. Wear and other factors, such as damage from weapons, extreme forces or temperatures, may impact the moment when a failure occurs. Failures can be gradual; for example, a seizing-up motor or actuator may, at first, require higher forces to move and eventually stop altogether. Failures are NOT rolling a dice every second. However, we take into account all available sources describing what is the rated lifetime and approved failure rates. The total number of already defined possible points of failure in the F-4E is counted in thousands. Last but not least, if, for any reason, you want to deactivate all of the above, you can select 'reference aircraft' in the mission editor. Your F-4E will have all properties standardized, factory-fresh and in perfect condition. In summary, we wanted to make the F-4E feel organic and unique each time you fly it, and we hope you'll enjoy all the new features.

I fixed replays for the F-4 some time ago, and they work like a charm, yay! Sadly, it's not easy to apply the same fix for the F-14, so it will take some time before the changes are applied to the F-14.

After posting, I realised the picture is a bit small. So I used zoom-enhance (I mean Gigapixel AI) and magnified it 3x with the default settings, so it should be easier to view on smaller screens.

Oh, pixel counting - my favourite job! (Actually, I'm almost crying thinking about those hours spent measuring all elements of the LANTIRN display from the available videos.) So, this is tricky stuff because we have almost no footage of how it looked in the cockpit, and everything comes from the videos like the one above. I don't know how they got those recordings, but it seems like recording through a VHS camera footage played from another VHS device. I mean, the quality appears to be much worse than the original feed, everything much more blurry, not to mention the stretching from the aspect ratio difference. So definitely, nothing is blocky (even the symbology) because we're watching it through grease-covered glasses . It's so bad that I struggled with deciding if some symbols were single-pixel or double-pixel width. Finally, the shots from the EXP view are pretty rare. I guess the crews didn't enjoy the digital zoom (TBH, I never use it when I fly). But the Fighter Fling 1995 video has some, and I took a screenshot: It is blocky - the smallest squares are double the size of the font pixels. Ofc it's also very blurred - so much so that reading the text is difficult.

The plan was that the initial release version (non-DMAS) would be smokier, and the DMAS version would be the version after the upgrade, so the less smoky. OFC, everything is subject to change™

Thank you for your reports. I verified the tracks, and the bug is not related to the SA-5 but to two tracking radars positioned next to each other. The tracks helped me find a bug in the RWR threat association algorithm, and it should be fixed in the next patch. Again, thank you very much.

Thank you for your reports. GBU-24 bombs use a different type of steering/profile than the other laser-guided bombs available, and their time to impact depends heavily on the conditions when released and when lasing starts. We measured the difference, and we adjusted the calculated TTI to make the numbers closer to the bomb flight time when lasing immediately after the release. Also, we educated Jester to start lasing right after you pickle when using GBU-24. These changes should be included in the next update.

Thank you for the reports. It's fixed internally and should be included in the next update.

Thank you for your reports. I'll check it with the debug tools, and I'll get back to you when I know more about the reason for the freezes.

Interesting, I'll take a look. I remember it worked when I tested queuing entering more than one waypoint, but it was long ago. I'll let you know about the results. Thank you.

Yes, on the DSCG, I thought about the displays as that is how I understood the discussion above. The rest, I think, I answered in my first comment. Yes, we want the DSCG aircraft to have Pave Spike, and yes, we're thinking about Pave Tack for DMAS, but it's too soon to say that it's going to be there for sure.

Both versions will be DSCG, but as far as I know, TISEO wasn't retrofitted to blocks 36-45. And the DMAS? I hate how the TISEO camera looks, but I guess we would never forgive ourselves if we didn't attach that ugly cylinder to the left wing.

We plan to equip the "classic" (Blocks 36-45) with the Pave Spike. The DMAS version is too distant to discuss it now in detail, but we are thinking about creating the Pave Tack for it. However, it's too soon to consider it a promise because it depends on multiple factors. I just wanted to write that it looks like we, the flight sim enthusiasts, think very much alike, and we dream about the same things.

Thank you for your reports. I tested entering home base on the ground and an aircraft carrier, and I couldn't reproduce your described results. Could you provide us with more details, like the mission, screenshots, or a video?

Good catch, thank you. Noted, and it should be an easy fix. Unfortunately, it's too late to include it in the coming update, so I'd expect a fix in the first update in 2022.

We reviewed the available sources and diagrams very carefully again, and we found that the data flow from the AHRS to the CSDC and then to the VDIG doesn't even need the WCS to be powered. In other words, when the INS is off, the VDIG (VDI + HUD) uses attitude and heading data from the backup source - the ARHS - which is always on.

Hey kievbsm, Re 1: POINT track requires targets clearly visible against the background. If there had been many objects in your view, the pod might have had problems tracking them. It's difficult to say without seeing the feed from your flight. Re 2: yes, POINT requires WHOT to engage. You can switch it to BHOT after the pod establishes tracking. A general note: if the target is not moving, one should prefer selecting AREA over POINT as AREA is more reliable.

We are considering adding other methods of controlling the pod in the direct head control mode, but on the other hand, we don't want to make it just another pilot controls for the LANTIRN mod.

As I explained before, Jester automatically switches between WIDE and NARROW based on what mode he finds optimal for the current situation. Since a big part of his logic is built around this system, we don't plan to change it significantly at this stage.

Yes, now it's 100% exactly over the line and outside of the circle. I proposed that I move 100% a bit away from the edge towards the centre (so you can still easily hit 100% and not 90%+ ) and null the rate outside the circle.

Ah, but it already works that way. The distance between the centre of the VDI and the dot is proportional to the slewing rate. So the closer the dot to the edge of the big circle, the faster the pod is moving.

Thank you for the suggestion on the "pickle" call. We will tell Jester to be less excited when the release cue reaches zero and that he should check the other parts of the display too. On Jester checking what is outside, he should be more focused on the LANTIRN display when he tracks a unit or during bomb runs. Otherwise, he will try to maintain situational awareness.