Jump to content

addGroup() Do you still need to start off the table as "Mission" or something else to spawn an entirely new group?


Recommended Posts

Posted

Its just a table with entries on the first level of it being units, task, route, groupId, name, etc. 

The group table is just like the examples linked on that page; https://wiki.hoggitworld.com/view/DCS_exam_group_ground

 

I don't know where you are getting the idea of "mission" being required. Perhaps maybe the mission task that you can assign a group, but that is just like any other task where it is {id = "taskName", params = {actualTaskData}}

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Posted (edited)
9 hours ago, Grimes said:

just a table with entries on the first level of it being units, task, route, groupId, name, etc. 

The group table is just like the examples linked on that page; https://wiki.hoggitworld.com/view/DCS_exam_group_ground

First off, I recall reading somewhere that you can’t give a newly spawned group a task/route, until some undefined period after you spawn it for the dcs backend to be happy.

those ‘examples’ also include a lot of data that is *not required* as per the documentation page and even some things, you yourself told me to leave out like group and unit id’s which you said the engine will fill in for me, so as far as I understand it the documentation isn’t showing accurately the minimum or required data needed to spawn a group with unit(s) and your reply here, whilst I can’t find where I read that right now, contradicts the ‘you can’t assign route/tasks etc’ until some period after it spawns. 
 

Clarity and perhaps actual examples are all I’m asking for; surely that’s not too much to ask?

Edited by Elphaba
Posted

Examples were copy/pasted from a mission file. Depending on the group type and even the units within there are going to be some extra entries or non-standard entries. Payloads on weapons with fusing will have an entry for that while weapons that lack it won't. There are often entries that only the mission editor itself uses. Any route tasking with ["auto"] = true just means the editor added it automatically. However they don't really matter because unless the game is looking for a value it will just ignore anything extra in there. 

IIRC the items on the page that are listed as required are required. Anything in optional or not listed should be considered optional. Stuff like group and unit ids can be left out, but it is personal preference. I view it as a nice shortcut when I don't care what the Id is. If a required entry is missing then I'll add it because that is clearly important. Optional values is more of a "it depends". Yeah I need to add some of the group level options added in the last year or so. Additional properties for a Land Rover though isn't really important. 

As for route tasking you can spawn the AI with the route just fine, I personally prefer to do it that way for aircraft but not for ground/ships. The problems people had, and I'm not sure if it still causes issues or not, is when you spawn a group and assign a task in the same sequence like below. I never saw a reason why one would do that with a mission task because you could just add the mission table to the someGroup table. But hey, thats just me. IIRC you just need to wait a fraction of a second to assign the task anyway, but its still a hassle to schedule a function rather than just running it like that. 

local someGroup = {imagineAGroupTable}
coalition.addGroup(1, 1, someGroup)
Group.getByName(someGroup.name):getController():pushTask(whatever)
  • Thanks 1

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Posted
2 hours ago, Grimes said:

Examples were copy/pasted from a mission file. Depending on the group type and even the units within there are going to be some extra entries or non-standard entries. Payloads on weapons with fusing will have an entry for that while weapons that lack it won't. There are often entries that only the mission editor itself uses. Any route tasking with ["auto"] = true just means the editor added it automatically. However they don't really matter because unless the game is looking for a value it will just ignore anything extra in there. 

IIRC the items on the page that are listed as required are required. Anything in optional or not listed should be considered optional. Stuff like group and unit ids can be left out, but it is personal preference. I view it as a nice shortcut when I don't care what the Id is. If a required entry is missing then I'll add it because that is clearly important. Optional values is more of a "it depends". Yeah I need to add some of the group level options added in the last year or so. Additional properties for a Land Rover though isn't really important. 

As for route tasking you can spawn the AI with the route just fine, I personally prefer to do it that way for aircraft but not for ground/ships. The problems people had, and I'm not sure if it still causes issues or not, is when you spawn a group and assign a task in the same sequence like below. I never saw a reason why one would do that with a mission task because you could just add the mission table to the someGroup table. But hey, thats just me. IIRC you just need to wait a fraction of a second to assign the task anyway, but its still a hassle to schedule a function rather than just running it like that. 

local someGroup = {imagineAGroupTable}
coalition.addGroup(1, 1, someGroup)
Group.getByName(someGroup.name):getController():pushTask(whatever)

Ah ha! You said exactly what I was asking... 

This:

Quote

The problems people had, and I'm not sure if it still causes issues or not, is when you spawn a group and assign a task in the same sequence like below. I never saw a reason why one would do that with a mission task because you could just add the mission table to the someGroup table.

 

The 'mission' table, which I've worked out how to do from other questions / examples and can now give tasks to ground, naval and aircraft units by PUSHING a new MISSION task. But I couldn't see from the exampls 'ripped' from the mission file how the 'mission' table fit in with the 'addGroup' table. 

So my only thought was to do as you just said I shouldn't probably do - which is spawn the group with only the 'required' data, and then immediately 'PUSH' a new 'MISSION' task. 

But if I can add the contents of the 'mission' table right into the 'addGroup' table then I'll do that instead. 

Thanks.

Posted

Yeah so look at the example of a mission task. https://wiki.hoggitworld.com/view/DCS_task_mission Then look at the route entry for an aircraft group https://wiki.hoggitworld.com/view/DCS_exam_group_plane

If you wrote a mission task that you wanted to have an AI group start with, then all you'd need to do is....

local mission = {someMissionTask}
local newGroup = {someGroupTable}
newGroup.route = mission.params.route
coalition.addGroup(1, 1, newGroup)

Same thing applies to individual tasks, but is a bit more convoluted when added as part of a mission. 

["task"] = 
{
  ["id"] = "ComboTask",
  ["params"] = 
  {
    ["tasks"] = 
    {
      [1] = 
      {
        ["enabled"] = true,
        ["auto"] = true,
        ["id"] = "WrappedAction",
        ["number"] = 1,
        ["params"] = 
        {
          ["action"] = 
          {
            ["id"] = "EPLRS",
            ["params"] = 
            {
              ["value"] = true,
              ["groupId"] = 1,
            }, -- end of ["params"]
          }, -- end of ["action"]
        }, -- end of ["params"]
      }, -- end of [1]
    }, -- end of ["tasks"]
  }, -- end of ["params"]
}, -- end of ["task"]

Whereas if you decided to set a command anytime after it spawns then it is a simple call that isn't buried in the task.params.tasks[index].params.action table of a given mission waypoint. 

{ 
  id = 'EPLRS', 
  params = { 
    value = boolean, 
    groupId = number, 
  } 
}

 

  • Thanks 1

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...