KnightHawk75
Posts: 1450
Joined: 11/15/2018 Status: offline
|
quote:
ORIGINAL: michaelm75au It may be more practical to make this part of the 'side' wrapper as in: quote:
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 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.
|