Zabuzard

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.

The stick visuals are subject to animation smoothing to ensure it doesnt look silly when you jank around your stick IRL. Otherwise it would teleport and it would look really silly and break immersion. Its a compromise.
Take note that this is visual only, your input is being registered and transferred to the FM instantly. The stick animations are decoupled from that (see the Controls Indicator UI).
Afaik Cobra said some time ago that he might be tuning the animation again to find a slightly better compromise.

Yes, thats a good suggestion.

Unfortunately, not as low hanging as it may sound, mostly due to the jet not having an easy way of understanding what kind of weapon you got. Its absolutely solvable, but would probably take quite some time to develop "just to save u one click selecting the weapon" and then likely still fail you in practice because you may be running a mixed loadout or not having selected the delivery type yet because you are still on the ground.

IRL the "Bombing Tool" math is always done before even entering the cockpit. Its preplanned, you write down your solutions and then enter them midflight.
That was also kinda the idea we originally had with the tool, hence the button to "save a profile". You are not really supposed to click through this UI midflight, seconds before attacking the target.

This is a rare DCS engine bug that we have seen reported a few times since release.

Users reported that running a DCS repair and/or getting rid of certain unofficial mods repaired the issue for them. So Id suggest trying out that :)

Yes to both. But it also depends on the radar selection in the WSO pit. Like, if the radar is turned off, selection of this switch wont do much.
In practice, for most DCS players it is probably best to just leave it on ON. But there are of course situations in which it might be meaningful to have it off (or standby) while the radar itself is still turned on. Also relevant for ground tests (in particular IRL).
Some details here: https://f4.manuals.heatblur.se/cockpit/pilot/weapon_management.html#radar-missile-power-switch
More here: https://f4.manuals.heatblur.se/systems/radar/general_operation.html#klystron

They already do spawn with the ladder out - either the yellow external ladder or the onboard steps, which is randomized.

It is theoretically possible for a mission maker to force the ladder by playing the animations manually. Like, setting the animation for the external ladder to 1 (and the anim for the onboard steps to 0).

As soon as the pilot then clicks on "put helmet on", these "cold items" (e.g. also the red RBF flags and covers) get removed automatically by the code.

I dont exactly recall how you can play animations via mission editor, but its possible. They are not per device like commands, just a global animation ID. You can find them by opening the model in DCS ModelViewer and/or by opening our draw_args.lua file.

This is simply because there are too many weapons available and EDs UI does not feature a scrollbar (yet).
It is a known issue - we cannot do anything here, the UI is completely on ED.
Cheers

Here are details on the CL Lamp behavior:
https://f4.manuals.heatblur.se/systems/weapon_systems/multiple_weapons_system.html#centerline-tank-aboard-light

Do you have some screenshots or anything? Otherwise it is hard to judge how good your contrast actually was.

So far whenever people reported similar problems it turned out to be not enough contrast, so that would be my first guess.

(Note that the contrast locking is an ED topic)

Aye, this is a known bug. Cheers

The kneeboard has tables. Also, you can create yourself tables by using the Bombing Tool (RCTRL+B) - select DIRECT :)

Looks like a crash happening in EDs code. I do not see anything coming from us in your stacktrace:

Might be a non-Phantom specific issue.