New data in minecraft-data about minecraft-data HOT 14 OPEN

maybe these kind of thing too https://github.com/AlexKvazos/MinecraftChat/blob/master/app/server/parsers/vanilla.js

from minecraft-data.

spawnedObjectTypes / mobTypes are integrated (entities.json)

from minecraft-data.

Wurstmineberg has a decent collection: https://github.com/wurstmineberg/assets.wurstmineberg.de/tree/master/json

from minecraft-data.

Those Physics constants are only true for Mineflayer's implementation of Physics which is divergent from the 20tps notchian standard (Mineflayer physics run at 50tps). Physics constants should probably come from the wiki

http://minecraft.gamepedia.com/Transportation
http://minecraft.gamepedia.com/Gravity#Motion_of_entities

from minecraft-data.

no, mineflayer physics run at 20tps https://github.com/andrewrk/mineflayer/blob/master/lib/plugins/physics.js#L12
(the position update run at 50tps but that's a separate thing)

Now minecraft-data should probably use the /tick unity yes.

from minecraft-data.

@Gjum yeah I saw that. Not sure what we need from what they have, not sure if taking what they have is a correct extraction process (what happens when they stop updating ?)

from minecraft-data.

@rom1504 You have your calculation backwards
Physics runs every 20ms, 1sec/20ms is 50tps
Position Update runs every 50ms, 1sec/50ms is 20tps

Which makes perfect sense, if Mineflayer was updating at 50tps it would get hungry and die very quickly. Notchian client runs Physics and Player Update at the same time, 20tps. I never understood why Mineflayer ran Physics so fast.

from minecraft-data.

Ah indeed you're right.
I don't know why we are running physics so fast, I think at some point I tried to change it to the same value as position and it didn't change much, I might try that again.
But anyway, mineflayer takes into account the deltaSecond before the last iteration (https://github.com/andrewrk/mineflayer/blob/master/lib/plugins/physics.js#L127), so our values are independent of the ticking speed.

Edit: it seems all of mineflayer's physics was done in this commit PrismarineJS/mineflayer@0e57f53
Idk where andrewrk was taking his values, but it might be related to an old minecraft version.

Edit: alright I did some digging and found this https://github.com/andrewrk/mineflayer/blob/8ad380b0226aa5c57835d73231cd9a6283519e93/src/PhysicsDoer.cpp#L5 back in mineflayer cpp days (that's the last commit before the switch to node.js)
This is the correct value (20 tps), so I believe the explanation is simple : the position update was (https://github.com/andrewrk/mineflayer/blob/8ad380b0226aa5c57835d73231cd9a6283519e93/src/Game.cpp#L24) in the ms format and the physics update was in the tps format. When converting he didn't think about it, and made the same mistake I just did up there, and here we are.

I'll try later to put everything to the correct ticking speed, I'm pretty sure it doesn't change anything.

from minecraft-data.

Please add http://wiki.vg/Entities#Mobs, as this is not the same as in #11.

from minecraft-data.

Seems both page have pbs (http://minecraft.gamepedia.com/Data_values/Entity_IDs and http://wiki.vg/Entities#Mobs), better fix them before doing anything.

from minecraft-data.

• Enums of http://wiki.vg/Protocol in general (the non packet table), a bit like instruments.json (http://wiki.vg/Block_Actions) see #56 (comment)

from minecraft-data.

• http://wiki.vg/Protocol#Particle (#75)

from minecraft-data.

I came across another possible source of data http://technical-minecraft.wikia.com/

from minecraft-data.

This page lists containers that store items. This can be presented in windows.json as a persistent flag to indicate if an item that is deposited in there will drop when the window is closed or if it will still be in there when the container is reopened.

Also some windows send a Number Of Slots = 0 when getting opened, which is probably related to this persistent flag.

from minecraft-data.