Hardcard

I've tried Google, forum search, checked both the manual and Chuck's guide, but I haven't found any info about the Mi-8's IFF responder. Does anyone know if it actually works? Does it require setting up? If so, how? I'm asking because Mi-8s don't seem to respond to IFF interrogations (at least when vipers perform them... I'm not sure if it's a viper bug, an mi-8 bug or something else)

@Spins321

Issue persists in OB 2.7.1.7139

Issue persists in OB 2.7.1.7139

@Cyclops Your server hook is using an incorrect suffix ( "_client" instead of "_Client" ), that's probably why it isn't working, remember that Lua is case sensitive. Also, I'd remove all the dashes from your client group / unit names in the mission, since they might cause problems, use underscores instead.

@GusPT Doesn't need to be deterministic, you can randomize the offsets at your convenience, ofc. As long as the x offset is a positive number, the spawn point will be ahead of the chosen aircraft (regardless of its orientation). As for the z offset, it can be either positive (right side relative to aircraft) or negative (left side relative to aircraft). Y offset is for altitude, + = above, - = below. The offset point doesn't even have to be the actual spawn point, you can use it as the center of a spawn zone instead (from which you can get a random spawn point). Think of it like a big ass Cartesian graph, with your aircraft at the origin. 12 o'clock? x = positive number, z = 0 9 o'clock? x = 0, z = negative number 3 o'clock? x = 0, z = positive number 45º right? x = z ( as long as the value is greater than 0 ) 45º left? z = x * -1 ( x needs to be a positive number greater than 0 ) etc.

@Bones1775

I looked into offset points a couple of years ago, @funkyfranky was kind enough to assist and he ended up creating a MOOSE function that returns a vec3 point, offset from a chosen unit by a desired distance in all three axes. You basically introduce the desired offset in meters for each axis, the function will take care of the math. Most of it is standard Lua, you should have no trouble adapting it to MIST. Note that :GetOrientationX(), :GetOrientationY() and :GetOrientationZ() are the MOOSE way of accessing the DCS orientation tables returned by :getPosition() (x, y and z subtables only, not the p subtable). Here's the function. function POSITIONABLE:GetOffsetCoordinate(x,y,z) -- Default if nil. x=x or 0 y=y or 0 z=z or 0 -- Vectors making up the coordinate system. local X=self:GetOrientationX() local Y=self:GetOrientationY() local Z=self:GetOrientationZ() -- Offset vector: x meters ahead, z meters starboard, y meters above. local A={x=x, y=y, z=z} -- Scale components of orthonormal coordinate vectors. local x={x=X.x*A.x, y=X.y*A.x, z=X.z*A.x} local y={x=Y.x*A.y, y=Y.y*A.y, z=Y.z*A.y} local z={x=Z.x*A.z, y=Z.y*A.z, z=Z.z*A.z} -- Add up vectors in the unit coordinate system ==> this gives the offset vector relative the the origin of the map. local a={x=x.x+y.x+z.x, y=x.y+y.y+z.y, z=x.z+y.z+z.z} -- Vector from the origin of the map to the unit. local u=self:GetVec3() -- Translate offset vector from map origin to the unit: v=u+a. local v={x=a.x+u.x, y=a.y+u.y, z=a.z+u.z} local coord=COORDINATE:NewFromVec3(v) -- Return the offset coordinate. return coord end Here's a version of this script that I made for a test mission, using variables rather than tables, perhaps you'll find it easier to work with: function() local Cargo = UNIT:FindByName("Cargo") -- Vectors making up the coordinate system. local CargoXX = Cargo:GetOrientationX().x local CargoXY = Cargo:GetOrientationX().y local CargoXZ = Cargo:GetOrientationX().z local CargoYX = Cargo:GetOrientationY().x local CargoYY = Cargo:GetOrientationY().y local CargoYZ = Cargo:GetOrientationY().z local CargoZX = Cargo:GetOrientationZ().x local CargoZY = Cargo:GetOrientationZ().y local CargoZZ = Cargo:GetOrientationZ().z -- Offset vector: 24 m ahead, 5 meters above, 0 meters starboard (variable format) local Offset_X = 24 local Offset_Y = 5 local Offset_Z = 0 -- I've set it to 0 because the cargo containers are aligned with the ship's Z origin -- Scale components (variable format) local Scale_XX = CargoXX * Offset_X local Scale_XY = CargoXY * Offset_X local Scale_XZ = CargoXZ * Offset_X local Scale_YX = CargoYX * Offset_Y local Scale_YY = CargoYY * Offset_Y local Scale_YZ = CargoYZ * Offset_Y local Scale_ZX = CargoZX * Offset_Z local Scale_ZY = CargoZY * Offset_Z local Scale_ZZ = CargoZZ * Offset_Z -- Add up the relevant scale components to get the final offset values local Addition_X = Scale_XX + Scale_YX + Scale_ZX local Addition_Y = Scale_XY + Scale_YY + Scale_ZY local Addition_Z = Scale_XZ + Scale_YZ + Scale_ZZ -- Get PointVec3 and add up vectors in the unit coordinate system ==> this gives the offset vector relative the the origin of the map (variable format) local Cargo_Offset_PointVec3 = Cargo:GetPointVec3():AddX(Addition_X):AddY(Addition_Y):AddZ(Addition_Z) -- Flare Cargo_Offset_PointVec3:FlareRed() end

This

Problem persists in OB 2.7.1.6709

Yup, problem persists in OB 2.7.1.6709.

Problem persists in OB 2.7.1.6430

@[ED]Obi @Flappie Same here, problem persists in OB 2.7.1.6430

@Kappa Are you sure you have tested it for long enough? Problem persists in my case, regardless of driver version

@Xavven If you're using mav H or K with the viper, it makes much more sense to force correlate after TPOD designation. Why get within 3nm of the target when you can force correlate and hit from 12nm?

@FlippingGerman @Furiz I've just performed my first mav boresight on the ground, using a runway sign, it really does work Awesome tip, thanks guys.

@G.J.S Ok, then forget I said anything

@Flappie @[ED]Obi Looks like this affects AMD cards, for the most part, although some Nvidia users are also experiencing it. It's odd, since I've been using this card for years and never experienced problems with DCS before 2.7.

Ok, looks like this issue only affects AMD cards.

@dorianR666 @DOG Do you have AMD cards, guys?

@gunterlund I don't own the Syria map and won't be buying it any time soon, so I can't take a look. Also, SWAPR is only meant to support stable versions of MOOSE, since dev versions change every few days.

@gunterlund21 You making me work on Sunday, huh? No prob, I'll take a look right now

@Mav87th The mission file you included in "Mission and Logs" zip was using a modified SWAPR script with invalid syntax in line 19, that's why it didn't work, like I explained. After correcting that line, I set "Game_Mode" to "SP" and tested in a single player environment, seemed to work fine, even with 4 clients in the same group (which I don't recommend). I tested the same mission with SWAPR 1.4 and noticed some weird behavior: 1- First client in the group eventually gets replaced by an AI with the engines running. Also, when jumping back to that slot, the client starts hot, even though it's set to cold start in ME. This is probably a DCS issue, since SWAPR doesn't force replacements to start hot (it actually does the opposite), also, it can't change the settings of the original clients in ME, it can only influence their replacements. 2- The third client in the group is ignored at first (doesn't get the initial replacement used for heading capture), but it does get the actual replacement in the end. I honestly don't know what's going on with that, but it might be linked to having several clients in the same group. 3- I experienced a couple of abnormal spawns that led to access violations (ie DCS crashes). This might also be linked to having several clients in the same group, or having some of them in sheltered parking spots and the rest in open parking spots... In any case, I noticed something else in your mission that can potentially cause problems, the group name has a dash in it "Toxic-2". As a general rule, avoid using Lua characters in group and client names, since it might lead to problems and crashes. Like I explained in the main post: To be on the safe side, avoid using any of the following characters in either group or unit names ( ) [] {} / | # , . ` ´ ' % + - ~ = * ¿? ¡! ¨ ^ $ € @ Underscores are fine, you can use as many as you want. Yes, I know that Mission Editor automatically adds dashes to group and client names, but it doesn't generate replacements like SWAPR does, so it's better to be cautious. Anyway, despite these problems, SWAPR 1.4 seems to work fine with your test mission, even when you have 4 clients in the same group (which, again, I don't recommend)

Issue persists in open beta 2.7.0.5659 Please, this needs urgent fixing

I have an AMD card as well Issue persists in open beta 2.7.0.5659, UI broke again, logs attached dcs.log dcs.log