Have you ever, mid-print realised that you should have sliced the object differently? Maybe you do not need that much infill of would be better off with a different wall thickness. Wouldn't it be cool if you could re-slice the currently printing object and tell the octoprint to replace the current job with the new one. It should be possible on the next z-change, finding the matching layer height in the new file.
Obviously you would have to make sure that the new gcode still has the same support structures but there is a lot of slight changes where that wouldn't be a problem. You could, for example, change only the outer wall printing speed while not slowing down the rest of the print. I've certainly often been in a situation where I would like to re-slice the object mid-print. For me, this would be one of the most powerful features of octoprint.
What do you think?
It sounds like a good idea but seems like there would be a lot of moving parts involved. It also wouldn’t work if the replacement had a different layer height (especially if they don’t divide evenly, e.g. 0.2 → 0.3) because there would be more/less total layers. It would be a good idea for a plugin (unfortunately far out of my reach 
).
To me, it definitelly sounds doable. Even a different layer height can be fixed. You could define a maximal layer thickness error and then wait for the best layer to make the switch. Maybe you get a slight overextrusion on a single layer but it's a small price to pay for saving a print you would othervise have to possibly abort.
Next would be a Cura plugin that would, when there is a octoprint job active automatically change to buton from print with octoprint to modify the octoprint job.
It would be extremely difficult to make it bullet proof, not not too bad to make a working version that could be used by someone who understands the software. Layer change detection can be tricky, but to make it easier you could add gcode on layer change to define the start of a layer, count the occurance to get the exact layer change point, and switch files then. Not sure how the file could be switched, but i bet it could be done. If the new file isnt sliced properly it will fail, but that would be user error 
This is why the small trashcan next to my printer has lots of thin parts in it. I just abort, re-slice and start over. It's better than wasting plastic to see if the finished part is happy and then tossing it.
As they say though in the tailoring industry: "measure twice, cut once". You should get to the point where you're checking the settings twice before generating the gcode.
And yet, I've considered things like this (something that could in real-time completely change the stream of gcode with tweaks of all sorts). I actually wrote some preprocessing scripts in Go which would do some interesting things when relative extrusion came out in Cura as a new feature. I also did some work to repeat a layer in dry mode (no extrusion) so that the hotend would help to "iron out" any problems in a previous layer. For my printer, this was a typical problem for the first floating layer after the raft was finished. I've just done many other things to try to minimize that problem so these work-arounds are less necessary for me now.
Also I found out that the preview of the sliced model and playback of an simulated print in your slicer helps alot.
Cura does quite good a job, but Simplify3D got the best gcode preview and playback in my opinion.
i can do that while printing from sd card. but not always work as i wanted. usually z crash down to print little bit. didnt care parameters because not always i needed.