Secbots and Officer Beepsky (Proposal) #413
Conversation
github-actions
bot
added
Design
|
idea: since centralcommand (admins) can approve ssyndicate contraband. mabey propoe some kind of "exception clip" or something. and give HoS/Captain ability to make these. each "exception clip" only prevents that 1 item from being seen as contraband and only for that one person. minor contra would ask them to hand it over (drop it) or come with them (follow the bot willingly). failure to comply (or major contra) results in the normal "wee woo" behaviour |
|
|
||
| ## The Navigation Table | ||
|
|
||
| The navigation table is used to tell a secbot how to get from a given beacon to another beacon via a list of tile-by-tile directions. It will be a part of the map file, and will be able to update itself through the in-game actions of players. Since a lot of routes between beacons will take it via another beacon, we have a chance to optimise memory usage. Take 3 beacons in a line, in a 1 block wide corridor. | ||
|
|
||
| ``` | ||
| A -- B -- C | ||
| ``` | ||
| We can define the path from A to C as being the path from A to B, and then B to C. By storing this in the table we half the amount of path data stored (since the A to C path is twice as long as the other two). With optimal placement of beacons, **this navigation table becomes a planar graph, which has a linear max on the number of edges**. We still have to either store the `A -- B -- C` path, or do a smaller pathfinding algorithm over the navigation table to find out that the path `A -- B -- C`. Since it will be the longer paths that are compressed this way, this should have a significant impact on memory usage. Of course this only works when beacons are placed specifically to allow for this; in game it would be possible for a player to make a layout of beacons where every beacon has an extremely long, explicit path to every other beacon. We can optimise the amount of memory used for a path by packing multiple directions into single bytes. Specifically we can go to anywhere in the following pattern with half a byte of data (4 bits for 16 points). | ||
|
|
||
| ``` | ||
| X X X | ||
| XXX | ||
| XX@XX | ||
| XXX | ||
| X X X | ||
| ``` | ||
|
|
||
| Taking the largest map (Fland) to be about 100x150 tiles. Placing 16 beacons in a circle of diameter 150 and generating a path between each gives a sum of ~22,000 path tiles. We can encode 2 tiles of a given direction per byte. That's ~10KB of data stored for a scenario in which someone is deliberately trying to maximise the amount of data stored. Even if they were to make some maze that increased the number of tiles traversed, the `Explore` state will not store paths double the length of the best-case scenario, so we have a worst-case scenario of ~20KB. In reality we need fewer than 16 beacons, will have shorter paths, and can take advantage of our the above-mentioned linear maximum for edges. Again going to Fland, here's an example of a beacon layout, and the expected edges. | ||
|
|
||
|  | ||
|
|
||
| When updating the navigation table with the `Explore` state, some system will have to be put in place to allow for these A-to-B-to-C paths to be generated. The simplest solution is probably to maintain a stack of visited beacons when trying to go between 2 beacons while exploring. | ||
|
|
||
| With the suggested system, it would be possible to precompute the navigation table as part of the mapping process. Some `generateNavTable <gridID>` command would be used as part of the mapping process, similar to how pipe networks are colored, or atmos is generated. It would be possible to give a warning if 2 paths overlap, as that suggests a more efficient layout of beacons could be used. | ||
|
|
There was a problem hiding this comment.
This doc doesn't really make a whole lot of sense when pathfindingsystem already exists.
There was a problem hiding this comment.
Are you suggesting the system finds a new path every time it goes from a beacon to a beacon? That would be simpler but I was trying to minimise the time complexity of the system by caching as much as possible. The non-patrol states would probably use pathfindingsystem, but a secbot is going to be patrolling most of them time.
I figure if an admin wants to approve it, they can remove the component that marks it as contraband.
They're in the PR and they should appear properly on the docs website if/when this is merged. |
odd cause they aren't in the rendered when I go to your gh page |
I was using the wrong direction of slash :/, anyway fixed now cheers |
Secbots / Officer Beepsky Proposal, (ft. a beacon-based patrol navigation system)
There's a lot of stuff that could also be here like a killswitch console, but this is the minimum required to actually have the bots do stuff.