Jump to content

toilet2000

Members
  • Posts

    366
  • Joined

  • Last visited

Everything posted by toilet2000

  1. TSE is basically the core of a ballistic computer. Aiming at a point and getting the range to it with the LRFD should be used in conjunction with the INS to allow the weapons to compensate for the aircraft motion AND the target motion (if you're tracking it via the upcoming IAT or manually). Right now the gun for example will adjust for range, but any type of motion will lead to rounds falling short, long, left or right depending on the motion. TSE should eliminate that.
  2. Resolution not changing does not imply the same return intensity. If the return is very dim at 10 nm, you won't see it at all at 40 nm. SAR is not magic.
  3. Most likely you have an axis bound to the radar elevation and it stays at 0, preventing you from zooming in.
  4. For datalink, you need to press the UFC DL button twice to select Link 16 (once gets you Link 4 for ACLS), and then press ON/OFF to turn it on.
  5. Choosing with WEP selects the right channel and the right pylon to configure on the SMS. Even without a label, select the OSB where the SLAM option would be in the WEP menu still sets the DL channel to that station.
  6. Why would you use SteamVR with an Oculus headset? SteamVR will just eat performance and do nothing more. Use the native Oculus SDK as it is available in DCS. Don't even need OpenXR. Actually running the Oculus SDK implementation with vrperfkit will further improve performance over OpenXRToolkit + its implementation of foveated rendering.
  7. Indeed, it's been doing that for a long time. Everytime the server browser UI refreshes, there's a huge lag spike, as if the UI thread was waiting for a long time for some background thread to sync up.
  8. Yeah that ITAR excuse is really just an excuse. There’s hardly anything done by ED that doesn’t use ITAR covered info. There’s really nothing wrong with knowing ITAR covered information. The issue happen if you are a US person sharing and exporting with non-US persons. There’s nothing illegal about having those document as a non-US person. ITAR is very different (and much more lax) than classifications. At this point it’s just used by ED because it sounds official.
  9. That misconception comes from the fact that the ATFLIR was never really upgraded. The LITENING was first fielded in 1999 while the early ATFLIRs were in 2003 ish. Moreover, IIRC our LITENING is an early AT model (2003 ish), whereas the most well known LITENING is a 2008+ G4 with much better resolution. So for our Hornet, the ATFLIR is the better and more recent pod. For any Hornet after 2010-ish, the LITENING is the better pod because it was upgraded.
  10. Unfortunately the Gazelle is objectively a very incomplete, inaccurate and at this point unsupported module. Be it from RL Gazelle pilots or data-driven analysis. See: The issue is that sharing anecdotical evidence that it is "fine" with changing joystick curves (makes no sense) will lead to very dissatisfied customers. So yeah, I think Tippis has a much more valuable point here than yours.
  11. That’s not part of DCS but rather part of the radar code, which is most often per-module and not DCS-wide. I know Galinette (Razbam’s radar dev) has talked about it.
  12. That's exactly how Doppler notch filters work: that spinny thing has reflective material moving at a very high linear speed, both negative and positive. The issue though is that the return, even though it might have a very distinctive Doppler shift, is fairly small, so in general it's hard to detect a spinning rotor at long range. The shorter range of a missile might actually still be able to see it though. I would assume though that in this case, the AIM-120C just went directly for the last contact position with extrapolation as it should and hit the heli.
  13. You mean like the Hornet? Any modules will have tons of bugs at any time. That's true for any software, especially non-critical ones. Knowing there are issues doesn't make it "worse" than anything else. To the opposite, you might be greatly biases because you don't have access to those bug trackers for other modules. How so? Both work as intended for me.
  14. 90%? Not at all. Most of them are. Nonexistent damage model? On what planet do you live? It's at pretty much the same place as other modern modules. The issue is the WW2 damage model not being available yet on modern jets. If there's lots more, then it shouldn't be hard to list them without using hyperboles like you did.
  15. I can't say I've had that experience at all. Some switches are non-functional like in all modules, but a vast majority of them are. The rudder needs to be sensitive at low speed due to the very small turn radius required for roadbase operations. You can simply add a curve (like with every other module) if it's too much for you. As for bugs, pretty much all of those I had were fixed at the end of last year. Right now it's in a very good spot. I assume some of the issues are not with the module but a meter in front of the screen. Sometimes it's just a matter of learning the module, and the Viggen is very quirky by design.
  16. AI is currently unimpeded by weather. This was the biggest limitation of the new weather effects and engine and ED have said they are working on it.
  17. That's weird, it does work for me. Even if you put the inner radius at some ridiculously low value (like 0.1) it doesn't show any pixelation?
  18. There's a modification of fholger's vrperfkit that might be working for fixed foveated rendering in DCS, albeit with caveats. See: https://github.com/cedriclmenard/vrperfkit/releases/tag/v0.2.2-dcs-ffr
  19. The missiles are always SACLOS. They aren't SARH or ARH. Normally, the tracking radar automatically takes over to send SACLOS guidance commands to the missile, but SACLOS is not a fallback mode for the missile, it's the only guidance mode. The issue is that optical guidance is a fallback mode for the operator, requiring manual target range input. As for DCS, it seems to always use this mode and never use the radar tracking, except for the gun solution.
  20. As stated by @Hulkbust44, missiles can infer a "range" for the control laws by looking at the angular rate of the emitter target. An example of the same logic is seen in the Maverick missile, where it will "loft" a bit before coming down on the target. Real lofting though requires a somewhat precise position, as it is an optimization of several parameters for best kinematic range. You'll in fact see a much, much more pronounced loft at long distances.
  21. You first need to designate a target using the AG radar by depressing the TDC, I think it's called T5 Press. Make sure you assigned it in the controls because for me it got reset in the last patch. Once that is done, you either press the stick switch that changes the radar scale to the left (S2 hat) or you press the "RBM" OSB to change it to EXP then DBS1 and DBS2.
  22. Because the stores aren't mounted on the centerline. It actually looks like the CCIP solution is using 0 altitude (like if you were on the ground) on your images. That huge offset (170 mils) looks a lot like if you were flying basically as close to the ground as possible. I'd be curious to see if mounting only a bomb on the centerline gives that kind of offset too.
  23. No, we don't have an "Old Hornet model", we have a Lot 20 with TAMMAC and all the bells and whistles. Choosing a 1994 date doesn't change the plane, it only makes GPS unavailable. Same goes for the F-14. Changing the date doesn't give you an earlier model. The DIL could very well be displaced horizontally due to incorrect wind calculation, incorrect attitude estimation and wrong altitude. Best example is using Snakeyes, which you will see the DIL jump left and right from each releases at low altitude due to the offset between stores, with the horizontal jump getting bigger the lower the altitude. As I said, there is a bug nonetheless, but it's simply untrue that GPS/INS pos is supposed to have no impact on the CCIP solution. Yes, that's the bug I talked about in one of my previous comment
  24. You really don't understand how the CCIP cross is computed. I suggest looking a bit a the tutorials on the A-10C, as it only uses it's INS/GPS combined with DTED (Digital Terrain Elevation Database) to compute the slant range and point of impact. Old Hornet models used to simply compute the CCIP slant range (and thus the cross position) using the radalt or baro altitude (like the Mi-24) or using the AGR when commanded to (Sensor Select to HUD). The radar doesn't directly need any INS data to compute slant range. Hornets that received the TAMMAC upgrade (like ours, except for the HSI) have the integration of the DTED, meaning the aircraft, knowing its position from the INS/GPS, can infer the slant range by correlating its slant angle and INS position with the elevation database and finding the intersection of both. This gives slant range, but only if the INS is accurate. This is generally not an issue because moments without GPS coverage are often small enough that the INS won't drift enough for the accuracy to be that much lower. The issue arises when you completely remove the GPS on a whole mission with a bird made to fly with GPS and with the DTED integration. TL;DR Yes, the CCIP cross should depend on the INS position when not in AGR mode.
×
×
  • Create New...