rayzer

Yes, that's a good point. I haven't yet accounted for all the patches that aren't in the ```Patches.Events``` namespace, which should all be patched statically. (If that's what you meant)

I'm leaning away from attributes and more towards one or two interfaces to specify event patches, with the example patch/handler relationship given above. Still gonna wait for approval before finishing...

I lied, I like attributes more now. Probably best we don't have to mess with literally every existing transpiler, plus it's technically more efficient anyway.

Most impl. is done but there are some events that have `Exiled.Events` functionality embedded in the patches. I'm gonna try and find them and seperate them into handlers instead.

Look at it this way: Would you rather have all 450 exiled servers having the same broken patch when only 50 of them even use the event? I think it's...

Mostly done and tested, but still want feedback one thing before I mark ready: Currently I have the `+` ops for both event wrapper classes so all plugins don't have...

Just gonna open it as is, we can always obsolete stuff later if we need to

Probably should be Do Not Merge for exiled 6

It might; events should all be subscribed the same way and in the same order, however the time it takes to enable all plugins is bound to be much larger,...

Wouldn't ensuring a patch is run be done by a plugin tho?