MrChoke

What if I pulled down the 1.13pre branch right now? Would it even build yet? Can I see the converted 1.13 code? And last question, do you guys need any help finishing it?

So I finally got my new mob to pathfind ladders and move up and down them. It is really cool. However in order for me to do it, I had to override two big methods, move() in Entity and travel() in EntityLivingBase. It's ok enough that I had override them but they both reference private variables (a method too I think). Oftentimes these variables are used in other methods. I can't override everything and I don't want to. So I find myself having to use reflection again to get the value of the private vars in my methods, update them and set them at the end. It's a pain. I know Mojang does what they want and its up to us to adapt but why so many private methods and variables? Can we do something about this in Forge? Or is that too much change?

Ok, yes I saw that project. I thought that may have been the new approach. Is this project up-to-date that it can process the 1.13 code?

What is the replacement project? I thought it would be possible to get the "non-forge" version of the code like what is available here for older releases: http://www.modcoderpack.com/website/releases Is the better project going to give that as well?

Question I have is whether the 1.13 version of MCP comes out before Forge 1.13, or do you they usually get released at the same time? My understanding is the forge team is doing both.

I came across this code in removeSUnnyPath() in PathNavigate(): PathPoint pathpoint = this.currentPath.getPathPointFromIndex(i); PathPoint pathpoint1 = i + 1 < this.currentPath.getCurrentPathLength() ? this.currentPath.getPathPointFromIndex(i + 1) : null; IBlockState iblockstate = this.world.getBlockState(new BlockPos(pathpoint.x, pathpoint.y, pathpoint.z)); Block block = iblockstate.getBlock(); if (block == Blocks.CAULDRON) { this.currentPath.setPoint(i, pathpoint.cloneMove(pathpoint.x, pathpoint.y + 1, pathpoint.z)); if (pathpoint1 != null && pathpoint.y >= pathpoint1.y) { this.currentPath.setPoint(i + 1, pathpoint1.cloneMove(pathpoint1.x, pathpoint.y + 1, pathpoint1.z)); } } I read it like if a cauldron is along the path the AI is going sit there one extra move?? Didn't read that anywhere on the wiki..... Don't know why that would be in there.

I am going give up on it myself. My best guess though I cannot confirm may lie in use of a class called SPacketEntity. It has this code: public void processPacket(INetHandlerPlayClient handler) { handler.handleEntityMovement(this); } There is this class called: PacketThreadUtil that seems to run a bunch of scheduled tasks. A packet for handling entity movement is one of them.

@jabelar All that code in EntityTracker and EntityTrackerEntity is great but only if the entities make it into: private final Set<EntityTrackerEntry> entries And unless track() is called on an entity, it never gets in there. That includes all vanilla mobs. There must be a completely different system for them somewhere. I will say that setting 512, 2 on my custom mob fixed its issue. The rubber-banding stopped. So there is that.

Ok thanks. So from that track method, sounds like you are saying use this: this.track(entityIn, 512, 2); Still wish I knew more about how vanilla mobs don't need it at all. I probably need ot look at the code more I guess.

I have a custom mob based off of a zombie. The thing was moving much faster and more jerky (sudden stops and starts) then the vanilla zombie. It took me quite a while to figure out why. It is because of the EntityTracker. This thing is like a black box to me. I don't get it. Why set speed values for the entity when the tracking values seem much more critical? Also, you say use vanilla whenever possible. Almost all vanilla mobs don't set anything!!! See EntityTracker class, method: public void track(Entity entityIn) Mobs do not get tracked. Yet I believe Forge makes us set tracking values when we register a mob. For mine cusotm Zombie I set 64 and 20. The only way I got my mob to moving normally was by commenting out the first line in this method: if (net.minecraftforge.fml.common.registry.EntityRegistry.instance().tryTrackingEntity(this, entityIn)) return; I killed the forge hook. Can someone explain why vanilla works fine with not having tracking set and Forge makes us set values? What should I use to make it act like a normal mob? Thanks.

Ok, what are good suggested values for: updateFrequency, sendVelocityUpdates for a new type of Zombie? I was going to use 64 and 20... I also saw examples of 80 and 3 but that was for animals like sheep.

I came across this minecraft class while learning how to register stuff in Forge. What is it for?

Dinnerbone just released the very cool auto-complete system that 1.13 has built-in to commands. They call it Brigadier. He says we can use it where ever we want. But he gives no info as to how it can be used. I would think we'd still need some kind of modding tool like Forge to even be able to interface with the Minecraft game code. I guess they assume people use a modding tool and then incorporate Brigadier into their mod?

You mean I call the new field something like "MYMOD_FENCE_OPEN"?

Just wanted to let you know, that was a piece of cake to add. And the built-in valueOf() method works too: final Class[] parameterTypes = new Class[] { float.class }; PathNodeType FENCE_OPEN = EnumHelper.addEnum(PathNodeType.class, "FENCE_OPEN", parameterTypes, 0.0F); PathNodeType test1 = Enum.valueOf(PathNodeType.class, "FENCE_OPEN"); if(test1 == FENCE_OPEN) { System.out.println("PASSED!!"); }

Oh ok. Yeah that makes sense. Thanks!

Still not seeing how I can reference the new enum value as a constant... I am looking at the HroseArmor stuff....

I will look at the code you sent me. Seems like I can call addENum() from EnumHelper. That is fine too. So for my question on referencing it at runtime, would this built-in Enum method work for the runtime entry? static <T extends Enum<T>> T valueOf(Class<T> enumType, String name) If so, I think this will work.

Explain how its not required unless I start lifting EnumHelper code which I agree is a very bad idea. Though, please help me with my other question. How do you reference one of these new enums in code?? PathNodeType.NEW_TYPE sure won't work.

A method like "addPathNodeType" would be great. It doesn't exist! We need one. I smell a forge pull request coming....

Ok. Of course it still won't let me do something like this: PathNodeType.NEW_TYPE Since the compiler will fail that. But perhaps it will allow me to keep a lot of existing code at least. But how do I reference one of these new runtime enum values then??? So any chance of PathNodeType being added to EnumHelper?

WOW, that code is deep. I read enums are read-only, PERIOD. That is some serious hack-like code. It is using "sun" objects for example. Oh well. If it works great. I will see if I can copy part of it. Too bad PathNodeType is not handled already. Can that be a Forge change?

I am writing my own custom PathNavigator and NodeProcessor. And I am finding I can't extend anything from existing code because Mojang decided to make PathNodeType an enum. This enum is used all over the place in path finding and even in some other entity code. What if I need to define my own path nodes types? For example, I want to be able to break fences. Well, too bad trying to use any of the existing code because with an enum I can't add anything to it nor can I extend it. I don't know how many people have seen the 1.13 code yet. Did Mojang change this? If not, can we change this in Forge? I'll write the code if I need to. Thoughts?

OK, check them both out. EntityConstructing is called in the "Entity" class base constructor, so its before any other one. Seems like that is only good if you want to modify something on Entity only, not any sub-class. EntityJoinWorld however is perfect. It is called after the entity is built and called for natural spawn, command spawn and spawn egg. Thanks!

UPDATE: If anybody cares, I found root cause and fixed this Mojang bug. Yes, I know its fixed in 1.13 but I wanted to see if I can fix it anyway. It turns out its not a bug in ray tracing (the logic for what a mob can see), or path find, or the AI. It was a bug in the door blocks themselves. The blockstate's "open" property for the upper blocks of the doors was never being updated. It stayed "false" even when the lower block was "true". Most of the code that uses doors only look at the lower block but the path finding logic does not. When a mob is 2 blocks high both blocks have to be clear. The upper block was coming back as "DOOR_CLOSED" and the AI never went through. My fix is to set the block state of the upper block whenever the lower block was changed. It seems to only be needed in two places.