Is it possible to tell if an aircraft carrier on the map has slots reserved for human players from scripting?

[TEMPEST.114]

Basically, I need to know if there is a carrier on the map where players from any coalition can/will spawn from. 

I don't care about ones that only spawn AI, only CLIENT & PLAYER slots.

 

[Grimes]

Gotta parse env.mission and see if linkUnit is present on a take-off waypoint for aircraft. IIRC that is only present when assigned to takeoff from a ship. 

[TEMPEST.114]

12 hours ago, Grimes said:

Gotta parse env.mission and see if linkUnit is present on a take-off waypoint for aircraft. IIRC that is only present when assigned to takeoff from a ship. 

Oh. I'm not setting that manually in the mission editor (there is usually a drop box for link unit on the inspector on the right but this doesn't appear for an aircraft) but is this done automatically when you drop an aircraft near a carrier and select take off from parking hot / runway?

12 hours ago, Grimes said:

Gotta parse env.mission and see if linkUnit is present on a take-off waypoint for aircraft. IIRC that is only present when assigned to takeoff from a ship. 

Also, how do I get access to that from inside the scripting language and not by extracting the .miz file and opening it in notepad++?

 

Edited November 14, 2022 by Elphaba

[Grimes]

I swear I've answered this before to one of your questions in the past, but env.mission is the mission file generated by the mission editor. The lua files within the .miz are loaded into the respective env.X in the scripting environment. Those files are basically just a big lua table anyway, thus if you know the formatting or want to iterate in pairs to look for stuff you can. Its how MIST, MOOSE, and others build unit databases or use other information from the mission file that aren't directly accessible. For instance trigger.misc.getUserZone doesn't return any properties you may have assigned nor does it give the vertices of quad zones. That data is in env.mission. 

Just grabbed a random mission and this table entry is within env.mission.coalition.blue.country[7]   -- USA was at index 7

The carrier is unit Id 1 so the linkUnit and helipadId are set to 1 to correspond with that unit id. 

                    ["plane"] = 
                    {
                        ["group"] = 
                        {
                            [1] = 
                            {
                                ["modulation"] = 0,
                                ["tasks"] = 
                                {
                                }, -- end of ["tasks"]
                                ["radioSet"] = false,
                                ["task"] = "CAP",
                                ["uncontrolled"] = false,
                                ["route"] = 
                                {
                                    ["points"] = 
                                    {
                                        [1] = 
                                        {
                                            ["alt"] = 0,
                                            ["action"] = "From Parking Area Hot",
                                            ["alt_type"] = "BARO",
                                            ["linkUnit"] = 1,
                                            ["properties"] = 
                                            {
                                                ["addopt"] = 
                                                {
                                                }, -- end of ["addopt"]
                                            }, -- end of ["properties"]
                                            ["helipadId"] = 1,
                                            ["speed"] = 138.88888888889,
                                            ["task"] = 

I cutoff a whole lot of extra stuff because it wasn't relevant. Anyway there is a lot of value in viewing the contents of the miz file simply because some answer for how something works is likely within. Need to figure out a task? Make a mission with that task and see how it is formatted. Likewise parsing the file during the mission has its own uses as stated above. 

[TEMPEST.114]

4 hours ago, Grimes said:

I swear I've answered this before to one of your questions in the past, but env.mission is the mission file generated by the mission editor

You probably have, but I was asking about the specific command, because this page

https://wiki.hoggitworld.com/view/DCS_singleton_env

…doesn’t show anything about grabbing this huge Lua table via scripting at runtime and nor does it show how to parse it to find the specific thing you want.

it’s EXAMPLES we all need. It seems like the few who have worked out how to do this through sheer blood and sweat just want everyone else to work it out for themselves too because they had too.

That’s not the best way to foster growth in a fringe community.

And before someone says ‘look at moose/mist’ there is so much ‘extra’ stuff in there e.g. databases and their own ‘way’ of doing stuff, it’s hard for a novice to work out what’s actually required from what extra they’re doing. 

Edited November 15, 2022 by Elphaba

[Grimes]

1 hour ago, Elphaba said:

t’s EXAMPLES we all need. It seems like the few who have worked out how to do this through sheer blood and sweat just want everyone else to work it out for themselves too because they had too.

That’s not the best way to foster growth in a fringe community.

And before someone says ‘look at moose/mist’ there is so much ‘extra’ stuff in there e.g. databases and their own ‘way’ of doing stuff, it’s hard for a novice to work out what’s actually required from what extra they’re doing. 

There isn't any intentional gatekeeping going on with it. The single biggest contributing factor is that it isn't ED that created and maintains the "go to" documentation for the scripting engine. The hoggit wiki hosting the scripting documentation came about due to ED shutting down their own wiki. Then however many years ago with me being annoyed with the original documentation went through and tried to remodel it off of the Arma wiki design. To this day things are missing or examples are needed. Its one thing to go through and create basic documentation that is usable, its another to know what needs more detail the most. Over the last few years it usually results in me making a mental note to try and add detail to any given page whenever it gets brought up. The other part of it is being basically just me doing the wiki edits and I'm spread thin throughout every little aspect of DCS that I volunteering spend my time. The original documentation, which I've kept for the sake of posterity isn't much better. https://wiki.hoggitworld.com/view/DCS_Scripting_orig_Part_1#env

 

While I agree that looking through code written by other people can be annoying simply due to differences in formatting, it should be easy enough to note patterns or to take an idea they are doing to experiment with it further in your own way. https://github.com/mrSkortch/MissionScriptingTools/blob/master/mist.lua#L103

 

 

[Dangerzone]

1 hour ago, Elphaba said:

It seems like the few who have worked out how to do this through sheer blood and sweat just want everyone else to work it out for themselves too because they had too.

It may seem like that, but I think it's highly unlikely that is what's happening. Just that after we've gone to the effort of figuring it all out and applying it ourselves - the last thing we're going to do is go back and start writing a whole bunch of documentation on it when there's more work to be done in front of us. 

I think the community is very generous generally speaking. MIST/MOOSE made for us plus a number of other resources available, as well as any community mission having all the source code directly available to view as well, plus many generous people that give of their time to help people on this forum (as Grimes has just done for you). 

[TEMPEST.114]

2 hours ago, Grimes said:

There isn't any intentional gatekeeping going on with it. The single biggest contributing factor is that it isn't ED that created and maintains the "go to" documentation for the scripting engine. The hoggit wiki hosting the scripting documentation came about due to ED shutting down their own wiki. Then however many years ago with me being annoyed with the original documentation went through and tried to remodel it off of the Arma wiki design. To this day things are missing or examples are needed. Its one thing to go through and create basic documentation that is usable, its another to know what needs more detail the most. Over the last few years it usually results in me making a mental note to try and add detail to any given page whenever it gets brought up. The other part of it is being basically just me doing the wiki edits and I'm spread thin throughout every little aspect of DCS that I volunteering spend my time. The original documentation, which I've kept for the sake of posterity isn't much better. https://wiki.hoggitworld.com/view/DCS_Scripting_orig_Part_1#env

 

While I agree that looking through code written by other people can be annoying simply due to differences in formatting, it should be easy enough to note patterns or to take an idea they are doing to experiment with it further in your own way. https://github.com/mrSkortch/MissionScriptingTools/blob/master/mist.lua#L103

 

 

 

2 hours ago, Dangerzone said:

It may seem like that, but I think it's highly unlikely that is what's happening. Just that after we've gone to the effort of figuring it all out and applying it ourselves - the last thing we're going to do is go back and start writing a whole bunch of documentation on it when there's more work to be done in front of us. 

I think the community is very generous generally speaking. MIST/MOOSE made for us plus a number of other resources available, as well as any community mission having all the source code directly available to view as well, plus many generous people that give of their time to help people on this forum (as Grimes has just done for you). 

Ok, then, explicitly, how is it that people say ‘get the mission table from “env.mission”’,and yet there is no function or parameters listed on the env singleton documentation page for that property/function?

If it’s a secret or hidden function, and no documentation exists, how are we supposed to know about it?

I created a post earlier about a new singleton I just discovered last night ‘DCS Server’ that DOES have a ‘getMission’ function, but a) no documentation and b) its a server thing - so I asked if it has to be run from a dedicated server to get it or not… or if it’s something I need to do some configuration on in order to ‘get’ access to it. Because ‘env’ singleton doesn’t seem to have that function. 
 

I’m honestly not trying to be difficult here, but for the sake of clarity for me and anyone else who reads or finds this in a search, how explicitly do we get and parse that huge mission table from a non-moose/mist script?

[Grimes]

3 hours ago, Elphaba said:

Ok, then, explicitly, how is it that people say ‘get the mission table from “env.mission”’,and yet there is no function or parameters listed on the env singleton documentation page for that property/function?

If it’s a secret or hidden function, and no documentation exists, how are we supposed to know about it?

It isn't a function. Its just a table that exists. The way we find things that we didn't know existed in previous versions is by "writing the _G" table. Here is the relevant code from mist that you can copy or use at your leisure to get the file yourself. If you need some help understanding what _G is in lua then this page might help. http://underpop.online.fr/l/lua-gts-stolberg-de/en/tables.html

Short answer is that _G is everything that is accessible. It is a giant table containing functions and more tables. You will see all of the scripting functions and most of the constant values that you know and love from the documentation. As you may note from my attachment that mist is loaded and appears to be similar to entries like Airbase and Unit. In other words you can see the contents to the same extent. 

A note about the attachment, I did delete one giant entry that was over 8mb of data within the country table. Its basically a huge list of units available to every single country with a bunch of extra data.  At line 319 is where the env table can be found. You see the env.info and other functions. But env.mission and env.warehouses will be identical to their respective mission and warehouse files embedded within the .miz.

3 hours ago, Elphaba said:

I’m honestly not trying to be difficult here, but for the sake of clarity for me and anyone else who reads or finds this in a search, how explicitly do we get and parse that huge mission table from a non-moose/mist script?

for name, tblData in pairs(env.mission) -- this will print to the log all of the root entries found within a mission file embedded in a .miz
   env.info(name)
   if type(tblData) == 'table' then  -- if its a table then iterate it to print whats on the next level down. But really you should just start where-ever you are looking for data anyway.
      for L1N, L1D in pairs(tblData) do
         env.info(L1N)
      end
   end
end

 

2_8_0_32235.lua

[TEMPEST.114]

1 hour ago, Grimes said:

It isn't a function. Its just a table that exists. The way we find things that we didn't know existed in previous versions is by "writing the _G" table. Here is the relevant code from mist that you can copy or use at your leisure to get the file yourself. If you need some help understanding what _G is in lua then this page might help. http://underpop.online.fr/l/lua-gts-stolberg-de/en/tables.html

Short answer is that _G is everything that is accessible. It is a giant table containing functions and more tables. You will see all of the scripting functions and most of the constant values that you know and love from the documentation. As you may note from my attachment that mist is loaded and appears to be similar to entries like Airbase and Unit. In other words you can see the contents to the same extent. 

A note about the attachment, I did delete one giant entry that was over 8mb of data within the country table. Its basically a huge list of units available to every single country with a bunch of extra data.  At line 319 is where the env table can be found. You see the env.info and other functions. But env.mission and env.warehouses will be identical to their respective mission and warehouse files embedded within the .miz.

for name, tblData in pairs(env.mission) -- this will print to the log all of the root entries found within a mission file embedded in a .miz
   env.info(name)
   if type(tblData) == 'table' then  -- if its a table then iterate it to print whats on the next level down. But really you should just start where-ever you are looking for data anyway.
      for L1N, L1D in pairs(tblData) do
         env.info(L1N)
      end
   end
end

 

2_8_0_32235.lua 865.05 kB · 0 downloads

Thank you SO MUCH @Grimes  I didn’t realise ‘env.mission’ was a data structure, I thought it was a function. 

[TEMPEST.114]

@Grimes I'm following up on this. 

In your MIST examples, you mention about de-sanitising DCS to allow 'io' and 'lfs'.

Is it impossible to write to and read from the _G table without de-sanitising?

If it *is* possible, how does one do it?

[Grimes]

_G is always accessible, so you can read it just fine. io is needed to create and write to a given file. lfs isn't strictly required, its just really useful because lfs.writedir() returns the folder location of DCS in your saved games. 

Suppose you could always write given entries to the DCS.log, but there are plenty of use cases where that would be effectively useless. 

If you had a client side script that uses the gameGUI api then you have native access to io and lfs. Although I don't recall the differences of _G when checked from the server env compared to the mission env. 

[TEMPEST.114]

40 minutes ago, Grimes said:

_G is always accessible, so you can read it just fine. io is needed to create and write to a given file. lfs isn't strictly required, its just really useful because lfs.writedir() returns the folder location of DCS in your saved games. 

Suppose you could always write given entries to the DCS.log, but there are plenty of use cases where that would be effectively useless. 

If you had a client side script that uses the gameGUI api then you have native access to io and lfs. Although I don't recall the differences of _G when checked from the server env compared to the mission env. 

I'm still not sure I understand. You're still talking over my head.

I tried adding this:

_G["myNewData"] = someData

in messagesHistory.lua

and in myScript.lua I tried:

local retrievedData = _G["myNewData"]

but dcs.log gave an error on the line in messagesHistory.lua saying

2022-12-24 13:22:37.358 ERROR   LuaGUI (Main): [string "./Scripts/UI/messagesHistory.lua"]:156: attempt to index global '_G' (a nil value)
 

 

Edited December 25, 2022 by Elphaba

[Grimes]

It depends on the lua environment and what is intended to be accessible at a given point in time from what you are accessing it from. A lot of the lua files from mission editor and scripts folders get loaded when the game starts or at the very start of mission loading. More over it is meant to be separate and different from the mission scripting environment. Only a few script files from there get loaded into the mission env. Its why if you "dumped _G" from mission you won't see any code related to the UI scripts. Likewise if you tried to access _G from the server environment it would be different from the mission env.