Leaderboard

If my understanding is correct, .executes() needs to put inside the bracket of the .then (all "connected" action needs to do that)which should look like this root.then(Commands.literal("edit_a_float") .then(Commands.argument("float", FloatArgumentType.floatArg()) -> removed two brackets here .executes(source -> { return editPower(source.getSource(), source.getSource().asPlayer(), FloatArgumentType.getFloat(source, "float")); }))); -> added two brackets here

I misunderstood the problem. I am not sure, then.

I think you need a custom Teleporter class. Been a while since I looked into it, but I recall that if you don't have one, vanilla is like "oh you changed dimensions, lemme just build a nether portal for you..."

No problem, glad I could help!

really, now it works thanks you very much!

Sort of. The mounting can still be disabled. Only dismounting is bugged. The issue is that the client does not tick the PlayerEntity unless it is not riding an entity causing the movement flag to always be set to true.

Thank you! Now it's working

Either you do, or Mekanism does.

Double check your system environment variables for I think it's JAVA_OPTS or something like that that is setting -Xmx2G

That's terrible, and I mean the app. That app has stolen the .jar file extension from Java, run JarFix to fix the issue.

https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/opes/tiles/GrinderTile.java#L79 You need to clone this stack or things will go very wrong indeed. https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/lib/inventory/outputStackHandler.java#L7 This class should start with a capital letter to follow naming convention https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/lib/inventory/outputStackHandler.java#L17 You do not need to override this method, you're not doing anything that the base implementation does not already do. https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/lib/inventory/ProcessingBlockItemHandler.java#L10 This comment is objectively wrong. The int passed there is how many slots the handler has, so this "won't be shown" stuff is bollocs. https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/opes/tiles/GrinderTile.java#L80 This line assumes that all outputs are size 1. This may or may not be true. And finally, you have no data assets which use your recipe type, but the above issues not withstanding, your grinder is compatible with any mod that has a recipe that matches your grinder recipe.

Because you never know when a static block will execute, and if it executes too early, Forge can't insure that it has full control over the object. (Forge does lots of lots of behind the scenes magic and dangerous sorcery that you, as a modder, don't need to worry about, but that if it isn't done in order, things break)