Follow-up Comment #6, bug #21096 (project freeciv):
For S2_4 client:
pplayer->wonders[i] = pinfo->wonders[i];
if (!has_capability("wonder_city_id", client.conn.capability)) {
pplayer->wonders[i] = pinfo->wonders_new[i];
} else {
pplayer->wonders[i] = pinfo->wonders[i];
}
Am I totally misreading this, or is the sense of the capability test inverted,
such that this always uses the wrong member of packet_player_info?
(Which I think means that it'll always end up 0 == WONDER_NOT_BUILT.)
Also, the first assignment to pplayer->wonders[i] looks redundant (but doesn't
save the day).
I was unable to spot any obvious trouble on a quick look with a S2_4 savegame,
though.
Apart from the server warning (which isn't on S2_4), I'm guessing that the
most likely impact of the original bug -- depending on what happens when the
server does htons(-1) -- was that the client thinks any lost wonders are in
city ID 65535, which most likely doesn't exist. I can't see many knock-on
consequences from that -- in particular, I think city_from_wonder() happens to
do the right thing. Might affect some client inferences about what should be
grayed out in menus etc? Maybe affects small wonders more (cf multiplayer
ruleset)?
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?21096>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
