I can help you test this out @Kragrathea. You might benefit from adding release channels to your software update check...
The release channels are interesting! I started the process, but I want to mess with it more before I start using it.
I started a GitHub discussion about the new release:
I can test if you still need eyes on it.
One comment about the current 1.x version - it seems like x/y travel moves are REALLY slow compared to what the printer is doing. What controls this? FWIW, slicing with current Cura.
current position is typically ahead of what is actually printing, because OctoPrint's positioning of gcode viewer is as the command gets sent to the printer IIRC and your printer has a buffer that it fills up.
yes, but this is causing it to get significantly BEHIND the printer. For example - running OctoLapse, when the head moves out of the way to take a shot, the on-screen nozzle moves at what looks like about 50% of normal printing speed, and then comes back in a hurry because (I think) it figured out that it was way behind. If it were able to move faster, it wouldn't get behind as much.
edit: now that i'm watching a different part, with large areas of flat infill at the bottom, it's doing the same thing. creeping across until it falls far enough behind then rushing to catch up. it'd be fine with me if there was just a setting for travel speed, which I could set to the normal infill speed. Paying attention to the feed rate in the gcode would be a better solution, although this would still not quite sync it as it would probably be too much trouble to take acceleration into account.
I probably spent more time on syncing than any other single part of this plugin. It is really hard. I have tried multiple solutions and this one is (currently) the best compromise I have found.
First issue is the built in OctoPrint GCode visualizer and PrettyGCode uses the File Position to sync the line drawing in the view. This is actually when the line of GCode is read from the file on disk and NOT when it is actually printed.
Second the "rates" set in the GCode actually seldom reflect reality. I am not really sure why it is as far out of whack as it is.
Under the hood I wrote a simple printer simulator that should operate exactly the speed of a real printer (rate=1), but in reality it is faster or slower depending on the GCode. Sometimes much faster/slower.
So on top of that I use a simple routine to adapt the playback rate to try to stay about 2 Lines of GCode behind (see below). I know lines are not ideal, for one thing not all lines are the same length. But I use lines because it simply worked better than using any other metric I could find, including distance and predictive rates based on past performance.
I am sure there is a better solution. Possibly involving PIDs, but so far this works ok.
rate=1.0
//adapt rate to keep up with buffer.
if(linesBehind<1)
rate=0;
if(linesBehind>5)
{
rate=rate*(linesBehind/0.9);
//console.log(["Too Slow ",rate,linesBehind])
}
if(linesBehind<2)
{
rate=rate*(1.0/(linesBehind*5.0));
//console.log(["Too fast ",rate,linesBehind])
}
I'm pretty sure that one of the differences is, like I said, acceleration. From what I've read, it's pretty hard to model exactly what the printer is doing, whether in firmware or hardware, with any degree of accuracy. For a long straight line, the head will eventually move at a speed pretty close to what's in the gcode. However, especially for shorter moves, it won't ever get up to top speed before it has to slow down at the other end of the line. Some firmware is better than others at keeping speed going around corners, but again I can imagine that it's really hard to model this.
Keep up the good work. Lack of real sync aside, it's still a lot better than just watching the old gcode viewer. 
This potentially could change in newer Marlin versions with OctoPrint 1.7.0 and position auto reporting enabled in Marlin.
Hmm. Looks like that is just the x,y,z of the print head sent at a given interval, right? That actually won't help much narrowing down the print position in the gcode stream. Unless I sample so often it would slow things down.
Just file pos works surprisingly well. Most of the "bad sync" issues are really just the way I am handling simulated playback.
I think it is kind of like the auto temperature reporting, it sends the data back to the host software on a specified interval, so you wouldn't necessarily have to poll for it, but could react to receiving the gcode from the printer. However, I think your approach is fine, because this would be an option that requires being enabled and custom compiling firmware which we've seen is not practical for everyone.
Is there a way to adjust the camera angle to a set position through CSS? Also, is there a way to code the camera to follow the nozzle?
Are there any dark themes for this plugin by any chance?
I was able to do this by editing prettygcode.js (pi/oprint/lib/python3.7/site-packages/octoprint_prettygcode/static/js) to change two lines:
1683 scene.background = new THREE.Color(0xd0d0d0) >>> change to (0x1B1B1B)
1899 color: 0x909090, >>> change to 0x2F2F2F,
