UI:
	Viewport 		- Gaze Selection
		Performed by the user focussing their gaze at an <a-entity> for x time. x is currently set to 1 sec

	Left Control Stick 	- Nothing currently. If movement of camera is desired, it will be used for that

	Left Trigger		- Nothing currently. Planned to use to "Confirm" Auth_Chain is complete

	Left Grip		- Nothing. I do not plan to use this button (Maybe have a menu pop-up?)
	Right Grip		- Nothing. I do not plan to use this button (Maybe have a menu pop-up?)

	X Button		- Currently clears debug_console. 
					Planned to undo one entry in Auth_Chain (and undo selection like rotation)
					Command structure (review CPSC501)

	Y Button		- Currently performs Click Select[Y]

	Right Control Stick	- Used for Rotation if Rotation Select is chosen. Press down to change axis
					If Position and Scaling Selections are added, it will be used for that as well

	Right Trigger		- Used to choose an object for "special select" (RotationSelect, PositionSelect, ScalarSelect)

	A Button		- Used for ClickSelect[A]. If trigger+A is pressed, RotationSelect is initiated until trigger is released

	B Button		- Used for ClickSelect[B].
					Planned if time: If trigger+B is pressed, ScalarSelect is initiated until trigger is released

Selection types and keybinds:
	GazeSelection - No keybind
	ClickSelect[A, B] - A, B
	RotationSelect - Right Trigger + A
	Unimplemented:
		PositionSelect - Right Trigger
		ScalarSelect - Right Trigger + B


Design Considerations:
	If an <a-entity> is nested within another <a-entity> I plan to design a function that passes all classes and auth_element neccesities to
		the child. This way if the child is selected, the Auth Chain will count it as selecting the parent instead of the child. 
		Pros: allows complex object to be created while still counting as one entity. Selection events would need to be sent to the 
			parent to be emitted, and not be emitted by the child itself. I would have to check if parents exist and are not sceneEl
		Cons: This means that the children will inherit all rotation aspects of the parent, and cannot be selected independently.
			It would not be possible to rotate a full clock, then rotate only one of its hands. That would require two seperate a-entity
			Which sacrifices positional inheritance. There are ways around this problem if I have time to implement. Low priority
	Rotation is currently conducted only by a central axis. If there was to be a door that should be rotated on a hinge, that hinge
	would need to be defined as a parent a-entity
	
	What if all auth_elements have no geometry/visible components and are just the classes, with all children entities being what is selectable?
	I think that's what I'm doing now
	An Auth Element will have a position and rotational value. 
	This will allow an axis to be defined besides the default one through the center for the child geometry if desired