Skip to content
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

Add block_id! macro #101

Merged
merged 4 commits into from
Sep 19, 2024
Merged

Add block_id! macro #101

merged 4 commits into from
Sep 19, 2024

Conversation

lukas0008
Copy link
Contributor

Added a macro which allows getting BlockId from blocks.json at compile-time.

Basic usage:

let grass_block = block_id!("minecraft:grass_block");

with block properties:

let button = block_id!(
    "minecraft:acacia_button",
    "facing" = "north",
    "powered" = "true",
    "face" = "floor"
);

@Snowiiii
Copy link
Member

Hey, We need this for Chunks right?. Or for what usecases is this?

@lukas0008
Copy link
Contributor Author

It's for things that involve using BlockId, currently if you want to get a block id, you call BlockId::new with the name and properties of the block you need. This is not only bad because it is ran in runtime (making it a bit slower), but mainly it is bad since you need to unwrap the result from the function, which results in error prone and messy code. The macro solves the issue by just doing it at compile time and throwing an error if something isn't right.

@Snowiiii
Copy link
Member

Can't we refactor BlockId::new also use Compile time ?

@lukas0008
Copy link
Contributor Author

but... how?

@StripedMonkey
Copy link
Contributor

In principle it's possible to build the data as a bindgen-esque crate. I would advocate for not embedding block types/properties directly into the built binary though. Pre-generating them and caching the results somewhere feels like a better approach.

@lukas0008
Copy link
Contributor Author

lukas0008 commented Sep 19, 2024

I do store the parsed blocks.json statically, in the same build it only has to be parsed once, so the compile length hit should be negligible, since each macro is literally just a hashmap lookup with a bit of logic to parse the input.

PS: the block type and properties do not get embedded into the final built binary, after the macro execution it ends up just being a BlockId

@lukas0008 lukas0008 merged commit a30dbde into master Sep 19, 2024
10 checks passed
@lukas0008 lukas0008 deleted the block-macro branch September 19, 2024 15:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants