[Freeciv-Dev] Re: negative research points

[David Pfitzner <dwp@xxxxxxxxxxxxxx>]

Mitch Davis wrote:
> 
> David Pfitzner wrote:

[changing player.researched from 16 to 32 bits in packet]
[using capabilities]
> 
> I don't think it will be a noticable hit.  If profiling reveals
> that checking every time is a problem, then we could have a boolean
> (set from the capabilities on (re)load and (re)connect
> which indicated if the other side wanted 16 or 32 bits.
> I think it's unlikely that capabilities will change during
> a game, unless there's a reconnect or a reload, so the bool
> could be set then.

Agreed.

> > Or we can just leave it be for now.
> 
> I think we should leave it for now unless someone wants to
> look at it.  If they do, I think it should be done with
> capabilities, rather than extra fields.  (What will a new
> client or server do if the other side isn't sending the
> extra 32 bits?  It needs to test capabilities anyway..)

I think in principle in could be done without capabilities, 
because extra stuff on the end of packets is ignored (so older
clients are not bothered), and newer clients can check the
packet length to see if there is extra stuff there (ie, is
the server also newer).

Another possibility I thought of is that if values would 
under/overflow when converted to 16 bits, set the 16 bit
values to flag values (max/min representable), and only then
put the 32 bits values at the end.  Older clients get
the flag values (which are best approximation to correctness
using 16 bits), and newer clients can use the flag values
to notice the 32 bit values.  This avoids making the packet
bigger except when it needs to be.

But despite coming up with these ideas, really I think this is 
all unnecessarily complicated given that its not a very serious 
problem (and won't occur except in unusual cases, especially now 
that diplcost defaults to zero), so actually I think we should 
leave it be for 1.7.2, and perhaps after that change it, probably 
simply using capabilities...
 
> > Of course when we break protocol compatability (planned for 1.8)
> > we could tidy this up.
> 
> Yeah, by changing the packet.  We could put a /* FIXME */ in
> the code, as I generally look for them before a release.

Yep.

-- David