-
Notifications
You must be signed in to change notification settings - Fork 577
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
base: master
Are you sure you want to change the base?
Conversation
You made simple things complex without providing any benefit or optimization in return. |
@MoNTE48 Is there anything specific you would change about it? |
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:
since most of these depend on both type and material, I don't see much benefit in having a So I would propose refactoring to You could also consider introducing a
|
…ion function, change to tables instead of arguments for registration, leave tool descriptions as is for translation
@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. |
Clean up and refactoring of tools.lua. Some of the names might need to be changed though.