Extraction buildings #518
Merged
Extraction buildings #518
Conversation
This file contains hidden or 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
The `REGISTER_BUILDING_KIND` action has been extended so that `BuildingCategory` can be set. We are also setting craft recipes during registration
All tests use the new REGISTER_BUILDING action and are passing The function that is called as part of `REGISTER_BUILDING` was hitting a stack too deep error so I put all its params in a struct Rename `BuildingKindInfo` to `BuildingKindCfg` To match the param name
Moved (well copied) the `_registerRecipe` function from the CraftingRule into the BuildingRule. I needed to do this as dispatching `REGISTER_CRAFT_RECIPE` from within the BuildingRule would cause the CraftingRule to revert as `ctx.sender` is the BuldingRule address not the player's account.
Both category and ID are each encoded as uint64.
Extraction rule mostly implemented
Not full coverage but I'm seeing items being crafted from extracted goo and values in reservoir being depleted
Seeing reservoir values in the frontend. Calculated value in frontend is matching the calculated value that occurs at the point of extraction
Extract button is enabled when enough items to fulfil a batch have been extracted
Updated manifest to support the new `buildingCategory` and `model` properties
updated `apply.ts` to form the BuildingKind bytes24 ID from the name and category so it matches what the contracts do
I've put all 3 extractors in one manifest.
They also use a separate contract even though it's the same code. This is because if the byte code for a contract is seen as already deployed it won't be registered which meant that only the first extractor building to register the contract would work
The deployment was falling over consistently when trying to batch.
need Jack to work his magic on this though
hypnoshock
force-pushed
the
building-kind-registration
branch
from
14969b2 to
fbcee7f
Compare
ldunnplaymint
approved these changes
Aug 17, 2023
ldunnplaymint
suggested changes
Aug 17, 2023
ldunnplaymint
approved these changes
Aug 17, 2023
chrisfarms
reviewed
Aug 17, 2023
|
|
||
| export const BuildingSpec = z.object({ | ||
| name: Name, | ||
| category: BuildingCategoryEnum, |
There was a problem hiding this comment.
This is unused and can be removed I believe (since category is a BuildingKind thing not a Building thing)
| spec: | ||
| name: Mecha-Kaiju | ||
| location: [ 10, -21, 11 ] | ||
| category: blocker |
There was a problem hiding this comment.
category field can be removed from all these Building manifests I believe
| return CompoundKeyEncoder.encodeUint160(NodeSelectors.ClientPlugin, id); | ||
| }; | ||
|
|
||
| // TODO: Is there a way of referencing the Solidity enum? |
There was a problem hiding this comment.
🤔 core has the abi (it's how it checks the types for the action strings) ... so can probably expose a category type from there .... but think that one for later
| kind: Building | ||
| spec: | ||
| name: Green Goo Extractor | ||
| category: extractor |
| function BlockNum() external; | ||
| } | ||
|
|
||
| uint64 constant BLOCK_TIME_SECS = 10; |
There was a problem hiding this comment.
we might need this to be configurable at deployment time ... no change required now
Comment on lines
+424
to
+431
| function setBlockNum(State state, bytes24 kind, uint8 slot, uint64 blockNum) internal { | ||
| // TODO: don't use generic `Has` selector as it could conflict with something else | ||
| return state.set(Rel.Has.selector, slot, kind, Node.BlockNum(), blockNum); | ||
| } | ||
|
|
||
| function getBlockNum(State state, bytes24 kind, uint8 slot) internal view returns (uint64 blockNum) { | ||
| ( /*bytes24 item*/ , blockNum) = state.get(Rel.Has.selector, slot, kind); | ||
| } |
There was a problem hiding this comment.
think this relationship should probably be something more specific to extraction ... Block can be a generic concept, but think it might be clearer if the relationshpi and these funcs are about the extraction not the blocknum
Node.Something --Rel.LastExtractedAt--> Node.Block
| bytes24[4] memory inputItemIDs; | ||
| uint64[4] memory inputQtys; | ||
|
|
||
| // TODO: Is this test for name annotions necessary anymore? |
There was a problem hiding this comment.
no I don't think so ... burn it
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
What
An addition of
BuildingCategoryonBuildingKindwhich allows us to define if a building is either a blocker, factory, extractor or other.As part of this I have implemented the extraction category which allows you to define an extractor building that outputs an item that is comprised of one type of goo (atom)
Extractor buildings are show on the map and are the color as defined as their model which is either
red,greenorblueAs part of the deployment I am deploying 3 extractors that represent the 3 goo types and also placing them on the map close to the starting point.
I have also added some basic frontend so the item extraction can be tested