Easier proxying and UI Buttons.

[nrgill28]

Overview:

• All MonoBehaviour components related to proxying in-game components now reside in MappingComponents/
• Editor scripts are in the Editor/ directory
• Scripts that execute in-game are in the Runtime/ directory
• Renamed the 'Generic' level type to 'Sandbox' (Including the namespace for it's mapping components)
• Added a ComponentProxy class that makes it easier to create new component proxies.
• Added a mapping component for making functional in-game UI buttons (PointableButton)
• Added a class that makes getting references to in-game objects much easier (ObjectReferences)

Component Proxy: This is a simple abstract class that enables the code to GetComponentsInChildren() and let the derived class resolve the proxy in it's own class. See the new button class for an example. Additionally, it has an virtual OnExport() method that can be used for one time calculations right before the map is exported (Some proxied components have Editor functions that can be emulated here instead of at run-time)

ObjectReferences: This class will find static fields with the ObjectReference attribute and searches the scene for a GameObject that matches the name filter and the component type. The search is the first thing that happens when a scene is loaded to make sure nothing gets deleted before a reference can be taken. For example:

// Reference to the first GameObject in the scene that has a name containing "Destructobin"
[ObjectReference("Destructobin")]
public static GameObject DestructobinReference;

// Reference to the first SosigSpawner component found in the scene (You can also filter by name here too)
[ObjectReference]
public static SosigSpawner SosigSpawnerReference;

This is very useful when proxying components since we usually need to borrow values from existing game objects or components, so being able to automatically search for these references makes getting those values much easier.

[Nolenz]

You have correctly come to the conclusion that my organization is completely terrible, and I really do appreciate the efforts in trying to piece it into something that isn't quite as idiotic. The only problem with that is it nukes backwards compatibility. If these changes are pushed out, old levels stop working. Monobehaviour FileIDs are generated like this. If you break that mapping by changing a class name or namespace, loading an old scene produces missing components and everything breaks.

If I'd internalized that a bit better when I was puking out classes, maybe I would've spent a bit more time actually organizing things properly. Ah well. Breaking changes like this were the kind of things I was hoping to save for when Anton inevitably breaks the whole mod with the release of the second TNH map.

I'm a big fan of ComponentProxy. I'd planned something similar as I watched the Loader class bloat, it was just a matter of sitting down and porting everything. I'm perfectly happy to merge that in alongside your PointableButton proxy. ObjectReferences, too. That's a cool shortcut, I'm a fan. All that will help clean things up.

[nrgill28]

Yeah I was aware this would break existing maps, they just outright crash the game when loading with these changes. That could be something to look into, not letting the player load a map that isn't compatible just in case.

As for all the other changes, did you want me to open a different PR with just the ComponentProxy, PointableButton and ObjectReference classes in the meantime?

[Nolenz]

Yeah, I'll gladly merge those files, and then I'll get around to porting existing proxies hopefully soon.

[nrgill28]

Moved the other changes to another branch. This PR now has only the desired classes.