Jump to content

toilet2000

Members
  • Posts

    408
  • Joined

  • Last visited

Recent Profile Visitors

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

  1. Not at all. It'll display all detected targets, be it moving or static.
  2. Already posted a request some time ago, so I'm going to link it here to keep track:
  3. What I'm saying is not that it is not a 3D problem, just that making some hypothesis or constraining the problem to "the target has to be on the ground given a certain DTED" or "the target has to be at system altitude 0", it can be solved as either a 2D or 2.5D problem, meaning there exist additional equations to solve the problem. Also, as I hinted at, using multiple measurements can also solve the problem without additional receivers. I'm not talking about what it's currently doing in DCS (we don't know that) or what it's doing IRL (I and probably no one here knows, and if they do, they probably can't talk about it here). An under-constrained problem can be solved with multiple measurements under some state constraints. That's a possible answer to OP's question.
  4. AFAIK, the problem doesn't need to be a full 3D problem at all. Either through a digital terrain elevation database or simply a sync'd target altitude between the different receivers (F-16s in this case), this adds a constraint to the height dimension which could be used to solve the problem. There would be a positional error associated with that, but that error could very well be within the accuracy of other parts of the measurement system. Also, there is no requirements for a single measurement. Assuming a certain "target" or emitter model, such as a static one, we can take multiple measurements where the different position solutions for each combined (over all receivers) measurement can be filtered by their state properties. For example, a target assumed static (as would be the case for an SA-10 search radar for example) should move very little over multiple combined measurements and that movement should be somewhat random since it would be linked to measurement errors and noise. Using @KlarSnow's example, even with 2 receivers, only one of the 2 position solutions for the emitter would stay static over time, the other position solutions (intersections of the circles) would move w.r.t. the position of the receivers, not w.r.t. the position of the emitter only. I might definitely be missing something though, so feel free to correct me.
  5. As far as I've read, you're absolutely right. My apologies for misunderstanding the -34.
  6. Page 1-86C describes what "lockon" means in this context. It is not performed by the WSO and is automatically done to provide ranging information. It is again very similar to the A-4E where the radar scans the range gate until a significant return is detected along the boresight line. It does not do any angle tracking.
  7. Yeah, but some unofficial sources says it may apply to non-CUDA workloads also... So maybe? My guess is that DCS perhaps uses the IDXGIAdapter3::QueryVideoMemoryInfo method or a similar way to get the DXGI_QUERY_VIDEO_MEMORY_INFO struct which contains the `AvailableForReservation` field that it could use to infer the amount of VRAM to reserve. See: https://learn.microsoft.com/en-us/windows/win32/api/dxgi1_4/ns-dxgi1_4-dxgi_query_video_memory_info If `AvailableForReservation` changes according to the system memory fallback option, then it could really be that it isn't a placebo. I'll see if I can get a confirmation of that later today.
  8. I would have to test it, but if this work, my guess would be that DCS asks DirectX for the available VRAM, which would return the total GPU VRAM if the driver implements system memory fallback is enabled, but the available VRAM (total VRAM minus current usage/reserved memory) if it is disabled, meaning DCS will never force a VRAM-host RAM swap of the VR runtime. This is if it actually works, as this setting is labeled as "CUDA" and therefore I would assume this might apply to CUDA workloads only and perhaps not DirectX/OGL/Vulkan workloads. We often see the placebo effect in action when it comes to DCS and VR performance. I'll check if I can find more info on that option and the possible DirectX calls DCS does to find the available VRAM.
  9. 1F-4E-34-1-1 (April 1979 with latest change in December 1986) page 1-119 and 1-120. Not sure if I can post any images or details since the revisions are post 1980, but it should be very straightforward for you to verify. What @Northstar98 said is the gist of it and 100% accurate. You can definitely bomb à la A-4E in the DSCG F-4E that we'll get in DCS initially, without the WSO locking the ground.
  10. Dive Toss and Dive Level both don’t require the WSO to lock the ground with the radar. It works extremely similar to the computer bombing mode of the A-4E: you point the pipper at the target, pickle and then either proceed for a toss or a level bombing. Bombs are released automatically using the slant range from radar ranging at the initial pickle.
  11. For me it was still very much present in 2.8.
  12. Given that OpenXR supports hand tracking directly (hand tracking extension), be it through Leap Motion or from headsets that support it such as Quest/Quest 2/Quest Pro/Quest 3, it would be a lot easier to use hand tracking in DCS if DCS supported the technology through OpenXR instead of proprietary hand tracking solutions such as LeapMotion/Ultraleap.
  13. Considering the Hornet is built around MSI, it would be surprising if a track jumped between bin changes. To the opposite, a very basic linear Kalman target state estimator would smooth out these jumps given the high range measurement uncertainty (variance). My guess would be exactly as is currently: raw hits jump, tracks are smoothly interpolated.
  14. It stutters pretty badly for me on an i7 12700KF, 64GB of RAM and a RTX 4080. A "low fidelity" checkbox required for such a rig… I wouldn’t call that low fidelity. There seems to be something more than not having a beefy enough rig.
×
×
  • Create New...