Creators-of-Create
Furnace Minecart contraption doesn't stop when mining blocks
Description
When the minecart contraption using a furnace minecart and mechanical drills/plough is self-powered and the drills make contact with blocks they do not stop the contraption from moving wile mining. I was able to replicate this with a furnace minecart being pushed by powered/controller rails. I was able to replicate the issue with a regular minecart being at full speed on a powered rail. So this might be speed related.
Game Log
No log
Debug Information
Client Info
Create:
Mod Version: 6.0.3
Mod Git Commit: 7f14bcc64b0eed202617fe08f0dbf5a1e74443d3
Ponder Version: 1.0.45
NeoForge Version: 21.1.129
Minecraft Version: 1.21.1
Graphics:
Flywheel Version: 1.0.1-11
Flywheel Backend: flywheel:indirect
OpenGL Renderer: NVIDIA GeForce RTX 4070 Ti/PCIe/SSE2
OpenGL Version: 4.6.0 NVIDIA 565.90
Graphics Mode: Fancy
System Information:
Operating System: Windows 10 (amd64) version 10.0
Java Version: 21.0.3, Microsoft
JVM Flags: 10 total; -Xmx4096M -XX:MetaspaceSize=256M -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xss1M
Memory: 760933056 bytes (725 MiB) / 1476395008 bytes (1408 MiB) up to 4294967296 bytes (4096 MiB)
Total Memory: 717535912 bytes (684 MiB) / 1476395008 bytes (1408 MiB)
CPU: AMD Ryzen 5 5600X 6-Core Processor @ 3.70 GHz; 6 cores / 12 threads on 1 socket(s)
Graphics cards: none
Other Mods:
Server Info
Create:
Mod Version: 6.0.3
Mod Git Commit: 7f14bcc64b0eed202617fe08f0dbf5a1e74443d3
Ponder Version: 1.0.45
NeoForge Version: 21.1.129
Minecraft Version: 1.21.1
System Information:
Operating System: Windows 10 (amd64) version 10.0
Java Version: 21.0.3, Microsoft
JVM Flags: 10 total; -Xmx4096M -XX:MetaspaceSize=256M -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xss1M
Memory: 760933056 bytes (725 MiB) / 1476395008 bytes (1408 MiB) up to 4294967296 bytes (4096 MiB)
Total Memory: 717535912 bytes (684 MiB) / 1476395008 bytes (1408 MiB)
CPU: AMD Ryzen 5 5600X 6-Core Processor @ 3.70 GHz; 6 cores / 12 threads on 1 socket(s)
Graphics cards: none
Other Mods:
@VoidLeech , marking this issue as a duplicate of newer reported issues is making the issue tracking system a mess. I am certain this is not how you use GitHub. It should be the other way around. This one is #8031, and you are referring to #8145 and #8095, which came AFTER this one. Those 2 issues are the duplicates of this reported issue, so I would encourage you to fix this and remember for future threads.
I have to refer many Redditors to this issue particularly so they know it's already been reported.
What? Those issues have been closed as duplicates of this one (so we know what they're a duplicate of). That act automatically makes a link here. This (indeed earlier) one remains open.
I will admit I've closed some other issues as duplicates of newer ones, often in case the newer one had a significantly better description, reproduction steps (both vital for actually reproducing bugs) or issue name for searching, but that's not the case here.
@VoidLeech You're not in the wrong, @hexaF6-NinjaMC Either is blind and thought this was marked duplicate or doesn't know how github works.
@electricsteve , I have to disagree. The marking as completed in other issues is fine, as GitHub doesn't automatically close issues marked as duplicates of other issues. However, it states in this issue this is a duplicate of other issues that came after and have the same description of the issue, so this issue should be the root issue to follow, if later ones aren't more descriptive. A simple LinkedIn learning tutorial would show the correct flow. I know, it seems very childish of me to state something like this. I'm not intending to be malicious, but it's a peeve having to locate some issues and being confused by the flow and flairs and mis-marked duplicates.
Here's a screenie; I am not blind. The grammar here ("... marked this as a duplicate of...") states this issue was the less-descriptive, hence the misstep of it being the other way around.
And yes, I know how GitHub works. Appreciate the claim, though.
Sounds like an issue to be reported to whatever interface you're using (: That's not what I have on desktop/mobile web.
@VoidLeech , I apologize for this poor display of behavior then. Time to send this to github mobile devs. Thanks for patiently dealing with me.
@hexaF6-NinjaMC Well that is interesting, that seems to be a language error on githubs part.
@electricsteve , yeah, I reported this to GitHub devs in their community discussions, so they are aware and looking at implementing an auto-close feature for when something is marked as duplicate too.
I also found where I was thinking of a contributor of a compat mod being annoying, repeatedly marking things as duplicates and closing things, but the issues weren't really related. So, my mistake, and a very bad one, and I hope I don't do something like this again.
@Ar3czekTV , @electricsteve , @darknesschaos , supposedly a redditor in the CreateMod subreddit claims controller rails are a solution here, but I wouldn't know of the validity of this claim.
@hexaF6-NinjaMC I suspect it doesn't fix the issue because the issue is with it not stopping and not with the speed.
The problem is in the furnace cart. Use a regular minecart and energy rails, powering them by putting red stone blocks next to them or red torches
Hi, We fixed this on our server by placing the furnace minecart directly on the track WITHOUT the card assembler. Might also have to do with pushing it to start, idk.
I encountered this issue while playing on a modpack with OpenPAC. A contraption wouldn't work correctly, exactly as stated here, if placed partially inside/outside of claimed chunks, despite me being the owner.
Placing it fully inside or outside resolved the issue
@CalebMorseST10343104 That seems more like an issue with OpenPAC not with create.
In my pack, I found that controller rails were not fixing the issue right away but after some travel the contraption started to work correctly. Controller rails with 1 power definitely are a good bandage until this issue gets fixed.
I confirmed this problem exists with create versions 6.0.0 through 6.0.4 and neoforge versions 21.1.138 through 21.1.172 for minecraft 1.12.1 using minecarts with powered rails with redstone torches, as well as furnace minecarts being powered with coal. Using the controller rail set to a power level of 1 works, but is an inellegant solution in that it's not easily automateable with the contraptions, but the slower moving contraption does not have the same problems.
To me, this suggests that the speed of the contraption might play a role in the contraption not mining all of the blocks before moving forward. Or possibly, the drills are not properly checking for blocks in front of them before the contraption moves, or the check for blocks vs moving forward logic is not setup properly. Or one other option since this appears to primarily affect the neoforge loader is that neoforge doesn things differently which has a downbstream affect on the logic.
my bad- my problems with this stemmed from a mod called "faster minecarts" which makes minecarts (and minecart contraptions) go twice as fast. After removing the mod, the issue didn't exist for me anymore. That said, with the future updates allowing for differnt minecart speeds, I can see this still being a potential issue.
I've experienced this exact thing and can confirm both the issue and the temporary workaround.
This might be an issue with the minecart assembler. A reddit post here recommended putting the contraption directly on a separate rail and sending the contraption off that way and it seemed to work in my game. Sending it through the cart assembler caused the issue every time.
@mcspacecash It didn't work for me + I would not recommend it because it's inconsistent,
Adding in to the pile. I didn't know this was an issue as I started with powered rails and have no issue. Someone on server using regular rails has this issue.
To break down what is going on to triaging what might be an issue and you guys might able to help us confirm:
All drill contraptions that move use the same BlockBreakingMovementBehaviour. This will add checks for every game tick on how block breaking should behave, should the the contraption stall.
https://github.com/Creators-of-Create/Create/blob/8f18d8dd0d03260020674ec681a3ab3bcaa5bac6/src/main/java/com/simibubi/create/content/kinetics/base/BlockBreakingMovementBehaviour.java#L126-L145
https://github.com/Creators-of-Create/Create/blob/8f18d8dd0d03260020674ec681a3ab3bcaa5bac6/src/main/java/com/simibubi/create/content/kinetics/base/BlockBreakingMovementBehaviour.java#L37-L50
Now, the actual candidates for breaking depends on a BreakPos NBT data which comes from the LastPos NBT data itself which is updated whenever a block is broken:
https://github.com/Creators-of-Create/Create/blob/8f18d8dd0d03260020674ec681a3ab3bcaa5bac6/src/main/java/com/simibubi/create/content/kinetics/base/BlockBreakingMovementBehaviour.java#L241-L250
From the looks of it, in order to visit a new position, and determine if the machine needs to stall for progressing, that should take at least 2 game ticks as the written NBT data would not show up until the next game tick. Unless somehow NBT data is instantly available, which does not alter much in the scenario.
Theory: When the minecart moves 4 (furnace) - 8 (redstone) block/s it means that there is 5-2.5 game tick or so time for doing all the reading and writing. With more than one drills needing to do the same check, it seems that the error room is very thin, so if your server ever goes bellow 20 TPS, you would notice that the contraption phases through blocks.
Can you guys do some tests with Spark and measure the TPS impact for the theory?
On a world with, sadly, several other mods, (couldn't get a world with just create where my tps was dipping notably low, at least in the quick testing I was doing, and also wasn't seeing the issue), I observed tps that occasionally spiked but were mostly healthy, and a drilling contraption that mostly drilled, except the top blocks, every other block.
https://spark.lucko.me/ueKKyT4s63
Thank you very much! That 16-14 TPS would be enough to observe the theory. Even with a good 20 TPS period, it only takes one dip at an unfortunate time to skip a block and halt everything.
In your case, the two primary sources of lag come from executing commands and waiting on CPU threads. The latter you cannot do much about, but the former usually involves datapacks like mob griefing prevention and similar. Try removing those datapacks and see if you can consistently get your TPS above 18, and if that helps with the phasing problem.
Someone found a workaround. Hope GH lets me paste the link: https://www.youtube.com/watch?v=ozJz9CVUtes
I just checked this issue myself, I ran NeoForge 21.1.209 with create 6.0.6 where this was happening, when I downgraded NeoForge to 21.1.208, the issue were no longer there, so there seems to be an issue with newer version of NeoForge
There is also one known behaviour: the stalling is skipped if you trigger the minecart from the assembler, but if you pick up your drill and place it down fresh, it appears to work.