S-Spirit

I want to create screen with blur background, similar to this mode. But I need it only for my own screen, not need to change vanilla. Faced a problem to found tutorial about this - all results in Google says how install shaders, how use shaders with optifine and e.t.c Can't found any one about how to use shaders in my own mode. Tried to investigate this mode, but it is old (last version support 1.13) and have tons of dark magic related to change vanilla screnes backgrounds. Also tried to investigate how vanilla use standard blur shader, but this is also so hard way (at least with my skills). S

Oh, you are right! This string inside "capNBT" looks very similar to JSON and I thinked, NBT is system for wrapp and simplify JSON serialization. Thanks for clarification and sorry about that misunderstanding.

Sorry, I am confused a little. I implements writeNBT and readNBT methods for my capability. In this methods I construct nested CompoundNBT, ListNBT and e.t.c. Don't serializes all data to JSON and stores like NBT with 1 element. Is it right way? Thanks. So I should remove this feature or implement it by more compact way.

I try to stores story of item craft ingredients. In my mode recipes are not strongly determined. So it is not possible to say "if this is X it was exacly created from Y and Z". So I have case when some item was created from 4 another item, and each of them was created from few another and e.t.c I don't serialize capabilities manually. But at debug I see in ItemStack the field named "capNBT" (with JSON inside), and when I checked it size I started to worry

I want to store in my ItemStacks big size data. I used capabilities, so all this data serializes into JSON and stores at capNBT. For now capNBT for one stack may be between 100 and 10 000 characters. I think near 3 000 is middle value. I have a few ideas, how make capNBT more short, but doesn't know, should I spend time to it or not. So I have few related questions: 1. Does Forge have limit to capNBT size? 2. Does ItemsStaks from closed chest (in loaded chanck) stores at RAM? Even if user doesn't open it? 3. Maybe exist some another nuances related to big capNBT?

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."

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.

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.

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 (optiona

Thanks, got it! No one. It was my own conclusion from documentation and tutorials. When you asked, I read about @OnlyIn one more time, and see - my conclusion was fully wrong. I even thinked @OnlyIn work with logical sides, but specification says - physical. So I should make a refactorng. Thanks for get my attention.

Thank you very much! You was right - problem was related to code Minecraft.getInstance().player. I Have read page about networking few times and missed this example of common beginners mistakes... But how I should get opened container at server side? I added list of listeners into ModNetworking private static final NonNullList<WeakReference<Object>> serverListeners = NonNullList.create(); public static void addServerListener(Object obj) { serverListeners.add(new WeakReference(obj)); } public static void removeServerListener(Object obj) { serverListeners.remove(o

Added Forge version to title. Does anyone meet this network issue?

I implementing screen, where user may select option and server should be notified about it. Simple case. I found tutorial and implemented this feature uses SimpleImp. Maybe I missed something - packet from server sends to client successfully, but when I tries to use sendToServer client get message instead server. My network class public class ModNetworking { private static final String PROTOCOL_VERSION = "1.0"; private static SimpleChannel INSTANCE; private static int ID = 0; public static int nextId () { return ID++; } public static void registerMessages