-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid IDs as JSON object keys in move format #178
Conversation
This changes the format for building updates: Instead of using a JSON object keyed by the building IDs as strings, we just use a single JSON object or an array of objects for the individual operations, and set the building ID inside each operation: {"b": {"id": 42, "sf": 50}} {"b": [{"id": 1, "sf": 50}, {"id": 2, "sf": 10}]} This makes the format and in particular the processing order more straight-forward and simple. In theory it also allows now to do multiple updates to a single building in one move. This is a first step for a bigger set of changes. The main change (and with higher impact) will be doing the same thing also for characters and group-updates.
Change the format of godmode sethp and teleport to avoid JSON objects keyed by stringified IDs, and instead just use JSON arrays with object entries. This avoids the need to explicitly parse an ID from a JSON string, and it also removes any doubt about the order in which the commands might be processed. The new format for teleport is this: {"god": {"teleport": [{"id": 42, "pos": {"x": 1, "y": 2}}, ...]}} The new format for sethp (buildings and characters) is: {"god": {"sethp": {"c": [{"id": 42, "a": 5, ...}, ...], "b": [...]}}}
This changes the move format for character updates: Instead of a JSON object that is keyed by stringified character IDs, we have a JSON array of individual updates (or just a JSON object for a single update). Each entry is a JSON object which explicitly specifies the ID as a single integer or array of integers (for batched updates). With this form, the order in which the changes are done is more explicit, and can also be chosen freely by the user. In fact, it is even possible to do changes to a single character multiple times, in a particular order and relative to other character changes. This will allow better control for convoy moves, for instance. The new format is like this: {"c": [{"id": 42, ...}, {"id": [10, 20], ...}, ...]} {"c": {"id": 1, ...}}
The two functions were used to handle stringified IDs in moves (as part of JSON object keys). But since the move format has been changed to never have those, there is no need to keep them around anymore.
This implements a new type of move, which will *add to* existing waypoints of a character: {"c": {"id": 1, "wpx": "..."}} The format of "wpx" is an encoded list of waypoints, as for normal "wp" moves. The move is valid only if the character has already some waypoints set, i.e. is already moving. In this case, all waypoints from the new "wpx" list will be added at the end of the current list of waypoints. This is mostly useful for efficient convoy movements: For them, we want a set of characters to move along the same path; but since they are likely on different initial positions, we first need individual paths for all of them to some shared first waypoint. After that, we want to add the rest of the path for all of them at once. This can be done with a move like this: { "c": [ {"id": 1, "wp": "from position 1 to some shared coordinate"}, {"id": 2, "wp": "from position 2 to some shared coordinate"}, {"id": 3, "wp": "from position 3 to some shared coordinate"}, {"id": [1, 2, 3], "wpx": "long path from that coordinate to target"} ] }
Split out the findpath integration testing with explicit character data into its own function in the test, so that it is easier to maintain and extend with more things (e.g. changed vehicle-as-obstacle rules).
Update the integration tests to be even more independent of where / how characters are spawned (most already are), so that they will work also with characters spawned inside buildings. Also adjust changeCharacterVehicle to take advantage of a character that already is inside a building (making it a bit more efficient in that situation).
Change the movement.py integration test so that the "blocked path" part is checked with a building rather than a vehicle that comes across, which will also hold true independent of the "unblock spawns" change. Also extend the setWaypoints utility method so that it can set a chosen speed (optionally), and use that to simplify the chosen speed test part.
Extend the movement.py integration test to include a convoy movement based on "shared suffix" paths with waypoint extension.
For building update moves (for now, just setting the service fee), the new format is this (replacing a JSON object keyed by IDs with a single object or array of objects that have the ID explicitly as a field):
Similarly, the format for character updates is also changed (except that the
|
God-mode
|
For the new waypoint extension feature, a character update can include a
The main intention of this feature is to support movement of many characters as a convoy. For this, a common "initial waypoint" S must be chosen. Then each of the characters is sent to S, and all of them (with a batched ID list) have their paths extended from S to the final target T:
An example for how to do such convoy movement is in the integration test. |
Avoid IDs as JSON object keys in move format
This changes the move format (mainly for character updates, but also some godmode commands and building updates) so that it does not rely at all on "IDs as strings used to index JSON objects". This change makes the format simpler and more expressive, especially with respect to the order in which updates are done. It also allows to update one character multiple times (in a defined order) within a single move. In addition to that, this also implements a new "waypoint extension" move, which appends a list of waypoints onto the already existing waypoints of some character.
Both changes together allow to implement proper and efficient convoy movement (sharing the main part of a long path between many characters) with the "principal directions" movement system.
This also includes a port of the first three commits from #170 to
master
from the0.3
branch.