[REQUESTED]RCIP/RAUT

[lukeXIII]

Whenever the velocity vector is not intersecting the ground the RCIP pipper behaves as expected and moves up and down according to radar altimeter height (see video 1)

 

However when the velocity vector is intersecting the ground, radar altimeter height stops being used. In the example below (video 2) there should be a rapid change in the RCIP pipper postion due to the sudden change in elevation flying over the dam however this is not happening.

 

What I think is happening: Currently in game the DMT gets the exact elevation of whatever it is looking at. By default the DMT is slaved to the velocity vector, and so the elevation of whatever the velocity vector is looking at is being used in the bombing calculations.

 

When there is an existing target designation, the height is locked to that elevation which makes the radar altimeter height meaningless.

 

Radar altimeter height is not being used at all for RAUT; bombs land on target regardless of varying terrain.

 

 

Edited September 10, 2020 by lukeXIII

[lukeXIII]

I should add that this behaviour is exactly the same for CCIP, BCIP and GCIP (which makes no sense for those modes). The only thing changing in game is the letters that show up on the hud.

[tea_cypher]

Can you provide a track please, do we have any references we can use to show this is incorrect?

[lukeXIII]

TAC-000 pg 492 gives a summary of how the radar altimeter altitude is used for the "height above target". For RCIP the radar altimeter is the only altitude source used to determine the impact location, and hence line of sight angle and pipper location on the HUD. This means that the pipper angle should decrease (i.e it moves up the hud) if the radar altimeter altitude decreases and vice versa.

 

Just to restate from the original post, the bug with RCIP is that the correct behaviour gets overridden when the velocity vector intersects the ground.

 

The CCIP in the a10c currently behaves how the RCIP in the av8b should be. Attached are two similar profiles flying over the dam; the pipper in the a10 correctly moves up and down as it passes over the dam whereas it does not in the av8b. Also in the av8b track you can see that the pipper behaves oddly in a climb which is a result of the velocity vector giving a higher target elevation than the av8bs current altitude.

 

For RAUT (the same TAC-000 page), how it should function is that it should take a single reading from the radar altimeter altitude when a target is designated to determine the "height above target" and then use barometric data for the rest of the run in. Currently the "height above target" is calculated from the exact target designation elevation and the exact geometrical altitude of the av8b which can be seen in bombs landing perfectly on target regardless of errors due to terrain.

a10c_CCIP.trk

av8b_RCIP.trk

av8b_RAUT.trk

[lukeXIII]

This attached track is just to show that cycling through the different bombing modes results in no change to the pipper location (only change is designation/no-designation) meaning that all bombing modes are behaving exactly the same.

av8b_all_bombing_modes.trk

[tea_cypher]

I haven't forgotten this one, just still reseaching.

[tea_cypher]

Still struggling with this, could this actually be ARBS functioning correctly? Calculating the drop based on the info it being given?

Edited September 16, 2020 by tea_cypher
changed my mind

[ChickenSim]

Still struggling with this, could this actually be ARBS functioning correctly? Calculating the drop based on the info it being given?

 

If ARBS is the selected altitude source it should be CCIP.

 

RCIP forces the aircraft to use RADALT as the altitude source. BCIP forces barometric altimeter. GCIP forces GPS altitude. (2-54 - 2-56 TACMAN I)

 

I think what this report is saying is that these modes should both function correctly (I think there are other reports indicating that they might not), and they should continue to function correctly even if the nose is pointed below the horizon/at terrain.

Edited September 16, 2020 by ChickenSim

[lukeXIII]

As ChickenSim stated, ARBS should not factor into this as it a) has not been selected as the altitude source and b) no target has been locked by the DMT.

 

Here's a practical example of attempting to bomb a target at the bottom of a dam using RCIP and mk82 slicks:

 

 

It can be seen that the bomb falls significantly short of the target. Doing a fly by of the designation point created at pickle shows that it is hovering in the air and before the target. The reason for why this designation point was created here and not on the target is because it used the elevation of where the velocity vector was placed which was on top of the dam. The attached images below shows how it is currently working and how it should be working.

 

Also to note on the designation fly by: the RCIP is also affected by the designation point elevation (which is not correct behaviour) as can be seen with an invalid pipper.

 

Just to sum up again:

Pipper location is related to the Height Above Target (HAT)

Current RCIP (no designation + VV not intersecting ground): HAT = RADALT (correct)

Current RCIP (no designation + VV intersecting ground): HAT = Geometrical altitude - velocity vector intersection elevation (incorrect)

Current RCIP (with designation): HAT = Geometrical altitude - designation elevation (incorrect)

 

RCIP should be behaving the same with or without designation and regardless of VV, where HAT = RADALT for all cases

 

 

(Side note: the "HOT" in the figures should be "HAT")

RCIP_example.trk

Edited September 17, 2020 by lukeXIII
Added info

[tea_cypher]

Ok I talked to razbam, and this was the intended behavour, I think what we are seeing here is probably a crude implementation of ARBS, as such its not a bug, but an improvement request. And I will have the thread marked as such, hopefully simce they have a new CM he can look into this, as I will be going on a short brake soon and have alot of fixes to test before next weeks planned OB release.

[ChickenSim]

Tea,

 

It needs to be understood that if this is intended behavior as a crude implementation of ARBS, then both ARBS and RCIP/BCIP/GCIP are incredibly broken and none of them function at all.

 

You're telling us that there is functionally no operational CCIP on the aircraft without the ARBS locked onto a target, which means something is wrong or misunderstood.

 

That has to be a bug report in some fashion. Do we make an individual thread for each of the non-functional CIP modes? Do we need to report the ARBS as both doing the math wrong (the bomb obviously failed to hit, where if ARBS/CCIP were being used it should have) and operating at all times, even when we are specifically asking it not to?

 

If you were trying to turn the radar off in the Hornet and all your missiles and cues were behaving as though your radar was still on (and also missing those targets), the radar is broken, not a "crude implementation."

Edited September 17, 2020 by ChickenSim

[LastRifleRound]

I'm not sure how it could be a crude ARBS implementation. RCIP by definition ignores ARBS. ARBS "ANGLE RATE bombing system" uses angular rates, therefore requires lock. Having no lock with CCIP should use RADALT. In fact, if RCIP is manually selected, EVEN WITH ARBS lock, the ARBS slant range will be ignored for HOT.

 

There are SME's on RAZ's discord who have outlined this in detail, as well as it being detailed just as Luke and Chicken describe it in the TACMAN (one of which is also an SME).

 

This kind of contradicts what I heard earlier. Saying if it's in the sim, it can't be a missing feature thus feature complete. Now we're saying though it's in the sim, it's not a bug but a missing feature.

 

All these semantics are killing us. Perhaps we shouldn't use these vague notions of "bug" vs "feature" to denote priority since no one from the devs to mods to us can keep it straight? I mean it's even possible that a missing feature could be a bug. Did the developers INTEND for RCIP to not function according to the TACMAN? Then I suppose it is a missing feature and not a bug. If they did not, it's a bug. Either way it requires me to know what's in their mind, and they're saying missing feature, so not intended to be operational.

 

It's something in the sim that when you click it it doesn't have the expected effect to those of us who know how it's actually supposed to work. Whatever you want to call that is what we have here.

[ChickenSim]

Tea,

 

Is this something you want to wait until after the next patch to address too? Because this onion can get peeled apart into about 10 distinct bug reports depending on testing.

 

- RCIP not functional in a dive

- BCIP not functional in a dive

- GCIP not functional in a dive

- No difference between RCIP/BCIP/GCIP (that has been tested yet?)

- "ARBS" calculations always supersede other modes in a dive

- "ARBS" functioning without a designation

- "ARBS" calculating release parameters incorrectly

plus AUTO modes, needing testing...

 

It would be really helpful for ELMO to let us know if this is intended behavior that all of these things are happening in their "ARBS" feature, or if this is a heavily bugged/missing feature (both are indistinguishable from each other to the end user) that they are intending to correct, not just "request."

[tea_cypher]

Yes please.