FredTargaryen

Sorry, I screwed up. The TileEntityType was null because I had forgotten to make that variable an ObjectHolder. Thank you anyway!

My mod is supposed to allow users to customise any tile entity's behaviour by entering its ResourceLocation string and other parameters in a text file. This text file is imported at runtime and used to add Capabilities. For a given TileEntity object , it should obtain the ResourceLocation and use that to search the data imported from the text file. In 1.12, I got that data for any given TileEntity by using the registry in the TileEntity class, which mapped between ResourceLocations and TileEntity Classes. In 1.13, it looks like that registry has been replaced with ForgeRegistries.TILE_ENTITIES, which maps between TileEntityTypes and ResourceLocations. However, when a Capability is constructed I can't get the TileEntityType because TileEntity variables are always null or 0 when Capabilities are being added. It seems that the Class is the only distinguishing information I can get from a TileEntity object when Capabilities are being attached. Is there a simple way around this that will let me keep using ResourceLocations, or will I need to ask users to enter the Class name instead of the ResourceLocation? Thanks for reading.

Ah, I'll look into DataFixers then. Thank you!

Well like I say I didn't see MissingMappingsEvent fired for tile entities. GameData doesn't seem to call makeRegistry for tile entities either. I'll change the ResourceLocations; guessing because your way is harder to screw up and avoids an extra function call?

Yep, I don't want to lose data from a world made before changing the ID. The TileEntity stores teleporter data, so on a world with lots of teleporters players would have to break and replace all their teleporters and that could be tedious with a lot of teleporters in the world. I also have another TileEntity which has an inventory, and I wouldn't want players' items to be destroyed. I can keep the IDs the way they are; I'd just like to be able to change the ID to make my code a bit more consistent.

I want to change the line GameRegistry.registerTileEntity(TileEntityFireplace.class, new ResourceLocation(DataReference.MODID+":fireplaceTE")); to GameRegistry.registerTileEntity(TileEntityFireplace.class, new ResourceLocation(DataReference.MODID+":fireplace")); but if I run post-change Minecraft with a pre-change world I get the error [15:23:33] [Server thread/WARN] [minecraft/TileEntity]: Skipping BlockEntity with id ftfloocraft:fireplace and the TileEntity is gone, because there doesn't seem to be an opportunity to remap the pre-change TileEntity to the post-change ResourceLocation. MissingMappingsEvent didn't seem to fire for TileEntities. My only idea right now is to register the tile entity once with the old ResourceLocation and once with the old one, and then somehow migrate the NBT data over. Is there a better way? Thanks for reading.

Do you happen to know why? It seems like a deliberate decision

Something I'm working on right now needs to be able to rotate minecarts on the z axis before they render, so I wrote the whole thing thinking there would be some kind of RenderEntityEvent I could use. I've found RenderPlayerEvent and RenderLivingEvent but I can't find anything that fires for just any entity. My guess is it hasn't been implemented because it would fire a lot, which I sort of understand. I'd really appreciate one of these in a future Forge version, or at least the reason why it hasn't been implemented... or if it actually has been implemented can someone please tell me how to use it? I know one workaround involving overriding the handler in RenderingRegistry; as far as I can tell registering the new handler requires you to know the class of the entity to override, which is not great if you want to use Capabilities to work with mod entities as well. Thanks for reading.

The log says the crash is because of line 26 of EntityKnowledge, in the constructor, but in your pasted EntityKnowledge code line 26 is just defining canBeRidden... is that definitely the same EntityKnowledge code that produced that crash log?

Ah never mind, I messed up. Code from 1.7.10 does work after all. Oops😅

Sneaky bump just in case; won't do it again

Hi everyone, I've been porting a mod from 1.7.10 which had no problem rendering entities with models imported from .obj files; it just called renderAll() and that was that. I didn't find something similar in 1.12.2 so have naively written my own renderer, which looks like this (renderWithNormal function): https://github.com/fredtargaryen/ExRollerCoaster/blob/1.12.2/src/main/java/erc/renderer/ModelRenderer.java Here's the result: https://imgur.com/a/EJbBQ31 So it looks like if it's going to render a face, it won't render any faces that share an edge with that face... the problem is probably deeper than just that though. Things I've considered so far: Invalid .obj file: the .obj worked with 1.7.10, and importing it in Blender shows all the triangles. Bad renderer: I have copied the rendering code from decompiled Forge 1.7.10, and as far as I can see the model was the same. Personally I can't see why my naive renderer wouldn't work. Model importing wrong: the OBJModel object has the same number of faces as the .obj file has. There might be some kind of check the importing code does which changes point coordinates; I haven't checked whether all the values are the same yet because that could be a long, tedious process. So my guess is there's some quirk with how 1.12.2 does graphics, that may have led to that renderAll system being removed? Though of course I am open to the suggestion that my renderer's bad. Anyone know what's going on here? Thanks for reading.

I was wondering if nowadays there is a good way to freely control the camera, possibly with the GlStateManager? I've tried it in the RenderTickEvent but it didn't seem to have an effect. From what I have read so far the usual solution is to make a new renderViewEntity and use that; unfortunately that still doesn't allow the camera to roll. I am porting a mod which in 1.7.10 was able to freely control the camera, but it did this with a coremod, and I don't want to use that because it's terrifying not good protocol. If this isn't possible, is it worth suggesting for Forge 1.13? Thanks for reading.

So in light of the fact that the client is the only good source of speed info, I have found a compromise to this problem which works pretty well. When an AttachCapabilitiesEvent is fired for the player, if the player's world is remote I construct a listener object and register it with the Forge Event Bus (if not remote I attach the capability). Each tick the listener calculates the speed of the player and compares it with the previous speed. If the current speed differs from the previous speed by more than 0.01, only then do I send a packet (there is still variation on the client but it is extremely subtle compared to the server) and update the previous speed. The packet then updates the speed on the Capability on the server. So on the server, instead of trying to calculate the speed from player variables, the last speed sent from the client is used. To account for the latency of sending the update packet I run the break code by simulating collisions ahead of where the player will be next tick, so the blocks break as if the player has been moving for three ticks instead of one. Most of the time this produces the effect I was looking for. Thank you to everyone for your help and advice! Code: @SubscribeEvent public void onBreakerConstruct(AttachCapabilitiesEvent<Entity> evt) { final Entity e = evt.getObject(); if(e.world.isRemote) { if(e instanceof EntityPlayer) { MinecraftForge.EVENT_BUS.register(new Object() { private EntityPlayer ep = (EntityPlayer) e; private double lastSpeed; @SubscribeEvent(priority=EventPriority.HIGHEST) public void speedUpdate(TickEvent.ClientTickEvent event) { if(event.phase == TickEvent.Phase.END) { double speed = Math.sqrt(ep.motionX * ep.motionX + ep.motionY * ep.motionY + ep.motionZ * ep.motionZ); if(Math.abs(speed - this.lastSpeed) > 0.01) { MessageBreakerMovement mbm = new MessageBreakerMovement(); mbm.motionx = ep.motionX; mbm.motiony = ep.motionY; mbm.motionz = ep.motionZ; mbm.speed = speed; PacketHandler.INSTANCE.sendToServer(mbm); this.lastSpeed = speed; } if(ep.isDead) { MinecraftForge.EVENT_BUS.unregister(this); } } } @SubscribeEvent public void killObject(FMLNetworkEvent.ClientDisconnectionFromServerEvent event) { MinecraftForge.EVENT_BUS.unregister(this); } }); } ... } For a ridiculous block comment thesis about my block break system you can see here.

I did used to have this as a block as you described but for various reasons, a lot of which I can't remember, I decided it would be best to make this a player thing. The main reason is I'm making fragile glass blocks, so I would expect players to use them like glass blocks, i.e. TileEntities all over the place if they make a big building or window. Those TileEntities would be constantly checking for players even if none were close enough, and if they're next to each other they'd be unnecessarily checking the same player twice or more. Luckily I have my version control so I can branch if I don't get anywhere with this, but I am getting a much better effect this way for every entity... except players. I'm thinking of only sending a message when the player changes speed significantly... but I need to see some client motion values first, and if they're as unpredictable as the server that won't really be possible.