Digital Miner issue
Moobien opened this issue · 41 comments
Hey guys, not sure if anyone else is experiencing this or if its a simple mod conflict, but for a couple of months now in 1.11.2 and now 1.12.2 I am finding that the Digital miner does not mine.
the 2 screenshots of the DM's interface were taken about 10 minutes apart in 1.12.2
Below is a list of ALL installed mods.
ActuallyAdditions-1.12.2-r124.jar
AdvancedRocketry-1.12.2-1.2.5a-22.jar
ArmorStandGUI-1.12-1.0.4.jar
autoplant-1.12-1.0.0.jar
backpacks 1.12.2 - 3.4.2.jar
base-1.12-3.4.2.jar
BetterBuildersWands-1.12-0.11.1.245+69d0d70.jar
BetterFoliage-MC1.12-2.1.10.jar
BiblioCraft[v2.4.3][MC1.12.0].jar
BowInfinityFix-1.11.x-1.12.x-rv5.jar
Chameleon-1.12-4.1.3.jar
ChickenChunks-1.12-2.4.0.70-universal.jar
Chisel-MC1.12-0.0.14.18.jar
chiselsandbits-14.9.jar
Clumps-3.0.0.jar
CodeChickenLib-1.12-3.1.3.313-universal.jar
CoFHCore-1.12-4.3.6.14-universal.jar
CoFHWorld-1.12-1.0.1.8-universal.jar
CoralReef-2.2-1.12.2.jar
CTM-MC1.12-0.2.3.9.jar
Decocraft-2.5.2_1.12.2.jar
EnchantingTable-1.12-1.1.2.jar
extrautils2-1.12-1.6.7.jar
ExtremeReactors-1.12-0.4.5.44.jar
FastLeafDecay-v14.jar
FTBLib-4.2.3.jar
Futurepack-1.12.1-26.2.27.jar
HoloInventory-1.12.2-2.0.2.148.jar
InventoryTweaks-1.63.jar
IronBackpacks-1.12.2-3.0.1-2.jar
ironchest-1.12.2-7.0.34.820.jar
IronMan-Beta-1.12-1.0.1.jar
jei_1.12.2-4.8.0.114.jar
journeymap-1.12.2-5.5.2.jar
LC 0.0.1.jar
LibVulpes-1.12.2-0.2.6-12-universal.jar
lostcities-1.12-1.0.2.jar
LucraftCore-1.12-1.2.3.jar
Mantle-1.12-1.3.1.21.jar
MCA-1.12.x-5.3.1-universal.jar
mcjtylib-1.12-2.4.5.jar
Mekanism-1.12.1-9.4.1.326.jar
MekanismGenerators-1.12.1-9.4.1.326.jar
MekanismTools-1.12.1-9.4.1.326.jar
minecolonies-universal-1.12.2-0.8.4832.jar
modeltrains-1.2.2.jar
NotEnoughItems-1.12-2.4.0.231-universal.jar
omlib-1.12.2-3.0.0-131.jar
openmodularturrets-1.12.2-3.0.0-221.jar
OptiFine_1.12.2_HD_U_C6.jar
platforms-1.12.0-1.4.1.jar
RadixCore-1.12.x-2.2.1-universal.jar
railsplus-1.0.1.jar
realms_persistence.json
RebornCore-1.12.2-3.4.12.155-universal.jar
RebornStorage-1.12.2-2.1.1.16.jar
RedstoneFlux-1.12-2.0.1.2-universal.jar
refinedstorage-1.5.23.jar
rflux-1.12-0.1.2.jar
rftools-1.12-7.13.jar
shetiphiancore-1.12.0-3.5.4.jar
Signals-1.12.2-1.0.0-universal.jar
SpacePackExtended-1.12-2.2.4-alpha.jar
StevesCarts-1.12.2-2.4.12.62.jar
StorageDrawers-1.12.1-5.3.3.jar
switchbow-1.5-1.12.2.jar
TConstruct-1.12-2.7.4.34.jar
ThermalCultivation-1.12-0.1.1.6-universal.jar
ThermalDynamics-1.12-2.3.6.13-universal.jar
ThermalExpansion-1.12-5.3.6.20-universal.jar
ThermalFoundation-1.12-2.3.6.16-universal.jar
tombstone-1.6.0-1.12.jar
torohealth-1.12.2-11.jar
TreeChopper-1.12.2-1.2.4.jar
UniDict-1.12.2-1.2.jar
VeinMiner-1.12-0.38.1.639+134fb1e.jar
VillageNames-1.12.2-2.0.jar
WanionLib-1.12.2-1.2.jar
wolfarmor-1.12.2-2.1.0.24-RELEASE.jar
YABBA-1.0.10.jar
zerocore-1.12-0.1.1.0.jar
What logs are you guys needing from me?
I assume I need to remove all 3 mekanism jar files before installing the one you linked?
Changes have been made to the miner in dev, so issues may be solved.
If single player, you can try https://github.com/aidancbrady/Mekanism/releases/tag/9.4.1%2B8bbef954
I just tried your .jar something new happened. I clicked it to start it, after a few seconds the dminer turned off.
Gonna remove futurepack and see if that makes a difference.
EDIT: Still did the same thing in my existing world so I made a new world where FP was never installed for and the dminer worked. I will raise an issue with FP for this.
EDIT 2: crosslinking issues. mcenderdragon/Futurepack-API#313
Well yeah I block all players (so I guess even fake players if they fire events) from breaking the dungeon blocks. Because it is realy important to not break them until the player cleared them, else the player could achive stuff they should not have (end game).
But I am only protecting the needed blocks not all, so you should be able to mine anything around it. Also it is very cool from Mekanism to use fake players and not just destroy the blocks (buildcraft querrys...)
The digital miner turning off is a good thing, that is an indication it's done with its mining goal. The change @thiakil applied to the file you download is a check to make sure it can break it and skip it if it cannot be mined (thus preventing a stall on an unbreakable block), previous versions would try over and over, failing constantly. (Reference: 9e49a7c)
I can understand where @mcenderdragon is coming from, but the dminer isn't trying to mine any of the FP blocks as you can see in the screenshots so even ores are being blocked.
one layer around the dungeon is protected as always cuboids get protected, so if the structure was a star there are alot of unchanged but still protected blocks, this is to make sure you can cheat you in higher levels.
Try this build. If it doesnt stall you definitely have some kind of chunk protection.
http://maven.thiakil.com/filedump/MekanismAll-1.12.2-9.4.2.353eecc3.jar
There is 1 thing I can think of that COULD be causing it. Futurepack recently added their own dungeons. Anything you break in them is instantly restored.
@mcenderdragon I owe you an apology. I found the real culprit. @thiakil you were right about it being a protection issue. Minecolonies has a 'colony protection' option that once disabled allows the dminer to mine. With the option turned on it stops the miner. This explains why it worked fine in a fresh world and not preexisting ones. My new test worlds havent had a colony started yet, therefore at that point the protection wasnt active. Will let them know.
Hmmmmm wonder why then that the miner cant mine anything at all if only 1 layer gets protected.
Are you saying it works fine in that world if you remove FuturePack? Or just that it does in a fresh world?
It worked perfectly fine in a new world created after the removal of FP. But wont work in worlds created while FP was installed both before and after the removal of FP
The only thing of relevance I changed in the newest build was to make it not fail to move on if a block break is denied. If FP is no longer installed it cannot be the cause of the denial
@thiakil it works perfectly on a world created after the removal of FP. On worlds created while FP was installed the dminer turns off after a few seconds and does nothing.
The behaviour of it not working after removal reminds me of how some skyrim mods leave scripts etc in the save file and need to be manually removed if that makes any sense
Sure, but that's not how Minecraft works. Create a copy of that world and remove everything except Mekanism. It will probably work.
Try this, and enable logDigitalMinerBlockBreakDenied in the config, then check your logs after having tried mining. It should tell you what denied the event.
http://maven.thiakil.com/filedump/MekanismAll-1.12.2-9.4.2.custom-log-break-denials.jar
I wanted to test something so i reinstalled FP and made a new world. The dminer works perfectly in this new world, seems its my old ones that it wont work in.
there is no way to get a properly displayable Name for them all, so that we can list them properly in a UI where the user selects them.
You most certainly can cache the GameProfiles you see in event and present them, or just let users enter the name/id
With a not needed.
Reflection can get you access to the list.
Currently the ownership system in Mekanism is not set up properly to handle all cases of giving a FakePlayer a UUID it can return. And if something has block protection it can either allow fake players or not, that's for the user to configure.
@Moobien @mcenderdragon @thiakil I am one of the Main developers of Mincolonies. Am i right to asume that the Digital Miner is a FakeUser?
Then you need to set the correct username in accordance with Forge. If Mekanism sets the user id of the placer on the FakePlayer (in according with Forge documentation, yes we fell on our noses with lex ourself when we first encountered this error) Minecolonies will accept the FakePlayer just fine.
The user of the fake player is always the same; we only use one for the whole mod in order to not pollute the player list, much like many other mods.
You also shouldn't be using names to store/distinguish players, rather the UUID
Yep, we asked lex how to handle this, since their is no way to get a proper username list from these FakePlayers, and lex flat out told us, that the implementer of the FakePlayer is wrong and should use the UUID of the placing Player as the UUID for the FakePlayer, he was not willing to provide a list for us, since in his opinion even adding a single FakePlayer with a unique UUID for the whole mod was poluting the list, since you could use the UUID of the placer. Which would identify the FakePlayer properly to anyone who wants ist username.
This is the relevant discussion whe had with Lex: ldtteam/minecolonies#645 (comment)
I am well aware of what you mean, but in typical Lex manner, the javadoc says nothing about it should be the same as the player who placed it.
Forge does in fact keep a weak cache of fakeplayers created using its factory, though it doesnt seem very useful.
The fake player not matching a user is valid behaviour imo, it just doesnt help your mod. We could even be using net.minecraftforge.common.util.FakePlayerFactory#getMinecraft(World) which uses a static player that anyone can use.
The user can still trust the Mekanism user, though it will not be specific to that user's Digital Miner(s)
The Problem is that there is no way to get a properly displayable Name for them all, so that we can list them properly in a UI where the user selects them.
Do not get me wrong I wish it worked the other way around, but it does not sadly.... The insane Things is that we offered a PR to get the List as a Immutable, wrapped up and neat. Refused. With a not needed.