Minecraftforge: Blockstate list in the level.dat

[gentlegiantJGC]

I am part of a team that is working on a program called Amulet which is planning to supersede MCEdit (we are also the team that maintain MCEdit). The new editor is working natively in blockstates and we are trying to work out how we can support Forge.

From what I can tell in 1.12 there is a list in the level.dat mapping from numerical id in the chunk to string id which is perfect for 1.12 and below. This is also present in 1.13 in the same format but is more limiting since it is working in blockstates.

We can load the chunk and know what each block is based on the chunk pallet and can load models from that. What we can't do is know what other states there are for that block or other blocks for use in a fill or other command.

For us the ideal option would be to have access in the level.dat file to all the possible states of the last version it was opened in. (similar to the minecraft server.jar output from net.minecraft.data.Main but with the added blocks as well).

The second option would be some other way to access this list possibly through the server so the user can at least point to a server to generate the list however for us the former would be preferred. #5298

[gentlegiantJGC]

Just had a thought that could solve our problem unless you can see an issue with it (I don't know too much about modded myself)

If we asked the user to point to their mod folder we could scrape the blockstates from the resources in the jar file. Hopefully the chunk blockstates match the model blockstates (afaik they do for vanilla and I think that is the whole point)

[tterrag1098]

Relying on client resources for blockstate data is a bad idea, it's not required to list all permutations in the blockstate json.

[williewillus]

That won't work. In 1.13+ blockstate jsons are permitted to omit any properties if rendering doesn't care about block properties.
Given a block with a single property of 4 values, this is still a valid blockstate json

{
    "variants": {
        "": { "model": "mymod:block/thing" }
    }
}

which says "I don't care what the value of any of the properties are, just use this model"

[gentlegiantJGC]

Ah ok. That won't work then. Thanks for letting me know. I don't know quite how we can achieve proper forge support if we don't know what blocks can be put in the world. One option is to have the user manually enter the blockstate but that is just asking for issues.

I know it was said in the other issue that the block state list won't get written to disk until Mojang removes sequential ids. I didn't fully understand this. Are they the network ids because I can't see how they are used?

Even just a list of values for each property would be a great help for us even if it is not used internally by forge. Something like this fence example: (default value would be nice but not required)

{
    "properties": {
        "east": [
            "true",
            "false"
        ],
        "north": [
            "true",
            "false"
        ],
        "south": [
            "true",
            "false"
        ],
        "west": [
            "true",
            "false"
        ]
    },
    "defaults": {
        "east": "false",
        "north": "false",
        "south": "false",
        "west": "false"
    }
}

[MajorTuvok]

If you wanted to, you could just write a mod, which is run by a user and then generates all necessary data for you...

You could then also choose the best format for your needs, at will write additional data, if you happen to need it and do a lot of stuff my tired brain can't think of at the moment...

[gentlegiantJGC]

Ok thanks. That does look like our best option at this point

[tterrag1098]

While it is true that in 1.13 IDs are mapped to states, I don't see why this is a problem. States are now the first class citizens of the save format. No longer is it "blocks with 4 bits of data sometimes". So why can't you just treat states as you used to treat blocks? Why are your needs special in a way that nothing else is? Maybe I'm not understanding what you need out of this.

[gentlegiantJGC]

We are natively dealing with blockstates internally. To clarify I am not asking for a map from runtime id to blockstate (if that is what you are talking about.)

We simply need to acquire somehow a list of all the blocks that the mods add for that world and the properties and values possible for each block. We want to be able to say to the user "here is a list of all the blocks you can pick from" have them pick a block and then be able to say "here are all the properties for that block". They then pick values for each property and we can set that block in the world.

The issue is from the save format we don't know any of that information. It looks like our best bet is to copy the user's forge directory that they specify and load all the mods used by the world along with a mod we create that reports back all the blocks added and properties for each block.

[LexManos]

Yes, for your situation, your best bet is to write a metadata dumper mod that people can load up.
Or you could go along and write a internal DB that builds a list of blockstates from the mods folder.
Dumping the full list on Forge's end would be expensive for a very small usecase that has no use in the game/forge.