Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

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

  1. I only have moderate knowledge of the Tomcat, but I had a crashpad roommate a few years ago who was a Tomcat driver and we used to talk about the jet all the time. He said that in most cases, the D was prohibited from launching in AB because the higher thrust engines increased Vmca to an airspeed where rudder authority was insufficient to compensate for an engine failure during the cat stroke. Hence MIL thrust takeoffs. He never mentioned an explicit Vmca value - and I never asked - but he did say they could push it to AB once the jet was climbing away. I don't know whether the same restriction existed on the B. What is a typical cat end speed for a B/D, anyway?
  2. The concept is not complicated. The implementation, however, can be as complicated as the developer desires. I'm just saying that plenty more can be done to realistically simulate EW without ever approaching the level that requires more than basic math or a rudimentary understanding of the ECM/ECCM techniques. Like I said above, the process can be almost entirely abstracted, to the point that individual ECM techniques are nothing more than column labels.
  3. Caveat: I didn't read the whole thread so if I repeat a talking point, I apologize. At present, the lack of any semblance of EW in DCS prevents realistic tactics against double-digit SAMs, and fails to capture the point of carrying an SPJ in the first place. SPJs are specifically designed to defeat radar locks, and/or generate sufficient miss-distance in order to ensure aircraft survival. Current DCS jammers make no attempt to perform this task. There are plenty of ways to more realistically model EW without it becoming overly complex for either users or developers. One does not need to model every radar's range and velocity gate algorithms in order to simulate an SPJs ability to employ an RGPO/VGPO countermeasure. Nor does one need to play EWO in order to make the pod do its job. All that is required is to give each radar a set of representative characteristics: Band, PW, PRF, ERP, antenna pattern, scan type, etc. Then give each radar a set vulnerabilities, call them 0-9. For each vulnerability, assign a susceptibility value e.g., "0.85". Now create a jammer, and give it some characteristics: Band, ERP, number of transmitters, antenna pattern, response time, max threats tracked, max threats countered, etc. And give it some ECM techniques, call them 0-9. Give each one an effectiveness value e.g., "0.5". Use range to the victim radar, the SPJs signal characteristics, and the effectiveness/susceptibility values to algebraically calculate the probability of breaking the track. Voila...instant ECM. Yes, some additional effort would be required in order to define the pod's priorities, and task specific techniques against specific threats, but it's not that complicated, and you only have to do it for number of pods in the game, which isn't many. The beauty is that the pod's threat and technique libraries could be altered in the .lua files in order to create realistic threat response behaviors. All without actually modelling any specific ECM or ECCM technique. Now if you wanted to call Vulnerability 1 "Range Gate", and Technique 1 "RGPO", so much the better. But it doesn't matter... Repeat for SOJ which prevents acquisition in the first place, and now you've got a reasonable approximation of the EW environment with relatively little effort...plus a reason to have Growlers/Prowlers in the game.
  4. Sorry, since the F-5 is using the IP-1310 display and the control head is identical, I assumed it was the ALR-69 which is the current standard. The ALR-69 behaves as I described. I don't know anything about the ALR-87...
  5. The SEARCH pushbutton should enable the display of search and acquisition radars that are otherwise suppressed from the azimuth display. Suppression of search radars declutters the azimuth display and is the default state. Selecting the SEARCH mode adds search and acquisition radars symbols to the display, up the maximum allowable number of symbols. For audio, there is: 1) Threat audio. Threat audio for the emitter under the diamond is played continuously in the headset. The audio is created using the emitter's characteristics, e.g., PRF, scan pattern, scan volume, signal strength, etc. A rotating surveillance radar sounds very different than a conical scan or staring fire control radar. The audio directly correlates to the RF energy received at the aircraft, so the audio is the best indictator whether a lock has been broken. For emitters with PRFs outside the human audible range, synthetic digital audio is used. See here for how it's done: 2) New Guy audio. Three tones in 1.5 seconds at the emitter's PRF. 3) Missile Launch audio. 7 tones in 1.5 seconds at 1kHz.
  6. Real J85 engine behavior in a T-38A: Yes, it's a slightly different variant, but the behavior (spool time, nozzle position and scheduling, oil pressure, RPM, EGT, FF, etc) is representative of the entire (after burning) J85 family. You can draw your own conclusions re: the current modeling.
  7. Cool. I inherited my dad's Thud model, which now graces my home.
  8. Some ED files had the commas while others didn't; same for 3rd party files. I swear I tried it both ways, but I must have missed something. Removing the cited comma made everything work. My new roadblock is getting the A-10's DSMS to recognize I've the pod without having to manually inventory it. As before, I've located the 3 relevant files and made what I think are appropriate entries, but the station is still blank in the DSMS Inventory until I manually add it via the MFCD. It's hard not to get discouraged when you've made all the logical changes you can think of, and you're down to essentially pressing buttons and hoping to get lucky.
  9. No worries, thanks for taking a look. If you have time tomorrow, I'd certainly appreciate it. It's difficult to list all of the troubleshooting steps I've taken, but among them were adding and removing commas after the brackets. Some of ED's native files have them and some third parties don't, so I tried it both ways. I was frustrated for a while because DCS kept crashing when loading the ME because "elements" must be written as "Elements" else it's not recognized. Without an SDK or examples like yours from which to copy and paste, there would be no way to figure that out! EDIT: You've got eagle eyes; that extra comma was the problem. Thanks for saving me untold hours and days trying to figure it out on my own!
  10. Okay, at one point I had EVERYTHING named "AAQ_33" just to make sure it wasn't a mismatched name or an issue with dashes, but it made no difference. I'll try again to make sure. Yes, I've added the CLSID to the A-10C.lua for pylons 2 and 10. Edit: Confirmed that with everything named identically to my .edm, it still does not appear in the ME.
  11. Thanks tom. I tried using the format you suggested for a new pod, and although the module is visible in DCS, the pod isn't available in the ME. I've done a significant amount of tinkering with the format, order, adding elements from the declare_weapon() function from Skate's examples, amd even adding the entire declare_weapon() code block, but after 5 hours of moving stuff around I can't seem to make this work. This is the entire contents of the Armament.lua file called by Entry.lua. Can anyone see an error in my syntax? declare_loadout( { category = CAT_PODS, CLSID = "{AAQ_33}", attribute = {4, 15, 44, WSTYPE_PLACEHOLDER}, Picture = "AAQ-33.png", displayName = _("AAQ-33 Sniper XR"), Weight = 289.000, Cx_pil = 0.001, shape_table_data = { { name = "AAQ_33", file = "AAQ_33", life = 1, fire = {0, 1}, username = "AAQ_33", index = WSTYPE_PLACEHOLDER, }, }, Elements = { { ShapeName = "AAQ-33", Position = {0, 0, 0} } } } )
  12. Thanks SkateZilla, I'll give your examples a try! I created models for several different new stores, including JDAMs with nose plugs instead of the default M904 nose fuze, as well as a few alternate variants of the AIS pod. Pods like the AIS seem to lack the type of data contained in your second code snippet. The only thing to enter there would be the basic header info (name/username/category/etc) and the shapetable data; will that suffice?
  13. No, if I were going to add a weapon to the F-5, it would be the BLU-27.
  14. Thanks for the replies Gospadin. I hadn't considered downloading 3rd party modules without purchasing a key...it never occurred to me. Hopefully that will provide some sort of usable example, because although I understand the procedure, it's the actual syntax that remains elusive. Nonetheless, I appreciate the clues.
  15. Ok, last try... Any one here feel like helping?
  • Create New...