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.

Great suggestions, guys, thanks! I'm trying to help improve one of the multiplayer missions for the squadron I recently joined. It has a lot of moving parts and would otherwise rely on 20+ people. Sounds like making the players into immortal expert AI will really help with the exception of edge cases that I've read about on here (issues with AI and SEAD, for example.)

Hi All, Sorry if there's a good thread on this--I tried searching! Any suggestions for good ways of testing missions? Do you set up radio commands to manually trip flags? Similar but for killing off specific targets? Thanks!

Both SP and MP, most recent crash uploaded. Crashes straight to desktop, no consistent situation (once while on the ground in A10C, once while in AA combat in FA 18) i7 5820k RTX 2080 (most recent graphics driver) 32GB DDR4 Windows 10 64 Bit Game had been running rock solid until this past week. I'll try some of the troubleshooting steps and update about any crashes (or lack thereof) over the rest of the weekend. Logs.zip

Catseye, it sounds like you didn't put targetdx128.tmh in the target /scripts folder? Actually, re-reading sedenion's thread (he's the one who figured out the 128 buttons thing), I wonder if you're using old versions of TARGET--that was the issue for a poster who was running into the same error a couple of years ago.

Ah thanks for clarifying, I had conflated the force-sensing version and that one that the majority of us have ordered (waiting for mine..)

This is a bit of an educated guess, but I looks like line 348 is the first step in the function that maps peripheral buttons. I wonder if the index error is because somehow TARGET recognizes that there is no longer an installed SC (TDC depress). Please try the attached file with the original targetdx128 (all I did was remove the SC assignment.) WarthogThrottleALLSwitchPosNOTDC.tmc.txt

Hey Delta, I'm looking forward to receiving the slew I ordered. Someone who has already installed a slew mod tried using the TARGET script I posted and ran into what seems to be an index error in the function that seems to assign throttle buttons to directx keys. Related, do you (or anyone else ITT) know if TARGET correctly picks up that the TDC depress button is removed when the slew mod is installed?

That's really interesting, I wonder if somehow TARGET knows that the TDC no longer has a push button. I'll probably end up having to troubleshoot this when I get my slew mod. You may actually need to comment out the TDC button, but I'm about to go to bed so can't figure out its proper name at this very moment, will follow up when I next have time.

Hmm honestly I'm not a pro at this overall. Just to make sure, you installed targetdx128 in your scripts folder? It looks like line 867 has to do with TWCS throttle mapping and so TBTN1 is probably referencing a button on that throttle. You could try commenting out that line by using // in front of int TWCS etc. and see if it works. Also, just to check, you don't happen to also be using a TWCS throttle at the same time? (Although I don't know if that would actually make a difference.) I'll upload the version I'm using in case something was changed for some reason. targetdx128.zip

I've ordered the delta mini-stick. Until then, I use the TDC curves suggested in the A-10C on other modules, sometimes with a slightly higher Y-saturation. Something like deadzone = 40 Y sat = 40 curve = 0. I'm curious, while we're on the topic of new WARTHOGs, whether anyone else finds that they have to press on the far end of the brake switch to get it to move? For example, if I'm trying to pull it back to engage the airbrake, I have to "push" it from the front because "pulling" from the back impacts it within its housing and keeps it from moving (due to a good bit of wobble in the button piece itself). Hopefully that was a clearish explanation!