Zabuzard

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

Can you send a screenshot of the main panel area and the left console when it happened? Should help to identify which switch was accidentally pressed, leading to the engine going out :)

This is just the CEF process idling in the background, being ready for subsequent uses of HB aircraft. CEF, with its multi-process architecture, doesnt support being fully shutdown and restarted later on, so it must be kept alive. This is normal and also does not influence your performance.

The binds are defined in DCS/Mods/aircraft/F-4E/Inputs/Pilot/Keyboard/default.lua and the corresponding file in the WSO folder respectively. They are referring to opening the Pilot file and copying the lines from the WSO file that define the controls for the WSOs Radar Range knob into it. Once you did that, you can map the bind from the Pilot seat as well. Manipulating WSO binds can easily confuse Jester as he doesnt expect that, so you will need to disable Jester when you mess around with his pit.

Iirc the plan was to add one or two of the older pods as well. Especially the ones often used during the Vietnam periods. Note though that in DCS (currently) you can only say "jamming on/off". So you unfortunately cant model the details and "strength" of the jammer pod.

If you are in 5nm then you likely commanded the plane into CAGE mode (button on the throttle). That mode forces the plane into a 5nm boresight dogfight AA setting. Also, the setting you are talking about is for telling Jester the preferred scope setting for a standard scan situation. Not for other situations, such as wheb you already have a bandit focused. In that case Jester will always adjust the scope accordingly to the focused bandit. If you dont want that you first have to defocus the bandit.

That control hint idea is somewhere in the backlog already. Definitely a good idea for an optional UI. Similar to how most AAA games show control hints in the corner of the games "HUD" [emoji106] The idea with the eyeballs thing is an already planned bigger and more general feature. Some form of general smart context menu that lets you point either outside or inside the cockpit, also on a gauge. And then giving you context sensitive options.

Do you have any mods or scripts installed? Even if they appear to be F4 unrelated the presence of some mods can cause weird issues like that.

A bug that has been fixed internally already :)

A more generic approach to that which could be used anywhere in the wheel was planned. But its a bit more complex. Its necessary to also keep the Enable/Disable structure to allow for: * assigning it to 2-way switches * allowing for better integration with voice-control software Theres plenty of places in the wheel where some Toggle feature would be useful on top. So we intended to solve this in a more generic way :)

Not sure what you mean by "planned". The aircraft is already equipped with pretty much all weapons it could carry (for that variant and timeframe). The list is more or less complete. The upgraded variant (DMAS) will see a datalink guided bomb which you can steer into the target manually after launch but that's about it.

"Not allowed" is the wrong term, but yeah. Our stuff will be included in the regular patch again, when there was also enough time for all the testing steps that take place behind the curtain to ensure you have a smooth experience and not constant crashes [emoji51]

We believe that the interface we offer for you to communicate with Jester and get him to do what you want (once its fully fleshed out and the missing bits have been added) will be more effective while also represent a more authentic way of natural pilot to WSO communication rather than you trying to fulfill both roles simultaneously. If you are not happy with the current state of this interface during Early Access the best you can do is to bind the Jester Enable/Disable buttons, allowing you to take full control of the backseat from the frontseat with ease - provided you can manage the workload. Once you acquired your lock you can also reenable Jester, he has been coded to support a lock made while he was deactivated and roll with it.

You are not supposed to play WSO from the front seat. So no, you are not able to move the antenna around. If you truly want to do this, disable Jester first. There should be no need for you to mess with the antenna. Instead, you can tell Jester where you expect the bandit and he will play the antenna correspondingly. I would suggest you have a read over the Jester Radar chapter in the manual that explains how to use Jester effectively. Other than that I have some trouble following your thoughts.

These "quick fixes" you have in mind all cost a full work day to code. Another day to test and possibly another for a round of bug fixes. And don't forget the invisible cost of someone having to context switch and probably also to study "foreign code", considering that the people who wrote this snippet arent around anymore. Not here to argue against your idea, but its not "just a quick thing" to do between other tasks during lunch break or similar. Its not a bad idea, not at all, but rather low on the prio list that is packed with other more crucial things already. Either case, thank you for your suggestion. It will be considered, cheers.

You need to be careful with the gauges as there are different variations and they got changed over the years. So especially with consulting the standard flight manual you might need to pay attention whether it actually applies to our bird or not. If I recall correctly, our VSI is RCS-60-1LO, which is built to meet the standard MIL-I-18804. You can find lag and error specifications and whatnot in that doc.

The issue had been semi-fixed a week ago or so, for the next update. There is more to fix unfortunately, but it should be usable again soon.

From all the cases ive investigated so far it always turned out to be users confusing the interface and Jesters feedback. So it would be great if you can share a track, then we can tell you immediately what might have gone wrong or clear any misconception. Cheers :)

The gauges are modelled very closely to the manufacturer specification documents, maint docs and test results. The behavior was also carefully verufied by our real world Phantom pilots (inactive but also some who still fly the Phantom today). This btw also includes their variance and how they react to forces. Speaking of, make sure you select the "reference aircraft" in the mission editor for a good base of discussion. Otherwise you might experience whatever the mission maker had set up for you.

Everything marked in the manual as "todo" will eventually come :) Combat Tree is quite cool, but the very limited IFF-environment in DCS makes it challenging to implement it. (Currently you cant query any IFF info from other planes, such as if their transponder is turned on/off or what code etc.) What we have in mind is implementing it similar to friendly-IFF, that is it will show you any hostile aircraft (based on faction) on your screen, just like it was IRL. And then provide mission editors with options to either turn it off completely or a historic mode where it only works on certain planes that were equipped with the specific russian IFF transponders that the US were able to crack.