Zabuzard

Make sure you click with your (real) mouse into the field first so it gets keyboard focus.

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

It will be available with the next update :)

Hey there, this is a known issue. It can safely be ignored for now. Fortunately, modern browsers are resilient enough these days.

Yeah, this has been reported somewhere already. Its on the list, cheers 👍

Note that you can "read" the target altitude also through the antenna elevation symbol plus the distance. All crew trained to do this within seconds so they can leave the Aspect Knob to display Vc the entire time (the single most important value).
The rule of thumb for that math is: delta altitude = antenna angle * range
Example: target at 10nm, antenna elevation pointing 5° up, gives you 5 * 10 = 50 (x100) ft. Your target is 5k ft above you.
But as said, there is a plan to provide the info you are looking for. Likely through some sort of a "Hey Jester, where is the target?" thing - which would then also work in other contexts 🙂 

For the tracks to work you need to enter the bombing table details during the track again. Because their input is not captured by DCS tracks. If you do not do that, it is as if you never used the bombing table and hence your bombs drop immediately.
You can for example press ESC during the track replay, then enter the details quickly and hit "tell jester" and then it will work.

Sounnds like you opened the Jester Console (RCTRL+L), not Wheel (A).
Please doublecheck your binds, thanks.

Mind sharing the mission file or a short track of your attempt? Im sure we can easily identify whats going on that way 👍

The bombing tool does not include loadout currently (for technical reasons). You have to add that yourself.

Yeah that's what I meant. I believe this video was edited and did not have the tone in the actual gameplay either.
(I remember people talking about it on Discord when the video came out)

Offset mode utilitizes the INS data, so your speed and altitude is not of a concern as long as it matches the speed and altitude you used when computing the drag coefficient right at the moment of release.
But yeah, this mode is more meant for attacking perhaps a factory facility or something - and ofc with multiple other F-4 in trail 🙂 
Same here, also based on INS. So you just need to ensure your profile at release matches the data you used during planning or the weapons ballistics will be off.
By the way, you do not need to visually see the target as long as you have another way of determining you are right above the IP. So if its a landmark or you use your TACAN or a waypoint (ofc a bit less accurate) you can also use laydown mode without seeing the target. The technique with depressing the sight and pressing the button once it aligns with the target is very neat but optional - it is just one of many ways how you would know that you are right above the IP.
Should be, yes. Maybe someone else from the team can provide you some details on it.
Yes. Essentially all bombing modes in the F4 are fully implemented. There are currently no known bugs with them. (The bombing tool has some known bugs though, but not the systems in the aircraft).
Worth noting that a lot of the loft modes are meant for nuclear delivery and hence do not need to be very precise. Since they are all timer based and not using the INS you indeed need to fly the profile accurately all the way.

Are you sure you actually have to hit the lower part? Afaik the full center area is clickable already.
That said, there is also an extra back bind. And if you hold the Jester UI Action bind (A) long, it will close the wheel (no need to navigate back all the way).
Worth noting that you can adjust the sensitivity in the special settings (max angle).

CAGE mode is a pilot controlled "panic" radar override (for when you get jumped by Migs). It is 5nm only.
You need to explicitly leave CAGE mode again to get back to the normal radar modes. You do so either by moving the Weapon Knob in or out of the B position or the WSO needs to press the A2A button. Jester can do latter if you press the context button twice.

That wont help you much as the update included many more changes than swapping out a few sound files. The entire code was changed and improved. So replacing sound files would not give you back the old behavior.

It is a limitation of how the Jester Wheel is currently coded. I.e. it is missing another page.
UI aside, there is no limitation.

The aircraft itself isnt able to store waypoints (besides one) anyways. Jester memorizes them and enters them as you fly around (leap-frogging) :)

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.

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

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 🙂 

There is significant smoke ingame since launch already for cartridge start.

Not as heavy as in the video but that is due ti engine limitations. The graphic effect glutches out heavily in DCS if yiu try to reproduce the look of the IRL footage, it looks extremely silly.

But again, there is plenty of smoke already ingame. The rest of what you said is partially modeled already as well and more is planned for later.

Yes, that is correct behavior.
The Pave Spike goes upside down, unlike the Lantirn.

Its on the list, cheers

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).

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 👍

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.