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