Page 1 of 1

Fleet AI Primary Key bug

Posted: Thu Jun 16, 2022 10:35 am
by Lothos
Found something interesting

The Primary Key for fleet.txt is the COUNTRY_ID and the first GOAL_POSITION

If two events fire with the same IDs then both get ignored. I did this test with the German starting ships and ran into this issue as I was trying to move the Deutschland and the Sub next to it back to Germany.

Would suggest a change to the primary key so that you can have multiple points hit the same GOAL_POSITION

Would suggest changing it to

COUNTRY_ID
UNIT_ID
first GOAL_POSITION
first FRIENDLY_POSITION

This would then allow you to (for example) tell the AI to move ships from Egypt back to the UK and at the same time tell them to move ships from Canada to the same exact spot in the UK.

Sure their is a work around by choosing one hex over as a GOAL_POSITION but this creates a situation where you have only a certain amount of events you can code to area. With the change it then becomes unlimited.

Adding UNIT_ID will let you have events with the same start and end point for specific ships. So you can tell the USA AI to move all its CARRIERS and LIGHT CARRIERS from the Atlantic to the Pacific and have them go to the same points

OR

You can support more than one UNIT_ID in an event.

Re: Fleet AI Primary Key bug

Posted: Fri Jun 17, 2022 2:15 pm
by Hubert Cater
I'm surprised that having two plans with the same GOAL_POSITION resulted in both being ignored, it should if I remember correctly just read in and execute the first plan, ignoring the second one.

It's an interesting idea to have a larger key, but any change would apply to most if not all plans and I'd have to look into it. It wouldn't be at the top of my list of things to do, but I can at least add it for consideration.

Re: Fleet AI Primary Key bug

Posted: Fri Jun 17, 2022 2:31 pm
by Lothos
Hubert Cater wrote: Fri Jun 17, 2022 2:15 pm I'm surprised that having two plans with the same GOAL_POSITION resulted in both being ignored, it should if I remember correctly just read in and execute the first plan, ignoring the second one.

It's an interesting idea to have a larger key, but any change would apply to most if not all plans and I'd have to look into it. It wouldn't be at the top of my list of things to do, but I can at least add it for consideration.
It should have no effect on existing events, all of those fields are required already.

Developer myself (30 years) and work with Oracle and SQL Server every day so I have an understanding on how Keys works. The danger you are concerned about can only happen if you take keys away (which is not the case here) or the fields you are adding can be null (which is also not the case as all those fields are required).