don_bruce

Just figured out what I did wrong: I forgot to super initGui() in GUIPropellerBench. That super function initializes the player inventory and syncs it with the player slots in the GUI. Don't know how I missed that...

You're only overriding that method on the Entities that you create, so inherently there's no incompatibility. If a mod overrides default collision handling, your mod will override theirs, as you're overriding the default method that they overrode. While this might seem like you're breaking their system, consider that their code would have broken yours. In general, you don't want to mess with default Minecraft code. Just create your own that works the way you want it to.

Rather than creating a new bounding box system that will cause headaches, why not change the action that's performed when a player collides with your model? It should be simple. First, ensure the current bounding box covers the entire model, even when rotating. You can view the box by pressing F3+B to ensure it's the right size. Next, override applyEntityCollision to get rid of the default bounding-box based collision system and create your own. If your entity is a triangle, you can use the entity's rotationYaw to find out where the slope is and whether or not to you need to prevent movement. More complex entities would have to be broken up into parts, but that's no different than breaking up your model mesh. You could also link multiple entities together to make a collision system. It's what I do for one of my mods. That's much more difficult, though, so I'd recommend sticking with a collision mesh if you can.

I'm experiencing some odd behavior with one of my blocks. Specifically, I have a TileEntity that implements IInventory that's messing up slot data. Right now I just have it open a GUI that has the standard player inventory. The inventory is just fine on the server (checked with println statements), but for some reason all slots are shifted by an index of 9. By this I mean that I can have an item in the left-most slot on my hotbar, but upon opening the inventory it suddenly warps up one slot to the lower-left slot in my internal inventory. Although the item (and tooltip) is in the upper slot, I can only grab the item if I take it out of the lower slot, which tells me the slot data is correct on the server. Opening the TileEntity GUI results in no change, unless I open the Player GUI first which appears to save the 'new' slot position. This warping happens until the item goes out of the inventory index, and sometimes results in my player becoming a literal blockhead. I know it's linked to container slot assignments, as each non-player slot assigned to the container results in items shifting one less slot. The code for the player slot data is copied directly from ContainerChest, and works fine on one of my custom Entities, as does the inventory code, so I can't fathom why it's not working on my TileEntity. Hopefully someone here can tell me where to start looking. Currently running Forge 1.7.10-1558 Class Files BlockPropellerBench TileEntityCrafter GUIPropellerBench ContainerPropellerBench

Never thought of using selective collision. That would take care of the spawning issue, though saving the data would be a bit of a problem as you say. Bouncing the ideas off of you got me thinking that the true issue was that children moved on the client at different points in the game tick. I was already using a tick handler to check to see if the player was in a plane, so I hooked into that to move children on the client. This works just fine, as children on the server update after the parent moves, while the children on the client move all together at the start of each tick. Thanks for all your help; I'm marking this as solved.

You're correct in that registration order has nothing to to with the problem; I register all my entities in the common proxy at initialization. What I'm encountering is that the spawning order of the children relative to the parent determines whether they update correctly. Any child that is spawned after the parent has its onUpdate() method called after movement is applied by the parent, while any child spawned before the parent has its onUpdate() called before the parent moves all the children. It's this calling scheme that leads me to believe that whatever's calling onUpdate() is also adjusting the rendered position of the children. Since the movement hasn't been applied for some children at that point, they don't update their 'positions' until the next tick. As to the dragon, this line in the EntityDragon(World) constructor is the one I'm talking about: this.dragonPartArray = new EntityDragonPart[] {this.dragonPartHead = new EntityDragonPart(this, "head", 6.0F, 6.0F), this.dragonPartBody = new EntityDragonPart(this, "body", 8.0F, 8.0F), this.dragonPartTail1 = new EntityDragonPart(this, "tail", 4.0F, 4.0F), this.dragonPartTail2 = new EntityDragonPart(this, "tail", 4.0F, 4.0F), this.dragonPartTail3 = new EntityDragonPart(this, "tail", 4.0F, 4.0F), this.dragonPartWing1 = new EntityDragonPart(this, "wing", 4.0F, 4.0F), this.dragonPartWing2 = new EntityDragonPart(this, "wing", 4.0F, 4.0F)}; That seems to indicate to me that whenever the dragon's class is loaded, either from spawning or from disk, new child entities are created. Interestingly, those children don't seem to ever get spawned in the world, as only EntityDragon gets sent into a spawnEntityInWorld() call. Does this mean I shouldn't be spawning my children?

I've poked around in the dragon code before. After studying it for a while, I've come to suspect that the dragon has the same issues I'm having. This is evidenced by the fact that the dragon spawns a new set of children each time the constructor is called, and leaves the old set orphaned. Since the children are spawned within a constructor, they don't get antsy like entities spawned post-constructor. This method won't work for me, as I want to be able to add entities to the plane post-spawn (like adding a wheel to repair one that broke). My updating methods are the same as the dragon's, though, as the dragon simply moves the parent and then each part in sequence. To test my code some more, I changed the parent to only update its position every 20th tick. I then added print statements showing positions after moving the parent, after moving a specific child, and in the specific child's onEntityUpdate() method. Through this I was able to confirm that the parent DOES have its position set before any children do. Each child also gets its position set directly after the parent sets its position, and doesn't change position after the parent does. There was an odd trend I noticed, which was that any child who was spawned after the parent had its onEntityUpdate() triggered that tick, while any child who was spawned before the parent had to wait until the next tick. I'm starting to suspect this is a rendering routine error, considering that the this problem only happens on the client and the positions are fine. It'd make sense, as normally Minecraft doesn't have to worry about multipart entities and can just run through the loaded entity list for rendering updates. Even the dragon doesn't have to worry too much, as the whole dragon is rendered by the parent, and so jittering children wouldn't be noticed unless someone was looking at the bounding boxes. I'm hoping this isn't the case, though, as it'd mean I have to go and re-work most of the entity-linking code.

You're correct on that jabelar. The whole reason I'm making separate entities is so I can implement multipart collision. For example, how can a plane land realistically on three wheels if the bounding box is just for the entire plane? It also allows me to be a bit more creative with rendering options, like making a wheel turn only if it hits the ground, and making it break off if the plane clips a house during takeoff. Yes, I could compile all the code into one entity, but then the plane wouldn't handle like a real plane, which is the whole reason I'm making this mod.

Normally I'd rely on the built-in tracker method; however the tracker is being troublesome in that it won't sync correctly. I posted this problem earlier on the Minecraft Forums page here, which I believe you were helping me with, jabelar. The end result was that I tracked down the method the tracker uses and overrode it to prevent the tracker from setting positions. I thought that that might be the issue, but re-enabling that method doesn't fix the problem. As to my packets: I only send packets to the parent entity. Like the dragon, my children are dumb and don't move themselves. They don't even get velocity information, as the movement is done using setPosition(). The only place I move a child is in the moveChildren() section of the parent, which happens after the parent calls moveEntity(). This should ensure that all the children are moved at the same time, right? As to rendering them within the same call as the plane, that strikes me as a bit of a kludge. Either way, I need an actual entity present to do collision detection, and some of the entities do special things (e.g. propeller entity changes texture if different model is given and applies damage to mobs). The linear interpolation is pretty spot-on, as I move the children every tick and apply a rotation matrix using pre-set offsets. Assuming no entities get antsy in their updating, you can't even tell that the plane's made up of multiple entities.

For the past month I've been working on an airplane mod that uses multiple entities for different components. Each entity represents a specific part of the plane, like wheels, propellers, or fuselage points. To tie all the entities together, I link each to a parent, which moves all its children each tick. I've got all the children moving just fine, the problem is that children spawned AFTER the main parent class move a split second BEFORE the parent does. This means that any entities spawned within an extended parent constructor move with the parent, but any entities added after the parent is spawned move too early. This is particularly troublesome when loading a saved world, as each entity gets loaded at different times and can cause an unspecified number of out-of-sync children. Currently the parent's onUpdate method runs on the server and client to allow for fluid motion, with syncing packets being sent every 50 ticks. I changed the onUpdate method to only run server-side, and then having sync packets sent every tick, which caused the stuttering to disappear, suggesting that this is a client-side issue. Below is the routine where the children are moved, and the constructor for the parent entity. The constructor is called by right-clicking an item, which simply executes world.spawnEntityInWorld() with a new parent entity provided. Child Movement Section Item Code Parent Constructor Spawning a plane with this setup results in the two EntityCore entities following the parent perfectly; however any entity spawned afterwards skips ahead. Oddly enough, editing the item's code to create a new plane, but holding off spawning it until after the cores have spawned results in the cores not following the parent correctly either. This suggests that there's something that Minecraft is doing after spawning the parent entity that's causing all the linked children to get out of whack. I really don't see what it could be, though, as all the child entities are moved in the same loop of code. As a visual reference, here's two links to a couple of gifs that demonstrate what I'm talking about (note that jumps happen every tick; the gifs don't have enough FPS to display that). The first gif is with the default item-constructor, while the second gif is the modified item-constructor. In both gifs my character is riding a child, so any entity that's not wiggling is actually updating early. Gif#1: http://i.imgur.com/v5Y8sWx.gifv Gif#2: http://i.imgur.com/8F9fbUH.gifv Hopefully somebody knows what's going on, cause I sure don't!