Zabuzard

Yes. This aspect in particular has been carefully fine-tuned to match all available (very detailed) technical data and our SMEs all confirm that it felt exactly like that.

I suspect you did not actually finish the refueling but misinterpreted the events. There is a DCS "bug" with the tanker where when you disconnect due to maneuvering and then dont cycle the door quick enough while the tanker connects again, he will incorrectly state "refueling complete" instead of waiting for the door to be cycled first. When that happens you have to reengage the dialog with the tanker and continue with the refueling (ofc after cycling the door).

In case you run into an issue with us automatic deployment. There have for example been cases where it extends and retracts constantly, causing unstable flight. Mostly due to malfunction but there are also situations where u might anticipate it to trigger in/out and then you could use that switch to force it in one position. For example to prepare for a landing where you really don't need this thing to act up.

No worries. You are not the first to trip over this acronym. Also reminds me of doing that one feature I had in mind where you mousehover over abbreviations like that and it shows the full name, perhaps including with a link to where it is explained in more detail

There is an edit button in the top right corner ARR is correct, it stands for Air Refueling Release button, see here for more: https://f4.manuals.heatblur.se/cockpit/pilot/stick_seat.html#air-refueling-release-button Ill link it in the manual in that article to avoid confusion

Something like that is planned. Its not that trivial though. From a UX perspective it is better to approach this stuff from the use cases and less from a "let me control the switches in the backpit". Some things, like the AAR and landing stuff should be fully automatic by Jester, you should not have to tell him to switch radar off or anything - so the solution for that will consist of improving the automatic behavior. Other than that there will be situations in which you want to shutdown all emitting equipment, i.e. a "go silent" option that does not only turn the radar off but also jammer and similar. The existing option in the wheel just switches the knob, there is no persistence applied to Jester that lets him remember your choice - so he will switch the radar on again whenever his logic decides its time to turn it on again. Making your choice permanent isnt ideal either. 10 minutes later you are jumped by a Mig and complain that Jester isnt smart enough to figure out that its time to put the radar on again without you explicitly telling him. This stuff needs to be approached in a proper and more modern way that resembles the real cockpit interaction between pilot and WSO better than you trying to control both pits at the same time

Its on the list, cheers

This is WIP. It is because currently this is the best way for him to understand that you are doing AAR. The condition should be refined so it wraps the process better, but its important that its specific enough to not trigger when you are for example just escorting a tanker or waiting for your buddies to be refueled. Not that simple, so the AAR door has been picked as intermediate condition for the time being.

This is mostly due to technical limitations. Thirdparties dont have much control over how the cursor works or looks. The way the explain feature works is by setting a flag in the code (while holding down M) and if that flag is set the code will intercept any input/bind that DCS feeds it with, ignore its normal function and instead open the manual at a dedicated page. So its technically not only "click at something", the code cant differentiate that from someone pressing a HOTAS command or any other bind. The linkage from command/bind to manual is setup in a file called explain_table.csv, you can find it in DCS/Mods/aircraft/F-4E/Input. Your suggestions are welcome and make sense. But I doubt they can be implemented currently. Cheers

The team has repeatedly confirmed the bug and that it happened during test sessions already as well, that is not the problem. For finding the cause and fixing it its necessary for it to be reproducible in debug mode with the debugger attached. Not just once or twice but like 50 times in a row. Hence the need for a tracl that reproduces the issue when replaying the track :)

For clarification, CAGE mode is left by entering or leaving the B position - not by staying in it, its the impulse that triggers it. If you did that you probably did leave CAGE mode, unless you have accidentally entered it again. Possibly due to a bind conflict, Ive seen that a couple of times already. Otherwise, I would suggest you press Context Action twice and pay attention to what Jester says. You can also deactivate AUTOFOCUS in the Jester Wheel (Radar) to rule that out as factor. Hard to guess whats going on. A track would tell instantly if you can share one.

Are you talking about the kneeboard or where are you missing the QFE exactly? If former: Known issue, fixed internally already :)

Its as mentioned earlier in the thread. Some of them are supposed to be adjustable and as such the team will make them adjustable eventually. The difficulty is not adding the interaction and tilting the mirror. Its teaching DCS that the "camera view" inside the mirror has to change as well. See the little gif I shared earlier which has the interaction but the actual "picture" shown by the mirrors remains the same - not helpful. Someone from the team has to sit down, figure it out and make it happen. It's probably rather low on the prio list. But it will be done eventually.

You would start with them being set so you can see your control surfaces. Especially for the checks on ground. And then you might adjust them as needed later on.

When you replay the track in DCS (main menu > replay), does it reproduce the issue as well? The main problem with this issue is that so far no one was able to nail it on a track that reproduces it yet, unfortunately. Its a known bug and the team already did some blind investigations and attempts to fix it, but without a working track it probably will remain very hard to find and fix.

The team has not communicated a date or timeframe yet. Cobra said they expect to come far in 2025, thats all that has been said.

As mentioned earlier, this is a known bug that has been fixed internally already. It will be available with the next DCS update, cheers

Dont worry, its in the backlog so it cant be forgotten

I feel like there is nothing I can add to the discussion anymore really. Thank you for your input

The Tomcat PDF version was manually created, it is not connected to the website content. Its not maintainable and consequently lacks behind the true content for many many "versions" already. Or in simple terms: It may look nice but its bad. In that we have a fundamental disagreement, I suppose. You dont have to, that is a misunderstanding. I am saying you (or anyone else) can contribute if they want - helping out when Heatblur simply has no time to take care of it right now (which is the case for the PDF topic). It doesnt, thats the thing. The Viggen manual is a failure from a dev-side, its unmaintainable. So much in fact that the topic was taken over by a dedicated community member (who is now actually part of the team). The Tomcat manual was an improvement over that, it can be edited and deployed by the team much easier (and also detached from DCS update cycles). But therefore it essentially sacrified the PDF completely. And unfortunately didnt really make a lot of use of the benefits of being an interactive website, so it was hard to see why the website-version is superior. The Phantom manual learned of all these things, its easy to edit by the entire team (even including the community) and a format was chosen that at least allows a PDF export. Automatic deployment is an enourmous help, allowing anyone to make a quick edit with instant deployment and not waiting for months until the dev with the arcane knowledge and a working local setup shows up. Unlike the Tomcat manual it starts to explore the advantages of it being a dynamic website, for example by having embedded videos, a great search function, themes, mobile support, tablet support, being able to share direct anchored links to certain topics in chat when helping people, in-game embedded manual with "explain me" functionality. And more ideas that come to mind, such as clickable cockpit overview pictures or showing "where is this" cockpit overview pictures on the side as you read the content of a specific system. There are a lot of things and consequences that you, as customer, dont see when it comes to these things. For example the Phantom manual being so complete and content-rich is a direct consequence of the format we choose - allowing everyone to contribute without much friction, instead of only having one or two editors who write the entire document and lack expert knowledge on certain topics. I understand the desire for a nice PDF, no one from the team is disagreeing on that. But dont forget that there are so many more use cases. There are so many people who read through the manual on their phone from bed, people who have the manual on their tablet while flying. Plenty of people using the "explain me" feature. Or simply checking out the manual from their desktop PC. The PDF is great for offline usage, especially during travel. And thats why it was important for us to at least offer a PDF export. Its shortcomings are very unfortunate, but it is definitely better than no PDF at all - and to be fair, they arent a dealbreaker either. The PDF version still works just fine for studying the aircraft, its just less convenient. Also worth noticing that Chucks Guide will eventually drop as well, offering a great PDF experience - which the team can then embed right into the game as well and also ship it as "official" document. Either case, I do not feel like this discussion is moving forward much. And it also seems to drift away from the threads topic. To make it clear again: Currently Heatblur is not able or planning to invest time into improving the PDF version. Please use the website version if possible (online or offline) or accept the shortcomings of the PDF version for the time being. The community is most welcome to help out on this front (see GitHub link) Hope that answers your questions, cheers

In case you have missed it, unlike for the Tomcat, the Phantom does come with a PDF. The PDF is auto-generated out of the website version. This thread is about some people not liking that this PDF is essentially a second class product and not first class, such as the website (and hence has some smaller issues such as broken links). The intermediate product is markdown. If you find proper tools to make PDFs out of markdown, go ahead. I want to emphasize again that the manual is fully open source and a community project. So if you (or anyone else) has some extra time you can spend it on implementing a better PDF. For various reasons (some layed out earlier), the team wont spend too much time on an improved PDF version. Feel free, select "Offline" in the Special Options and no internet traffic will happen from our side at all. The in-game manual is not an online manual, its an offline-website being displayed by the browser (located in DCS/Mods/aircraft/F-4E/UI/Manual). CEF (Chromium Embedded Framework). It does not impact performance. If you remove CEF entirely you will maybe gain 1 FPS in total only. Heatblur has of course tested this before adding the technology. If you select "Lower HB UI Refresh Rate" even that (small) impact will be gone entirely: https://f4.manuals.heatblur.se/dcs/special_options.html#lower-hb-ui-refresh-rate You can fully control which domains it can talk to and which not. See the manual for details: https://f4.manuals.heatblur.se/dcs/special_options.html#domain-access The PDF is available at GitHub for download and in your local folder DCS/Mods/aircraft/F-4E/Documents.

I suppose this is where opinions differ then. The team is convinced that the website-approach enables a lot of useful features that, based on user feedback, seems to be highly appreciated by most users.

For various reasons the team decided to go with a website instead of a PDF as main format. This has multiple advantages and for example also enables embedding it ingame with the "explain me"-feature and also other more sophisticated features such as embedding Youtube videos or making clickable cockpit navigation inside the manual. These things are not possible in a classic PDF. So its a website, first and foremost. The website version also has the big advantage that it can be updated instantously detached from the DCS update cycle, its accessible on all devices, also offering optimized versions for mobile phones and tablet devices. Markdown as format is a good fit since it allows non-tech people to contribute as well, which is important since this manual is a community project - not just maintained by the devs. In contrast to the F-14, whose setup doesnt allow any PDF export to begin with, the team thought it would be nice to be able to also offer a PDF as second class citizen. So the approach via Chromes print-API was choosen to enable a working and usable PDF export at low maintenance cost. Its important to understand that the PDF is not the main format for this manual and that the alternative would be no PDF at all. You are most welcome to suggest and find a better alternative that works with the existing mdbook format.

Correct. You can read on why in the link. That said, the manual is a community effort. So if you are feeling fancy, feel free to investigate into fixing it. As explained in the link, this needs to be solved in the Chrome API, not on our side

Hey there, those are known issues and already reported here: https://github.com/Heatblur-Simulations/f-4e-manual/issues Cheers