[Released] cInput 2 - Unitys custom inputmanager got improved !

Okay, it seems the problem was that I was using the Keys.Xbox1* entries for everything... I took the 1 out of all of them and now it seems to be working perfectly for both 360 and Xbox One controllers. Does that make sense?

 

Yes, that makes sense.

The Keys class should return different values for the D-Pad between Xbox One and Xbox 360 controllers. That would be why it was working for one, but not for the other.

But, since the Keys.Xbox[Button] (without any number immediately following "Xbox") checks any and all connected controllers and can't distinguish between 360 or One controllers when checking all connected controllers, since there may be one or more of both types of controllers connected simultaneously, it doesn't even try and just returns all values as if they were Xbox 360 gamepads.

So that's why it makes sense and that's why it's working after you made that change.

Maybe it's time for me to run more tests and see if 360 and One controllers match up, and stop supporting versions of Windows 10 before the Anniversary Update where the button/axis mappings didn't match up.

 

Hi,

For me binding slash is not working, it calls the slash binding when I press semicolon. I use a non-US keyboard.

Any way to get this working?

 

What is bound when you press the slash using the cInput GUI menu?

There isn't much we can do to support non-US keyboards since Unity itself doesn't support them very well. cInput uses Unity's keyboard mappings. So the trick is to figure out what Unity thinks the slash is on your keyboard and use that binding instead.

But that's one of the nice things about having the controls be rebindable during gameplay. If some default mapping doesn't work, you can just pop open the menu and change it.

 

Alright, I think you used something different than unity keycodes, they have the same problem using them directlly. The problem is not yours is from unity, but thank you anyway for the answer.

 

@Deozaan I have imported System.Windows.Forms into my project and want to be able to control Cursor.Position using cInput, but the stick vertical and horizontal outputs are floats, not ints, do you have any tips on allowing me to do this?

 

I'm not sure I understand the problem entirely.

If you're asking how to move the mouse cursor with cInput, then cInput doesn't work that way. cInput only reads values from hardware inputs such as mice, keyboards, gamepads, steering wheels, etc. It doesn't set the values or set the position of the mouse cursor.

But if all you need is for cInput to give you ints instead of floats you can cast the floats to ints or round them to an int.

Code (csharp):

1. float myFloat;
2.  
3. void Update() {
4.     myFloat = cInput.GetAxis("Horizontal");
5.     // I believe this truncates past the decimal, so if myFloat is 0.7f, castToInt will be 0
6.     int castToInt = (int)myFloat;
7.     // this rounds to the nearest integer, so if myFloat is 0.7f, roundToInt will be 1
8.     int roundToInt = Mathf.RoundToInt(myFloat);
9. }

You could then use these cast/rounded ints where you need an int. You can also cast/round in-place, for example:

Code (csharp):

1. int myInt = (int)cInput.GetAxis("Horizontal");
2. int myRoundedInt = Mathf.RoundToInt(cInput.GetAxis("Horizontal"));

 

I am experiencing this issue with two xbox 360 controllers, using cInput 2.9 and the latest Unity beta. If I push RT or LT on both gamepads at the same time it somewhat works.

 

Sadly, this is a problem with Unity itself. Unity has had a longstanding bug (or series of bugs) with Xbox controllers. This affects more than just cInput. And since cInput is just a wrapper around Unity's Input Manager, it unfortunately provides no workaround for this issue.

See: https://forum.unity3d.com/threads/still-xbox-360-joypads-bug-on-windows-unbelievable.296519/
And: http://www.gallantgames.com/posts/27/details-on-the-xbox-360-controller-bug-in-unity

For more details about the Xbox controller bug(s).

 

Ok. Is there any asset on the assetstore which is directly supported by cInput and circumvents the issue?

 

No, not that I'm aware of. Sorry.

Rewired supposedly circumvents the issue by accessing DirectInput or XInput directly as needed instead of relying on Unity to do it correctly. But I've never used it and obviously don't provide support for it, so your mileage may vary.

 

Hi,deozaan!
Does your plugin support to set G27/G29 wheel,and how to do it,Is there a example?
And I have a question with unity input,I used float Acc = Input.GetAxis("Acc"); in update
function.First I got 1 in the debug console,but When I clicked clear or waited for about 20 seconds then I got 0！！！What is the problem?
The Setting is Type：Joystick
Axis：3rd axis

Best Regards

 

Hi yumianhuli1,

First of all, I am so sorry for not having responded earlier. For some reason I was not notified of your post.

Yes, cInput should support G27 and G29 steering wheels, just like any other kind of input device. The basic rule of thumb is this: If Unity's built-in Input Manager supports it, then cInput should too. If you want to test out a device to make sure it is detected, you can try our WebGL demo. You can even download a trial "Dev Edition" of cInput which can be found on our Itch.io store page to make sure it will integrate into your project.

I'm not sure I understand your question about "Acc" but it looks like you're using Unity's built-in Input Manager instead of cInput in the example code you wrote. We don't provide support for Unity, since we have no control over what the folks at Unity do with their engine.

If you have further questions about or need help with cInput, we're happy to help you out. Under normal circumstances we are really good at responding within about 24-48 hours, but if for some reason we don't respond in a timely manner, try contacting us through our contact form or ping me on my personal Twitter account to see if I received your inquiry.

 

Hi folks,

An update to cInput has been submitted to the Asset Store. If you bought cInput from the Asset Store then the update should be available in a few days. If you bought cInput on our website, the update should be available immediately.

cInput changelog:

v2.9.1

• Fixed saving individual axis sensitivity, gravity, and deadzone settings. (Thanks Kailan)
• Better handle edge cases when trying to use GetText for invalid inputs. (Thanks Guray)
  
• Fixed some console warnings in recent versions of Unity.
  
• No longer support versions of Unity older than 5.6.4.

 

Hey, I found a bug in cInput. Sorry, I didn't read through this whole thread so maybe it's already been reported.

Anyway, if you define an axis with a low sensitivity and gravity (technically this still occurs with high sensitivity and gravity, but it's easier to see with low) you can create some odd behavior. When you press and hold one of the keys in the axis, then a bit later press and hold the opposite key for a little while, then release both keys, the axis value will stay frozen at that value for a while, then begins returning to zero like expected.

To reproduce:

Code (csharp):

1.  
2. public class cInputTest : MonoBehaviour
3. {
4.     private float value;
5.    
6.     private void Awake()
7.     {
8.         // Initialize cInput Bindings.
9.         cInput.SetKey("Test+", Keys.UpArrow);
10.         cInput.SetKey("Test-", Keys.DownArrow);
11.         cInput.SetAxis("Test", "Test-", "Test+", .01f, .01f);
12.     }
13.  
14.     private void Update()
15.     {
16.         // Get value every frame.
17.         value = cInput.GetAxis("Test");
18.     }
19.  
20.     private void OnGUI()
21.     {
22.         // Display value to screen for easy debugging.
23.         GUI.Label(new Rect(10, 10, 100, 20), value.ToString());
24.     }
25. }
26.  

Enter play mode and press and hold the up arrow for 3 seconds. Then, while still holding up arrow, press and hold the down arrow for 3 seconds. While holding both buttons, the value of the axis freezes (which I suppose is reasonable, though my expectation would be that the value would be zero). However, after releasing both buttons simultaneously, the value remains frozen at the previous value (for 3 seconds), then begins decreasing as expected.

This issue seems to be caused by the fact that the full "Test" axis is composed of two individual positive and negative axes. When both of these are >0 and the buttons are not held, both are decreasing at the same rate, therefore in _CheckInputs() when doing _getAxisArray[n] = _getAxis[pos] - _getAxis[neg];, the value of the composed axis remains constant, because the difference between the positive and negative axes is remaining constant.

For my particular use case, I was able to "resolve" the bug by setting the value of the axis and the two component axes to 0 if the raw value of both component axes is 1. Essentially this just completely erases any existing value on that axis if conflicting inputs are received. This solution may not be viable in the general case however.

Here is my "fix", within the _CheckInput method (basically at the very end):

Previous code:

Code (csharp):

1. _getAxisArray[n] = _getAxis[pos] - _getAxis[neg];
2. _getAxisArrayRaw[n] = _getAxisRaw[pos] - _getAxisRaw[neg];

New code:

Code (csharp):

1. if (_getAxisRaw[pos] == 1 && _getAxisRaw[neg] == 1)
2. {
3.     _getAxisArray[n] = 0;
4.     _getAxis[pos] = 0;
5.     _getAxis[neg] = 0;
6. }
7. else
8. {
9.     _getAxisArray[n] = _getAxis[pos] - _getAxis[neg];
10. }
11.  
12. _getAxisArrayRaw[n] = _getAxisRaw[pos] - _getAxisRaw[neg];

A more optimal solution would be to calculate the raw composite axis value, then apply the sensitivity/gravity to that to get the final result, rather than computing sensitivity/gravity on the individual components of the axis, then composing the result of that.

I can email/pm you a fresh unity project that reproduces the issue if you wish.

 

First of all, sorry for the delay. I was out for the holidays and all that.

Thank you for the very thorough bug report. As well as a working solution. I have verified that the bug exists as stated in the latest version of cInput. We'll have it fixed in the next update.

Thank you for putting the time and effort into your report!

 

Downloaded, and currently testing cInput, and it seems great so far. I've got one question... for now!

Rather than launching the remap utility by pressing escape, as in the example scene, would it be possible to run it by clicking a button on my existing menu screen?

Thanks in advance,

John.

 

Yes, that's possible. You can fully customize the UI and all the necessary functions are exposed to you to be able to call them from anywhere in your code that makes sense.

 

That's great. Thanks for the quick reply. I don't want to sound like a bigger noob than I probably, (appear to be) am, but I couldn't see how in the documentation, so any help you could offer would be greatly appreciated.

By the way, I also used the contact me option on your website to ask the same question, as I wasn't sure how active this forum is...

Thanks again,

John.

 

If you're using the (legacy) GUI provided with cInput, called cGUI, then you can just call cGUI.ToggleGUI() to toggle the GUI open or closed.

If you're building your own UI then you'd have to build your own code to show or hide the UI. More details about writing your own UI can be found in the cInput Manual here.

P.S. I hope you don't mind if I "ignore" your contact form support request since I helped you out here.

 

That's brilliant, thanks. I'll have a look tomorrow, as I'm too tired to see straight now!

ignoring the contact form request is fine as well.

 

OK, I've had another look, and am now starting to get my head around this. Haven't changed the menu look yet, as I actually like it the way it is!

I am seriously impressed with this, and will say so in the asset store review section. Thanks a lot, for a great asset, and your swift support.

 

Thanks! I'm glad to hear it.

 

Hi, I have a couple of questions.
Currently I am building my own UGUI menu to allow input selection (via a wrapper that handles action creation for axes, and a unity editor GUI for assigning the defaults similarly to unity's input system).

1) Is it possible to get cInput to scan but not directly assign the key, just return (possibly via event?) the pressed key (what I would like to do it have duplicates allowed but give a warning if a duplicate key is assigned, and give a prompt to allow the use to cancel [return to previous key] or continue [have both actions assigned to the same key])

2) Is is possible to Reset a specific action to it's default, rather than resetting the entire set? (I'd like a reset button that I can put on each row of the input selection to reset the whole action/axis to default)

 

Another question, aswell:

3) Is it possible to make the string based dictionaries in cInput (the ones that get the index from the actions/axes and keys from keycode etc.) case-insensitive, possibly also ignoring spaces?

For case-insensitivity alone it can be done pretty simply:
var comparer = StringComparer.OrdinalIgnoreCase;
var caseInsensitiveDictionary = new Dictionary<string, int>(comparer);

This would be really helpful as it would also make all of the functions work with the logical string inputs ("w" is the same as "W" and "leftARROW" is the same as "LeftArrow", spaces would allow more consistency as well, as "Mouse Left" could follow the same rules and be "MouseLeft" without breaking backwards compatibility)

 

The short answer is that no, cInput doesn't do any of these things.

The longer answer follows:

We're coming up on cInput's 6th anniversary since its release in 2012, and to the best of my knowledge, nobody has requested these features yet. The first two features especially seem like something we'd have been happy to implement into cInput in the past. However, Unity is planning on releasing a new input system sometime in the next few months with the launch of Unity 2018.2. We're unsure of the future of cInput, since it's a real possibility that the new input system will fix all the flaws with Unity's Input Manager that made tools like cInput necessary. We'll definitely provide support and bug fixes in the meantime, but until we have a better idea of how the new input system is going to work, and whether or not cInput will be necessary going forward, we're hesitant to spend more resources developing new features for it. So I can't make any promises at this time that the things you've requested will make it into a future release.

That said, if you have cInput Pro, which provides access to the source code, then you can of course customize it to do anything you want.

 

Thank you for your response.

I do have cInput pro and probably can implement these features, as you say. I fully understand your reasoning and I sincerely hope that their new system does fix all of the problems that cause the necessity for plugins such as yours. I'm not convinced the system will be brilliant, and I'm certain there will be issues, especially early on, so I will probably continue to use cInput for a while.

The reason I posted here rather than implementing them myself straight away is simply because you obviously have a greater knowledge of how your code works and other people may benefit.

If I do get to implementing these features, would you like me to send you (via DM or similar) the changes I have made?

 

Thank you very much for your understanding. We are cautiously optimistic (for the sake of Unity users) that the new input system coming "soon" to Unity will indeed make cInput unnecessary. Time will tell.

Yes, you have a point about my familiarity with the code. Maybe this will point you in the right direction:

(1) For getting cInput to trigger an event instead of automatically assigning or rejecting a duplicate, one (or more) of the following methods should be relevant:

• _InputScans() - This is where the code waits for the player to press some input and handles a bunch of logic about whether or not this key is valid and can be assigned, is forbidden and can't be used, or is a modifier, etc.
• _CheckDuplicates() - This is where, if duplicates are not allowed, cInput will search through all previously assigned keys to see if any of them match a newly assigned key and if so, un-assign those keys. This is called from _InputScans().
• _CheckDuplicateStrings() - This does basically the same thing as _CheckDuplicates() but it searches various input types that use strings (e.g., axes) instead of KeyCodes.

(2) For being able to reset individual keys instead of having on monolithic method which resets all inputs at once, check out _ResetInputs() to see an example of how cInput does it (to all inputs) in a loop.

(3) I'm not sure I fully understand all the various places you want case-insensitivity and ignoring whitespace to occur. But from what I understand of your request, I suspect making this change will require many little changes interspersed throughout the code; it will require you to make changes everywhere cInput compares strings. Basically all of the _SetKey(), _ChangeKey(), and _GetKey() (and Button/Axis) variants are good places to look, and maybe other places as well. The reason why this may not be as simple as your suggested example is because cInput converts all strings into hashes and uses those internally in the lookup dictionaries, since doing string comparisons is relatively slow compared to hash (integer) comparisons. But it may be as "simple" as doing a search for all occurrences of GetHashCode() and making sure the string is converted to lower case before getting/comparing its hash code.

I hope this helps you in your efforts if you decide to implement these features yourself.

If you do, we would be glad for you to submit your changes to us for possible inclusion in a future update. You can initiate a more private conversation with us (to discuss source code, internals, etc.) from our contact form here: http://cmonkeys.com/contact-us/

Thanks.

 

Wow, thank you for your detailed answer!

That is very helpful.
As far as #3, I have found there are a number of places that use hash codes and (i think) i have converted them all (via .ToLowerInvariant). Regarding the comparison speed: I assumed that c# would be doing hash code comparison for == on strings anyway, unless using something like string.Compare()/CompareTo() which give the order and use culture variance etc., so it is intreresting to find that it is slower

 

You could be right and I could be wrong. I was told by someone who seemed more knowledgeable than myself on the subject that using hash codes would lead to greater performance. But maybe I misunderstood the reasons why. For example, it may be that C# compares hash codes on strings by default, but converting a string to a hash code has a performance cost which can be avoided if you simply pass in the hash code yourself instead of the string(s) to be converted to hash codes.

So cInput allows you to pass in strings for backwards compatibility and ease of use, but it also allows you to pass in hash codes in some cases for that extra performance.

 

Hi,

I really like the cInput System. Paid for the ProVerson. Very simple to use. But now I encountered a strange problem and I don`t find the cause for this behavior:

Problem: When I hit "DEFAULTS" in the gui, it loads up the wrong Default Key mapping (but only in the "built" Version).
In the Editor the Default key mapping is correct.

I uploaded 3 Pics here:

https://imgur.com/a/S1zYZEZ

Pic1) This is the code I use to set up the Default Keys (mapped them to a gamepad via code)
Pic2) This keys are loaded when I hit "DEFAULTS" in the Unity editor - works correct. Keys are mapped to the coded lines -> gamepad.
Pic3) But when I start a "built" version of it, and I hit Defaults, it loads up the wrong keys. (now mapped to Arrows, not gamepad anymore)

Can you help me out of this?

PS:
cInput.ResetInputs();
cInput.Clear();

did not help?!

 

If using cInput.Clear() in the build didn't help then that makes me think perhaps you have another script or scene that is setting those as the default values that is running in your build but not in the editor.

To be absolutely sure, you can manually delete the cInput values from PlayerPrefs using PlayerPrefs.DeleteAll() (use with caution as this will, of course, remove anything else you've saved to PlayerPrefs for your game!) or you can go into the appropriate location for your OS and delete anything in your PlayerPrefs with "cInput" at the beginning. Then run your new build and see what the defaults are when you reset the inputs.

Since you have cInput Pro you can also do other things to debug, such as add a debug log message to cInput._SetKey() and see every line of every script that is calling SetKey().

 

Hi, I'm trying to follow the readme to setup the InputManager Asset, but there is no cInput item in the Project Settings menu.

Additionally, this warning pops up on the console :

There are menu items registered under Edit/Project Settings: cInput/Setup InputManager Asset
Consider using [SettingsProvider] attribute to register in the Unified Settings Window.

UnityEditor.EditorApplication:Internal_CallUpdateFunctions()

I'm using Unity version 2019.2.2f1

Any help on this would be appreciated!

 

Hi there!

That script hasn't yet been updated to handle the new unified settings window, but the option is still there where it says it should be. It's just in a different "Project Settings" menu.

 

Oh man, how did I not see that lol. Thanks!

 

I have a question about the cInput in-game menu, can it be navigated using a controller?
At the moment it seems to be mouse only.

Im using it with Universal Fighting Engine 2 if that is of any help.

 

No, the built-in menu doesn't support gamepad navigation by default. But all the necessary variables and methods are publicly exposed through cInput to allow you to add this if you want to.

The included menu is meant to be a quick, dirty, and temporary menu for development only. It uses the legacy IMGUI rather than uGUI. It's recommended to build your own custom keybind remapping menu that fits the needs and style of your game with uGUI or whatever UI system you prefer.

 

Hey, i am trying to create Options for my game to change the input, the problem is, how do i change a key that has a negative and positive value? so i have vertical axis and i want to create an option that allow me to make "W" as positive "Vertical" and "S" as negative "Vertical"

Any help? it seems cInput.ChangeKey doesn't allow me to do this kind of mapping, any help?

 

For this you would use a virtual axis.

Code (CSharp):

1. // set up the default keys to use for the "Vertical" axis
2. cInput.SetKey("Up", Keys.W);
3. cInput.SetKey("Down", Keys.S);
4. // create the axis with the above keys
5. cInput.SetAxis("Vertical", "Down", "Up");

And if you want to allow the player to customize which keys are used for the up and down inputs, you would then use ChangeKey() as expected.

Code (CSharp):

1. cInput.ChangeKey("Up"); // changes the key(s) used for the Up (positive Vertical)
2. cInput.ChangeKey("Down"); // changes the key(s) used for the Down (negative Vertical)

I refer you to the cInput manual for more specific details on how to use the ChangeKey() method in your UIs.

 

Thank you so much for the help!

Great asset, life saver!

 

Don't know if this problem has come up before, but I can rebind my W (forward) and S (backwards) keys to anything else (say, I and K) in my standard FPSController in the Unity Editor. The first problem is that they are reversed and I don't know why. Second, and more importantly, the rebinding is ignored in the project build (even though the change seems to be registered in the PlayerPrefs) and it reverts back to W and S. Any help would be appreciated. Thanks.

 

For the keys being reversed, it sounds like maybe you're using a virtual axis and unintentionally setting AxisInverted to the opposite of what you want.

For the rebinding being ignored, it sounds like maybe the bindings are being reloaded or reset back to their defaults.

It's hard to know for sure without more information. Seeing some relevant code snippets would probably help. Knowing which version of Unity you're experiencing these issues on might also be useful. It would be most helpful if you could provide a reproduction example project that I could use to investigate what might be causing the issues.

 

Thanks for the reply. I’m using Unity 2019.1.4 on Windows 10 with a standard keyboard. Basically, since I just wanted to test things out, I used your demo scene and GUI interface and added my own FPSController. In the FirstPersonController.cs script I added an OnEnable function:

Code (CSharp):

1.         private void OnEnable()
2.         {
3.             cInput.SetKey("Up", "W", Keys.UpArrow);
4.             cInput.SetKey("Down", "S", Keys.DownArrow);
5.             cInput.SetKey("Left", "A", Keys.LeftArrow);
6.             cInput.SetKey("Right", "D", Keys.RightArrow);
7.             cInput.SetAxis("Vertical", "Up", "Down");
8.             cInput.SetAxis("Horizontal", "Left", "Right");
9.         }

I also changed the GetInput function like so (now it should get cInput info on both horizontal and vertical axes):

Code (CSharp):

1.             // Read input
2.          //   float horizontal = CrossPlatformInputManager.GetAxis("Horizontal");
3.         //    float vertical = CrossPlatformInputManager.GetAxis("Vertical");
4.             float vertical = cInput.GetAxis("Vertical");
5.             float horizontal = cInput.GetAxis("Horizontal");
6.             bool waswalking = m_IsWalking;
7.  

I was wrong in a couple of respects in my earlier post. Both in the Unity Editor and in a project build, a change in binding is not reflected in the FPSController behaviour until I exit and then reenter the game. Only then is the change made. So PlayerPrefs are working as expected, but I’m not getting the current binding change to the FPController. I haven’t found a solution yet. Also, the reversed forward and backward directions is still there.

 

Thank you for your more detailed response.

SetAxis expects the negative value to be first, and in Unity, up is the positive Y axis. So just swap the order of "Up" and "Down" and you should be good.

Code (csharp):

1. cInput.SetAxis("Vertical", "Down", "Up");

That said, I am embarrassed to say that I see we also have it backwards in our example code. Because we never actually use the "Vertical" axis in our little demo that's something we didn't catch. I'm sorry our example demo led you astray. (Note that the documentation is correct, even if the unused code in our example scene is not.)

As for the changed inputs not being reflected until after restarting the game, I'm still unable to see why that would be happening. I imported cInput (Pro) into a new project in Unity 2019.1.4f1 and I added a new object to the demo scene which has the same code as you have in its OnEnable method, but the input changes are still immediately reflected in the game when I open the GUI and make changes.

This leads me to believe that the problem lies somewhere in your FPSController script or other code. If so, I won't be able to troubleshoot that with you further without seeing exactly what the code is doing. One way to know for sure whether or not the problem lies with cInput vs. your code is to try the unmodified demo code and see if it works properly for you. If you still have problems with the unmodified code then we'll know the problem is with cInput and I'll do what I can to get it fixed for you.

 

Thanks again. The tip on reversing the 'up' and 'down' inputs is noted. (I was thinking along the same lines.) As for the other problem, I started a new project, added my FPSController with the same code to your demo scene as before, moved cGUI, CInput, cInputGUI and cKeys files to a Plugin folder, and it worked fine! Maybe it was the fact that I moved those files to the Plugin folder? I didn't seem to need to do that on my first attempt. Maybe because I started with your basic edition then upgraded to Pro? Anyway, now I'll transcribe your GUI code to a Canvas UI. That might be something you could think about doing in any future releases.

Thanks for all your help. It's definitely a handy little asset!

 

I'm glad you got it working. I'm honestly not sure if moving the files to the Plugin folder is what solved it, but I'll keep it in mind if we get further reports of things not working as they should.

Thanks for the suggestion about using uGUI in a future release. It's something we will probably do, eventually. But because we expose everything needed to create your own UI for input rebinding, and to really reiterate the point that the included GUI is meant for prototyping and isn't intended to be used for the final UI, we haven't been in too much of a rush to do that.

 

https://i.imgur.com/lxerGuQ.png
I made the manager, it wiped input manager settings, i readded them, made some controls use cInput, it throws errors.
Anyone knows? I dont rly use this forum, so if u know something, mind sending it to iruaxys@gmail.com?

 

It looks like you're still trying to use the Input Manager to create and define your inputs. The purpose of cInput is to replace the Input Manager. After you perform the initial setup, you should never have to touch the Input Manager again. At least not in relation to cInput.

Please read the included user manual to get a better idea of how to use cInput.

Alternatively, there are some instructional videos that, while a bit dated, give generally accurate information on actually using cInput in your project.

 

https://i.imgur.com/SLn3y7E.png i copy/pasted the demo script, first i set the keys, then the axis using previously set keys. it still throws the errors.. in video there is no mention of such errors.

 

It looks like your script is properly setting up the keys and axes. But your screenshot doesn't show the lines of code that are generating the errors, so I am left to guess why you might be getting errors. Here are my guesses based on what's in your screenshot:

1. It's possible that your script that creates the keys and axes ("actions" in cInput terminology) is not being run before the code that tries to access them. It's important that your setup script runs before any other script that tries to access inputs through cInput.
2. Maybe you did set them up correctly and in the correct order, but even so, you may be trying to access them incorrectly. You have not shown all the relevant lines of code pertaining to the errors in your screenshot. It looks like you're trying to access the axes as keys, but they are not the same thing. You need to use GetAxis() for axes and GetKey() for keys.

In the future, please just attach and embed photos to your post instead of linking to an external image hosting site. That will make it easier to see and it ensures that the images don't disappear unintentionally.

You can also include relevant code snippets within code brackets to make it easy to see what's going on with your scripts.