Please add "Unit's distance to Unit smaller/greater" condition

[cfrag]

A condition that checks if the distance between two units is greater than or smaller than a trigger value would simplify a lot of my missions. Currently, I simulate this condition by

• creating a trigger zone with the required distance
• then add a 'unit in moving zone' condition

 

It's very difficult to read, annoying to maintain, and creates a LOT of unnecessary clutter in ME for simple distance checks. I'm aware that it would 'only' be a QOL addition since technically, this ability already exists. But it would make my life so much easier.

 

Thank you.

Edited March 20, 2021 by cfrag

[StevanJ]

At first I wanted the same thing, But i realised the moving zone IS the solution.
"Advanced"- Mission Planning will solve this issue.
The moving Zone is THE BEST way of dealing with distance between two units.
Its how we can deal with 'mid air refuelling' triggers too without a script.

Do you plan your missions first?
Because alot of what you seem to be asking can be made alot easier just by making a plan, and 'building it outside of the editor first'..

Draw your mission on a piece of paper ie- 'Unit kills target' (unit at one end the target at the other with a line between them), then write down what 'other units/tasks' you want in the 'plot line' (the middle of the mission).
ie FA18 Kills Tanks, On the way to his primary task his options 'might' or 'might not' include random events; an example being 'staying clear of Anti Air/destroying CAP/mid air or ground Refuels/joins up with an escort etc'.
Build your plot first independantly of the rest of the mission allowing the player to 'win' once they achieve it and make this his sole mission- then assign independant sub plots that contribute towards or against his primary mission- And get into a practice of naming the units in the current task 'A', 'A1' until a task is finished in the mission editor.

Once a task is complete- Rename the unit with a proper name to signal that task is finished and to certify to yourself 'this task has been completed'
Moving zones then become MUCH easier to setup, example- player 'A' inside moving zone (distance) enemy 'A1'
Making sure you complete the task to the finish, before moving on to sub tasks that might happen randomly.
This will stop you from having to scroll through a long list of units each and every time.

[cfrag]

As user interface, the moving zone solution is an ugly hack and a truly abysmal solution to providing access to something as elementary as the distance between two objects.

 

How far are two points A and B apart? Magnitude(A-B). But hey, let's introduce a Zone Z that has it's own origin, radius and name, and then provide a (subjectively) hellish UI to manage this completely unrelated interface object. Then, for good measure, let's put them together using yet another UI metaphor and compare Mag(A-B) to radius(Z). Yeah, that's the ticket! /sarcasm 

 

If you need to test how close two objects are then you don't want to have to access a third separate object just to get a scalar value to compare the distance to. It's inefficient. It's silly from a UX perspective. It creates UI clutter, is difficult to read (when reading the condition you then need to switch out of context, find and access the zone object on the map to read the radius, then switch back into context by looking for the condition again), and incredibly annoying to maintain and debug (just how many conditions reference that zone? Did I catch all, or did I just break the mission by changing this radius?). 

 

In short: it's really bad interface design. 'Advanced Planning' doesn't enter the picture - but if you need 'Advanced Anything' to resolve something this elementary, rest assured that something is wrong.

 

I'm now using a simple Lua predicate instead. Ugly, yes, but much better than using the moving zones kludge. That way I at least have all relevant information in one line of text:

 

return delta("Colt-1", "Colt-2")>2000

 

 

Clear. Concise. Serviceable. Still bad interface because of the two magic strings. But at least no frigging zone management. 

 

-ch

Addendum: For those who are interested: define this very simple Lua script at the beginning of your mission (or as init script) to use the predicate I'm using.

function dist(point1, point2)
  local x = point1.x - point2.x
  local y = point1.y - point2.y 
  local z = point1.z - point2.z
  
  return (x*x + y*y + z*z)^0.5
end

function delta(name1, name2)
  local n1Pos = Unit.getByName(name1):getPosition().p
  local n2Pos = Unit.getByName(name2):getPosition().p
  return dist(n1Pos, n2Pos)
end

 

Performance notes: 

• Above can be optimized by inlining the dist() call; I'm trying to keep my code serviceable.
• If you need max performance, omit the root call and compare to the square of target distance instead

Also please note that I taught myself Lua yesterday (literally - on Easter Monday), so I'm still somewhat n00bish with this particular programming language.

 

Programming notes:
Be aware: no guards before getPosition()

 

Mission Designer notes:
delta() return value is in meters.
 

[StevanJ]

40 minutes ago, cfrag said:

As user interface, the moving zone solution is an ugly hack and a truly abysmal solution to providing access to something as elementary as the distance between two objects.

 

How far are two points A and B apart? Magnitude(A-B). But hey, let's introduce a Zone Z that has it's own origin, radius and name, and then provide a (subjectively) hellish UI to manage this completely unrelated interface object. Then, for good measure, let's put them together using yet another UI metaphor and compare Mag(A-B) to radius(Z). Yeah, that's the ticket! /sarcasm 

 

If you need to test how close two objects are then you don't want to have to access a third separate object just to get a scalar value to compare the distance to. It's inefficient. It's silly from a UX perspective. It creates UI clutter, is difficult to read (when reading the condition you then need to switch out of context, find and access the zone object on the map to read the radius, then switch back into context by looking for the condition again), and incredibly annoying to maintain and debug (just how many conditions reference that zone? Did I catch all, or did I just break the mission by changing this radius?). 

 

In short: it's really bad interface design. 'Advanced Planning' doesn't enter the picture - but if you need 'Advanced Anything' to resolve something this elementary, rest assured that something is wrong.

 

I'm now using a simple Lua predicate instead. Ugly, yes, but much better than using the moving zones kludge. That way I at least have all relevant information in one line of text:

 

return delta("Colt-1", "Colt-2")>2000

 

 

Clear. Concise. Serviceable. Still bad interface because of the two magic strings. But at least no frigging zone management. 

 

-ch

Addendum: For those who are interested: define this very simple Lua script at the beginning of your mission (or as init script) to use the predicate I'm using.

function dist(point1, point2)
  local x = point1.x - point2.x
  local y = point1.y - point2.y 
  local z = point1.z - point2.z
  
  return (x*x + y*y + z*z)^0.5
end

function delta(name1, name2)
  local n1Pos = Unit.getByName(name1):getPosition().p
  local n2Pos = Unit.getByName(name2):getPosition().p
  return dist(n1Pos, n2Pos)
end

 

Performance notes: 

• Above can be optimized by inlining the dist() call; I'm trying to keep my code serviceable.
• If you need max performance, omit the root call and compare to the square of target distance instead

Also please note that I taught myself Lua yesterday (literally - on Easter Monday), so I'm still somewhat n00bish with this particular programming language.

 

Programming notes:
Be aware: no guards before getPosition()

 

Mission Designer notes:
delta() return value is in meters.
 

Whole heartedly agree about the UI and ive asked for changes, but i doubt theyll come
 

As for your comment, theres ALOT of over thinking going on- And its a question for the individual user..
Does a new person want to fill out 12 lines of code, or work with what weve got, saving your time and get better using it..
With a little practice, i can squeeze out a full campaign in a little over a few days. And then create a completely different campaign with a much harder difficulty for someone who wants it, in 25 minutes.
It all comes down to personal preference, but for me, 12 lines of code or a few seconds in using what we have?

Ill pick what we have..

Theres nothing worse than spending your time learning the code just to achieve the same thing in the editor in 2 minutes, then enjoying the moment you dont have to maintain the mission because of a new OB patch.

EDIT: Didnt you previously ask for a placement for a 'roadside FARP'? I made this, and i hope it helps..

Edited April 6, 2021 by StevanJ
Added link

[Fri13]

Unit/Group/Side distance = <> X meters of Unit / Group / (Unit X) Waypoint etc would really be welcoming feature.

 

It would instantly make possible easily make a conditions for engagement ranges and trigger many other functions if someone flies too far from something, too close to them etc. 

We could easily get dynamics to combat as example suddenly having enemies too close to group would get group stopping and engaging the new enemy or retreat to previous waypoint direction etc.