minecraft-data

minecraft-data copied to clipboard

Would be interesting.

16:23 <hansihe> i would think the optimal way to maintain the protocol files would be to start at some base version, then have each version be represented as a diff from the last 16:23 <hansihe> then generate the full files 16:24 <hansihe> keep in mind i have little knowledge on how you maintain/add new versions, but if it was done like that, changes to things like naming in one protocol version would (mostly) automatically be propagated to the others

This might be a good idea.

A diff could simply contain the packet that changed. Things that would need to be done:

• [ ] script to generate the diff between 2 protocol.json
• [ ] script to generate the full file from a base and a diff

Lol. This was the way I originally wanted to handle the protocol data, and after a long argument with... erm, either myself or you " ? I opted to go down the "full protocol.json route".

A pro of diffs is that if there's a bug in 1.5 that snowballs to 1.6, 1.7, etc..., fixing it in 1.5 will fix all affected versions. The con is obviously that if 1.6 didn't have that change, well now you broke the later versions.

Another con is that each protocol.json becomes dependant on the previous ones to make sense.

Yeah we argued about that a long time ago. My problem with it (as Gjum just said on gitter) was mostly that then users have to generate the protocol.json themselves. But if we have the diff + the full file then it's convenient enough. (we change the diff manually, and generate the full file automatically)

And it makes much more sense now that we support snapshots and many small versions, there are little diff between those. And that the name-id mapping is just in one packet.

just a quick idea, we can have a git hook that autogenerates the full file from the diffs pretty easily. so we don't forget. Also will want to have the build status make sure the generated file matches the in-tree file

Here is a proposal for a json diff format:

• from 16w20a to 1.10-pre1
• from 1.8 to 1.9.4
• the script

old means "types to remove", new means "types to add"

We could use something like this to display a more useful diff between types. (Without having to define a diff format for each type)

Why the need to specify the oldType ? Is it purely for diff readability ?

Because without it we don't know what packets to remove. Also it makes the diff reversable (which might be useful I guess ?)

Although if we don't care about reversability, we could add a "removedTypes" with just a list of names. (and remove oldTypes)

I think the full jsons are better for projects that will only be using the information of one protocol. I don't want to have to patch a base json with a diff if I can use a complete one instead.

I do think displaying the diffs is a good idea. It might be the easiest way to store them, but their use cases are fewer.

Even if we put json diff in the repo, the full files will still be available ;)

@phase the idea is to make maintenance (AKA editing the files) easier, along with making the differences easier to see. The full file will still be available, but will be auto-generated when pushing a modifications by going from the base file and applying the patch files.