With #145, paths sent in moves got a lot bigger when moving long distances. Moving e.g. across the entire map could result in a list of waypoints that exceeds the value-size-limit in Xaya. This change replaces the value passed to wp in a move with an encoded string (which is the previous array serialised as string, compressed and base64-encoded). Moves across the map that previously would have taken 3.5 KiB now need less than 700 bytes in encoded form (which is good enough for the 2 KiB size limit).
The first impact this has is that now the findpath method returns an additional output, encoded. This is the encoded string corresponding to the returned waypoints in wp.
Secondly, the wp field in a character update move now needs to be passed a string of the right form (i.e. returned by findpath) instead of a plain JSON array of waypoints. It can also be set explicitly to JSON null, which corresponds to an empty set of waypoints, e.g. for stopping movement or mining.
With #145, paths sent in moves got a lot bigger when moving long distances. Moving e.g. across the entire map could result in a list of waypoints that exceeds the value-size-limit in Xaya. This change replaces the value passed to
wpin a move with an encoded string (which is the previous array serialised as string, compressed and base64-encoded). Moves across the map that previously would have taken 3.5 KiB now need less than 700 bytes in encoded form (which is good enough for the 2 KiB size limit).The first impact this has is that now the
findpathmethod returns an additional output,encoded. This is the encoded string corresponding to the returned waypoints inwp.Secondly, the
wpfield in a character update move now needs to be passed a string of the right form (i.e. returned byfindpath) instead of a plain JSON array of waypoints. It can also be set explicitly to JSONnull, which corresponds to an empty set of waypoints, e.g. for stopping movement or mining.