Complete.Org: Mailing Lists: Archives: freeciv-dev: December 1998:
negative research points, was Re: [Freeciv-Dev] Some remarks (bugs?)...
Home

negative research points, was Re: [Freeciv-Dev] Some remarks (bugs?)...

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: negative research points, was Re: [Freeciv-Dev] Some remarks (bugs?)...
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Sat, 5 Dec 1998 13:03:29 +1100

Rizos Sakellariou wrote:
> 
> I wonder whether it is sensible to allow a player ending up with 
> negative points in the technology being researched. This may occur 
> when a penalty due to diplomacy/free_tech/conquest_of_city is subtracted 
> from the player's current research points (the functions currently 
> existing in plrhand.c do not check if the resulting quantity ends up 
> being negative). In fact, i played a game where this negative quantity 
> increased so quickly (due to continuous treaties) that an overflow 
> apparently occurred and this number ended up as a high positive number 
> in the science report!

Actually, I think part of the problem here is that player.researched 
(the amount of research done so far) is sent as a 16 bit quantity, so it 
probably didn't (and couldn't) underflow on the server (freeciv 
assumes 32 bit ints, in various places, I believe), but the value
received by the client wrapped around.

(I agree with Reinier that negative research points make good
sense if diplcost (et al) are non-zero.)

(player.researchpoints, the research target, is also sent with 16 bits, 
which could be a problem is high enough values of researchspeed are used.)

I'm not sure of the best way to change these 16 bits values to 32
bits in packets in a backwardly compatable way.  We could use 
capabilities, (which involves some CPU hit each time we make/receive 
a packet and test the capabilities?) or we could just add the 32 bit 
values at the end of the packet (as well as the 16 bit values already 
in the packet) and only recent enough clients will take any notice of 
the extra values (this increases the packet size somewhat more than 
necessary).  Or we can just leave it be for now.
Of course when we break protocol compatability (planned for 1.8) 
we could tidy this up.

-- David


[Prev in Thread] Current Thread [Next in Thread]