Leaderboard

Thank you @Abburo and @Timex3 - and everyone else supporting the development! Status update Weapon issues with DCS 2.9.5.55300 As you remember, there are currently two issues at hand. 1) Affecting all SAMs using TVC - making them go haywire and flying everywhere All affected missiles in all the affected country packs have been fixed. We are running final tests now. 2) Affecting all missiles using the old DCS missile parameter set - making them fall short of the intended target As I mentioned before, this issue is a bit more tricky as it can't be reproduced with DCS core units (as ED has migrated all their weapons to newer parameter sets), and therefore we can't submit a proper error report to ED. I'm working weapon for weapon to see what I can come up with. I'm currently working on the guided 155 mm shells and think I have a viable solution. Here's the preliminary list of assets affected by issue #2: HIMARS ATACMS HIMARS PrSM HIMARS PrSM antiship HIMARS GLSDB HIMARS GMLRS M270 GLSDB M270 GMLRS M270 ATACMS M777 Excalibur B-21 AGM-88G DF-21D PCL-181 GP155 Type 055 YJ-21 Iskander 9M723 Grigorovich Frigate RBU-6000 Artillerisystem 08 Excalibur PzH 2000 Excalibur

Hi @Snappy, I'm the developer of the FM of the F1. The combat flaps significantly improve the sustained turn-rate at low speeds (which is easy to test). Obviously, the trade-off is less acceleration at those speeds. In general, in a dogfight in the F1 you want to stay above 400 kt, especially against the DCS F-5 and MiG-21 so ideally you wouldn't enter the combat flap zone of the envelope, but if you do and you can't extend away, then absolutely deploy combat flaps. This is my feedback as the person that looks at the data, I'll try to ask an irl pilot to give you the point of view of someone that has actually used the aircraft and has been trained on it.

Congratulations on the Phantom release but party's over - can we get back to regular updates and bug fixes? Tomcat has been put aside for too long, not nice.

This is the critical point here that I made earlier. When producing compensation for non-FFB users, the general outcome of control smoothness and accuracy should be similar or better than the outcome of users flying with FFB. Otherwise, you end up simply punishing a user for not having expensive hardware. The strength and dampening effect from the arm of the virtual pilot needs to be able to hold the virtual stick firmly as would someone in the real aircraft, or in the sim with a correctly recreated FFB system. According to mil standards, the forces produced by that stick, including those by momentum of the weights, cannot exceed certain values to prevent control difficulties like this, and thus, the aircraft doesn't kick back very hard. What we should be feeling is approximately what we feel in DCS simulated with FFB, and we are able to hold the stick quite firmly in that case and the sim correctly represents that. The problem is the weak pilot arm for non-FFB that cannot hold the stick as expected. The loose grip allows for a larger expression of the force feedback without the expected compensation. Based on a little bit of data logging at various speeds showing consistent and smooth response frequencies at all deflections including center, I assume most all of this reaction is coming from reaction-torque about the bob weights. As you shove the stick forward, you are not just attacking the force of the weights, but also adding rotational kinetic energy. Bringing the stick to a stop while in motion thus requires extra torque. This is easy to feel and counter with and FFB stick but the non-FFB simulation lets it pass and this is what turns into the unwanted oscillations you see that you also can't easily counter. This is also why those oscillations occur at every position, not just center, but are likely exacerbated near center due to how most non-FFB sticks "snap" as they hit center. For people with extended sticks, this may be less apparent as the stick may often not be moving as fast, thus less kinetic energy stored before coming to a stop. The drop in oscillation amplitude I'm seeing after turning on FFB drops around 90% ish, even though my accuracy to bring the stick to a perfect center with FFB is a little more difficult. That is a big difference. The fix for this problem is straight forward: Fly the aircraft in such a way you can enable and disable FFB, record the pitch response, Increased arm strength and dampening when FFB is disabled until it starts to match the results recorded with FFB on. I grabbed stick position and recorded data with and without FFB enabled in the game settings. This can be done through export lua using the code testfile = io.open("B:/Users/username/Saved Games/DCS.openbeta/Logs/FlightRecord.txt", "w") if testfile then testfile:write("Log Start") end function LuaExportAfterNextFrame() local Controls = GetDevice(0) Controls:update_arguments() local pitchCommand = Controls:get_argument_value(2) -- was 3002 local pitchmessage = string.format("%.4f\n",pitchCommand) testfile:write(pitchmessage) end function LuaExportStop() if testfile then testfile:close() testfile = nil end end And this is the compared result: I start at 400 kts IAS conditions and simply pitch forward and back over and over. Notice how the squiggle at the end of each pitch command change is much smaller when using FFB. This is because I can fight the force response physically. Without FFB, I am not allowed to do it and the pitch oscillates.

Here's what I'm talking about. The behavior is there at all speeds and weights, varying at bit of course with aerodynamic damping, loading (on the plane) and moments of inertia, I'm sure, but all showing the oscillating stab. It is nothing to do with roll input. By unload after pull, I mean move the stick (and stab) back to its original trimmed position before the pull while still gripping the stick. I am not referencing roll reversal -- nobody in this thread mentioned that. I am using a VKB gunfighter with a 200mm extension and 2x #50 springs on each axis for a total of 4 with the soft center avia cams. It is the heaviest feel I can get on my stick. Like you, I crave a heavy stick because heavy control forces are what I'm used to IRL. My stick is center mounted, I typically don't rest my arm on anything, but as you can see from my flying of the other modules and my control indicator I have no trouble being precise with it. I was using a curve of 15 in the video, but started initially with 20. Apologies for the first few seconds, I was trying to show that in-game stick was locked to my inputs while pulling, but my lower FOV was cut off by the VR mirror.

I’m not sure if some of the commenters here understand how flight control systems work in a non-reversible hydraulic system typically found on conventional control tactical jets. In such control systems, the pilot never feels aerodynamic loads on the controls, nor are the weight or balance of the controls themselves transmitted to the stick . Sitting on the ground where the aircraft can’t generate more than one G, a pilot displacing the stick from its neutral point only feels springs, bobweights and friction. Those forces get heavier in the air only as G loads are felt on any bobweights in the system. Most of such systems move the stick during trim operations. Inputs such as Mach trim, or an integrated trim system inputs that independently offset flap, speedbrake and auxiliary inputs like DLC engagement or actuation generally don’t move the stick, nor do stability augmentation system inputs to the flight surfaces. For a sim player with a spring stick controller, the physical stick’s location frequently doesn’t follow the virtual stick in the game. On the ground for instance, in the F14, F5, F86, etc, if the player actuates the pitch trim only without touching the physical stick, then the virtual stick will move on screen, but the player’s physical stick doesn’t. The two are out of synch, so to speak. Another is that the physical stick has a symmetric throw in all axis, but the real aircraft don’t, with the neutral point well forward in the arc, so that more aft stick throw is available than forward stick. The F14 also has a physical pitch curve already built into its system, so you can see that the module’s virtual stick doesn’t follow the player’s physical stick in a 1:1 fashion. For trimming, the only force available to produce an out of trim force is the spring in the stick. So as the player trims out those spring forces, he must concurrently move the stick opposite the trim direction. You can test this in the aforementioned aircraft by trimming at 500 knots, then slowing to 150 knots without trimming. Note the trimmed stick position at 500 knots against a reference point on the instrument panel, then decelerate while the back pressure against the spring. Note a reference the stick ends up. Then trim out the forces to maintain 150 knots. You will notice that the stick is in the same place with respect to the instrument panel, but you have unconsciously moved your physical stick to back to its center, neutral spring position. If you don’t compensate, and hold your physical stick fixed in position while trimming aft during this exercise, then the virtual aircraft will enter a climb. The F-4E behaves the same way during this exercise, the only difference is that the stick moves slightly with trim inputs, which manifest just like trim inputs in the other jets listed. I’ll let Grover explain the F-4E pitch control system, he’ll likely blow your socks off, but hopefully this background information helps clear up the nuances and limitations of real trim vs virtual. You can put me down for one of the guys who finds the F-4E solid and easy to fly because of its emulation of the bellows system. It’s very pitch stable in holding a constant G, and I’m not seeing any of the behavior you’ve describe during roll reversals (which I checked again today in a variety of conditions). I would add that I have a WingWing base with a 120mm extension, with the heaviest springs I could find and a pitch curve of 12. This provides a more familiar feel as I’m used to much higher stick force per G than most stock controllers provide. I’ve found that it makes tanking, carrier landings and trimming straightforward.. I was pretty comfortable in the F-4E module straightaway. It trims and flys similarly to a grossly overpowered A-4, but believe it or not, the A-4 was more sensitive in pitch and roll than the F-4E.

HB people here, who are “against” your stick to nonFFB joystick linking, are very much educated and completely understand what is going on with the system itself, and glad you’ve got a deep dive into the simulation of it’s proper work. Please try to hear what we keep saying. There is no problem in system simulation! And it works like it should (well almost) but benefits of the simulation are only could be seen on FFB devices or real aircraft. Spring joysticks require adaptation of this simulation to work in proper way. That’s it. Do you understand that simple statement? All of these kind gentlemen here not only bought your module appreciating by this all of your hard work, but spending a lot of their’s time providing you very qualified feedback and support for free.

This feature is coming. Altitudes too.

This is unequivocally, undeniably false. The virtual stick moving about uncommanded by the player in pitch is directly representative of the virtual horizontal stab moving about uncommanded. You can see it for yourself in the external view. Since the stab is also moving and altering flight dynamics, this is in no way "only visual". This is happening because the player is not directly connected to the control loop via the stick as they would be in real life, or indeed in other more properly modelled non-FBW modules (including the F-14). No, leaving it centered means the stick is centered! The sim cannot possibly know whether or not the springs are holding it centered, or if our grip is. Traditionally linked flight controls behave just the same on the ground in the absence of dynamic pressures over the control surfaces as the F-4 should -- the elevators or stabs will droop under their own weight and the stick will usually slump forward against the stops. That doesn't mean you can't move it around freely -- quite the opposite, as it can be far easier and lighter to manipulate without any load -- you're just lifting the weight of the control surface itself. In the game currently on the ground and at low airspeeds as in the video posted, the stick flops around as if nobody has their hands on it, and when you do try to manipulate the stick to set a desired control surface deflection, your inputs are in essence run through a ridiculous filter that ends up flopping it around every which way. This is in no way realistic! This is completely misrepresenting what @Maksim Savelev was saying, and in fact leads me to believe you are the one not understanding how control inputs work in real aircraft. As pilots, we use the control stick directly to set a desired deflection, which gives us our desired attitude -- we do this IRREGARDLESS of forces felt through the controls. If we want to sustain that selected attitude for a period of time, we'll only then trim out the force. You have broken this basic principle with your stick modelling for non-FFB users and made it impossible to smoothly and accurately set desired pitch attitudes without a whole heap of extra slop that shouldn't be there. I get it, you were trying to convey a "feel", which is great. You have done similar things in the past with the enhanced buffeting and aural cues in the Tomcat. But this time you have actually broken the most primary flight control loop in a very real way.

Just had to make this video

Fausete has explained this very weel. Normally we use to deploy combat flaps provided combat was below 300 KTS, especially with nose high looking for flat scissors or trying to overchute the opponent. Good technique, although below 300 KTS with nose down accelerating, is deselecting combat flaps to increase acceleration looking asap to be above 400/450 KTS. Enviado desde mi SM-G981B mediante Tapatalk

First, we'll ship our hotfix which should improve radar CPU performance impact - then we will circle back and try to find these hotspots for everyone.

Is the plane's nose oscillating up and down in reaction to the stab going up and down only visual??? I'm sorry, but what?? I am really struggling to understand the disconnects here (both in the discussion, and in the F-4's virtual flight controls). It's not only the case on the ground -- watch the end of maksim's video at 15:45 as he lets the plane nose over close to the stall. His physical joystick is centered, yet the stab and in-game stick are fully forward. Pretty sure he's in the air there! I don't want to get used to it because it is broken. It does not fly like a real aircraft in this one critical regard. I get that you do not want to accept that assertion, and that's your prerogative as well. I also get that most players don't know enough to understand what's going on as they don't fly aircraft in real life. Maybe one day, if they ever get a chance to learn, they'll understand that they sometimes actually have to push back against the controls in order to make them do what they want.

To the first point: Not sure how often we need to repeat that the low pass filter is only visual. Apparently you know our code better than us. We also said repeatedly that you will get a smoothed animation setting it 1:1 To the second point: As explained this is only the case on the ground, because friction cannot be emulated in DCS. It does not apply, when airborne. To the third point: it is impossible for you, maybe, but the far majority seems to have no problems with it, including our SMEs, who are happy with the FM as is, and further fine tuning will be done based on their feedback, and theirs alone. I get it, you do not want to get used to it and learn to fly it, because you disagree with how it is modeled. That is your prerogative. Just please don't expect us to change and re-code our FM and stick simulation to accommodate a minority, who does not like it. I can understand the blowback, what I cannot understand is not giving yourself enough time to learn how to fly the F-4 with precision as is. If most of us can, there is no reason why you wouldn't be able to either. I can only invite you again, to do so. As predicted, we are turning in circles, so please forgive us, if we move on from this discussion. As promised, we will have the thread that explains the simulation up, once we have time for it. If you want to revisit the topic then, we'll be happy to.

Hello everyone, My name is Krzysztof Sobczak (some of you may know me as “Grover”), I am the Technical Director at Heatblur. Although I haven't been very involved in direct communication with our users because I have been focusing on working hard on our projects, today, I am excited to share some technical insights about our latest release. As some of you may read from me for the first time, I'll start with a short introduction: I am originally a physicist holding a PhD in particle physics. However, most of my professional life has been dedicated to developing flight simulations. I have had the privilege of working with companies like A2A Simulations and Metrea. In 2018, I joined Heatblur Simulations to work on the F-14 Tomcat. During this project, my areas of responsibility included the communication and navigation systems, the LANTIRN targeting pod, and JESTER LANTIRN. In 2021, I became the Technical Director to create a new core system - codename Anvil - a genuinely new-generation simulation platform. Having been involved in creating several flight simulation engines throughout my career, I have gained a deep understanding of the requirements for such engines and the shortcomings of existing solutions. This extensive experience has been invaluable in shaping the form of our new flight simulation platform, which we present today through the release of the Heatblur F-4E Phantom II. Our users may already be familiar with the innovative approach we applied in the F-4E Phantom II, particularly the concept of the components system. For those with programming experience, this might initially sound like a marketing trick, similar to object-oriented programming and using objects through composition in different contexts to build complex structures. However, there is much more depth to the system we created. Our approach goes beyond simple object composition and reuse. What sets our system apart from other solutions and programming techniques is its orientation around data flow. This focus is crucial for creating a system that is both reusable and granular enough to build entire aircraft and reuse components in other aircraft or systems. The challenge in making such a system lies in the uniqueness of many aircraft devices, so to achieve true reusability, we had to reach deep to a level where components can be generalized - the level of individual switches, relays, lamps, amplifiers, actuators, valves, and all other kinds of low-level components. By focusing on the components and the data flow between them through the connections, we managed to move all non-simulation elements outside the components and let Anvil handle them. The first core aspect of our F-4E Phantom II, driven by our engine, is its multi-crew capability. The component connection approach allows our developers to focus entirely on creating the simulation part of each component. At the same time, the system handles the communication between different components and distributes it over the network. From the developer's perspective, there is no difference between developing an aircraft simulated entirely on one computer and an aircraft whose simulation is spread across multiple computers. The second feature unlocked by the component system is multi-threading. By strictly separating components from each other and not allowing them to access other components directly, we ensure that the simulation part of each component can run concurrently. This approach means that developers do not have to worry about the complexities of multi-threaded development and can work as if the simulation of each component were entirely single-threaded. The connection system governs the rest — it de-conflicts multiple simulation threads seamlessly. It is important to note that while our system is designed to support multi-threading, this feature is not enabled in the version that users are receiving today to limit the risks of the adverse effects for the premiere of such a complex aircraft. However, multi-threading will be enabled in future updates, offering a significant boost in performance for everyone. Also, note that this is not the same as using the multi-threaded version of DCS - the multi-threading part of our component system adds another layer of parallelization, effectively offloading the aircraft simulation from the main DCS thread. The component system is oriented toward providing developers with the tools to create new components quickly and efficiently. With those tools, we can focus on recreating components' real-life properties and giving them an organic feel by adding imperfections, individual characteristics and failures that can occur as a natural result based on the treatment of the components. Later, we use those components as bricks to build the aircraft in a fully synthetic way, while Anvil makes each airframe unique and each flight a new adventure while giving virtual pilots an incentive to not mistreat the aircraft. Finally, we plan to use Anvil and the same library of base components in all our future products, retrofitting them to the already published products where applicable. Sharing the same code will ensure that all our future aircraft will be automatically updated with our latest achievements and changes introduced to the system while developing any new product. This means that from now on, our simulation can only get more profound and more realistic. After introducing key features of the component system, let's delve into some statistics about DCS F-4E Phantom II. The total count of components used in our simulation, as in the final build provided to Eagle Dynamics, is 6,389. We used 14,627 component connections. Out of these, 2,297 connections are synchronized in multi-crew. The total number of properties across all components is 34,964, with 25,032 of these properties synchronized in multi-crew. Many of these properties are randomized and depend on the wear and condition of the aircraft. Finally, the total count of all damaged states in the aircraft is 1,562. While this number is already high, we plan to implement many more new failures during the early access period. Some of you might be concerned about the costs of creating detailed products like our F-4E Phantom II, which could negatively impact the entire market. We never intended that, and we are confident this won't happen. First of all, our goal was to make the development of complex modules less expensive by improving the reusability of the code and offloading most of the low-level and repetitive development to Anvil, which will handle it automatically. Furthermore, we are part of the flight-sim community and want the study-level flight simulation to thrive. From the first days of this new platform, we shaped it in the form of SDK, which we want to offer our partners. This includes the entire library of components and JESTER. We believe that cooperation and fostering synergies is more creative and profitable than non-amicable competition. As you will be able to experience the F-4E Phantom II for DCS yourself, I hope you will enjoy every minute spent in our recreation of this magnificent aircraft. On behalf of the entire team, thank you for the support and excitement you express daily through all communication channels. Have fun!

What is the problem for developers to make “stop holding the stick” a disabled option? I don't understand this forced promotion of their "achievements" in the simulation. The “everyone likes it” argument is not relevant, I am sure that the majority are don’t know because they have no real experience in flight. — sry for my English

While I appriciete the work you have done I must say I do not agree with this reasoning. The trend of developers including all livereries that there were and those that did not has way more impact than just space. We see a trend where you will be expected at some point to replace your PC every 2 to 3 years which can be expensive and not sustainable for majority. We are not talking here just disk space: cpu/gpu/ram also play significant role here. I have already seen very devoted people drop off the scene. Ultimatly its a difference between being a niche and mainstream game. Therefore its actually very important for ED to keep the base footprint of this game lower, so the user base can expand. I can not see anyone in sales want to shrink the userbase of the products. In most cases you will never see these the liveries in the first place, unless you cycle them through F2. In addition even if you can afford to "race" and replace your PC every year, the more money you spend on PC, the less money you will spend on modules, maps and other content. Therefore I do believe the DEVs need to think hard about optimizations. E.g. have at least basic pack with few high res liveries and rest low res. If someone wants it let him download the full pack. This is just one way to do it. Other possibility is to implementing LRU livery cache.

I deleted the reply because I wanted to check something specific before re-posting it and subsequently got ill later in the evening. Nothing nefarious going on except busy developers and getting pulled in many directions. Apologies! Our privacy policy is linked directly from our site, as well as linked from the EULA in the game folder. As mentioned in the other thread, since there seems to be concern about errant http requests, we'll add a new safeguard for ensuring there is no connectivity whatsoever. There's absolutely no aggressive telemetry or malware delivery happening, at all. One of the google fonts was left in the manual which has since been removed (hence it was pulling it from Google) and as noted in the privacy policy, we only have a user counter otherwise. The font-fix should be available in the hotfix, apologies. As noted in the other thread though, our UI will never rely on any online features, so we'll add a fully offline checkbox to inhibit any HTTP requests to inhibit any and all connection requests. As a stop-gap it should work totally fine to just firewall HeatblurUI.exe off entirely. It actually shouldn't; this may be a bug. I will look into it as we want as little CPU overhead as possible since the aircraft itself is very complex. When any UI element is closed, it should be mostly sleeping, and thus use very little CPU resources. We do have to periodically ping some of the UI elements to keep the JS ticking; but it shouldn't incur that much CPU usage.

Dear friends and pilots. We apologize for map update delay, this will be a good lesson for us in the future. We are confident that the update will be released soon, we are working hard on it. But rest assured that we read feedback and look at new bugs and improvements from users. We are preparing not just an update that will fix most of the bugs, but massive map improvement that provide more flying options and adds new visual content. We have already finished modeling airports and unique objects that were announced before. Now we work on unique scenes and map optimization. Most of the time is spent on small improvements and bug fixing, although globally it already seems that everything is done. For every small update, it is necessary to build the entire project and update must be approved, then users need to download it, this is inconvenient in our opinion. That's why we decided to release Phase 3 along with the bugs fixed, but we didn't take into account the time factor, which goes by very quickly. Thank you for your patience and support.

This is great and probably the best counter argument to anything I've brought up. The problem is that when talking about control forces we start getting into fuzzy territory with regards to modelling it on a non-FFB stick. As mentioned, you can control the behavior with an FFB stick, but can't with a regular spring loaded one. This would mean our virtual pilot ends up being endowed with a comparative wet noodle for an arm.

Success of Firing Fire and forget medium range missiles Build SU-57 Felon-A Standalone Progress.

Its not happening with FFB, I can confirm that

Actually we need to investigate if a bug, really. We currently think it may not be, the oscillations are mentioned in the manuals, and the advice is to kill them by changing speed immediately. We're currently looking into it with the SMEs. Another way to override it, is to use slats out or slats override if prolonged flight at such a speed, where it occurs, is planned. Thank you that is a good idea. I won't promise it for now though, as we're currently still busy fixing all the launch issues. But if time permits, I like the idea.

Yes this is the same thing. The defect was that ground units (not air units for whatever reason) didn't "forget" the list of what they detected. This meant that if you flew up, got seen by an EWR, then ducked behind a hill, if you asked that controller for the list of targets it sees, you are still on that list. This wasn't an easy bug to understand because most folks cannot tell that they were legitimatly detected or when. The entire thing is compounded by the ability for the EWR Task to send DLINK detections to planes. If a ground controller has a detection and an EWR Task it will send the detection to any plane. So a Mig 15 could and did chase you all over the map based on this bug. And since no one understands that in the first place, then Reddit just exclaims that the AI has superpowers, when in fact a simple defect caused this since last November. I felt very strongly about this defect.

When people make concentration camp comments they come off less educated and qualified and more hyperbolic and emotional. More than a little ridiculous. Im still not sure what the problem is? The video doesnt mention what settings were used and mostly seems to demonstrate behaviour on the ground. As grover mentioned its a special case and anyway not really relevant for handling the airplane since it isnt moving. I had a try with my WH yesterday and none of it really struck me as unusual or unintuitive. Actually it felt pretty good. I had no problem flying at combat speeds or setting up for an onspeed approach. In a few ways once trimmed it was easier than with my FFB stick, since the axes are higher resolution and the forces dont slacken off like with FFB. Of course if you snatch the stick the nose will oscillate, but this happens even with EDs implentation. Admittedly in this quick test I didnt see a huge difference between blending on or off, and I also eagerly await grovers write-up on how exactly this works and what its doing.

Yeah they acknowledged that it might feel 'on rails' for the benefit of single players in the cpg seat vs all the hassles George brings, but also stated that they'd allow this to be turned off in mission/mp settings etc for those with objections

I continue to fly this module patiently and read carefully. But. Do you know what the most unpleasant thing is? HB constantly hints that too few users are dissatisfied with the control system and FM in general. Should statistics be collected and there is some minimum threshold of dissatisfaction so that HB stops saying that they will not change anything on this issue? No. In many other requests, we will get an instant response and a desire to address the problem. Many many people do not complain, based on gratitude for the module as a whole. Many people are not greedy, so as not to repeat what has already been written, or do not feel competent enough in the field of controlling real aircraft. So do we have a problem with statistics or are we dealing with double standards? Another interesting point: are SME reading this topic or is HB saving their nerves?

I don't think anybody is disputing anything you wrote. Good description of how our control interfaces in sims work. I also don't see anybody in here confused about flight control systems. I have no problems flying the thing. As in, I can take off, fly around, shoot things and drop bombs just fine. I just think it handles pretty terribly in pitch in one specific area because there is a pretty gnarly error in how they've tried to shoehorn feel forces into the processing of control inputs -- it directly, and adversely affects stick/stab position being selected by the pilot. It manifests as a pronounced bunting and ensuing oscillation in pitch when unloading after a pull. You cannot control it because direct control of the stick is not possible, as it would be in real life -- as it is in other non-FBW modules. It stands out to me as a small, but still glaring error in an otherwise amazing accomplishment so far. I'll see if I can get a video up describing my problem with it, comparing the relation of physical stick inputs to the control surfaces of a couple other modules juxtaposed with the Phantom.

@Super Grover Sorry to bug you again, but in the process of trying to put together a video a thought occurred to me, and I wanted to run it by you to see if there was something I was missing. I think we all understand the concept of the bob weights attached to the stick and the bellows creating a balancing force. I think everybody here understands and accepts that and also that a sudden increase in load on the bob weights would cause an imbalance and throw off trim. My main problem with all of this has always been the uncommanded stab deflections, and according to your simulation, it's due to the modulation of the trim neutral point when load is put on the plane -- but my question is this: Did you take into account that in this control system, when a pilot is pulling on the stick, or indeed if he were to suddenly relax his pull, that he is still gripping the stick and holding it in place, and thus supporting the increased load of the bobweight? If this is the case, the moment caused by the increased load of the bobweight should not be fed back into the system to throw off the trim neutral point, therefore, it should not be modulating erratically as it does with load. If this is indeed an oversight, I believe it would pretty much resolve the issues I'm seeing with the pitch oscillations. What do you think? Is it perhaps one of those engineering oversights where one might be so zeroed in on the complex interactions of the system that one forgets to put the system into its proper context? ie. The pilot's arm in real life is actually there, and doing the work of supporting the increased load. It's not an isolated system -- a human is meant to be part of it providing forces of their own.

Folks its obvious we are not going to be able to please everyone. I can tell you more people have been thanking us for the pilot model than have been complaining about it however. Its very easy to back seat manage projects but without being part of the team you don't know what is going on so can not make informed choices, that is for the project managers to do, they are the best people to know what our teams can focus on.

I put together some simple procedural kneeboards for the F-4E Phantom, placed in the User Files section. https://www.digitalcombatsimulator.com/en/files/3338073/ As stated, these are not official procedures, just what I've put together as a quick reminder on how to employ various weapons on the F-4E (after not flying it for a while, or in this case, while learning a new module). Kneeboards included so far: F-4E - AGM-45-1.png F-4E - AGM-45-2.png F-4E - AGM-62.png F-4E - AGM-65.png F-4E - AIR-TO-AIR ACM AIM-9.png F-4E - AIR-TO-AIR BVR ACM AIM-7-1.png F-4E - AIR-TO-AIR BVR ACM AIM-7-2.png F-4E - AIR-TO-AIR BVR ACM AIM-7-3.png F-4E - GBU-12 PAVE SPIKE.png F-4E - UNGUIDED BOMBS-1.png F-4E - UNGUIDED BOMBS-2.png F-4E - UNGUIDED ROCKETS AND GUNS.png The F-4E kneeboards need to be placed in the F-4E Kneeboard folder, for example: C:\Users\<your name>\Saved Games\DCS.openbeta\Kneeboard\F-4E-45MC Enjoy! AKA_Relent (ED forums: 609_Relentov)

ED is well aware of what the desync issues are, as the patch notes even say to expect them. The real question is, when can we expect a fix? What does “ASAP” mean in the patch notes? Is there a hot fix coming, or are we going to be waiting for weeks? Your most passionate users, members of virtual squadrons that train and fly together as a PLT and CPG team, are essentially grounded right now with a completely unusable module.

We all need to help support CH, the models he uses are extremely expensive. ED could sure learn a lot from CH. CH is 100% responsible for bringing life to DCS World. He has created over two hundred high-quality assets for the DCS Community. I'm also having issues with missiles, but the issues will be fixed, it's just going to take a little time! Thank you, CH, Timex 3

Kinda spoiled by the Tomcats, but can I have it on F-4E too? If so, how?

See, if you actually read what I said, it means you would've got the fact that I realize it has to be done repeatedly. But you yourself said it takes very little time. You're doubtlessly spending far more time writing about how much time it takes than the time it takes to actually do it. And I would repeat that your analogy to remapping your HOTAS is a non-analogy. I read what you write and I understand what the argument is. You've repeatedly asked why you should have to have files on your PC that you don't want or use. My response is somewhere between "That's the nature of software" and "Life isn't fair". And as by pretty much everyone's account this qualifies as verrrrrry low on the to-do list, and presents no real problem at all to anyone, I feel at liberty to point that out. And you exhibit an ability to advocate for solutions to non-problems with a level of precision and vehemence that is unmatched. Kudos.

The fact that so many people are reporting the same points to there being an issue somewhere. That is an undeniable fact, as is the fact that the hardware and software used by devs, SMEs, and beta testers is not representative of what the average end-user has. It's also a fact that the devs and SMEs are going to be biased towrads perfection of simulating the real deal, practical usability for the average customer be damned. From a purely logical and objective, unbiased perspective, this should be an option. To be clear, it should not be removed, but the choice to turn it off should be available so the end-user can tweak the controls simulation to work better according to their hardware/software.

exactly what our squadron "sme" - a former F4 pilot - describes. frequent trim inputs with multiple short clicks. But short clicks have too much effect as it is now. (mt client here)

You likely disconnected due to bad maneuvering. When that happens, there is currently a bug with the DCS tanker where he ignores that the Phantom cant accept fuel until the door has been cycled again (DISCONNECT light is on). The tanker then just sticks his boom in, ignoring that, and then immediately notices that he should not have done that. He disconnects immediately and incorrectly calls "transfer complete". We are figuring out with ED why this is happening. In the meantime, cycle your AAR door and go through the communication cycle with the tanker to initiate AAR again.

The turorials do not take months to complete. In fact, they are much quicker than your current trial and failure-method.

Which is instant, minus inertia that would also occur in real life, unlike falsly understood by some in this thread. The reason a stick on the ground would not fall forward when pulled by nose down trim, is friction, which cannot be emulated in DCS. However, this only applies to being on the ground. IRL you would need to pull back on the stick to counter the nose down trim. You can still pull it backwards in the sim, if you want, but leaving it centred, means that you are not pulling. Once you get sufficient airflow, this issue is not present anymore and does not apply. Only one of the points where the video above is wrong. "The bellows system pulls at the stick with increasing airspeed, while the bobweight system pushes the stick forward with increasing G. In flight and when you are trimmed out well, these forces roughly balance each other out naturally. On ground however, the bellows measure airspeed 0 and hence do not add any force that would counter the bobweight system pushing the stick forward. You also will not see trim doing anything in that situation, since the trimming merely changes the length of the lever to which the bellows can apply force to the stick and do not move the stick around directly." But hey, getting it out there and spreading misinformation and calling us wrong, again, without understanding fully how it works or even considering the above information, is a great course of action, I guess, while the complaint basically sums up to "my spring stick neutral position should equal my hand pulling on the stick, even though my real hand is not pulling on the stick." Like, how about: pull on your stick? And again, this is only an issue when sitting on the ground, as in flight the bobweights and bellows more or less balance each other out when trimmed. I also think what many don't understand, is how little roll you get at slow speed in the F-4, which makes it feel like it is delayed at times, and the inertia that is in effect in the real flight model. The only disconnect you have, is visual. And we already promised: "Yes, that's a feature we can and will add - just a 1:1 animation without any smoothing. Similarly, we want to add it to the pilot body, which, when smoothened, may cause unpleasant sensations in VR for some. I can't promise the timeline, but such an option will undoubtedly appear." Equally trim is something that needs getting used to, as everyone is used to a "fake" tim axis, naturally so. Trim in the F-4 does not move stick center up and down an axis, it changes the lever to which the bellows can apply force to the stick, it does not move the stick around. The F-4 was and is notorious for trimming, needs careful but constant trimming. Yet I can easily trim her on speed level and fly around for ages like that almost hands off. If your nose is dropping - pull back on the stick and trim. Once you are trimmed out nicely, you need less hands on, but even so, you can never be really hands off with it except for a few seconds. I can only repeat what I said above: we won't change it. It's not up to debate now, and it won't be up to debate in the future. Our apologies if that leaves a handful of people disappointed, which of course is not our intention.

I understand the need, I truly do, as in order to install the last update I had to uninstall FOUR maps (Sinai, Normandy 2.0, Syria and Persian Gulf) from my DCS: .... however, two points: 1) A larger SSD does not cost "thousands" of dollars, I just was looking to expand my PC and a 2 TB SSD costs 90-100 US$ on my country. 2) Saving a few GB of livery space would have not helped me one bit on the last DCS update, as I needed over 140 GB of hard drive space ... so, spending development time to optimize what is essentially a relatively small part of the DCS footprint would help almost no one. So, updating the PC is unavoidable if you want to keep adding maps and aircraft to your DCS install, the only way to not enlarge it is to simply stop purchasing ever more modules and maps.

The video below was a combination of several flights with me and the boys. Been putting together a simulated Vietnam environment on the Marianas Map. Most of this stuff is randomly spawned in groups throughout the jungle that Mistermann has been creating. Makes each time different. In the Cayuse especially, it gets crazy flying over a random spot of jungle and taking small arms fire. It has been fun locating targets in the OH-6 and marking for the Phantoms and A-4s. Words do not really convey the experience in VR. Flying low with doors off and having the F-4 roll in overhead and take out a hill will never get old. I have that time stamped in the video below. Looking forward to seeing how the mod progresses and if anything else will be added in the future.

Please understand that what we cannot accept, is that folks want to tell us that the FM and stick input implementation is wrong, and to change it, after flying it for precisely 1 day or much less even in hours. and without having flown the real jet. The reactions we get from SMEs (12 of them who flew the jet for thousands of combined hours and one of them who still flies it today) - are a destinct testimony to the opposite. The FM has been build based on heavily including their input, every step of the way. Again, whether you give it an open minded chance, or not, is up to you. Fly it for a couple weeks, a month even - then tell us what you think. Of course that won't help much, if you never give it a real chance. If you are a real pilot, you will know that judging an FM and getting a good feel for it after a few hours of flight is not possible. I invited you to give it an honest try. You keep coming back with "no". After spending likely less than a full day with it. Please be so kind and understand that that won't just change our mind. Don't get me wrong. I know where you are coming from. I felt very similar initially. And all I can say, I am so, so happy that I didn't convice Grover to go the classic route, as I initially wanted to, when I first tried it. I truly and fully know where you are coming from. But so many things that we were able to do that work as in the real aircraft, are made possible through this. And the rabbit hole goes deep. From bellow intakes freezing at high alt, to flipping backwards with pitch down stick in a clean tailslide to so many quirks and peculiarities in between, to just name a random few, which occur now naturally, most importantly - made it possible for us to take the FM to the next level, and we will continue improving on it, too. But you can't explore and experience it, if you don't give it an honest chance. I can only kindly invite you again to do so.

Actually, everyone would lose, and I'll explain it in detail soon.

I was writing it down at the FFB topic, but this topic is more related. So sorry to all of you who will read it twice: To HeatBlur Hello. I'm participating as a test pilot and some kind of expert in the FFBeast project. It all started more than 3.5 years ago, but the devices are only now getting ready to be delivered to the first customers. We made significant progress by understanding the necessity of a wide range of feedback forces required for correct simulation and implementing them into our products. At this moment, some versions can produce about 60 pounds of force, which makes them a perfect fit for use with the Phantom. I have been talking to other people about how important it is to have such devices. Coming from my real-life experience of flying a wide variety of different aircraft, I was able to replicate the feel of controls of most airplanes and helicopters in DCS throughout the project software. For example, when we’re talking about the Mosquito or Spitfire, very little stick movement is required to control the aircraft in the longitudinal axis. That is why the stick has to be very firm and well-loaded from the first millimeters of movement to prevent over-control. But it would be a very different story for the Fokker A-8. The same applies to different types of jets depending on the type of boosting systems they have, Fly-by-wire, or the absence of any boosters. The main idea behind all of this is that through the control stick and pedals, you can feel the “character” of the aircraft you’re flying. Let’s say you’re sliding the tail down in your P-51 after a vertical line; you should be prepared and keep your flight stick firmly; otherwise, it will probably kick you very hard between your legs. So all of this makes people with flight experience believe that they’re flying the real thing, especially in VR, and teaches virtual pilots what to expect from real controls and helps them better understand the regimes they’re getting themselves into. Using FFB is what makes flying “bright and colorful,” and no matter what, you can’t replicate the same with a regular spring-loaded joystick. Sliding the tail down on a regular joystick won’t give you the feel of airflow going in the backward direction. But it doesn’t mean you can fake this by breaking the linkage between a physical joystick and the 3D stick in the cockpit, letting it go all the way to the pilot seat because you will affect the pilot’s decision, will, and control of the aircraft. It might be that he wanted to have the stick all the way forward to make the airplane fall on its back. What you have done by trying to fake FFB feelings on the stick when using a spring joystick is absolutely unacceptable because the pilot doesn’t have any control over this. No matter what, you’re not allowed to interrupt the pilot’s control input in such a way because it doesn’t work right, replicates nothing except your poor judgment, and brings only frustration and poor flight technique, which is already a problem among virtual pilots. I get your point; I read the manual and went through the schematics very precisely, watched a lot of videos to compare stick behavior, and even though I don’t agree with you on how in a very exaggerated way you wanted to simulate stick rebalancing, on FFB I can overcome it by force, but there’s no possible way to fight it on a spring joystick. Please leave this “rebalancing” feature only for FFB users and don’t try to fake it in a very “arcadic” way for people with spring joysticks. They are at a disadvantage already, having all aircraft and helicopters “flat and grey,” it’s already very difficult. The problem is that this mathematical interpretation of “rebalancing central position” is only can be applied for the FFB users and when you’re applying this approach to the regular joystick you’re breaking the linkage between pilot and control stick. Basically It replicate hands off flying. It’s like pilot has introduced some force impulse and let the stick go completely removing his hands from the control and now the system “stick-airplane” oscillates completely freely. It’s not a case in a real flying. Also if Heatblur had enough experience of flying, that “rebalancing” of control center is happening in every warbird as well, even if the elevator or ailerons itself are perfectly balanced by the counter weight. It happens because when you’re maneuvering local AOA on elevator and aileron changes as well which basically moves aerodynamic “center” causing shift of the stick trimmed position. It could be easily seen especially during snap rolls. And yet it does cost zero troubles for pilots myself including to overcome that and doesn’t produce any oscillation after the breaking maneuver. These effects are more pronounced if you’re flying aircraft with elevator which is unbalanced, meaning the stick will fall forward on the ground with no airflow around it. And yet again- is not a problem or inconvenience in any way. Also interesting facts that may affect this “spring weight”oscillation thinking of yours: On the ground in F-4 stick with 3lbs bob weight doesn’t move forward, because of total resistance in the system (weight of elements, friction, stickiness of grease). All of these are the natural damper. Maybe, and this is the most important one: Override spring cartridge is positioned that way, that when it’s pulled by bellows it can move stick back just on very limited angle and then it’s only pulling out the spring emulating aerodynamic loads. Think, how you can get any loads on the control higher than bob weights? In your understanding what will happen when emulated by bellows aerodynamic forces will be higher than the weight of bob weight? Stick will be spring out of the center? You’ve got a reference that during supersonic flight it might required around 60lbs of force to get a 6G turn; let’s say 18lbs or 30lbs (depends on the bob weight) are caused by bob weight, where you’re getting the rest of the load? Exactly it comes from the bellows and it points towards the center. I don’t know, but my guess is the only reason why the spring override cartridge is not perfectly aligned with the pivot point of the bellcrank is to give some space to the spring to be pulled out to compensate the weight of the bob weight. That means when you’re thinking about oscillating weight and spring, you have to be thinking about very limited range of movement, and it will come down almost instantly because of dampening characteristics of the system itself and because the spring cartilage itself has much more of the resistance than inertia of a 3lbs bob weight. Yes 3lbs or 5lbs whichever you have implemented. G factor doesn’t apply here. Think this way: McDonalld wanted to make a feel unit mimicking the airflow loads. They have determined specific max load by the spring resistance which caused, due to wide range of speeds aft CGs and effective stabilator, very light loads at the takeoff and landing speeds and also which is more critical low forces are required to perform high G maneuvering at subsonic region. So they putted bob weight, just to increase these loads for the G maneuvers. That’s it. You have written in your manual It was designed around carefully balanced bob weight and a spring. To be honest, when I read this, I thought you will fail to make it right, because you have emphasized wrong point. Basically I don’t care how did you do all of this “mathematics” because for my FFBeast I can do everything right through the software. But I insist you have to remove this “feature” from using it with the spring joystick.

Dear all, gathering your questions and most pressing concerns and feedback from yesterday, we want to present you with a list of issues you may run into, when trying the F-4E for the first time, and ways on how to avoid them. We hope the below list helps you get started faster and smoother. Please spread the word! Your Heatblur Team Issue: I am experiencing bad performance with the F-4E. Fix: Make sure you are using the multithreaded version of DCS, not the singlethreaded. This will significantly improve your performance. We do not recommend running the F-4 in the singlethreaded version. You already have both versions installed, always. To run the multithreaded version simply run the DCS.exe in your Eagle Dynamics\DCS World\bin-mt folder. Issue: My F-4E keeps pitching up violently although my controls are bound correctly. Fix: This happens to non-FFB users who have FFB enabled in their MISC options. Simply go to MISC options and disable FFB and the issue will go away. Issue: I am using VR and the JESTER Menu, Manual and/or Bombing Calculator are cut off. Fix 1: It is an issue with the DCS VR implementation and an unfortunate combination of graphic settings. You can fix it either by selecting "use dcs internal resolution" in your VR settings or using our special options if you don’t want to do that. It is described further in this section of our manual: https://f4.manuals.heatblur.se/dcs/special_options.html#hb-ui Fix 2: As stated in the manual, setting the VR render window to LEFT or RIGHT eye without checking the "Use DCS resolution" box makes the Jester menu cut off. However if "Use DCS resolution" (fix 1) alone does not solve it for you, you can try to use the "BOTH" setting for the redering option. Jester menu should then be back in full, normal size and centered. Fix 3: Found by Des 2-2 (thank you!): "an (easy) solution to the HBUI cut off at the bottom in VR issue: change the resolution of the VR mirror to at least 1920x1080. Many people set it below that in the hope that it frees up a little GPU resources." Note: We are currently trying to find a solution together with ED. In the meantime, if neither fix 1 nor fix 2 work for you, the best is to experiment with the resolution settings offered in the special options. Our apologies. Issue: I downloaded and installed via the DCS module manager, but when I spawn in the mission, it goes to the F10 map and only AI spawns. Fix + EDIT: Going through the reports of the past few days and fixes that were found, most likely this issues is because your antivir program is either blocking HBUI.exe or one of our DLLs. We kindly ask you to add exceptions to these in your antivir program. This should fix your issue. If the issue persists, please make a report. Issue: When I go to the mission editor, I do not see the F-4E. Fix: You need to turn off the “historical setting” in the Mission Editor. It is at the bottom center, represented by a clock symbol. Click the clock symbol to turn it off. Issue: My JESTER menu gets stuck. Fix: If using head tracking and mouse at the same time, they can conflict. You can disable either in the special options settings for the F-4E. Moving the mouse pointer out of the menu fixes it, too. To close the menu you can hold the Jester menu button long. Issue: My force feedback pitch and roll force seems very light or weak. Fix: You have gain settings for force feedback in the special menu options. Note that you can increase them to 500%. Note that if both roll and pitch axis are set to the same value, the roll axis will have less force feedback force. This is intentional and true to the real aircraft, where the roll axis requires less input force than the pitch axis. Please adjust to your personal preferences. Issue: It looks like the stick in my cockpit is lagging in comparison to my real stick. Fix: The movement of the 3d model of the stick in the cockpit goes through a type of low-pass-like filter. Otherwise, it might look erratic and actually even less realistic. However, it doesn't represent the actual physical simulation of the entire stick simulation, and that means that the change of your input is instantaneously transferred to the controls system. Yet, that system runs a complex simulation that adds realistic inertia to the mechanisms that transfer your input to the power actuators. To summarise, the lag you may see when observing the 3D controls doesn't represent the system's delay; there might be some realistic inertia reducing the controls' responsiveness. Issue: I want to close the manual or bomb calculator, but it does not work. Fix: You need to click with the mouse out of the manual or bomb calc window. If clicked into it, keyboard input is enabled and will prevent the close/open commands. Issue: My cockpit appears to be very dark. Fix: Please make sure that you have “Cockpit Global Illumination” turned ON. If this alone does not help, our recommended Gamma setting is 2.2, so you may want to increase your Gamma. Note: there is currently a bug that will load the cockpit darker on the second spawn. A third spawn should fix that. Issue: My trim is not working on the ground, the stick is either full forward or full back and when I trim it does not change position. Fix: This is correct as is on the ground. The bellows system pulls at the stick with increasing airspeed, while the bobweight system pushes the stick forward with increasing G. In flight and when you are trimmed out well, these forces roughly balance each other out naturally. On ground however, the bellows measure airspeed 0 and hence do not add any force that would counter the bobweight system pushing the stick forward. You also will not see trim doing anything in that situation, since the trimming merely changes the length of the lever to which the bellows can apply force to the stick and do not move the stick around directly. Issue: I cannot make sense of the controls indicator. Fix: The big green diamond is your joystick input. The small green diamond is the neutral in-cockpit stick position - this is where the cockpit stick will reset if you re-centre your joystick. The orange/red diamond represents the actual cockpit stick position after taking into account all effects, including your joystick input, the feel trim system, force limiting, and blending. This position is transferred to the power actuators moving the control surfaces. Issue: I have trouble getting used to JESTER 2.0 and the new menu. Fix: We recommend giving it a few days to get used to it. Jester 2.0 is designed more proactive than JESTER 1.0, he scans the sky himself for example, he will turn radar on and off himself if landing or refueling, etc., and overall requires less use of the menu through the JESTER context action. With context action you can direct him to switch targets, lock them, unlock them in air to air, to lock ground returns for dive toss, and more. We recommend to familiarize yourselves with the JESTER section in our manual in general, here: https://f4.manuals.heatblur.se/jester/overview.html And with the JESTER combat section in regards to context action, here: https://f4.manuals.heatblur.se/jester/combat/overview.html Issue: Jester has trouble finding targets. Fix: While Jester searches the sky in a forward, primarily head-on, co-alt aspect of your radar, one still needs to consider the limitations of the AN/APQ-120 radar. It is not a search radar, and the detection ranges are very short. This means that with 2 bandits racing at each other, from detection to merge, your BVR timeline can be less than 45 seconds. IRL Phantoms were guided to their target’s general position with the help of GCI and AWACS units. The F-4E’s radar is also a radar that needs to be “flown” pro-actively. This means helping it through your maneuvering - or non-maneuvering - as much as you can. Look-up aspect is in general preferable, so positioning yourself slightly below the bandit helps. Some bandits with a smaller cross section, like the MiG-19 may be picked up by the radar at less than 20 nm. In short: try to use the radar more as an intercept radar than a search radar. Try to estimate where you targets will be, either through conventional SA building or through the aid of GCI and AWACS, and then position yourself for a successful intercept. If you want to dive deeper into the topic, we recommend Karon’s tutorials on youtube, from FlyAndWire. Issue: I am encountering weird behavior, like some weapons not working, or even get a CTD when trying to host a server, etc. Fix: This is likely owed to the presence of mods. As of now, the only mod we know that works together with the DCS: F-4E Phantom II for certain is the Community A-4 mod. Any other mod can potentially cause issues of various kinds. This is why we strongly recommend to disable all your mods, should you be running into such issues. ED is aware of the potential conflicts between modules and mods and will be looking into it. Please be so kind and understand that full functionality of the module cannot be guaranteed when running it with mods. Thank you! A tip from user “Mederlock” to improve performance, if running into issues: “A little tip that might help some people's performance: in the task manager details page, dcs.exe->set affinity->de-select the first core. If you check the DCS log file you can even see which of your cores perform the worst and de-select those specifically. You'll have to re-do this every time you launch the game or use a tool like process lasso to automate it on startup. I've heard a few reasons why this can help, [...], I don't really know the theory but it certainly helped my performance a lot, as well as several other people in the group I play with. Worth a shot if you're having stuttery or poor performance.” Check out these beginner tipps and tricks from Tricker: Here is also a nice cheat sheet for WH key binds, made by Blackbird (as a proposal). You can also check out the control bindings guide in our manual here: https://f4.manuals.heatblur.se/dcs/controls.html#binding-guide