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".
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.
Because of a bug in Python, os.environ doesn't handle non-ascii characters correctly. Python uses the old ascii API for fetching environment variables instead of the new unicode API.
I don't know why WScript.Shell doesn't respect your %APPDATA% setting. Did you try knocking that part out to see if SHGetSpecialFolderLocation does respect the setting?
Just for the record, I was never able to get in contact with anyone at Mojang. Either I wasn't persistent enough in sending emails or they never got around to returning them.
Anyway, here are two files you'll need to update when any new blocks or items are added:
There, I updated the OP with a blurb about the state of things. Send me a PM when I need to update it with another link.
I did put in one last change after releasing the source. I added some half-baked support for the 1.2 world format that works by literally emulating the older chunk format. This uses as much memory as the older Extended Height chunks, plus a loading speed penalty for the emulation. It's kind of emblematic of this project that Mojang's new, high-speed low-memory world format becomes slow and bloated instead when MCEdit tries to use it.
I have just two things to ask of anyone who uses it: Kindly share your changes, and cut me in on any fortunes you happen to make from it.
I'm taking a long break from developing MCEdit, but I may come back to it someday. Feel free to send a PM with any questions you might have. If anyone needs me, I'll be in Hawaii.
After giving it a lot of thought, I've decided I won't do the source code sale-slash-fundraiser after all. Holding my work hostage and demanding payment from users before it continues is a business model suited only to tyrants and despots, and I'd rather not be remembered that way.
I guess I have a lot to learn.
I really just wanted to be compensated for my time. I doubt the source code itself is worth that much. After reading through it again, I'm not sure it's worth $100, let alone 10g. There will be lots of "He wanted $10k for THAT!?!?" in the near future.
MCEdit's source code will be posted to http://github.com/codewarrior0/mcedit once I've finished cleaning my personal information and passwords out of it.
I'm not sure who I should pass the torch to, but I don't want to leave the "lead developer" position up for grabs so I'm just going to name a few names. TkTech wrote to me and offered on the behalf of #mcdevs to maintain it for me. I'd also be pleased to see Eggplant! or hetmankp continue the work, since both of them have their own projects based on my pymclevel that they would love to have integrated with MCEdit. So, I'll leave it up to the three of them to decide.
I love you all and I hope you all have a wonderful day. :smile.gif:
It has been pretty clear that I haven't been active on this project for at least a month or two. The short of it is that I've lost interest in playing Minecraft, and because of that I haven't been motivated to tinker with MCEdit.
I've been treating MCEdit as a personal project so far. There's no official issue tracker, wiki, or discussion forums; I've been keeping it low key, running the entire project out of my inbox and this one forum thread. When I work on the code, I tend to work on whatever I think would be fun.
There's a point when it stops being fun. That point is when I feel obligated to solve people's issues or add new features on request, when those people (probably) haven't done me any favors and at a time when I really need to be looking for paid work rather than fooling around with an add-on for a video game.
For the first year of development (starting July 2010), I spent 30-40 hours a week on MCEdit. In addition to writing code for viewing and editing the level files, I also spent time experimenting with Minecraft and investigating issues that users took the time to describe. One memorable exchange is with a user who kept trying to fill an area with wood, but in game the wood was lined with grooves all running in one direction. After denying it a few times, it turned out that he was in fact filling the area with Wooden Stairs and not Wood. Another user reported a ton of lag after filling an area with dirt, but after downloading his save it turned out he was filling the area with Grass instead. I coded in an extra step that turns buried Grass into Dirt before saving the level.
I spent some time on a feature that probably wasn't important to many people: file formats. MCEdit can read, write, and export from very old versions of Minecraft. Classic Singleplayer (.mine) and Multiplayer (.dat) files are partially supported with filename assistance for nonstandard sizes. (Full support would use a helper application made in Java.) Indev files (.mclevel) are fully supported as are world folders from Minecraft Infdev, Alpha, Beta, Release and Pocket Edition. In addition, the export format (.schematic) includes a field that tells MCEdit which version it came from. MCEdit uses this field to eliminate blocks that aren't available in older versions, and to "translate" block IDs for blocks that appear in different editions of Minecraft with different block IDs - colored wool, notably.
That may have been a bad decision and the time would have been better spent making a list of the known defects in the application. Or applying for work.
"Yeah yeah, but can you release the source code so someone can keep working on it?" That's the topic I was getting to. MCEdit and its source code reflect the work I've done on it over the past year and a half. For a lot of that time I had no primary occupation so MCEdit became my full-time job. I was sagely advised to keep all of the source code private. However, I felt a bit obliged to the OSS community for all of the tools I was (and am still) using, so I shared the level-loading code on github under the name pymclevel.
I intend to share MCEdit's source code, but I also intend to get paid for my work. Here is the deal. We'll raise a modest sum through a crowd-funding site like Kickstarter. Once the money is raised, I'll upload MCEdit's full source code to github, licensed under the GPL. If the project is overfunded at all, the surplus will go toward paying my salary for another year of development on MCEdit. I think I will set the price of the source code at $10,000.
The source code isn't pretty. It's by no means the work of a master programmer - I consider myself below average at best. The LevelEditor class is bloated, the MCEdit class has unclear responsibilities, and the Brush tool still doesn't have a plugin system. If you read the code for pymclevel, you will have a good idea of what quality of code to expect. When you get down to it though, the code works for many of its intended purposes and also embodies solutions to problems or hangups that I fixed and later forgot.
I will update the OP with a big fat link to the crowd-funding site as soon as I get it set up.
I'll end this announcement with a big thank-you to everyone who downloaded and used MCEdit. Thanks for coming along with me, it has been a blast getting to know my users and you've given me a taste of what professional software dev can be like. An additional thank-you goes to everyone who has donated any amount of money. Your donations haven't been forgotten and will be counted toward the fundraising goal. A final shout-out goes to everyone who sent in a feature request along with your donation and saw it implemented: the command-line "dumpchests" feature in mce.py, the "Classic Water Flood" filter, and the "Paste" brush (and a few more I'm forgetting) were all added at the requests of donators.
(And a big high-five to dudecon for porting all of his scripts to MCEdit's filter system. What a beast!)
I'll make an announcement about the future of MCEdit's development shortly. The brief version is that I'm no longer interested in playing Minecraft, and I'm not making enough money developing MCEdit to justify pursuing it as even a part time job.
I'll take a moment to tell you what I know about this issue:
ok I ran into an issue with MCedit which makes it VERY frustrating. on an Mcedited map when logging out of minecraft then logging back in some chunks regenerate. It happens on custom maps other people make and ones I do (which makes development a pain). I am not the only person who has experienced this I raised this problem on vech's super hostile forum page as one of the custom maps that was affected was "spellbound caves". Please fix this it sorta kills all map making... here are some pictures for reference.
It does not seem to happen on non mcedited worlds.
The last time I heard about this problem, it was because of importing an Indev level into Minecraft using an old version of MCEdit that is unable to convert Indev's entities into the format used by modern Minecraft.
Technically, this happens whenever Minecraft raises an exception while it's trying to instantiate all of the entities in a chunk. Instead of rejecting the bad entity, Minecraft rejects the entire chunk and regenerates it.
Practically, this can happen when you import a .schematic that was exported from a modded version of Minecraft. I can't say why the errors in the images are happening. I need a lot more information about how you used MCEdit on the affected worlds. Specifically, I need the sequence of edits you did and the .schematic files you imported.
The errors in Spellbound Caves should be very easy to reproduce. If you can post the coordinates for the affected areas, then I can download Spellbound Caves and check out the places myself to see what's going on.
How do you keep your spawn from changing? What are the requirements for a spawn point? D:
Your spawn point must be in a column where there is a solid block at H=63.
This is because Minecraft only starts scanning for the top surface of the terrain beginning at H=63. If that block is empty, Minecraft assumes the entire column is empty and moves your spawnpoint somewhere else.
0
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.
3
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.
0
Can you paste the last 20 lines of the mcedit.log file from inside the MCEdit-0.1.3.win32 folder?
1
17
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.
0
0
I don't know why WScript.Shell doesn't respect your %APPDATA% setting. Did you try knocking that part out to see if SHGetSpecialFolderLocation does respect the setting?
5
Anyway, here are two files you'll need to update when any new blocks or items are added:
Blocks - https://github.com/mcedit/pymclevel/blob/master/minecraft.yaml
Items - https://github.com/mcedit/pymclevel/blob/master/items.txt
2
I did put in one last change after releasing the source. I added some half-baked support for the 1.2 world format that works by literally emulating the older chunk format. This uses as much memory as the older Extended Height chunks, plus a loading speed penalty for the emulation. It's kind of emblematic of this project that Mojang's new, high-speed low-memory world format becomes slow and bloated instead when MCEdit tries to use it.
8
I have just two things to ask of anyone who uses it: Kindly share your changes, and cut me in on any fortunes you happen to make from it.
I'm taking a long break from developing MCEdit, but I may come back to it someday. Feel free to send a PM with any questions you might have. If anyone needs me, I'll be in Hawaii.
7
When I say "building", of course I mean downloading and copy-pasting things others have built.
19
I guess I have a lot to learn.
I really just wanted to be compensated for my time. I doubt the source code itself is worth that much. After reading through it again, I'm not sure it's worth $100, let alone 10g. There will be lots of "He wanted $10k for THAT!?!?" in the near future.
MCEdit's source code will be posted to http://github.com/codewarrior0/mcedit once I've finished cleaning my personal information and passwords out of it.
I'm not sure who I should pass the torch to, but I don't want to leave the "lead developer" position up for grabs so I'm just going to name a few names. TkTech wrote to me and offered on the behalf of #mcdevs to maintain it for me. I'd also be pleased to see Eggplant! or hetmankp continue the work, since both of them have their own projects based on my pymclevel that they would love to have integrated with MCEdit. So, I'll leave it up to the three of them to decide.
I love you all and I hope you all have a wonderful day. :smile.gif:
18
I've been treating MCEdit as a personal project so far. There's no official issue tracker, wiki, or discussion forums; I've been keeping it low key, running the entire project out of my inbox and this one forum thread. When I work on the code, I tend to work on whatever I think would be fun.
There's a point when it stops being fun. That point is when I feel obligated to solve people's issues or add new features on request, when those people (probably) haven't done me any favors and at a time when I really need to be looking for paid work rather than fooling around with an add-on for a video game.
For the first year of development (starting July 2010), I spent 30-40 hours a week on MCEdit. In addition to writing code for viewing and editing the level files, I also spent time experimenting with Minecraft and investigating issues that users took the time to describe. One memorable exchange is with a user who kept trying to fill an area with wood, but in game the wood was lined with grooves all running in one direction. After denying it a few times, it turned out that he was in fact filling the area with Wooden Stairs and not Wood. Another user reported a ton of lag after filling an area with dirt, but after downloading his save it turned out he was filling the area with Grass instead. I coded in an extra step that turns buried Grass into Dirt before saving the level.
I spent some time on a feature that probably wasn't important to many people: file formats. MCEdit can read, write, and export from very old versions of Minecraft. Classic Singleplayer (.mine) and Multiplayer (.dat) files are partially supported with filename assistance for nonstandard sizes. (Full support would use a helper application made in Java.) Indev files (.mclevel) are fully supported as are world folders from Minecraft Infdev, Alpha, Beta, Release and Pocket Edition. In addition, the export format (.schematic) includes a field that tells MCEdit which version it came from. MCEdit uses this field to eliminate blocks that aren't available in older versions, and to "translate" block IDs for blocks that appear in different editions of Minecraft with different block IDs - colored wool, notably.
That may have been a bad decision and the time would have been better spent making a list of the known defects in the application. Or applying for work.
"Yeah yeah, but can you release the source code so someone can keep working on it?" That's the topic I was getting to. MCEdit and its source code reflect the work I've done on it over the past year and a half. For a lot of that time I had no primary occupation so MCEdit became my full-time job. I was sagely advised to keep all of the source code private. However, I felt a bit obliged to the OSS community for all of the tools I was (and am still) using, so I shared the level-loading code on github under the name pymclevel.I intend to share MCEdit's source code, but I also intend to get paid for my work. Here is the deal. We'll raise a modest sum through a crowd-funding site like Kickstarter. Once the money is raised, I'll upload MCEdit's full source code to github, licensed under the GPL. If the project is overfunded at all, the surplus will go toward paying my salary for another year of development on MCEdit. I think I will set the price of the source code at $10,000.The source code isn't pretty. It's by no means the work of a master programmer - I consider myself below average at best. The LevelEditor class is bloated, the MCEdit class has unclear responsibilities, and the Brush tool still doesn't have a plugin system. If you read the code for pymclevel, you will have a good idea of what quality of code to expect. When you get down to it though, the code works for many of its intended purposes and also embodies solutions to problems or hangups that I fixed and later forgot.
I will update the OP with a big fat link to the crowd-funding site as soon as I get it set up.I'll end this announcement with a big thank-you to everyone who downloaded and used MCEdit. Thanks for coming along with me, it has been a blast getting to know my users and you've given me a taste of what professional software dev can be like. An additional thank-you goes to everyone who has donated any amount of money. Your donations haven't been forgotten
and will be counted toward the fundraising goal. A final shout-out goes to everyone who sent in a feature request along with your donation and saw it implemented: the command-line "dumpchests" feature in mce.py, the "Classic Water Flood" filter, and the "Paste" brush (and a few more I'm forgetting) were all added at the requests of donators.(And a big high-five to dudecon for porting all of his scripts to MCEdit's filter system. What a beast!)
1
I'll take a moment to tell you what I know about this issue:
The last time I heard about this problem, it was because of importing an Indev level into Minecraft using an old version of MCEdit that is unable to convert Indev's entities into the format used by modern Minecraft.
Technically, this happens whenever Minecraft raises an exception while it's trying to instantiate all of the entities in a chunk. Instead of rejecting the bad entity, Minecraft rejects the entire chunk and regenerates it.
Practically, this can happen when you import a .schematic that was exported from a modded version of Minecraft. I can't say why the errors in the images are happening. I need a lot more information about how you used MCEdit on the affected worlds. Specifically, I need the sequence of edits you did and the .schematic files you imported.
The errors in Spellbound Caves should be very easy to reproduce. If you can post the coordinates for the affected areas, then I can download Spellbound Caves and check out the places myself to see what's going on.
1
Your spawn point must be in a column where there is a solid block at H=63.
This is because Minecraft only starts scanning for the top surface of the terrain beginning at H=63. If that block is empty, Minecraft assumes the entire column is empty and moves your spawnpoint somewhere else.