nighteyes2017

Ok, a friend of mine had this weird problem with an X65f from saitek in windows 11. I found a post with a solution that finally worked, and i thought I'd share for future reference and for anyone having problems. The symptom are that in windows, the calibration of the axes seem fine, but in dcs the axis give 100% or -100% and nothing in between. turns out the calibration process, gets stored in the windows registry with the wrong values. Deleting these entries solves the problem, or, if you need deadzones, you can adjust the values manually. the post tells you how i found it in this post, read carefully. https://forum.piboso.com/index.php?topic=20051.0 the post describes W10, but W11 works just fine as well. As i said, i ended up just deleting the calibration entries for the faulty axis and that worked. (reboot after deleting or adjusting) you need your product id used in the registry. i found that here: https://forum.simflight.com/topic/78117-fixing-problems-with-50-or-digital-onoff-action-with-saitek-levers/ this post didn't actually work, but going into the registry there i was able to identify the needed id because the entry values said saitek. so i cross referenced that with the other post and voila!. it is also possible to just go over the registry entries and see which one has a subfolder named 'calibration' it.

seems that when you tell the ground vehicle to switch waypoints, it just stops. I know that another issue like this is already open. Probably related. setup: ground vehicle on the runway, steerpoints along the runway. last waypoint halfway to the right of the runway. set a recallable action to switch to last waypoint add radioitem to set a flag when flag true, call the action to switch to the waypoint. run mission, let the vehicle drive a bit, then use F10 menu to set the flag to true. result: vehicle stops where it is. Goto waypoint stops vehicletrk.trk goto waypoint test.miz

It seems that parkings that the hangars at parking number 1 and 2, actually also hold parking 3 thru 6, which doesn't match the map numbers. This in turns offsets all the other parking numbers by 4.

I am currenty building a mission and have the same settings. Evade off, Status Red. I cannot get the SA15's to engage the harms. So whats the difference? I am trying to get the SA15's to defend the SA2 next to it. But every time the only start to launch about 1 second before the harm impacts the SA2. Too late. They used to be much more aggresive. I now am unable to get any sam to engage the harm. Maybe the new harm profile is now too good?

I heard that eventually, the new tgp will replace the old one, and that the old one will be removed from the game. If so, how would this affect existing mission files? Will the new one be automatically placed instead of the old one in mission files? cause that would be great!

It still doesn't make sense to me to just use a tv mode in the center which has the same level of zoom (absolute zoom, i'm not talking about the fact that the tv zoom has to zoom further than the ir to get the same picture). Not just in the TGP and flightsims, but as a general rule, PIP's are used to give a more zoomed in detail of a larger view. Think electronic microscopes for a second for example. The pip's on those monitors show a higher level of zoom than the general area the camera is aiming at and not just a crisper image. I get that the quality of the image is better in tv mode (what about at night?) but the zoom level itself in my opinion should also be higher. I cannot fathom that any airforce would miss something like that. I can even imagine that one could simple set the level of zoom of the pip itself. With the old TGP, i normally would set a zoom level where i can distinguish potential targets as small dots, and then inspect those dots using the FOV button, and if it is not a target, i zoom out again and scan further using that general level. Thus inspecting each potential dot. With the PIP, i would have expected this to be able to do in 1 pass. With the higher zoom in the PIP. So it is not intended to work like this? I would call that i missed chance. Unfortunately i don't have any documents or sources to show any of this, i am just very much wondering and speculating about the functionality and usefulness of the PIP here. If it just works like this in real life, fine. If we wanna do it as real as possible, no arguments there. It just that it seems a waste of potential functionality.

So from my previous bug report and the answer on it, i understand that the tv is actually at a higher zoom. but with the surrounding IR picture is basically means the same detail level. So whats the point??? I mean, i get it if the PIP show a higher zoom than the surrounding area. Isn't the idea then that you can use the surrounding area to see where your target pod is looking in the big picture, and then see more detail at the PIP? that would be a good workflow and i'm guessing here, but i think that would be the point. But if the PIP just shows the same picture, but just in TV mode, what is the use? I therefore think that the level of detail in the PIP should be higher than the surrounding area???

according to waggs' youtube explanation (part 1, 6m22s in). the PIP in the new tgp should have a higher magnification. but as you can see, it isn't

yeah, i'll try to make an extraction from different situations on the acmis, and pile them together.

From what i have seen the last five missions i have flown, this is still an issue. The ai is able to dodge aim120's by barrel rolling. The acmi's from those missions clearly shows multiple ai thrashing multiple missiles by rolling. Is this still on ED's radar?

Many thx!. So based on that, it sounds like the better option for that action would be to have it always turned on by default, and have to option to turn it off. Guess ill update my templates to turn this option on.

yeah i saw that, but that is not much information. That just calls for more questions than it answers. Like 'when does the AI avoid combat engagements?' This action was written for a reason. What is that reason? So far i have not encountered a situation where this action could have helped me out. How do i use this action exactly?

I understand that, but the general consensus is number two on the left. And even if you can do right and left hand, then you should make that an option like they did with echelon right en left.

Used the formation option on a group of 4 AI F16's. Set finger four formation. Seems its in reverse.

So what does this setting actually do in the mission editor?

Could we have the same ruler in de mission editor as in the mission itself using the F10 map? I mean, in the mission, the F10 map ruler shows true and magnetic heading at the same time, but not in the editor. Also, the compass rose is available in the mission, but not in the editor.

Some very weird AI behaviour only in multiplayer: The mission: Put 1 flight of 2 F16's on the ramp, cold start, set as clients Put 1 flight of 2 F16's on the ramp, AI cold start, set flag as uncontrolled. It happens only client side in multiplayer. After 60 to 80 seconds, the uncontrolled AI flight lead start gently rock left right around the Z axis while parked, then becomes faster and faster. The host does not see this, only the client. If multiple AI flights are on the ramp as uncontrolled, all the flight leads start rocking. Tested with several different hosts, and several different clients. Test with both AI and clients as F16 and F18's. Happened also, so probably not module related. If you let it continue for a while, it crashes the client. Mission file included. Client Track file included. EDIT: changed AI to A10II's. And then it does not happen. So maybe still related to F16/F18 ! spin test-20250112-140305.trk spin test.miz

For some unknown reason. The missions, wich have not been altered, now suddenly work again. I really didnt change a thing. Now however, the AI will not shoot sooner than 27nm. No matter wich aircraft or missile, AI shoots at 27nm. So a Mig31, loaded with R33 (54nm) coming in at mach 1.2 at 40000, set to max range launch, still will not shoot until 27nm. Each red aircraft, with either a R33 or a R27ER (37nm), no matter the settings, will not shoot before 27nm. Seriously, ED needs to look at AI BVR behaviour. A couple of updates ago this was a big improvement thingy. However its not working anymore.

I am trying to get the AI to engage in a BVR fight. However, whatever i try whatever type of aircraft, or whatever task or rule i try to give the AI, it will not shoot unless i close to around 10nm!! This wasn't a problem before. Also on missions in the past where i had this working just fine, this no longer functions. Tried giving the AI aim120, r77, r27ER. Tried setting max range launch, intercept, fighter sweep, cap, attack specific group, engage in zone, come in high and fast etc. etc. No matter what i try, AI does not fire untill close range. what.....the......heck is going on?

Could we have an airframe filter on the warehouse pages for an airfield? Almost every time, i would want to make a weapons available or unavailable for a specific type, and sorting through which weapon belongs to which airframe makes it difficult to find them.

mmm, this is weird. Because for me this is exactly what the engage in zone does. When i test it, as soon as an enemy leaves the zone, the AI breaks off the attack and goes back to their patrol route. mission file example included. I put the target a bit far away in order for de CAP to setup their race track. otherwise at the start they wont react right away because of that setup. (takes about half an orbit). engage in zone test.miz

well, i thought this was a bit of a fun challenge to figure this out. It seems i got it working. It would be a bit difficult to explain it al in text only, so i included a mission file to go with it. Here goes: First of all, you need to discern 2 different things: if the missile fire is the first, or a second or third missile. So when the first missile fires, you detect a missile, and you set a "Missile Active" Flag to on, and you also test that flag to be OFF on that very same trigger. If that flag is off, it is the first missile. --- Then. You need to clone that exact trigger again, but this time, check for that "Missile Active" Flag to be ON. If it is true, then this is not the first missile. Now Set the Missile Active" Flag to on again, even if it is already on. Now. on this second missile detection, you set another flag to true, name this a "Multi Missile Active" Flag You need to check this flag as well to be off on the first detection trigger. --- Every time a flag is set to on, while it is already on, that trigger will restart the count. (you could also build a trigger to manually set it to off, and then immediatley set it to on again after 1 second) Now build a trigger that sets the "Missile Active" Flag to off after 120s (time since flag). Build another trigger that sets the ""Multi Missile Active" Flag to off after 180s (time since flag). --- As for the detection zone, make it small. why? Well, the above works in theory, but needs one more thing. If a missile is launched, and the flag comes on, it wil immediately trigger the second detection rule also, since the only difference in the detection triggers is that "Missile Active" Flag. So we need to build an inhibit flag. A flag that comes on with any missile launch, but then sets a flag for 10 secs and then turns off. that flag needs to be off in order for any of the 2 missile detection triggers to be valid. Those 10 seconds is what the missile needs to leave the small detection zone. So when the inhibit switches off, there is no missile to detect in the zone anymore, and the zones are ready for the next detection. Lastly, i build in a missile launch simulator. Which means you can use the radio F10 menu to trigger a simulated missile launch. That is why you will find the 'OR' statements in the detection triggers. also, i set the timers different for easy testing. 30 sec instead of 120, and 60 secs instead of 180. You can easily adjust those off course. Text messages included in the operations. Hope this helps. Missile loops.miz Missile loops with missile simulation.miz

1. alright, then its a bug, obviously. 2. you can actually. you can check if the object exists so it is nil. Also, you could define an array for all existing groups at the beginning of the mission that exist and thus are alive, so you know which groups should be alive. again, its a workaround. 3. thought you would have, but just to be sure.

ah, i understand. Sorry for misinterpreting. I'm not entirely sure this is a bug exactly since checking for a group alive less than, or a group that is dead, won't yield the same result. I guess it comes from when a group that is dead, you can't check it for how alive they are, since the group no longer exists in the mission database. Did it actually work before this? Then it would be a bug. But i have run into this problem when scripting lua, and it made sense to me because you can't check a variable for an object that does not exist, unless you made a note of it when it did exist, and remember that value. However as a workaround: What i always do in my triggers, is add an or statement, checking for group dead, so: group alive less than 50 OR Group dead This should work as a workaround and a failsafe.

I took the trigger 1 test from OP en tested it. It works fine, except for 1 thing. The trigger was set for 50%. That means that if 2 out of 4 units are dead, the trigger wont fire!. Because 2 out of 4 units actually equals 50%, and not less than 50 %. Set the trigger for 51% and then it will work. So for example if you want the trigger to fire when only 1 out of 4 units dies, you should set 76% and not 75. I edited the mission you used and added a gamemaster and an F10 menu to explode each individual unit for easy testing. This worked for me just fine. Trigger Test 1 edited.miz