Decision events Do not play well with AI events (Devs Please Help)

[Lothos]

Discovered this bug and it hurts allot. I am not able to do multi layer checks for AI files that have decisions that are checked continuously.

This works
####################
# decision.txt
####################
{
#NAME= DE 580 - Japan - Axis - AI - Japan Garrison Size Check
#POPUP=
#MESSAGE= Hello
#IMAGE=
#SOUND=
#FLAG= 1
#TYPE= 1 <-------------------- THIS IS THE DIFFERENCE
#AI= 0
#LEVEL= 0
#COUNTRY_ID= 60
#TRIGGER= 100
#DISPLAY_ORDER= 1
#GV= 1[1,100]
#LINK= 0[0]
#DECISION= 580
#MPP_UPDOWN= 0
#MPP_TURNS= 0
#MPP_TEXT=
#NOTES=
#NOTES_POSITION=
#AI_RESPONSE= 100
#AI_RESPONSE_POPUP=
#DATE= 1939/09/01
#TEXT_RGB= 0,0,0
#SHADOW_RGB= 0,0,0
; - Tokyo - Axis
#ALIGNMENT_POSITION= 389,114 [1]
#NATIONAL_MORALE_TRIGGER= 0 [0]
; - Japan - Axis - War - Not Surrendered
#VARIABLE_CONDITION= 60 [1] [100] [0]
; - Hiroshima - Range 20 - 4 Units - Axis - Japan
#CONDITION_POSITION= 389,114 [20,20] [2,2] [1] [60]
}

# amphibious_minor.txt
#####################

{
#NAME= Japan DE 580[1] - Axis - (Zone 2) - Hiroshima -> Philippines - Dagupan
#POPUP=
#FLAG= 1
#TYPE= 2
#COUNTRY_ID= 60
#TRIGGER= 100
#LEVEL= 0
#GV= 1[1,100]
#LINK= 580[1]
#SIZE= 1,2
#BUILD_LENGTH= 1
#LENGTH= 15
#RANGE= 20
#LONG_RANGE= 1
; Dagupan
#GOAL_POSITION= 358,152
#GOAL_POSITION= 374,123
#COASTAL_POSITION= 356,150
#DATE= 1939/09/01
#STEAL= 0
;Japan
#FRIENDLY_POSITION= 382,117
#FRIENDLY_POSITION= 377,120
#FRIENDLY_POSITION= 378,118
#FRIENDLY_POSITION= 382,119
#FRIENDLY_POSITION= 383,115
#FRIENDLY_POSITION= 386,116
#FRIENDLY_POSITION= 389,114
#FRIENDLY_POSITION= 390,109
#FRIENDLY_POSITION= 390,102
#FRIENDLY_POSITION= 391,97
#FRIENDLY_POSITION= 395,97
; - Zone 1
#FRIENDLY_POSITION= 372,130
#FRIENDLY_POSITION= 391,133
#FRIENDLY_POSITION= 360,133
#FRIENDLY_POSITION= 358,138
; - Japan - Axis - War - Not Surrendered
#VARIABLE_CONDITION= 60 [1] [100] [0]
#TACTICAL_CONDITION= 389,114 [3]
#ACTIVATE_POSITION= 0,0 [0,0] [0,0] [0]
; - Hiroshima - Range 20 - 1 Unit - Allies
#CANCEL_POSITION= 382,117 [20,20] [1,1] [2]
}




This DOES NOT work
####################
# decision.txt
####################
{
#NAME= DE 580 - Japan - Axis - AI - Japan Garrison Size Check
#POPUP=
#MESSAGE= Hello
#IMAGE=
#SOUND=
#FLAG= 1
#TYPE= 2 <-------------------- THIS IS THE DIFFERENCE
#AI= 0
#LEVEL= 0
#COUNTRY_ID= 60
#TRIGGER= 100
#DISPLAY_ORDER= 1
#GV= 1[1,100]
#LINK= 0[0]
#DECISION= 580
#MPP_UPDOWN= 0
#MPP_TURNS= 0
#MPP_TEXT=
#NOTES=
#NOTES_POSITION=
#AI_RESPONSE= 100
#AI_RESPONSE_POPUP=
#DATE= 1939/09/01
#TEXT_RGB= 0,0,0
#SHADOW_RGB= 0,0,0
; - Tokyo - Axis
#ALIGNMENT_POSITION= 389,114 [1]
#NATIONAL_MORALE_TRIGGER= 0 [0]
; - Japan - Axis - War - Not Surrendered
#VARIABLE_CONDITION= 60 [1] [100] [0]
; - Hiroshima - Range 20 - 4 Units - Axis - Japan
#CONDITION_POSITION= 389,114 [20,20] [2,2] [1] [60]
}

# amphibious_minor.txt
#####################

{
#NAME= Japan DE 580[1] - Axis - (Zone 2) - Hiroshima -> Philippines - Dagupan
#POPUP=
#FLAG= 1
#TYPE= 2
#COUNTRY_ID= 60
#TRIGGER= 100
#LEVEL= 0
#GV= 1[1,100]
#LINK= 580[1]
#SIZE= 1,2
#BUILD_LENGTH= 1
#LENGTH= 15
#RANGE= 20
#LONG_RANGE= 1
; Dagupan
#GOAL_POSITION= 358,152
#GOAL_POSITION= 374,123
#COASTAL_POSITION= 356,150
#DATE= 1939/09/01
#STEAL= 0
;Japan
#FRIENDLY_POSITION= 382,117
#FRIENDLY_POSITION= 377,120
#FRIENDLY_POSITION= 378,118
#FRIENDLY_POSITION= 382,119
#FRIENDLY_POSITION= 383,115
#FRIENDLY_POSITION= 386,116
#FRIENDLY_POSITION= 389,114
#FRIENDLY_POSITION= 390,109
#FRIENDLY_POSITION= 390,102
#FRIENDLY_POSITION= 391,97
#FRIENDLY_POSITION= 395,97
; - Zone 1
#FRIENDLY_POSITION= 372,130
#FRIENDLY_POSITION= 391,133
#FRIENDLY_POSITION= 360,133
#FRIENDLY_POSITION= 358,138
; - Japan - Axis - War - Not Surrendered
#VARIABLE_CONDITION= 60 [1] [100] [0]
#TACTICAL_CONDITION= 389,114 [3]
#ACTIVATE_POSITION= 0,0 [0,0] [0,0] [0]
; - Hiroshima - Range 20 - 1 Unit - Allies
#CANCEL_POSITION= 382,117 [20,20] [1,1] [2]
}

[BillRunacre]

The trouble is that a Type= 2 will be resetting every turn, so it's almost like having something turned on, turned off, turned on, turned off again on a continuous basis.

If you can explain a bit more what the aim of the non-working script is, perhaps we can think of an alternative approach?

[Lothos]

The trouble is that a Type= 2 will be resetting every turn, so it's almost like having something turned on, turned off, turned on, turned off again on a continuous basis.

If you can explain a bit more what the aim of the non-working script is, perhaps we can think of an alternative approach?

Part 1 - The script is multilayer I need to make sure that Japan has enough forces in Japan which is why the Decision Event (CONDITION_POSITION)
Part 2 - The AI script itself then uses the (ACTIVATE_POSITION) to do checks to see if their are enemy present in the area it is going to invade or not

Reason it is done this way is because ACTIVATE_POSITION is an OR clause (when you have multiples) and not an AND clause

##################

Separate note, also discovered another INVASION bug and this one I can't fix. AI will launch invasions against its own territory. Since we do not have a NOT_FRIENDLY command I just assumed that the EXE was knew that if a territory is already friendly controlled it would ignore the INVASION command.

Unfortunately my assumption was wrong. (Screenshot below)

If you have any idea around this one, all ears but this one pretty much puts this mod DOA as their is no way to teach the AI to invade. Yes I could add CANCEL_POSITION commands but the problem is what if their are no units on the island and it is friendly controlled. You then get a false hit and the AI will invade.

I know that you can do ALIGNMENT_POSITION under DECISIONS.txt BUT their are not enough decision event IDS to handle all the AI invasion commands and locations the AI can invade so its not really an option. Also since DECISION.txt does not appear to support TYPE= 2 when working with AI files that also stops that potential work around also.

* My suggestion to this issue is that an invasion script will not execute if the GOAL_POSITION is already friendly controlled.

[Hubert Cater]

As Bill mentioned a type=2 decision event is just not going to work for what you have in mind and for amphibious assaults, the problem is that once a GOAL_POSITION is friendly, the issue with cancelling it under that condition is that it would also cancel any amphibious plans that are still active, e.g. once let's say Cherbourg is captured, all D-Day units that have yet to arrive or yet to unload would cancel while in progress which is not ideal either.

Thus GOAL_POSITION is not considered and it is left up to the script writer to work around that.

You could take a look at the default D-Day scripts as a way to see how we've worked around the issues you've encountered.

For example, I have an end of 1942 prep date for D-Day, e.g. for the optional early 1943 D-Day landing, and if that one fails, I have another one for the end of 1943 prep date for D-Day for the regular 1944 D-Day landings.

Once the conditions are satisfied, everything just gets locked in, e.g. no matter what the conditions will or will not be after that.

Granted it does require you to write a few versions of the desired scripts, but that is the only way around this for now.

[Lothos]

As Bill mentioned a type=2 decision event is just not going to work for what you have in mind and for amphibious assaults, the problem is that once a GOAL_POSITION is friendly, the issue with cancelling it under that condition is that it would also cancel any amphibious plans that are still active, e.g. once let's say Cherbourg is captured, all D-Day units that have yet to arrive or yet to unload would cancel while in progress which is not ideal either.

Thus GOAL_POSITION is not considered and it is left up to the script writer to work around that.

You could take a look at the default D-Day scripts as a way to see how we've worked around the issues you've encountered.

For example, I have an end of 1942 prep date for D-Day, e.g. for the optional early 1943 D-Day landing, and if that one fails, I have another one for the end of 1943 prep date for D-Day for the regular 1944 D-Day landings.

Once the conditions are satisfied, everything just gets locked in, e.g. no matter what the conditions will or will not be after that.

Granted it does require you to write a few versions of the desired scripts, but that is the only way around this for now.

My suggestion on GOAL_POSITION is not to cancel a script once executed but not to allow it to fire if GOAL_POSITION for an amphib is a friendly controlled hex. Basically, all amphib commands that are not currently in the que should not execute if GOAL_POSITION is friendly.

Their really is no work around for this, I have gone over the D-Day invasion and it works because you are using CANCEL commands around Paris and if you detect any allied units to then cancel it. The bug still exists and if the allies moved all of their units into Germany and out of France you would then get USA and UK trying to do D-Day again even though they control France.

The other problem with how D-Day is coded and if done the same is it then requires every single island in the Pacific to be garrisoned for it to work! No human player would ever do that as they would run out of units.

[BillRunacre]

Part 1 - The script is multilayer I need to make sure that Japan has enough forces in Japan which is why the Decision Event (CONDITION_POSITION)
Part 2 - The AI script itself then uses the (ACTIVATE_POSITION) to do checks to see if their are enemy present in the area it is going to invade or not

Reason it is done this way is because ACTIVATE_POSITION is an OR clause (when you have multiples) and not an AND clause

Is this something that is only likely to be needed at a certain point in the game though, i.e. late 1941 or mid-1942?

If so then it might be that you could use TYPE= 3, having various so that if the date of the first one passes and doesn't fire because it's conditions aren't met, the second or third one might.

[Lothos]

Part 1 - The script is multilayer I need to make sure that Japan has enough forces in Japan which is why the Decision Event (CONDITION_POSITION)
Part 2 - The AI script itself then uses the (ACTIVATE_POSITION) to do checks to see if their are enemy present in the area it is going to invade or not

Reason it is done this way is because ACTIVATE_POSITION is an OR clause (when you have multiples) and not an AND clause

Is this something that is only likely to be needed at a certain point in the game though, i.e. late 1941 or mid-1942?

If so then it might be that you could use TYPE= 3, having various so that if the date of the first one passes and doesn't fire because it's conditions aren't met, the second or third one might.

No, it is a reoccurring check till the end of the game in case the Allies retake the Phillipienes. It is meant to help the AI handle a human doing things. If I hardcode it to a specific date then it would not be able to handle a human counter offensive taking territory back.

The more I learn about the game engine the more I realize the AI is not reactive to things (base game). It has hatdcode scripts for specific events but once those scripts are done running the AI will just sit their and do nothing in the Pacifix (this is in the official game). What youbarw seeing in this script is a very small piece at a much larger file to teach the AI how to be more reactive to a human player.

That is why I discovered the issue of the AI invading itself and type 2 not working with AI commands.

Majority of people play the game in single player. If we improve the AI overall it would increase the shelf life of the game.

[Hubert Cater]

I had to revisit and I believe the issue there still is mostly D-Day related or inspired for the current setup on our end.

For example, while ports such as Cherbourg and LeHavre could be captured and thus result in the cancelling via GOAL_POSITION, subsequent attacks on those positions via AMPHIBIOUS would not initiate, which while this is what you are after, turned out to be problematic.

e.g. the ports take some time to get back online and become usable, sizable Axis units could remain in the area, and the best way to ensure a successful D-Day would be to not have the GOAL_POSITION be a limiting factor, but rather I ended up leaving it to just the CANCEL_CONDITIONS instead.

Essentially, having follow up Amphibious assaults were more ideal, and more or less needed to ensure success.

Thus the tying things into Paris, as in, once the Allies got that far, it was safe enough to cancel the Amphibious plans, and ensuring no follow up Amphibious plans would be fired as long as I kept the applicable Allied unit in place there.

Granted this works well for the game as is, but not as ideal for what you are after unfortunately.

But unfortunately here again, any of the proposed changes would have an affect on the default campaigns in a negative way, and that is not something I'd want either.

Ideally an additional switch to say that GOAL_POSITION would determine whether an Amphibious plan fires would work, but that's not something I'd likely implement either any time soon.

[Lothos]

I had to revisit and I believe the issue there still is mostly D-Day related or inspired for the current setup on our end.

For example, while ports such as Cherbourg and LeHavre could be captured and thus result in the cancelling via GOAL_POSITION, subsequent attacks on those positions via AMPHIBIOUS would not initiate, which while this is what you are after, turned out to be problematic.

e.g. the ports take some time to get back online and become usable, sizable Axis units could remain in the area, and the best way to ensure a successful D-Day would be to not have the GOAL_POSITION be a limiting factor, but rather I ended up leaving it to just the CANCEL_CONDITIONS instead.

Essentially, having follow up Amphibious assaults were more ideal, and more or less needed to ensure success.

Thus the tying things into Paris, as in, once the Allies got that far, it was safe enough to cancel the Amphibious plans, and ensuring no follow up Amphibious plans would be fired as long as I kept the applicable Allied unit in place there.

Granted this works well for the game as is, but not as ideal for what you are after unfortunately.

But unfortunately here again, any of the proposed changes would have an affect on the default campaigns in a negative way, and that is not something I'd want either.

Ideally an additional switch to say that GOAL_POSITION would determine whether an Amphibious plan fires would work, but that's not something I'd likely implement either any time soon.

Thanks Hubert for your response and explanation. If I am reading this correctly you see the issue I am describing.

Does your response mean that in a future patch you can (assuming its not a lot of work) the additional check BEFORE starting an Amphib operation to make sure GOAL_POSITION is not friend controlled already? This change should have no effect on the current base game for Europe and World. If your answer is yes I can move forward with the work and add CANCEL commands for the time being that if a unit is present on the invasion hex to not invade, not a good solution because the AI will run out of troops fast but it will at least give me time to get the AI working in other areas and moving forward.

If you can do that it would solve 90% of the main issue, the TYPE=2 command is something nice to have but is not completely required.

[Hubert Cater]

It would solve your issue, however it is not something we currently plan to implement at the moment.

Apologies as it would require an extensive update to the entire Strategic Command system, e.g. all the campaigns across 4 games would have to have their campaign scripts updated etc., and the code updated to match.

Unfortunately it would not be on our priority list, just being honest here.

* * *

Just to clarify again, GOAL_POSITION check for Amphibious script plan validity is not something we would want for our end, as in we need this to work as it currently is for the current default campaigns.

What would be required would be an extra line in the scripts to opt for this to be either on or off, and that's just not something we are going to implement at this point as described above.

[Lothos]

It would solve your issue, however it is not something we currently plan to implement at the moment.

Apologies as it would require an extensive update to the entire Strategic Command system, e.g. all the campaigns across 4 games would have to have their campaign scripts updated etc., and the code updated to match.

Unfortunately it would not be on our priority list, just being honest here.

* * *

Just to clarify again, GOAL_POSITION check for Amphibious script plan validity is not something we would want for our end, as in we need this to work as it currently is for the current default campaigns.

What would be required would be an extra line in the scripts to opt for this to be either on or off, and that's just not something we are going to implement at this point as described above.

Hi Hubert

Again thanks for replying

I would disagree on the effect for your current scripts. It would not have an effect at all other than to not launch the invasion since the GOAL_POSITION (only for Amphib files) is already controlled by their side. Their is already Transport AI that would reinforce the troops in those areas (D-Day etc...). In fact the fix may solve some strange oddities people see from time to time.

For example in one of my simulations the AI sent over 15 units to Hainan because it kept trying to invade itself.

[Hubert Cater]

The problem is as mentioned that let's say LeHavre or Cherbourg are captured, there could still be Axis units in the area along the coast, and the ports take some time to come back online as they are usually damaged and cannot be used for rapid disembarkation until they are back to at least strength 5.

While I do have follow up transport plans in place as well that will take over once the optimal conditions are set for them, I found through testing that having a steady stream of amphibious units attacking and landing and pushing back Axis all units, despite the capture of the immediate GOAL_POSITION targets, until the Allies let's say get to Paris, worked better in my tests than not.

This is pretty much why it is implemented this way at least for the defaults campaigns.

Knowing this I also tailored the rest of my Amphibious plans so I wouldn't have the type of situation you've described with your campaign and with Hainan etc.

There is always give and take with any implementation, and for now since I had already spent so much time optimizing the existing default campaigns, and that I'm generally happy with them, I'm just not going to change things to possibly make things worse or to potentially require a lot of testing to make sure nothing is broken with a change like this, that we just don't have time for on our ends etc.

Again just being honest here and hopefully you can work around the current implementation for what it is you are hoping to achieve with your campaigns.

[BillRunacre]

No, it is a reoccurring check till the end of the game in case the Allies retake the Phillipienes. It is meant to help the AI handle a human doing things. If I hardcode it to a specific date then it would not be able to handle a human counter offensive taking territory back.

Hi Lothos

I've been thinking further about this and I wonder if simply having a dummy DECISION of TYPE= 3 firing once a quarter to check for the Philippines being in Allied hands AND there being a certain number of Axis units in Japan will work.

This would mean that a strong Japan (i.e. one with sufficient forces in the home country) could launch an attempt to retake the country, and while it might take longer than a script that checks per turn, it would not require a huge number of dummy DECISIONS: just 4 a year.

Going off at a tangent, you could even change it so that after the DECISION is triggered by the Allies occupying the Philippines, rather than it also checking for there being plenty of Japanese units in Japan, it could trigger the deployment of some to help with re-invading the Philippines.

Overall, I don't think the Axis AI has to necessarily take and hold every island in the Pacific in order to give a human player a challenge, and if there is some variety in which islands it attacks from game to game, enough to surprise players who have played it more than once, then it should keep them happy.

Bill

[Lothos]

No, it is a reoccurring check till the end of the game in case the Allies retake the Phillipienes. It is meant to help the AI handle a human doing things. If I hardcode it to a specific date then it would not be able to handle a human counter offensive taking territory back.

Hi Lothos

I've been thinking further about this and I wonder if simply having a dummy DECISION of TYPE= 3 firing once a quarter to check for the Philippines being in Allied hands AND there being a certain number of Axis units in Japan will work.

This would mean that a strong Japan (i.e. one with sufficient forces in the home country) could launch an attempt to retake the country, and while it might take longer than a script that checks per turn, it would not require a huge number of dummy DECISIONS: just 4 a year.

Going off at a tangent, you could even change it so that after the DECISION is triggered by the Allies occupying the Philippines, rather than it also checking for there being plenty of Japanese units in Japan, it could trigger the deployment of some to help with re-invading the Philippines.

Overall, I don't think the Axis AI has to necessarily take and hold every island in the Pacific in order to give a human player a challenge, and if there is some variety in which islands it attacks from game to game, enough to surprise players who have played it more than once, then it should keep them happy.

Bill

Hi BillRunacre

I am trying my best to figure out how best to handle this for the AI. First, I do want to say that I try and make an AI that will try and win the game and not just provide a challenge, that is my goal and always has been.

I did not consider TYPE=3 before but it would require multiple copies of the same invasion event because you can only have one LINK (which is fine but possible).

As for invading all the islands, its important for a Japan AI to lock down all the islands it can so that they can't be used as a base to re-supply Allied ships. The only option I can come up with is to have a Cancel Command for the AI if it is already garrisoned by a Japanese unit.

Another thing that dawned on me is how difficult it is to invade in a 1 vs 1 scenario (which is common in the Pacific War). I codded the Japanese AI to try and invade single hex islands with 3 units instead of 1 when an enemy is present. What dawned on me after is that once they take the island that only one invading unit can fit so what does the AI do with the other 2 AVL's?

I have not tried yet to use fleet commands to pull in all the AVL units in the Pacific back to Japan but my gut tells me that even if I did that it would not work because I have a feeling the AI won't unload the unit if its fleet AI command target hex was a port because it will treat it as a ship and not as an AVL that is lost with no target.

[Hubert Cater]

Hi Lothos,

If they are single hex islands and there is no cancellation of the plan once the hex island is taken, likely they'll remain active trying to still land on that hex for the duration of the game if it is a TYPE=2 plan.

If the plan is cancelled, or you use a TYPE=1 plan, transports that no longer have a plan will try and go to the nearest port and unload.

When this happens you'll see where this happens most often and you'll need to add some 'clean up' scripts to transport these units to preferable locations.

However, if it can't unload as there is only a single hex island with a port and the hex is already occupied, they may just stick around that island until a new TRANSPORT or AMPHIBIOUS plan is activated to draw them away, e.g. TRANSPORT or AMPHIBIOUS plans will look for existing transports or amphibs in range first before trying to grab land units.

FLEET plans will not work with TRANSPORTS or AMPHIBIOUS units.

Hubert

[Hubert Cater]

Another set of things you could try is to identify which plans can be indeed set to TYPE=1 so as to not have to worry about repetitive invasions of the same islands, e.g. just a one and done if possible.

Perhaps use the CANCEL_CONDITION tied to the GOAL_POSITION for whenever a friendly unit is located on that hex, but in this case use a free AI UNIT, e.g. a Garrison dropped in there via UNIT script event once the island is taken.

This might get tricky with one island hexes, maybe a check for friendly but now empty and it drops in a GARRISON unit which would still prevent a follow up AMPHIBIOUS plan from firing, or a 2 hex island (at least) may make things easier to manage once the island just has one unit there, e.g. drop the Garrison then and they should swap out with the right GUARD script setting.

Those island will likely need ports to make it all work as well.

Just some more ideas to hopefully help,
Hubert

[Lothos]

Hi Lothos,

If they are single hex islands and there is no cancellation of the plan once the hex island is taken, likely they'll remain active trying to still land on that hex for the duration of the game if it is a TYPE=2 plan.

If the plan is cancelled, or you use a TYPE=1 plan, transports that no longer have a plan will try and go to the nearest port and unload.

When this happens you'll see where this happens most often and you'll need to add some 'clean up' scripts to transport these units to preferable locations.

However, if it can't unload as there is only a single hex island with a port and the hex is already occupied, they may just stick around that island until a new TRANSPORT or AMPHIBIOUS plan is activated to draw them away, e.g. TRANSPORT or AMPHIBIOUS plans will look for existing transports or amphibs in range first before trying to grab land units.

FLEET plans will not work with TRANSPORTS or AMPHIBIOUS units.

Hubert

Not sure that the AI grabing AVL's that have no orders is actually working. I've seen an AVL near the island of Truk sit their and do nothing even though invasion orders keep coming to pull units from Japan.

I guess the first question is how does this additional check you are describing work? For an invasion the first Friend Position has to be a land hex with a range so the AI will pull units for the invasion but how does that work for land units at sea on an AVL. What range does it use and from what point does it start that range from?

If fleet commands do not work on Transports and Amphibs then the bigger question is what happens if the Amphib or transport is out in the middle of no where near an island. It is then lost their for the remainder of the game?

FYI, for lost unit scripts if you look at both TRP Europe and World their is an enormous section under the Transport AI called Lost Units and that is the goal is to pull in all lost land units to the main center point (UK for the Allies) so they can then get new orders. I call it the center out approach, so I try and pull lost stuff back into the center, but clearly this wont work for lost transports or lost AVLs.

[Lothos]

Another set of things you could try is to identify which plans can be indeed set to TYPE=1 so as to not have to worry about repetitive invasions of the same islands, e.g. just a one and done if possible.

Perhaps use the CANCEL_CONDITION tied to the GOAL_POSITION for whenever a friendly unit is located on that hex, but in this case use a free AI UNIT, e.g. a Garrison dropped in there via UNIT script event once the island is taken.

This might get tricky with one island hexes, maybe a check for friendly but now empty and it drops in a GARRISON unit which would still prevent a follow up AMPHIBIOUS plan from firing, or a 2 hex island (at least) may make things easier to manage once the island just has one unit there, e.g. drop the Garrison then and they should swap out with the right GUARD script setting.

Those island will likely need ports to make it all work as well.

Just some more ideas to hopefully help,
Hubert

Having a decision to drop the garrison unit in the hex and then move the unit that invaded back to Japan would work. I just hate having the AI cheat, however that solves allot of the problem. The one thing is how to make the decision that would do this fire for only an AI Japan. I guess it would be AI=1 so it fires for an Axis AI in single player games but I guess it would not fire if it is a single player game but the human player is playing Germany only or do I need AI=3?

Wish their was an AI parameter that says if the COUNTRY_ID the event is tied to is AI controlled then fire and not have the AI tied to a specific side.

[Hubert Cater]

A) What the AI will do is if the Ampibious or Transport plan is without waypoints, it will look for available units amphbs or transports without plans within range of the desired coastal landing position. The range is within the range of the maximum distance of any naval unit associated with that particular country. It is a general calculation to assign a reasonable range to consider.

This is typically a shorter range plan, e.g. like D-Day, or like like the ones for the default 1943 campaign that has the AI already with Amphbious Transports at sea for the Allies at the start of the campaign to invade Sicily from North Africa.

B) If the Amphibious or Transport plan has waypoints, this is typically a longer range plan, the AI will look for any available Amphibs or Transports within the same range as described/calculated in A) but from the first FRIENDLY_POSITION, and yes it will scan outwards towards the sea from that position even though it is a land position.

* * *

The reason for the difference between how a longer range plan and a shorter range plan is handled when it comes to abandoned transports is that an amphibious plan will not unload until 50% of transports are in range of coastal position, and from testing it was found that to collect abandoned transports near the original FRIENDLY_POSITION, presumably where more friendly transports will join, just worked out better overall.

[Hubert Cater]

Having a decision to drop the garrison unit in the hex and then move the unit that invaded back to Japan would work. I just hate having the AI cheat, however that solves allot of the problem. The one thing is how to make the decision that would do this fire for only an AI Japan. I guess it would be AI=1 so it fires for an Axis AI in single player games but I guess it would not fire if it is a single player game but the human player is playing Germany only or do I need AI=3?

Wish their was an AI parameter that says if the COUNTRY_ID the event is tied to is AI controlled then fire and not have the AI tied to a specific side.

AI=1 will work as it will only be for AI games and for the Axis AI. AI=3 would be if you wanted it for AI and multiplayer games, which is what you do not want, but I would suggest AI=5 as that will cover the Axis AI no matter if it is your opponent AI and for those times that players will have Japan on their side but wish to have it controlled by the AI. This way the friendly controlled AI will work the same way.