KnightHawk75
Posts: 1450
Joined: 11/15/2018
Status: offline
|
quote:
ORIGINAL: SeaQueen
Huh, that sounds like a start. I was hoping for something maybe, more extensive?
quote:
...
I was hoping for something maybe, more extensive?
How much rambling do you want?  I too was sitting on this for a couple days.
As usual I'm probably gonna be more long winded here than need so I'll put the bottom line at the top. 
Unfortunately often at present one can't pull the information needed from a contact\unit like that is displayed in the contact status screen via Lua. This makes life difficult in trying to accomplishing anything too advanced\too extensive in a reliable and performant way because you can't (consistently\reliably) associate a contact with who's actually got relatively recent tracks on it upon which to make more informed decisions logic upon what you may want to do (or not do). The information exists,can't get at it. Don't get me wrong I know the devs only have so much time to allocate to enhancements like this, particularly in retail.
I raised this some time ago, http://www.matrixgames.com/forums/fb.asp?m=4911711 the limitation and what access to that data would help enable seemed to be acknowledged, as for any priority give too it vs 1000 other requests who knows, and it's my guess there aren't a ton of people trying to script their own little ai's in retail... but there are a few. ;)
That's my TLDR Version.
The Extensive\Advanced things you generally can't do in retail:
Some of things I've wanted to do (context here mainly AI side) but can't.
If sensor s1(or just the unit) on unit A is tracking contact X and it's <= range y from unit A (say a EWR) or some other arbitrary point, then enable specific sensor s3 on unit F (be that fcr, search radar, ir tracking, whatever, otherwise don't activate). That would apply to things involved with IAD hierarchy. You can do the contact range part relative to a unit, but you can do it based on who's tracking\has the track on it.
Getting even more advanced like checking if unit A is tracking contact X at rate of every 12sec, and unit B is also tracking contact X at every 5sec or less and B's track is from a FCR radar and at certain range and B has weapons available, and unit C is <= N nm from unit B then maybe there is no need to fire up it's radars yet. Additionally maybe that gets overridden in cases and you do want to fire up the radar still - say if unit B is actively firing on something at it's max firing rate (ie B's weapon table shows 16 missiles outbound,12 more available,but only has once instance of a 16 channel missile command comms) and the contacts that B's is tracking in missile range exceed 16, and said 'extra' contacts are inside C's fcr and missile range such that turning on C might help. etc..etc..
You simply can't do a lot of this advanced logic even if you wanted to spend the time atm without reliably knowing exactly who (which units) and sensors have tracking on what contacts.
BUT if one had access to the contact status screen level of data one could if one wanted create all kinds of logic (good or bad lol) for a given specific scene setup, or maybe even develop some more broadly usable logic toward specific sorts of setups\desires. Even having just the last 20 or 25 or so I think per contact that it keeps would be incredibly useful and we could build our own extended tables based on the ever changing last ~20 provided. Alternatively I suppose a sensor detection trigger type (not to be confused with the generic detection trigger that exists that doesn't cover what is needed) would let one build and maintain their own tracking and association tables. The first strikes me as more modest request to implement be it on the unit or the contact wrapper (or both) as all the info at least preexists.
Types of things you CAN do today if you want to spend the time scripting it, some are heavier lifts than others:
-If X destroyed or damaged > Y% (or checking particular sensor(s) on unit X for damage\destruction) then Do\activate Z.
-If weapons of type Q are exhausted on Unit A or B or Group D or inventory < Y on unit A or Unit B then dosomething\like activate unit C.
-If unit A or B looks overwhelmed (firing x amount of missiles exceeding it's comm lines) and y amount of contacts marked posture H are in a given area and they look like they are in range of Unit C then activate unit C (flip him off passive and to tight).
-Contact range based things broadly - ie If contact X of type Y <= Zrange from UnitA (no matter who is actually tracking it and if this unit would know that) then activate or deactivate desired sensor(s) on one or more units. Just be careful to check\measure contact.areaofuncertainty size first though cause you often don't want to go turning things on due to a widely uncertain readings. This can give you at least some control when dealing with layered IAD's and knowing went to flip off hold or not, so at least things far-in aren't turning on well before you may need them too. I have a customizable per unit\sensor form of this in my YARC for example but after the passive not really being passive anymore have to go back and adjust for release doctrine to actually restrict things.
-You can apply some logic based on if the unit\sam in question is already a contact on another side, and grab that contact wrapper and see what the detection level is (assuming it's accurate - it isn't always and I've reported it) and if the areaofuncertainty is greater than x, or what types of tracking they have on you. If you determine they have only a vauge fix on your unit maybe that plays into if you really want to activate your emissions more. If your unit is mobile, maybe it's time to scoot to a new location if they do have a good fix on you, or if static-fixedfacility maybe go hot because they already know you're there. Using unit.ascontact is however more on the "cheat" since unless your weaving info-warfare into the scene as it's info the unit\side may not realistically know. But often it's still worth doing. You can always make it degrade or turned off with the destruction of particular or groups of particular things, or maybe is only active during certain times, or the human gets certain things exposed or give if balance is needed.
-You can apply some logic based on entries in unit.weapon, unit.firingAt, unit.targetedBy, and unit.firedOn tables (should data exist and timing is right) as to if "now" is really a good time to turn off one's emitting sensors (or for that matter to turn on). This can be useful if randomizing sensor activities for periods of times and you want over-rides to the randomness (like I know I told you to turn off now.. but ignore my orders for at least 30 extra seconds cause you have weapons in the air that need your guidance...check back again in 30 seconds).
-Though firedOn and targetedBy can be a little cheat'ish in certain circumstances depending if the unit being fired on actually really knows it yet (ie cruise missiles 400 miles away that are not yet detected as I recall will still turn up -which isn't always a bad thing, rather have the data and choose when not to use it,than not have it). That said giving an AI opponent a bit of an edge in information there in CMO I rarely consider bad in most scenes because of all the other limitations\disadvantages it has vs a human player - especially one who may know how to 'game' usual behaviors. Even when applied on the human side it's often less a cheat and more just a time\focus saver more than anything. ascontact is definitely more on the cheat side.
-Here and there QueryDB can help but it really needs to be extended more in it's coverage to be more useful but one can overcome that by embedding one's own databases of capabilities.
Side note - Also wish there was a way to determine "jammed" status of a unit (or even better at the sensor level on that unit) as it could be optionally be used as a factor applied to certain implementations of logic related to emissions control.
http://www.matrixgames.com/forums/fb.asp?m=4905591
Side side note - Still after all these years you can't simply query the state of a units\groups\mission\side EMCON, sure you can set it, sure you can override it with what you want now, and in 1146.x+ you can query and flip the override state at unit level, but you can't actually query the current state\doctrine setting. I don't understand why there is no corollary such as a ScenEdit_GetEMCON() to ScenEdit_SetEMCON (request posted). Makes it problematic when trying to dynamically return something to a prior original state since you can't record what that was, or determine if you even need to waste some calls to do something that may already be set. I have added it to the list of requested features, also there was some discussion some time back about making a 3rd emcon state such that active was on, passive like it used to be was off and the new default was current behavior of passive not really passive but FC coming on when the system thinks it should.
In addition to all the scripting solutions you also have the basic of separating things to search unit and firecontrol based unit like pn79 mentioned (and if us\uk and few other pieces - cec related trickery\deception you can setup sometimes), and adding a whole lot of WRA range settings (which you have to do anyway now) so that things (now..at least - I preferred the old system when passive actually really meant passive) don't expose themselves earlier than needed, though the new system has is upside cases too. What others have mentioned already are all good suggestions with very little to no scripting needed.
Hopefully there was something useful to someone somewhere in all that.
|
Printable Version
IADS Hierarchy and EMCON - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread