TheGreyGhost

Howdy I've found a lot of great samples on this site, it's my first go to. https://freesound.org/ -TGG

Howdy This tutorial project has two working examples of containers with GUI that you might perhaps find useful https://github.com/TheGreyGhost/MinecraftByExample (mbe30, mbe31) Add the button to your ContainerScreen, and as dieSieben says, send a packet to the server when your button is clicked (if you don't know how, see mbe60 for clues) and forward it to your server-side container code to actually move the items. -TGG

Howdy I think you're heading in the right direction, the renderModelSmooth is the one that you want; some suggestions 1) pick an existing vanilla RenderBuffer instead of making your own, eg IVertexBuilder vertexBuilderBlockQuads = renderBuffer.getBuffer(RenderType.getSolid()); Ah wait - you're using 1.14.4. The principle is the same but you may have used the right buffer modes already. There are a couple of settings that will stop vanilla applying lighting properly- depends on the source of your model - if the Quads in your model have diffuse lighting false, then the direction-depending lighting won't be applied. if the block is opaque, the light value might be set to zero for quads which aren't at the outermost edges of the block if the block is glowing, ambient occlusion is turned off You might just need to trace into the render method to see exactly what is going on - the ambient occlusion & brightness methods are complicated but it's not too difficult to see what they are doing / why there's no lighting being applied at all. This link might be useful for background information http://greyminecraftcoder.blogspot.com/2020/04/lighting-1144.html Cheers TGG

Howdy That's odd, I have done exactly the same thing with IntelliJ and haven't had any problems. My logs look very similar to yours too. Have you tried importing the MDK without modifying the build.gradle at all? You could also try running gradlew build (and then genIntelliJruns) from the command line instead of from IntelliJ Alternatively you could Open project instead of Import project. In previous versions of Forge / IntelliJ that did sometimes make a difference for me. -TGG

Hi I'm just making the switch from 1.12.2 to 1.15.2 at the moment and 1.15.2 seems stable enough to me. I've had no trouble with gradle build in IntelliJ. I suggest you use the latest "1.15.2 - 31.1.46" instead of recommended "1.15.2 - 31.1.0" because latest uses a much newer set of MCP mappings (i.e. nearly all the classes and methods have sensible human-readable names now, whereas recommended is still full of func_923535 and similar names). -TGG

Hi FYI some notes from my testing on the buses so far... // Beware - there are two event busses: the MinecraftForge.EVENT_BUS, and your own ModEventBus. // If you subscribe your event to the wrong bus, it will never get called. // likewise, beware of the difference between static and non-static methods, i.e. // If you register a class, but the @SubscribeEvent is on a non-static method, it won't be called. e.g. // MOD_EVENT_BUS.register(MyClass.class); // public class ServerLifecycleEvents { // @SubscribeEvent // public void onServerStartingEvent(FMLServerStartingEvent event) { // missing static! --> never gets called} // } // Based on my testing: ModEventBus is used for setup events only, in the following order: // * RegistryEvent of all types // * ColorHandlerEvent for blocks & items // * ParticleFactoryRegisterEvent // * FMLCommonSetupEvent // * TextureStitchEvent // * ModelBakeEvent // * FMLClientSetupEvent or FMLDedicatedServerSetupEvent // * ModelRegistryEvent // * Other ModLifecycleEvents such as InterModEnqueueEvent, InterModProcessEvent // Everything else: the MinecraftForge.EVENT_BUS -TGG

Hi Looks like a problem in your recipe file: SingleItemRecipe$Serializer.read This is the code that reads recipes from json files. It will probably help if you put a breakpoint in the constructor of ResourceLocationException, and then look back up the call stack to check what the variables are (i.e. which part of the recipe is being parsed) -TGG

Hi Although I know nothing about the BLOCK_STRIPPING_MAP you can use Reflection to access protected and private fields, and perhaps final members as well (although I've never had to do that myself) Even if it is final, you can still manipulate the existing map (add/remove elements) even if you can't replace the map itself. And actually - even simpler - Because it's a static field, you can just generate a dummy MyAxeItem extends AxeItem, and get access to the protected field from there, no Reflection required. -TGG

Hi Just a guess because I haven't used DeferredRegistry yet, but your block doesn't appear to be typed properly? public static final RegistryObject WAND_INFUSER = BLOCKS.register("wand_infuser", () -> new BlockWandInfuser()); i.e. RegistryObject<Block> ? -TGG

Howdy I think it would be possible to do this using one of the BlockEvents, eg NeighborNotifyEvent or BreakEvent. i.e. you subscribe to BreakEvent; when any block is broken, your code checks to see if it was within a multiblock structure (eg - look for controller tile entities within a given radius). If so, the controller "check your structure components, they have been changed". -TGG

Hi Based on my testing so far: // Based on my testing: ModEventBus is used for setup events only, in the following order: // * RegistryEvent of all types // * ColorHandlerEvent for blocks & items // * ParticleFactoryRegisterEvent // * FMLCommonSetupEvent // * TextureStitchEvent // * ModelBakeEvent // * FMLClientSetupEvent or FMLDedicatedServerSetupEvent // * ModelRegistryEvent // * Other ModLifecycleEvents such as InterModEnqueueEvent, InterModProcessEvent // Everything else: the MinecraftForge.EVENT_BUS Easy enough to tell using a breakpoint if you've chosen the wrong one. -TGG

Hi This example project might help (mbe20) https://github.com/TheGreyGhost/MinecraftByExample You are probably missing one of these methods: // When the world loads from disk, the server needs to send the TileEntity information to the client // it uses getUpdatePacket(), getUpdateTag(), onDataPacket(), and handleUpdateTag() to do this: // getUpdatePacket() and onDataPacket() are used for one-at-a-time TileEntity updates // getUpdateTag() and handleUpdateTag() are used by vanilla to collate together into a single chunk update packet Cheers TGG

Hi Yeah it's a bit weird. It helps to know the history- originally there was just the Block class with those methods, and you had to pass a 4-bit 'metadata' to most functions. Then Mojang added BlockStates which was more-or-less Block plus metadata. So they put a 'deprecated' onto the Block functions to say "don't call these Block functions any more, call the BlockStates instead". Not really what @deprecated is intended for, but then again Minecraft isn't an API by any stretch of the imagination either. Just ignore it is what I usually do... if it breaks next version update, I'll fix it along with the other 50 things that got broken -TGG

Hi Mojang means "Call the corresponding BlockState function, don't call the Block function". It doesn't mean "you must not override this method when you extend the Block class". Basically you can ignore the @deprecated, it's just an advice that there might be a better way. In this case (extending the block class), there is no better way. -TGG

Hi >Thanks for the response! So to do this, would I basically need to add a value for every modified block containing the location and energy values (and potentially the block type as well) of each block? Yeah, pretty much. You might use (say) a HashMap of BlockPos vs energy value for all blocks which are are partially depleted. The block type is stored already (in the World) so you don't need to store that. You might also need some sort of second datastructure (eg HashSet) for blocks which are permanently depleted. I think you also need to decide how the game should react if the data structures get too big and you need to cull them from memory. What's your game mechanic for that? eg Do you strip out the depleted blocks which are a long way away? ("Natural energy regenerates instantly when there are no spellcasters within X radius") If too many blocks get fully depleted in an area, does it destroy the entire chunk? ("If the flow of natural energy is sufficiently disturbed, then all natural energy in the area sickens and dies") If those have an unacceptable game impact, you might need to split your data structure into chunks and store them in parallel with normal world data. i.e. hook into the chunk loading and unloading events, and load+unload your own datastructures in parallel with those. WorldSavedData might not be suitable for storing large amounts of data (I'm not sure); you may need to write your own datastructures on disk similar to how the chunk system does it, i.e. allows you to modify chunks within the file without having to rewrite the entire file. That would be more complicated but it would still work if you're careful. -TGG

Hi This example project has a working example of OBJ models that you might find helpful. There are a few things you need to get exactly right before it works and often the errors are not clear. https://github.com/TheGreyGhost/MinecraftByExample see mbe21 Strategically placed breakpoints in OBJModel and OBJloader will help too. -TGG

Hi I don't think it's possible to directly add this information to vanilla blocks. If it were your own blocks, you could have blockstates for each one (say 16 levels) or a tileentity. However it's certainly possible to maintain a parallel data structure of your own which stores the energy level for every block (or perhaps more efficiently - every partially depleted block) - you can store it in WorldSavedData, and can update it regularly using server world tick. You may need to be careful about chunks loading in or out (not trying to update information for chunks which have been unloaded because the player is a long way away, for example) but it wouldn't be particularly difficult. If there are other mods which seem to do something similar, you could look at their source code too. -TGG

Hi This link might help with some background information on VoxelShapes and why you might need them. https://greyminecraftcoder.blogspot.com/2020/02/block-shapes-voxelshapes-1144.html -TGG

Howdy This example project might be helpful https://github.com/TheGreyGhost/MinecraftByExample see mbe02 The blue patch is caused by incorrect VoxelShape (default is full cube), if you set that correctly the problem will be be fixed -TGG

Hi I have exactly the same problem (in IntelliJ), I haven't spent the time to figure out exactly what the root cause is, but there is a workaround that you don't have to delete the cache for. If you go to Project Structure, Libraries, and select the mapped snapshot, you can manually unlink the older sources which are mapped to the class file. Eg see screenshot (after removing the extra/older source). It's not perfect because when you refresh the gradle task it puts the old ones back in again, but it's not a big hassle. -TGG

Hi Your code has a problem with one of its resources, and due to a bug in Forge it causes infinite reloading loop https://github.com/MinecraftForge/MinecraftForge/issues/6593 As PenWallet said, it might be your item registration. If it's not that, you might need to do trial and error removal of selected registrations until the error disappears -TGG

Hi Did you try the instructions on this page? https://docs.gimp.org/en/gimp-concepts-patterns.html -TGG

Hi You might find this example project useful https://github.com/TheGreyGhost/MinecraftByExample It doesn't used DeferredRegister (uses alternative registration methods) but it will give you working examples of blocks, items, etc -TGG

Hi Antonii (1) I think the GuiConfig code etc from 1.12.2 is gone; I certainly can't find it. The annotations will allow you to generate fields which read from a config file but I don't think the "automatic" Gui Configuration code has been ported to 1.15.2. (2) I'm not sure what you mean, but I suspect it doesn't exist now (3) posX, posY, posZ of what object? -TGG

Hi Rick motionX, Y, Z are velocity, i.e. the movement per tick. The position of the player is controlled from the server, not the client. The client sends packets to the server telling it what the player is doing (CInputPacket). The client position is periodically updated by a packet sent from the server to the client (eg SEntityTeleportPacket or SEntityPacket). In 1.15.2 the CInputPacket sets moveStrafing and moveForward, which are copied to the motion during livingTick Some of the methods where motionX, Y, Z are passed in are not actually displacements although they might look like it. They are a displacement per tick. So the tick method just adds the motionX because it has already been converted to the correct units i.e. x += deltaX; where deltaX = motionX * time, however time = 1 (tick), so the code just says deltaX = motionX i.e. x += motionX; -TGG