In every NBT editor I've used, to edit schematics, besides NBTedit, I get this error:
I don't know how to import this file: schem.schematic.
LoadingError(('Multiple errors encountered', AssertionError('Data is not a TAG_Compound (found 64)',), IOError('MCJavaLevel attempted for smaller than 64 blocks cubed',)), <traceback object at 0x10e7dc638>)
I tried NBTedit, NBTexplrorer 2.0.2, NBTexplorer 1.x, and nbt2yaml. The only one that works is NBTedit, and that's the only one which doesn't work well enough with mono. So, what's the issue? Using MCEdit 0.1.3.
Edit: This doesn't save. Neinedit can't add data, only edit. mc-nbt-edit is entirely incapable. This saves compatibly, but you can't add data, only edit. This doesn't load files on mac. This can only edit, not add.
I guess I will code my own NBT editor with your python library . I even tried twoolie's NBT library - no good. But really, since something like only 3 editors out of every single one that I tried is compatible, would it be possible to make MCEdit more lenient toward schematic files?
This error is because Apple's OS X 10.7.5 update changed the version of a specific library (libfreetype) used by MCEdit. When MCEdit is built on 10.7.5, the resulting app won't launch on any earlier version of OS X. I managed to work around this by grabbing the older version from 10.7.0 and building against it, and the app from that build will actually launch on 10.6. Will post a new OS X build shortly.
I'm done with being burned out. I'm picking up where I left off on MCEdit's development. I've asked TkTech to send me the bounties he collected for Anvil support, which I had partially completed before my break. Let's all give him a round of applause for filling in for me.
I've got a fix ready for the "Intel Graphics Bug" which has been affecting users on netbooks, and a fix that allows Anvil's extended block IDs (used by Tekkit, etc) to be imported and exported. I'm also putting together a new website that should make it easier to download the latest MCEdit and find more information about it. New builds will be posted within the next few days.
Welcome back codewarrior! Those will be very useful updates indeed, and it's great to hear about that 4096ID's compatibility, the Forge crowd will be very happy to hear that.
And a huge thanks to TkTech for all that he has done and will hopefully still be doing!
Can someone post the reason for it closing everytime i click on brush, fill etc as it seems other people have the problem too. ( I'm on a pc). I'm guessing this has been asked may times before, sorry..
Can i ask here if anyone knows a reason why both the 32 and 64 bit versions both instantly crash when i click on anything at the bottom like the brush tool or the filters button?
Look at the last two pages before expecting an answer.
How exactly do you make a custom villager trade? I've tried every position of the items in the chest possible and even watched a few videos to see the proper format, but nothing works. It just makes a villager with an empty trading screen.
Hi,sorry Y am from Argentina and Y am not very good at english, Y have a problem: Y have Windows and my sistem is 32.Y download it perfectly,Y unzip the file, but when i open the .exe it load,takes a while, and it closes D: .
Y re-download it 10 more times and nothing, the same.
Please Y need help.
One more time sorry for the english and thanks for reading.
I've spent the last few days making a haunted house adventure mode map in creative, and a friend suggested I use this to encase the whole thing in a box to keep the light out and keep players from wandering too far off. I checked my system, 32bit, downloaded that version, and every time I try to run it, the command prompt opens, the MCedit window opens, then it all closes before anything appears. I tried the 64bit version for good measure. No good, it doesn't work with my system.
Here's the traceback just to be safe.
[ERROR][971][mcedit]:An unhandled error occured.
Traceback (most recent call last):
File "mcedit.py", line 967, in main
File "mcedit.py", line 835, in main
File "mcedit.py", line 589, in __init__
File "mcedit.py", line 624, in reloadEditor
File "leveleditor.pyo", line 1435, in __init__
File "leveleditor.pyo", line 1890, in genSixteenBlockTexture
File "glutils.pyo", line 180, in __init__
File "leveleditor.pyo", line 1873, in makeSixteenBlockTex
File "OpenGL\GL\exceptional.pyo", line 169, in glTexParameter
File "OpenGL\error.pyo", line 208, in glCheckError
GLError: GLError(
err = 1280,
description = 'invalid enumerant',
baseOperation = glTexParameteri,
cArguments = (
GL_TEXTURE_2D,
GL_TEXTURE_MAX_LEVEL,
0,
)
)
Would be nice to get this fixed up so I don't have to make a 100x100x100 black wool box by hand.
In every NBT editor I've used, to edit schematics, besides NBTedit, I get this error:
I don't know how to import this file: schem.schematic.
LoadingError(('Multiple errors encountered', AssertionError('Data is not a TAG_Compound (found 64)',), IOError('MCJavaLevel attempted for smaller than 64 blocks cubed',)), <traceback object at 0x10e7dc638>)
I tried NBTedit, NBTexplrorer 2.0.2, NBTexplorer 1.x, and nbt2yaml. The only one that works is NBTedit, and that's the only one which doesn't work well enough with mono. So, what's the issue? Using MCEdit 0.1.3.
Edit: This doesn't save. Neinedit can't add data, only edit. mc-nbt-edit is entirely incapable. This saves compatibly, but you can't add data, only edit. This doesn't load files on mac. This can only edit, not add.
If almost every program is failing to process your file, I'd think there's something malformed about it. Maybe you should post a failing sample for tool authors to investigate. I just tried a random schematic file with NBTExplorer and it handled it fine.
He wasn't saying that those can't process his schematic. He said that MCEdit doesn't accept the schematic after some of those have been used to modify it.
I've experienced the same with schematics of my own. If I edit a schematic with NBTedit then it works with MCEdit. If I edit it with NBTexplorer then MCEdit doesn't accept it. I had been using twoolie's NBT library, but schematics built with it didn't work in MCEdit (even though the previously mentioned programs could open it).
I ended up just using pynbt.py straight from MCEdit to build the schematics.
Oh, I misunderstood. I can reproduce the same kind of error. When I save out the same data, the outputs are quite different, thought the data is the same. Could be that the python and DotNetZip zlib packages aren't playing nice together, but I'd have to dig a little more to be sure.
Oh, I misunderstood. I can reproduce the same kind of error. When I save out the same data, the outputs are quite different, thought the data is the same. Could be that the python and DotNetZip zlib packages aren't playing nice together, but I'd have to dig a little more to be sure.
Gzip output from .NET programs always seems to include extra data after the first gzip "member". In MCEdit, I have to work around this by using zlib directly instead of working with GzipFile. The latter always throws an error when it comes to the extra data even though it just read the first member correctly. I'm pretty sure my workaround is wrong because what I do is strip off a fixed length gzip header and pass the remainder to zlib.decompress(). Gzip headers don't have a fixed length; I need to compute the length from the header's "flags" field or else try to patch GzipFile to ignore the trailing data instead of trying to interpret it as a second gzip "member".
I tried NBTedit, NBTexplrorer 2.0.2, NBTexplorer 1.x, and nbt2yaml. The only one that works is NBTedit, and that's the only one which doesn't work well enough with mono. So, what's the issue? Using MCEdit 0.1.3.
Edit: This doesn't save. Neinedit can't add data, only edit. mc-nbt-edit is entirely incapable. This saves compatibly, but you can't add data, only edit. This doesn't load files on mac. This can only edit, not add.
Can you paste the last 20 lines of the mcedit.log file from inside the MCEdit-0.1.3.win32 folder?
"We will absolutely not keep in mind what external mapeditors will have to do to read data from the disk, that makes no sense whatsoever." - Grum
This error is because Apple's OS X 10.7.5 update changed the version of a specific library (libfreetype) used by MCEdit. When MCEdit is built on 10.7.5, the resulting app won't launch on any earlier version of OS X. I managed to work around this by grabbing the older version from 10.7.0 and building against it, and the app from that build will actually launch on 10.6. Will post a new OS X build shortly.
"We will absolutely not keep in mind what external mapeditors will have to do to read data from the disk, that makes no sense whatsoever." - Grum
MCedit v 0.1.3
Minecraft 1.3.2
Windows
Welcome back codewarrior! Those will be very useful updates indeed, and it's great to hear about that 4096ID's compatibility, the Forge crowd will be very happy to hear that.
And a huge thanks to TkTech for all that he has done and will hopefully still be doing!
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
You guys have worked wonders on this!
Look at the last two pages before expecting an answer.
Two posts up.
Y re-download it 10 more times and nothing, the same.
Please Y need help.
One more time sorry for the english and thanks for reading.
Here's the traceback just to be safe.
[ERROR][971][mcedit]:An unhandled error occured.
Traceback (most recent call last):
File "mcedit.py", line 967, in main
File "mcedit.py", line 835, in main
File "mcedit.py", line 589, in __init__
File "mcedit.py", line 624, in reloadEditor
File "leveleditor.pyo", line 1435, in __init__
File "leveleditor.pyo", line 1890, in genSixteenBlockTexture
File "glutils.pyo", line 180, in __init__
File "leveleditor.pyo", line 1873, in makeSixteenBlockTex
File "OpenGL\GL\exceptional.pyo", line 169, in glTexParameter
File "OpenGL\error.pyo", line 208, in glCheckError
GLError: GLError(
err = 1280,
description = 'invalid enumerant',
baseOperation = glTexParameteri,
cArguments = (
GL_TEXTURE_2D,
GL_TEXTURE_MAX_LEVEL,
0,
)
)
Would be nice to get this fixed up so I don't have to make a 100x100x100 black wool box by hand.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
I've experienced the same with schematics of my own. If I edit a schematic with NBTedit then it works with MCEdit. If I edit it with NBTexplorer then MCEdit doesn't accept it. I had been using twoolie's NBT library, but schematics built with it didn't work in MCEdit (even though the previously mentioned programs could open it).
I ended up just using pynbt.py straight from MCEdit to build the schematics.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
Gzip output from .NET programs always seems to include extra data after the first gzip "member". In MCEdit, I have to work around this by using zlib directly instead of working with GzipFile. The latter always throws an error when it comes to the extra data even though it just read the first member correctly. I'm pretty sure my workaround is wrong because what I do is strip off a fixed length gzip header and pass the remainder to zlib.decompress(). Gzip headers don't have a fixed length; I need to compute the length from the header's "flags" field or else try to patch GzipFile to ignore the trailing data instead of trying to interpret it as a second gzip "member".
I hope that makes sense.
"We will absolutely not keep in mind what external mapeditors will have to do to read data from the disk, that makes no sense whatsoever." - Grum