Jump to content

Guidance on when to check world.isRemote


Drakmyth
 Share

Recommended Posts

I know world.isRemote indicates whether the code is running on the logical server or the logical client. I further know that in most cases interacting with the world from the logical client causes desync/ghost entities/etc and so it is important to only interact with the world from the logical server. Finally, although I haven't learned much about GUIs yet, I know those are one of the primary places where logical client-specific code exists.

 

What I'm wondering is if there is any guidance on what scenarios world.isRemote needs to be checked, or how to tell if any particular method should include that check?

 

My current impression is that with the exception of registration code (which I'm doing through DeferredRegister and thus is registered on each side according to how Forge knows how to do it) there generally should not be any logic that should run on both sides and so world.isRemote should be checked in pretty much every method. Further, unless there is logic that is specifically known that it should only be executed client-side, generally all logic should be logical server-side only. Obviously this may differ wildly depending on the particular mods goals, but as a general-case implementing vanilla-like items and blocks mod goes that seems to be the case.

 

For instance: I believe I should check (!isRemote) in Item#onItemUse, but not in Block#createTileEntity (because tile entities *should* be created in the client?) but what about in Block#getShape or TileEntity#tick?

 

If there's not a general rule-of-thumb (such as "never execute on the client unless you know you have to"), what kinds of properties or scenarios should I be looking for to understand when I do need to check? How do I tell which sides a particular method will even be executed on?

Link to comment
Share on other sites

I would say read the statements on the different kinds of sides prior to me explaining my reasoning. Even though all logic should be executed on the server side, sometimes it's less computationally heavy to execute the logic on both sides. For example, if your TE changes it's texture based on the amount of liquid it has, you might just want to send a boolean to client saying whether to increase the liquid or decrease it. It more or less depends on what information gets synchronized between the two sides. NBT data on an ItemStack is synchronized to the client when changed, so it should be logically sided within Item#onItemUse. Alternatively, Block#createTileEntity is called on both sides if we want to change how something like a TileEntityRenderer appears based on the stored data on the server. Same thing with entities except their spawning is sent through a packet to keep the same id.

So, generally, all logic should be on the logical server unless you want to display something. Then, that information should be synced to the logical client. However, if it's sending a multitude of information every single tick, then the logic should be handled on both sides and synced via some value that switches both of their states. At least, this is my opinion.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • REM Forge requires a configured set of both JVM and program arguments. REM Add custom JVM arguments to the user_jvm_args.txt REM Add custom program arguments {such as nogui} to this file in the next line before the %* or REM  pass them to this script directly "C:\Program Files\Java\jdk-17\bin\Java.exe" @user_jvm_args.txt @libraries/net/minecraftforge/forge/1.18.2-40.1.80/win_args.txt -Xmx8G -Xms8G %* pause     so I used it.
    • I created an SOUL_JAR Item that has been registered for each mob like - mod:soul_jar_minecraft_cow etc.. but it all has different registry names, i have a model file name soul_jar.json and i want to know how to bind each of those items to this class (When mod iterates through all of vanilla mobs and registering items for them).   I didn't found any info about it because all of info is outdated, and forge docs is complicated asf (i wish there would be more examples) i also used AI but it showing me only outdated info, but theres some code where i registering my item and trying to bind it to model ->   public static void register(IEventBus eventBus){ ITEMS.register(eventBus); Set<ResourceLocation> entityKeyList = ForgeRegistries.ENTITY_TYPES.getKeys(); for (ResourceLocation k : entityKeyList) { EntityType<?> entityType = ForgeRegistries.ENTITY_TYPES.getValue(k); if (!entityType.getCategory().equals(MobCategory.MISC)) { RegistryObject<Item> SOUL_JAR = ITEMS.register("soul_jar" + '_' + k.toString().replace(':', '_').replace('.', '_'), () -> new JarItem(new Item.Properties().rarity(Rarity.RARE).tab(ModTabs.MAGICAL_OBSESSION_JARS), entityType)); if (Thread.currentThread().getThreadGroup() == SidedThreadGroups.CLIENT) { ItemModelShaper itemModelShaper = Minecraft.getInstance().getItemRenderer().getItemModelShaper(); itemModelShaper.register(SOUL_JAR.get().asItem(), new ModelResourceLocation("item.soul_jar", "inventory")); } } } } I also have more questions like how to iterate through all other mods mobs also, or render mob inside of a jar in inventory, but i will try to figure it out.
    • I looked into OctoEconomyAPI and saw that it was a JAR api for fabric. This means you have a fabric mod in your mods folder. I downloaded your mod folder and wasted 2 solid hours creating a Python script to try to find the faulty mod, and eventually just gave up. I suggest you create two installations with half or the mods in each, find which one doesn't launch, cut that one in half, and repeat until you find the fabric mod. Investigué OctoEconomyAPI y vi que era una API JAR para fabric. Esto significa que tienes un mod de Fabric en tu carpeta de mods. Descargué su carpeta de mods y desperdicié 2 horas completas creando un script de Python para tratar de encontrar el mod defectuoso, y finalmente me di por vencido. Le sugiero que cree dos instalaciones con la mitad o las modificaciones en cada una, encuentre cuál no se inicia, córtela por la mitad y repita hasta que encuentre la modificación Fabric.   (The Python script I made is here): (El script de Python que hice está aquí):  
    • I've got it to work now. Instead of using the texture manager I used the Render System:   RenderSystem.setShaderTexture(0, new ResourceLocation("mcaquests", "textures/item/questbook.png"));  
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.