SA3 gets not registrated by SET_UNIT (and maybe others)

[DBBR406]

An SA-3 is not recognized by the MOOSE SET_UNIT. I put up a mission with a SEAD task (but it also can be reproduced with BAI or CAS tasks) and it says "no targets left" SA3.zip

[FlightControl-User]

Sorry, can't follow.

An SA-3 is not recognized by the MOOSE SET_UNIT.

What you mean with that?

[thebgpikester]

I believe the comments are saying it's not detected, rather than not in a SET, which I know to be false since SET's don't care about specific units (as long as it's not filtered, or isn't a static or something obviously wrong) and I've not had a problem myself. It's referring to a detection set in SEAD or other tasking, the report is saying the SA-3 is not detected if I translate the brevity of this.

The bug report is invalid in it's current state although the problem of detection may exist, for some weird reason.

If I were to spend 30 minutes of my own time on this I would want:

• DCS version (since SA-3 variously had some problems in history as a unit)
• Clean mission made from one of the detection demos and the SA3 swapped with an existing unit
• Steps to reproduce
• Expected results
• Actual results

Showing some effort by producing the logs, where you added SET:Flush() results would and should be expected to be supplied if the title is to be kept.

Videos can be substituted for those with trouble with the English for convenience.

The reason for the harshness on the report is because Detection works fine (I use it all the time), but can have unexpected results for the inexperienced due to line of sight, distance and darkness and the bug is badly phrased with an irrelevant title and explanation and it's going to waste 45 minutes of getting that mission replayed to find it's nothing to do with a SET and the Detection failed for any number of reasons. Additionally, having seen Detection show strange results in the past i'm inclined to believe it's down to something like that until the explanation and effort is put in to convince me it's a bug and not a config issue.

[DBBR406]

I'm sorry for my bad english skills and that you don't understand what i'm referring to. When i'm back at home i will provide the TASK_SEAD demo mission with an SA3 unit as target unit in it, to show that if you join the task and call the task report, the report says "No targets left" although there are units alive in the target unit. The only thing to reproduce is to join the task and call the report (you can do that with my attached mission). As i remember correctly the log shows that the SA3 unit doesn't get added to the target SET.

I don't understand what DETECTION has to do with this issue?

My expected result is the same result that i get in other tasks: the report shows the units in the target SET and the task is not marked as completed as long as the target unit is alive. The actual result is that the report says "no targets left" with the the following message "Congratulations ... task is completed".

Does it work for you in my attached mission?

As there is no problem with other units only with SA3, i thoght it is a problem with this unit type. But i did not check every unit available in DCS, so this problem could affect others as well.

[thebgpikester]

OK, now I looked at the mission (which I had to change to get working) I see your issue.

This type of TASK has been bugged for too long now and just doesn't work.

You should use the TASK dispatcher version and you will need a detection to get things to work.

I will be honest, I had tried this method for a very long time before giving up.

It's not the unit or the SET. SA3 is in the set, I can assign myself to the task but you will not get map updates and it breaks after this.

2018-07-04 11:51:54.610 INFO SCRIPTING: 6420( 6543)/E: SETTINGS00067.IsA2A_BRAA({[BRA]=true,}) 2018-07-04 11:51:54.612 INFO SCRIPTING: 11114( 11740)/E: SET_GROUP00116._FilterStart({[1]=Adding Object:,[2]=Client,}) 2018-07-04 11:51:54.613 INFO SCRIPTING: 63620( 67502)/I: MISSION00118.AddTask({[1]===> Adding TASK ,[TaskName]=HQ,[MissionName]=SEAD,}) 2018-07-04 11:52:08.671 INFO SCRIPTING: MOOSE error in MENU COMMAND function: [string "D:\temp\DCS.openbeta\/~mis00005199"]:67429: attempt to index a nil value 2018-07-04 11:52:08.671 INFO SCRIPTING: stack traceback:

[string "D:\temp\DCS.openbeta\/~mis00005199"]:67429: in function 'UpdateTaskInfo'
[string "D:\temp\DCS.openbeta\/~mis00005199"]:64982: in function 'MenuMarkToGroup'
[string "D:\temp\DCS.openbeta\/~mis00005199"]:63933: in function <[string "D:\temp\DCS.openbeta\/~mis00005199"]:63918>
(tail call): ?
[C]: in function 'xpcall'
[string "D:\temp\DCS.openbeta\/~mis00005199"]:7194: in function <[string "D:\temp\DCS.openbeta\/~mis00005199"]:7190>

I used a moose dev version and changed the script a little so it will almost work, you can have a look at what i did in attached file.

HQ = GROUP:FindByName("HQ") CommandCenter = COMMANDCENTER:New(HQ, "Overlord") Targets = SET_UNIT:New():FilterPrefixes("SA3"):FilterStart() PlayerGroups = SET_GROUP:New():FilterPrefixes("Client"):FilterStart() function SetTasks() Mission = MISSION:New(CommandCenter,"SEAD","Stage 1","Destroy SA-3",coalition.side.BLUE) TaskSA3 = TASK_A2G_SEAD:New(Mission,PlayerGroups,"HQ",Targets,"Doesn't work :( ") end SetTasks() SA3.zip

I would advise strongly to use A2G_TaskDispatcher as it's much better and handles the marking better.

[thebgpikester]

Last thing. https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/Task_A2G_Dispatcher.html

requires a detection. It doesn't cater for non detected groups so you need a blue spotter.

One day, maybe, we will get a proper method for doing assigned strikes without detection that will work how your original script did. I think I created bugs on this, but I stopped worrying about it because it's not going to happen fast.

[DBBR406]

I don't see why i have to use Task_Dispatcher for this as it was working fine with all other units and stuff. I use all kind of dispatchers in my mission and only had the problem with the SA-3 site. In addition it worked now with SA3 also, at least withe the DCS patch today. As it is working now, i wont revert DCS back to a previous version to see if the bug is persistent there. Maybe it was an other problem. Eventually this report can be closed. Some pics of the tests:

[Delta-99]

@DanWithUsernameNotAlreadyTaken - anything in the patch notes that points to something like this being an issue with detection with this unit? Wouldn't surprise me at all. Agreed that if everything else for you was working except for this one unit then it likely was a DCS bug. If its working now and you are satisfied then please let me know and we'll close this issue.

If it creeps up again in the future we can re-open it.

[thebgpikester]

I swapped the units around and it was broken just the same with other units. If you can get me a mission where it works as expected then I'd be chuffed to bits because as far as I am concerned this was my prefered tasking. Still as I said, I didn't get your script working, had to change it, then changed the units to another unit type and it all exhibited the same issues with marks.

Best to try my mission and comment back.

[thebgpikester]

Regards your screenshots - can you do the following and confirm:

1. Ask for marks on the F10 map
2. Review the results and DCS.log and send up the feedback

If it's anything like the script I used it was broken despite being assigned to the task.

[thebgpikester]

Onece more, this is the legacy tasking that FC dropped in favour of rewriting the dispatcher. There is NO detection and the SA3 shows up Definitely in the SET with SET:Flush(). This type of task just takes the SET and spits out the units into a task machine.

[DBBR406]

@thebgpikester Will do this asap and update this comment. Can take a bit as i'm eating in a few minutes. @Delta-99 yes i'm satisfied right now. Despite as i reviewed the screenshots i noticed that the search radar does not show up in this report (but it is in the same group in the mission). I will do further testing but it is OK for my purposes.

[thebgpikester]

I'm interested mainly because I'd like to see this working so I can use it myself actually! I genuinely couldn't get your mission to work, the birth event never fired so the function never started, then I got the same as you for no Objects, hooray, success mission so I moved the SET to before the function in case it was timing and it showed up, then I came to the error with the Map markers. So I had to change a lot to get it to work as I saw it. This is why the confusion is there.

[DBBR406]

Without the birth event i don't get any tasks in the mission. It gets fired, if you go to spectator first. I don't know why it has to be with an event as i did it some patches ago without this and it worked. I think it has to do with a DCS-bug in the Player-Enters-Unit-Event (but i'm not sure). Marking does work. In the attached zip is the working mission and my log file. There is an error in it but this error should not break anything (and there are often errors from reports from the tasking, but not this time in this log and they don't have much impact, at least after a player joined at least one task). And, if i'm correct, only four units get added to the SET_UNIT, the track radar in the SA-3 site is not added to the SET (i think so). TSK-010 - Task Modelling - SEAD.zip

[thebgpikester]

Just to let you know, yes, four targets out of five, because in that specific mission, the 5th target is called something completely different and doesn't go in the filter. I'm working it now.

[thebgpikester]

tasktest.zip it works perfectly apart from the GetAlt bug which I have no idea what that is from but saw it all the time.

1. All units show up in the filter in the logs.
2. In the demo mission there is a unit called Hawk PCP blah blah and it's not in the SET and ignored.
3. I made the mission host only friendly because I think you are testing on a dedi server, so I removed the event since it wont fire for me.

If we talk about the original subject line, the best possibility I can think of was an incorrectly named unit as they always showed up, no matter what unit type.

I can't think of a reason to keep this open because it just works. See per attached miz. we can close.

[thebgpikester]

GetAlt() bug goes away without issue (so far) if you change GetAlt() to GetY() on line 83306 in dev @DanWithUsernameNotAlreadyTaken check issue #956