Implement "unblock spawns" fork #170
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Add a ForkHandler class and expose it through Context, which will be used in the future to check on the state of hardforks of the game rules. For now, no fork is defined, this just creates the basic system.
|
This will be first merged and tested on |
Define a new type of fork and set the heights for it. The fork will help to solve the issue of blocked spawn areas in the 0.3 competition (as well as just test doing a fork in practice). For now, it has no effect, but they will be added in later commits. The fork activates on height 500 on regtest and 2'159'000 on mainnet.
Update the game rules after the "unblock spawns" fork so that new characters will spawn in the starter-city building of their faction, rather than directly on the map. This helps to reduce the amount of idle characters in the starter zones that were created with the f2p "faucet" and never touched; they will now be inside the building, where they are not as annoying.
The new SparseTileMap template class implements a map from HexCoords on the map to arbitrary values. It assumes that this map is sparse, and can be used efficiently in that situation (i.e. if most coordinates have no entry, then looking them up is very efficient).
Instead of exposing IsPassable (with the logic to check for buildings and vehicles of a certain faction) in DynObstacles directly, expose the lower-level data about buildings and vehicles and do the logic whether or not that means "passable" in the callsites. This is just a refactor for now, but will make it easier to change the logic for vehicles that can be passed (but slower) in the future.
Change the internal data in DynObstacles, to actually count how many vehicles there are on any given tile and faction, rather than just keeping track of true/false. For now this does nothing to actually change behaviour of the game (except for making some setpathdata calls valid that were invalid before), but it will be used to implement the "unblock spawns" fork logic in the future.
When spawning on the map (not for new characters, but e.g. after leaving a building), the pre-fork behaviour is to choose any passable tile (i.e. not a building and not a vehicle of the own faction, but other factions are fine). This changes it post-fork to exclude any vehicles (even other factions). Those are not impassable per-se after the fork, but we still want to avoid them for nicer game behaviour.
After the "unblock spawns" fork, vehicles (of any faction) are no longer obstacles. Instead, they will just make moving onto a tile that is already occupied 8x slower. Moving off the tile is still fast, which in particular makes convoy movement work much better (because when different characters conflict into their movement onto the same tiles, the lowest-ID one will go through and the others will be "soft blocked" and then spread out one after the other).
|
The fork will activate on regtest at height 500, and on mainnet on height 2'159'000 (roughly five days from now, on September 8th). |
domob1812
added a commit
that referenced
this pull request
Sep 3, 2020
Implement "unblock spawns" fork
This was referenced Oct 9, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements a planned hardfork for the 0.3 (3rd competition) test world, which serves two main purposes: First, to actually test doing a fork in practice. Second, to get rid of the issue of spawn areas currently blocked up with idle characters (mostly from people who abused the f2p as a CHI faucet and never intended to actually play Taurion).
Starting at a signal height, the rules will be changed as such:
To facilitate the change in movement edge weights, the
findpathRPC method now has a new (mandatory)heightargument, which should be the block height for which the path should be calculated (e.g. current height + 1).