Mist "plugin" spawning/cloning/teleporting

Requires Mist 2.0: http://forums.eagle.ru/showpost.php?p=1740382&postcount=132

Attached are a set of functions or something similar that will eventually be implemented with Mist. However much of Mist is not quite adapted for use with dynamically spawned groups and Speed and I want to make the complete changes before releasing it. For instance the alive and dead units databases aren't updated for dynamically added groups quite yet. Additionally there is need for an easier script to dynamically add groups to missions. As a result we decided the best course of action was to release a separate script so that mission builders have access to at least some of the functions.

This lua file adds several functions and a new database. It also updates the mist.getRandPointInCircle() function to accept vec2 coordinates.

Added functions are the following:

sct.DBs.dynGroupsAdded

sct.respawnInZone()

sct.teleportInZone()

sct.cloneInZone()

sct.teleportToPoint()

sct.getGroupData()

sct.getCurrentGroupData()

sct.dynAdd()

mist.isTerrainValid()

mist.getRandPointInCircle() (updated)

v2

added sct.getPayload()

added sct.respawnGroup()

added sct.cloneGroup()

added sct.teleportGroup()

removed sct.getEditorRouteTask()

fixed issues with respawning/cloning/teleporting aircraft

updated all functions that can be used to spawn a group to return a mission editor formatted groupTable.

mist.getGroupRoute() updated to return more data and an optional "task" variable.

Feedback will be appreciated and could possibly change how the functions would be implemented into Mist.

sctv2.rar

thanks, will play around with the new function this evening....

Looks great, I am gonna test it soon. :thumbup:

Looks great and a simple example with sct.cloneInZone worked just fine. How do I get a handle on the new group, so I can deactivate it at will? Maybe the teleportToPoint function could return a handle, which is the chained through the cloneInZone to the caller?

looks good, hope to get a chance to work with it in the next few days

Looks great and a simple example with sct.cloneInZone worked just fine. How do I get a handle on the new group, so I can deactivate it at will? Maybe the teleportToPoint function could return a handle, which is the chained through the cloneInZone to the caller?

Good point - anything that creates a new group should return the group it creates.

Assuming you don't add other groups immediately it would be the last group added to the sct.DBs.dynAddedGroups DB.

I suppose the functions oughta return the index of the group once it gets added to the DB.

I suppose the functions oughta return the index of the group once it gets added to the DB.

Would be great.....

Awesome, thanks!

First thanks for all the work and hints here in the forum.:thumbup:

I am actually have no idea of LUA or programming languages at all, I just grab what I can get and try to understand, what is going on.

I understood the "sct.dynAdd" function adds units when called via script and generates the group and unit IDs automatically. This would be very useful for randomly generated opponents, which happen not to be the primary target, but just side effects, so I try to generate a Russian Infantry squad randomly inside the zone "LZ Tango" and used the following script:

local pos = trigger.misc.getZone('LZ Tango')
local ranpos = {}

ranpos.x = pos.point.x + math.random(pos.radius * -1, pos.radius)
ranpos.z = pos.point.z + math.random(pos.radius * -1, pos.radius)

local data = {

units = {
[1] = {
["x"] = ranpos.x,
["y"] = ranpos.z,
["type"] = "Soldier AK",
bearing = bearing,
}, -- end of unit 1

[2] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
bearing = bearing,
},

[3] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
bearing = bearing,
},

[4] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
bearing = bearing,
},

[5] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
bearing = bearing,
},

[6] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
bearing = bearing,
},

[7] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
bearing = bearing,
},

[8] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
bearing = bearing,
},

[9] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier RPG",
bearing = bearing,
},

[10] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier RPG",
bearing = bearing,
},

[11] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "SAM SA-18 Igla-S comm",
bearing = bearing,
},

[12] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "SAM SA-18 Igla-S MANPADS",
bearing = bearing,
}, -- end of unit 2

}, --end of units
} -- end of group table

sct.dynAdd (country.id.RUSSIA, Group.Category.GROUND, data)

In the guide it just states :

groupData = {

units = {

[1] = {

x = posX,

y = posy,

type = typeOfUnit,

bearing = bearing,

}, -- end of unit 1

[2] = { etc…

}, -- end of unit 2

}, --end of units

} -- end of group table

--]]

But in the another part of a script I got working the data table is arranged differently, so I orientated on that working one, but I cannot find our what to use for "bearing". Before I slowly work through the error messages I receive, I thought I drop in here, to see if I am steaming in the right direction at all?

I guess bearing is the heading of the unit, so any value from 0 to 359 should be fine.

In other scripts "heading" is used for that, so was confused. Should it also be in RAD?

I am working through the error messages with try and error, but the table "data" structure is something I am not sure if that is correct at all.

Doh, that entry should be heading not bearing. And yes, heading is in radians.

Thanks Grimes, got it working now:

local pos = trigger.misc.getZone('test')
local ranpos = {}

ranpos.x = pos.point.x + math.random(pos.radius * -1, pos.radius)
ranpos.z = pos.point.z + math.random(pos.radius * -1, pos.radius)

local data = {

units = {
[1] = {
["x"] = ranpos.x,
["y"] = ranpos.z,
["type"] = "Soldier AK",
["heading"] = 0,
}, -- end of unit 1

[2] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
["heading"] = 0,
},

[3] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
["heading"] = 0,
},

[4] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
["heading"] = 0,
},

[5] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
["heading"] = 0,
},

[6] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
["heading"] = 0,
},

[7] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
["heading"] = 0,
},

[8] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier AK",
["heading"] = 0,
},

[9] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier RPG",
["heading"] = 0,
},

[10] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "Soldier RPG",
["heading"] = 0,
},

[11] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "SA-18 Igla-S comm",
["heading"] = 0,
},

[12] = {
["x"] = ranpos.x + math.random(5,100),
["y"] = ranpos.z + math.random(5,100),
["type"] = "SA-18 Igla manpad",
["heading"] = 0,
}, -- end of unit 2

}, --end of units
} -- end of group table

sct.dynAdd ("RUSSIA", "vehicle", data)

One step forward I am facing the next wall... ;)

The ME built in Triggerfunctions to pop smoke or flares or even to attach a zone to unit, does not work for units I teleported, spawned or added via the sctv1 or MIST2 scripts, is that right?

I was happy to have the teleport function, because I thought I can then address the unit in the ME to pop smoke on teleported units (which I can´t for added units, because they are not in the ME) and attach moving zones to these units, but now I have to find a way around this.

Is there a way to kind of "update" the units coordinates in order to get the moving zones and pop smoke functions working on teleportet units?

Not sure. Although its not entirely surprising that the triggers associated with teleported groups would no longer work. Especially considering that there is no mission editor equivalent to coalition.addGroup(). That said all scripting options should still be available to pop smoke and analyze if a unit is "inside a zone." For instance you can get the coordinate of any of the units and use :

trigger.action.smoke(Vec3 point, enum trigger.smokeColor color)

Trying to get the respawninzone function to work, but keep getting error messages. I have Mist 2.0 and the SCT update loaded at mission start. I am trying to respawn a KC135 refueler if/when it goes down. I am providing a timed delay after the original group "KC135" has been deactivated/killed. I have a respawn zone in place named "Kc135Restart". Could someone please show me the correct syntax for that group and zone for the respawninzone function?

Thank you

One step forward I am facing the next wall... ;)

 

The ME built in Triggerfunctions to pop smoke or flares or even to attach a zone to unit, does not work for units I teleported, spawned or added via the sctv1 or MIST2 scripts, is that right?

 

I was happy to have the teleport function, because I thought I can then address the unit in the ME to pop smoke on teleported units (which I can´t for added units, because they are not in the ME) and attach moving zones to these units, but now I have to find a way around this.

 

Is there a way to kind of "update" the units coordinates in order to get the moving zones and pop smoke functions working on teleportet units?

I've been testing this the past few days and it appears that not only is a moving zone "lost" when the unit it is attached to "respawns" to replace the same-named unit created in the ME, but a moving zone attached to a "fixed" (non-respawning unit) will not detect a unit that was respawned.

I also noticed that some conditions attached to a unit in the ME, such as "units pitch", "units speed", "units vertical speed in limits", etc. won't work when the object unit is "respawned".

Much of that we can indeed get around via scripting, though.

but a moving zone attached to a "fixed" (non-respawning unit) will not detect a unit that was respawned.

This sounds like a bug in DCS itself - it appears that groups created with addGroup are not added to whatever internal list DCS checks when testing zones. Hope they can fix this, as it would be quite a PITA if we had to treat spawned and non-spawned units so differently. If anyone has time, I'm sure ED would appreciate a simple test case.

a moving zone "lost" when the unit it is attached to "respawns" to replace the same-named unit created in the ME,

Not sure if this is a bug or just an unfortunate side-effect. Re-spawned/teleported groups aren't really the same group that they replace, they just use the same name, so it makes sense that moving zones would lose their association with the new group.

Updated the file. I added some new functions and made some fixess.

There is now a generic sct.respawn/teleport/clone function that will do the respective action from the groups initial position. If the group has a default task, there is an optional variable to give that task to the group or not. If you don't move ground units when you clone them they will stack!

Also added a sct.getPayload() function. This is mainly for aircraft as it seems you can spawn AI aircraft in the air without fuel really easily.

Removed sct.getEditorRouteTask() and replaced it with a slightly upgraded version of mist.getGroupRoute()

Fixed bugs related to spawning aircraft and helicopters.

I also adjusted it so that all spawning related functions will return a mission editor formatted group table. Its not the scripting engine group class, but you can easily get that by the following:

local test = sct.cloneGroup('groupName')

local newGroup = Group.getByName(test)

Download is updated in the first post.

but a moving zone attached to a "fixed" (non-respawning unit) will not detect a unit that was respawned.

This sounds like a bug in DCS itself - it appears that groups created with addGroup are not added to whatever internal list DCS checks when testing zones. Hope they can fix this, as it would be quite a PITA if we had to treat spawned and non-spawned units so differently. If anyone has time, I'm sure ED would appreciate a simple test case.

I set up a test case and I don't think it's a bug, just an unfortunate side-effect of how names are used by DCSW. When you 'respawn' you are actually deleting the original group then creating an identical one in it's place (or in a new place). Even though the name of the group and units are the same, they aren't really the same unit to DCSW. So the moving trigger does not recognize the unit that enters the zone as the unit it should respond to with 'Unit inside Moving Zone'.

Maybe grimes can recommend a way to make all triggers that where looking for the old unit named UnitA now look for the new unit named UnitA. I did not see anything in the scripting docs that appeared to give a list of triggers, but I may be missing it.

If I recall all of the mission editor stuff is actually group/unit Id based not name based, although the mission editor makes it easy on you by providing the group/unit name. However as it stands triggers don't really react to dynamically spawned units. Furthermore I'm not even sure if waypoint actions associated with a dynamically spawned group would work. This is the first patch with dynamically spawned groups, so I'd suspect things will be improved in the future.

The scripting engine does "see" dynamically spawned groups and many of the triggers are somewhat easily created by scripting via the "expression" condition. As a result it is very much possible to create scripts to deal with dynamically spawned groups. For example "unit inside moving zone" could look like this:

local unitPos = Unit.getByName('insertUnitNameHere'):getPosition():p
local zone = trigger.misc.getZone('insertTheZoneNameHere')

if math.sqrt(((unitPos.x - zone.point.x)^2) + ((unitPos.z - zone.point.z)^2)) < zone.radius then
return true
end

I was impressed how easy it was to implement this library to respawn groups where I wanted and when. Great work, thanks.

If you are still collecting suggestions:

sct.teleportToPoint takes a groupName as an argument. This is a great convenience, and generally what the user will want.

However, I have been playing with randomizing the groups a bit (applying casualties) and would like to optionally pass my own table in the format that sct.getGroupData returns, rather than a group name.

thanks again for your work.