Jump to content

TAW_Blaze

Members
  • Posts

    1390
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by TAW_Blaze

  1. Well.. 90% of friendly fires on "DCS MP servers" is just horrid piloting. The real problem is the shortcomings of the EW simulation making the missiles miss in a lot of cases where they should not. Especially in the last months I'm seeing a huge surge of completely suicidal tactics working out far too often.
  2. Not sure to be fair. I've never really spent the time to see how broken it is to use it on 32 sec. I personally found it completely counterproductive to use anything above 8 because your B-scope will be so horribly cluttered you cannot read what's going on. Especially when you're maneuvering to shoot a maneuvering target.
  3. I would see it from a context of the simulation sandbox. Is this parameter simulated in other aircraft? Does it create a relevant advantage? If both answers are no then from my point of view it does not matter. If one developer wants they can always add more realism and hopefully the others will be inspired to continue in their path. If it creates a relevant advantage then it should be reported and fixed and depending on the extent of the advantage banned from competitive plays (i.e. ECM bug in the last months). Unfortunately this is kind of a stupid issue, because there is no way to enforce - think about how they tried banning Hornet memory of 16/32 sec by asking for screenshots / etc. from the user that ultimately proves nothing..
  4. Interesting. To be honest this is not a huge issue to get me into detailed testing, and atm I don't feel confident anymore about what the root cause might be. but I would appreciate it if it was faster for sure.
  5. Then the developer should model the aircraft with it's limits properly. You cannot expect that users know and adhere to non-trivial limitations that even the people with the best documentation available might not know. The best virtual pilots are always looking to excel in the simulated environment and will develop tactics that are effective in the simulated environment (spoiler alert: the real life pilots do the same for the real environment). The simulated environment is always defined by the current state of DCS. The unfortunate side effect that unlike the real world, DCS has bugs (hmm, maybe it could be argued that the real world has some serious defects, especially lately.. :) ). Therefore the environment that's driving the tactics can be impacted by these bugs.. although generally discounting some major issues (i.e. ECM) the fundamental tactics are in principle similiar to real life because the #1 factor is alway reliability. If users going out of their way to creatively macro something that gives them an advantage (not an easy task to do to result in a significant advantage, CM macroing is minor difference in FF modules) then what can we say about people in general not adhering to other basic airframe limits that are also not modeled? i.e. F-16 pulling 9G with bags, F-15C pulling 12G with bags that has been cried over for a decade etc. I generally don't get the point. If someone manages to find a way to break the game via macros it should be reported and fixed by ED. Period.
  6. Following that logic snap views and TrackIR is also cheating because it allows higher gradient of head movement than what is possible physically. The bottom line is that this is not a black and white problem and just because someone makes a macro to do something it does not mean he's cheating. There is an upper limit of how many keys you can trigger within a timeframe (atleast this is what I found in a couple different programs I've tried in the past) and you will have a hard time managing to generate more than 20-30 inputs per second. Also, compared to the typical spinbots etc. you see in FPS games there is a practical limit to what you can do in a flight sim: Generating an extremely different flight controller input every 10 ms does not result in any advantage (actually it'll only bleed your energy or outright stall your plane). FCR macros for targeting are practically not possible because it would require image processing AI to get it right (since you cannot automatically move the cursor somewhere, this is generally the largest issue in FCR management, especially in high G maneuvers). Countermeasures are a common field of use, although this is something you can achieve by modding the .lua files (in this case modding only achieves that you don't have to waste 1 minute setting the profile every time you spawn - and this is a huge QoL feature since anyway IRL you never airspawn etc.). Cockpit management: you can have some macros to set display pages to predefined state, which is mostly bypassing the lack of implementation of appropriate features by ED or improving trashtier avionics design (this could be argued as unrealistic, however I'm clicking MFD buttons on a 2D screen not feeling G effect, so then again this is kind of a pointless argument). I.e. on the Hornet you could have macros to swap MFD pages as you wish.. but this same advantage can be achieved even much better by having external screen exports, so this is far from cheating too.. or are people with cockpit builds also cheaters now? ECM blinking: this was a clear case of an exploit that had a strong impact in the past but in general should not work.
  7. 50nm is past the battery limit even against a co altitude Mach 1 target when fired supersonic.
  8. I think this is a problem of the HMD refresh rate for some reason. If you lock someone, even at long ranges ( 30 nm+ ) and the target dives aggressively you will see roughly up to date target designation on your HUD. However if you do the same thing while in a crank, monitoring visually the target designation box on the HMD he will lag behind. I can double check later on but I'm about 90% sure that I looked into this in the near past and this is what I found and it is rather odd. If the radar mech was so slow to not keep up with the target maneuvers you would alltogether lose lock much more likely than just have a lag, especially for such extended periods. Edit: hmm, looks like it's actually struggling the most when you're also maneuvering hard.. at longer ranges the HMD seems fairly stable, but when you pull hard the HMD will get pretty jumpy and can be off the location too.
  9. You need the line of sight vector at 90 degrees, not the missile flight path. You're nowhere near a notch.
  10. Because once you're closing inside 2-3 miles to the missile it'll be next to impossible to stay within the notch gate. Currently in DCS you're more often defeating the missile much further away and it never bothers to track again, or if it does it doesn't matter anyway because it reset it's flight path to a trajectory that will make it impossible to hit you in the event that it manages to reacquire. By getting DL updates up to this range you are patching that gap and driving the missile reliably in the correct direction and once inside that range it's not realistic to reliably stay in that notch anymore.
  11. This looks amazing.. just out of curiosity, what is your method of recording / exporting data? I've done a lot of stuff flown by hand then exporting data through Tacview, but it's rather tedious. Especially when a patch comes out and you have to redo a lot of it.
  12. Co-altitude at 40kft, 25 miles, hot target dives to the deck at 60 degrees and SAM has absolutely 0 problem tracking him until you run out of elevation limit (about 6 miles). If the target dives at 80 degrees SAM will lose lock faster, but TWS will also lose lock.. I suspect TWS might have a longer memory which results in that.
  13. I'm very surprised that I've shot well over 100 missiles since the patch and I've never experienced this issue.. and definitely a significant portion of those shots were under heavy Gs.
  14. This is wrong, SAM will automatically follow the target altitude. I'm not even sure why you would think that it does not.. there is a bug that will sometimes throw your lock away and cut the display range in half, but that has nothing to do with elevation. I'd say this was working since day 1 of Viper release.. otherwise you wouldn't even be able to pull off a basic F-pole since as soon as you dive you'd lose lock since the required antenna elevation changes by anything between 20 to 50 degrees. The elevation caret display might be out of sync though, I noticed at least that when you're in a dive/climb it will display inaccurate data (i.e. picture diving at 20kft against a bandit still at 40kft around 20 miles, for sure your radar has to be pointing up, however it typically shows centered elevation caret).
  15. Tbh I can't picture a good Viper driver in DCS using TWS more than ~ 20% of the time. RWS is just far superior. The only time you're using TWS is to build picture and multi target. The Hornet is another story.. but in my opinion the whole avionics implementation of the Hornet is the absolute worst possible. It is literally the polar opposite of good user interface. Picture the things you can do in other fighters by passively looking at a display or pressing 1 button. In the Hornet you have to push 16 buttons to achieve the same result.
  16. I'm not interested in buffing or nerfing for the sake of balance or whatnot. Maybe my phrasing was ambiguous, I meant that some things are wrong in general. The FMs definitely have some issues, but also there are other things at play.. including poor G modeling, and people abusing mechanics like the G override on the Hornet which would not be allowed in a real jet. I got carried away yesterday and I realize that this is not leading to anything useful. From my point of view it's extremely hard to pinpoint what is wrong since I only have data on the Viper and even that data does not cover all aspects.. and I'm just suffering through the end result that the Viper is simply not very competitive in a dogfight, which is very frustrating since according to all accounts it should be. Anyways.. I'm off to enjoy the wonderful new lighting and weather in 2.7. ED outdid themselves with that, it is looking far better than I expected.
  17. Pretty sure DI of 50 is wingtip 2x AIM-9M, 4x empty LAU-129 launchers and the normal fuel tank pylons on inner stations and the centerline pylon mounted, but no other load outside the 2x 9M. I was checking this yesterday in the HAF CJ supplement and clean plane with 2x wingtip 9Ms is a DI of 4, LAU-129 is a DI of 6 each below the wing, the inner fuel pylons are 8 each, and the belly pylon is 7. Alltogether results in a DI of 51. The problem with comparing vs. the 0 DI chart is that you have to literally fly with 0 fuel (as far as I saw there is no DI = 0 chart with any gross weight above 22000), which only leaves the option to turn on infinite fuel. Which has been previously known to have buggy impact on flight model. Also, pylons removed is not a valid reference for dogfighting performance since you never fly like that. This is why I was checking on the DI = 50 charts with 26000 lb. Sadly the region above M0.8 cannot be verified (especially at sea level) without removing G effect because the DCS pilot GLOCs way to soon.
  18. Which can't happen. I can test against the F-16 manuals I have and the result is basically the same as the guy explained above. Spot checking points of PS = X curve will typically tell that the turn rate is within 1 deg/s ballpark. Unfortunately I cannot test the Hornet since I don't have data on that. But according to numerous accounts of real pilots, even ones including that posted in this forum the Viper FM is off in multiple regards. The fact that the Hornet seems to be performing better than it should and some other cherries on top like everyone and their mother abusing the G limit override, or that by real life standards the DCS pilot would not make the cut to be certified on an F-16 since it basically can't handle 15 seconds of 9 G without completely losing vision or flat out GLOCing. Simulating one aircraft accurately is a difficult thing for sure. However that ultimately means little if it's thrown into an inaccurate environment in other regards. The fact is you get outrated by basically every other aircraft in DCS.
  19. As I said either the Viper FM is off or there is something wrong with the others, or both. It simply cannot be that you couldn't match any real life descriptions of basic dogfighting scenarios if everything was accurate. I'm obviously not the expert to judge exactly what is wrong, but overall it is very far from correct when you're outrated by a Hornet at high subsonic airspeeds.
  20. Personally I did not do any research because I preordered it on day 1. Since I knew what it should be. All the people who preordered are in that same boat. I'm just sad that for the past 2 years I have to fly this aircraft with it's hands tied. It definitely performs well in some areas, but dogfighting is not one of them. You can adapt and work-around, but that always has it's limitations and also you cannot avoid every problem always.
  21. If other DCS modules are also developed according to the same real world data then it cannot be that you are clearly losing in BFM setups against other aircraft types, i.e. the Hornet when accordig to various testimonies of IRL fighter pilots you should be winning. So either the Viper FM is incorrectly modeled, or the Hornet FM is incorrectly modeled, or a combination of both. I'm not even talking of complex BFM setups, but really simple flat 2c rate fights. In a significant portion of the Mach range you should be flat out winning, especially at around M0.8 yet the Hornet basically has competitive or better turn rates. Don't get me wrong I appreciate the work that goes into it. But what is the user supposed to do in a jet that has 2 major regions of BFM, 1 where you're supposed to lose and 1 where you're supposed to win, and instead you are borderline automatically losing in both?
  22. It does not have to be stated anywhere. DCS is advertised as one of the highest fidelity study sims, especially when it comes to flight modeling. One of the key features of this aircraft is being an excellent dogfighter, commonly considered as "the best" of it's era, especially compared to the other american teen fighters. Therefore a lot of users are interested in exploring it's fighting capabilities according what is known by various real life accounts and other sims. From my point of view it's unacceptable to sell a product even in early access that fails to deliver on one of the most important defining characteristics of the airframe.
  23. Viper FM is not even in an approximate ballpark of accuracy since 2 years. You basically cannot employ it to the designed operational BFM criteria, you're pretty much guaranteed to lose in any dogfight against a dissimilar opponent. Your ace up the sleeve should be best in the league turn rate and energy capability. Instead the aircraft is basically the worst in both of these when compared to 15/18 or flanker family. So what exactly is early access then? Can you release a 3d model of an F-22 with nav modes and the flight model of a biplane and call it a day for the next 3 years? Edit: tl; dr my problem is not that the Viper FM is not 100% accurate. But rather that in relative terms to other DCS modules it is so bad in BFM performance that it pretty much cannot compete at all with the other contemporary fighters. Meanwhile the module itself is sold on the premise that it is one of the best dogfighters of it's era.
  24. Is there any chance you tipped the jet on taxi to damage the wings? In the past typically you'd only lose wings if you did that first.
×
×
  • Create New...