I want to implement my own block for crafting. So, I investigated canonical example - workbench. And found this code:

 

   protected static void updateCraftingResult(int id, World world, PlayerEntity player, CraftingInventory inventory, CraftResultInventory inventoryResult) {
      if (!world.isRemote) {
         ServerPlayerEntity serverplayerentity = (ServerPlayerEntity)player;
         ItemStack itemstack = ItemStack.EMPTY;
         Optional<ICraftingRecipe> optional = world.getServer().getRecipeManager().getRecipe(IRecipeType.CRAFTING, inventory, world);
         if (optional.isPresent()) {
            ICraftingRecipe icraftingrecipe = optional.get();
            if (inventoryResult.canUseRecipe(world, serverplayerentity, icraftingrecipe)) {
               itemstack = icraftingrecipe.getCraftingResult(inventory);
            }
         }

         inventoryResult.setInventorySlotContents(0, itemstack);
         serverplayerentity.connection.sendPacket(new SSetSlotPacket(id, 0, itemstack));
      }
   }

 

Crafting result calculates on logical server and than client will be notified about result. But why? My crafting interface propose few results, based on items, which player have. Calculation of all combinations is not easy (of couse it have options for optimisation). What a reason to execute crafting result calculations on server?

https://link.springer.com/referenceworkentry/10.1007%2F978-3-319-08234-9_272-1

It's the architecture, the server does all the logical shenanigans, and the client is only a viewport, an interface to the state that's managed in the server side

54 minutes ago, kiou.23 said:

https://link.springer.com/referenceworkentry/10.1007%2F978-3-319-08234-9_272-1

It's the architecture, the server does all the logical shenanigans, and the client is only a viewport, an interface to the state that's managed in the server side

So, it is more ideologically question than strong restriction? I will try to prevent all situations, when count of combination will be critically big. But in theory I may miss some scenarious, which will creates overload. In this case will be better to overload client and give bad expirience for one player, than overlod server and give bad expirience for all.

Edited January 22, 20214 yr by S-Spirit

36 minutes ago, S-Spirit said:

So, it is more ideologically question than strong restriction? I will try to prevent all situations, when count of combination will be critically big. But in theory I may miss some scenarious, which will creates overload. In this case will be better to overload client and give bad expirience for one player, than overlod server and give bad expirience for all.

Cheating.

 

Player says "let me just modify my recipe files so that cobblestone makes diamonds."

Normal server goes "what, no stupid, you can't make diamonds out of cobblestone."

You: "OK, diamonds for you! That is a totally legitimate result I believe you're being honest."

22 hours ago, Draco18s said:

Cheating.

 

Player says "let me just modify my recipe files so that cobblestone makes diamonds."

Normal server goes "what, no stupid, you can't make diamonds out of cobblestone."

You: "OK, diamonds for you! That is a totally legitimate result I believe you're being honest."

For now it is impossible. My crating system is tricki a little. I didn't found way to represents necessary logic by JSON without losing my wishes about customisation. So I don't use recipes consept at all. But I hope at future resolve this problem and use it. In any case, I think your notification about cheating it a great point! So I will implement combinations calculation and filtration at client, but then send results to server for approve and apply into slots. Thanks.

Edited January 23, 20214 yr by S-Spirit

1 hour ago, S-Spirit said:

but then send results to server for approve

The server would have to do all the same calculations the client did in order to approve.

13 hours ago, Draco18s said:

The server would have to do all the same calculations the client did in order to approve.

I want to propose to user few options, which he/she may craft from items in inventory. Client will prepare all combinations, than select only few best (in my context). Server will validate only this few combinations. Ofcouse I plans to add precheck how many combination client may construct and prevent few-seconds freezes with message like "Sorry, so many ingredients for autocompletion."