These are chat archives for PrismarineJS/minecraft-data

31st
May 2016
Robin Lambertz
@roblabla
May 31 2016 08:41
usesNetty is justs do differenciate pre-1.7 protocol from post-1.7
because they resetted the number
Romain Beaumont
@rom1504
May 31 2016 09:01
yes
my problem was to decide what to do about this parameter for the pocket edition file
and I decided that value doesn't make sense
so I just made it optional
(it doesn't make sense for pe)
Robin Lambertz
@roblabla
May 31 2016 09:02
Yup
It might make sense to instead have something like type: ["pc", "pc-netty", "pe", "classic"] ?
Romain Beaumont
@rom1504
May 31 2016 09:10
well pe and pc are now in 2 distinct namespaces, there's 2 version files
but yeah we probably don't handle all the different kind of versions pre-netty
not sure if the numbering has been reset before that too
I guess that can be done when PrismarineJS/minecraft-data#128 is done
Robin Lambertz
@roblabla
May 31 2016 09:15
PreNetty didn't have any reset
AFAIK
Even classic => pc is continuous
Hans Elias J.
@hansihe
May 31 2016 13:30
rom1504: I really like the knowledge base idea
With protocol I think it would make sense to have some kind of diffs for adjacent protocol versions
At least in addition to the complete protocol file
Romain Beaumont
@rom1504
May 31 2016 14:21
would it be useful as part of the data ?
I considered adding it to the doc PrismarineJS/minecraft-data#136
the problem of actually having a diff file and a full file is it means maintaining both
(well I guess we could generate the diff at each change but still)
Hans Elias J.
@hansihe
May 31 2016 14:23
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
then generate the full files
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
Romain Beaumont
@rom1504
May 31 2016 15:45
ah yeah it's true we could do that
Gjum
@Gjum
May 31 2016 16:00
while auto-propagating changes is useful for maintaining, this would mean that you have to apply all the diffs before you can use the data
Romain Beaumont
@rom1504
May 31 2016 16:13
Gjum: no the idea here was to have both the full json and the diff
we change the diff and then generate the full files automatically
Gjum
@Gjum
May 31 2016 16:54
ok, but then we duplicate all the data
Hans Elias J.
@hansihe
May 31 2016 16:55
You only edit the diffs
Then generate the full files and use them
Romain Beaumont
@rom1504
May 31 2016 17:00
yes the data is duplicated, but not the maintaining
not sure how far we should go about this idea though
there's nothing preventing doing the same with the rest of the data
Romain Beaumont
@rom1504
May 31 2016 17:17
well I guess the rest of the data is automatically generated so it might make less sense to have diffs
Romain Beaumont
@rom1504
May 31 2016 17:28
I think let's generate some diff, to see how it looks, we can decide afterwards
Robin Lambertz
@roblabla
May 31 2016 17:35
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
Romain Beaumont
@rom1504
May 31 2016 17:36
ah yeah good idea
Robin Lambertz
@roblabla
May 31 2016 17:37
with those two things, we should have a fairly robust system :)
Hans Elias J.
@hansihe
May 31 2016 17:38
you could even say webscale