Re: network improvements

[Hans Ronne <hronne at pp dot sbbs dot se>]

>> It seems that some kind of command filter is still needed here, but
>> I'm not sure that the current client-side filter in advance_into_cell
>> (which only stops some double-clicks) is the best solution. Perhaps we
>> can just let the host ignore invalid commands instead.
>
>I can't help but think that something host-side would be the better
>solution.  Maybe some kind of "recently killed" list if ignoring all
>attacks on dead units is too drastic?  Maybe there is a simpler
>or more elegant solution, but I'm not thinking of it right away.

What I would like to see is something that also catches other manual
commands to dead units, not just overrun actions. This means that the
filter would have to be further down in the network code, if on the client
side. The more I think about this, the more I think that the best option
may be to limit broadcasted actions to exactly one per unit and run_game
execution. Thus, we might have a unit->acted flag that is set by
broadcast_action and reset by run_game. There are several merits to this
scheme:

1. It would filter out all double-clicks whether overrun actions or not.

2. It would still let through the kernel bugs that we want to catch. They
are caused by iterating over dead units, which has nothing to do with
double-clicks.

3. It may actually speed up the game. It seemed to me when we were testing
the intro game, that clicking rapidly on the same unit would delay things.
Not sure about this, but perhaps the extra network load does make a
difference.

4. It is less clunky than the double-click block (not to mention a
"recently dead" list). No arbitrary time delays. Just a flag that is reset
on a perfectly regular basis.

The key question is if there is any situation where more than one action
per unit and run_game execution should be allowed. I think probably not. In
fact, the run_game executions are limited to exactly one action per run for
all units. It is possible to pass a larger number of actions in the
maxactions argument, but it is not currently used.

The only effect of limiting the number of actions that can be broadcasted
to one per unit and run_game execution is that it would prevent the single
action that is executed from being changed a number of times before
execution. In the human case, it would render a second click (whether in
the same or a different cell) ineffective. This might prevent you from
changing your mind at the last moment, but considering how often run_game
is executed, I doubt that it would matter at all. In the AI case, such a
filter might actually prevent some buzzing, or at least help us to detect
it, which is also good.

Hans

Hans Ronne

hronne@pp.sbbs.se