Glitches/inaccuracies in demonstrations

[vzhuang]

There seem to be quite a few bugs in the demonstrations. I'll give three examples (all from Treechop):

• V1_equal_olive_chimera-6_10120-13407
  • There is clearly a glitch in frames 2266/2267. In general, the player seems to lag out from frames 2000-2300.
• V1_virtuous_mustard_greens_raven_spirit-8_19711-24322
  • Frames 1139-1149: screen moves even though camera angles are zero.
• V1_virtuous_mustard_greens_raven_spirit-8_15578-19208
  • Frames 356-370: agent keeps moving forward even though forward action is not active since frame 355. There is some visual glitch in frame 371.

This seems like a pretty widespread issue to me. If it's related to the data collection method, can you guys comment on the different kinds of possible bugs?

Related to #134

[MadcowD]

Hey @vzhuang! Thanks for making this issue. Thought I should comment to help explain some of these things.

"Lagging Out": In Minecraft and generally computer games players occasionally no-op/afk during play! I've inspected the packet streams we record to make sure that this is the case and in these streams it's certainly the case that these players were just AFKing during a demonstration. If you want to avoid learning no-op actions, just remove frames if the player has no-op'd for more than n frames. Honestly, I don't really have a better solution; there are some people doing research with this dataset that actually want to use the no-op frames (e.g. in HCI research) to build more 'player-like' agents. We could filter them out during our data-processing step, but we'd rather this be an option on the researcher's side than remove this information from the dataset. --> Perhaps the best move here is making a page in the docs discussing this and other properties of the data.

"Movement/Camera Changes w/o Actions": In Minecraft movement actions have momentum! (Open up Minecraft right now and gently tap the forward key, or `gym.make('MineRLTreechop-v0'), perform a bunch of forward actions and then slowly step through a series of no-ops). This is a part of the environment and is reflected in the data. That being said, our renderer (which takes game-packets and re-renders them as player streams), is smoothing camera movements; that is, we record the delta of player camera angle, but visually it takes a few ticks for this to appear in the stream. --> We can add smoothing to the camera action in the simulator, or remove smoothing from the data. I'll make an issue to track this :)

"Visual Glitches": Thanks for finding this! We render our videos using ffmpeg, and I suspect what is happening is that after along series of no-ops the video codec/bitrate we are choosing compreses that part of the video and then encounters a keyframe forcing a v-update. This is totally recoverable, but the size of the dataset will increase. Are you okay with this? -> I'll make an issue to track these visual artifacts.

"Related to #134" These inaccuracies that you're observing are not actually related to what was happening in #134; there a player installed an incompatible mod and we have since blacklisted their streams (minerl-0.2.3).

Luckily, we generate our dataset by re-rendering packet streams, so we can continue to fix/imporve accuracies and re-release the data as you find issues!

Thanks again :) :) :) So happy to see people using the data! I'm going to close this issue and track the issues separately.

[MadcowD]

(Here is some more info on interpolation) Since MC only ticks 20 times per second, everything is rendered at interpolated positions based on a parameter passed to the render method (usually called renderPartialTicks or just partialTicks). It's most likely this kind of interpolation which you're seeing. You can prevent it by setting mc.timer.renderPartialTicks to 1 (or 0 depending on how/when you tick) after updating the timer [1]. For that to work properly, you will ofc have to make sure that you update the replay by exactly one tick per frame (i.e. make sure no update packets are late) and by default the replay doesn't contain sufficient information to do that but iirc you're already doing something like that.

Players and minecarts additionally (for whatever reason) interpolate from their current position to their actual position over several ticks (usually 3 for players and 5 for minecarts iirc) after they were teleported or have moved significant distances within one tick for some other reason. Have a look at EntityOtherPlayerMP#otherPlayerMPPosRotationIncrements and similarly named fields (afaict minecarts function in more or less the same way though the names for the fields are different and the effect is less noticeable since they snap to rails anyway).

I