Tutorial/advice on dcs scripting to handle position & orientation of objects?

[TEMPEST.114]

I’m trying to spawn a group to drive and park at an exact point an exact distance from another vehicle (group). To do this in get the position & orientation of the ‘target’ vehicle, so I add on the distance I want the ‘following’ vehicle to park at in relation to x & z and then I do this calculation:

follower.position.x = target.position.x + target.x.x * offset.x

follower.position.x = target.position.y + target.y.y * offset.y

follower.position.x = target.position.z + target.z.z * offset.z

but when follower ‘parks’ it’s never in the right or same space when the target’s heading changes. And if the target is heading west, the targets x.x is zero, which negates the offset.x value. 
 

any help please?

[cfrag]

1 hour ago, Elphaba said:

follower.position.x = target.position.x + target.x.x * offset.x

follower.position.x = target.position.y + target.y.y * offset.y

follower.position.x = target.position.z + target.z.z * offset.z

Perhaps it could help if you showed us the actual code. In your example above are a number of issues I don't understand, and of course I see no heading calculations involved. That, of course, and the fact that I'm not convinced that you can precisely control where a unit stops when you give orders to a group.

 

[TEMPEST.114]

Well perhaps more general then, given that ‘getPosition()’ returns a table of 4 vec3d’s the first, p is the orientation, the latter 3 are its translation/x,y,z in 3d game space,

how does one use that to orient and offset by fixed offset values, such that a waypoint 9s created that will stop a unit in the exact spot you want, in relation to the orientation of the first object?

And the reason I’m not showing any code is because I don’t have any code working.

[cfrag]

42 minutes ago, Elphaba said:

Well perhaps more general then, given that ‘getPosition()’ returns a table of 4 vec3d’s the first, p is the orientation, the latter 3 are its translation/x,y,z in 3d game space

Ah. This may be a mis-interpretation of what's written in the documentation.

getPosition() returns a vec 4 that contains the object's location in p, and the orientation of the object (it's forward, up, and right unit vectors) in x, y, and z.

stupid null

So getPosition's p is the same as what you would get with getPoint(). You can derive the object's heading from getPosition's unit x vector like so:

local pos = theUnit:getPosition() -- returns four vectors, p is location, x, y and z are unit vectors for orientation
-- we interpret x as "unit forward", therefore its x and z components to derive heading on map's (x,z) plane 
local heading = math.atan2(pos.x.z, pos.x.x) -- in rads, not degrees

Indeed, you can then use that to calculate the offsets.

Edited November 7, 2022 by cfrag

[TEMPEST.114]

38 minutes ago, cfrag said:

Ah. This may be a mis-interpretation of what's written in the documentation.

getPosition() returns a vec 4 that contains the object's location in p, and the orientation of the object (it's forward, up, and right unit vectors) in x, y, and z.

stupid null

So getPosition's p is the same as what you would get with getPoint(). You can derive the object's heading from getPosition's unit x vector like so:

local pos = theUnit:getPosition() -- returns four vectors, p is location, x, y and z are unit vectors for orientation
-- we interpret x as "unit forward", therefore its x and z components to derive heading on map's (x,z) plane 
local heading = math.atan2(pos.x.z, pos.x.x) -- in rads, not degrees

Indeed, you can then use that to calculate the offsets.

 

Thanks so much!

About p though. You said it’s the same as ‘getPoint’ right? That means a single point. Where does dcs consider to be ‘the point’ when it comes to a model? Is it the centre x,y,z of a model I.e. its centre of mass? Or is it like the top left corner of the model? Or the bottom left?

 

knowing that for each model will clue me in to working out the offsets required. 

[cfrag]

1 minute ago, Elphaba said:

Where does dcs consider to be ‘the point’ when it comes to a model? Is it the centre x,y,z of a model I.e. its centre of mass?

DCS uses a 3D engine that is structured like most others. All objects have an abstract local origin (local zero) where a 3D model is drawn around. So, move the origin, move where the object appears when the scene is rendered. For the 3D engine though, the object is wherever the object's origin is. The 3D engine has no idea about mass, or what is drawn at the object's origin, how it looks. It merely tells the rendering engine: hey, draw your 3D model relative to that point with that orientation - and the object renderer takes it from there.

That's a somewhat convoluted way to say: the 3D renderer decides how an object is drawn around the unit's point. For the 3D engine, that's immaterial, it only uses one point (origin) and three vectors (orientation) to represent the entire object.  Now, because of how models are designed in 3D modelling software, the model's origin also happens to be (or is very close to) the object's mass center, usually because many objects tend to be symmetrical. But where the artist places the origin is completely arbitrary, and can be consciously placed outside of its center: in many games, models have their origin placed at their lowest point, so moving on surfaces is made easier to the programmer. 

To me, I find it much easier to simply abstract. The point that I receive from getPoint() is where the object is, and to me it's infinitesimally small. I let the 3D engine worry about drawing the model around that point (since we have no easy way to get a 3D model's transformed boundaries, it's better not to dwell on this anyway). So: getPoint() = where the object is.

[TEMPEST.114]

5 hours ago, cfrag said:

DCS uses a 3D engine that is structured like most others. All objects have an abstract local origin (local zero) where a 3D model is drawn around. So, move the origin, move where the object appears when the scene is rendered. For the 3D engine though, the object is wherever the object's origin is. The 3D engine has no idea about mass, or what is drawn at the object's origin, how it looks. It merely tells the rendering engine: hey, draw your 3D model relative to that point with that orientation - and the object renderer takes it from there.

That's a somewhat convoluted way to say: the 3D renderer decides how an object is drawn around the unit's point. For the 3D engine, that's immaterial, it only uses one point (origin) and three vectors (orientation) to represent the entire object.  Now, because of how models are designed in 3D modelling software, the model's origin also happens to be (or is very close to) the object's mass center, usually because many objects tend to be symmetrical. But where the artist places the origin is completely arbitrary, and can be consciously placed outside of its center: in many games, models have their origin placed at their lowest point, so moving on surfaces is made easier to the programmer. 

To me, I find it much easier to simply abstract. The point that I receive from getPoint() is where the object is, and to me it's infinitesimally small. I let the 3D engine worry about drawing the model around that point (since we have no easy way to get a 3D model's transformed boundaries, it's better not to dwell on this anyway). So: getPoint() = where the object is.

Yeah I get all that but considering different models have different shapes, lengths and widths, knowing there the zero ref point is will determine what offsets I have to come up with when placing another object in direct relation to the first. So if it’s centre mass I.e. middle width, middle height, middle length then the offsets will be quite different if it’s zero on the front, bottom left…

 

so knowing where dcs keeps/wants/needs the zero ref point is very important to me. 

[cfrag]

40 minutes ago, Elphaba said:

so knowing where dcs keeps/wants/needs the zero ref point is very important to me. 

Agreed. Unfortunately, that information is not easily available. For simplicity I simply assume that most ground unit's y origin is close to the ground, while x,z center to its (x,z) outline. If you *really* need to know these, many units have their bounding "box" attribute inside their Desc (see here for the infantry AK). There you can see that this unit's bounding box goes from 0 to 1.8m in y (meaning its origin it at 0.9), while x and z bounds are somewhat symmetrically between -0.4 and 0.4, so their xz center is somewhere in the middle at (0,0).  

Edited November 7, 2022 by cfrag

[TEMPEST.114]

Is there a tutorial that explains SIMPLY the maths required to orientate one unit to be matched with another?

[cfrag]

15 hours ago, Elphaba said:

the maths required to orientate one unit to be matched with another

If you want a unit to spawn into a specific heading (match heading of unit A), use the 'heading' attribute with heading in rads. Important: If you are using a ME template to spawn the unit, make sure that if it has a psi attribute to set it to (0-heading), or DCS will screw you over. This is sadly documented nowhere.

If you are looking for a specific math like 'make unit A look at unit B', I'm sure we can quickly come up with the relevant formulas/algorithms, they are usually straight-forward geometric solutions. 

[TEMPEST.114]

@cfragPsi?

Edited November 10, 2022 by Elphaba

[TEMPEST.114]

Let's say we have a vehicle, 10m long, 4m wide. 

We know it's position on the map from Unit:getPoint()

It's 'position' in 3d space is Unit:getPosition where 

So if there was a part on this vehicle like a control panel or a door or something and you wanted an infantry unit to walk up to that point. You'd first have to work out, in the coordinates of the vehicle the x and z in metres of where that panel/door/controls are

Let's say it's 4m from the back and considering the vehicle is 4m wide the panel will be 2m on one side of the origin. From what I've seen in the modelviewer the origin is 'roughly' (depends on the model) in the centre of the model. So, with a little bit of trial and error let's say that the panel you want the soldier to walk up to is -1m backwards in the longitudinal axis and +2m on the lateral axis. 

Now, if the vehicle was always orientated so that the + on its longitudinal axis was the same as the maps +X axis, and + on its lateral axis was +Z then it would be simple, but that's not taking into account the ORIENTATION OF THE VEHICLE into account. 

That's where the other 3 vectors in the Unit:getPosition() come into play. 

My question, is how can I - after working out the offsets for the panel/controls/door or whatever from the model viewer, create a waypoint for a ground unit (infantry say) that will take them to that exact point, regardless of the orientation of the vehicle in question. 

      position.p.x = position.p.x + position.x.x * offset.x

      position.p.z = position.p.z + position.z.z * offset.z

Isn't really working, sometimes it's close, sometimes it's way off. Depending on the orientation of the vehicle in question. 

The offset.x and offset.z are floats in metres based upon the grid used in the model viewer. 

I'm using these like this:

      groupToSpawn.route.points[#points].x = vehiclePos.p.x

      groupToSpawn.route.points[#points].y = vehiclePos.p.z

Are the problems I'm seeing (the infantry going to completely the wrong place or never consistent depending on orientation or even the numbers not making sense in relation to the vehicle model) because we can't trust the AI Pathfinding to do exactly what I tell it to do i.e. go to a specific point exactly, or is it my maths? 

The maths above was kindly given to me by someone from the official discord, but I don't profess to really understand how it works. If someone could explain it such that I understand it maybe I can see where the flaw is. 

Or if it's just 'DCS' being 'DCS' then I'll give up trying to get this right and move on with my life. I've been at this 3 weeks already. 

Can someone please help? I'm at the limits of my understanding here and I don't know if I'm running up against DCS's 'DCSisms' or if I'm doing this wrong. 

[Grimes]

Don't know much about unit vectors, but there are two sure fire ways to do it. 

This is more or less copied from mist.vec.rotateVec2. You have a known offset, get the heading of the unit, and do some math. 

    local offset = {x = 0.5, z = 1} 
    local position = Unit.getByName( "Ground-1-1"):getPosition()
    local theta =  math.atan2(position.x.z, position.x.x)
    local newPoint = {}
    newPoint.x = offset.x*math.cos(theta) - offset.z*math.sin(theta) + position.p.x
    newPoint.y = offset.x*math.sin(theta) + offset.z*math.cos(theta) + position.p.z

The other way is similar, but would be done via storing the relative heading and distance from object center and projecting a point. 

    local offset = {t = math.rad(70), d = 1.5}    -- unit oriented north, offset position is 70 degrees and 1.5 meters
    local position = Unit.getByName( "Ground-1-1"):getPosition()
    local theta =  math.atan2(position.x.z, position.x.x) + offset.t  -- get the heading and add the offset
    local newPoint = {}
    newPoint.x = (math.cos(theta) * offset.d) + possition.p.x   -- project the point and offset the position. 
    newPoint.y = (math.sin(theta) * offset.d) + possition.p.z

 

[cfrag]

12 hours ago, Elphaba said:

Psi?

Yes. Nobody knows what it's for, except that it appears to be a unit's reverse heading, and it screws up your unit's heading if it's present and not inversely aligned with heading. Such are the mysteries of DCS.

[cfrag]

2 hours ago, Elphaba said:

So if there was a part on this vehicle like a control panel or a door or something and you wanted an infantry unit to walk up to that point. You'd first have to work out, in the coordinates of the vehicle the x and z in metres of where that panel/door/controls are

Yes. Let's imagine we have a vehicle that has it's center (origin) = (0,0) somewhat slightly forward, and you then go in and determine that it's front right corner is 2 meters to the right (positive x) and 3 meters forward (y). That corner therefore is (2,3) relative to the origin.

The thing about this is that to the model, that point is always (2,3) relative to (0,0), and some simple (but scary-looking because it uses sine and cosine) fixed formula can always give you the position of the front right corner if you know the position of the origin and heading. It's a standard rotation by angle, and that formula luckily always works the same. 

2 hours ago, Elphaba said:

So, with a little bit of trial and error let's say that the panel you want the soldier to walk up to is -1m backwards in the longitudinal axis and +2m on the lateral axis. 

That is *exactly* how you do this. Annoying, boring, easy to trip up in DCS for reasons I'll say below. The only thing to remember here is that you need to determine the location where the soldier needs to walk to is with relation to a model that is not yet rotated. That point is supposed to rotate with the vehicle so it always stays in the same relative orientation. I believe that you say as much in your description, so from my point of view you are already 99% of the way there

2 hours ago, Elphaba said:

Now, if the vehicle was always orientated so that the + on its longitudinal axis was the same as the maps +X axis, and + on its lateral axis was +Z then it would be simple, but that's not taking into account the ORIENTATION OF THE VEHICLE into account. 

That's where the other 3 vectors in the Unit:getPosition() come into play. 

My question, is how can I - after working out the offsets for the panel/controls/door or whatever from the model viewer, create a waypoint for a ground unit (infantry say) that will take them to that exact point, regardless of the orientation of the vehicle in question. 

 It's usually a lot simpler than you fear. The reason is usually because people often think too complex. What needs to be done is to reduce this complex problem to one we have already solved. And that is how to solve this when the origin of the vehicle coincides with the world's origin. We then solve the rotation, and then we move everything back.

So the standard approach for rotating a reference point around an arbitrary point (say a vehicles center) is to do this:

• subtract the coordinates of the vehicle's map location from both points. The vehicle's center now is at 0,0 and the reference is somewhere close by. Since we subtracted the same amount of both, they are still in the same relative relation to each other
• Now apply the rotation (it's a simple formula: two multiplications, two sums)
• Then add back the coordinates of the vehicle, and -tadaaa- you end up with the reference point rotated around the vehicle's map location

Once you have done this, you'll immediately recognize this pattern in all algorithms: subtract the master location to transport the problem to the origin, perform some transformation, then move back. 

So, long story short: all you need is a 'rotate approach point around a vehicle for an angle' method. @Grimes already kindly provided possible code for that. The algorithm would be (and I'd be happy to assist with that)

• determine the location of the vehicle. That's the p part of getPosition().
• determine the heading of the vehicle that is to be approached. The heading you get from the getPosition(), and use the x vector (that's where the scary atan() function comes in. It returns the heading of the vehicle in the XZ plane.
• Then rotate the approach point around the vehicle by the current heading: subtract origin, rotate around origin by heading amount, add origin back in
• there is no step four

Of course, DCS being what it is, there are some pitfalls you need to be aware of when you put that into code: DCS is a bit casual when naming coordinates: when you assemble a table for adding units, their location is given in x and y and altitude. When you get a location via getPoint() or getPosition(),  that is given in (x, y, z). And here you must be careful that "z" in-game is actually "y" when using creation tables. It *will* bite you, but at least you know that it's coming, and you can be prepared.

 

Edited November 10, 2022 by cfrag

[TEMPEST.114]

9 hours ago, Grimes said:

Don't know much about unit vectors, but there are two sure fire ways to do it. 

This is more or less copied from mist.vec.rotateVec2. You have a known offset, get the heading of the unit, and do some math. 

    local offset = {x = 0.5, z = 1} 
    local position = Unit.getByName( "Ground-1-1"):getPosition()
    local theta =  math.atan2(position.x.z, position.x.x)
    local newPoint = {}
    newPoint.x = offset.x*math.cos(theta) - offset.z*math.sin(theta) + position.p.x
    newPoint.y = offset.x*math.sin(theta) + offset.z*math.cos(theta) + position.p.z

The other way is similar, but would be done via storing the relative heading and distance from object center and projecting a point. 

    local offset = {t = math.rad(70), d = 1.5}    -- unit oriented north, offset position is 70 degrees and 1.5 meters
    local position = Unit.getByName( "Ground-1-1"):getPosition()
    local theta =  math.atan2(position.x.z, position.x.x) + offset.t  -- get the heading and add the offset
    local newPoint = {}
    newPoint.x = (math.cos(theta) * offset.d) + possition.p.x   -- project the point and offset the position. 
    newPoint.y = (math.sin(theta) * offset.d) + possition.p.z

 

Thanks @Grimes

As a test, I put two different vehicle units to send an infantry to. A ground vehicle (working fine) and a Huey. The infantry never goes to the right position on the Huey, and if I reverse the direction the Huey is pointing, then the infantry goes to a completely different spot. 

I have no idea what's going on... 

e.g. (offset x = 1, z = 2) So that's +1 (forward from zero) and +2 (right from zero) with these based off viewing the model in the model viewer.

 

 

However the stupid infantry stops many metres in front of the helo on the right (way outside the offsets) if the helo is facing away from the infantry spawn point, but if the helo if facing the infantry spawn point then, with the same offsets, the infantry moves to the other darn side.

 

And in fact, if I set either vehicle to heading 0 (due north) or 180, 270, 90 then the positioning goes off... 


EDIT

If I change the code to the radial and distance code you supplied, and keep your code identical, this is what I get (70 degrees at 1.5m from 0,0,0)

null

There is no way that's 70deg from the heading of the huey or 1.5m from the 0,0,0 point (according to the model viewer)

Edited November 10, 2022 by Elphaba

[cfrag]

1 hour ago, Elphaba said:

There is no way that's 70deg from the heading of the huey or 1.5m from the 0,0,0 point (according to the model viewer)

I strongly recommend that you show the code that you are using, otherwise we will make assumptions that are wrong. For example: did you convert 70 degrees into radiants or are you using 70 for the sin/cos functions. (1 rad = 57.2958 degrees, so if you input 70 into that without dividing 70 by 57.2958, your guy is bound to end up in a different place).

That being said, while you can precisely control where a unit spawns, having it move to a location is not guaranteed in DCS - you give commands to whole group, not individual units, and often 'close is good enough' for the AI.

[TEMPEST.114]

function TLC:Spawn_INFANTRY_Using_ME_GroupAsTemplate_TO_Vehicle(groupName, toVehicleGroupName, maxCapacity)

  local meGroup = Group.getByName(groupName)

  if meGroup ~= nil then

    local groupToSpawn = self:CreateMutableGroupFrom(groupName)

    if #groupToSpawn.units > 1 then

      self:LogWrite("TLC", "INFO", "Can't spawn group with name %s because it has more than one Unit", groupName)

    else

      local newIndex = #self.spawnedPassengerGroups + 1

      groupToSpawn.name = "TLC_" .. groupName .. "_" .. tostring(newIndex)

      self:LogWrite("TLC", "INFO", "Group To Spawn New Name %s", groupToSpawn.name)

      groupToSpawn.units[1].name = "TLC_" .. groupToSpawn.units[1].name .. "_" .. tostring(newIndex)

      self:LogWrite("TLC", "INFO", "Group To Spawn New UNIT Name %s", groupToSpawn.units[1].name)

      local points     = groupToSpawn.route.points
      local vehiclePos = self:GetVehicleSpawnPoint(toVehicleGroupName)

      groupToSpawn.route.points[#points].x = vehiclePos.x
      groupToSpawn.route.points[#points].y = vehiclePos.y

      coalition.addGroup(2, 2, groupToSpawn)
      table.insert(self.spawnedPassengerGroups, groupToSpawn)

    end

  else

    self:LogWrite("TLC", "INFO", "Could not spawn group with name %s", groupName)

  end

end

function TLC:CreateMutableGroupFrom(groupName)

  self:LogWrite("TLC", "INFO", "Create Mutable Group from GroupName %s", groupName)

  local mutableGroup = {}

  for sideName, coalitionData in pairs(env.mission.coalition) do

    if sideName == "neutrals" then sideName = "neutral" end

      if type(coalitionData) == "table" then

        if coalitionData.country then

          for _, countryData in pairs(coalitionData.country) do

            for categoryName, objectData in pairs(countryData) do

              if categoryName == "plane"
              or categoryName == "helicopter"
              or categoryName == "vehicle"
              or categoryName == "ship" then

              for _, groupData in pairs(objectData.group) do

                if groupData.name == groupName then

                  if groupData.lateActivation then

                    groupData.lateActivation = false

                 end

                  mutableGroup = self:deepCopy(groupData)

                  for unitId, unitData in pairs(groupData.units) do

                    mutableGroup = self:deepCopy(groupData)
                    mutableGroup.name = unitData.name
                    mutableGroup.units = {}
                    mutableGroup.units[unitId] = self:deepCopy(unitData)

                  end

                  return mutableGroup

                end

              end

              elseif categoryName == "static" then

                for _, staticData in pairs(objectData.group) do

                  local staticName = staticData.units[1].name
                  mutableGroup = self:deepCopy(staticData)
                  mutableGroup.countryId = countryData.id

                end

              end

            end

          end

        end

      end

    end
end

---------------------------------------------------------------------------------------------------
-- ************************************************************************************************
---------------------------------------------------------------------------------------------------
-- *** Board Vehicle Setup ***
---------------------------------------------------------------------------------------------------
-- ************************************************************************************************
---------------------------------------------------------------------------------------------------

function TLC:AddAllPassengerVehicles()

  TLC:AddPassengerVehicle( "LAZ Bus", 3, 0.8, 34, 50 )
  TLC:AddPassengerVehicle( "UH-1H"  , 1,   1, 14, 14 )

end

function TLC:AddPassengerVehicle(typeName, longitudinalOffset, lateralOffset, normalCapacity, maxCapacity)

  self.usableVehicles[typeName] =
  {
      ["Offsets"]        = self:GenerateVehicleOffsetTemplate(longitudinalOffset, lateralOffset),
      ["NormalCapacity"] = normalCapacity,
      ["MaxCapacity"]    = maxCapacity,
      ["UsedCapacity"]   = 0
  }

  self:LogWrite("TLC", "INFO", "Added New PassengerVehicle: %s", typeName)

end

function TLC:GenerateVehicleOffsetTemplate(longitudinalOffset, lateralOffset)

  return
  {
    ["x"] = longitudinalOffset,
    ["y"] = lateralOffset
  }

end

function TLC:GetVehicleSpawnPoint(vehicleGroupName)

  local vehicle = Group.getByName(vehicleGroupName):getUnit(1)

  if vehicle ~= nil then

    local vehiclePos   = vehicle:getPosition()

    local vehicleType  = vehicle:getTypeName()
    local spawnVehicle = self.usableVehicles[vehicleType]

    if spawnVehicle then

      local offset   = spawnVehicle.Offsets
      local position = TLC:deepCopy(vehiclePos)
      local theta    = math.atan2(position.x.z, position.x.x)
      local newPoint = {}

      newPoint.x = offset.x * math.cos(theta) - offset.y * math.sin(theta) + position.p.x
      newPoint.y = offset.x * math.sin(theta) + offset.y * math.cos(theta) + position.p.z

      return newPoint

    else

      self:LogWrite("TLC", "INFO", "%s isn't in the list of usable Vehicles", vehicleGroupName)

    end

  else

    self:LogWrite("TLC", "INFO", "Trying to Get Vehicle Spawn Point for a vehicle that doesn't exist %s", vehicleGroupName)

  end

end

@cfrag @Grimes 

See any flaws?

Edited November 11, 2022 by Elphaba

[TEMPEST.114]

Anyone?

[ADHS]

32 minutes ago, Elphaba said:

Anyone?

It's weekend my friend. You may need to wait

As for the position:

In 3D programs there is always a PARENT drag point.
If you drag this, the rest of the the object is following.
Means: all object's axis are refering to this ONE point
and they are not changing. The POINT is changing X,Y,Z.
Seems that not all DCS objects have the PARENT point
at the sameplace. F.e. i was checking the speed and
altitube of planes and helicopters in ground level.
Helicopter was fine LOWER than 1 but planes need
LOWER than 2 (pilot's height). Keep this in mind to
check the infantry's PARENT (at shoes level) in your example.

Edited November 11, 2022 by ADHS

[TEMPEST.114]

@ADHSThanks! 

I'm not sure what you mean by 'Parent drag point'. 

I'm not sure how that applies to what I'm seeing, but this is all new to me so it could just be me being especially dense. 

[ADHS]

Let me explain:

You want to move a point in your screen. You drag it and you move it.
Now, you have a 3D object that you want to drag and move.
Here is the trick:
Instead to calculate all points of the object to update with the
new position, you assign a new 4rth POINT that is the ZERO POSITION
for your object. So if you assign correctly all object's AXES to this
point, and then you drag THIS point, the object will follow. This called PARENT.
X,Y,Z that we can get with getPosition.p is This ONE's POINT cordinates in DCS world.
Hope this helps.

This POINT may have been set to:
Helicopter: 0,25 cm above AGL
Planes: 1,80 meters above AGL
Infantry: 0,5 cm above AGL etc

Edited November 12, 2022 by ADHS

[TEMPEST.114]

@ADHS I'm trying to do this dynamically using scripting - not via the GUI Mission Editor. And I'm not trying to move their initial position, but their last waypoint. 

 

Am I completely misunderstanding you? Sorry...

[ADHS]

4 minutes ago, Elphaba said:

Am I completely misunderstanding you? Sorry...

No but i mean that your idea may fail if you are not set the propper condition check for your units, according the DCS standards. As i did in my example. Good luck.

Edited November 12, 2022 by ADHS

[TEMPEST.114]

Just now, ADHS said:

No but i mean that your idea may fail if you are not set the propper condition check for your units, according the DCS standards. As i did in my example. Good luck.

 

Can you convert your idea to some code - or even pseudo code so I can follow along better please?