UnitRemainsInArea

[TitaniumTrout]

I'm using a Unit Remains in Area trigger and have several units inside of the area. When the trigger fires it only appears to effect one of the units, which is the same each time.

Is there a way to iterate through the list of units still inside of the area?

[KnightHawk75]

Via inspecting the zone itself no.
But if you knew the names\guids of the units to check you could inspect each of their areaTriggersFired properties\tables, but outside debugging where you would know which units to check I'm not sure how helpful that is to you, unless you're already recording those (for debugging purposes or not) via an enters trigger.

I wonder, if you specificity a type (even if you don't want to per-say) does it then do more than just the first\one?

[TitaniumTrout]

The first script I used from RockPaperScissors & Whicker iterates through the entire list of units, measures the distance from a point, and then applies the effect. It works, but every time it fires there is a second or two lag. I had hoped the UnitRemains trigger might be a quicker way to do it.

I'll see if it works by unit type, but I have a feeling I'll run into the same issue if it's a flight of jets or a group of boats.

[KnightHawk75]

If you're looking for an alternative scanning method, that may not lag like that (test and see I'd be interested in results), see the script I provided for vettim89 here, I've used it with checking couple hundred once per minute, but not thousands of units so don't know if it lags.

fb.asp?m=4797380

[TitaniumTrout]

ORIGINAL: KnightHawk75

If you're looking for an alternative scanning method, that may not lag like that (test and see I'd be interested in results), see the script I provided for vettim89 here, I've used it with checking couple hundred once per minute, but not thousands of units so don't know if it lags.

fb.asp?m=4797380

Thanks Knighthawk! I'll check it out and see how it works.

[KnightHawk75]

ORIGINAL: TitaniumTrout

ORIGINAL: KnightHawk75

If you're looking for an alternative scanning method, that may not lag like that (test and see I'd be interested in results), see the script I provided for vettim89 here, I've used it with checking couple hundred once per minute, but not thousands of units so don't know if it lags.

fb.asp?m=4797380

Thanks Knighthawk! I'll check it out and see how it works.

I did a couple tests with the remain in area, yeah it basically only meant to be used one-trigger entry per unit, no way around that. So either tracking entry\exit + global table and calculating the time inside yourself, or using the inPolygon function in the mentioned script to check (and also calculate the time yourself) are probably the best options.

One more option is upon an on-enter area trigger script, dynamically generate a new event and new trigger specific for the entering unit with it's name having a certain prefix, then it'll fire after that 5 minutes for who ever enters and stays. Then in the script that runs for that UnitInAreaTrigger after the 5minutes does whatever it needs to do but also at the end removes the event or maybe safer just marks itself inactive, if doing the latter then have another that just does a cleans up cycle. That cycle would say every 5-15min run though any inactive events certain prefix string, and find it's related trigger, remove the given event, and remove the matching trigger. The on-exit trigger could equally attempt a cleanup check specific for that unit. Little convoluted but I think doable and technically avoids having to check a ton of units on a regular basis.

[michaelm75au]

Let me see if I can workout a way to have a 'variable' that can be looked at as a list of 'unit ids' that satisfies the event in the same game cycle.
If you have a save that I can use to trial this, it is appreciated.
---

This event is for any unit that matches the criteria being in the area for a set time. So even if a list variable is returned with all the other units in the area, none of of them need to have been there for the set time.

So maybe having this tied to the event is meaningless.[&:]
--

So what exactly are you trying to get from this event, where you need a list of units?

The event is just saying a unit (of the appropriate type) has been here for '5 minutes'.

[michaelm75au]

It may be more practical to make this part of the 'side' wrapper as in:

local side = VP_GetSide({side='sidea'})
print(side)
local u = side:unitsInArea({Area = { 'RP-3137', 'RP-3139', 'RP-3136', 'RP-3138'}, TargetFilter = { TargetType = 'Ship' } })
print(u)
side {
guid = '387dfb31-e553-412a-8258-9b959aa00aed',
name = 'SideA',
units = 'table',
contacts = 'table',
}
{ [1] = { name = 'DD 101 Murasame', guid = 'a1a52edf-3541-4b55-bea4-58d4e1ab11dc' } }

Omit the TargetFilter, and it would give all units on the side in the area. Area needs to be mandatory of course.

[KnightHawk75]

ORIGINAL: michaelm75au

It may be more practical to make this part of the 'side' wrapper as in:

local side = VP_GetSide({side='sidea'})
print(side)
local u = side:unitsInArea({Area = { 'RP-3137', 'RP-3139', 'RP-3136', 'RP-3138'}, TargetFilter = { TargetType = 'Ship' } })
print(u)
side {
guid = '387dfb31-e553-412a-8258-9b959aa00aed',
name = 'SideA',
units = 'table',
contacts = 'table',
}
{ [1] = { name = 'DD 101 Murasame', guid = 'a1a52edf-3541-4b55-bea4-58d4e1ab11dc' } }

Omit the TargetFilter, and it would give all units on the side in the area. Area needs to be mandatory of course.

Wow that idea would be a nice replacement for the inPolygon thing, I have to image it being built in it
would run at least marginally faster, the math is probably similar but at least all the getunit calls while traversing a sides unit list, (even an already :unitsby filtered) one each wouldn't be brokered though lua, could be savings there. [:)]

On the list variable idea... that's an interesting thought and would save those in TitaniumTrout situation from some code, idk what complications it introduces on your end though. So... sort of like trigger type 'Remains in area' but with a [X]AnyAndAllUnits checkbox that if enabled, tells it if anyone is in the area provided, for the provided amount of time, then trigger (ie 1 or more units qualifies). Then ListX() during the event returns a table of those units, containing guid,name,side,type,subtype,dbid of each unit matching. spitballing maybe in that context UnitX is just the table. Actually you could probably keep today's functionality entirely, but then just fill ListX with all who qualify, null if none, if you didn't care about doing the extra processing regardless of if it was needed.

or not [:D]

Without something like that it leaves the whole time tracking issue to the scripter but I tend to think that's ok. One can handle the persistence across sessions of the time tracking by packing the simple tracking table into a key on every check cycle, and unpacking it during OnScenarioLoad. I do wish there was a OnScenarioSave trigger that fired just before the game actually saves. Such would give a chance for an author to save state, not so much for this example, but ones that involve things that get updated more often then each minute or just involve bigger tables where repacking them into a key(s) constantly may not be as practical.

[TitaniumTrout]

In a nutshell I'm working with a script Whicker and RockPaperShotgun came up with that uses the inverse square law to calculate the odds that a unit is comms jammed. The UnitsInArea method looks great and I'll test it out this evening, I haven't played with the side wrapper at all, but that method looks like it'll work great. I'll use a RegTime trigger and whammo, I'm in business.

Thanks guys!

[TitaniumTrout]

ORIGINAL: michaelm75au

It may be more practical to make this part of the 'side' wrapper as in:

local side = VP_GetSide({side='sidea'})
print(side)
local u = side:unitsInArea({Area = { 'RP-3137', 'RP-3139', 'RP-3136', 'RP-3138'}, TargetFilter = { TargetType = 'Ship' } })
print(u)
side {
guid = '387dfb31-e553-412a-8258-9b959aa00aed',
name = 'SideA',
units = 'table',
contacts = 'table',
}
{ [1] = { name = 'DD 101 Murasame', guid = 'a1a52edf-3541-4b55-bea4-58d4e1ab11dc' } }

Omit the TargetFilter, and it would give all units on the side in the area. Area needs to be mandatory of course.

local side = VP_GetSide({side='NATO Allied Air Command'})

local jammerArea = {'Jammer 1', 'Jammer 2', 'Jammer 3', 'Jammer 4', 'Jammer 5', 'Jammer 6', 'Jammer 7', 'Jammer 8'}

for k,v in ipairs(side.units) do
local x = ScenEdit_GetUnit({ guid=v.guid })
if x:inArea(jammerArea) == true then print("In!") else print("Out!") end
end

Progress! I could not get the code to work using the side wrapper alone, but I can get all the guid's and use it inside of the unit wrapper. This is the first time I've encountered the : operator and I'm still not clear on how it's functioning. Could you elaborate on it?

What do I need to do to get it to work as you posted?

Thanks much guys!

[TitaniumTrout]

There we go!



RPS & Whickers inverse square is the basis. I might try to fit a different curve down the road. It runs pretty quick with both the distance method and the inArea method.

Appreciate all the help guys. Thank you! I think it's going to turn out great. Now I can get on with the scenario.

[Whicker]

not sure I even know what an inverse square is! don't remember doing anything with it, sounds cool though.

[KnightHawk75]

@TitaniumTrout - On the Side wrapper addition, I think what Michael posted was a 'what if i added something like this', for discussion purposes.

Cool stuff your working on, taking nocomms\comms jamming to a new level! (without PE edition)

This is the first time I've encountered the : operator and I'm still not clear on how it's functioning. Could you elaborate on it?

Just means you're calling a method on an object in lua. Technically you can define Lua functions in two different ways, with '.' notation or ':' notation. The difference beyond cosmetics comes to down to primarily if the 'self' hidden variable is provided where ':' provides syntactic sugar to say you want it, similar to 'this' in some other languages. This mainly comes into play when using OO concepts with Lua and metatables, which I'll avoid because it's way beyond the scope here, and I'm no expert. None of this really matters to the use of the wrapper other than knowing : means you're calling a method not a property or field. I'll illustrate though the basic difference between the two when using it yourself in Lua.

Code: Select all

gKH = {};gKH.Sensors = {} -- build our namespace for example.
 gKH.Sensors.MatchParams = {} -- our MatchParams table\object. 
 
 --Method returns a instance of MatchParams with '.'
 function gKH.Sensors.MatchParams.new(p)
   local self = {};
   self.MatchType = p.MatchType or 'DBID';
   self.MatchValue = p.MatchValue or '0';
 return self
 end
 
 --Now using : notation.
 --Method returns a instance of MatchParams with ':'
 function gKH.Sensors.MatchParams:new(p)
 -- a variable 'self' exists here that refers to the instance of a MatchParams object that new was called on)
   self.MatchType = p.MatchType or 'DBID';
   self.MatchValue = p.MatchValue or '0';
   return self; 
 end
 

Code: Select all

 --function that is part of each MatchParams instance, does a self-check on it's own values using '.' 
 -- without getting into metatable stuff... that's out of scope 
 function gKH.Sensors.MatchParams.checkparams(obj)
 -- we need caller to specify the object to use
   if obj.MatchType ~= 'RANGELOWER' then print('not range lower'); end
 end
 
 --Same thing with ':' only we inherently have 'self' to use.
 function gKH.Sensors.MatchParams:checkparams()
   --self inherently means this instance.
   if self.MatchType ~= 'RANGELOWER' then print('not range lower');end
 end
 

Code: Select all

 -- Both notations above accomplish the same thing just differently. 
 local m = gKH.Sensors.MatchParams.new({MatchType="ROLE"})
 m.checkparams(m); -- <-- we have to tell it which object 
 -- vs.
 local m = gKH.Sensors.MatchParams:new({MatchType="ROLE"})
 m:checkparams; -- <-- m is automatically passed
 

Now you can\could use . notation and still use the self concept, just have to create the 'self' var yourself and set it's metatable to that which you want it to reference, I personally prefer this actually for consistency. But : notation provides nice syntactic sugar for setting it to the calling object, it also provides a way for the user to sort of know if they're calling a function\method vs a field\property not.

[michaelm75au]

The new method in the 'side' wrapper would not be available until a future build. Sorry if I caused confusion.

[TitaniumTrout]

ORIGINAL: michaelm75au

The new method in the 'side' wrapper would not be available until a future build. Sorry if I caused confusion.

There's no confusion here, just awesomeness. This is good stuff.

Just to make sure I'm getting this. If I define a unit as variable "questionUnit" I could for example :



questionUnit:delete
questionUnit:rangetotarget('contactid')

Whereas questionUnit.name would just return a value.

Thanks much guys, learning a great deal here.

[KnightHawk75]

Yup. You got it.