• Recently Browsing

    No registered users viewing this page.

  • Posts

    • Thank you very much for everything
    • Hi, Im a french guy and i want to create mod for me and my friend, So i try to create a very simple mod for testing. I following a lot of modding tutorial in 1.15 in English and Spanish but i encountered the same problem every time and .... CA COMMENCE A ME SAOULER 😂 -> Sorry, a french  expression 😆..   So, the problem is a texture problem : When i start the game (with runClient in EclipseJava), the textures of new blocks ... there a not texture 😆     The src code :    Main class : BlockInit class : assets/tutorialmod/blockstates/example_block.json : assets/tutorialmod/lang/en_us.json : assets/tutorialmod/models/block/example_block.json : assets/tutorialmod/texture/blocks/example_block.png: .... here, an 16x16 image   The Package Explorer :   When place the block, there are not texture but the ItemBlock has the good texture and the good name.... And there are not error in the console.... Its craaaazzzzyyyyyy.... I not understand anything....     I need your help pleaaase,  Im Going CRAZYY 😂 Thanks
    • It works, most of the time. To understand when it does not work, you have to know a lot about how lambdas are implemented and how the JVM loads class files. If you write a lambda, that code becomes a static method in the same class. If you write two lambdas (even if they are nested within each other), the code is still present in the containing class file, as two static methods. The JDK will then at runtime use whatever means it sees fit (currently it just creates new class files using ASM) to turn those static methods into actual instances of the interface. Now, when the JVM loads your class file it has to verify it, so that there are no unsound type operations in the bytecode, for example. So, if you e.g. do: ClientWorld world = Minecraft.getMinecraft().world  The JVM has to check that the type of Minecraft#world (ClientWorld) is actually assignable to ClientWorld. In this case this is trivial, because obviously ClientWorld is-a ClientWorld.   In this case the JVM can verify this code without loading any classes (i.e. it doesn't need to load ClientWorld). Your class (containing the two static methods for the lambdas) loads fine, even on the server.   Now, let's do a very subtle change: World world = Minecraft.getMinecraft().world Suddenly, your code will crash on the server. Why? Because the JVM has to now load World and ClientWorld to see if ClientWorld is assignable to World. It will fail to find ClientWorld and boom, your code crashes with a NoClassDefFoundError on a server.   This is why I really do not like this approach, because it is brittle and requires deep understanding of many mechanics that you normally never need to worry about in Java development to use correctly. Yes, it's argueably a lot more convenient than @SidedProxy, but @SidedProxy made it very clear that we are dealing with classes that are potentially absent here, thus reflection must be used, it is the only truly safe way to interact with classes that are potentially absent. It is also still unclear if this optimization the JVM does (not loading the classes at all if they are equal) is actually specified in the JVM specification, or if this whole approach relies on an implementation detail that HotSpot (OpenJDK's main JVM) does.
    • Does it not? I've used the double supplier trick in a lot of code and it's all worked just fine on dedicated servers.
    • Just as a note, it doesn't actually do this properly.
  • Topics

  • Who's Online (See full list)