some campaigns use unsupported quad zones for scenery objectives, "No white triggerzones found"

[hreich11]

Affected versions

Development build 6.0.0-4.2.3.0

Development build

6.0.0-4.2.3.0

Campaign name

• [x] Peace Spring
• [x] Vectron's Claw
• [x] Golan Heights

Blue faction

US

Red faction

n/a

Modifications to default settings

n/a

Description

No white triggerzones - error on campaign start wizard

Log file

n/a

[5js-xifu]

Affected versions

Development build 6.0.0-4.2.3.0

Development build

6.0.0-4.2.3.0 Campaign name

Syria- Peace Spring

Description

No white triggerzones - error on campaign start wizard. This campaing contains maps objets . It seems this error only affect to campaings with map objets. With build 4211 the campaig works well. It was broken since update pydcs in 4230 build.

[Raffson]

Those campaigns contain blue quad-point triggers, which are supposed to be circular according to the wiki (see #2375). Adjusting the campaign's mission file so it uses circular triggers zones instead should fix the issue.

Though I'm thinking more in terms of introducing support for quad-point triggers, because given the 4 points it should be deductible whether another point (representing the center of the white trigger zones) lies within its bounds.

I think this would sit best in pydcs itself, this way Liberation could validate trigger zones by using something like blue_zone.is_point_in_zone(white_zone.position). I'll see if I can slap something together.

[5js-xifu]

I have a campaing in nevada with all blue triggers zone in circular, and the objets are white and quad-point . the error is the same.

File attach

redflag_campaing.zip

[Raffson]

Interesting, I'll have a look at it over the weekend, but either way, I think I have the math locked down for the idea I mentioned so I'm starting to get convinced that's a better way to go.

[Starfire13]

Thing is, square trigger zones used to work just fine. I've been using them since they were available in the editor. The reason the wiki doesn't mention them is because back then, only circular trigger zones were available in the mission editor. But it looks like square ones are no longer accepted in the latest pydcs. If this was an inadvertent change, then I would think the easiest option is to just revert back to the old behaviour.

[DanAlbert]

I don't think it was working the way you think it was. Pydcs only had circular zones until very recently (and it differentiating these is what caused the breakage). I really have no idea what was being loaded from the miz if you were previously using non-circular zones. Probably garbage.

[DanAlbert]

This is a pydcs behavior change. Even quad zones have radii in the miz, but after https://github.com/pydcs/dcs/pull/243 that property is no longer exposed in the generic zone type, only in the circular zone type:

[23] = 
{
    ["radius"] = 318.48057177765,
    ["zoneId"] = 807,
    ["color"] = 
    {
        [1] = 1,
        [2] = 1,
        [3] = 1,
        [4] = 0.15,
    }, -- end of ["color"]
    ["properties"] = 
    {
        [1] = 
        {
            ["key"] = "ROLE",
            ["value"] = "",
        }, -- end of [1]
        [2] = 
        {
            ["key"] = "VALUE",
            ["value"] = "",
        }, -- end of [2]
        [3] = 
        {
            ["key"] = "OBJECT ID",
            ["value"] = "82150981",
        }, -- end of [3]
        [4] = 
        {
            ["key"] = "NAME",
            ["value"] = "asad_building",
        }, -- end of [4]
    }, -- end of ["properties"]
    ["hidden"] = false,
    ["y"] = 27546.56640625,
    ["x"] = -167861.046875,
    ["name"] = "Red Command Center",
    ["type"] = 2,
    ["verticies"] = 
    {
        [1] = 
        {
            ["y"] = 27319.010092016,
            ["x"] = -167638.22857297,
        }, -- end of [1]
        [2] = 
        {
            ["y"] = 27837.344868086,
            ["x"] = -167731.13244933,
        }, -- end of [2]
        [3] = 
        {
            ["y"] = 27774.122720484,
            ["x"] = -168083.86517703,
        }, -- end of [3]
        [4] = 
        {
            ["y"] = 27255.787944414,
            ["x"] = -167990.96130067,
        }, -- end of [4]
    }, -- end of ["verticies"]
}, -- end of [23]

I don't know what the hell that means though. It might be a nonsense value, maybe it's the radius of a circumscribed or inscribed circle, or maybe it's some average width.

Since we have never actually handled these quad zones in Liberation, what you see in the miz when making these zones for a campaign is at best a lie that approximates the truth. For or now I think these are all latent campaign bugs, since they've never worked according to the designers intent.

Fixing pydcs will restore the earlier behavior, but I'm not sure if that's actually a good thing since it's misleading to the designer. Actually supporting quad zones would do what the designer intended, but it would also be a behavior change. Not saying we shouldn't do that, just that it is a new feature and will be prioritized as such.

[Raffson]

Quad-point triggers still have a radius attribute when you open up a mission file, which is why it used to work before pydcs' update. So even if you were using quad-point triggers before, they were actually treated as circular zone instead.

The change in pydcs was most certainly not inadvertent. Whoever wrote the changes probably didn't know what implications it had for Liberation. At the time I knew immediately this was going to be a problem, for which I tried to start a discussion in #2347.

Either way, after work I'm starting on a solution to solve this problem. The idea is to deduct 4 first order functions from the vertices of the quad-point trigger zone, and compare the function results to the given point to test. It's a pretty straight forward solution until you reach the edge cases, but I'm confident it'll point itself out 👍

[Raffson]

This is a pydcs behavior change. Even quad zones have radii in the miz, but after https://github.com/pydcs/dcs/pull/243 that property is no longer exposed in the generic zone type, only in the circular zone type:

Seems like my app hadn't refreshed when writing my last reply, but that's exactly the problem.

I don't know what the hell that means though. It might be a nonsense value, maybe it's the radius of a circumscribed or inscribed circle, or maybe it's some average width.

Having messed with the ME, I think it's the radius of the circumscribed circle.

[Starfire13]

Ah, that explains why it appeared to work fine when I tested it.

[DanAlbert]

I've updated the OP with a list of campaigns that we know have this bug. There may be others, those are just the three I've seen reported.

@Khopa @Starfire13, assigning the two of you since they're your campaigns. Those non-circular zones need to be replaced with circular zones. I can easily suppress this error in Liberation, but that won't do anyone any favors. Those zones have never been working the way you designed them. I've forked https://github.com/dcs-liberation/dcs_liberation/issues/2473 to cover supporting quad zones in the future, so if someone chooses to pick that up for 6, you won't need to fix anything (I have no intention of doing so myself).

[Starfire13]

Vegas Nerve is also impacted (as will Grabthar's Hammer when that is complete). I setup the map object strike targets on those campaigns to use quad triggers (since that's now the default in the ME), and quite a number of them won't work well if converted to circular triggers due to proximity (we'd end up with the same false positive/negative issue). I think I'll leave them as is for now and if the issue doesn't get fixed by 6.0 release, we can temporarily remove the campaigns for that release. They can go back in for 7.x when the fix is implemented.

[DanAlbert]

I setup the map object strike targets on those campaigns to use quad triggers (since that's now the default in the ME), and quite a number of them won't work well if converted to circular triggers due to proximity (we'd end up with the same false positive/negative issue).

They've always been circles in reality. That's why I don't want to revert to the original behavior: it clearly was misleading people into thinking that their quad zones were actually being obeyed. They never have been.

They can go back in for 7.x when the fix is implemented.

That isn't planned.

[Starfire13]

Yes, I understand that they weren't working as expected. My point is that they still wouldn't be working right even if I convert them to circles because for rectangular or odd-shaped buildings, you're going to end up with larger circles that would overlap other nearby trigger zones. I could remove the map object strike targets and go back to using the randomly generated strike targets, though that feels like a step backwards in terms of campaign design.

[DanAlbert]

Can't you just make a smaller circle?

[DanAlbert]

Reading the docs, I don't understand how you ended up with quad zones in the first place, unless the ME behavior changed.

[Starfire13]

The mission editor now intelligently creates quad trigger zones on buildings with four sides in order to fit the dimensions of the buildings exactly. Quad trigger zones are now the default in such cases. When it's a round building such as a fuel storage tank, it will automatically use a circle.

To clarify, it's not the large trigger zone for the entire strike target group which is the problem (I just use circles for that). It's the trigger zones for individual objects (typically buildings) that make up that strike target.

[DanAlbert]

Aha! I didn't know that behavior had changed (I never use this feature myself, because it seems to be endless maintenance pain for designers, and I don't want to sign myself up for that extra work 🙂).

From what I could figure out briefly looking through the implementation last night, the only thing that matters is the point that DCS communicates to us as the center of the zone. Quad zones likely do not have centers in the miz, and if they are, they may not be reliable, so we're still stuck on "quad zones can't be used reliably until this feature is reworked". The docs are definitely wrong though, since they're what led you to this.

FWIW I think the best advice is probably to just not use this feature until someone wants to spend time on making it work with quad zones. Scenery objectives have been a pain for campaign designers in every release, which is why I still avoid them in my campaigns.

[Starfire13]

Now that the need to recreate the trigger zones after every map update has been gotten rid off, I've actually found them to be pretty maintenance free. That's why I switched the majority of the strike targets on my campaigns over to using map objects. I like that it adds to the feel that you're hitting an actual target, because you can name each building to identify what it is. So for example, a mining facility can have a water treatment tower, mineral processing, storage warehouse, hoist enclosure, maintenance depot, etc.

[DanAlbert]

Well, except now the maintenance cost of those being harder to make because the ME is creating zones that won't work, and you have to go back through and remake all the ones you've already made (since the ME defaulted to the kind that won't work).

[Starfire13]

True enough. Hence why I think I'll just leave them as is, in hopes of someone getting quad zones working for 7.0. We can always use the campaign miz templates from 5.2 for 6.0, since those don't have the quad triggers.