get rid of that god forsaken cursor positioning thread and put it in setCursorPos like anyone else would

I can be as excited as I want about 2D subcanvases, but this takes the cake.

• Look into modifying shatter to work on a 3D level. how hard can it be?
  • I have yet to do 3D programming well, so this may be interesting.
• Provide transitioning from 3D to 2D canvases (and vice versa) so users have the ability to 'detach'/'attach' terminals.
  • Walk into a 3D terminal object, clamps to face. Who wouldn't want xenomorph terminals?
• Figure out how mouse and keyboard interactions are going to function within an environment of 3D terminals
• Will the user even have the ability to create multiple 3D/2D terminal objects? How will human interfacing peripherals interact? Maybe some sort of keybinding to switch active terminal windows, where the active terminal window has some sort of outline... maybe?

Guess who needs feedback. This bagel.

See if there is a way to make setAlpha a term API implement, and then make it behave like setTextColor/setBackgroundColor. Of course instead of a color, a number from 0-1 would be put in its place.

Suggested by @Ale32bit

Just a way for people to break free of the 16 color 'palette' system that is in normal terminals.
(You can get away with this anyways, see #7 )
Because this is a Overlay Glasses specific call, and not a redirectable term call, 8 digit hex codes will be supported meaning you can set RGB and A

This may be something out of my control but even in SP the scroll function is just god awful. For things like the shell I'm looking into ways I can just execute scrolling every 1/20th of a second instead of literally every time the event is pulled. That's a fix unrelated to this program, I'm wondering if I may have to restructure the data such that it's easy to perform scrolling sans latency.

SQUIDDDDDDD!

Currently in progress, will have ranges 0.1 to 10, don't really see the use of having anything more than that. If the limit becomes a problem I probably will change it.

Title explains it all, currently both text and bg change when you set alpha

Suggested by @Ale32bit

return the base canvas object with a modified clear function that doesn't remove any shatter related objects.

The glasses have already been shattered, you wouldn't want to obliterate them would you? That's just not nice.

The gist of it is the function doesn't redraw the terminal.
Example, using colors.black:

term.setTextColor(colors.black) --setting to black, pretty typical
term.write("hello") --written in black, also typical
term.setPaletteColor(colors.black, 0xff00ff) --turn black into vibrant yellow. "hello" doesn't change to yellow...
term.write("world") --written in yellow as expected

Of course I do like the idea of having all colors available, but not like this. See #6
This also applies to setAlpha

Just thinking about ways on my end I could face the issue of shatter being unusable in full proper form on Switchcraft because of the claims blocking the right click ability of the keyboard. Here's the layout:

1. It is universally acknowledged that nobody uses scroll lock.
2. Keyboards can be put into the neural interface and then detect keystrokes without the keyboard even having to be right clicked
   Goal: read function that can be toggled with keys.scrollLock

this has been pushed to plethora. I think this calls for an overhaul:

• Add support for 2D object groupings, maybe revive #4 with the modification that shatter.base returns a subcanvas of the master that shatter is on rather than the literal terminal object.
• Subcanvas-ify shatter for compatibility with other programs.