|
KnightHawk75 -> RE: Creating a hierarchical IADS (12/12/2021 2:30:51 AM)
|
quote:
If information shared with A passes freely from A->B an B->C but not A->C then by removing B, you deny C the information from A. Nah, cause C never had access to A's info no trust existed between A & C.
quote:
That renders B redundant
Yup, now you get it, you can't do what you're trying to do without scripting the logic. Unless B is more than just logical ie it also has it's own assets or need for information from A (or C for that matter) it's entirely redundant and should be removed. Where you might not is say B had air assets to scramble, where it would be making use of the info. Your detectors need to consider the shooters friendly for shooters to get their contacts from them, and even then you can't predict which of those contacts they'll choose if there are multiple per underlying unit (a separate rabbit hole you may come across with detectors all being on separate sides).
If you did want to simulate A (radar units) B (middleman layer units) C (shooter units), you trigger a scan say every 15seconds for the interested units on side B, if they exist and are not significantly damaged, you do nothing, if they are damaged or destroyed, you then change postures on side A toward C from F to N. Even then you don't 'need' a real side B, as the triggering unit(s) could exist wherever. I've done what you're trying to do before, basically making it necessary for side Z to strike a bunker on side B (which had other reasons to exist), where after a comm-link inside the bunker on B is 'destroyed', the information sharing from detectors(A) stops to shooter units(C), as well as information sharing stopped from side B to C as well, also in my case the shooters(C) were also disabled by same script, instead of just being left to act on their own information. In that specific instance I wanted to pretend the shooters were relaying on search and FC data from others (even though due to lack of cec or los-with data provider, they technically were not and had their own FCR) and wanting the taking out the fake-middle-man link(s) to make the shooters useless.
You can make it more advanced, having multiple bunkers\network points, multiple author defined links\associations between bunkers\network points and end-users\shooters, your own routing\path-finding logic to determine if there is still a path from detectors to your shooters based on your own associations and the units status. But you'll have to build that subsystem yourself. Alternatively as above it can be as simple as as does bunker exist...share, if not...don't.
As for if things should be transitive...ehhh even though it would help in these instances it would step on other instances where it's definitely not desired, and probably complicate other matters. What you really want is link-daisy-chaining ability, combined with rightly matched links,link-capability, and range, combined with cec system, avoiding some of the whole extra sides machinations and subsystem building.
I'm off off-topic but...
I'll tell you what helps greatly in designing better IADS in the game, being able to edit the database and piggy backing on the cec system, and tweaking links as needed for the behavior you want (entirely realistic or not). Changing links themselves (flagging daisy chain),adjusting range, los-requirements, assignment on units(cec), and munitions(cec) such that you don't have to get into playing games with sides and you can better mimic FC being off-unit from launchers, even if they are just a couple hundred meters apart. You can do some neat stuff, but you need to build out all the right pieces for it (many lacking from db3k, some probably rightfully so).
In non-pro though, even if you raw edit the scene file to turn off ParentSpecfic (db speak for supports cec) for the unit assigned links, you still have the issue often with the link on the missile itself not supporting it (restricting launch, such is case with sa21b's), and there is no way of tweaking\overriding it ahead of time. If more missile links in the database had parent specific set to off, then one could selectively enable some off-boarding by manual edits of the raw file... or additions to UpdateUnit() that allowed flagging PS=false on the add_comm routine on the unit. It would enable authors to better selectively, yet purposely, do both realistic stuff, and if they so choose unrealistic or hypothetical/future stuff with existing gear, but in most cases it would wouldn't change the default behavior, as someone would have to mod the placed unit links to enable it as mentioned.
Anyway that's a topic you may run into next after you have contacts shared they way you want, as sharing them doesn't always do you any good if you can't make your launcher fire using that off-board data,or link-los issues arise, though you can use it for queuing on when is a good time to fire-up the local FCR, take a shot, and then move, which seems more like what your scene was interested in doing.
|
|
|
|
