Can't even open world.
ehgoodenough opened this issue · 14 comments
Set Up
I'm having issues even opening a world in Substrate. I cloned this repo and tried to compile Substrate/SubstrateCS/Examples/BlockReplace/Program.cs
using Substrate/SubstrateCS/bin/Debug/Substrate.dll
.
$ mcs /reference:Substrate.dll BlockReplace.cs
$ mono BlockReplace.exe ./path/to/my/world 32 48
But all I got was NullReferenceException
. :<
Stack Traces
I tried debugging the issue by deleting a lot of the code. The issue is when I try to open the world, which doesn't return an NBTWorld, but instead null, which the IChunkManager chokes on.
using System;
using Substrate;
class MyProgram {
static void Main (string[] args) {
var path = "./workworkfashionbaby";
try {
NbtWorld world = NbtWorld.Open(path);
IChunkManager cm = world.GetChunkManager();
} catch (Exception error) {
Console.WriteLine("Error: Failed to open world: " + path);
Console.WriteLine("Exception: " + error.Message);
Console.WriteLine(error.StackTrace);
return;
}
}
}
Error: Failed to open world: ./workworkfashionbaby
Exception: Object reference not set to an instance of an object
at Export.Main (System.String[] args) <0x545ed8 + 0x0002e> in <filename unknown>:0
I also tried opening an AnvilWorld, not an NBTWorld, which did throw an error, instead of just silently returning null. It looks like it is finding the file, but for whatever reason, just isn't parsing the level?
class MyProgram {
static void Main (string[] args) {
var path = "./workworkfashionbaby";
try {
AnvilWorld world = AnvilWorld.Open(path);
} catch (Exception error) {
# ...
}
}
}
Error: Failed to open world: ./workworkfashionbaby
Exception: Failed to load 'level.dat'
at Substrate.AnvilWorld.OpenWorld (System.String path) <0x4f2208 + 0x002cf> in <filename unknown>:0
at Substrate.AnvilWorld.Open (System.String path) <0x4f1078 + 0x0003b> in <filename unknown>:0
at Export.Main (System.String[] args) <0x4f0ed8 + 0x00027> in <filename unknown>:0
What am I doing wrong?
I am using a world built in the latest and greatest Minecraft 1.8.9. Maybe that's the issue?
I am getting null world as well. I even referenced the 1.3.10 Substrate.dll from NBTExplorer. NBTExplorer is able to open the world. MineBack shows the version as 19133 (1.8+). I am able to open a world that MineBack shows as version 19133 (apx. 1.2).
I created a profile to run 1.8.5 and created a new world. I added some blocks and closed the world. world was still null. I ran MineBack and noticed my newly created world showed as version 19133 (1.8+). I also noticed the world I have been trying to open now shows as 19133 (apx.1.2) so I tried using it for NbtWorld. It is not null anymore - it shows as Subtrate.AnvilWorld. MineBack still shows my other words as 19133 (1.8+) except for the others that it originally showed (and still) at 19133 (apx. 1.2).
@WadiaSoft, so your solution was to run it through Mineback?
Level is not loaded because of
_id = ctree["id"].ToTagShort();
in Item.LoadTree.
Commenting it makes the world load, but I suppose all the items will be broken afterwards. If you only need the world blocks as I do it will probably work without problems :)
My problem was with 1.8.9, 1.7.10 worlds seem to work
That seemed to fix it on the one world but I tried it on another world it didn't work. Also, in Mineback that original world now shows at 19133 (apx.1.8+). I am working off a copy of it. Maybe I just got lucky.
Worked for me, too. Will _id = ctree["id"].ToTagShort();
be fixed in the next release?
Does this happen with 1.9.2?
I've back-ported some code and tests from 2.x in #39, I haven't noticed the id issue, but that fixes an issue with the player health. I'll try to reproduce the id problem with a survival world asap.
Getting this issue too with 1.9.2 worlds, haven't tested with older worlds.
What kind of object is the id tag for?
Somewhere in the 1.7.x updates (after 1.7.2), items were changed from numeric ID's to strings. I found a reference on the minecraft forum. The unit tests are likely not finding this issue because there aren't any players with items in their inventory, which is where it was failing for me.
I committed a proof of concept change to fix the issue for my needs (so far anyway), available here. However, this does break any versions prior to the numeric to string change, e.g. 1.7.2
@unscannablejoe try the code in the 2.x branch, there are considerable changes to support the new IDs in there.
Same problem back, can you please update it to 1.10.2?