MrChoke

It works! That first error was because I still had a JAVA_HOME env-var set to JDK 11 and gradle by default used that and not 17 like it should. All good. Thanks.

Hmmm, At first I tried 17 and then got errors during the build about one of the jars, don't remember which was compiled with 55 and I was using 61. OK, let me re-install 17 and see how far I get again with that route. Thanks.

I don't know why IntelliJ and/or Gradle keep doing this. I have a fresh new install of latest version 21 IntelliJ. I followed the instructions on how to setup the Forge project with IntelliJ 21. It all worked great. I run any of the generated configurations like "Clean Clean Client" for example. And I get this error: > Task :clean:Main.main() FAILED Error: LinkageError occurred while loading main class net.minecraft.client.main.Main java.lang.UnsupportedClassVersionError: net/minecraft/client/main/Main has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0 LinkageError occurred while loading main class net.minecraft.client.main.Main It compiled the classes as Java 17, not 11. Sure enough I find the .class files at: \projects\clean\build\classes\java\main. I decompile any of them and they are all bytecode 61, not 55. I have JDK 11 installed. I have JDK 11 set in all places I can find in Gradle, module settings, SDKs and javac settings. I made sure I don't have a JDK 17 installed anywhere on my PC either. Anybody know why its doing this?

Ok, you do mean the ai tasks and goals. I have used those a ton including making my own. "Brain" and the sensors I am learning now but that is all new to 1.14 and I had not done this stuff since since 1.13. For example I have them opening trapdoors and fences. Those are new goals I created for the AI. Note you still need to update pathfnding for this too. TRapdoors and fences each have their own PathNodeTypes but the pthfinding is hard-coded to treat them a certain way. An AI task or goal can't change this. ALl it can do is call tryTOMoveXYZ() to the pathfinder code. As far as going up ladders I assure you it is not that simple either. The vanilla pathfinder does not path search up or down ladders. The heart of it is WalkNodeProcessor and findPathOptions. It doesn't check up or down when calling getSafePoint(). And once you get the pathfinding to work you still have to get the mob to actually move up or down. That is harder part. I had to change MoveController and travel. The vanilla code in travel has hard coded 0.2 upward movement on a ladder (that is why you see him use a ladder on accident sometimes) and nothing for down except it stops free fall if you are on the ladder. Non-flying mobs use MoveController to set the "moveForward" and rotationYaw" which travel uses. "moveVertical" exists too however a walking mob never uses it, only flying ones do (it uses FlyingMoveController). travel never gets anything but 0 for moveVertical unless all of the code for a flying mob gets executed. I have learned this code very very well back in 1.1.3 I had fixed numerous bugs too. One in 1.15 that people reported is mobs spinning on scaffolidng and not path finding over it. Not my mod, not anymore. I fixed it. That fix was easy compared to most of the other stuff I have achieved.

Like I say, I have no intention of distributing these mods in any way, my work is only for me. I wanted a jar to run on my laptop as well as my desktop PC, that was the need. As far as using Forge I am not sure what an entity task is exactly. Is that a forge construct?? I know what tasks and goals are for the AI in vanilla. My mod for example allows ALL mobs to go up ladders. I had to make core changes to LivingEntity travel() among other core areas. Sure I can create my own versions of all of the mobs in the game, copy tons of code into my own versions of it, then turn off all of the vanilla mobs (I assume I can do that with forge). Fine, yeah. If I want to publish my mod someday maybe I'll do that Anyway, sorry I asked. I have been burned so many times asking questions here and and on Discord you'd think I would have learned my lesson by now.

Yeah, thanks the rude response. Typical of most of you people on this forum. I am modding for me, not you or anybody else. You tell me how I can use forge to make all the mos climb ladders, open trap doors, open/break fences and a bunch of other cool stuff then maybe I'll "do it right". Until then, too bad. I figure it out anyway at least for the sever. I didn't do the client yet. Thanks again for nothing. BTW, why is there a clean jar and clean release task in the project? I wouldn't have even asked if I didn't see those. Why have them if clowns like me try to use them right?

I have made many changes to the "clean" project available from Forge. I can't use a forge build because many of my changes have no available hooks or ability to do it with Forge. How do I build a jar with my changes? I have tried "gradlew clean:jar" and it said it was successful. But I don't see that it did anything.

I notice that there are two types of ForgeChunkManager tickets you can create, NORMAL ones and ENTITY ones. With entity ones I had hoped that the behavior would be to automatically keep the chunk that the entity is in loaded. By automatic I mean that I do not have to manually force and unforce chunks as the entity moves. In testing it doesn't appear to be automatic. Does anyone know if it is supposed to work this way? If I do have to track the chunk the entity is in, I'd rather not do it as he moves. So that would leave doing it right before the chunk unloads. Any suggestions on this? Thanks.

OK, yeah, read on the wiki, it says render distance. So chunk loaders, I see a ChunkLoader class in the minecraft code. Do we use that to keep chunks loaded or does Forge have some other way? Thanks.

Ok, good to know that it reads/writes to file. Do you know when a chunk unloads?

I'd like to understand more about how chunk unloading occurs. Take for example some custom mobs that are moving around under new AI I wrote. I have them set to never despawn. But I am assuming they will *pause* their movement when the chunk unloads and resume when the chunk comes back. Can someone explain how that works? Thanks.

I am starting to learn how models work. My initial goal though is to be able to change my custom mob's color dynamically (with a mouse click). For the variation in color I have read that blocks and items can use IBlockColor and IItemColor. Can these apply to entities as well? My best guess at this time is NO. Another approach I think is to have different textures for my mob (one for each color) and then use variants to switch the texture. This is possible with entities right? The forge doco I saw talks about blocks and items but says nothing about entities. Any suggestion here would be great. UPDATE: WOW, I didn't even need to post this. Entities are always rendered dynamically. All I need to do is update the texture used in the render class for the entity.

You need to update the pathfinding code if you want the AI smart enough to avoid that block. You can create custom PathNodeType objects (even though its an enum) using a Forge class called EnumHelper. Example: LADDER = EnumHelper.addEnum(PathNodeType.class, MODID + "LADDER", parameterTypes, 0.0F); //0.0 means its as good as OPEN or WALKABLE

By sides, I mean specifying a side, with world.isRemote() or @Side. I guess I will just follow the common sense approach when I add sides. Right now I am running in any integrated server sop I know my code is going need work when I move to dedicated.

I get the concept of sides, a server thread (or separate JVM if dedicated) versus a client thread. What confuses me is when should we specify a side in our code? I know if its rendering stuff it should be client only. But how about other things, like entity movement, AI, process mouse clicks, etc?? Is there someplace I can check or read up on to help with this? I fear I am not specifying the side enough (I barely have it at all) and does that mean I have the client loading and/or doing too much stuff that it doesn't need to.