Follow-up Comment #8, patch #5729 (project freeciv):
_Old code discarded such moves user didn't mean, does the new code handle
that?_
handle_unit_orders() will abort if the order's source tile and the unit's tile
aren't the same. (unithand.c line 2877)
Follow-up Comment #7, patch #5729 (project freeciv):
Occurred to me only now:
Does this cause an regression when the client is out-of-sync? With lagging
connection it's not rare that when one quickly moves units two steps, client
actually has not got the correct location of the unit after the
Update of patch #5729 (project freeciv):
Status: Ready For Test = Done
Open/Closed:Open = Closed
___
Reply to this item at:
Update of patch #5729 (project freeciv):
Status: Need Info = Ready For Test
___
Reply to this item at:
http://gna.org/patch/?5729
___
Message sent
Follow-up Comment #4, patch #5729 (project freeciv):
Oh, right. It's used only from client to server and not to the other
direction. Sorry for the noise.
One wonders how much it would help if there *was* a specialized packet (unit
id + tile id + facing direction + moves left) for the most common
Follow-up Comment #2, patch #5729 (project freeciv):
See patch #4804 for another (unimplemented) idea about changing the UNIT_MOVE
packet.
___
Reply to this item at:
http://gna.org/patch/?5729
Update of patch #5729 (project freeciv):
Status: Ready For Test = Need Info
___
Follow-up Comment #3:
_How this affects bandwidth usage?_
Each keypad move becomes about 3 times as large. (The
URL:
http://gna.org/patch/?5729
Summary: Protocol: Get rid of the unit_move packet.
Project: Freeciv
Submitted by: sveinung
Submitted on: Mon 19 Jan 2015 03:54:37 PM UTC
Category: general
Priority: 5 -
Follow-up Comment #1, patch #5729 (project freeciv):
How this affects bandwidth usage? You replace one of the most often sent
packages with a lot bigger one.
___
Reply to this item at:
http://gna.org/patch/?5729
