ReflexArc

I'm wondering if anyone has run into this issue with a 7900XTX. Mid-flight the game hard locks to 65 FPS which is 60% gpu utilization (1440UW mostly high settings.) If I pause the game, GPU util goes to 100% with 175 FPS. CPU seems to be running the exact same either way. Any ideas? Edit: Did a little more googling, either iUFC or DCSDTC make an export.lua modification that limits FPS. Commenting out those lines fixed the issue. See this thread for more details:

OP, did you ever figure this out? I'm running into the same issue. GPU utilization 60% and lower framerate than when I hade an RTX 3070 in the system. Edit: Did a little more googling, either iUFC or DCSDTC make an export.lua modification that limits FPS. Commenting out those lines fixed the issue. See this thread for more details:

This is really great, like other people said, it "just works." Are you still involved/maintaining the project? I noticed no updates on github in the last 9 mo. I would really love to have the pylon selectors / jettison module available as those are something I might need to use quickly in combat and can be hard to click on in the heat of the moment!

A bit of a bump. Since the last patch, the line width tweak seems to be interpreted differently and I can barely see contacts on SA page and Radar both in game and on exported monitors. Posting before I have a chance to search the thread to see if I can find the default widths/weights.

There's some sort of post-processing added to the in-game MFD's ever since they did some lighting changes. Which leads to bloom and night time blindness (realistically) if you try to leave the MFD's on the day setting during night missions (so that you can see stuff on the exported views.)

For another alternative solution, you could check out this thread: https://forums.eagle.ru/showthread.php?t=226594&page=4

Getting ready to likely take advantage of bn's service. Any tips for getting the connectors unplugged? I have the hot glue off but they really don't want to come out. Afraid of breaking something if I yank on the wires themselves.

Looking at the version that you uploaded, the only difference between the file that I have and the one that you uploaded is the following lines: MINE: YOURS: I suspect that yours may have a bug because it assigns both the T16000 and the T16000L the same device ID. Unfortunately I'm not sure how to help Spool. Thank you for helping folks out ITT! I uploaded the most recent version of the TARGET script that I've been using to the OP just in case the old version had an issue. Also, looking earlier in the thread: //Configure(&Throttle, MODE_EXCLUDED); //Configure(&Joystick, MODE_EXCLUDED); Configure(&LMFD, MODE_EXCLUDED); Configure(&RMFD, MODE_EXCLUDED); Configure(&HCougar, MODE_EXCLUDED); Configure(&T16000, MODE_EXCLUDED); Configure(&TWCSThrottle, MODE_EXCLUDED); Configure(&TFRPRudder, MODE_EXCLUDED); Configure(&T16000L, MODE_EXCLUDED); Configure(&TFRPHARudder, MODE_EXCLUDED); Configure(&JoystickF18, MODE_EXCLUDED); JoystickF18 and TFRPHARudder are not currently aliased in the targetdx128.tmh file, so that may be causing the error for one of the earlier posters.

As an update, Sahaj got back to me, seems like the original package was returned to sender for whatever reason. Sahaj offered to send a replacement with upgraded shipping without charging any extra. Much appreciated, package arrived today and the extension works great!

Now on 6 weeks. Tried emailing Sahaj a few different ways, no response to any of them. I did talk to someone in our wing who said it took 6 weeks to get to CA with the upgraded shipping, so I'll hold out hope for a few more weeks, although you'd think shipping to MA would be faster coming from Poland.

Anyone in the US able to give some idea on shipping time with the standard shipping? I'm on three weeks now since it left Poland.

I got the 'EVENT' error in that first post because I was loading in the wrong moose.lua (the small one that builds from source and not the standalone one that you include with missions). Yes, I added the weapon names from your script. It turns out routines.utils.round is not defined anywhere in the MOOSE code. It is called in a number of places, including as part of the function to get SAMs to change places within the SEAD class. I replaced routines.utils.round with math.floor and now the whole SEAD function is working just fine. Later, instead of using math.floor, I added the snippet below to the moose.lua and everything works. routines.utils.round = function(number, decimals) local power = 10^decimals return math.floor(number * power) / power end In case anyone wants the weapon names provided by Hardcard: SEADWeaponName == "weapons.missiles.X_58" --Kh-58U anti-radiation missiles fired or SEADWeaponName == "weapons.missiles.Kh25MP_PRGS1VP" --Kh-25MP anti-radiation missiles fired or SEADWeaponName == "weapons.missiles.X_25MP" --Kh-25MPU anti-radiation missiles fired or SEADWeaponName == "weapons.missiles.X_28" --Kh-28 anti-radiation missiles fired or SEADWeaponName == "weapons.missiles.X_31P" --Kh-31P anti-radiation missiles fired or SEADWeaponName == "weapons.missiles.AGM_45A" --AGM-45A anti-radiation missiles fired or SEADWeaponName == "weapons.missiles.AGM_45" --AGM-45B anti-radiation missiles fired or SEADWeaponName == "weapons.missiles.AGM_88" --AGM-88C anti-radiation missiles fired or SEADWeaponName == "weapons.missiles.AGM_122" --AGM-122 Sidearm anti-radiation missiles fired or SEADWeaponName == "weapons.missiles.ALARM" --ALARM anti-radiation missiles fired then -- Check if the missile is a SEAD

Thanks @Hardcard, I'm looking through your old posts on the topic. I see you might have tried changing the weapon names to the correct values--did that work for you? EDIT: Well, I think I figured out the issue in the SEAD function. I enabled a bunch of tracing and it turns out this was the error: 2019-07-19 23:21:06.560 INFO SCRIPTING: stack traceback: [string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:6062: in function 'round' [string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:726: in function 'groupToRandomPoint' [string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:780: in function 'groupToRandomZone' [string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:752: in function 'groupRandomDistSelf' [string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:40642: in function 'EventFunction' [string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:6377: in function <[string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:6376> [C]: in function 'xpcall' [string "C:\Users\\AppData\Local\Temp\DCS\/~mis00001105.lua"]:6375: in function 'onEvent' [string "Scripts/World/EventHandlers.lua"]:13: in function <[string "Scripts/World/EventHandlers.lua"]:11> So I commented out this line --routines.groupRandomDistSelf(_targetMimgroup,300,'Diamond',250,20) -- move randomly And now the SAMs correctly change alarm state. I haven't quite been able to figure out how things are getting improperly passed to the round util function but I'm sure someone with more familiarity with the code base than myself could figure that out pretty quickly...

Yes that's exactly it, thank you. For anyone else who runs into my issue, the problem was that I tried to use the MOOSE.lua from the source code download and not the MOOSE.lua that contains the entire source. As for whether the SEAD function works, I'm testing but it's looking like possibly no? Is there a way of calling the emissions off action from lua? Might be more reliable than alarm state which doesn't seem to be working.

I'm perplexed. I'm trying to add simple SEAD evasion behavior to a SAM site in a test mission. As far as I can tell, the functionality is not working in the Caucasus map. When I do the same thing (same script, same SAM site) in NTTR, I get a string error but the SEAD evasion functionality works perfectly. About to test in PG. Will supply NTTR error message shortly. But hoping maybe this is already a known problem or someone might have a clue what's going on? I'm not familiar enough with the DCS source code to know why different maps would cause totally different MOOSE SEAD behavior. Edit 1: To add to the strangeness, I tested on PG, no string error, just didn't work. Went back to NTTR to try to reproduce SEAD evasion working but getting a weird string error. Now NTTR is just not working like the rest of the maps. Edit 2: Suspecting extra weirdness, I quit out of DCS. Reopened the same NTTR mission without making any changes. Started the mission, got the same two string errors. SEAD evasion functionality working perfectly. Error 1: [string "C:\Users\(myname)\AppData\Local\Temp\DCS\/~mis00007487.lua"]:5: attempt to index global 'EVENT' (a nil value) stack traceback: [C]: ? [string "C:\Users\(myname)\AppData\Local\Temp\DCS\/~mis00007487.lua"]:5: in main chunk Error 2: Same as 1 but "SEAD" and different mis number (000022D0):1 The code I'm using is literally the example code. -- CCCP SEAD Defenses SEAD_RU_SAM_Defenses = SEAD :New( { 'SAM Test' } ) Edit 3: Actually, NTTR isn't working now, just throwing error codes. Very frustrating.