Major problem with the path code

[Stan Shebs]

Hans Ronne wrote:

>
>>The pathfinding is now implemented as part of the action code, and that
>>is wrong, it should be part of the player code, because the path that
>>is found is only ever hypothetical. Also it ie expensive, so should not
>>be replicated on all computers in a networked game. So have pathfinding
>>called from task.c, but not move.c.
>>
>>This would require that move tasks be private to each player, and not
>>broadcast over the network. So the logical thing to do is to stop
>>broadcasting all tasks, only actions, and for each game loop to only
>>process local ai players. Also the shared state should not include
>>tasks or plans. Plans should be private, it should be irrelevant to the
>>referee code what the plan for each unit should be, only what its
>>actions are.
>>
>
>I agree. I discussed this with Stan a long time ago. I remember that he had
>some good arguments why plans and tasks also should be broadcasted, but I
>am not sure to what extent they still apply today. They might have had to
>do with performance, which is not an issue any longer. I will have to do
>some email archeology to find out. Or maybe Stan can comment on this?
>
OK, I've been trolled - or more accurately, had the lure bobbed up and down
in my face. :-)

All I remember ("my mind is going, I can feel it") is that if a task had to
broadcast all the actions it generated, it seemed like it would be a lot of
extra traffic for slow connections. The more synchronized state you have,
the more you can do locally. I also wasn't expecting to support much 
per-peer
variability at the plan/task level, because those are made at least partly
visible to the UI, and it would be good to have at least a modicum of
consistency by wiring it into the kernel.

These don't seem like really strong arguments though; I suspect everything
could be made to work OK with local plans and tasks.

Stan