Thanks for the explanation.
Dale asked:
One final question, are you speaking in the context of scenario set up (to defeat the player) or are you setting it up in single player as part of an overall strategy for defeating a scenario?
The reasons behind using the specific shipstrike or landstrike are ALWAYS (when I use them) to program the AI to give a good player a run for his money. Couple of examples (SPOILER ALERT!):
- In 2FR_NL a diesel/electric submarine lies in wait before an approaching CVBG. I put the sub on delayed specific shipstrike mission to attack the carrier and used the plotted path during the delay period to move the sub towards where I (the designer) thought the player would move the CVBG. In 3.6 this means that if the player runs his CVBG in the anticipated direction without good ASW practices (active sonar, helicopter patrols), the SSK will hold fire untill the carrier is in range and shoot at her. This is what I think a really bold sub driver would do. Works like a charm in 3.6. In 3.7.3 the sub shoots at a DDG in the outer screen and of course is detected and killed easily by the player. Reading the above I guess the SSK sees the DDG as a threat, but hey, those are risks SSKs with orders to penetrate a CVBG are supposed to take!
- In the example of UNIFIL; Iranian SSMs are aimed at Israeli runways. Iran is then made neutral to Israel so the SSMs don't fire. I then set up a ferry mission of Iranian attack planes to make the player (Israel) make a decision; "do I see the Iranian planes as threat and kill them or do I hold fire". if he shoots; the SSMs (in 3.6) fire and damage his runways which take about 5 hours to repair (great feature that!). In 3.7.3. the whole airbase (all facilities) get destroyed. So in this case I aimed for a mild punishment of the player for breaking ROE and now cannot control the damage done (in fact I've seen the SSMs fire at a different SIDE when that became hostile).
I do understand the efforts made by AGSI to make the AI smarter (that is after all exactly what I try to do in the above examples). However it creates two problems for scen designers that are serious to me:
1. The daunting task to replay/retest ALL my scens in 3.7.3 (which on my 5 yr old PC runs VERY slow) to discover the changes in behaviour of the AI - You may have observed that I've only fully tested and released for 3.7.0 and 3.7.1 about a dozen scens (in about 6 months). I know dozens more need major surgery that I don't have time for (yet).
2. Then to decide how and if I can take the time to change my scens so they will work as intended with 3.7.3.
Don't want to sound negative at all; but is certainly seems that FORWARD compatibility of already built scenario's from 3.6 to 3.7.3 is not one of the features of 3.7.3. By compatibility I mean that the scen plays roughly as the designer intended. There are some GREAT features in 3.7.3 (I've enjoyed Multi-Player, the higher speeds of air intercept missions, the more realistic visual horizon) but it seems that many of my scens will have to stay with 3.6. and I must choose if I spend my H3-time retesting/rebuilding them or leaving them unavailable for 3.7.3 and focus on designing new scens.
I welcome this discussion and hope that maybe Bucks new logic and the 3.6. specific target missions can be combined in some way.
Freek
