Jump to content

Frederf

Members
  • Posts

    6356
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Frederf

  1. The answer is, yes, if LASR page is "0" and TGP says "1688" then laser emitted is 1688 and will guide a bomb. I like to think that pilot is telling airplane a code and then airplane telling TGP a code in a chain of command. If airplane value is "0" then airplane is either not sending a code or is sending an invalid code to TGP. In either case TGP is not getting the directive and does something else like last-used or default code which in our case seems to be 1688.
  2. The mission editor weapon laser code will be shown on the kneeboard in flight. It shouldn't be possible for weapon laser code and kneeboard code to be different at any time. The laser emission code will always start as 1688 though so you must make sure to change it to match the weapon laser code. I don't know what the real airplane does for TGP CODE if it's not specified in DTC or DTC is not loaded. It might have an OFP or even TGP-defined default plus either of those systems might have a memory to retain the last loaded value. It's clear from the MFD setup and flight plan that the DCS module isn't simulating an airplane which has not had any DTC load. It's glossed over which is certainly practical but not rigorously real. Defaulting the laser code to match the editor weapon code (but not post-spawn pilot kneeboard changes) seems reasonable but no particular arrangement is exactly wrong. Thankfully no matter what the default is, matching weapon code is a quick task.
  3. When OSB 19 and 20 are pressed and the scale changing option is currently automatic the radar should change to manual scale changing option and perform the scale change associated with the pressed OSB. Currently presses of OSB 19/20 in automatic scale option causes the radar to remain in automatic scale option and the range change to be rejected. F16 scale OSB press in AUTO.trk
  4. Currently "AUTO" is displayed when manual range switching option is in effect and "MAN" is displayed when automatic range switching option is in effect. The labels should reflect the currently selected option. F16 scale MAN AUTO.trk
  5. Currently GM range is automatically changing based on cursor position while slewing. Automatic scale change should only occur when slewing stops. F16 scale changes cursor deflected.trk
  6. In freeze mode the radar is currently automatically changing display range scale. For auto scale the range does not automatically change until freeze mode is deselected. F16 freeze scale changes.trk
  7. With freeze mode radar display in which the ownship marker is displayed, the marker position is not displayed relative to the expanded radar imagery accurately. In the attached track the marker indicates ownship is directly over the bridge/steerpoint on the FCR display but the actual ownship position is a few miles away. This occurs using freeze in all EXP/DBS1/DBS2 modes. F16 ownship marker expand.trk
  8. Ah, I think I've found out what the solid-diamond v. hollow box is. If you haven't slewed and SPI is on steerpoint then designation designates the steerpoint location as hollow box. If you slew some cursor deltas in away from steerpoint and designate it is a solid diamond. I guess it lets you designate the coordinates in the jet directly instead of attempting a radar track. The coast solid-square is something else and would be in place of the solid-diamond during a brief loss of track.
  9. GM sees and tracks moving targets just fine except for DBS which tends to blur out motion. SEA doesn't get DBS modes probably for that reason. FTT isn't really in right now in the sense that it actually tracks objects. Despite the "F", FTT tracks don't have to be stationary. FTT is the tracking mode associated with mapping radar modes other than GMT (which gets MTT). GMT filters out stationary but GM does not filter out moving. We have a sort of freeze mode designate instead. The antenna markers are jittering like they're doing real FTT but it's clear it's not tracking a ship which will move away from the diamond. I don't know if FTT is happy to track a truck going down the highway at 120 mph but a ship at 17 knots is fine. I was able to detect a Seawise Giant at about 43nm (possibly 80km) beam aspect in GM and the same in SEA. I got the same performance EGM/RBM and gain min/max didn't seem to do anything except change the brightness of the return. My understanding is that radar detection depends on TGP rendering range (or it was). I was unable to see the ship in TGP outside of 80km and when I got closer slightly I could clearly. SEA radar mode is a filtered version of GM. Right now our ocean is jet black no returns in GM. That's reasonable for still water but in poor weather winds make waves and waves make radar clutter. SEA mode is designed to filter out the sea state clutter which is troublesome in GM over rough water. When the ocean is giving no clutter then there's no point in using SEA mode.
  10. There are two course settings for ILS, the HSI one and the DED one, and they're fully independent. For some reason in DCS they are acting semi-connected. Anyway, you've set course 091°. It's more like 079°. You can't trust the ruler or the ME label as those are in true/ruler direction and not magnetic.
  11. That's weird. TMS right cycles the sighting point rotary. The TGP should just follow slaved to the FCR cursors at all times without any input from the pilot. I see how it's doing it in DCS but that's not how I understand it working at all. If TGP is already tracking then SOI away from TGP won't cause an immediate break track but it will if there's any slew/track activity done with the radar.
  12. They will be normally. I heartily recommend this mod which allows custom input lua without having to fix it every update. I put Quaggles itself on a JSGME mod which is easy to restore on updates (dcs_updater will erase it) but the injected lua files themselves are untouched by updating.
  13. In newer F-16 you can CZ with TMS down, but not in this one. You need to press the OSB with the CZ label. You want the diamond, the real track. If it loses track it will coast just like the AA radar will coast if it temporarily loses a MiG-29. The hollow box in DBS2 is something I don't know anything about but consider it the same as solid diamond. I don't see evidence that it is possible to get into FTT-coast so ignore that idea right now. We don't actually have FTT either in DCS right now. It's being modeled as a pseudo-FTT-freeze "first stage" designation which is PPI with static radar image (which is a real thing, at least in -66v2). Designating again would do traditional B-scope FTT display and just the diamond and crosshairs (no image, just like older -68 radars). I don't know if it's correct because I'm looking at info for nearly but not exactly the same -68 info and contemporary -66 info. They are different. The "snapback" feeling is weird and probably wrong. When you stop slewing over a certain frame's image it shouldn't jump back on the previous frame to the old location and then only update on the next frame. The cursors should remain where slewing stopped on the current frame's location and the next frame's update updates the image practically seemlessly. That would eliminate that "snapback" effect which is quite jarring to experience. If you have patience though and ignore the snapback the next frame will be where you left your cursor when you released.
  14. I have two guesses as to how the behavior got this way: The utility light was supposed to work on a/c battery power but implementation took that to mean solely a/c battery power instead of including normal full power. The utility light was interpreted as "stow before takeoff" so developer made the utility light not functional in flight. I'm curious how practical it is to use the utility light in flight. If there wants to be a limiting system then maybe the light can point toward the floor uncontrollably based on aircraft G (e.g. >2G).
  15. When wind display is activated on the ground, the DED CNI page is displaying "DFLT" on line two of the display. This should not occur. "DFLT" is an indication associated with the communication radios and occurs when UFC radio setting memory is lost. Cycling selection of wind display is unrelated. Except when this condition occurs the info box will remain blanked. See -1, "CNI READOUT/DED PAGE SUMMARY" search for "DFLT". F16 DFLT DED.trk
  16. The CNI page line 2 has four boxes to display information: OFF/GRD/BUP/(blank)/(HQ), DFLT/(blank), direction, speed. The first two info boxes refer to the radio system. The second two are calculated wind data. Normally the MMC calculates the wind data based on the difference between CADC airspeed and INS motion. On the ground this calculation cannot be done. The word "DFLT" (default) has nothing to do with the wind display though and shouldn't show up as it does. "DFLT" shows up when the UFC connection is lost and the UFC reverts to default radio settings.
  17. Box is a coast track, diamond is an active track. I can't get FTT to act normally. Every time I designate the radar enters FZ mode instead of going FTT.
  18. The labels have a black outline of 1 pixel to give good contrast against a light video image.
  19. VS and VSR are Velocity Search and Velocity Search with Ranging. Earlier APG-68 has VS, later APG-68 has VSR. Both were an interleaved "alert" scan and a follow up scan in different PRF to detect closing targets. The difference was in display. You don't set APG-68 PRF as a pilot. You pick a mode and it does what it does.
  20. In short, the switch is working correctly. A bit of understanding will help explain why. The F-16 pitch channel autopilot switch is a complicated switch. It's spring-loaded to return to center with solenoid mechanisms to keep the switch stuck in the up/down positions based on computer logic. This means if the switch returns to center when pilot finger pressure against the spring is removed depends on the solenoid state. Your three-way device switch is logically two buttons associated with the up and down positions. With switch up DX27 is pressed. With switch down DX28 is pressed. With switch center no button is pressed. When the solenoids are unpowered the switch will fall to the center position by spring force unless the pilot is actively holding the switch with his finger. DCS is interpreting buttons 27 and 28 as the pilot's finger pressing the switch into the up and down positions. Releasing button 27 (28) represents the pilot ceasing to push the switch to the up (down) position. DCS is not interpreting release of those buttons as is actively returning the switch to center by force. Ceasing pressing the switch results in the switch falling back to center only if the solenoids are unpowered. Of course a real pilot has an additional option: actively grab the switch and pull it to center regardless of the solenoid magnetic sticking. That would be a distinct action like "Autopilot PITCH Switch - A/P OFF" which your controller doesn't naturally have a separate button for. It is possible to construct a DCS action which releasing the button commands the switch into the center position. The "Autopilot ROLL Switch (special) - HDG SEL/ATT HOLD" action is such an example. Because of the complex nature of the switch an explicit "move this switch to center" action wasn't made. Looking at the three commands in the .lua files it looks like there isn't a specific way to get the same behavior. My solution was to write a TARGET script which pulsed the switch on and off and made the center position command the center position with a specific separate button. Usually there is a way to construct custom .lua input actions so that it does something on the down stroke and something else on the up stroke (release). The default commands are: ALT down 1, up 0 OFF down -1, up none ATT down -1, up 0 What you want is some kind of: ALT down 1, up something which makes the switch go to center ATT down -1, up something which makes the switch go to center I'm looking into how to make that. EDIT: OK, it's somewhat simple. The inputs 1, 0, -1 are relative switch movements. +1 goes up a state, 0 remains a state, -1 goes down a state. So this is my Quaggle's custom input section. I hope that helps. return { keyCommands = { { down = control_commands.ApPitchAlt_EXT, up = control_commands.ApPitchAlt_EXT, cockpit_device_id = devices.CONTROL_INTERFACE, value_down = 1.0, value_up = -1.0, name = _('AP Pitch - ALT'), category = { _('Custom')}}, { down = control_commands.ApPitchAlt_EXT, cockpit_device_id = devices.CONTROL_INTERFACE, value_down = -1.0, name = _('AP Pitch - Center'), category = { _('Custom')}}, { down = control_commands.ApPitchAtt_EXT, up = control_commands.ApPitchAtt_EXT, cockpit_device_id = devices.CONTROL_INTERFACE, value_down = -1.0, value_up = 1.0, name = _('AP Pitch - ATT'), category = { _('Custom')}} } }
  21. Check your SMS page. If it says "AAM" then that's the missile submode of the AA master mode. But if it says "MSL" or "DGFT" then you have the override switch not centered which would explain why it's not possible to get into NAV/AA/AG master modes.
  22. FF has a very good correlation to thrust. Between two similar config'd airplanes that should be a decent speed reference. It's not as crazy a technique as it sounds. If one airplane has loads of bombs then it's going to be working harder for the same speed so thrust matching goes out the window. If speed isn't critical setting a FF allows the flight to change speed (climb, descend, turn, etc.) but everyone knows what the score is.
×
×
  • Create New...