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

[Autocrafter] Needs a list of non-autocraftable items #63

Open
Maverick2797 opened this issue Apr 10, 2023 · 4 comments
Open

[Autocrafter] Needs a list of non-autocraftable items #63

Maverick2797 opened this issue Apr 10, 2023 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@Maverick2797
Copy link

Maverick2797 commented Apr 10, 2023

There should be some way for mods to mark items as not being able to be crafted by an autocrafter, ideally as a group. This would prevent the autocrafter being able to craft anything in the game, bypassing minetest.register_on_craft() and minetest.register_craft_predict().

I suggest the group do_not_autocraft as a starting point. If the output item has this group, don't accept the recipe in the crafting grid.

There's currently a patch thread for AdvTrains that would provide survival craft recipes for LuaATC items, items that would require certain privs to craft (and use). Currently the autocrafter makes the priv system (and any other restriction systems) irrelevant as it bypasses all the craft predictions and skips straight to the final output.

@S-S-X
Copy link
Member

S-S-X commented Apr 10, 2023

I think I disagree with AdvTrains needing this for LuaATC items because I believe that using items should require privs, not crafting.

minetest.register_on_craft and minetest.register_craft_predict cannot be reliably used without adding autocrafter specific API.

Main issue is that a lot of crafting done by autocrafter specifically should not trigger those functions. craft_predict is kinda useless here anyway but on_craft is where decision should probably be made per mod (for example no xp/achievements/ranks, no satiation/damage/etc changes from crafting).

Other than that sounds like a good addition anyway and sure has some server specific use cases too.
Having group to disable recipe for autocrafter sounds like a good solution but IMO should not be used to replace privilege checks.

@Maverick2797
Copy link
Author

I fully agree that it shouldn't replace privilege checks, but the harder it is to get a hold of the restricted items in the first place the less chance that they can be used. "Swiss Cheese" security and all. Privilege checks in on_craft cover this for the player crafting manually, but autocrafters bypass crafting checks entirely by not being done directly by the player.
Another option could be to assign an owner to the autocrafter, and act as if the owner crafted the output manually, but this could still be liable to being programmed by a digiline by someone else.

BTW, I've updated the OP. LuaATC items do already require the atlatc privilege to be used, however that doesn't stop someone getting a hold of them if they were craftable.

@S-S-X
Copy link
Member

S-S-X commented Apr 10, 2023

Another option could be to assign an owner to the autocrafter, and act as if the owner crafted the output manually, but this could still be liable to being programmed by a digiline by someone else.

In theory this would be best solution but unfortunately it wont be that simple in real world.
This would still break in some (many) cases if player is not online and certain core functions get called, in addition to this also many other mods would have to add check to have special handling for autocrafter. And of course digiline feature you've mentioned.

@OgelGames
Copy link
Contributor

Preventing crafting does little to prevent players without privs obtaining the items, because players with privs can still obtain them, and then can give them to others if they choose. Preventing the use of items is much more effective, and in most cases is simpler to implement.

However, that being said, the autocrafter is lacking any kind of callback, so perhaps there should be a generalized callback added.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants