Zabuzard

Thats the kind of micromanaging that we want to avoid. The plan is instead to add a superior and more general way of pointing Jester at targets. Think of a "Jester, look here" where you point in the sky or on the radar screen or on the rwr screen or similar. Further, Jester will learn to incorperate more data into his search behavior, for example AWACS calls, RWR, mission data and so on. So that he is able to find targets more proactively than now where he only performs a general search pattern. The majority of F4 WSOs hated 2-bar mode for various reasons and always used 1-bar instead, while controlling the elevation by themselves. In 2-bar Jesters logic doesnt really work well anymore, so such an option likely wont be offered soon. And again, its micromanagement that you, as Pilot, should not have to do. Jester will be improved so you can focus on doing your Pilot job instead.

It is because MS and friends processed the whitelisting requests. As explained throughout this and other threads, the problem is the Antivirus Software incorrectly detecting a virus in the DLL files and it takes them a few weeks to process the request to whitelist the files. If you have not made an explicit exclusion rule on your side this issue will likely get back to you in a future update that changed the DLLs again in a way that the AV software thinks its a virus again. And then it will eventually go away again as they processed the request.

There is no workaround for this bug. Wait until the needle on the gauge caught up and he stops.

The team and ED first have to design a proper solution. As explained, that file serves a good purpose. This will most certainly not be resolved in a "hotfix", no.

Yes. That cache file remembers the names of all sounds the F4 is supposed to contain. So if you add files with new names, due to that cache mechanism, they are ignored. If your new files replace the existing sound files, i.e. same name, they will get loaded again. I am talking about the new file DCS/Mods/aircraft/F-4E/Sounds/sdef.tar. If you look into the file, you can see it contains all names of the original sound files. DCS uses that file to speedup loading times. If you delete the file your loading times will be back to how it was before the update, but custom sounds (with new names) will be loaded again.

Yes, ED changed something in regards to sound files. There is now some form of cache file in the sound folder to accelerate loading times, but it prevents adding custom unknown sounds. We have contacted ED and are looking for a resolution. In the meantime you can either rename your custom sounds to the original names (they will then get loaded again) or temporarily delete that sound-cache file.

Your impression is incorrect then. Everything shown in the Bombing Table is mandatory to enter and follow. It is just that Dive Toss, for standard attack profiles and low drag bombs, generally is quite forgiving and often ends up close to the default values.

Not yet. But most other BITs are (for example HUD or Pave Spike).

It is technically possible to add one of the existing Anti-Ship-Missiles to the Viggen instead and make it compatible with the aircraft. This weapon would then obviously lack all the unique features of the Viggens missiles and just be, well, one of the existing ASMs and thats it. This option is currently not considered by the team and instead HB and ED pursue transferring the weapons to ED to address this issue.

It is a technical limitation of DCS and a consequence of the fact that the weapon is run by Heatblur code instead of ED code (unlike most other weapons in the game). The only way to get rid of this issue is by having ED implement the weapon fully on their side and Heatblur then switching over to EDs code instead. This is of course planned and will eventually be done.

Its field modifications done to prevent the buttons from falling out during a catapult launch.

It is a button only, it can be pressed. The secondary functions are not about "weapon selection" but rather "weapon related". While hold down it enables slewing for Mavericks and Sidewinders. See the manual for details: https://f4.manuals.heatblur.se/cockpit/pilot/stick_seat.html#air-refueling-release-button

Great! (also, first try - yay [emoji16])

No, these methods are in the DCS SDK, C++ sided.

For cold start, yes. As per proper checklist.

Track file would be preferable, ideally in Caucasus. Thank you

(Windows usually resolves the english name for these default directories correctly as well)

He is not supposed to repeat it, only mention it once when the gauge displays a value that, compared to your altimeter readout, indicates a leak. It is a bug and not intentional.

Fair, so the same but the other way around So the way this works is, if you check the bind_dsl.lua file you can find the code for the function being used here (switch_3_springloaded_down). It first forwards to another function (switch_3) which sets up the following binds (in the typical DCS syntax that you might know from other aircraft): local binds = { pos_neg_1 = { name = _(name .. ' - ' .. pos_neg_1_name), value_down = -1, down = command_id_position }, pos_0 = { name = _(name .. ' - ' .. pos_0_name), value_down = 0, down = command_id_position }, pos_1 = { name = _(name .. ' - ' .. pos_1_name), value_down = 1, down = command_id_position }, pos_3_way_up = { name = _(name .. ' - ' .. pos_1_name .. '/' .. pos_0_name .. ' (3-way up)'), value_down = 1, value_up = 0, down = command_id_position, up = command_id_position }, pos_3_way_down = { name = _(name .. ' - ' .. pos_neg_1_name .. '/' .. pos_0_name .. ' (3-way down)'), value_down = -1, value_up = 0, down = command_id_position, up = command_id_position }, } Then it may add inc/dec binds to the mix: binds.dec = { name = _(name .. ' - ' .. dir_dec), value_down = -1, down = command_id_inc_dec } binds.inc = { name = _(name .. ' - ' .. dir_inc), value_down = 1, down = command_id_inc_dec } A "next" bind: binds.next = { name = _(name .. ' - [Next]'), value_down = 1, value_up = 0, down = command_id_next, up = command_id_next } And an axis bind: binds.axis = { name = _(axis_prefix .. name .. ' (Switch)'), action = command_id_axis, category = { axis_categories.switch } } Finally it gets back to the previous function which has the override for the springloading: local springload_override = { binds = { pos_neg_1 = { name = _(name .. ' - ' .. pos_neg_1_name .. ' (Hold)'), value_up = 0, up = command_id_position }, pos_3_way_down = { remove = true }, } } On the C++ side the command being used here is device_commands.CONTROLSURFACES_BrakeExtendRetract So thats the command that those binds send, they send it to the device: devices.CONTROLSURFACES The value being send over that command indicates the position for the switch. -1 means switch down (in this case the in-game AFT, i.e. extend). 0 is switch center (in-game center, i.e. stop). +1 means switch up (in-game FORWARD, i.e. retract). In the LUA value_down is the value send when holding down the keybind and value_up is the value send when releasing the keybind (this is what makes springloading work). Functionally the binds you want are both identical as the springloading comes from your IRL equipment anyways. So what you want is a bind that sends value 1 (extend) on value_down and value -1 (retract) on value_up. You would then bind this to both of your IRL positions (AFT and FORWARD). Long story short, try adding this line to your default.lua: { name = _('Speed Brake - Out/In (3-way up and down)'), down = device_commands.CONTROLSURFACES_BrakeExtendRetract, up = device_commands.CONTROLSURFACES_BrakeExtendRetract, value_down = -1, value_up = 1, cockpit_device_id = devices.CONTROLSURFACES, category = { categories.flight_controls, categories.throttle } }, This is the ordinary DCS syntax for binds, a bit easier to use for small additions

Sounds to me like you have a bind issue. Check your control binds. The Jester Console is by default RCTRL+L iirc (or was it RCTRL+C?) The Jester Wheel (is that what you mean by menu?) is by default bound to A. Make sure whatever you are pressing is not accidentally bound to the wrong thing.

FYI the problem self-recovers and only happens when you hotstart in-air at a specific altitude range. Once the cabin pressure stabilized for the given altitude Jester stops screaming. So you just have to give him a few minutes (or not airspawn).

So: * IRL Forward (springloaded to center): Extend * IRL Center: Retract * IRL Aft (not springloaded): Extend Then you are missing a position to hold the speedbrake at the current position and it can either go extend or retract. Did I get this right, is that what you want?

The repo is currently private but will go public soon after Cobra figured out some last legal topics. It contains all the source files.

I would recommend this: https://f4.manuals.heatblur.se/dcs/controls.html#binding-guide Also, make use of the ingame category selection if you have trouble finding something. The categories for the Phantoms binds are quite exhaustive.

Sure. But its low on the prio list. Except TL the missing modes were all exclusively used for nuclear ordnance anyways.