TheGreyGhost

Howdy You might find this tutorial project useful, it has two working examples of obj models wavefront obj model for a TileEntity Renderer: https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe21_tileentityrenderer wavefront obj for an entity (boomerang): https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe81_entity_projectile -TGG

Howdy That Slerp is something different, nothing to do with what you are trying to do. For low values of pitch, you can get a smooth motion like this. Initial position: yaw0 pitch0 time0 Final position: yaw1 pitch1 time1 each tick: the time is timeX (starts initially at time0, finishes at time1) yawX = yaw0 + (time - time0) * (yaw1 - yaw0) / (time1 - time0) pitchX = pitch0 + (time - time0) * (pitch1 - pitch0) / (time1 - time0) If you want the acceleration and deceleration to be smooth as well, it gets trickier but not a lot trickier. You just need to define a new variable progress time0 = start of acceleration time1 = end of acceleration, start of constant speed time2 = end of constant speed, start of deceleration time3 = end of deceleration during acceleration: progress = 0.5 * A * (timeX - time0)^2 during constant speed: progress = 0.5 * A * (time1 - time0)^2 + S * (timeX - time1) during deceleration: progress = 0.5 * A * (time1 - time0)^2 + S * (timeX - time1) - 0.5 * D * (timeX - time2)^2 and then calculate eg yawX = yaw0 + (progress- progress0) * (yaw3 - yaw0) / (progress3- progress0) You choose A, D, and S depending on how fast you want the acceleration, coasting speed, and deceleration to be. There are some constraints i.e. S = (time1 - time0) * A. and you need to check for the case that there is no constant speed (i.e. you start accelerating but don't reach steady speed before having to start decelerating.) If you have high values of pitch (say 60 degrees or more) then the motion will speed up or slow down a bit (faster near pitch 0, slower near pitch 90) but it will still look smooth and it's probably not worthwhile going into the more-complicated maths (sin, cos, and/or Quaternions) that you would need. Cheers TGG

Howdy My guess is - your VoxelShape is wrong https://greyminecraftcoder.blogspot.com/2020/02/block-shapes-voxelshapes-1144.html https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe02_block_partial -TGG

hi This tutorial has two examples of entity registration that you might find helpful https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe81_entity_projectile -tgg

Hi You might find this example code useful https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe31_inventory_furnace -tgg

Howdy I'm not sure I understand the problem you're facing. Because you control the creation of your own types, you should be able to create a map of the entity type and its string name when you create them, and when you get a string name, use that map to decide if it's one of your entities and then spawn it. Your registered entity type has the factory in it already. Using reflection to search your own registry class seems like a very strange idea to me. I also suggest not to use static initialisers for your entity types; either used DeferredRegistry or use an event, like this https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe81_entity_projectile/StartupCommon.java Cheers TGG

Howdy It looks to me like the enums have just taken place of the bits. An EnumSet actually is functionally equivalent to the way the mutex were used before. eg if previously MOVE was bit 0 (=1), JUMP was bit 1(=2), LOOK was bit 2(=4), and TARGET was bit 3(=8) then a mutex of 7 = 1 + 2 + 4 = MOVE + JUMP + LOOK is the same as an enumset of {MOVE, JUMP, LOOK} You just need to find the 1.12.2 mutex bits which correspond to the new flags. Goal.setMutexFlags() appears to be the method you need. -TGG

Howdy Have a look in TexturedParticle::renderParticle. You will need to understand some vector rotation math (Quaternions) but with a bit of experimentation you should be able to figure it out. Some more information on particles here in case you need it: https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe50_particle Cheers TGG

Howdy That might be tricky depending on what you're trying to achieve; it will make blocks under your glass appear dark? It will probably help to dig through the vanilla code for notSolid and the vanilla calculations for light propagation, with any luck you will find a combination of properties that achieves what you want without messing up rendering effects like ambient occlusion or the rendering culling (the "see through portal" effect you discovered). AbstractGlassBlock is a good place to start, glass already reduces the light passing through it by a certain amount (like water as well, from memory) so that may be a further clue. Re tutorials- You might find this tutorial project (working examples) useful; it's currently at 1.16.4 https://github.com/TheGreyGhost/MinecraftByExample http://greyminecraftcoder.blogspot.com/2020/05/minecraft-by-example.html -TGG

Howdy You'll probably find this working tutorial example helpful https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe81_entity_projectile -TGG

Howdy folks Does anyone know what's happening with a possible Forge move from MCP to official Minecraft mapping names? The last "official" information I found was from CPW, here: http://cpw.github.io/MinecraftMappingData.html#update-august-2020 I for one am getting pretty weary of bulk name changes every time version updates, and the continual subtle (and often misleading) name changes when they are manually remapped, so I'm exploring options to code in Minecraft Mapping. Obviously it would be great if this were natively implemented by Forge but it appears like that may be some way off. In the meantime I see some tools around which look like they might be an interim measure eg: https://github.com/HeartPattern/MC-Remapper Does anyone have experience, hints/tips etc with using those? Cheers TGG

Howdy folks I'm having some trouble with the ObfuscationReflectionHelper. I'm using findfield, and it works fine when I run it in a development environment and when I package it as a mod. But I've had a bug report from another programmer who finds that it crashes his code. The difference appears to be that his environment is running with obfuscated names, so that the reflection helper can't find the deobfuscated field name. Any thoughts on what's going on and how I can robustly fix it? The whole obfuscation/deobfuscation is still something of a black box for me and I can't reproduce his issue so I don't have many clues to point me in the right direction. Cheers TGG The code: private static World getPrivateWorldFromWorldRenderer(WorldRenderer worldRenderer) throws IllegalAccessException { if (worldField == null) { worldField = ObfuscationReflectionHelper.findField(WorldRenderer.class, "world"); } return (World)worldField.get(worldRenderer); } private static Field worldField; His crash log: https://pastebin.com/ExUU5BaS and in particular: Caused by: java.lang.NoSuchFieldException: world and I notice lots of obfuscated (Searge) names in there: eg at net.minecraft.client.renderer.WorldRenderer.func_228426_a_(WorldRenderer.java:1096) ~[?:?] {re:classloading,pl:runtimedistcleaner:A} When I try to reproduce the crash by changing my code to worldField = ObfuscationReflectionHelper.findField(WorldRenderer.class, "worldDONOTFIND"); I get the same error but my crash log has deobfuscated (MCP) names in it eg at net.minecraft.client.renderer.WorldRenderer.updateCameraAndRender(WorldRenderer.java:1118) ~[forge:?] {re:classloading,pl:runtimedistcleaner:A}

OK, so if I understand you correctly, your point is that the client TileEntity has an Inventory but it's actually useless. You can sync it if you like, and vanilla sometimes does, but it's not used for anything. When the player opens a container, the client container gets a temporary inventory which is synched with the server via the container, not via the tileentity. Vanilla usually creates a new temporary inventory, but if the mod wants to use the useless client inventory in the TileEntity instead of creating a new temporary inventory, it may as well. When I tried it that way in 1.12.2 it led to occasional random visual glitches under stress testing. The problem was particularly noticeable for TrackedInts being stored in the TileEntity (for example - the furnace burn progress would jump back and forth because it was being updated simultaneously by the GUI (container) packets and the TileEntity update packets), but also occasionally occurred for items in the inventory. However if you don't dirty the server TileEntity, or the TileEntity update packets do not synch the inventory (for example you are using a Capability), then I imagine it's not a problem. I can't think of any reason a client TileEntity would need to know the contents of the Inventory, unless it is changing its rendering like the campfire does. In which case using the client tileentity as the container inventory would be a bad idea, i.e. because the tile entity update packets and the container modifications would clash with each other. The worst symptom would be visual glitches I imagine. -TGG

Hi I'm not sure I understand your question, but perhaps this example project might help. JSON model plus TESR, where TESR is one of four different types of rendering https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe21_tileentityrenderer -TGG

Howdy Perhaps related to these two methods: /** * Sets a target position for the client to interpolate towards over the next few ticks * For normal projectiles, this is important in order to make sure that the client stays in sync with the server */ @OnlyIn(Dist.CLIENT) @Override public void setPositionAndRotationDirect(double x, double y, double z, float yaw, float pitch, int posRotationIncrements, boolean teleport) { boolean isInFlight = this.dataManager.get(IN_FLIGHT_DMP); if (isInFlight) return; // if we are in flight, the client tick will force the position, yaw and pitch every tick so we // don't need to set it here; i.e. just ignore it // otherwise, update position and rotation to match the server this.setPosition(x, y, z); this.setRotation(yaw, pitch); } /** * Updates the entity motion clientside, called by packets from the server */ @OnlyIn(Dist.CLIENT) @Override public void setVelocity(double x, double y, double z) { this.setMotion(x, y, z); } For more context, see here: https://github.com/TheGreyGhost/MinecraftByExample/blob/1-15-2-final/src/main/java/minecraftbyexample/mbe81_entity_projectile/BoomerangEntity.java -TGG

HI Pls show your code? And upload your project to GitHub? -TGG

Are you sure? Last time I checked (admittedly a few versions ago now), many of the client Inventories appear to be synchronised using NBT packets for their inventory contents even when there is no open container. Based on my testing (from a few versions ago I admit), there are three inventories; one on the server and two on the client. Using TileEntity as an example: 1a) The Server TileEntity has(is) an inventory. 1b) The Server Container gets a reference to that Inventory. 2) The Client TileEntity has(is) an inventory. It is synchronised to the Server TileEntity via the usual packets for TileEntities. It is not used by the Client Container. 3) The Client Container creates an empty Inventory which is then synchronised to the Server Container's referenced inventory using the Container packets. If you're sure that's not right, I will spend some time testing it on vanilla to see what's actually happening. Cheers TGG

Do you just want your ContainerScreen to read the NBT for an item? That should be automatically transmitted to the client container, assuming you have set the NBT properly. Your ContainerScreen should be able to just read the tag for the ItemStack. Or do you mean - you want your screen to be able to modify the nbt for an item? If so - your Screen will need to send custom packets to the server. Have a look at the vanilla code for Screens, how they drag ItemStacks from one slot to another. Basically, the screen sends a packet back to the server saying "drag the ItemStack from slot X to slot Y". In your case - your Screen will need to send a packet to the server that says "Change the NBT for the ItemStack in slot X for the currently open container", and you will need a packet handler on the server that makes the corresponding modification to the ItemStack in the Server Container. -TGG

Hi DieSieben That diagram is for an ItemStack which has an inventory of other ItemStacks (held in an Item_Handler_Capability) There is no client side link between the Client ItemStack and the inventory contents of the Client Container. If I recall correctly the Client ItemStack doesn't even get a copy of the server's ItemStackHandler unless you manually synchronise it. The equivalent diagram for TileEntity might be a bit clearer what the intent is, ie that the client side container is initialised with empty inventory that is not linked to the client-side inventory. The synchronisation is always from server container to server inventory then to client inventory. If you try to link the client-side container to the client-side inventory, you get two different synchronisation methods fighting with each other (quite noticeable when there is a bit of lag). -TGG

Hi There are a few working examples of redstone in this tutorial project https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe06_redstone http://greyminecraftcoder.blogspot.com/2020/05/minecraft-by-example.html (mbe06) Redstone power has a few different things to understand, in particular weak power and strong power. The link above has more explanation. Cheers TGG

Try adding .notOpaque() to the block properties.

Try looking at CropsBlock.

Howdy You might find this tutorial mod useful; it has a working example of how to create a block with a GUI (in this case - a simple chest) https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe30_inventory_basic -TGG

Howdy You might get some inspiration from this class, it shows the method I've used to make the example mod work with Dedicated Server: https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/MinecraftByExample.java The key bits are: @Mod(MinecraftByExample.MODID) public class MinecraftByExample { public MinecraftByExample() { // We need to split the registration of events into: // 1) "Common" events that are executed on a dedicated server and also on an integrated client + server installation // 2) "Client only" events that are not executed on a dedicated server. // If you aren't careful to split these into two parts, your mod will crash when installed on a dedicated server // It doesn't matter if your client-only code is never actually called; simply referencing the class is often enough to // cause a crash. registerCommonEvents(); DistExecutor.runWhenOn(Dist.CLIENT, () -> MinecraftByExample::registerClientOnlyEvents); } } public static void registerCommonEvents() { MOD_EVENT_BUS.register(minecraftbyexample.mbe01_block_simple.StartupCommon.class); } public static void registerClientOnlyEvents() { MOD_EVENT_BUS.register(minecraftbyexample.mbe01_block_simple.StartupClientOnly.class); } public class StartupCommon { public static BlockSimple blockSimple; // this holds the unique instance of your block public static BlockItem itemBlockSimple; // this holds the unique instance of the ItemBlock corresponding to your block @SubscribeEvent public static void onBlocksRegistration(final RegistryEvent.Register<Block> blockRegisterEvent) { blockSimple = (BlockSimple)(new BlockSimple().setRegistryName("minecraftbyexample", "mbe01_block_simple_registry_name")); blockRegisterEvent.getRegistry().register(blockSimple); } } public class StartupClientOnly { /** * Tell the renderer this is a solid block * @param event */ @SubscribeEvent public static void onClientSetupEvent(FMLClientSetupEvent event) { RenderTypeLookup.setRenderLayer(StartupCommon.blockSimple, RenderType.getSolid()); } }

https://github.com/TheGreyGhost/MinecraftByExample/tree/1-15-2-final/src/main/java/minecraftbyexample/mbe81_entity_projectile