Wizard1393

+1 on the Reverb G2

Man I remember back in the 1.2.6 days-ish when the KMGU dispensers where da bomb. Very effective and cool effects. Somewhere along the lines they changed the weapon, removing the cool visuals and completely nerfing it to the point of uselessness. IIRC it caused performance issues as it was, and thats why they changed it. However, they could have skipped the nerf imo.

Ok well, still, ED should be able to fix it as other steam vr games does not have this issue?

Tried the tool. Making it symmetric and then swapping up down made it better. But not 100%. Still have a weird feeling, but just not as bad. How come DCS have a problem with "alignment" when other games do not? Why should I as a customer be having to fiddle with this? Please fix it ED. Also, if anyone have managed to get a 100% feel good alignment for the G2, please post the settings file.

Wow I thought something was off. Why did I feel crosseyed in DCS only with my new Reverb G2??? So there's definately an issue with the G2 and DCS then? EDIT: Tried the tool. Making it symmetric and then swapping up down made it better. But not 100%. Still have a weird feeling, but just not as bad. How come DCS have a problem with "alignment" when other games do not? Why should I as a customer be having to fiddle with this? Please fix it ED! Also, if anyone have managed to get a 100% feel good alignment for the G2, please post the settings file.

F-15 for me is the hardest, being that the refueling port is behind the canopy. Never tried in the F-16.

I'll have a cheap HP Reverb G1 for sale pretty soon...

Yes, exactly that, except I also had the elevation caret visibly moving left to right in the top. Interesting. I know I used ACM Guns in this flight. But I also know I've done the steps you're describing and not have the radar end up in a faulty state. I usually STT lock target, switch to guns, kill target, then to exit ACM Gun mode i usually select AIM-120 and then Undesignate. Perhaps the step that breaks it is in the step how you EXIT the Gun mode rather than enter it? If I have time later I'll test and produce the exact steps to reproduce...

Yesterday I had a weird occurrance with the radar. The azimuth caret was moved to the left side where the elevation caret normally is, and the elevation caret was moved to the top of the DDI. It was not like this from the start, happened somewhere during flight. Anyone else happened upon this bug?

Yup. Nice catch @captain_dalan

I'm thinking it must not be common that people are popping chaffs if you can't detect anything locking you (TWS)? I'd agree though that you would activate your ECM Jammer if equipped when in a hostile environment. Maybe thats what you mean by "reacting"? If STT locked thats another story though, that you react to.

I'm not sure about all this, but I'm curious. Imho, regarding the default CAP task when no parameters are given, fighters should prioritize engagements according to threat level. So if you have a BLUE bomber group and an escort fighter group, RED fighters should engage the fighter escorts first, again, if no parameters are given. And offcourse, if the player/client is in the fighter escort group, it should not matter, AI should not prioritize player/client more than any other fighters in the escort group.

Yes, I've heard this mentioned before, however honestly it should be reviewed and changed. It's an OK solution when SARH/IR missiles are fired. But it is severely needed to change the behavior regarding reaction or ARH missiles. AI should only react when ARH missile gone Pitbull as this will trigger a RWR launch warning.

Cool! Np! I should have posted that this was the cause. I'mma change the thread subject now... EDIT: Couldn't change old post subject. Updating first post.

Cool. Yeah I've fiddled some with Moose some year ago and it's a powerful framework. I just never got around to getting myself really into it and learning it's functions. Also, like Grimes kind of said, when your result (e.g. AI behavior) is not what you intended, it's so much harder to know if it's the wrapper code (e.g. Moose) or the SSE itself not doing what you expect. The native SSE I understand and know my way around. Thats why I keep using it in conjuction with the excellent MIST library. Force of habit I guess :)

Yes. I'm going to try this as well, although with scripting, and see what the result will be, if they rush from 100+miles away to engage something that's in the engagement zone. I'm also wondering what the engagement distance is. I'm thinking there must be one, under the hood somewhere, concealed from scripting. I mean, otherwise any AI CAP flight with AWACS support would fly hundreds of miles to engage any enemy aircraft...

I just want to say that the cause of this for me turned out to be modded viewdistance preset lua files (Extreme.lua, Ultra.lua etc.). I had done this to get even longer ranges etc. Reverting to original files removed this "bug" for me.

You are absolutely right. I get it now. You need to checks, one that checks MaxDist from route so they won't stray for too far, and also one for checking MaxDist from self. That way you can say "Go max 60 miles away from route, but also only engage targets within 30 miles from self.

@Grimes Wow, just wow. I applaud you. Grimes the script ninja strikes again. That is it, tested now with the red cap point 55 miles away from the blue awacs orbit point (MaxDist set to 45nm) and they do not engage. Wow this bug is bad. That removes the use (for me) of the MaxDist setting almost entirely. I like dynamic and unpredictable content. This bug makes my mission more static :( EDIT: So wait. The spawned red AI MiG's in this case can only have this MaxDist bug "apply" on ME created assets then right? I have a few ME placed flight such as AWACS and tankers, if I made all blue flights spawned the bug is not there you think? EDIT2: And you say that it's a "known behavior"? So it's not a bug? Thats weird. This is so far from what you think the MaxDist setting would do. You easily assume if at any time during the flight, an enemy aircraft comes within MaxDist setting, it will engage. Not "if blue flight wpt/leg is closer than MaxDist to red flight wpt/leg" engage at any distance... how'd did they even come up with this?

Yes, it's basically copied from the mission file the ME generated and then adjusted, (some non-critical stuff omitted, some changed to vars etc.) In my test, no, the ME placed MiG was not exactly in the spawnzone for the script-spawned migs. But it was closer to targets as I recall it, within 70 miles or so. Spawnpoint for script spawned red CAP is around 80-100 miles. But spawned red MiGs almost immediately see the orbiting blue awacs and escort fighter from 120-ish miles away, goes full AB and climbs to 30k+ feet. I'm curious too though about what you wrote about the bug. Can it be so, that because the MiGs eventually will (if not contested) end up within 50 miles of the blue AWACS orbit point, they engage right away?. It's in their route to end up close enough to engage. @toutenglisse My script gets the point from a zone point so it doesn't have the altitude coord. Also I know my coords work since they fly the route normally when there's nothing to engage.

Do you get dynamically spawned AI aircraft to follow a specific route (waypoints) and route (waypoint) actions with moose?

I'm spawning it via mist.dynadd(groupTable) GroupTable: local tblGroup = {} tblGroup = { ["country"] = 'Syria', ["category"] = 'AIRPLANE', ["units"] = tblUnits, ["name"] = 'Red Fighter Group', ["route"] = tblRoute, ["task"] = "CAP", ["taskSelected"] = true, } Unit Table (tblUnits): local tblUnits = {} local intUnitNum for intUnitNum = 1, 2 do tblUnits[intUnitNum] = { ["name"] = 'Red Fighter Unit ' .. msn.funcNextRedUnitNumber(), ["type"] = "MiG-29A", ["payload"] = msn.cap_SpawnFighterGroup_payload(), ["skill"] = "Random", ["onboard_num"] = "10"..intUnitNum, ["alt"] = 1000, ["alt_type"] = "BARO", ["x"] = spawnPoint.x+spawnDist, ["y"] = spawnPoint.y, ["speed"] = 210, } spawnDist = spawnDist + 100 end Route Table (tblRoute): local wpt2Point = mist.utils.vecToWP(trigger.misc.getZone('Objective Zone').point) local tblRoute = {} tblRoute = { ["points"] = { [1] = { ["alt"] = 1000, ["action"] = "Turning Point", ["alt_type"] = "BARO", ["speed"] = 210, ["task"] = { ["id"] = "ComboTask", ["params"] = { ["tasks"] = { [1] = { ["enabled"] = true, ["key"] = "CAP", ["id"] = "EngageTargets", ["number"] = 1, ["auto"] = true, ["params"] = { ["targetTypes"] = { [1] = "Air", }, -- end of ["targetTypes"] ["maxDist"] = 83340, ["priority"] = 0, }, -- end of ["params"] }, -- end of [1] [2] = { ["enabled"] = true, ["auto"] = false, ["id"] = "WrappedAction", ["number"] = 2, ["params"] = { ["action"] = { ["id"] = "Option", ["params"] = { ["value"] = 2, ["name"] = 1, }, -- end of ["params"] }, -- end of ["action"] }, -- end of ["params"] }, -- end of [2] [3] = { ["enabled"] = true, ["auto"] = false, ["id"] = "WrappedAction", ["number"] = 3, ["params"] = { ["action"] = { ["id"] = "Option", ["params"] = { ["value"] = true, ["name"] = 15, }, -- end of ["params"] }, -- end of ["action"] }, -- end of ["params"] }, -- end of [3] [4] = { ["enabled"] = true, ["auto"] = false, ["id"] = "WrappedAction", ["number"] = 4, ["params"] = { ["action"] = { ["id"] = "Option", ["params"] = { ["value"] = 2, ["name"] = 0, }, -- end of ["params"] }, -- end of ["action"] }, -- end of ["params"] }, -- end of [4] }, -- end of ["tasks"] }, -- end of ["params"] }, -- end of ["task"] ["type"] = "Turning Point", ["speed_locked"] = true, ["y"] = spawnPoint.y, --var I send to the function that create the route table ["x"] = spawnPoint.x, --var I send to the function that create the route table }, -- end of [1] [2] = { ["alt"] = math.random(3000,7000), ["action"] = "Turning Point", ["alt_type"] = "BARO", ["speed"] = 210, ["task"] = { ["id"] = "ComboTask", ["params"] = { ["tasks"] = { [1] = { ["enabled"] = true, ["auto"] = false, ["id"] = "Orbit", ["number"] = 1, ["params"] = { ["altitude"] = math.random(3000,7000), ["pattern"] = "Circle", ["speed"] = 150, }, -- end of ["params"] }, -- end of [1] }, -- end of ["tasks"] }, -- end of ["params"] }, -- end of ["task"] ["type"] = "Turning Point", ["ETA_locked"] = false, ["y"] = wpt2Point.y, ["x"] = wpt2Point.x, ["speed_locked"] = true, }, -- end of [2] }, -- end of ["points"] }

Hi, I'm trying to spawn a red fighter group of 2 MiG-29A's and have them go to a waypoint which is in the "players" CAP area. I want them to have an Engagement distance of 50nm so I've set that in the task. When they reach their waypoint they should orbit there, engaging anything that comes within 50nm, then RTB at bingo. This works fine with a predefined group in the mission editor. But not when spawned dynamically. The fighter group is spawned in around 80-110nm away, but they almost immediately climb to 30k+ ft, goes full AB and pushes towards the blue Awacs or tanker which is 100nm+ away. Perhaps I'm doing something wrong in my spawning. Does anyone have any guess as to why this happens?

Yes I believe you are right. I remember having this issue since 2.5 even in non-vr mode, however I remember that as you say, it happened randomly sometimes when entering a server. You had to either disconnect/reconnect or restart DCS entirely to resolve the issue. This might be the same root cause, but I figured I posted this separately because it's been very frequent for me that it happens almost every time I'm shot down/eject/die and respawn in another slot. Sometimes it happens even before I choose another slot. But always after crash/ejection/death. This happens in SP. And even though choosing a same aircraft type slot. I've checked it before many times, there's never anything abnormal or something indicating an issue in it. But sure, next time it happens, I'll save the log file and attach it to the first post, so you can check it too.

Track uploaded to first post. Please also note that while you can see in the track how the second MAV wanders off target when uncaged the first time as descibed in my first post, it also locks the wrong target after cage and ungage.