Jump to content

Star57

Members
  • Posts

    21
  • Joined

  • Last visited

1 Follower

Personal Information

  • Flight Simulators
    DCS World

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Good call! I tested again with 1LOOKRAID enabled, and the 0 alt label is displayed for all non L&S/DT2 trackfiles. Track for this here: f18twsincorrectlabel1lookraidenabled.trk The other unexpected difference, and likely what caused this to not be reproduced on your end @Lord Vader, is that the 1LOOKRAID option looks to be persistent through mission restart, so the original track would've had that option disabled. I also tested the other issue which I reported in a separate thread (STT not going into memory/dropping when it should) in the following trackfile, and as soon as 1LOOKRAID was enabled, this issue returned. Shown in this track: f18twsincorrectlabel1lookraid2.trk f18twsincorrectlabel1lookraidenabled.trk
  2. Hi, I'm on the latest Open Beta, I launched the game just now and ran both this track and the track for the other bug I reported, and for me, both tracks did not show the issues. I then attempted to reproduce both issues in game, and neither would occur. As I created these tracks after a couple of hours of gameplay on a multiplayer server last night, I will attempt to (roughly) reproduce the conditions and the issues. If this succeeds then I'll run a repair and try again. For reference, this is what the "0 altitude" trackfile looked like:
  3. Track attached below, Steps to reproduce: 1. Enter TWS mode with at least two targets within your search area 2. Build two trackfiles on these targets 3. Observe that the target which is not an L&S has an incorrectly displayed mach/altitude label, displaying nothing for mach and "0" for altitude. Upon switching L&S to the second trackfile, its labels will display properly, but the first trackfile will now display nothing for mach and "0" for altitude, unless the cursor is placed over it. f18twsincorrectlabel.trk
  4. Track attached below, Steps to reproduce: 1. STT an airborne target (HACQ, AACQ, doesn't matter) 2. Exceed gimbal limits by flying past the target 3. Observe that the displayed symbology indicates that the locked target is not in memory mode, and will not time out to drop the false lockf18sttnomemory.trk
  5. When attempting to lock a target with HACQ, often the following chain of events happens: User places HACQ circle around target TD box is generated in a position not associated with any actual game object HUD/HMD shows an arrow pointing towards the TD box, which is static in relation to the aircraft HUD/HMD still shows the HACQ circle and "HACQ" text, though it is now non-functional and will not lock up a target ATTK RDR page shows ACM GUNS scan pattern, though it moves to some degree with head motion (this scan pattern is non-functional and will not lock up a target) ATTK RDR page shows a fake target in a position different than the TD box. The mach number and altitude of this fake target will change according to your plane's current speed and altitude (if the false target is initially 4,000 feet above you and you climb, the fake target's altitude will increase to stay 4,000 feet above you) The current issue makes it frustrating to use the helmet acquisition modes in the F/A-18C, as you cannot rely on it to work when it should. Attached below is a track using an AI F-16CM as an example adversary. It is not equipped with a jammer nor does it have any chaff. The failed lock occurs in lookup against clear sky, and against a hot target. hornet HACQ issue.trk
  6. Just to clarify, I don't have an FSSB stick either, rather a normal Virpil WarBRD base which is not force sensing. My axis bindings for my stick (saturation, curves, deadzone) have not changed since the patch where roll inertia was behaving as expected (with no inertia upon stick recenter), other than setting a deadzone of 22 in roll for the express purpose of recording that track, to ensure that releasing the stick returned the stick to the center position practically instantly.
  7. In which case, for some reason there is a difference between roll inertia between the two of us, although we are both on the latest Open Beta, as you have stated. I would like to point out that there is still an issue here, whether it may be due to some obscure reason or not, as I don't see why else we would have differing roll inertia between me recording a track and you taking control of that track.
  8. Given the recent developments, could we get some clarification on this, seeing as a difference in roll inertia has been observed between us for whatever reason? Which roll inertia value has the SME deemed to be correct, the one as represented in my track or the one that you have perceived in your version of the game?
  9. Extremely unlikely, seeing as the patch prior to the FLCS update with corrected roll rate had the correct roll response with no inertia.
  10. Please swap my F-15C slot from TAW_Luminary to TAW_redcoreSix TAW_Luminary Mirage 2000C
  11. I did some testing using a regular stick (Virpil WarBRD base), using a deadzone of 22 to ensure accuracy when returning to center. The following track shows roll inertia after return to center position, control display is visible in the track. viperrollinertia.trk
  12. TAW_Luminary F-15C TAW_Spectrum F-15C
  13. Below approximately 5,000 feet, both radar detection range and radar tracking range for a target in lookup suffer a severe range penalty, which increases in severity the lower the altitude you fly at. For example, the range at which you are able to bug a target in SAM mode is approximately 38NM at 5,000 feet. This is reduced to 14.2NM when flying at less than 100 feet. Bugging a target at a higher altitude and descending to the deck results in the track being lost, regardless of whether the track was in SAM mode or STT. Testing was conducted over the water, using a target F/A-18C Lot 20 flying hot 40,000 feet above the player aircraft. If the player aircraft was at 5,000 feet, the target would be at 45,000 feet, etc. Included is a control test at 10,000 feet, showing a normal (maximum) detection range and bugging range. viperlookupdetectionandtrack100feet.trk viperlookupdetectionandtrack10kfeet.trk viperlookupdetectionandtrack5kfeetdescent.trk Attached is another track which couldn't fit in the original post. viperlookupdetectionandtrack2kfeet.trk
  14. The yellow AZ/EL radar scan coverage box is larger in the vertical than the actual radar scan coverage. To reproduce: - Use a mission with an AWACS and a non-maneuvering target within radar range to see target's actual altitude on Link 16 - Use antenna elevation to place the target just within the vertical limits of the AZ/EL scan coverage box - Observe that the target is not within vertical scan coverage limits on the ATTK RDR page, and as such is not detected by radar, but is shown as within the scan coverage limits on the AZ/EL page Track attached below. hornet AZEL coverage bug.trk
  15. When you can see a jamming contact as an Angle Only Track, displayed in the dugout for the ATTK RDR and SA page, the bearing displayed for the jamming contact in the SA page dugout changes as you change the scale of the SA page. It seems that the further away the jamming contact is, the more significant the change in bearing is when you reduce the SA page scale. To reproduce: - Find a jamming contact with radar outside burnthrough range - Look at position of jamming contact on SA page dugout - Reduce SA page scale and watch jamming contact bearing change Track attached below. hornet SA dugout bug.trk
×
×
  • Create New...