FredTargaryen

Well I figured it out; maybe this is helpful for 1.14.4 and beyond too. Declare a Vec3d representing the offset in the world. This is how much the world will be translated around the camera. The following statements transform that world offset into screen coordinates, so that no matter where the player is looking the camera moves by the same offset in the world. Vec3d alignedToYaw = rotateAroundVector(offsetVec, new Vec3d(0, 1, 0), player.rotationYaw * Math.PI / 180); Vec3d alignedToPitch = rotateAroundVector(alignedToYaw, new Vec3d(1, 0, 0), player.rotationPitch * Math.PI / 180); //Put rotation first, so it comes out, then turns at the point it came out to GL11.glRotatef(prevRotationRoll + (rotationRoll - prevRotationRoll) * f, 0.0F, 0.0F, 1.0F); GL11.glTranslated(alignedToPitch.x, alignedToPitch.y, -alignedToPitch.z); If you swap the rotate and translate, this is effectively rotating your offset vector and you won't see a camera tilt. rotateAroundVector is a function that takes one vector and returns the rotated vector using another vector as the axis. You can implement your own or see an example implementation here.

This might not help (sorry) but I have a TESR which draws long tracks which used to disappear when looked at from a certain angle, with the block off the screen. That was only fixed by overriding isGlobalRenderer, returning true. This might hurt performance if you plan to have a lot of these blocks but I didn't have any problems with about 50 of those blocks on the screen (didn't try any higher).

Hi, This gif from a 1.7.10 mod shows the camera turning as the coaster turns. It feels like the camera is fixed onto the coaster. It accomplished this with a coremod that inserted a GL11.rotated call at the start of orientCamera. For some reason, trying the same thing in 1.12.2 produces this! The camera hovers above the coaster in the world regardless of its orientation. I've experimented with a lot of different GL translations to replicate the first effect but it's been difficult trying to find translations that work for all camera orientations - made more difficult by those translations being relative to the screen rather than the world, so knowing where the camera should be in the world relative to the coaster is not enough. Trying this using the CameraSetup event has the same effect as the second gif but the mouse no longer lines up with where the player is looking. So I am hoping that anyone out there knows any of: GL commands to move the camera along the world axes instead of the screen axes How to convert some world coordinates to screen coordinates, so that maybe I can move the camera that way (I thought about maybe using the modelview matrix but don't know the best way to get hold of that) A different method that accomplishes the original effect Why the effect of added roll has changed between 1.7.10 and 1.12.2 The obvious answer that I've probably missed because of massive tunnel vision Anything else that might help Thanks for reading.

This was flagged up as an issue on the MinecraftForge GitHub but unfortunately it hasn't gone anywhere yet.

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.

It's not an anti-cheat but I need to check speed every tick, or as near as possible, because I want blocks to respond to the player speed before the player can collide with them. I didn't want the heavy traffic of movement packets, or to have to deal with the latency of packets being sent, so I tried to make it all server-side, but as you can see that didn't work. Yeah, sending the average speed every few ticks sounds much saner than every tick. I will try it.

So I suppose sending my own packets from the client each tick as as accurate as I can get then. Just gotta pray it doesn't prove too intensive. Thank you all for your answers so far; not marking as solved just yet in case I have a brainwave.

So does the server not move players around at all? The position only updates on the server when the client tells it to update? I assumed if the player was falling for example the server would process that without waiting for client info.

I made a timer and after checking with that, realised that I'm not actually skipping any ticks. I removed a minimum distance that I had put into the code and realised the mode distance travelled each tick is actually about 0.215, which is consistent with the wiki. However during a normal forward walk, the distance in one tick can still sometimes be set to 0.43 or higher, which is faster than sprinting. This is bad for my code because ideally I should be able to check if the player is definitely moving at sprinting speed or faster in just one tick. My best guess is that the server occasionally moves the player ahead further than their movement suggests, in which case I'm at a loss as to what to do about it (I probably shouldn't be doing anything about it). I could keep track of the mean speed over several ticks but these outliers are so high that the mean might still be faster than sprinting. I'm thinking about tracking the mode of the last few tick distances, and assuming the mode distance if the latest distances are out of line with the mode. This probably gives me the best chance of getting the right speed but it does mean a change from walking to sprinting, for example, wouldn't register for a few ticks. If anyone has any better ideas I'm all ears.

Yeah, I only have a potato to develop on so I often get "Server is 23123s behind, skipping 1024 ticks" or words to that effect. I thought if ticks were being skipped then PlayerTickEvents would not fire so the prevPos values weren't being updated, so the speed would look faster when the next PlayerTickEvent fired. Maybe that doesn't quite make sense but I was just guessing. OK, I'll set up a timer and see what happens. Thanks!

Have you registered the sounds in the FMLPreInitializationEvent handler of your mod class? If not, "ForgeRegistries.SOUND_EVENTS.register(GALOPIN_AMBIENT);" should do it. I've never needed to use SoundEvent.REGISTRY.getObject.