Underground structures look more distinctive with black wall edges, allowing to see whether cave blocks next to each other are connected or not. The old Delphi version supported this, I'm working on the C# implementation:
I've found a bug in the latest version (0.7.315dev); the world seed isn't being displayed correctly; for example, the seed "-123775873255737467" is being displayed as "-19138561" and the seed "-8431078562958559239" is being displayed as "-1", which seems to be a problem with handing the 64 bit seed values (I'm guessing that Unmined is trying to use 32 bit integers).
I've found a bug in the latest version (0.7.315dev); the world seed isn't being displayed correctly; for example, the seed "-123775873255737467" is being displayed as "-19138561" and the seed "-8431078562958559239" is being displayed as "-1", which seems to be a problem with handing the 64 bit seed values (I'm guessing that Unmined is trying to use 32 bit integers).
The big endian int64 decoder was wrong. Thank you for reporting.
I don't think it matters which order the "Applies to" and "Basecolor" are in. It will also read Minecraft names as well as item ID numbers. I used the Mapwriter color file, and that uses ID numbers, so that is how I formatted mine. If an item has only one instance, no meta data, then just use the number or item name, if it has several types with different meta data for each, use the format XXXX:XXXX to define each different object by it's metadata. Same goes for named items
Rollback Post to RevisionRollBack
D_B
To tell them how to live is to prevent them living.
That appear to be what the mod created. I renamed them to .json and put them in the Metapacks folder and ran uNmINeD.0.9.324dev and got this error:
System.ArgumentNullException: Value cannot be null.
Parameter name: key
at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& value)
at Unmined.Core.Metapacks.BlockDictionary.Refresh()
at Unmined.Core.Instance.UnminedInstance..ctor()
at Unmined.WpfApp.UnminedBootstrapper.OnStartup(Object sender, StartupEventArgs e)
at Unmined.WpfApp.App.OnStartup(StartupEventArgs e)
at System.Windows.Application.<.ctor>b__1(Object unused)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
I take it I did something wrong? Putting the files in the Stylesheets folder allows the program to run but does not do anything for colors.
Appears it's just the metadump.blocks file that causes the problem?
A few issues and suggestions involving custom style JSONs:
1. Is it possible to make the mod name in block IDs default to 'minecraft' if unspecified? That way you could use 'stone' instead of 'minecraft:stone'.
2. When a data value isn't specified, it should apply to all versions of that block. For example, applying a color to 'minecraft:spruce_stairs' doesn't color anything. You have to include minecraft:spruce_stairs:0, minecraft:spruce_stairs:1, etc. I seem to remember this being how it worked in earlier versions, but in the latest release you have to manually specify all versions of each block.
3. Do Hue/Id/Lightness/Saturation definitions support anything except HSL? It'd be easier to write custom stylesheets if they supported hex, like the BaseColorId/AppliesTo definitions do.
4. Related to the above, would it be possible to make the BaseColorId/AppliesTo definitions override the HSL color definitions? Currently, you can't change gravel's color using {"BaseColorId": "#6c664b","AppliesTo": ["minecraft:gravel"]}, because the HSL definition in the default stylesheet takes priority, and the only way to color gravel is by adding a "Colors" block to your custom stylesheet and redefine the gravel color using HSL, which is more work and less intuitive.
1. Is it possible to make the mod name in block IDs default to 'minecraft' if unspecified?
Yep, I'll do it
2. When a data value isn't specified, it should apply to all versions of that block. For example, applying a color to 'minecraft:spruce_stairs' doesn't color anything.
It's a bug, eh.
3. Do Hue/Id/Lightness/Saturation definitions support anything except HSL? It'd be easier to write custom stylesheets if they supported hex, like the BaseColorId/AppliesTo definitions do.
Currently it supports HSL only. Adding hex is a good idea, thx.
4. Related to the above, would it be possible to make the BaseColorId/AppliesTo definitions override the HSL color definitions? Currently, you can't change gravel's color using {"BaseColorId": "#6c664b","AppliesTo": ["minecraft:gravel"]}, because the HSL definition in the default stylesheet takes priority, and the only way to color gravel is by adding a "Colors" block to your custom stylesheet and redefine the gravel color using HSL, which is more work and less intuitive.
It's not the HSL definitions, I think it's the same bug as 2.
I'm going to change the way how stylesheets work. There will be more and shorter tags like #vegetation, #stone, #stairs, #tree, #leaves, and coloring all stone stair blocks will look like {"SetColor": "#bbbbbb", "Blocks": ["#stone #stairs"]}, or giving a different tone to all BiomesOPlenty leaves is {"AdjustHue": "-6", "Blocks": ["biomesoplenty:* #leaves"]}. I have plans to support biomes too, like {"SetHue": "48", "Blocks": ["#water"], "Biomes"=["SWAMP", "DEAD"]}.
Having an issue with uNmINeD.0.10.331dev. For some reason, a chunk is missing from the map I downloaded from my server this morning. It might have been corrupted or the file just didn't download properly, as MC Edit says the chunk is missing. Unmined fails to show the entire 16x16 chunk section that contains that chunk. I re-downloaded the region file and it works fine, so there was a problem, but it would be better if it could show all the chunks that exist and just skip the single one that is missing/corrupt, instead of a 16x16 set of chunks.
Also, the slicer toolbar goes away every time a new dimension is selected, I'd rather it just stay visible all the time.
It seems Unmined doesn't like the asteroids dimension from galacticraft, it only shows a few chunks and then goes blank when the map is panned in any direction.
Having an issue with uNmINeD.0.10.331dev. For some reason, a chunk is missing from the map I downloaded from my server this morning. It might have been corrupted or the file just didn't download properly, as MC Edit says the chunk is missing. Unmined fails to show the entire 16x16 chunk section that contains that chunk. I re-downloaded the region file and it works fine, so there was a problem, but it would be better if it could show all the chunks that exist and just skip the single one that is missing/corrupt, instead of a 16x16 set of chunks.
Also, the slicer toolbar goes away every time a new dimension is selected, I'd rather it just stay visible all the time.
It seems Unmined doesn't like the asteroids dimension from galacticraft, it only shows a few chunks and then goes blank when the map is panned in any direction.
Thanks for reporting these.
I'm cleaning the code now, and implementing proper error handling and exception reporting.
All chunk data read from region files are converted to "tiles" first before any processing. These tiles are 256x256 blocks wide (16x16 chunks), causing much less memory fragmentation and CPU overhead compared to chunks.
Works fine, just tried it on a 1.8.2pre5 world, no problems.
D_B
To tell them how to live is to prevent them living.
You can customize colors by editing files in Stylesheets and Metapacks folder.
Next release will have more colors by default:
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
The big endian int64 decoder was wrong. Thank you for reporting.
{"DisplayName": "uNmINeD custom colors", "Items": [ {"AppliesTo":["567"],"BaseColorId":"#b895b5"}, {"AppliesTo":["568:0"],"BaseColorId":"#395723"}, {"AppliesTo":["568:1"],"BaseColorId":"#406237"}, ] }I don't think it matters which order the "Applies to" and "Basecolor" are in. It will also read Minecraft names as well as item ID numbers. I used the Mapwriter color file, and that uses ID numbers, so that is how I formatted mine. If an item has only one instance, no meta data, then just use the number or item name, if it has several types with different meta data for each, use the format XXXX:XXXX to define each different object by it's metadata. Same goes for named items
D_B
To tell them how to live is to prevent them living.
"Id": 785,
"Name": "arsmagica2:stairsWitchwood",
"UnlocalizedName": "tile.arsmagica2:stairsWitchwood",
"LocalizedName": "Witchwood Stairs",
"CanProvidePower": false,
"LightOpacity": 255,
"LightValue": 0,
"BlockColor": "#FFFFFF",
"Material": {
"IsSolid": true,
"IsLiquid": false,
"IsOpaque": true,
"CanBurn": true
},
"Class": [
"am2.blocks.WitchwoodStairs",
"net.minecraft.block.BlockStairs",
"net.minecraft.block.Block"
],
"MapColor": "#685332"
},
uNmINeD will able to read these dumps to deal with unknown blocks automatically, and convert to metapacks you can fine-tune and share with others.
Btw I have created the included metapacks by hand using Excel spreadsheets and formulas
Edit:
The metadata dump mod is now available at http://unmined.intro.hu/metadump for MC 1.7.10 and 1.8.
metadump.biomes.txt
metadump.blocks.txt
metadump.version.txt
That appear to be what the mod created. I renamed them to .json and put them in the Metapacks folder and ran uNmINeD.0.9.324dev and got this error:
Parameter name: key
at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& value)
at Unmined.Core.Metapacks.BlockDictionary.Refresh()
at Unmined.Core.Instance.UnminedInstance..ctor()
at Unmined.WpfApp.UnminedBootstrapper.OnStartup(Object sender, StartupEventArgs e)
at Unmined.WpfApp.App.OnStartup(StartupEventArgs e)
at System.Windows.Application.<.ctor>b__1(Object unused)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
I take it I did something wrong? Putting the files in the Stylesheets folder allows the program to run but does not do anything for colors.
Appears it's just the metadump.blocks file that causes the problem?
D_B
To tell them how to live is to prevent them living.
0.9.x cannot read these dumps, I'm working on it.
D_B
To tell them how to live is to prevent them living.
1. Is it possible to make the mod name in block IDs default to 'minecraft' if unspecified? That way you could use 'stone' instead of 'minecraft:stone'.
2. When a data value isn't specified, it should apply to all versions of that block. For example, applying a color to 'minecraft:spruce_stairs' doesn't color anything. You have to include minecraft:spruce_stairs:0, minecraft:spruce_stairs:1, etc. I seem to remember this being how it worked in earlier versions, but in the latest release you have to manually specify all versions of each block.
3. Do Hue/Id/Lightness/Saturation definitions support anything except HSL? It'd be easier to write custom stylesheets if they supported hex, like the BaseColorId/AppliesTo definitions do.
4. Related to the above, would it be possible to make the BaseColorId/AppliesTo definitions override the HSL color definitions? Currently, you can't change gravel's color using {"BaseColorId": "#6c664b","AppliesTo": ["minecraft:gravel"]}, because the HSL definition in the default stylesheet takes priority, and the only way to color gravel is by adding a "Colors" block to your custom stylesheet and redefine the gravel color using HSL, which is more work and less intuitive.
Yep, I'll do it
It's a bug, eh.
Currently it supports HSL only. Adding hex is a good idea, thx.
It's not the HSL definitions, I think it's the same bug as 2.
I'm going to change the way how stylesheets work. There will be more and shorter tags like #vegetation, #stone, #stairs, #tree, #leaves, and coloring all stone stair blocks will look like {"SetColor": "#bbbbbb", "Blocks": ["#stone #stairs"]}, or giving a different tone to all BiomesOPlenty leaves is {"AdjustHue": "-6", "Blocks": ["biomesoplenty:* #leaves"]}. I have plans to support biomes too, like {"SetHue": "48", "Blocks": ["#water"], "Biomes"=["SWAMP", "DEAD"]}.
(work-in-progress screenshots of unreleased version)
D_B
To tell them how to live is to prevent them living.
Yes, position of the sun and shadow strength are adjustable.
The code now is slow as hell, I have to optimize.
Here are some (not so HQ) longer shadows with low sun altitude:
Edit: added two images (with/without shadows). RWG landscapes are beautiful.
D_B
To tell them how to live is to prevent them living.
Also, the slicer toolbar goes away every time a new dimension is selected, I'd rather it just stay visible all the time.
It seems Unmined doesn't like the asteroids dimension from galacticraft, it only shows a few chunks and then goes blank when the map is panned in any direction.
D_B
To tell them how to live is to prevent them living.
Thanks for reporting these.
I'm cleaning the code now, and implementing proper error handling and exception reporting.
All chunk data read from region files are converted to "tiles" first before any processing. These tiles are 256x256 blocks wide (16x16 chunks), causing much less memory fragmentation and CPU overhead compared to chunks.