These are chat archives for PrismarineJS/minecraft-data

21st
Oct 2015
Gjum
@Gjum
Oct 21 2015 21:05
rom1504, how will 1.9 loot tables be integrated? they will replace the drops array in blocks.json (and entity.json if it would already track drops)
Romain Beaumont
@rom1504
Oct 21 2015 21:28
hmm
well they are a superset to drops aren't they ?
so, we just take this as the new drops format and write 1.8 drops that way
(trying to keep the same format for 1.8 and 1.9 so it's easier to mcdata users to go cross version)
I haven't quite resolved the "copying the data" problem though, which seems more and more important as mojang start using readable formats
well, the mcwiki do share that data anyway, so I guess it's ok to copy it
Gjum
@Gjum
Oct 21 2015 21:32
same thing with language files
... regarding the need for copying of data
btw, drop tables are world-specific, not just version-specific
Romain Beaumont
@rom1504
Oct 21 2015 21:33
world specific ?
Gjum
@Gjum
Oct 21 2015 21:33
but there are default tables I guess, so these would be used, because modded server can already override drops
yeah
Romain Beaumont
@rom1504
Oct 21 2015 21:34
do you mean they change with the server ?
Gjum
@Gjum
Oct 21 2015 21:34
WORLD_FOLDER/data/somethingDropsFoo
see the mc forum article I linked
Romain Beaumont
@rom1504
Oct 21 2015 21:34
do they send that to the client or it's all handled server side ?
Gjum
@Gjum
Oct 21 2015 21:34
drops are server-side in all versions
Romain Beaumont
@rom1504
Oct 21 2015 21:35
okay
so yeah indeed we could store the default tables
Gjum
@Gjum
Oct 21 2015 21:36
so what about .lang?
Romain Beaumont
@rom1504
Oct 21 2015 21:38
I'm not sure
any clue how big these lang files are ?
tbh, if I ignore all legal issues, I'd prefer them to be in minecraft-data
it would make things easier
providing they are not too big
for example, I probably wouldn't put models and images in minecraft data I think
(let's not make minecraft-data 100Mo)
@Gjum what about rom1504/python-minecraft-data#8 ?
Robin Lambertz
@roblabla
Oct 21 2015 21:45
@rom1504 You could just make mc-data download them at runtime or something like that
Gjum
@Gjum
Oct 21 2015 21:46
en_us.lang is 118K, <=2678 lines
*en_US.lang
Robin Lambertz
@roblabla
Oct 21 2015 21:46
But i agree importing them in repo would be besy
Although we would have to translate them to json (they are ini files)
Gjum
@Gjum
Oct 21 2015 21:47
we could copy them as is and convert at runtime
thats working fine already in spock
Robin Lambertz
@roblabla
Oct 21 2015 21:47
That's annoying
I think mc-data should contain only json
Gjum
@Gjum
Oct 21 2015 21:48
well if you have json or ini, you have to convert it to memory anyways
Robin Lambertz
@roblabla
Oct 21 2015 21:48
A converter should be simple enough
Yeah but it's a matter of keeping the repo consistent
Otherwise we start depending on a json impl and an ini impl
Next thing we know we'll have 50 different formats in the repo
Romain Beaumont
@rom1504
Oct 21 2015 21:56
Ah if it's that's small we can include it yeah
I agree about putting it in json
Robin Lambertz
@roblabla
Oct 21 2015 21:56
,
Gjum
@Gjum
Oct 21 2015 21:57
would it be a flat map, or would we nest the maps by splitting the keys at "."?
i.e. would I do lang['item.banner.straight_cross.lightBlue'] or lang['item']['banner']['straight_cross']['lightBlue']
Robin Lambertz
@roblabla
Oct 21 2015 21:58
If we were to keep the semantics of ini we would split on dots
But I don't know what's best for our specific use case
Gjum
@Gjum
Oct 21 2015 22:00
chat sends strings as "chat.type.text", so splitting is not needed for that at least
Romain Beaumont
@rom1504
Oct 21 2015 22:00
Yeah I don't think we need to split
Gjum
@Gjum
Oct 21 2015 22:01
but exploring the translations would benefit from splitting, as you can get lang['chat'].keys() for example
Romain Beaumont
@rom1504
Oct 21 2015 22:02
And I think keeping the unindexed pattern is a good idea (and pymcdata would index ny whatever needed)
Gjum
@Gjum
Oct 21 2015 22:02
what about mcdata doesnt split, but an implementation using mcdata can still split if needed
^
Romain Beaumont
@rom1504
Oct 21 2015 22:03
Yeah
Gjum
@Gjum
Oct 21 2015 22:08
python3 -c "import json;print(json.dumps({k:v for k, v in map(lambda l: l[:-1].split('=', 1), filter(lambda l: l != '\n', open('en_US.lang')))}))" > lang.json
Gjum
@Gjum
Oct 21 2015 22:15
mh, sorted would be better, change that to python -c "import json;print(json.dumps({k:v for k,v in map(lambda l:l[:-1].split('=',1),filter(lambda l:l!='\n',open('en_US.lang')))},indent=2,sort_keys=True))" > lang.json
oh, apparently it also stores the block.name -> block.displayName mapping, that would be duplicated...
Romain Beaumont
@rom1504
Oct 21 2015 22:27
ah really ?
all the blocks ?
Gjum
@Gjum
Oct 21 2015 22:33
yep
Romain Beaumont
@rom1504
Oct 21 2015 22:33
where is that en_US.lang file already ?
Gjum
@Gjum
Oct 21 2015 22:34
grep '"tile.' lang.json | wc -l prints me 342, so yeah, all items+blocks
Robin Lambertz
@roblabla
Oct 21 2015 22:34
But it has no name id mapping :(
Gjum
@Gjum
Oct 21 2015 22:36
yeah we would have to define white=0 oak=0 etc.
Romain Beaumont
@rom1504
Oct 21 2015 22:37
where are the names ?
"tile.clayHardenedStained"
Gjum
@Gjum
Oct 21 2015 22:37
rom1504, lang is in 1.8.8.jar /assets/minecraft/lang/
Romain Beaumont
@rom1504
Oct 21 2015 22:38
clayHardenedStained is not the name
Gjum
@Gjum
Oct 21 2015 22:38
and names are, sec
Romain Beaumont
@rom1504
Oct 21 2015 22:38
the name is (minecraft:)stained_hardened_clay
Gjum
@Gjum
Oct 21 2015 22:38
hm yeah
so we would need a mapping function for tile.X <-> block.name
I guess we're fine keeping it in blocks+items for now
Romain Beaumont
@rom1504
Oct 21 2015 22:40
yeah
Gjum
@Gjum
Oct 21 2015 22:42
and btw, theres some items/blocks missing in released 1.9 pymcdata (and I think mcdata too), see last line: https://gist.github.com/Gjum/d661b4beff8da7b65c89
Romain Beaumont
@rom1504
Oct 21 2015 22:42
I think what we could do is remove displayName in blocks.json and items.json, instead put internationalizationName (or some shorter field name :d), and then let pymcdata/spock use the display name from the lang.json file
(which wouldn't have to be english by the way)
Gjum: yes I haven't update 1.9 blocks.json yet
only items.json
*updated
Gjum
@Gjum
Oct 21 2015 22:43
ah ok
yeah, the i18n mapping would be even more useful, although more inconvenient for the wrappers
Romain Beaumont
@rom1504
Oct 21 2015 22:45
yeah but that's a more general approach I think, since the "display" is really a i18n thing
Gjum
@Gjum
Oct 21 2015 22:45
yup
Romain Beaumont
@rom1504
Oct 21 2015 22:46
it would probably apply to entities and whatnot
Gjum: where is that jsfiddle coming from ?
Romain Beaumont
@rom1504
Oct 21 2015 22:49
ah right
I'm glad mojang is using json anyway
Gjum
@Gjum
Oct 21 2015 22:49
no idea where the item name list comes from though