IDK how to access the index in the sensor table
I bet you do, probably just over thinking what I mean.
local u = SE_GetUnit({guid=someguid}) --get unit.
u.sensors[1] -- access the first index\key in the sensors table. assuming there is at least 1
u.sensors[2] -- access the second index\key in the sensors table assuming there is at least 2
u.sensors[#u.sensors] --access the last index\key in the sensors table assuming there is at least 1.
-- sensors can change position as you remove odd ones, add new ones etc.
So I went little further that just some code, here is working scene example uses mainly sensor guid tracking more than indexes anyway (though the index can be handy at times so it saves that too).[:)]
Load the Individual_Sensor_Addressing.scen in the editor. You will be on side Blue, there are no units.
Load up your \Logs\LuaHistory ... you should see a bunch of successfully loaded xxxx.lua messages. If you don't we got problems. Then set your map settings to show all unit radars.
Press special action button. Press the 'Add USS KH2'. Now is good time to re-open that log and see what it just did. Press play. Wait at least 5 seconds. Watch the pretty radars flicker and change ever 5 seconds. Amazing what's so special about that? [8|]
Well it's that it's being done not by randomly picking a entry, but by randomly selecting based on extra data, in this case an arctype code, and finding the sensor with that arc on that unit. Part of the process after unit creation runs through the unit, removes the 3 spy radars that are there by default, and replaces them with 4 6051's variants. During each one of those add's is when the 'magic' happens in that we associate an arctype with each guid and new index and we store that for later use. In a nutshell that's really it.
People often ask for the code in text file form, with that in mind I implemented things such that that everything loads from the \Lua folder inside the included scene folder. This makes editing with external editors very simple while keeping things organized, the only thing embedded in the .scen is what has to be, the bootstrap code to load the scripts, and 1/2 a dozen lines total between the events and the special action.
Attached is SensorAddressingScene.zip it contains
Individual_Sensor_Addr_InstallationNotes.txt - just tells you to drag\drop SensorAddressingScene in anywhere under main Scenarios folder. It's important.
\SensorAddressingScene Folder - The folder containing the scene
\SensorAddressingScene\Individual_Sensor_Addressing.scen - The Scene file.
\SensorAddressingScene\Lua - Critical sub-folder containing 99% of the code.
\SensorAddressingScene\Lua\gKH.lua -- Couple of lines (stripped bare for this scene)
\SensorAddressingScene\Lua\gKH_base.lua - Couple dozen lines. (stripped bare for this scene)
\SensorAddressingScene\Lua\State.lua - Coupe hundred lines (but you can almost completely ignore it)
\SensorAddressingScene\Lua\SensorTracking_5064771.lua - The meat ~600 lines.
Don't freak out, of the total ~900 lines involved, 50% are comments another 25% probably error\parameter checking code.
SensorTracking_5064771.lua has a lot of information in comments as to what is going on and explicitly calls out the 3 main functions that relate to 'grabbing' the data you need, which may be all you are really interested in or need. ALL the rest is really just related to storing, and managing that data as well as "putting it to use" in the form of the radar flipper. I hope it's at least remotely similar to how you may be trying to use it. It does other stuff too like handle saving that "storage" and re-loading it on startup if you create a save file from it after you've added the unit etc.. again stuff you may not need, but a full-working example is better imho then just 3 functions thrown at you.
Scene Requires: DB3k 489, build 1.03.1147.29+
