BlockLauncher crashes every time, when i try open Launcher options or MCPE Scripts menu. Nexus 2012 (KitKat 4.4) MCPE 0.7.6
exact same problem here but im on android 4.2.2 but selinux says enforcing. is enforcing for kitkat too so the problem here is selinux. is there a workaround for this 500ise or will it require a rewrite of blocklauncher?
Regarding updates:
I'm going to try to update PocketInvEditor before BlockLauncher, in case Mojang pushes out a 0.8.1 release.
Please be patient; I will push the update out when it's ready. There will probably be no beta - I'll just push directly to release.
Um, texture packs don't seem to work now. All of the alpha test builds worked fine with the previous BLpro and Texture packs, but now the new BLpro and official 0.8.0 release make texture packs unusable. Did Mojang change the file structure or something? Anyone else have issues?
However, everything else is fine. Thanks as always for such a great app and caring dev...
Um, texture packs don't seem to work now. All of the alpha test builds worked fine with the previous BLpro and Texture packs, but now the new BLpro and official 0.8.0 release make texture packs unusable. Did Mojang change the file structure or something? Anyone else have issues?
However, everything else is fine. Thanks as always for such a great app and caring dev...
Ya everything else is good but mod scripters gotta start updating their mods now though,
like elemental arrows and a lot of my favorites don't work either but maybe a couple, one that does still work thankfully is 500ISEs fly on mobs mod
Sorry for double posting but forgot to ask, is this new update going to change everything? What I mean is will it make making mods for it harder
Or just have to update the bl app and all will work like it should? Am I making sense?
Ninth, the items.meta: Really important file, as there is all about how the item has to look like and other stuff. This is not a picture, this is a text. Open it with any text editor.
The twelfth: terrain.meta. The same as item.meta, but now for all blocks.
It seems that the tool doesn't support HD files bro.
No - if you can teach me how to do HD files, I'll add support for it.
terrain.meta and items.meta are plain text files (JSON files, actually).
You don't have to change them if you are doing a 16x16. For a HD pack, I would guess that you need to change the width and heights of the image to your new widths and heights. (Each texture coordinate ends with either 512, 256 or 256, 256 - width, height)
terrain.meta and items.meta are plain text files (JSON files, actually).
You don't have to change them if you are doing a 16x16. For a HD pack, I would guess that you need to change the width and heights of the image to your new widths and heights. (Each texture coordinate ends with either 512, 256 or 256, 256 - width, height)
From a casual examination of the .meta files, it appears that there are two routes you can go with creating new texture sets. Each "uv" property in the file has a data set with six parameters: [A, B, C, D, E, F]. The last two, E and F, are always the dimensions of the referenced file, so for a 16x terrain set, this would be '512, 256' if you were replicating the standard layout. A and B are the horizontal and vertical offsets from the upper-left corner of the image for the upper-left corner of the texture, expressed as a decimal fraction of the image, and C and D are the horizontal and vertical offsets from the upper-left corner of the image for the lower-right corner of the texture. Some block labels have multiple blocks under the one general category -- 'sandstone', for example, has five different individual textures -- and these have the 'additonal_textures' property populated with the coordinate set for each additional block in the group; 'sandstone', for example, has the initial texture, and the 'additonal_textures' property has the other four, separated by commas.
The first is to keep the layout of the items and terrain files the same as in the default files; in this case, you only need to fiddle with the .meta files if you're making a larger texture set (i.e., 32x textures would require a 1024x512 'terrain-atlas.tga' file, and you would change the string '512,256' everywhere it occurs in the terrain.meta file to '1024,512'.
The second -- and without testing my theory, I don't know whether this will work -- is to convert the terrain.png file from a pre-0.8.0 texture pack to a Targa .tga file, and then go through the terrain.meta file and change all of the 'uv' coordinates to map where that particular texture appears in the file. So, for example, using a 1024x1024 terrain.png file as the source, the 'uv' coordinates for the diamond ore texture would be changed from '[0.125,0.125,0.1562,0.1875,512,256]' to '[0.1563,0.1875,0.1875,0.2188,1024,1024]' to point at the position of the diamond ore texture in its position as the third texture in the fourth row of the terrain.tga file. This is very tedious; whether it's more tedious than copying textures, one by one, into their correct places in the new layout will have to be up to the individual texture pack creator. However, once this mapping to the old terrain.png layout is done, the resulting terrain.meta file could be used for any terrain file using the old format.
One of the things that I won't know until I part my own texture pack to the new format -- but which appears to fall out of the use of the .meta files is that it appears to allow for one texture to overlap, and possibly to have different sizes -- with a 16x texture pack, to have one or more textures defined in the .meta file as being, say, double the standard width and height.
One of the cautions with either route is that, for textures with multiple textures -- the different sandstones, for example -- the order of the textures is inherent; for example, in the items image file, all of the tool/weapon items appear in the same order -- wood, stone, iron, gold, and diamond for each implement. If you get the 'additonal_textures' sets out of order, you'll get the wrong appearance for a tool.
The advantage of the new system is that a new texture can simply be dropped into the appropriate file and the .meta filed edited to set the values that MCPE will use to locate the texture on the image.
exact same problem here but im on android 4.2.2 but selinux says enforcing. is enforcing for kitkat too so the problem here is selinux. is there a workaround for this 500ise or will it require a rewrite of blocklauncher?
Want GUI Templates? Done!
https://github.com/BeATz-UnKNoWN/ModPE_Scripts/wiki/ModPE-Script-Templates
P.S. Feel free to follow me so you know when I post "awesome" content and make the MCForums a brighter place (totally).
If you need to contact me you can either shoot a Kik message to beatz_unknown or send an email to [email protected]
PE 0.8.0 build 8
and I hate the demo tp...
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'm going to try to update PocketInvEditor before BlockLauncher, in case Mojang pushes out a 0.8.1 release.
Please be patient; I will push the update out when it's ready. There will probably be no beta - I'll just push directly to release.
Thanks for your support.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhen are you uploading to google play? my phone doesn't allow me to install .apk files.
But hey at least I can use the mods still on 0.8.0
However, everything else is fine. Thanks as always for such a great app and caring dev...
http://www.minecraftforum.net/forums/minecraft-pocket-edition/mcpe-mods-tools/2610428-0-13-emeraldcraft-metalurgic-gems-alchemy
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYes, Mojang changed the texture pack system.
like elemental arrows and a lot of my favorites don't work either but maybe a couple, one that does still work thankfully is 500ISEs fly on mobs mod
Or just have to update the bl app and all will work like it should? Am I making sense?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDon't bother: there's already a 1.6 release: http://tinyw.in/bl
I'm working on an app to make porting easier: search for Mercator on Google Play.
Do we need to edit these files too?
It seems that the tool doesn't support HD files bro.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNo - if you can teach me how to do HD files, I'll add support for it.
terrain.meta and items.meta are plain text files (JSON files, actually).
You don't have to change them if you are doing a 16x16. For a HD pack, I would guess that you need to change the width and heights of the image to your new widths and heights. (Each texture coordinate ends with either 512, 256 or 256, 256 - width, height)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumPlease report back: I'll incorporate your findings into Mercator so we can convert Desktop hi-res packs to PE.
http://www.minecraftforum.net/forums/minecraft-pocket-edition/mcpe-mods-tools/2610428-0-13-emeraldcraft-metalurgic-gems-alchemy
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumItems support is still OK: see https://raw.github.com/zhuowei/ModPEScripts/master/treebl_newitem.js
From a casual examination of the .meta files, it appears that there are two routes you can go with creating new texture sets. Each "uv" property in the file has a data set with six parameters: [A, B, C, D, E, F]. The last two, E and F, are always the dimensions of the referenced file, so for a 16x terrain set, this would be '512, 256' if you were replicating the standard layout. A and B are the horizontal and vertical offsets from the upper-left corner of the image for the upper-left corner of the texture, expressed as a decimal fraction of the image, and C and D are the horizontal and vertical offsets from the upper-left corner of the image for the lower-right corner of the texture. Some block labels have multiple blocks under the one general category -- 'sandstone', for example, has five different individual textures -- and these have the 'additonal_textures' property populated with the coordinate set for each additional block in the group; 'sandstone', for example, has the initial texture, and the 'additonal_textures' property has the other four, separated by commas.
The first is to keep the layout of the items and terrain files the same as in the default files; in this case, you only need to fiddle with the .meta files if you're making a larger texture set (i.e., 32x textures would require a 1024x512 'terrain-atlas.tga' file, and you would change the string '512,256' everywhere it occurs in the terrain.meta file to '1024,512'.
The second -- and without testing my theory, I don't know whether this will work -- is to convert the terrain.png file from a pre-0.8.0 texture pack to a Targa .tga file, and then go through the terrain.meta file and change all of the 'uv' coordinates to map where that particular texture appears in the file. So, for example, using a 1024x1024 terrain.png file as the source, the 'uv' coordinates for the diamond ore texture would be changed from '[0.125,0.125,0.1562,0.1875,512,256]' to '[0.1563,0.1875,0.1875,0.2188,1024,1024]' to point at the position of the diamond ore texture in its position as the third texture in the fourth row of the terrain.tga file. This is very tedious; whether it's more tedious than copying textures, one by one, into their correct places in the new layout will have to be up to the individual texture pack creator. However, once this mapping to the old terrain.png layout is done, the resulting terrain.meta file could be used for any terrain file using the old format.
One of the things that I won't know until I part my own texture pack to the new format -- but which appears to fall out of the use of the .meta files is that it appears to allow for one texture to overlap, and possibly to have different sizes -- with a 16x texture pack, to have one or more textures defined in the .meta file as being, say, double the standard width and height.
One of the cautions with either route is that, for textures with multiple textures -- the different sandstones, for example -- the order of the textures is inherent; for example, in the items image file, all of the tool/weapon items appear in the same order -- wood, stone, iron, gold, and diamond for each implement. If you get the 'additonal_textures' sets out of order, you'll get the wrong appearance for a tool.
The advantage of the new system is that a new texture can simply be dropped into the appropriate file and the .meta filed edited to set the values that MCPE will use to locate the texture on the image.