Re: [Civil-devel]Handling unit orders

[Marcus A. <maa...@ra...>]

Jan Ekholm wrote:

>>Hi, sorry I haven't been able to do anything at all for ages. I
>>just finished my submission for the UML 2004 conference, so it'll be
>>interesting to take a short brake and see what you've been up to.
> Congratulations. Do you get to go to the conference too?

Well, at least if it gets accepted. But the competition is hard, last 
year ~150 submissions and 30 accepted. I'm also organising a "doctoral 
symposium" for PhD students there. It'll be my ticket to the conference 
if my paper doesn't get accepted :-D

> One thing that needs to get solved however is how the clients know what
> plans to visualize. Imagine that a player gives a few movement orders to a
> unit, followed by a wait and then something else. Right now the plans are
> just sent to the server/engine for handling and the engine adds them to
> the list of plans for the unit in its internal copy of the units. The
> clients then receive action when the unit starts to execute the orders.
> The clients have no knowledge of the plans that have been sent off, no way
> to cancel them etc.
> 
> I see two ways to fix that:
> 
> 1. the engine always sends back plans that it acknowledges as ok and will
> start simulating in due time. This is simple, correct but introduces a
> delay between when the player gives the order until it is visualized
> graphically. Will be annoying, I think.
> 
> 2. let the client immediately store the given plans in the affected unit
> and immediately visualize it. The plan is also sent to the server which
> can then acknowledge it and send back something like "the plan is ok" or
> "the plan is not ok". The first case would be the normal, but the latter
> *will* happen some time. I can't think of actual cases right now, but I'm
> sure there will be.
> 

Hm. Option 1 is not very nice, and it's trying to be just a bit too 
simple/clever in avoiding the issue. I think we must handle the hard 
case as well, at some point.

 From another post:

 > I did a small fix that now simply adds plans to the units that issue
 > them. They are also sent to the server for manipulation and 
execution, > but the clients at leats get to visualize them immediately.

 > There still needs to be some added id or similar for the plans, so
 > that the server can say the client which plans are not acceptable and 
 > which must be removed. Should be no biggie if it is really needed.

What I'd say is the main point is that the rest of the _client_ system 
issuing plans and such is not aware of how this problem is solved. The 
client's actions should just be "add this order", "remove this", "can I 
add this order here?", and it needs to be able to ask "what's my current 
state/position and my next plans?" so it knows how to visualize them. 
But it definitely should not have to care "is plan X yet accepted?". 
That's handled by the some separate small client connection to the 
server. If the above idea of "plan id:s" is the way to go, good.

Comments?