for 11.10:
[list=1]
Go to the Ubuntu market
Search for "wine".
[snip]
Even after all of this trouble, I still cannot get any of the world to render except for the character marker. I don't know why it doesn't work, but I have requested linux support. all we can do now is continuously bug him about it.
There is an "MCEdit for Linux" section on the downloads page.
Everyone, please disregard his "wine" instructions. There is no need to run MCEdit using "wine", and besides, he makes it clear that even after that trouble the program doesn't even work under wine.
Minecraft RC2 adds a new kind of saved data, TileTicks, for keeping track of the state of Redstone machines and for other purposes. When a world is first created, a TileTick is added for each "active" block including Sand, Gravel, Water and Lava (active), Leaves (decaying) and others. This can result in up to a thousand TileTicks being saved in each chunk, which is just a little bit more than MCEdit can handle while still being responsive. (A drawback of using pure Python for reading NBT data. I managed to make NBT load twice as fast by cleaning it up, but a C or Pyrex-based NBT loader would be at least ten times faster.)
A picture might give you a better idea.
In this picture, I've opened a world that was just created by the Minecraft Server. This world loads very slowly because of the TileTicks. TileTicks are the white cubes; on the right is a chunk file I extracted from this world (using Chunk Control, Extract Chunks) and then opened with NBTEdit.
Because I stopped the server as soon as it reported "Done!", it didn't get a chance to process any of the TileTicks. If I wait up to 20 seconds after "Done!" to stop the server, most of the ticks are processed.
Is there a way to filter out various kinds of entity types? The ones that appear in the translucent red boxes in particular are annoying if I have to search for my death location amongst a lot of animal/monster mob entities. It's easy if there's a large amount of items they just clump up way more than animal/monster mob entities do. But if I only had a few items on me, it is a lot harder to find my stuff amongst them all!
Also, how accurate is MCEdit when it analyzes a map for a particular release version? I'm running RC2 at the moment, and I've found on large ocean biomes it can be particularly time-consuming to find the first tree. I could of course search for leaf blocks by selecting all, but this seems to yield weird results, as in that it finds way less blocks of a particular type than I could actually see, the numbers seem way off to me.
I tried pumpkin blocks having spotted 5 scattered on one map with MCedit, it on the other hand only reported finding 3, and I had selected the entire map!
I've played around with MC-Edit a few times in the past, but only recently have I had a project where I really needed to use it extensively. After a short learning curve, I have to say that this is one of the most well-designed and intuitive programs I've ever used. It's robust and clean, and efficient to use.
In short, this is an amazing program you've created, and I'm beyond impressed by its functionality and capabilities. You probably hear this a lot, but this is the one of the best additions to the MineCraft community that exists. Thank you!
Testing build #227 is building and uploading while I type this.
I'd like to release that build as the "Compatible with Minecraft 1.0.0" build today or tomorrow. Please give it a try and let me know about any show-stopping problems. I'm getting a few auto reports of the program crashing right after an automatic update, but I'm not able to reproduce them. I hope it's just a problem with a few installs that crashed mid-update.
Is there a way to filter out various kinds of entity types? The ones that appear in the translucent red boxes in particular are annoying if I have to search for my death location amongst a lot of animal/monster mob entities. It's easy if there's a large amount of items they just clump up way more than animal/monster mob entities do. But if I only had a few items on me, it is a lot harder to find my stuff amongst them all!
Also, how accurate is MCEdit when it analyzes a map for a particular release version? I'm running RC2 at the moment, and I've found on large ocean biomes it can be particularly time-consuming to find the first tree. I could of course search for leaf blocks by selecting all, but this seems to yield weird results, as in that it finds way less blocks of a particular type than I could actually see, the numbers seem way off to me.
I tried pumpkin blocks having spotted 5 scattered on one map with MCedit, it on the other hand only reported finding 3, and I had selected the entire map!
Cheers ...
BrickVoid
Yes, I'll eventually add handy view options for showing monsters, passive mobs, items, other entities, tile entities, and tile ticks separately.
The stable build has one gotcha in the Analyze function: blocks with the same name but different data values are counted separately. You can click on "(ID:Data)" to sort the list by block ID and see what's what. The latest test build counts blocks with the same name together, so you don't see 16 entries for "Water" and whatnot.
I've played around with MC-Edit a few times in the past, but only recently have I had a project where I really needed to use it extensively. After a short learning curve, I have to say that this is one of the most well-designed and intuitive programs I've ever used. It's robust and clean, and efficient to use.
In short, this is an amazing program you've created, and I'm beyond impressed by its functionality and capabilities. You probably hear this a lot, but this is the one of the best additions to the MineCraft community that exists. Thank you!
You're welcome, and thanks for the compliment! Sometimes it seems like I'm only hearing about how MCEdit is "clunky and unintuitive" or reading about people who can't even get it up and running, so I'm glad you're at least able to get some use out of it. :smile.gif:
Love your invaluable program like always. I am having issues with editing new 1.0 maps though. MCEdit is running extremely slow, to the extent that it is unusable. I was not having these slowdown issues with old 1.8- maps.
This issue effects stable33 but it is running slightly faster on Testing build #227. I really have no clue what could be the issue. I am running a newly generated map (Using Minecraft Land Generator) that is fairly large, 3000x3000 chunks, but I wasn't having these problems a few months ago with other maps.
GordonChin: Yeah, it's a new issue that's going to affect any maps you create with Minecraft Land Generator. Go back a page in the thread and look at post #4747 (and then turn on Show Entities in the Graphic options.) Testing build 227 has a slight workaround that makes the server process all of the chunks for 15 seconds after generating them, but you have to use MCEdit's own server-based generator instead of using MLG.
GordonChin: Yeah, it's a new issue that's going to affect any maps you create with Minecraft Land Generator. Go back a page in the thread and look at post #4747 (and then turn on Show Entities in the Graphic options.) Testing build 227 has a slight workaround that makes the server process all of the chunks for 15 seconds after generating them, but you have to use MCEdit's own server-based generator instead of using MLG.
Thanks for the quick reply. I didn't know MCEdit had a generator of its own now. I'll try using that, thanks!
The built in generator isn't working for me. I tried twice to make a 3000x3000 map with the default minecraft server but it seems to just hang after the first generation, hogs most of my CPU and memory. Also the time estimate is 4+ days. MLG only took about 30 minutes to complete that task.
Using 64bit Windows 7, 64bit Python, 64bit Java, 64bit MCEdit Testing build 227.
Installed the 227 build and opened a relatively small newly-generated 1.0.0 map. In the ocean biome, there are a ton of small clusters of white-outlined blocks. They seem to be slowing down MCEdit when in view, and I'm hesitant to do any real editing with them around.
Same thing happens in both 64- and 32-bit versions of build 227. 64-bit Windows 7.
You're welcome, and thanks for the compliment! Sometimes it seems like I'm only hearing about how MCEdit is "clunky and unintuitive" or reading about people who can't even get it up and running, so I'm glad you're at least able to get some use out of it. :smile.gif:
I've said it before and I'll say it again, you are awesome. My map series just would not exist without MCedit, and I'm positive the same can be said for many, many other custom Minecraft maps.
well... after searching my computer for 15 mins for the words "control" and "system" to get to the "environment variable" button and remove the"%cosmosm%;"thing in the PATH thing. it now work perfectly and with no unbarable fps after loading alot of chunks. this is the first time i'm seeing such a diffrence in performance between a 32 bit, and a 64 bit version of a program.
the way i found the path thing was: i started by 1)opening the control panel. 2)clicking "system and maintenance". 3)then system.(by now i was here: Control Panel\System and Maintenance\System) 4)then i clicked "advanced system settings" then in the "advanced tab" is the "environment variable"... then you explained the rest prety well after that.
now that i can really use mcedit, i can say its great. i'v been slow/manual building for so long i was tired of doing it agen after starting new worlds for the new biome updates and mods. thank you for this awesome tool and 4 helping get it to work.
having an issue with your new build, everytime i select anything and then hit fill/replace it crashes. i know its a test build, but making sure you catch it for full release
There is an "MCEdit for Linux" section on the downloads page.
Everyone, please disregard his "wine" instructions. There is no need to run MCEdit using "wine", and besides, he makes it clear that even after that trouble the program doesn't even work under wine.
"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
Minecraft RC2 adds a new kind of saved data, TileTicks, for keeping track of the state of Redstone machines and for other purposes. When a world is first created, a TileTick is added for each "active" block including Sand, Gravel, Water and Lava (active), Leaves (decaying) and others. This can result in up to a thousand TileTicks being saved in each chunk, which is just a little bit more than MCEdit can handle while still being responsive. (A drawback of using pure Python for reading NBT data. I managed to make NBT load twice as fast by cleaning it up, but a C or Pyrex-based NBT loader would be at least ten times faster.)
A picture might give you a better idea.
In this picture, I've opened a world that was just created by the Minecraft Server. This world loads very slowly because of the TileTicks. TileTicks are the white cubes; on the right is a chunk file I extracted from this world (using Chunk Control, Extract Chunks) and then opened with NBTEdit.
Because I stopped the server as soon as it reported "Done!", it didn't get a chance to process any of the TileTicks. If I wait up to 20 seconds after "Done!" to stop the server, most of the ticks are processed.
"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
It will load faster while you are alt-tabbed, especially if your hardware is any good.
"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
2. DOES IT WORK WITH SPC AND TOOMANYITEMS
otherwise nice job, this will definitely come in handy (once it works for 1.9)
YOU JUST GOT TROLOLOLED
Also, how accurate is MCEdit when it analyzes a map for a particular release version? I'm running RC2 at the moment, and I've found on large ocean biomes it can be particularly time-consuming to find the first tree. I could of course search for leaf blocks by selecting all, but this seems to yield weird results, as in that it finds way less blocks of a particular type than I could actually see, the numbers seem way off to me.
I tried pumpkin blocks having spotted 5 scattered on one map with MCedit, it on the other hand only reported finding 3, and I had selected the entire map!
Cheers ...
BrickVoid
In short, this is an amazing program you've created, and I'm beyond impressed by its functionality and capabilities. You probably hear this a lot, but this is the one of the best additions to the MineCraft community that exists. Thank you!
I'd like to release that build as the "Compatible with Minecraft 1.0.0" build today or tomorrow. Please give it a try and let me know about any show-stopping problems. I'm getting a few auto reports of the program crashing right after an automatic update, but I'm not able to reproduce them. I hope it's just a problem with a few installs that crashed mid-update.
Try the new testing build, I think I've worked around it.
Read the directions again - you need to change the "Environment variables" settings under the "System" control panel.
In fact, this may or may not be fixed in the new testing build. If you try it out, let me know what happens.
Yes, I'll eventually add handy view options for showing monsters, passive mobs, items, other entities, tile entities, and tile ticks separately.
The stable build has one gotcha in the Analyze function: blocks with the same name but different data values are counted separately. You can click on "(ID:Data)" to sort the list by block ID and see what's what. The latest test build counts blocks with the same name together, so you don't see 16 entries for "Water" and whatnot.
You're welcome, and thanks for the compliment! Sometimes it seems like I'm only hearing about how MCEdit is "clunky and unintuitive" or reading about people who can't even get it up and running, so I'm glad you're at least able to get some use out of it. :smile.gif:
"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 issue effects stable33 but it is running slightly faster on Testing build #227. I really have no clue what could be the issue. I am running a newly generated map (Using Minecraft Land Generator) that is fairly large, 3000x3000 chunks, but I wasn't having these problems a few months ago with other maps.
"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
Thanks for the quick reply. I didn't know MCEdit had a generator of its own now. I'll try using that, thanks!
Using 64bit Windows 7, 64bit Python, 64bit Java, 64bit MCEdit Testing build 227.
Installed the 227 build and opened a relatively small newly-generated 1.0.0 map. In the ocean biome, there are a ton of small clusters of white-outlined blocks. They seem to be slowing down MCEdit when in view, and I'm hesitant to do any real editing with them around.
Same thing happens in both 64- and 32-bit versions of build 227. 64-bit Windows 7.
Here are some sshots:
I've said it before and I'll say it again, you are awesome. My map series just would not exist without MCedit, and I'm positive the same can be said for many, many other custom Minecraft maps.
:smile.gif:
the way i found the path thing was: i started by 1)opening the control panel. 2)clicking "system and maintenance". 3)then system.(by now i was here: Control Panel\System and Maintenance\System) 4)then i clicked "advanced system settings" then in the "advanced tab" is the "environment variable"... then you explained the rest prety well after that.
now that i can really use mcedit, i can say its great. i'v been slow/manual building for so long i was tired of doing it agen after starting new worlds for the new biome updates and mods. thank you for this awesome tool and 4 helping get it to work.
Thanks For Download Map
When will MCEDIT be compatible with 1.0.0 ???
Edit: it only does that if non-number characters are inputted in the box.
Edit: Edit: It seems to work when I lower the number to 200x200 but that's not big enough, darn it!