Zabuzard

FYI we have just corrected something on this topic. Coming with next phantom build https://github.com/Heatblur-Simulations/f-4e-manual/commit/b8e2aa131247b26083957bf104ee912b9603dc12

FYI we have just corrected something on this topic. Coming with next phantom build https://github.com/Heatblur-Simulations/f-4e-manual/commit/b8e2aa131247b26083957bf104ee912b9603dc12

(worth noting combat tree isnt a DMAS exclusive feature. it will be coming to the dscg as well.)

We have made some significant progress on it recently. There is one more issue that needs to be figured out first (some of the textures bleed on the center of the main screen around the HUD area when being exported). Once that is done, we will also prepare a detailed page in the manual that explains how this works. That said, you can already do it yourself since all of this is "lua only", so available for local editing/modding. Essentially, all you have to do is to open the correct init.lua and add two lines to export the lua-indicator to the viewport you defined in your local viewport file. For example: dofile(LockOn_Options.common_script_path .. "ViewportHandling.lua") try_find_assigned_viewport("F4E_Cameras_AvtrTimeIndicatorPilot") The name you put is whatever name you choose in your local viewport file - which is the file that defines your viewports. For the RWR and DSCG its important to pick the correct init files. Those are the files you have to edit to export the content: For the DSCG I found out that the DSCG_Pilot and DSCG_WSO exports only work when you also export and display the TV_Sensor (you can export this with width and height 1 px though, as long as it is non-zero). This is the local viewport file I have been using locally for testing: test.lua Anyways, once the texture-bleeding and shenanigans are fixed, there will be a detailed guide in the manual. Cheers

Please do not misinterpret lack of time as lack of interest. ED is aware of the issue and ofc interested in finding a suitable fix for it.

Essentially, the knob has two functions. You commented on its secondary function. When moved out of the full CCW position, the aircraft assumes you are in a nightflight and all warning and indicator lights switch their power source to a low voltage one, entering a (non variable) DIM state. The primary function is that it would set the brightness for the backlighting of all instruments from 0% to 100% (with the full CCW position also being 100% for daylight mode). This feature is currently incorrectly linked to the knob on the lighting panel (right console aft) due to technical limitations with the animations. Further, all flight instruments can be controlled individually with the extra knobs on the right wall panel. (Currently not available for the same technical limitation.)

The knob works correct. This is a common misconception and explained in the manual, see here: https://f4.manuals.heatblur.se/cockpit/pilot/weapon_management.html#flight-instrument-brightness-knob There are also some other threads on the topic already :)

The weapon has not been removed from those pylons. Could you send a screenshot or something to show your issue? Potentially you are just running into the issue with the list being too long and hence not showing everything because DCS has no scrollbar on it. Cheers

I guess my point is: If you would swap out Jester against a human WSO, would something different have happened? From my experience, usually not. To me this sounds like it was not Jester to blame. Instead, the crew needs to practice how to effectively position the aircraft in order for the radar to work as expected. And of course manage expectations. If you got a track to look into, I can try to give more concrete help [emoji106]

If you truly think Jester performed bad in one of your sorties - while a human WSO would have done better, it would be great to get hands on working (short, singleplayer) track files. So we can best figure out what to change and tweak

Most of such reports are actually more down to people understanding the radar. What it is, how to use it effectively, what its limitations are. As in, if you would fly with a human WSO, you would likely run into the same issues. Especially when it is about getting contacts on the screen, there is little that the WSO can contribute to that. This is mostly a pilots job of placing the aircraft correctly. A few things to consider: Establish a look-up attitude, not look-down, ideally also not co-alt. Approach targets from the side, not front, to increase the RCS. Dont place targets around clutter, know the terrain. Dont place targets at a distance equal to your altitude. Dont expect unrealistic spotting distances - for a fighter you can expect to get them on screen between 10 and 20nm if you did it well. For large targets 25-40nm. This isnt really "BVR". If all stars align you get the chance to shoot maybe one Sparrow before you are already in Sidewinder/Guns range (in particular since the Sparrow needs a few seconds before it can be launched). Practice practice practice. If you cant get them on screen before you see them visually, switch to a visual mode instead. For example (regular) Boresight or (CAGE) Boresight, put the target on the nose and hit the Jester Context key so he can lock the target that way. This will be your main tool to lock targets that are in visual distance (~10nm or closer).

The blades you are looking at are fixed (IRL and ingame) The actual compressor blades that move are further down behind the blades you see. See here: https://youtu.be/Or6mIaSWZ8g?si=9bSqzVlPkqCTmqhG&t=33

Sensor icing is implemented, but not for the engine airstream yet. This switch currently has no function. Moving it doesnt do anything. It gets a bind as soon as it does something.

Soo uuuh, what is the problem exactly? They seem to work just fine on my end. Make sure it is night, they are barely visible during daylight (just like IRL). Turn the mode switch to ON and move the brightness knob up (clockwise).

Ah yeah. Checked the code. It is a bit more complex on the code-side because it has a pre-condition. Its on the TODO list actually

The switch has no function. Hence no bind, cheers.

Sure its not available? Should be. Which bind exactly are you talking about? P?

Possibly he sets it but then later in the flow is a moment where his logic tells him to set it to on, perhaps after takeoff. That would explain it because the wheel action is momentary and not "put into his memory". So in this case the code would at least behave as expexted, but understandable that this leads to confusion. Similar to how he will activate the radar once airborne even if you told him on ground to shut it down. Because at that trigger point his logic tells him to prepare the aircraft for flight.

Ull be able to explore this in more depth once the EFB electric page is available with the next update. You can see the state of each bus with that and more. Afaik this topic is implemented correct. But yeah, with the EFB you can get more details out of whats going on

That sounds about right. Can you hop into the backseat and check if his flares knob is actually in OFF? Otherwise yeah, a track would be super helpful. Thanks

Such a great document, congrats Chuck! We are very happy to promote the content in the Phantom. It has been added to the frontpage of the official manual, to the modules Doc folder and to the Virtual Browser (RCTRL+V) for viewing it in-game as well. Available with the next Phantom build

Doublecheck the flares switch on your left console, around the fuel panel. This is an override switch for the pilot that forces the flares on, regardless of what the WSO set. Otherwise a track file would be great to see whats going on, thanks

There is no ETA on it, but it is being worked on and HB has occasionally shared news about it in Discord. For example that artwork has finished and integration work has begun

No need to rumor about it. This has been officially stated a few times, especially on our Discord and in the news channel there. The EF is supposed to be HBs next DCS module. The flyable A-6 afterwards.

yes