warjort

Now you have a conflict between DataFixSlayer and LazyDFU, you can't have both. DataFixSlayer is probably the one you want to remove. Again it wasn't in your original modpack. Do you remember which mods you added to the modpack? If you are going to add mods to a modpack, it is better to do it one by one so you can easily see which of them are compatible.

NOTE: I never looked at this before, this is my quick assessment. The answer to your question is kind of complicated and inconsistent. Some places use entity.getY() -1.0D while the main LivingEntity.getBlockPosBelowThatAffectsMyMovement() uses getBoundingBox().minY-0.500001D So if you are not a full block, it will probably look at the block below, but not always if you are bigger than half a block. How the boat handles friction is a different story. 🙂 Overriding is probably difficult since the checks are calculated using the entities location to find the relevant block. This is only indirectly related to your block given that the entity will be standing on top of your bounding box. This means there is no place where it looks at your block during the calculation.

So the opposite of what I said. 🙂 I wonder how many other modders don't realise code executed directly in the setup event is potentially not threadsafe? It kind of breaks "the principle of least surprise". The only mention in the javadoc is a throw away "This is a parallel dispatch event". You might not appreciate what it is telling you since it just looks like a redundant restatement of the parent class. The ParallelDispatchEvent has no javadoc itself explaining how it works. I'd always assumed ParallelDispatchEvent was an "executor" for parallel work, given the methods look like they say they "queue work on a parallel dispatcher", hence my misunderstanding above. -- End Rant --

Here's an example of Botania spawning a pixie (you can ignore the bits about the sword and the potion effect). https://github.com/VazkiiMods/Botania/blob/f419d200f480515d596125c078f59fe868513ea0/Xplat/src/main/java/vazkii/botania/common/handler/PixieHandler.java#L77 NOTE: How it must be done on the server side. !player.level.isClientSide

Pretty sure sulfuric and radon are both ports of phosphor. You won't be able to run them together, e.g. they can't both redirect that method. https://github.com/Asek3/Radon/blob/663c52618a07d1c8fb62111be8a49e5ce5000f5b/src/main/java/net/caffeinemc/phosphor/mixin/client/world/MixinClientWorld.java#L20 https://github.com/Someone-Else-Was-Taken/Periodic-Table-Reforged/blob/351d42880003941a1eebd3b41a769da287c4bede/Legacy Phosphor/src/main/java/me/jellysquid/mods/phosphor/mixin/client/world/MixinClientWorld.java#L21 I don't see radon in the modlist of your original modpack (better minecraft plus), so I guess you can remove that mod?

As I understand it, it is used to run setup tasks in parallel (including with other mods in the same loader stage) if you have something that takes a long time. Using it for simple tasks like that simple rendertype registration likely takes more work in terms of the overhead of scheduling the tasks on different threads? And like you say, it could cause problems if the code being called is not threadsafe. setRenderLayer() is a synchronized method added by forge so it wouldn't cause an issue for that.

You already have them downloaded in your mods folder jei-1.16.5.7.7.1.152.jar and RoughlyEnoughItems-6.5.436.jar You need to remove one of them.

The environment variable the OS uses to find executables. echo %Path%

run.bat doesn't reference JAVA_HOME? Its just going to use whatever is in the path

On the command line type "where java" to find its location and then "java -version" to err... You should see something like:

No its the same error:

If you are still getting the error. then the original problem probably wasn't quark. There is some other long running process that is taking a long time. It just happened that quark was doing something when the timer hit 60 seconds and got the blame. e.g. that long running process took 59 seconds then quark used 1 second Your current error shows it happening when astral sorcery is doing something with entity collisions. But that is also probably a false report. To get more concrete information you can try using a profiling tool like: https://www.curseforge.com/minecraft/mc-mods/spark This link in their documentation should give you some background about your problem: https://spark.lucko.me/docs/guides/The-tick-loop

Or wait for this fix to forge: https://github.com/MinecraftForge/MinecraftForge/pull/8671 See https://github.com/Chisel-Team/ConnectedTexturesMod/issues/184

https://forums.minecraftforge.net/topic/113059-1182-cant-launch-minecraft/ Look at the bottom.

The error says you have a bee with an attribute. But the attribute has not been registered with minecraft/forge. Since you only have 2 mods, just remove each of them individually and see if it fixes the problem?

The error says something is taking a long time on the server thread. Minecraft crashes by default when this is longer than 60 seconds. The stacktrace says the server thread is currently doing advancements in response to quark unlocking some recipes when a player logs in. It doesn't look to be blocked, so it might be looping? You should contact the mod author, since it looks like you have the latest release for 1.16.5

> but i dont have friking idea where that piece of code would go As I said on the other thread, it goes in your client setup code. See doClientStuff() in the example mod https://github.com/MinecraftForge/MinecraftForge/blob/1.16.x/mdk/src/main/java/com/example/examplemod/ExampleMod.java

You are looking in the saves folder - this is the world data - don't delete anything from there! The error says "Failed loading config file Mekanism/general.toml" so it will be in your config folder. WisentPack/config/Mechanism/general.toml Deleting the file will mean it recreates with default settings. This might not be correct if the modpack author has changed some settings. Downloading the client version of the modpack should have the correct version of this file if it has been changed. The config should be the same? It is probably a good idea to ask the modpack author.

Your code looks very different to the iron bars block. I don't think most of your shape stuff is relevant to this problem, mostly I think the shapes get used for things like entity collision and drawing hit boxes, etc. The real stuff for the rendering will be in your blockstates and models json. To check you have all the code in the right place for a transparent block, it might be easier to try to code something like a new leaves block which has a much simpler block model, but it still uses cutoutMipped. Sometimes the problem is not that you don't have the right code, instead the code is in wrong place, or it has a typo, etc. Doing something simpler helps to get rid of irrelevant complications.

I think I took your question too literally? What you really wanted is to find all players within a certain distance of your entity? You can do that with some code like this: // This will only work on the logical server public static List<ServerPlayer> findNearbyPlayersForEntity(Entity entity, double distance) { ServerLevel level = (ServerLevel) entity.level; return level.getPlayers(player -> entity.closerThan(player, distance) && !player.isSpectator()); }

Maybe you want? this.closerThan(player, distance); Where this is an entity and the distance is in blocks.

Known issue, stoneholm doesn't yet support 1.18.2 https://github.com/TheGrimsey/StoneholmForge/issues/18

Its hard to say without seeing what you have actually done. Maybe? (the same as IRON_BARS) ItemBlockRenderTypes.setRenderLayer(YOUR_BLOCK, RenderType.cutoutMipped()); in your client setup.

problem with the lootr mod. report it to the author.

Looks the same as this? https://forums.minecraftforge.net/topic/112091-game-crashes-as-i-load-a-modpack/