Frederf

Whoops, forgot file F16 VRP 12-6B.trk

My track does. I probably moved too quickly. I also didn't make too much fuss about the precision as my slews were very large. I'll make another slower one. I never saw the Syria track because it requires that I own the Syria terrain to view it. Be aware there is another bug related to the radar where it doesn't move the imagery properly until 1 or 2 azimuth sweeps are completed. The cursor will appear to "snapback" after slewing until the picture updates which makes refinement of the cursors more difficult to do precisely as it would otherwise be. The cursor placement isn't as it appears until you allow the radar to do 1 or 2 passes after the last time you slewed. DCS radar doesn't do FTT mode fully yet. The TMS forward from GM/GMT/SEA produces a sort of middle ground freeze that I've seen documented for AGP-66 MLU radars. Proper "full" FTT completely blanks the display except for the target diamond and crosshairs and is in a B-scope format not PPI. But to your question, with MARK DED page open, TMS aft should not change the selected marking sensor as it does. TMS forward should not record coordinates onto the next markpoint slot until the radar is already in the locked state. I.e. the first TMS forward from a searching GM radar would enter a track mode and only the second would record coordinates for the mark point. In this way the radar can be locked/unlocked any number of times without recording coordinates. Pressing TMS aft should have no effect on the mark mode as it is strictly a radar control input at that point. It should not change the marking sensor to HUD. The only way to do that directly would be to SEQ from FCR to HUD. F16 FCR mark and CZ2.trk

Provided track has TGT defined by STPT 1 center of runway ahead. RP is defined as 90.0°T 6000' relative to TGT/STPT. RP is selected as sighting point. On run in TD box is seen geographically correct as target at center of runway and steerpoint. RP diamond is seen geographically correct as one mile east. However CCRP aiming is directed in error toward RP and bomb delivered normally lands at RP location. This should never happen as OA1, OA2, RP, or IP are never the weapons target and no bombs should be directed at them in any circumstance. What should happen as RP/TGT are cycled is that ASL remains unchanged as aiming direction towards target location. Sensors follow sighting point, ASL doesn't.

I'm getting a crash on sighting point change too: https://forums.eagle.ru/topic/287564-crash-cycling-vrp-sighting-point/ I don't believe that crashes have a saved track. In several important ways DCS VRP and VIP is working correctly and in several important ways it is not. Judging by the "IP" on OSB10 label you are in VIP mode, not VRP. But in either mode the IP/RP and the TD symbols should move smoothly and continuously while slewing the TGP. The symbols should always be pointing at the sensor sighting point at all times. Pressing CZ should cause both symbols and sensors to jump back to their zero-slew positions together. Here is a track demonstrating how the symbols should move together with slewing. By changing the sighting point the sensors will jump to the other sighting point. This is normal and correct. What is incorrect in the attached track is that the weapon aiming cues (ASL, etc.) are changing based on the sighting point selection. In the real airplane the weapon aiming and weapon delivery are always to the target, regardless of sighting point selection. In VIP there is some navigation to the sighting point but never, ever weapon delivery. F16 VRP 12-6.trk

Have you seen my track? It's an example of an FCR mark and mark was accurate.

Example track which should show "F" as the slant range sensor source (AG, CCRP, FCR GM primary sensor). F16 Slant Range F.trk

CZ, not FZ

TARGET is able to program any selection of supported devices which I believe includes the Cougar throttle. It might depend on how it's connected. I would recommend getting a powered USB hub. The Warthog throttle uses quite a bit of power, more than the Warthog joystick possibly due to its lights. A passive USB hub often doesn't supply enough electricity. Also, USB power saving should be disabled to ensure the USB port doesn't go into low power mode:

DMS down will bounce SOI between the two MFDs if both are selectable. The first DMS down chooses the priority format depending on what you're doing. Sometimes SOI is restricted to a particular display or in some cases there is no SOI allowed at all. When HUD is SOI an * will show on the left side.

I'm not sure if our TGP is supposed to have the NV pointer or not. In some TGP the PTR option is selected on OSB2 which is where we have the AUTO/MAN option currently. In this later TGP 2x TMS right is the hands on shortcut to cycle through the three options: designator -> pointer -> both. Also in this later TGP the TMS left x2 cycles between IR and TV for TGP. TMS left x1 is for cycling between IR BHOT and IR WHOT. In DCS the cycle is a simple IR B -> IR W -> TV without the double tap. The TGP is capable of producing up to three laser wavelengths: 1.54 micrometer training designator, 1.06 micrometer combat designator, and ~900 nanometer NV pointer. The training/combat designator are for weapon or LSS designations and are invisible when viewed through NVGs. The training wavelength is eye safe at a closer range and is used with special practice LGB rounds. The training/combat selection is cycled on the laser DED page. The NV pointer works regardless of the laser arm switch and produces alone or simultaneously with the designator laser a visible laser beam when viewed through NVGs. It's good for pointing things out to others at night.

It might be related to the above double-movement. That should only apply in FZ though. Another thing might be that you're not CZ'ing after selecting the new markpoint. This would cause initial cursor placement to be mark point plus previous slews. Here's a track of an FCR GM mark involving slews. You see that when I select STPT 26 the cursor jumps away due to my existing slews. When I press CZ the cursor returns to the location that I marked. F16 FCR mark and CZ.trk

I believe there is a bug where if HAD locks an object and the object disappears it's not able to be unlocked. Notwithstanding simply making TGP SOI should break any and all other tracking sensors and make TGP the SPI-providing sensor immediately. I had a look at your track. It's not just TGP that's stuck. Any attempt to move SPI is impossible. HAD seems to be acting as SPI generator during attack (not sure if that's accurate) and not giving up SPI control as it should (definitely wrong).

The input signal to response is part of the FLCS code itself internal to the airplane. The idea is that because the SSC is a force transducer sensor some breakout force before anything happens makes sense. Otherwise the lightest touch on the stick (or any miscalibration or signal noise) would be providing input further down the logical path. ED is faithfully recreating the FLCS laws of the real airplane. However almost none of us customers have physical controller hardware that mimics the genuine SSC in this way. Most have displacement (not force) as the driver of the signal which comes with its own mechanical breakout force requirement plus we always have the option to add additional deadzone in options. I agree that viewed holistically the ability to alter the FLCS laws to remove this breakout part of the response function and replace it with any amount of deadzone would more faithfully recreate the control experience. In the absence of a first party modification it's theoretically possible to create your "negative deadzone" with the appropriate joystick programming software. I don't know if TARGET has the fine control needed but a custom curve where 0=0 and the smallest deflection resulted in a large jump in output (to the FLCS breakout threshold) would effectively erase the breakout part of the FLCS response.

Can't look at it because I don't own Syria. Can you describe it or recreate it with an included terrain?

It has worked for the past three years and it works right now. There's nothing to fix. Set the moveable pipper to -1.5° manually or use the -1.5° X mark on the fixed reticle as your radar boresight reference.

I do find the nose wheel pivots according to steering and reversal is not instant. Keeping rolling, avoid sharp turns, and allow some room for reversal. It can get scary with the deck edge near and the caster a mind of its own.

Keep a point nearby. If your FPAS point is off the coast of Africa (0°N 0°E) that's quite a distance.

I attempted to takeoff according to MiG-21bis Pilot Flight Operating Instruction, Day Circuit Flying, Concrete-Runway Takeoff without much success. ISA atmosphere, no wind, no stores, 50% fuel (7500kg) as assumed to day circuit flying training. Expected Engine stabilized at takeoff power setting before brakes release Upon 150-200 km/h control stick back 75%. Upon 250-270 km/h nose wheel unstick. Rotate to takeoff attitude: base of pitot at horizon, UUA-1 11-13°. Upon 340-360 km/h main wheels unstick. Retain liftoff pitch angle without airplane tendency to balloon or stall Retract landing gear at 10-15m height Retraction of flaps below 100m involves a controllable nose down moment No significant difference is expected with ventral tank, and up to two missiles or two UB-16 pods Unstick speed and takeoff length increases with heavier loads Manual Chart 8500kg, 11°, 760mmHg, 0m/s = 340 km/h unstick (320 km/h at +2° UUA) 8500kg 345 km/h unstick, 725m run, 900m rwy req., +10-15% reheat, +20-25% full throttle Actual Full throttle take off is impossible without grossly exceeding safe pitch Nose wheel unstick at 290 km/h lightweight (7500kg), 305 km/h medium weight (9300kg), 308 km/h heavy weight (10400kg) If pitch of 4-5° is used, UUA-1 is 11-13° and base of pitot at point of vane attachment is level with horizon If pitch of 7-8° is used, UUA-1 is >15° and base of pitot support boom at attachment to fuselage is level with horizon 8500kg passing 834m is only going 257km/h in full reheat. The idea of unsticking with full throttle takeoff at 11° UUA-1 within 906m run as predicted is unthinkable. With lightweight (7500kg) config the following are unstick distances and speeds at full reheat for nose wheel, main wheel with 5 degree technique, and 8 degree technique respectively. NWU 992m @ 290 MWU-5 1850m @ 374 MWU-8 2080m @ 378 === Acceleration of airplane during takeoff roll is insufficient to meet documented performance. UUA-1 produces too high of a reading at takeoff attitude or takeoff attitude does not produce a takeoff Takeoff run distances in some configs are approximately 200% of their charted values

https://apps.dtic.mil/sti/citations/ADA044697 https://apps.dtic.mil/sti/citations/ADA044698

Did you merge the old and new folders together?

Above that speed FPAS gives up because you're clearly not trying for fuel economy. You'd just be getting alerts all the time and maybe the prediction isn't that accurate beyond a certain speed. I don't know why it prevents you from changing the reference point as a design decision though. Lot 20 is pretty old. Computational resources could be pretty limited.

Yes it's 300 meters from Ka-50 (before DCS World) or possibly Flaming Cliffs. Makes sense that a helicopter being cleared to such a small height.

Look in: \Mods\aircraft\F-16C\Missions\Training\lessons.lua That determines the order items are listed in the UI. File 2-6 is lesson 1-5 File 6-9 is lesson 11-14 File 10-16 is lesson 17-23 File 25 is lesson 25 Lots of gaps.

AGL has a minimum value that is above the surface. MSL's minimum value is at the surface. They are different behaviors but I doubt it's a bug. The MSL floor used to be the same as the AGL floor many patches ago but it changed. Probably this happened because the waypoints of sophisticated airplanes were taking their vertical position from the waypoint Y values and this was a big annoyance when trying to attack said points. I don't see why the AGL floor value isn't 0 as well. I suppose it's to prevent setting very low AGL flight plans and opening bug reports when the AI wouldn't fly that low properly.

Rockeye doesn't have any electronic interface. It's just a metal lanyard (or two). Nothing on the weapon accepts the voltages of the FFCS.