3 - I will ask IDs and generation parameter in IC topic to use your great tool with this awesome mod !
4 - I dont really understand. You purpose to add block ID 99 to modified chunks in order to filter them next time ? Sounds great but how do I create a block Id which doesn't exist in Minecraft ?
5 - I don't see exactly what every parameters stand for
-d, --data=VAL Set the block's data value to VAL (0-15)
-r, --rounds=NUM Geneate NUM deposits per chunk
-s, --size=VAL Generates deposits containing roughly up to VAL blocks
Block Id sounds ok for me, but these 3 ones I don't really see differents between them. How do your algorithm works using these params ?
4. No, that's not what I meant. I was using 99 as an example of a block type you added via mod (like uranium or tin or something else .. I have no idea what IDs these use but obviously they must be something not already used by Minecraft). In the example, if you created deposits of that block type, they would only appear in the existing chunks, and in newly generated chunks they would be absent. But if you were to run the tool again using the -cx option, then it would add that ore to the new chunks, without re-adding (and thus doubling) the amount in the old chunks.
Your test might have failed from the small size. I'm not sure if anything will generate at -s 1. Actually it's more likely that because of the depths you specified, it is trying to overwrite bedrock, which won't happen without specifying some other options. Ores only replace smooth stone by default. Then again I'm not sure the "affected chunks" report is accurate either, as some parts of NBToolkit have decayed while I have been focusing my efforts on developing the underlying SDK. In the future I will be cleaning up the output of the tool.
5. Every block has a 4 bit data value associated with it, but not all block types use it. This is used to set the color of wool, type of sapling, direction of furnaces/ladders/signs/switches/etc, and so on. It's actually not relevant to any of the normal ores, but it might be relevant to modded ores, and it's definitely relevant to the block replace tool.
Rounds is the number of times the tool tries to generate a deposit per chunk. The native Minecraft algorithm also works on a concept of rounds, such that for each new chunk it generates it will generate one round of diamond, 2 rounds of gold, 8 rounds of redstone, 20 rounds of iron, etc.
Size is a tunable parameter to the Minecraft ore generation algorithm. There is no exact definition of it (it doesn't represent diameter, or the number of blocks in the deposit, or any other specific characteristic), but larger values will generate larger deposits. If you want a better reference, then diamond deposits are size 7, iron/gold deposits are size 8, coal deposits are size 16, and dirt/gravel desposits are size 32.
I wouldn't really recommend it. Minecraft used to outright crash when you fed it blocks that it didn't recognize. I don't think it crashes now, but I don't know what it does with the blocks either. Maybe it converts them to something? What could happen if you tried mining a block that doesn't exist?
I think it would be better if you used the -cx flag on the same block ID you're generating. If you managed to mine out all the the ore in a chunk, then it would generate again, but it would be fairly unlikely.
Earlier in this thread I discussed a couple different ways that I might be able to support tagging chunks to deal with this kind of problem, which I'll still look into. Adding a new NBT attribute would be safe but I'm not sure that MC would preserve it. Probably the most fool-proof method would be embedding a special block (like wool) in the bedrock at layer 0. Of course I would need to add some new flags to the tool to take care of this.
I was thinking of mining it = crash. If I use a blockid which is really used I won't be able to filter chunks "nbtoolkited". I have to use a not used block id.
I won't have luck If i mine this ore ! :smile.gif:
Edit : I tried blockid 99 on a single player : I used replace tool to change coal in blockid 99 and the world didn't crashed, just coal blocks "disapear". I can't mine blockid 99
Can I use this tool to remove all the bedrock except for a single (solid - plugging any existing holes) layer at the very bottom of the map? I use another editor to do this occasionally by hand on my SMP server, but we're starting a new map soon and I would like to automate it via cron job.
I think you can do this with two block-replace commands
nbtoolkit replace -b 7 -a 1 --byr=1:4
nbtoolkit replace -b 9 -a 7 --byr=0:0
The first command replaces all the partial partial bedrock on layers 1-4 with smooth stone
The second command replaces any water on the bottom layer (0) with bedrock. Are there other blocks that can appear as holes here? In a future release I could make the -b flag optional to hit all block types in one go.
Actually, I've seen both air or smooth stone as inclusions in the bottom layer. Can run through all the block IDs like...
for BLOCK_ID in `seq 1..$MAX_BLOCK_ID`; do echo nbtoolkit replace -b $BLOCK_ID -a 7 --byr=0:0; done
I think. Shell is not my forte. It's overkill, since not all block IDs can spawn in that level... I have downtime window during daytime when no one's playing, so as long as it's not taking an hour+ to run then no biggie.
Does your tool handle custom block id's > 255?
Having an optional -b would be good... if a bit dangerous / useful, in an "the entire world is now lava!" sort of way.
How about a '-bx=id1,id2,id3...' which will replace all blocks EXCEPT those specified? It would be great for making custom scenario maps such as Deserts.
Many thanks for the tool. I think I will be poking through your code this weekend... do you take patches for new features? :smile.gif:
You can clip the map size to a box with the purge command. You'll need to specify --cxr and --czr to define a box around the chunks you want to keep, and use --crv to invert the selection so you delete everything around the box instead of everything inside of it.
Offhand, I don't believe it will compact region files if they are partially deleted (although this might happen in the future), but it will delete region files that are completely emptied.
Sorry, I skimmed your post and missed that you said "squares". I assume in that case you wanted to trim everything outside of a 1000x1000 block area. --cxr / --czr work on chunk coordinates, so just divide 500 by 16 (which is 32) and try again.
Relight is useful for people who use map generators that cannot correctly calculate their own light (some SDKs have incorrect lighting code or fail to provide it at all), or run tools that manipulate world geometry but can't properly maintain lighting (very common -- just about every block replace tool out there, other than nbtoolkit and mcedit). MC will fix lighting over time but only if you're actively modifying the world. Also as recent updates have demonstrated, even MC has managed to severely break its own lighting code and fixing this is much easier with an outside tool.
I actually need to update nbtoolkit to incorporate the latest version of Substrate which fixes some bugs in things like relight. But it does serve a purpose.
An updated version of NBToolkit is available for download. It includes the latest build of Substrate, which should fix many bugs (particularly in relighting abilities). Some changes have also been made to the options
New Chunk Filter option (for all tools that use this option set):
--cp=VAL : Probability that a chunk will be selected even if all other conditions match
New Block Filter option set (currently for 'replace' tool)
--bxr/--byr/--bzr : Same as before
--bi : Block included in match (optional, repeatable, replaces -b option)
--bz : Block excluded from match (optional, repeatable)
--bp : Probability that a block will be selected (replaces -p option)
1- If I don't use the -r parameter, I will just multiply by 2 the amount of each ore, am I right ?
2 - ok :sad.gif:
3 - I will ask IDs and generation parameter in IC topic to use your great tool with this awesome mod !
4 - I dont really understand. You purpose to add block ID 99 to modified chunks in order to filter them next time ? Sounds great but how do I create a block Id which doesn't exist in Minecraft ?
Is that right ? because 1913 chunks each time
5 - I don't see exactly what every parameters stand for
Block Id sounds ok for me, but these 3 ones I don't really see differents between them. How do your algorithm works using these params ?
Thanks for your support ! :smile.gif:
4. No, that's not what I meant. I was using 99 as an example of a block type you added via mod (like uranium or tin or something else .. I have no idea what IDs these use but obviously they must be something not already used by Minecraft). In the example, if you created deposits of that block type, they would only appear in the existing chunks, and in newly generated chunks they would be absent. But if you were to run the tool again using the -cx option, then it would add that ore to the new chunks, without re-adding (and thus doubling) the amount in the old chunks.
Your test might have failed from the small size. I'm not sure if anything will generate at -s 1. Actually it's more likely that because of the depths you specified, it is trying to overwrite bedrock, which won't happen without specifying some other options. Ores only replace smooth stone by default. Then again I'm not sure the "affected chunks" report is accurate either, as some parts of NBToolkit have decayed while I have been focusing my efforts on developing the underlying SDK. In the future I will be cleaning up the output of the tool.
5. Every block has a 4 bit data value associated with it, but not all block types use it. This is used to set the color of wool, type of sapling, direction of furnaces/ladders/signs/switches/etc, and so on. It's actually not relevant to any of the normal ores, but it might be relevant to modded ores, and it's definitely relevant to the block replace tool.
Rounds is the number of times the tool tries to generate a deposit per chunk. The native Minecraft algorithm also works on a concept of rounds, such that for each new chunk it generates it will generate one round of diamond, 2 rounds of gold, 8 rounds of redstone, 20 rounds of iron, etc.
Size is a tunable parameter to the Minecraft ore generation algorithm. There is no exact definition of it (it doesn't represent diameter, or the number of blocks in the deposit, or any other specific characteristic), but larger values will generate larger deposits. If you want a better reference, then diamond deposits are size 7, iron/gold deposits are size 8, coal deposits are size 16, and dirt/gravel desposits are size 32.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
0 chunks for the last one. And after :
Next time I will add -cx 96 each line.
The map seems to work. What do you think of that ? Thanks
I think it would be better if you used the -cx flag on the same block ID you're generating. If you managed to mine out all the the ore in a chunk, then it would generate again, but it would be fairly unlikely.
Earlier in this thread I discussed a couple different ways that I might be able to support tagging chunks to deal with this kind of problem, which I'll still look into. Adding a new NBT attribute would be safe but I'm not sure that MC would preserve it. Probably the most fool-proof method would be embedding a special block (like wool) in the bedrock at layer 0. Of course I would need to add some new flags to the tool to take care of this.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
I won't have luck If i mine this ore ! :smile.gif:
Edit : I tried blockid 99 on a single player : I used replace tool to change coal in blockid 99 and the world didn't crashed, just coal blocks "disapear". I can't mine blockid 99
nbtoolkit replace -b 7 -a 1 --byr=1:4
nbtoolkit replace -b 9 -a 7 --byr=0:0
The first command replaces all the partial partial bedrock on layers 1-4 with smooth stone
The second command replaces any water on the bottom layer (0) with bedrock. Are there other blocks that can appear as holes here? In a future release I could make the -b flag optional to hit all block types in one go.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
for BLOCK_ID in `seq 1..$MAX_BLOCK_ID`; do echo nbtoolkit replace -b $BLOCK_ID -a 7 --byr=0:0; done
I think. Shell is not my forte. It's overkill, since not all block IDs can spawn in that level... I have downtime window during daytime when no one's playing, so as long as it's not taking an hour+ to run then no biggie.
Does your tool handle custom block id's > 255?
Having an optional -b would be good... if a bit dangerous / useful, in an "the entire world is now lava!" sort of way.
How about a '-bx=id1,id2,id3...' which will replace all blocks EXCEPT those specified? It would be great for making custom scenario maps such as Deserts.
Many thanks for the tool. I think I will be poking through your code this weekend... do you take patches for new features? :smile.gif:
The -bx flag would be a good idea, along with making the -b flag repeatable.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
I saw on this topic but I can't find it anymore. We can delete chunks in a radius to make the map size go down ?
Thanks :smile.gif:
Offhand, I don't believe it will compact region files if they are partially deleted (although this might happen in the future), but it will delete region files that are completely emptied.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
should make a 1000*1000 square around 0 position and erase all chunks outside, isn't it ?
Thanks
Edit: The option is actually --crv, not --cvr
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
strange ?
And another question : what does relight exactly do ? I don't understand the aim
Relight is useful for people who use map generators that cannot correctly calculate their own light (some SDKs have incorrect lighting code or fail to provide it at all), or run tools that manipulate world geometry but can't properly maintain lighting (very common -- just about every block replace tool out there, other than nbtoolkit and mcedit). MC will fix lighting over time but only if you're actively modifying the world. Also as recent updates have demonstrated, even MC has managed to severely break its own lighting code and fixing this is much easier with an outside tool.
I actually need to update nbtoolkit to incorporate the latest version of Substrate which fixes some bugs in things like relight. But it does serve a purpose.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
"The application failed to initialize properly (0xc0000135). Click OK to terminate the application."
Anyone have ideas on why I'm getting the error?
New Chunk Filter option (for all tools that use this option set):
--cp=VAL : Probability that a chunk will be selected even if all other conditions match
New Block Filter option set (currently for 'replace' tool)
--bxr/--byr/--bzr : Same as before
--bi : Block included in match (optional, repeatable, replaces -b option)
--bz : Block excluded from match (optional, repeatable)
--bp : Probability that a block will be selected (replaces -p option)
http://hocuspocus.taloncrossing.com/rii/nbtk2.zip
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate
We actively participate in the MC SMP global bannning system. Join up!
dunno if the modder is still on this great tool ? A question : can we replace multiple blockId by one ? in a single pass ?
Thanks
e.g.
nbtoolkit replace -w path/to/world --bi=90 --bi=91 --bi=93 -a 0
To replace block IDs 90, 91, and 93 with air.
Mods I Develop: Garden Stuff -- Storage Drawers -- Hunger Strike
Tools I Develop: NBTExplorer -- Substrate