Add a zone with script?

[marcost]

I've searched and read, but can't find how to do this with DCS lua or MIST (even though similar questions were pointed in this direction).

I want to be able to create trigger zones with a script rather than ME. Why? Because I can then import them into other pre-existing missions using the same map.  

I will know what the x & y co-ordinates and radius need to be. I just need to know if it can be created within a script?

 

Pseudo-code:

CreateZone{
x = 1000
y = 2000
z = 0
radius = 3000
name = myZone}

Thanks

M

[Kanelbolle]

You can use MOOSE:

https://github.com/FlightControl-Master/MOOSE/blob/master/Moose Development/Moose/Core/Zone.lua

[Grimes]

There actually is an addZone function in the simulator scripting engine, however I've never been told the syntax for it, thus it remains undocumented. 

That said it doesn't really matter because with scripting the things you'd use it for can be done with simple math for the coordinates and radius anyway. 

[marcost]

Thanks both,

You put me on the right path, especially with the fact that only co-ordinates are required. I'm now a MIST user!

 

Regards,

M

[PravusJSB]

Here is how I add zone's using the SSE 'addZone' function, hope this helps;

local function add_zone(name, x, y, radius)
  if trigger.misc.getZone(name) then return trigger.misc.getZone(name) end
  return trigger.misc.addZone
  {
    ["name"] = name,
    ["y"] = y,
    ["x"] = x,
    ["radius"] = radius,
    ["properties"] =
    {
      [1] =
      {
        ["key"] = name,
        ["value"] = "",
      },
    },
    ["color"] = {0,0,0,1},
    ["hidden"] = false,
  }
end

local new_zone = add_zone(zone.name, zone_position.x, zone_position.z, zone.size)

 

Edited July 15, 2022 by PravusJSB

[marcost]

It does, thank you!

[OzDeaDMeaT]

On 7/16/2022 at 12:11 AM, PravusJSB said:

Here is how I add zone's using the SSE 'addZone' function, hope this helps;

local function add_zone(name, x, y, radius)
  if trigger.misc.getZone(name) then return trigger.misc.getZone(name) end
  return trigger.misc.addZone
  {
    ["name"] = name,
    ["y"] = y,
    ["x"] = x,
    ["radius"] = radius,
    ["properties"] =
    {
      [1] =
      {
        ["key"] = name,
        ["value"] = "",
      },
    },
    ["color"] = {0,0,0,1},
    ["hidden"] = false,
  }
end

local new_zone = add_zone(zone.name, zone_position.x, zone_position.z, zone.size)

 

 

Awesome function mate. Is there a removeZone as well?

Also, what is "SSE"?

Edited September 20, 2023 by OzDeaDMeaT

[OzDeaDMeaT]

bump

[TEMPEST.114]

3 hours ago, OzDeaDMeaT said:

bump

There's no removeZone.

I believe the SSE is Secret Scripting Environment/Expression... either way it's an undocumented function (there are a couple of them). 

Hint (Dump _G and take a gander)

Edited June 5, 2024 by TEMPEST.114

[OzDeaDMeaT]

@TEMPEST.114, who is the best person to talk to about these undocumented commands? And how do we start some comms between ED and us on getting them documented. I know we have Grimes and the team over at Hoggit maintaining that awesome resource, would love to help them grip up some of these newer commands.

[TEMPEST.114]

1 hour ago, OzDeaDMeaT said:

@TEMPEST.114, who is the best person to talk to about these undocumented commands? And how do we start some comms between ED and us on getting them documented. I know we have Grimes and the team over at Hoggit maintaining that awesome resource, would love to help them grip up some of these newer commands.

You don't.

Like I said, they're hidden and unexposed at the whims of ED. And Grimes knows about them and has never added them to the hoggit documentation for reasons I don't know, but there is no process or way to get ED to officially make an effort; they don't care very much about this stuff and they have priorities that are, in their opinion, much, much higher. 

If you want to find them (and I can only think of two or three off the top of my head that aren't 'documented' anywhere) then you are going to need to go looking for them yourself and if you're able to put the time and effort in, you can reverse engineer how the params are specified and the outcomes are testable and repeatable then you can use them, but they can vanish in a patch and break your scripts / missions / campaigns at any time. If you look at the 'wish' list or 'bugs' for the scripting engine things that we DESPERATELY need have been asked for and tracked for over a DECADE and they still won't address them or fix them.

The line ED have said in comments and messages is that most of the users of DCS are single players. The small percentage that do multiplayer do the big servers to just dogfight or bomb it to hell and a TINY portion of those create missions or even dive into campaign creation and scripting.

They have their priorities and the M.E. and Scripting Engine (S.E.) are not in that list.

Like I hinted above, if you want to compare what is on 'hoggitworld' (hint: it's not complete or fully accurate or up to date) with what is actually available with each patch of DCS, then you're going to have to dump the _G table so you can see all the C functions available - one of which is 'addZone' and you'll notice there is no 'removeZone' - so hence you can't do it. 

Even Grimes has said in posts and comments that he regularly dumps G so he can see what's been added/removed/changed.

The DCS Scripting Engine API (and ME) is pretty crap. It was never really 'designed' and the best it was ever 'officially' communicated was here: https://www.digitalcombatsimulator.com/en/support/faq/scripting_engine/  

If you look into the history it was born out of a need for debugging purposes and was provided 'as is' to only the most hardcore mission creators and put out on the 'YMMV' principle. No deep or thorough documentation, no real examples; you had to already be a programmer or software engineer to even begin to reverse engineer it to make use of it; the documentation on hoggit is not an ED thing and done by the community for the community; but it's not up to date and it's not completely accurate. It's just better than absolutely nothing. The 'architecture' if you can call it that is laughable, disparate systems that can't but should communicate, back end objects having been deleted before the S.E. gets a callback with an id of that object that will cause a crash if you try and inspect/use it etc etc etc.

So if you want to do these more complex things that you seem to be wanting to do, then you're just going to have to roll up your sleeves like the rest of us, get very familiar with lua tables and even metatables, start pulling out data structures from the .miz and looking in _G and even the mission editor lua files in the core game folders and start working it all out for yourself. 

It's what everyone before you has done. 

There is no real incentive for someone to volunteer a huge amount of time and effort to create in depth tutorials and  documentation for ED because they don't appear to value that (having never tried themselves) and the M.E. and scripting environment are woefully ignored in patches and updates. Not only that but most go out of date or aren't kept up with and most of the DCS community seem to be quite toxic and anti-intellectual; they want the results and rewards, but they don't want to go to the effort of learning and contributing (look at the fools arguing for AI and ChatGPT to do scripting for them, rather than use their brains and make an effort) but they're rather tear down those actively trying to highlight the problems, offer solutions and contribute with bug reports and scripting advice. There is a lot of gaslighting and mansplaining in this tiny niche group of scripters and mission creators. Lots of big egos writing cheques they can't cash. 

Ultimately, unless ED do a 180 and actually focus on doing this and the M.E. properly, it is what it is; if you can make it do something cool, great, but it could just as easily break with each patch or features you rely on could disappear forever and there is nothing you can do about it. 

If you get a buzz from the intellectual side of doing this crap then I'd say go for it; if you're just doing it to make a mission to play and the playing/flying/learning aircraft or flying with friends is more important, then focus on that and leave the scripting alone. 

Edited June 6, 2024 by TEMPEST.114

[TEMPEST.114]

And another thing; I put a poll out for the people who come into the M.E. forums about using mods for aircraft and objects that ED have no interest in adding into DCS yet open up HUGE amounts of narrative and mission types that DCS just can't do. 

Virtually everyone poo-pooed it; saying they hate mods, won't use OvGME, are unwilling to make their players install mods as they see it as a hurdle most of their users won't cross to get (or even see) the benefit and irrational worries about crashes. 

So even putting scripts into missions/campaigns is seen as a hurdle or problematic to a lot of the 'players' of DCS... you have to decide if it's even worth it.

[OzDeaDMeaT]

On 6/7/2024 at 3:00 AM, TEMPEST.114 said:

You don't.

Like I said, they're hidden and unexposed at the whims of ED. And Grimes knows about them and has never added them to the hoggit documentation for reasons I don't know, but there is no process or way to get ED to officially make an effort; they don't care very much about this stuff and they have priorities that are, in their opinion, much, much higher. 

If you want to find them (and I can only think of two or three off the top of my head that aren't 'documented' anywhere) then you are going to need to go looking for them yourself and if you're able to put the time and effort in, you can reverse engineer how the params are specified and the outcomes are testable and repeatable then you can use them, but they can vanish in a patch and break your scripts / missions / campaigns at any time. If you look at the 'wish' list or 'bugs' for the scripting engine things that we DESPERATELY need have been asked for and tracked for over a DECADE and they still won't address them or fix them.

The line ED have said in comments and messages is that most of the users of DCS are single players. The small percentage that do multiplayer do the big servers to just dogfight or bomb it to hell and a TINY portion of those create missions or even dive into campaign creation and scripting.

They have their priorities and the M.E. and Scripting Engine (S.E.) are not in that list.

Like I hinted above, if you want to compare what is on 'hoggitworld' (hint: it's not complete or fully accurate or up to date) with what is actually available with each patch of DCS, then you're going to have to dump the _G table so you can see all the C functions available - one of which is 'addZone' and you'll notice there is no 'removeZone' - so hence you can't do it. 

Even Grimes has said in posts and comments that he regularly dumps G so he can see what's been added/removed/changed.

The DCS Scripting Engine API (and ME) is pretty crap. It was never really 'designed' and the best it was ever 'officially' communicated was here: https://www.digitalcombatsimulator.com/en/support/faq/scripting_engine/  

If you look into the history it was born out of a need for debugging purposes and was provided 'as is' to only the most hardcore mission creators and put out on the 'YMMV' principle. No deep or thorough documentation, no real examples; you had to already be a programmer or software engineer to even begin to reverse engineer it to make use of it; the documentation on hoggit is not an ED thing and done by the community for the community; but it's not up to date and it's not completely accurate. It's just better than absolutely nothing. The 'architecture' if you can call it that is laughable, disparate systems that can't but should communicate, back end objects having been deleted before the S.E. gets a callback with an id of that object that will cause a crash if you try and inspect/use it etc etc etc.

So if you want to do these more complex things that you seem to be wanting to do, then you're just going to have to roll up your sleeves like the rest of us, get very familiar with lua tables and even metatables, start pulling out data structures from the .miz and looking in _G and even the mission editor lua files in the core game folders and start working it all out for yourself. 

It's what everyone before you has done. 

There is no real incentive for someone to volunteer a huge amount of time and effort to create in depth tutorials and  documentation for ED because they don't appear to value that (having never tried themselves) and the M.E. and scripting environment are woefully ignored in patches and updates. Not only that but most go out of date or aren't kept up with and most of the DCS community seem to be quite toxic and anti-intellectual; they want the results and rewards, but they don't want to go to the effort of learning and contributing (look at the fools arguing for AI and ChatGPT to do scripting for them, rather than use their brains and make an effort) but they're rather tear down those actively trying to highlight the problems, offer solutions and contribute with bug reports and scripting advice. There is a lot of gaslighting and mansplaining in this tiny niche group of scripters and mission creators. Lots of big egos writing cheques they can't cash. 

Ultimately, unless ED do a 180 and actually focus on doing this and the M.E. properly, it is what it is; if you can make it do something cool, great, but it could just as easily break with each patch or features you rely on could disappear forever and there is nothing you can do about it. 

If you get a buzz from the intellectual side of doing this crap then I'd say go for it; if you're just doing it to make a mission to play and the playing/flying/learning aircraft or flying with friends is more important, then focus on that and leave the scripting alone. 

 

Quite a bit to unpack there. I can tell there is a lot of personal pain that you have experienced by your response, or this is a copy and paste message you put into all questions related to trying to engage with ED about DCS API.

A quick history on my DCS API journey. I have taught myself LUA and the DCS API over the last year or so. I am moderately experienced as at this stage with the DCS API limitations and disappointing levels of company interaction and documentation. The question I was asking was more a hail Mary than me trying to troll anyone.

I am well versed at mission making and scripting in games with poorly described API's and scripting commands. I can also write my own code and am not looking for 'code hand outs', although I am grateful when / if it occurs as it helps me narrow down what I need to write for what I need. I tend to do my own research on elements of the API but often find myself going to Hoggit's Discord first and as a last resort I come here for answers. I try not to get too involved here because there seems to be more jaded DCS API users than any other demographic on this forum.

I do know about how things break between patches, the Event Handlers are an excellent example of constantly changing (note I didn't say evolving) code with zero documentation. As such, I do have my own levels of DCS jadedness and I am less than a year into my learning journey. I just try not to finger blast anyone asking what was an uninformed but genuine question.

On 6/7/2024 at 3:11 AM, TEMPEST.114 said:

And another thing; I put a poll out for the people who come into the M.E. forums about using mods for aircraft and objects that ED have no interest in adding into DCS yet open up HUGE amounts of narrative and mission types that DCS just can't do. 

Virtually everyone poo-pooed it; saying they hate mods, won't use OvGME, are unwilling to make their players install mods as they see it as a hurdle most of their users won't cross to get (or even see) the benefit and irrational worries about crashes. 

So even putting scripts into missions/campaigns is seen as a hurdle or problematic to a lot of the 'players' of DCS... you have to decide if it's even worth it.

I can understand why. If the game is so unstable, why the hell would you mod it and expect a better more stable result? That is a basic logic fail IMO.

[TEMPEST.114]

1 hour ago, OzDeaDMeaT said:

That is a basic logic fail IMO.

You like most completely missed the point and jumped to a fallacious conclusion. 
 

The mods I was talking about added npc/ai units - did nothing to affect change in DCs other than open more mission types; as such they never cause a crash or any instability; I’ve been running them for almost 4 years and had zero problems from them.

This fallacious closed mindedness is part of the problem. 

[OzDeaDMeaT]

21 hours ago, TEMPEST.114 said:

You like most completely missed the point and jumped to a fallacious conclusion. 
 

The mods I was talking about added npc/ai units - did nothing to affect change in DCs other than open more mission types; as such they never cause a crash or any instability; I’ve been running them for almost 4 years and had zero problems from them.

This fallacious closed mindedness is part of the problem. 

You didn't mention any mods specifically, but my statement is accurate for general mods, this isn't just a DCS related statement. It's not closed mindedness bro, its you communicating in incomplete thoughts that is causing the issue here. Anyway, I see little relevance to the forum thread topic so I am going to stop here. Good luck with your mods.