With the latest commit we've moved parsing arguments from nut.command.run to nut.command.parse this is more logical in my head, also made it so final strings in arguments don't require quotes surrounding them, the chatbox UI doesn't know this but I fully plan on refreshing the chatbox entirely so this won't be an issue forever.

We also have a decision to make, if we update the default commands to use the new argument system any nut.command.run calls to them will most likely be broken as nut.command.run now wants a table of the final arguments (after assertion changes them in parsing), compared to before where it just wanted a table of strings (the old argument system). I know breaking changes are frowned upon but this is in a rare case if any outside Schema/Plugins use nut.command.run to trigger native commands, and updating them to work would be extremely simple.

Also added nut.type.character type and updated commands reply, setvoicemail, flaggive, & flagtake to use new argument system.

With the latest commit we've switched from the pow2 calc to just iterating over the bits to find the next free bit position when adding types.
(this'll probably fail if we ever hit 32 types (ie 32 bits), possibly cause stack overflow or halt)

Any final argument can be typed without quotes now, not just strings. Chatbox updated to make that and syntax work. (temporary, will overhaul chatbox completely at a later date)
Fixed the help menu to actually display syntax.

Changed all commands in sh_commands.lua to use new the argument system (not yet plugin commands)

Now command arguments list can be a single value instead of table, and also arguments can have multiple types accepted, like in the case of /charunban (we could expand this to more commands later).

With the latest commit we've changed from using bitwise operations for managing types to now shoving types into a table, the implementation for and/or is now a little more convoluted but should still be manage-able. (I didn't like the 32bit limit that comes with operating on bits like that)

New functions:
nut.type.tor(...) accepts vararg of types (and more 'and/or' functions), and spits out a function, this function can be called with a value passed to it to see if it passes any of the type's assertion functions.

nut.type.tand(...) is functionally the same but instead of allowing it to pass any of the type's assertion's it must pass them all.

nut.type.resolve(nut.type.* OR and/or function, value) if a and/or function is provided it will go through all the types that were used to make that function and try to resolve them into their respective type. If a type is provided it will try to resolve for that type. (note: resolve does not do any sort of assertion)

and nut.type.assert(nut.type.* OR and/or function, value) will call and return the function that is provided into it (should be a and/or function) or, pass a nut.type.* into it and it will call and return that type's assertion function.

Assertion as been cleaned up to only implement actual "assertion" and not changing any values, that functionality, for "resolving" any value (most likely a command argument string) into the certain type has been put into the type's table as a new function added with nut.type.addResolve(type, func)

Resolve function's should be like this:
Any value (probably command argument string) gets passed into it, you should then here check to see if you can find a value of the type (i.e a character) that matches the passed argument, then return that character. There is also a return false, FAIL_STRING if you want to pass a fail string to nut.type.resolve's second output (fail string's are used in nut.command.parse to give that feedback to the client when a resolve fails).

Latest commit:

Change all remaining commands to use new argument system.
Change nut.util.findPlayer to use the player type resolve instead. (not needed, but cleans up redundant code, probably)
If a command argument is set to nut.type.optional only it won't show in the syntax and will always count as a success to resolve. (No real point to doing this though, I only used it for the dynamically created 'act' commands so the onRun variable doesn't get fed the old arguments system at any point.)
Resolves have been made a table on the type with unique identifiers per resolve, so you could add have more resolves per type now, they'll be automatically run with nut.type.resolve.

Also fixes some bugs that default commands had, I'm sure there's more.