Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create an upgrade table for blocks #4381

Open
madmaxoft opened this issue Aug 31, 2019 · 12 comments
Labels

Comments

@madmaxoft
Copy link
Member

@madmaxoft madmaxoft commented Aug 31, 2019

We'll need a table that will provide the data for upgrading blocks from 1.12 to 1.13. Basically, a map of {BlockTypeNumber, BlockMeta} to {BlockTypeName, BlockState}, such as this:

0	0	minecraft:air
1	0	minecraft:stone
1	1	minecraft:granite
...
54	2	minecraft:chest	facing	north	type	single
54	3	minecraft:chest	facing	south	type	single
...

This will be used by the world loader to upgrade older worlds. For now, we just need it as a string, preferably as a github gist. The format is <BlockTypeNumber><tab><BlockMeta><tab><BlockTypeName><tab><BlockState1><BlockState1Value>...
For blocks that need more information in 1.13+ than the old data value provides (such as a chest doesn't know in older formats whether it's a single or double chest, or a wall doesn't know which sides it is attached to), choose a reasonable default, like shown in the example.

Note: This will be A LOT of boring manual work! Multiple people can work on this, if you claim a range of the block type numbers. I don't suppose there's any datasource we could use to extract the data, rather than typing it manually, but maybe someone has already done something like this (maybe Minutor?) Investigate first.

@willstott101

This comment has been minimized.

Copy link

@willstott101 willstott101 commented Sep 8, 2019

In fact this page: https://minecraft.gamepedia.com/Java_Edition_1.13/Flattening references the following file: https://bugs.mojang.com/secure/attachment/151784/the_flattening.txt which looks quite parse-able if anyone can make sense of it.

@E14

This comment has been minimized.

Copy link
Contributor

@E14 E14 commented Sep 17, 2019

@madmaxoft is this connected to the ProtocolBlockTypePalette or BlockTypeRegistry?

@madmaxoft

This comment has been minimized.

Copy link
Member Author

@madmaxoft madmaxoft commented Sep 17, 2019

It is somewhat inverse to the ProtocolBlockTypePalette - this maps numeric IDs to block name + state for old versions, ProtocolBlockTypePalette maps the opposite direction for new versions.

@E14

This comment has been minimized.

Copy link
Contributor

@E14 E14 commented Sep 17, 2019

I think it should be fairly easy to use blocks.json or the ProtocolBlockTypePalette intermediary format (though blocks.json would be better) to pre-generate a changemap that only needs to be filled out - and even prefill some using the default key, that should make this work more digestible.

@madmaxoft

This comment has been minimized.

Copy link
Member Author

@madmaxoft madmaxoft commented Sep 17, 2019

Since the ProtocolBlockTypePalette is the opposite direction, and the old IDs didn't distinguish many states, there are a lot of "duplicates".
For example, the old IDs have a "redstone wire" block, with no extra data other than signal strength. The new types have many entries, specifying on which sides of the block the wire actually runs, what direction it runs (straight or up) etc.

@E14

This comment has been minimized.

Copy link
Contributor

@E14 E14 commented Sep 17, 2019

The format doesn't really matter in this case, as long as the IDs that are used are the same (are they? I didn't have time to look into the storage format yet) or you want to scan the mapping files on disk instead of loading into memory... You could build the opposite of ProtocolBlockTypePalette::aMapping in the same loop in loadFromString.

Though it doesn't have default key currently, so as stated, blocks.json would be preferable to build it, then you can fill missing fields from the data of the default key. Though for redstone I guess that would mean that it would have to be broken and placed again anyway, if the server actually honors the properties, or the connections would probably be not what's expected.

@madmaxoft

This comment has been minimized.

Copy link
Member Author

@madmaxoft madmaxoft commented Sep 25, 2019

@E14 I have a feeling there's still a misunderstanding about what this upgrade table should do. This has practically nothing to do with the 1.13 protocol blocks. This will be used when loading an old 1.12 chunk from the world, and "upgrading" it to the new 1.13 format. Therefore, the ID-to-blockspec mapping is completely different than in the 1.13 protocol, so it cannot be built from the 1.13 protocol map.

@E14

This comment has been minimized.

Copy link
Contributor

@E14 E14 commented Sep 26, 2019

@madmaxoft I'm talking about generating a "template" with all the 1.13 states to be filled out
Example: https://gist.github.com/E14/986ea00d88719bcc79d65ecd953e23fb
(the ignore table needs to be configured by somebody who knows about the changes to reduce the number of output lines, pretty sure it would be beneficial to start with a blockname->id mapping and integrate that too)

@madmaxoft

This comment has been minimized.

Copy link
Member Author

@madmaxoft madmaxoft commented Sep 26, 2019

I think it'd be easier to have as input the block type and meta, and add the typename and state, rather than the other way around. There are a lot of block types / states in 1.13 that have no 1.12 equivalent, so a lot of the lines in your tsv would need erasing.

blockname <-> id mapping is impossible, due to exceptions such as colored wool, which is represented as a single block with the color in its meta nibble.

@E14

This comment has been minimized.

Copy link
Contributor

@E14 E14 commented Sep 26, 2019

I didn't really want to make it a huge discussion...

I'd say, before there was nothing, now there is a template which may be filled out (...or not), including a generator which enables you to pre-filter said list in a reasonably descriptive manner.

@madmaxoft

This comment has been minimized.

Copy link
Member Author

@madmaxoft madmaxoft commented Sep 26, 2019

Thinking about this more, we might even need the full ProtocolBlockTypePalette for 1.12 and below, if we want to still support those protocols in the end. So it would be a good idea to instead base the mapping on the ProtocolBlockTypePalette, as you suggested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.