<URL: http://bugs.freeciv.org/Ticket/Display.html?id=18010 >
I lost the half of the message...
> [wsimpson - Mar. Aoû. 21 23:06:55 2007]:
> 1) The tiles array is uninitialized; its state is indicated by is_init.
> Would make more sense to have initially NULL. Would also make more
> sense to use fc_calloc, instead of whole_map_iterate() setting zero.
> (It seems horribly wasteful to have such a large array, one for every
> possible tile and direction, but that's for another time.)
What tiles array?
> 3) Each unit is saved in the map by id, and converted back to a pointer.
> Would make more sense to save the pointer in the first place. Is
> this a workaround for units that are destroyed during goto selection?
I don't think so. If one of your unit get killed when you are selecting
a new destination, it would crash... Or need to remove the pointer when
the client receive the packet_unit_remove.
> 4) As already discovered, is_goto_valid seems to be based on the final
> unit in the goto_map_iterate() list. It doesn't work, as some units
> can be valid, and others invalid.
Yes, it's what one of the things I tried to fix...
> 5) In addition, connect_initial is also based on the final unit in the
> goto_map_iterate() list. It seems that the value saved in each path
> is based on the previous unit(s). Makes no sense.
Patrol too. It's really make no sense. This problem could be fixed in
draw_line, where all update functions pass.
> 6) The parameter of is_valid_goto_destination(ptile) is unused. Clear
> evidence of partial implementation.
> 8) There are "waypoints" that cannot possibly work for battlegroups that
> are not already in the same stack. Moreover, there is no method for
> communicating waypoints to the server. Such waypoints could become
> obsolete as roads are connected during the following turns.
I don't think so. The server doesn't rearrange the path that the client
> 9) The code seems to contemplate multiple paths drawn simultaneously,
> but doesn't work correctly.
I totally agree...
Freeciv-dev mailing list