add external JSON for block names/colors/IDs?

[TheTechmage]

Could you please add an external JSON file with all of the block IDs, colors and names that c10t reads from? I would like to replace all of the black blocks in my level with either the appropriate colors, or remove some of them (tallgrass for example), but Editing the code you have seems a bit tedius, since they aren't associated with their color, name, and ID at the same time. Example:

MaterialName[Stone] = "Stone";
//...
setColor(Stone, 0, color(128,128,128,255));
//...
MaterialModes[Stone] = Block;
// Where is the ID specified, and why is everything spread out?

I don't know C++, but I know that the above code could be simplified in some other languages like the following psuedo-code

function make_material(String name, Color blockColor, BlockType blockType) {
    despacedName = stripspaces(name);
    MaterialName[despacedName] = name;
    setColor(despacedName, 0, blockColor);
    MaterialModes[despacedName] = blockType;
}
Enum BlockType {
    Block, HalfBlock;
}
//...
make_material("Stone", color(128,128,128,255), BlockType.Block);

Then if you did add the external JSON for blocks, you could just loop through and call the function.

Thanks =)

[uap-universe]

Is the color file feature suitable for your case? Or must it be explicitly a JSON file?

You can dump out the default color file by calling c10t with the -W option. Modify the file and load it with the -P option. Please note, that you must use the block-IDs insted of real names for custom blocks as c10t of course doesn't have enum constants for custom (unknown) blocks. You may also specifiy different colors for different data values by writing the ID in the format <block-id>:<data-value>. You will see how it works, when you inspect the file that -W prints out.

[TheTechmage]

Heh, I didn't see the -W and -P parameters, thanks! Anyways, the reason why I was suggesting JSON is because it is easier to read through and people could add in extra parameters to it without worrying about whether not not it breaks the syntax (since JSON is easier to read, and you could ignore excess parameters). For example, I think that the following would break with the current code:

#<block-id>          <base R,G,B,A>   <side R,G,B,A>
0 Air                  255,255,255,0    255,255,255,0
1 Stone                128,128,128,255  103,103,103,255
2 Grass                120,172,70,255   108,78,54,255

Yet if we did the same thing with JSON:

{
    {
        id: 0,
        "_comment": "this line, and the line above would be ignored, or it could be used so blocks could be out of order",
        block-id: "Air",
        color: "255,255,255,0",
        side-color: "255,255,255,0"
    }
    {
        id: 1,
        block-id: "Stone",
        color: "128,128,128,255",
        side-color: "103,103,103,255"
    }
    {
        id: 2,
        block-id: "Grass",
        color: "120,172,70,255",
        side-color: "108,78,54,255"
    }
    {
        id: 3,
        block-id: "Dirt",
        color: "134,96,67,255",
        side-color: "108,78,54,255"
    }
    {
        id: 4,
        block-id: "Cobblestone",
        color: "100,100,100,255",
        side-color: "81,81,81,255",
        use: "Building Foundation"
    }
    {
        id: 5,
        block-id: "wood",
        color: "157,128,79,255",
        side-color: "127,103,64,255",
        use: "Building Walls"
    }
}

It looks nicer, and doesn't break =D One idea that I have is that the fields that aren't used could be re-output in JSON so that web devs (and etc.) could use it to make a key or use them for some other purpose.