I'm actually working on a more universal InputScript that will allow for an easier script approach, but in essence, this is what the loop does:
Inside the loop you will notice lines such as these:

if (Input.GetAxisRaw(inputRef.inputButtonName) > 0) {

Input.GetButton(inputRef.inputButtonName)

These are a direct call to the standard Input Manager from Unity. The loop is basically just browsing through every input registered into the Global Editor - Input Options and checking if any of them were triggered.
Originally, these inputs are set by default into the InputManager file provided with the package, and they can be edited here.

As for cInput, if I'm not mistaken you can simply replace every "Input." under ControlsScript.cs with "cInput.", given that cInput also have methods such as GetButton and GetAxisRaw (If it does not have GetAxisRaw, you can change those to GetAxis).

Now, cInput probably has its own system to name a specific button reference so it can detect which button was pressed. In that case, you will probably also have to edit the input references set on the Input Options so it matches the references under cInput.

In other words, if you have something like cInput.GetButton("buttonA"), you have to make sure that "buttonA" is also listed under the Input Options on UFE.

PS: Im not entirely sure how the methods inside cInput are, but you can still follow a similar pattern if you want to change the input class. any reference to the Input class is inside that loop, and all its string references are inside the Input Options.

Humm its very hard to tell. I'm not sure exactly how far you got and if you are using cInput at this point.
I also never used cInput so I don't know how you set its key configurations or if it even uses Unity's Input Manager.
That error seems to come from cInput itself and from the looks of it, seems like you need to setup those buttons in there.
Originally, what UFE does is simply detect the Input being pressed that was originally listed in the Input manger.
In other words, this:

Connects to this:

So in essence, the foreach loop inside ControlsScript.cs is doing something like this:

if (Input.GetButton("P1Button6")){
..
}

Where P1Button6 is a listed Axis on Unity's Input Manager.

Since you changed Input. to cInput., you'll either have to change how these buttons are referenced on cInput or how they are named under UFE Input Options.

Humm I'm sorry I'm not quite following at this point.
Did you add that line in your code? I don't think I've added any direct Input.GetAxisRaw([string]) on ControlsScript.cs.
I've just made a search here and I don't have any string "Horizontal" originally written on ControlsScript either.
Maybe you changed a few things around before?

Okay, thankfully my changeset shows that I must have added that bit of code, and correcting all the instances of GetAxisRaw("Horizontal") to inputRef.inputButtonName got the characters to move correctly.

Only issue I'm dealing with now is that when I press an attack button it says it can't find a key match for the player's horizontal and vertical, " Is it possible you typed it wrong or forgot to setup your defaults after making changes?".

If I resume after the exception, the attack motions properly and resumes fine until another attack button is pressed.

Both axes are in the input config, otherwise i couldn't move the characters around.

Trying to debug it I can follow it until the following code will throw the exception upon completing the foreach initiated around 266:

foreach (InputReferences inputRef in inputReferences) {

I wouldn't trust that debug error hehe. I googled the previous error string (Is it possible you typed it wrong or forgot to setup your defaults after making changes?) and it seems to be a custom error from cInput.

When you set an input as Horizontal Axis or Vertical Axis on Global Editor -> Input Options you are telling the engine to detect those inputs as axis (Input.GetAxisRaw([Input Name]) > 0 and Input.GetAxisRaw([Input Name]) < 0 ) instead of buttons (Input.GetButton([Input Name])).

I got some help from a programmer who is currently working with cInput and he managed to get some neet compatibilities with both cInput and Control Freak (mobile port). I haven't had the chance to check on his development yet, but I think you are heading in the right direction as well.

With any luck I might be able to incorporate those updates into the next version from UFE.