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

Blocks toml #351

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft

Conversation

benjamin051000
Copy link
Contributor

@benjamin051000 benjamin051000 commented Jan 29, 2025

The current block-defs.rs is not a great solution. Instead, put all block info in a toml file, and pull it in (ideally, at compile time). Then, simply query the one you need either by its ID or name.

Note

The things to look at in this PR are block_definitions.rs and blocks.toml. Everything else is just my failed (it's getting there!) attempt to update all the API calls, and is now outdated anyway. We will get there eventually.

All, let me know if you like this change, and see my below comments for more info.

I'm not sure why these were initally functions. I think they are better
off as global arrays, since the function would initialize a new vec
every time its called, whereas this only initializes it once.
@@ -141,7 +141,7 @@ pub fn generate_world(
let total_iterations_grnd: f64 = (scale_factor_x + 1.0) * (scale_factor_z + 1.0);
let progress_increment_grnd: f64 = 30.0 / total_iterations_grnd;

let groundlayer_block = if args.winter { SNOW_BLOCK } else { GRASS_BLOCK };
let groundlayer_block = if args.winter { BLOCKS.by_name("snow_block").unwrap() } else { BLOCKS.by_name("grass_block").unwrap() };
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is... not the most elegant API. 🤷🏼‍♂️

@benjamin051000
Copy link
Contributor Author

benjamin051000 commented Jan 29, 2025

This is a good idea, but right now the implementation has some drawbacks:

  • toml::from_str isn't const (because we don't yet have const traits, apparently)
    • This can be resolved with static-toml crate, but makes the implementation uglier :(
    • Or, a custom proc_macro... maybe.
  • The API is not as good as it used to be due to all the unwraps and stuff
    • Maybe a lot of it can be removed? I'm not great at rust so there may be a better way

@benjamin051000
Copy link
Contributor Author

benjamin051000 commented Jan 29, 2025

  • toml::from_str isn't const (because we don't yet have const traits, apparently)

Meh, I guess the performance penalty is small...

  • This can be resolved with static-toml crate

True. That might be worth looking into. It still requires a global variable, though, and it seems clunky and tough to massage your struct into something nice.

  • The API is not as good as it used to be due to all the unwraps and stuff

Returning an Option is probably the right thing to do. You can always just ? it

@benjamin051000
Copy link
Contributor Author

Would it be better to use something like static-toml and keep the global var? Or should we just load this data into a var in main() and pass it around to functions? I'm not sure what's better.

If we had const fn toml::from_str, I'd simply use that and throw it into a static... I wonder if nightly rust supports this...

@benjamin051000
Copy link
Contributor Author

Trying to get static_toml working is not the best, but I asked about potentially modifying it to generate Option types for optional values here: cptpiepmatz/static-toml#6

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.

1 participant