know the position of a Map object with LUA

[Japo32]

Hello!

I am learning LUA for DCS and I know that I can have the position of  a unit called "myUnit" in ME like this:

local unitLoc = Unit.getByName('myUnit'):getPoint()

But if I don't have the name of that object, for example a House in the map. I only have the object ID. (For example 82505001) is there a way of having the "getPoint" or position of that house with its ID number? I suppose I have to use an StaticObject, but don't know what to use, because getID and getObjectID just returns the number of an named object I suppose. 

I am totally new with this. Thanks!

 

 

[cfrag]

17 minutes ago, Japo32 said:

But if I don't have the name of that object, for example a House in the map. I only have the object ID

With map objects, it’s very different. Right-click on the map object, and choose the ‘assign as’ pop-up. It’ll place a trigger zone over the map object. Use that trigger zone‘s name to access the zone, then get its (the zone’s) position. That’s the easiest way to access map object locations from Lua.

Edited December 14, 2023 by cfrag

[Japo32]

ok! and I suppose the sentence is the same Unit.getByName('name') ?

[cfrag]

To get a named trigger zone you use 

local myZone = trigger.misc.getZone('my zone name')

To access the point at the center of the zone you use 

local myPoint = myZone.point

 

[Grimes]

Gonna have to add some details. If you know the runtime object id then it is accessible via the scripting engine. 

So yeah, you can right click to populate a trigger zone that represents the object, however the object id can still be useful. 

Here is a basic function that takes the object Id displayed in the trigger zone and creates a table using that id value. Which then use an Object function on and lo and behold it returns a value. 

This is the result. So yes, if you know an object id you can just make a table in the format of {id_ = number} and scripting functions will work with it. Can't call functions like {id_ = whatever}:getTypeName() because its not an object in the traditional sense. 

The downside, and its a biggie, is that when the map updates EVERY single object id will be changed to something different. This is where the trigger zone can come in handy because you know object type exists at a specific point. You can use world.searchObjects to get the current runtime id of the object by checking known coordinates and typenames. The upside is that the id values don't update all that often, but they can update, which will throw a spanner in the works.