I'll definitely look into it when I get some time, but I don't actually own pocket edition, so testing will be difficult. I think the sandstone thing is an easy fix though. OniOniOn handles most of the pocket definitions so I'll pass it on.
Thank you! I don't know if MCEdit limits PE maps to 256x256 blocks but if it does would it be possible to eliminate that limit? maybe it'd help to port bigger maps though not so sure...
Thank you! I don't know if MCEdit limits PE maps to 256x256 blocks but if it does would it be possible to eliminate that limit? maybe it'd help to port bigger maps though not so sure...
Sandstone may actually already be fixed, have you tried my build 1.0.5? The size is changable, but until someone can figure out how to load the new format not much point in messing with it, it's part of the file loading code. Fun fact though, MCedit can create maps for pocket that are 512x512.
Sandstone may actually already be fixed, have you tried my build 1.0.5? The size is changable, but until someone can figure out how to load the new format not much point in messing with it, it's part of the file loading code. Fun fact though, MCedit can create maps for pocket that are 512x512.
Hopefully someone figures it out soon. Will be very hard to make maps on 0.9 without mcedit.
Rollback Post to RevisionRollBack
Tazader City 2015, the best Minecraft PE city map. Download at www.TazaderCity.com.
Loaded up a world with the latest experimental (and last stable) mcedit. However, I cannot seem to use the Filter button (it is red, unavailable). Chunks are selected, and there is a filters folder in the subfolder to where mcedit.exe is run from.
Can't find anyone else having this issue (the common fault is because people forget to select chunks before trying the filter button). Any ideas? (I just know this is going to make me kick myself )?
You may be using the wrong tool to select, filters only work through the select function, so if you were using chunk control to select an area it won't work.
Yes, that was it, thanks.
I was following a guide which said I should be in chunk view rather than camera view. Chunk view didn't allow me to use the filter button, camera view does.
..... <snipped> If it's one thing I don't know how to do is pull data from an external non-python file so if anyone can figure that out, I can edit the block definitions to match.
I understand the theory well enough, but I couldn't code it in Python without a LOT of irritation (as I said - Python and me don't see eye-to-I :P). What type of external file? Just plain text, XML, or what? I could explain it in a pseudo-programmer way (almost like COBOL) if it would help.
I don't know a ton about the new save format other than the libraries are written in C++ and can be found at https://github.com/Mojang/leveldb-mcpe. It seems to store in some kind of database, which isn't XML, but I don't really know more than that as I can't really read C++. I've never worked with COBOL so I can't really say anything about it.
Yes, that was it, thanks.
I was following a guide which said I should be in chunk view rather than camera view. Chunk view didn't allow me to use the filter button, camera view does.
So i successfully reset everything and can play again in 26c. Thanks. New problem is that there are no nether mobs, except those from spawners (blaze). Light levels are at 0 as expected, I see no relevant setting in NBTExplorer. I even reset lighting in mcedit for the whole nether with no effect. A new 26c map spawns them fine; moving to peaceful, then back to Hard has no effect either. I assume it's something that happened with mcedit when I was fixing my map as I see no-one mentioning this issue from maps started pre-26c.
Note to anyone who was using 26b, the ID changes were not intentional, so anyone who loaded a world in minecraft in that snapshot you might want to restore a backup if you have one. This wasn't a MCedit bug and it is all working again in 26c from what I can tell. My poor test world.
Sofa, try using the command /gamerule doMobSpawning true, mcedit doesn't have anything to do with mob spawning outside of making spawners.
I'd already tried the gamemobspawning command with no effect.
Moving into new nether area allows for mob spawns. I did notice that in the old area, near a blaze spawner, the blaze sometimes spawn halfway inside the ground. Makes me think that I inadvertently moved everything up one block or something, but the y-coords are still the same for various waypoints I have.
edit: noticed that deleting the largest .mca (r.0.0) region file allows for mob spawning everywhere. Of course, I lose too much of my nether setup to use this option.
I'd already tried the gamemobspawning command with no effect.
Moving into new nether area allows for mob spawns. I did notice that in the old area, near a blaze spawner, the blaze sometimes spawn halfway inside the ground. Makes me think that I inadvertently moved everything up one block or something, but the y-coords are still the same for various waypoints I have.
edit: noticed that deleting the largest .mca (r.0.0) region file allows for mob spawning everywhere. Of course, I lose too much of my nether setup to use this option.
Give it a new name, then load it back up. Name it something outside your current range, so you have in effect removed those chunks from the game, then when you go back in-game, Minecraft will regenerate but you won't loose anything. Then you can simply copy and paste any structures or whatever other work you've done from your renamed section to the regenerated section using MCEdit.
Too much work, and I'd rather find the exact issue rather than resetting. Fix the cause, not the symptoms...
My thinking atm is that this HAS to be an entry viewable in NBTexplorer; like a too-high light value, or a displacement of a y-value somewhere (I base that on the way the blaze spawners are operating - blaze spawn half-buried inside the ground surrounding the spawner)
I don't know a ton about the new save format other than the libraries are written in C++ and can be found at https://github.com/Mojang/leveldb-mcpe. It seems to store in some kind of database, which isn't XML, but I don't really know more than that as I can't really read C++. I've never worked with COBOL so I can't really say anything about it.
From perusing the LevelDB documentation and base code, it looks as though they use SQLite, and compress (g-zip, I believe) it on the fly when it reaches a certain point (or size).
How to access the structure from Python? Good question. I do know that you would need "wrappers" for the C++ stuff, although it says the data gets stored in a file/directory structure on the disk, so if you A) had some solid C++ that opened the LevelDB structure (better than the [pseudo-code in the documentation), performed read/write operations, and closed it again, you could in theory convert it using https://code.google.com/p/ctypesgen/ or you could write out the database access routines yourself.
But either way, you'd have to have a pretty good handle on Python in order to fix any discrepancies that came up from "translating" and to use database access (though this may help any of you other intrepid Pythoners in this regard: https://wiki.python.org/moin/DatabaseProgramming/).
It's been so long since I did any worthwhile programming (outside of simple BASH scripts to make my life easier on Linux) that the last program I wrote was in VisualBasic 6.0, back in college. *lol*
As for COBOL, it was almost like coding in English, but nobody outside of banks and insurance companies use it any more, so it's kind of a bad example.
Too much work, and I'd rather find the exact issue rather than resetting. Fix the cause, not the symptoms...
My thinking atm is that this HAS to be an entry viewable in NBTexplorer; like a too-high light value, or a displacement of a y-value somewhere (I base that on the way the blaze spawners are operating - blaze spawn half-buried inside the ground surrounding the spawner)
Try moving your Y up +1. I seem to recall that Minecraft calculates the Y-axis differently from MCEdit (or used to at some point - maybe they've reconciled now). One uses feet, the other eyes, though at my age, that could just be something I heard from the leprechauns that sit on my shoulders and whisper things in my ears when nobody is looking.
That being said, those little buggers are whispering to me that if it was indeed a botched Y-axis tag in the NBT schema, it should be more consistent - as in, happen every time - unless it picks the spawn point from a potential range of Y-axis coordinates.
Naturally, they also wish me to note that the only way to know for sure what's going on is to try and create the same scenarios in multiple copies with that same seed and compare your results in each using the NBT explorer. And not just copying your save to a new folder, but building from the ground up by generating a new world with the same seed number, and preferably several times.
So, mobs spawn in the nether under y=30 or so. Nothing above, unless I add a half-slab. Any blaze spawners spawn ok, but again, half a block above and an unknown distance to the side of where they 'should'.
That building in the background contains a simple blaze spawner, where a lot of them end up suffocating in a wall/ceiling or escape the container that worked perfectly before.
Also, any zombies that spawn when you are fighting zombie pigmen spawn with no problems OFF the half-slab (maybe they spawn half a slab above the floor and drop?) ie. on the original floor, so it seems there's a different mechanic for that type of mob.
Sandstone may actually already be fixed, have you tried my build 1.0.5? The size is changable, but until someone can figure out how to load the new format not much point in messing with it, it's part of the file loading code. Fun fact though, MCedit can create maps for pocket that are 512x512.
Nop, I didn't know that there were dev builds until a few weeks ago then I tried the last one before official update release now I'm on 0.1.7.1 but sandstone problem is there yet, if it's possible I'd like to try yours though I didn't find it in the site...
Could you explain me how to create a 512x512 pocket edition map? I can't find it in the options, the new format is not a problem yet, at least not for what I need
Try here: https://github.com/K...ases/tag/v1.0.5 for the sandstone issue, upon further inspection for the larger saves, while the code does seem to support 512 maps, it isn't currently set up to work with those sizes apparently, my bad.
I have a question about copying schematics to new worlds.
I have a world that got corrupted because of the new snapshot. I was able to recover the world through an MCEdit script that somebody posted on Reddit, but everything in my chests was gone (apparently this happened because I loaded it in an uncorrupt version before discovering the fix). I copied over my storage room from a week-old backup, so now I'm trying to copy over individual chests that I have scattered around my world. So before copying them over, I just saved a whole bunch of them in the schematics folder.
My problem now is that since I have a whole bunch of chests that all look the same in the schematics bar on the right, how can I tell which one I'm copying over? I named each one individually to determine which chests go where, but the name doesn't seem to come up on the actual MCEdit program, so I just have a whole bunch of chests that look the same in the sidebar with seemingly no way of knowing which chest is which. How can I tell? Is there something obvious I'm missing?
Thank you! I don't know if MCEdit limits PE maps to 256x256 blocks but if it does would it be possible to eliminate that limit? maybe it'd help to port bigger maps though not so sure...
Sandstone may actually already be fixed, have you tried my build 1.0.5? The size is changable, but until someone can figure out how to load the new format not much point in messing with it, it's part of the file loading code.
Fun fact though, MCedit can create maps for pocket that are 512x512.Hopefully someone figures it out soon. Will be very hard to make maps on 0.9 without mcedit.
Can't find anyone else having this issue (the common fault is because people forget to select chunks before trying the filter button). Any ideas? (I just know this is going to make me kick myself )?
I was following a guide which said I should be in chunk view rather than camera view. Chunk view didn't allow me to use the filter button, camera view does.
I understand the theory well enough, but I couldn't code it in Python without a LOT of irritation (as I said - Python and me don't see eye-to-I :P). What type of external file? Just plain text, XML, or what? I could explain it in a pseudo-programmer way (almost like COBOL) if it would help.
So i successfully reset everything and can play again in 26c. Thanks. New problem is that there are no nether mobs, except those from spawners (blaze). Light levels are at 0 as expected, I see no relevant setting in NBTExplorer. I even reset lighting in mcedit for the whole nether with no effect. A new 26c map spawns them fine; moving to peaceful, then back to Hard has no effect either. I assume it's something that happened with mcedit when I was fixing my map as I see no-one mentioning this issue from maps started pre-26c.
Sofa, try using the command /gamerule doMobSpawning true, mcedit doesn't have anything to do with mob spawning outside of making spawners.
Edit: Mcedit filter to uncorrupt your 26a/b saves: http://np.reddit.com/r/Minecraft/comments/29551r/if_you_corrupted_a_large_project_or_lost_a_large/cihnyjq
Moving into new nether area allows for mob spawns. I did notice that in the old area, near a blaze spawner, the blaze sometimes spawn halfway inside the ground. Makes me think that I inadvertently moved everything up one block or something, but the y-coords are still the same for various waypoints I have.
edit: noticed that deleting the largest .mca (r.0.0) region file allows for mob spawning everywhere. Of course, I lose too much of my nether setup to use this option.
Give it a new name, then load it back up. Name it something outside your current range, so you have in effect removed those chunks from the game, then when you go back in-game, Minecraft will regenerate but you won't loose anything. Then you can simply copy and paste any structures or whatever other work you've done from your renamed section to the regenerated section using MCEdit.
My thinking atm is that this HAS to be an entry viewable in NBTexplorer; like a too-high light value, or a displacement of a y-value somewhere (I base that on the way the blaze spawners are operating - blaze spawn half-buried inside the ground surrounding the spawner)
From perusing the LevelDB documentation and base code, it looks as though they use SQLite, and compress (g-zip, I believe) it on the fly when it reaches a certain point (or size).
How to access the structure from Python? Good question. I do know that you would need "wrappers" for the C++ stuff, although it says the data gets stored in a file/directory structure on the disk, so if you A) had some solid C++ that opened the LevelDB structure (better than the [pseudo-code in the documentation), performed read/write operations, and closed it again, you could in theory convert it using https://code.google.com/p/ctypesgen/ or you could write out the database access routines yourself.
But either way, you'd have to have a pretty good handle on Python in order to fix any discrepancies that came up from "translating" and to use database access (though this may help any of you other intrepid Pythoners in this regard: https://wiki.python.org/moin/DatabaseProgramming/).
It's been so long since I did any worthwhile programming (outside of simple BASH scripts to make my life easier on Linux) that the last program I wrote was in VisualBasic 6.0, back in college. *lol*
Failing that, you could always learn C/C++: http://www.entish.org/realquickcpp/
As for COBOL, it was almost like coding in English, but nobody outside of banks and insurance companies use it any more, so it's kind of a bad example.
Try moving your Y up +1. I seem to recall that Minecraft calculates the Y-axis differently from MCEdit (or used to at some point - maybe they've reconciled now). One uses feet, the other eyes, though at my age, that could just be something I heard from the leprechauns that sit on my shoulders and whisper things in my ears when nobody is looking.
That being said, those little buggers are whispering to me that if it was indeed a botched Y-axis tag in the NBT schema, it should be more consistent - as in, happen every time - unless it picks the spawn point from a potential range of Y-axis coordinates.
Naturally, they also wish me to note that the only way to know for sure what's going on is to try and create the same scenarios in multiple copies with that same seed and compare your results in each using the NBT explorer. And not just copying your save to a new folder, but building from the ground up by generating a new world with the same seed number, and preferably several times.
That building in the background contains a simple blaze spawner, where a lot of them end up suffocating in a wall/ceiling or escape the container that worked perfectly before.
Also, any zombies that spawn when you are fighting zombie pigmen spawn with no problems OFF the half-slab (maybe they spawn half a slab above the floor and drop?) ie. on the original floor, so it seems there's a different mechanic for that type of mob.
Nop, I didn't know that there were dev builds until a few weeks ago then I tried the last one before official update release now I'm on 0.1.7.1 but sandstone problem is there yet, if it's possible I'd like to try yours though I didn't find it in the site...
Could you explain me how to create a 512x512 pocket edition map? I can't find it in the options, the new format is not a problem yet, at least not for what I need
I have a world that got corrupted because of the new snapshot. I was able to recover the world through an MCEdit script that somebody posted on Reddit, but everything in my chests was gone (apparently this happened because I loaded it in an uncorrupt version before discovering the fix). I copied over my storage room from a week-old backup, so now I'm trying to copy over individual chests that I have scattered around my world. So before copying them over, I just saved a whole bunch of them in the schematics folder.
My problem now is that since I have a whole bunch of chests that all look the same in the schematics bar on the right, how can I tell which one I'm copying over? I named each one individually to determine which chests go where, but the name doesn't seem to come up on the actual MCEdit program, so I just have a whole bunch of chests that look the same in the sidebar with seemingly no way of knowing which chest is which. How can I tell? Is there something obvious I'm missing?