patpatpowercat

Hey @Admiral189, hope your recovery is going well. Just wanted to report an issue with the Admiral Ushakov, specifically the SA-N-7 missiles. Everything I can find says the Sovremenny-class has 2x 3S-90 Uragan single rail launchers, bow and stern, and either a magazine depth of 42 or 48 missiles (obviously this could change). However your mod seems to have unlimited ammo, and launches at a rate of far FAAR too fast. I modified the Admiral Ushakov.lua and added two lines (one for each launcher). GT.WS[ws].LN[1].ammo_capacity = 24; I also commented out all the connector_names with the exception of one per launcher. By performing these two things, it has a limit of 48 missiles in the magazine, and the RoF seems much more appropriate to what myself and other unit members have found, with ~2 missiles (1 per launcher) every 8-9 seconds. This is a rough approximation of a Mk13 launchers rate of 1 missile per 8 seconds, so seemed like a good estimated guess. If you want to take a look and let me know what you think. Thanks for all your mods, and best of luck with your recovery! Admiral Ushakov.lua

Would you be willing to share your complete .kmz?

Is that a typo that it is supposed to be 46.3km? I see you're using some of the same sources as me (CMO). That, wiki, and other sources I could find designate the range for the 9M38 as ~25nm (46.3 km). I see in the .lua the range is 46000, and active radar lock 56000. Although I dunno the difference between those two parameters. Thanks so much for your quick response with this stuff! Oh, and I think you have to update the Admiral Ushakov.lua file as well to reflect the lower threat ring in the map correct?

@Admiral189Can you look at the Admiral Ushakov as well? It is supposed to be a Sovremenny-class destroyer is it not? In which case it should have SA-N-7 Gadly missiles. It currently fires "SANSA11", with a SA-11 model, but to a range far beyond what it should be, with the threat range being 160nm, this should be ~25nm instead. Or am I mistaken?

Awesome thank you!! @Admiral189

Hey @Admiral189! I was just wondering if the LSD Oak Hill had been updated for the dancing missile guidance problems? I saw there was not an active link on your website for an update.

I do believe there is an SM-6 that was added to the base game files, although not implemented, so it seems clear that thinking ahead is in someone’s mind.

Awesome thank you!

@currenthillWith the change of ED’s core now having Arleigh Burkes that have selectable ammunition, will your future releases of the flight IIa and III from the USA assets pack include this as well?

+1

We've removed *all* scripts and this crash still occurs. Always related to the transport.dll. dcs.log-20241015-192648.zip dcs.log-20241017-191650.zip

Crashes occurred in clients occupying multiple different modules from multiple different module makers: F-18, 16, AH-64, F-15, F-14 were all effected the same way at the same time.

Our group had a couple large client crashes this weekend during an event. In both cases, the server did not crash. Members in gamemaster/spectator slots did not crash or disconnect. There were no lag spikes or issues prior to the client crashes. We did not add any new scripts/mods that we have not been using in the past. In all cases, the clients froze up, then crashed. In all cases, the client's crash log points to an access violation from the transport.dll. As you can see, they all occurred at the same time. No large event/battle occurred at this time. Attached are 3 client crash logs all showing the same thing, however I can happily produce more client crash logs showing the same. There is also a full log from another client. The server log showed nothing of note. This mission was run through multiple times in SP, and never had any issues. It seems to be only in MP that there are issues, and only for clients that are occupying module slots. pat_dcs.log-20241013-015641.zip matth_dcs.log-20241013-015641.zip cblou_dcs.log-20241013-015641.zip OGA04 Client Crash.log

We’ve had issues with S-3s in my group as well, getting stuck on catapults and not launching. Works fine in SP, but in MP they get stuck on cat and do not launch. It seems to be that if a player/client aircraft uses the catapult first the AI then gets stuck on it. If the AI uses the catapult before a client (beginning of mission say) there are not any issues.

This seems not to be just older static templates. It seems importing static templates renames the units off the GROUP name, rather than carrying in the UNIT name.

@currenthill It seems that at some point in time (perhaps latest update) many of your radars no longer appear on RWR. At all. I have tested many of your ships, both Chinese (all types) and Russian (all that I have tested: Grigorovich, Project 22160, Karakut). They shoot, however, none ever show up on RWR, as a 'U', or otherwise. No search, tracking, or launch warnings at all. I tested with both the F-18, and F-15. I tested with both your RWR definitions, as well as default. This does not seem to effect your HQ-22 system, S-350, nor Admiral's ship mods. Can you please look into this?

Apologies, I searched but didn't find this submitted. The AH-64 cannot have HF preset frequencies from the mission editor. Is this intentional/correct, or a bug? You can certainly change the channels, so I don't know why you can program the other 4 radios with presets, but HF does not exist.

This script is wonderful. However with latest update I am noticing a crew chief is spawned for air starts. Is this perhaps due to ED's changing of getcategory() with the getairbasecategory()?

Yeah I saw those posts too and tried that as well. Never had G hub or anything on my computer. TH support just said Win 11 wasn't supported and was no help. All good, joystick gremlin took some time to get setup, but it works for me and now I don't have to deal with the clunkiness of TARGET either. Thanks for all your help though!

I tried new user accounts, and even a new full reformat. No change.

I was able to use the registry edit hack in order to get TARGET scripts to run. However I have a new bug with it. Although the script runs successfully and the virtual device is created, the original devices also reappear after the script is run. So when giving a button input, it’s being input from both the joystick/throttle AND the virtual device that is created. I have tried driver re-install, TARGET reinstall, different USB ports (which required the regedit hack again), all to no avail. Any ideas?

I just updated to Windows 11. Now however I get an error when compiling or running this script, but from the targetdx128.tmh file. Identifier name expected in targetdx128.tmh at line 883 I checked line 883, and it is where the dx begins to be defined. define DX33 3032 Anyone have any ideas?

Hello! First off, let me say, ED, I am super happy with 2.9. Beyond that, many longstanding issues have been acknowledged and addressed by your team over the last several years, and the work you all do is commonly discredited, minimized, or marginalized in what is an amazing product that has brought myself and many others hours (if not days, literally) of pleasure over the last many years. Many of us understand the complexities of bug issues and crash reports, the inability to replicate, etc, that plague your passion to provide an amazing product. With that, there is a large bug with the new implementation of the F-18 and STNs: if the 1st digit in the 5 digit sequence is anything but 0, you crash the game. My multiplayer unit consists of several squadrons flying everything you have to offer, and discovered this issue while trying to determine what STNs to use to ensure separation amongst STNs and squadron use. To test, I have utilized the following STNs, in the F-18 (F-16 appears to not have any issue per our reports, although I don't own. If you'd like to gift to me I am happy to help test ) This is a vanilla mission, NOTHING except a single F-18 client aircraft with the following STN codes: 23101 >> crash 13101 >> crash 21101 >> crash 01101 >> no crash 11101 >> crash 03201 >> no crash 04201 >> no crash 06701 >> no crash 07441 >> no crash 07777 >> no crash 17777 >> crash 77201 >> crash As you can see, any first digit other than 0 causes a crash to desktop. This does NOT require a MP server. Simply create a blank mission (any map) and try the aforementioned STNs. To my testing, any digit in any other place other than the first causes no issue. Our F-16 squadron uses the 15xxx STN, and has had no issues. Again this appears to only effect the F-18. If required/requested, I will gladly provide any assistance I can to hunt down this bug. I cannot save any tracks, due to the game crash. However I have always sent crash reports. Again, to replicate, create a blank mission on any map, with F-18 client, with any digit other than 0 for the first spot of the STN, and upon occupying that slot, your game will crash. Thank you for your time, stay safe.

@currenthillI have a missing texture error with the US Infantry mod. I am using 1.2.0. The M249 gunner has no texture for his gun. See attached. Anyone else have this?

@prccowboyHave you thought of doing an E-8 JSTARS? That'd be super cool