Matrix Games Forums

Often, when you order a TF to meet another TF, it will instead move in formation with the other TF. The uploaded file (Archive.zip) gives an example of this. TF 9 is supposed to meet TF 13, but instead leads it by two hexes. I'm trying to have the small ASW TF attach itself to the transport TF and protect it as it travels through the Coral Sea, but that is not happening.

I suspect I have some insight into the technical issues. This is one of the hard problems in AI--animals seem to solve the tracking and interception problem in a way engineers haven't been able to figure out. We have evidence that rats and bats maintain a multi-dimensional space-time representation of their local volume. They might solve the interception problem by learning trajectories in space-time and overlaying the current data with the best approximation from the learned library. They do this for the moving object of interest and then bounce it against a collection of own trajectories to maximise or minimise the approach distance.

For the game, I don't think the problem can be solved without allowing the two TFs to coordinate. The meeter would query the meetee for its course and then propose a waypoint. If the meetee is not able to be at the waypoint at the planned time, it would propose an alternative waypoint, and this process would continue until convergence. Multiple meeters would be handled closest meeter first.

See if there's a literature on this problem.

The meeting code includes a sense of the relative position of the meeting TF, the met TF, and the destination of the met TF.

If the meeting TF is closer to the destination of the met TF than the met TF, the meeting TF will plot an intercept course somewhere along the met TF's path to the destination. The meeting TF will not normally move away from the destination as it would then just have to move back.

In the circumstance in your saves, the meeting TF is indeed closer to Milne Bay. It tries to intercept enroute but it's relative position, the speeds of the TFs, and closeness to Milne Bay make it difficult. The TFs enter Milne Bay independently - meeting TF first.

I understand that the intent was to have the meeting well south of Milne Bay. However the code as written is optimized the other way. Changing it to direct path merging creates as many problems as it solves especially if the two TFs are not so close to the destination.

We are looking at a possible refinement to the meeting path calculation but it will not be done by Patch 1.

Also, in tracing the circumstances a bug did pop out. The meet/merge logic is triggered by the meeting TF entering the hex containing the met TF. However, if the meeting TF reaches the destination first it is the met TF that enters the hex containing the meeting TF - and the merge logic is not triggered. We'll fix it so that merge will occur in this circumstance as well.

ORIGINAL: Don Bowen


The meeting code includes a sense of the relative position of the meeting TF, the met TF, and the destination of the met TF.

If the meeting TF is closer to the destination of the met TF than the met TF, the meeting TF will plot an intercept course somewhere along the met TF's path to the destination. The meeting TF will not normally move away from the destination as it would then just have to move back.

In the circumstance in your saves, the meeting TF is indeed closer to Milne Bay. It tries to intercept enroute but it's relative position, the speeds of the TFs, and closeness to Milne Bay make it difficult. The TFs enter Milne Bay independently - meeting TF first.

In a play-through of the Aleutians Campaign from the Japanese side, I sent a replenishment TF out ahead of the CVTF with orders to intercept the CVTF to refuel it. The replenishment TF maintained a 4-hex lead on the CVTF all the way into Dutch Harbor (the eventual target of the CV airstrikes). I think this is an example of your bug.

I understand that the intent was to have the meeting well south of Milne Bay. However the code as written is optimized the other way. Changing it to direct path merging creates as many problems as it solves especially if the two TFs are not so close to the destination.

We are looking at a possible refinement to the meeting path calculation but it will not be done by Patch 1.

Also, in tracing the circumstances a bug did pop out. The meet/merge logic is triggered by the meeting TF entering the hex containing the met TF. However, if the meeting TF reaches the destination first it is the met TF that enters the hex containing the meeting TF - and the merge logic is not triggered. We'll fix it so that merge will occur in this circumstance as well.

Refueling should also take place. As noted above, the bug occurs then as well.

Yes, programming a solution is difficult--you're dealing with an unsolved problem in AI. After I finished my PhD, I worked on it for four years, and I had a PhD student working on it for three, and neither of us found a really good solution. Animals seem to solve it by learning a library of intercept paths that they can produce. They then choose the one that comes closest to the target path. How that's done in a brain is not very clear--it seems to use cell assemblies. There's evidence the process exploits chaos to converge exponentially fast. That's grant proposal #2 in my current list.

Here's how I'd program it, given that I'm not trying to match vectors but only position.

Take the TF to be followed and the following TF. Start by estimating when the followed TF is likely to be in each hex of its current journey leg given its current movement orders. Then estimate the earliest the following TF can be in each hex given its current movement orders. Go to the first hex the following TF can reach before the followed TF enters it. Wait there. If there is no such hex, slow the followed TF by a knot and retry. If the followed TF drops to 0 knots, reset to its nominal speed, set the following TF to stationary (or return to home port), and post an alert to the operations report.

Run this algorithm at the time the follow order is first proposed, and during each movement phase thereafter. If the hex changes, move to the new hex.

The problem is much harder in three dimensions.

I've continued the Guadalcanal campaign, and now that I'm looking for it, the meet/follow/refuel bug is a good deal more prevalent than I had thought. It also makes for serious problems coordinating multiple TFs. It seems to be the consistent explanation for some of the goofier things I've seen the game engine do, both in AE and back when I was playing stock campaigns.