esb77

Combined arms vehicles driven by players appear to have changed their handling behavior significantly. They handle as if the spring rate is much softer, spring travel is longer, and damping is greatly decreased. Coefficient of friction on most terrain also appears to be significantly reduced. These are parameters that probably needed to be adjusted in those directions somewhat, but the current iteration appears to be excessive. The results are often quite comical, but it should probably be dialed back a little bit.

When a player in a JTAC slot is controlling a Tunguska in the driver or gunner slots the radar display does not show airborne targets.

So I was not super satisfied with previous suggestions, including my own, and set out to try to do a decent way to seed math.randomseed() in the DCS Scripting Environment. The TLDR that surprised me a bit is: "Don't worry, be happy. math.randomseed() appears to be broken in the DCS scripting engine because it has been replaced by something custom behind the scenes. If LUA scares you use the trigger system ACTION FLAG SET RANDOM VALUE (min, max) to generate a random number between min and max (inclusive), or if you are comfortable with LUA just use math.random() because it is pre-seeded, and math.randomseed() is broken so you can't use a custom seed anyway. Trying to get a good seed for math.randomseed() appears to be totally irrelevant in the DCS Simulation Scripting Environment, because as far as I can tell math.randomseed() is broken there. If you pass it either an integer variable, or even just an integer number, it throws an error saying that randomseed is a field with a nil value. I did some test code, and what works in standard LUA doesn't work in DCS, and what works in DCS doesn't work in standard LUA. It appears that math.randomseed has been replaced by something custom in DCS, so what you need to do is either use a Flag Set Random Value to get a random number, or just use math.random without math.randomseed in LUA code for DCS. This seedNumber = 1426 math.randomseed(seedNumber) print(math.random()) seedNumber = 2753 math.randomseed(seedNumber) print(math.random()) seedNumber = 2753 math.randomseed(seedNumber) print("Seed Number 2753 results:") print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) seedNumber = 1426 print("Seed Number 1426 results:") math.randomseed(seedNumber) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) print(math.random(1,10)) Produces this in LUA 0.11670539583512 0.50927697496681 Seed Number 2753 results: 7 4 5 Seed Number 1426 results: 5 6 5 1 3 3 3 5 7 7 9 math.randomseed(integerVariable) works as expected. In DCS this -- Random seeder, requires on mission start triggers that --1: Use an action set random flag to set a flag called seedPickFLat to a default of zero **deprecated you can just use step 2 --2: Use a Flag Set Random Value action to set seedPickFlag to a range from 1 to 16 randomLookUp16 = {1426, 2753, 6999, 9779, 5702, 6384, 9497, 2072, 7419, 1545, 1302, 6354, 4985, 1997, 4395, 3717} --table of 16 theoretically truly random numbers seedPick = (trigger.misc.getUserFlag("seedPickFlag")) --gets a random number from the flag and assigns it to a variable to pick a key from the lookup table trigger.action.outText( "seedPick is " .. seedPick, 20, false) --test message, comment out after validation seedNumber = randomLookUp16[seedPick] --sets seedNumber equal to the value for the selected key in the lookup table trigger.action.outText("seed Number is: " .. seedNumber, 20, false) --test message, shows contents of seedNumber variable, comment out after validation math.randomseed(seedNumber) -- intended to seed random number generator, Actual effect is to throw error: randomseed is a nil field. Works in that using a Flag Set Random Value (1, 16) will generate a random key, and select a number from the lookup table of seed numbers, but when you try to use that number assigned to a variable math.randomseed(integerVariable) throws an error saying randomseed is a nil field. Literally cutting and pasting working code from a LUA compiler gives that result. Valid input causes an error. Cut and paste that input from DCS to LUA and then math.randomseed() works as expected. My conclusion therefore is that if math.randomseed() from LUA still exists in DCS it is now behind the wall and cannot be accessed by normal users. It doesn't matter though, because they appear to have set things up so that math.randomseed( os.time() ) or something equivalent gets run automatically before math.random(), so all your random numbers in DCS scripts are correctly seeded, whether you want them to be or not. So we get convenience and security in one tidy little package. I'm not sure if I should feel happy or insulted that they idiot-proofed it so much that even I can't mess it up.

Thanks for posting this. I'm not to the point where most of my scripts would run afoul of this (I think) in terms of script complexity, but it's very valuable to start getting an outline of where minefields of new bugs might arise from the dynamic slots. Of course, I'll probably forget and run face first into some avoidable dynamic slot bugs anyway, but maybe when that happens after I've spent a few hours of frustration I'll remember your post and get myself unstuck. That's how it usually works for me, "Why couldn't I have remembered this earlier?"

F-15 E latest update triggered Norton antivirus on my machine and it helpfully removed ARF.dll from the F-15 module with bothering to ask me. Cited the threat as Trojan.Gen.MBT

If making a multiplayer mission with a client delayed activation group, if you call .activateGroup it can't activate the client group because the group table doesn't exist yet. There are workarounds, but the amount of workaround needed to perform a fairly basic mission function, spawning a player controlled group at a specified time or condition, is pretty ridiculous. If you're asking a mission maker, "What's a fairly challenging scripting task," I would argue that, "Spawning a player controlled unit in a multiplayer mission," should absolutely not be an answer to that question. Ideally, .activateGroup would just work when fed from Group.getByName(groupname) with no other intermediate steps needed, but there are legitimate reasons one might not want to create a group table for a group that may never be occupied. A method to look up a delayed activation unit placed in the Mission Editor and take its name to generate a group table that .activateGroup can take as input would be a reasonable intermediate solution. More generally, the biggest criticism I have of the Mission Editor and DCS Scripting Environment is inconsistent behavior across single player and multiplayer missions, and limitations of methods where the limitations are obscure and difficult to figure out. Using delayed activation and .activate as examples, if they were called SinglePlayerAI_UnitDelayedActivation and .activateSPDelayedGroup, then I'd have less of a problem with them. They'd then consistently and reliably do what they say they do, and instead of generating grumpy mission coders wondering "Why does this method not work," you'd instead get requests along the line of, "Hey, that's a nice function, do you think you could make a multiplayer version too?" I know that there's good reason not to change names of existing methods to avoid, so making an effort to upgrade existing methods that aren't general in how they act across SP an MP to be general would be good, and then going forward, if new limited use methods are created, reflect that in the naming. Then if they are later upgraded the upgraded version can be named without an indication that it's limited scope.

So in scouring for more info I found a solution: migGroupFromTable = migGroupsToActivate[1] nextMigGroup = Group.getByName(migGroupFromTable) nextMigGroup:activate() That does what I want, grabs a value from a table, and activates the group with that name. But I still don't understand why the general structure of: trigger.action.activateGroup("groupName") --or trigger.action.activateGroup(stringVariable) -- where stringVariable == "groupName" doesn't do basically the same thing. I'll look into it some more, because if trigger.action.activateGroup(Group) actually wants the group mission ID number, or the GUID number of the group and not the name, then I'm doing my most frequent ME script bug of wrong format of input into a function. I probably also need to go back and look up the difference between . and : in LUA, which I looked up two days ago and have already forgotten. Something about functions that pass self as the first parameter I think. I'll update if I manage to un-confuse myself. I managed to get it to work with this --Modifying it again, trying trigger.action: trigger.action.outText("testing activate method", 20, false) migGroupFromTable = migGroupsToActivate[1] trigger.action.outText(migGroupFromTable, 20, false) nextMigGroup = Group.getByName(migGroupFromTable) trigger.action.activateGroup(nextMigGroup) trigger.action.outText("Group getbyname got: " .. nextMigGroup, 20, false) which throws and error on the final outText and I think reveals my problem. trigger.action.activateGroup wants the Group object table, not the Group name string. Using .getByName gets the right input, and with that it works.

I've got a mission I'm working on where I'm trying to have delayed activation client aircraft. I've done missions before where I've used the ME triggers to do this successfully, but the conditions are more complicated, and ideally I'd like to spawn in up to 60 or so units and therefore I'd rather do the activation with a script, instead of creating a massive amount of triggers in ME. So my approach so far as been: Create a table of groups to spawn in a ONCE At Mission Start trigger. --migSpawn Test code -- objective: assuming that a global variable named mig29ActivationIndex has been initialized with a value of zero at mission start -- have a reapeating trigger activate a series of delayed start groups in response to a specific condition -- and display a counter of how many groups have been activated so far. --Create an integer indexed table with the names of the groups that are to be spawned, note for performance reasons this probably shouldn't be in a reapeating trigger in the actual mission, create the table in an initialization trigger and make the table global migGroupsToActivate = {} --table with names of mig groups to activate. local groupRootName = "Mig " local numbGroupsInTable = 5 -- enter how many groups of migs are to be delayed activated in the mission local groupIndexStart = 1 local indexValue = 1 --if the table values are Root_i this is the value of the current subscript for increment = groupIndexStart, numbGroupsInTable, 1 do -- starting at the index start, stopping when the index is equal to numbGroupsInTable with a step size of one table.insert(migGroupsToActivate, groupRootName .. indexValue) -- in table migGroupsToActivate for the next integer key enter the value groupRootName concatenated with the current indexValue indexValue = indexValue + 1 end local tableValueTest = migGroupsToActivate[4] trigger.action.outText(tableValueTest, 20, false) --checking that the table of mig groups exists and has valid value fields This part seems to be working. I get returns from the outText action that look like what I expect them to. Then in a separate trigger I have an if then structure to examine a global variable, and if true, advance a counter that starts at 0, and then activate the group from the table of group names along with a message to let me (and eventually players in the mission) know that the unit has been activated and is available. if speedViolation > 1 then --if a speeder was detected in the speed monitoring section mig29ActivationIndex = mig29ActivationIndex + 1 --increment the global variable that counts the index of how many mig groups have been activated. trigger.action.outText("Activation index = " .. mig29ActivationIndex, 20, false) --debugging line, test that index is advancing properly local nextMigGroup = migGroupsToActivate[mig29ActivationIndex] --use the mig index as an input to find the i th group in the mig groups table trigger.action.outText(nextMigGroup, 20, false) --debugging did I capture the value from the groups table trigger.action.activateGroup(nextMigGroup) --activate that group trigger.action.outText("Mig 29 unit: " .. mig29ActivationIndex .. " activated.", 20, false) --message players that the group has been activated. speedViolation = 0 -- reset the speed violation variable for the next monitoring loop. end It didn't work of course, which is how all my lines of code normally start out. I have debugged as far as trigger.action.activateGroup(nextMigGroup) and everything up to there seems to be working as I expect. I didn't entirely understand the error message: So I made a new mission, set up a ONCE trigger, TIME MORE (10) condition, and Do Script trigger.action.activateGroup("Aerial-1") to have the simplest possible version of the activate script, and I get this So having tried to simplify this as much as possible, it looks to me like when I use trigger.action and append .activateGroup to it, DCS looks for a method called "activate" and can't find it? So the questions are: Am I interpreting that error correctly? and How do I help the scripting environment find the activateGroup method? I'm getting reasonably good at figuring out how my incorrect input types make script functions not work (I get lots of practice), but not being able to call a script function is a first for me, and I'm not quite sure how to approach debugging that. I'm working off of https://wiki.hoggitworld.com/view/DCS_func_activateGroup this as documentation for activateGroups.

This is how it works for me. I'm starting to get to the point where I can feel those first four slices shrinking though. Also to the point where I can start doing things the canned scripts in the ME either can't do, or can do but would be tedious beyond belief to create triggers for every unit instead of just using a loop in a custom script.

System failures in MP would indeed be lovely. Having more parts of the systems/damage models hooked up would be nice too. Things like broken rudders, flaps, ailerons, airbrakes, etc. There are lots of things you can break with bad flying or from weapon hits that the failures system doesn't capture.

Does anyone know how exactly this reads the file structure for loading the misison? I.e. static or relative? Trying to figure out if there are going to be issues loading with this trigger if the mission is moved between computers with different file structures. If the target file in the ME trigger action dialogue box is: SampleReloadMission.miz will changes in the bolded section below cause problems? C:\Users\Myusername\Saved Games\DCS.openbeta\Missions\NewMP_MissionsTestFolder\SampleReloadMission.miz It's going from my personal computer to someone else's dedicated server, so some differences in the file hierarchy are likely, for example they won't have the mess of folders where I sort different new, old, and under construction, MP, and SP mission files,

Did you change it from a single player mission with the plane controller designated as Player to a multiplayer mission with the plane controller designated as Client at some point? The AI not shooting at you below a certain hitpoint threshold is a known issue in multiplayer missions. I haven't checked recently to see if it's working that way in single player too right now.

Hm, well I'm not sure if the server in question will have SSB or not, so I was thinking of primarily solutions that could be implemented in the .miz. I didn't know that the hook scripts were a separate category that needed to be implemented in .lua files in a particular spot in the server's install directory in order to be loaded and used. Thank you very, very much for pointing that out Dangerzone and cfrag, it's a huge minefield that would have had me very frustrated at, "why is all this cool stuff not working for me." In checking out hooks and a brief overview of how they work, I stumbled across documentation for the DCS Singleton net. Which has the force slot script. Apparently added in 2.7.6, so pretty new. So option 3, or a 2 & 3 hybrid look doable even stand-alone. Just need to make sure I follow the Singleton documentation, and not the Hook documentation, though I'm not sure if there's actually any difference. I'm sure SSB is the quickest, easiest and most reliable approach, and that'll be my backup plan, but I think I'll have a go at seeing if I can get the behavior I want from inside .miz file. At this point, even when I try things that fail, I'm learning so much from each failure that it's sort of worth it, and I fail enough that an extra failure or two doesn't really slow me down much because I'm already so slow. I'll try to remember to post an update here once I've got results of some sort. Thanks for taking a look, and for the advice.

I think it can be done, probably in multiple ways, but I don't know enough to tell the difference between good ways and bad ways. Desired behavior in a MP mission: On no-fly-zone violation (any of coalitionA in zone), for each violation v1, v2, . . . ,vn, spawn one Coalition B fighter client slot, parking hot, with a specific payload. If one of these client fighters dies or lands, it should not be able to respawn/rearm. Basically I want a single-use player controlled aircraft slot to spawn based on a trigger, and become unavailable again once the player is done with it. I'm considering 3 different approaches to solving this, and if anyone has good advice on one of them being obviously better than the others, or all being terrible compared to option 4 that I've never heard of, I'd appreciate any guidance. I'm only about 10 days into the script/LUA rabbit hole, an I'm still not sure I've found a complete set of documentation yet (have Grimes's wiki and learned about script/Hooks docs in DCS install from looking at Ciribob's SSB mod). Oh, and of course the LUA project wiki. Approach 1 Base all the desired units at one airfield and increment warehouse weapon amounts on each violation. This just controls missile numbers, doesn't worry about number of planes or whether they can respawn, but unarmed sorties aren't that effective so it should have the same effect more or less. Haven't yet found any DCSscripts that look like they can be easily combined into a LUA script to increment/set the number of available rounds of a specific weapon as a trigger action. Possible workaround, spawn AI units on short final and hope they despawn correctly after landing so that DCS increments their payload into the warehouse. Sources have mixed reports on if this works, I haven't tested yet. Approach 2 Activate - deactivate groups. CoalitionA unit entering zone sets flag v_i, i=1,2,3,... Switched condition Flag v_i activates delayed activation group g_i with single unit with desired payload. Switched conditon Flag g_i monitors, death, crash, or landing and deactivates group g_i if Flag g_i = true. Activation works for me, deactivation is very inconsistent, not sure why, though single player, fly option from Mission Editor, and MP server all seem to behave differently maybe? Need to test more, but I have problems where I'm able to spawn back into a group that should be deactivated. Also having a player in the plane seems to prevent deactivation. Sure, explode unit can solve that, but it's not an elegant solution in terms of wreckage on taxiways/runways. Approach 3 Steal from the last few lines of Ciribob's- Simple Slot Blocking, ie. use the net.force_player_slot(playerID, sideID, slotID) -> boolean to force kick to spectator in MP, to just boot players out of the slot with a message explaining it's unavailable if flags monitoring whether or not the aircraft has been used are true and the death/landing/despawn flag(s) are also true. Using the kick function from 3 also seems like it might be an option for making 2 work more consistently. Any thoughts?

For a military simulator it would be very nice to be able to display mission tasks accomplished or not accomplished to the players, better than DCS presently does. For all its faults and limitations, in the Mission Editor it's fairly easy to set flags to keep detailed track of things that have or have not been accomplished in a mission. Getting those results out to players in a convenient, on demand, human readable format is a nightmare. A UI element, that would take a Mission Goal Mission_Goal_Name(score, coalition) So say an example: Save the fuel truck(10, BLUE) and an accomplished/not accomplished set of the associated conditions: for example: UNIT DEAD(EnemyArmor1-1) and UNIT ALIVE(FriendlySupply1-1) with a script or dialog entry that would let the mission designer assign the conditions a text string as a name to be reported to the UI GOAL CONDITION(1,"Armor killed") = UNIT DEAD(EnemyArmor1-1) and GOAL CONDITION(2,"Fuel Truck Alive") = UNIT ALIVE(FriendlySupply1-1) where the output would be like this if both the enemy armor and the fuel truck were still alive: Mission Goal Scores Coalition Blue Coalition Red Goal Points Objectives Goal Points Objectives Save the fuel truck 0/10 points 1 Armor killed false Nul Nul Nul 2 Fuel Truck Alive true Code only used to preserve column alignment here, obviously you'd want to have some sort of GUI display set up for the various fields. Probably a check mark or other graphic for the condition display rather than a print out of the boolean value. I suppose you'd probably also have to limit the number of goals per coalition, and the number of conditions per goal to keep the display reasonably readable. At any rate, I think this would be a tremendously useful addition to the current scoring functionality which is really just a kill counter. Note, I have no particular preference about whether this sort of function would be integrated into the existing SP and MP score displays, or implemented as a completely independent UI and keybind.

If clever in route planning often you do not need to actively reposition the vehicle before lazing, operating radar, or shooting. The way it works now is: 1) enter vehicle, 2) vehicle stops 3) player takes control or 4) goes back to map 5) resets route 6) commands vehicle to follow reset route, 7) return to F1 view 8: puts vehicle in gear 9) engages autopilot 10) finally get to laze, irradiate, shoot etc. The way I want it to work is to go from step 1 directly to step 10, skipping everything in between by having the autopilot defaulting to stay on rather than turning off. It doesn't take long to do all those intermediate steps, but it's long enough to interfere with a CA operator's ability to be sneaky, devious, and downright evil, especially in some air defense applications. If you have autopilot default to stay on, and have it turn off at player steering/throttle/brake inputs, then the player gets to go from step 1 to step 3 or from step 1 to step 10 without an administrative hassle that allows AI or human opponents time in which to shoot them. It's not a huge deal, but it is a minor to moderate annoyance if you want to push the limits of what Combined Arms can do. Basically for times when you need that one unit to be smarter than the AI for something like 5 to 15 seconds. Jump in, help, jump out is really useful, but it would be more useful if you didn't have to spend half of the time you intended to be in the vehicle redoing a waypoint route in F10. It has nothing to do with physics. It has to do with wanting finer input resolution than a binary 0% or 100% with no intermediate values. Driving precision is better if you can continuously adjust input amounts instead of just stuttering between 0 and 100 to make a very crude discrete approximation to analog inputs. I want to have input curves, not input stairsteps. Mostly looking for making it easier to avoid overshoots when driving fast in tight urban environments. I'd love better vehicle physics, but this isn't ARMA, and I'd settle for improved control input for the game "physics" we currently have. CA is interesting, but really the ground vehicles in DCS are just targets/objectives for aircraft to do things to. Physics for them may not be reasonable. Improved control interface for what they already do, may also not be reasonable, but it's maybe a smaller more practical request than proper physics.

Yes, pretty much this. There are a lot of situations where for movement you'd just stay in F10 view and play with waypoints, without ever jumping in to drive a vehicle. However, it's often potentially very useful to shoot/laze/operate radar/observe from a vehicle that's in a group that's already moving on a waypoint route. Oddly, the lead vehicle often has the best view of the battlespace due to a lack of obstruction from other units in the group. Even in other vehicles in the order, if the route is a road following route that is constrained by terrain or structures, having one vehicle stop can create a very disruptive roadblock, not to mention that stopping makes a much easier target. I think that in general, it would be more useful to jump in and have the default behavior be autopilot continuing to operate, and have driving inputs cancel the autopilot in the same way throttle or brake cancel the cruise control. That way it's responsive if you're jumping in to drive, but doesn't create disruption if you're attempting to enter the vehicle for some other purpose.

I'm not a pilot so there may be missing steps, but I think the procedure for GA in a plane with the 109's level of equipment would be along these lines: Tune radio to VHF 121.5 (optional if you know local ATC freq., which you probably should, in which case just tune to ATC). Pick up microphone (if not using headset mic) and press transmit key. Say, "Mayday, mayday, mayday," and then give aircraft identifier. When ATC asks if you're declaring an emergency say yes, and tell them that you're a VFR aircraft in IMC. Then you'd ask ATC to give you emergency assistance using their radar to vector you to a divert field that is not covered in fog. If the the above procedure did not work, and you didn't have enough fuel to wait out the fog or fly to acceptable emergency landing terrain with VFR weather, you would almost certainly die in a fatal CFIT crash. Taking a VFR plane or VFR pilot into IFR conditions isn't quite a death sentence, but it is a life and death emergency, and prospects for survival are very poor. In the event that you survived I believe you'd also have to fill out an incident report. Definitely recommended to make all your suicidally stupid aviation mistakes in a simulator rather than in real life though. Edit: There also might be a free lecture after landing (if you survived) on the foolishness of not installing a Mode C transponder and ADS-B on your vintage warbird.

If you have a control input device where you can bind your trim to an axis, you can just go into the axis tune menu for that axis and desaturate it. That's what I usually do for trim and also for a lot of planes with target designator boxes. If you have some but not enough axis inputs on your HOTAS, you can use a modifier or several to work around that, though it's not ideal because it locks out the base function for that input while the modifier is active. If you're just working with momentary switches for trim, then yeah, it's annoying.

This is a feature that I'd like for mission making. There are so many scenarios where a two faction system is inadequate. It doesn't have to be a huge number of course, but at least five.

At a guess you're overspeeding the gear. Not sure what the official max gear up speed is, but I'd recommend trying to get them up by about 350 km/h or 195 knots IAS. What I would like on the Su-25 gear is improved ability to land and taxi on grass, and a wheel brake axis (or two).

Interesting observation I had looking at this thread. I think when people are talking about "Core game function" there's some disagreement on what the core function is. If you look at DCS World as an aircraft simulator, then there is a lot of work on core functionalities. Typically there are significant upgrades on something, or even many things, coming out every month to two months. The changelogs bear this out. If you look at DCS World as a warfare simulator, and feel that once an aircraft is in game and more or less functional further updates don't really count as "core," then there's a reasonable argument that there have been long periods of inaction on core functions. Especially if you define core as anything that's key to your personal sense of immersion and/or fun, which are some what more subjective. What's more "core" in a list of: armored vehicle damage model, naval damage model, AI dogfighting logic, or air defense AI can depend heavily on what sort of aircraft and what sort of mission a person prefers to fly. I'd say that on balance, DCS has been, is, and for the forseeable future will continue to be, primarily an aircraft simulator. That's the focus, and they do a really superb job of it. For simulating everything else, well it's nice when stuff works well, but it's probably forgivable if for example my attempt to make a fun and engaging RallySyria.miz failed because a HMMWV couldn't make it up a hill that it would have had no trouble with in real life. DCS tries to be a high fidelity simulator, but it's a narrowly targeted high fidelity simulator.

Requests I'd add: Vehicle movement controls, left/right axis Vehicle movement controls Brake axis. When taking control of a vehicle that is on a waypoint route as a JTAC or Tactical Commander, instead of defaulting to disabling the route and stopping, default to the vehicle continuing to travel on the active route on autopilot until the player actively takes control. The current behavior can create havoc if you grab a unit in a convoy in tight quarters.

Slingloading animals is a thing in real life. It was a classic staple of '70s and '80s wildlife documentary TV shows. Of course the cow slingload should be based on a generic large quadraped slingloading API so that if more large animals are introduced slingloading can be easily added to them as well. There are some obvious possibilities after all: Warthogs Rhinos Wild horses Crocodiles Tigersharks aren't quadrapeds, but whales sort of are on a technicality, and the shape is similar enough that I bet you could make it work.

You can also center the Track IR cursor (as displayed in the track ir program interface). Setting a sufficiently large central deadzone can make this easier. Target lock in Combined Arms can also somewhat compensate, but TrackIR cursor has to be close to centered before targets can be locked. It's difficult and annoying though, so just pausing TrackIR, default is F9 I think, while shooting is the easiest workaround.