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

refactor of default/tools.lua #3107

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

MistUnky
Copy link

Clean up and refactoring of tools.lua. Some of the names might need to be changed though.

@MoNTE48
Copy link
Contributor

MoNTE48 commented Apr 5, 2024

You made simple things complex without providing any benefit or optimization in return.

@MistUnky
Copy link
Author

MistUnky commented Apr 6, 2024

@MoNTE48 Is there anything specific you would change about it?

@appgurueu
Copy link
Contributor

I think deduplicating this code, and potentially exposing an API, makes sense; some things (such as recipes) simply follow the same pattern for the same tool type.

However, I have to agree that the way this PR goes about it is presently not an improvement. First of all, the overly long argument lists are very messy. Passing a definition table would be much preferable (and would also make it easier to pass arguments on unchanged).

Let's first determine which fields only depend on tool type (sword / shovel / pick / axe / hoe) and material type name (wood / stone / iron / bronze / mese / diamond), or are invariant:

  • Tool item name;
  • Tool inventory image;
  • Tool wield image;
  • (Technically also tool description, but for translation reasons we may not leverage this);
  • sound = {breaks = "default_tool_breaks"};
  • Tool recipe

since most of these depend on both type and material, I don't see much benefit in having a default.register_tool function at all; instead, simply have register_pick, register_shovel etc., potentially as local functions if you don't want to expose them. The only other thing that varies are the tool_capabilities, which need to be passed as a parameter.

So I would propose refactoring to register_<tool>(material, tool_capabilities) functions.

You could also consider introducing a register_tools(material, material_properties), where material_properties has fields full_punch_interval, max_drop_level, groupcap, damage_fleshy to register tools of all five types given a material type, though I'm not so sure about this.


S(desc.." "..typedesc) means the translation updating script will be unable to pick up these strings. You should take an entire description instead and write out S("Wooden Pickaxe") etc. each time.

…ion function, change to tables instead of arguments for registration, leave tool descriptions as is for translation
@MistUnky
Copy link
Author

MistUnky commented Apr 6, 2024

@appgurueu I made the functions local and rewrote them as you specified. I made the function arguments (ex) register_pick(tool_def) rather than register_pick(name, tool_def).

edit: I think something like a generic register_tools(tools_def, type_tool_def) would be preferable but I've left it out, as it might be too much.

@sfan5 sfan5 requested a review from appgurueu September 8, 2024 20:10
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