Re: plan_transport

[Hans Ronne <hronne at comhem dot se>]

>> To that I would add that AI-controlled occupants do not disembark when they
>> should. This was a problem also with the old code, but it seems worse now.
>
>I did have some problems with the test/transport.g game, but it is
>addressed now. The ferry drops each unit off at its requested position.

Excellent.

>> A player-settable TRANSPORT_TASK might be a good idea. But it would work
>> only for one ferry round. It would be even better to be able to set a
>> PLAN_TRANSPORT and let ferries run on automatic. However, this would
>> require a semi-automatic mode where it is possible to set (and keep) plans
>> also for player-controlled units. I experimented with this two years ago,
>> and I think it was discussed on the list. It would also make it possible to
>> assign PLAN_OFFENSIVE or PLAN_DEFENSIVE to units and then have the AI run
>> them according to a set plan (right now, the AI will replan as soon as you
>> turn over a unit to it, so setting plans has no effect even if it can be
>> done). Something to consider post-7.5, I think.
>
>In the current setup the human controlled units have PLAN_PASSIVE.
>But tasks can be assigned to units. So I thought it would be better to
>keep this structure if possible for now, so the "helper ai" is
>implemented as a task.

Exactly. That was my point. There has been a lot of confusion on this list
about plans and what happens if you set them for a human-controlled unit. I
therfore wanted to clarify this point.

>On a side note, having PLAN_OFFENSIVE and PLAN_DEFENSIVE is a bit
>artificial, and it is easy to imagine different AI setups. The most
>defensive of modern weapons is probably a fighter aircraft, because it
>operates only out of a fixed base, while the most offensive weapons are
>aircraft carriers and troop carriers, because they can project.

The difference between PLAN_OFFENSIVE and PLAN_DEFENSIVE is not that big
with respect to combat since the action-reaction code will handle combat in
both cases. The main difference is rather if the unit tries to go somewhere
(PLAN_OFFENSIVE) or stays where it is (PLAN_DEFENSIVE). Making this kind of
strategic assignment is, however, frequently what the human player would
like to do.

>> This one is easy. We would just need to define a precomputed u_ferry_worth
>> that measures ferry capacity and weighs it into mplayer_decide_plan.
>> Similarly for the build code. There is already basic_transport_worth but it
>> is rather crude. I would like something better.
>
>It is fairly complex actually. Need to account for aircraft carriers
>which are quite offensive, but which shouldnt really have much
>hit-pointage in themselves, bireme/trireme which take units to help them
>fight, transports and barges which enable land units to be seaborne, and
>cargo planes that take paratroopers. It would be nice to have the ai put
>together complete invasion packages with carriers, troop transports, and
>protection units like destroyers, battleships and minesweepers.

Writing a good u_ferry_worth can certainly be rather complicated. My point
was that the problem is easily dealt with in principle.

>However for the present it is easier to assign transports to
>PLAN_TRANSPORT based on the existing arrangement. The existing code has
>a tendency to assign ferries to offensive duties which is inappropriate.
>So it a ferry or cargo plane stays in PLAN_TRANSPORT rather than
>attacking something it would be better.

Precisely.

>Another note. These worths are a number starting at 0 and extending
>upwards. If they were scaled from 0 to say 100, then we could carry out
>fuzzy logic calculations, with fuzzy AND as a MIN operation, fuzzy OR as
>a MAX operation, and fuzzy NOT as a (100 -x) operation. Might help the
>AI think better.

The main reason why the worth function return relative (and open-ended)
rather than absolute values is generality. It is very difficult to get
worth functions that return absolute values to work with many different
games that have very different units. You could let the game designer
assign appropriate absolute values in each game, but then we are back in a
situation where the game designer rather than the AI is playing the AI
side, as discussed above.

We could take another look at this post-7.5, though. I'm not very happy
with the current worth functions.

Hans