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

Yeah, the issue can only be replicated by me when it's called "Cancel", if I name it anything else it works. It's no big deal for me to have it called something else, but perhaps valuable information should anyone else run into the same problem in the future.

 

Hi there! I seem to have a problem where once I set SetKey once, and then again later on with a different key. It doesn't actually update until I restart the scene.
I actually wish to avoid using cInput.ChangeKey for several reasons, so in what way could I manually refresh/update cInput to actually respond to the new keys?

Thanks.

 

If you want to change keys then you should be using ChangeKey. SetKey is for initializing cInput with the default inputs.

Can you share your reasons for not using ChangeKey please ? Perhaps it's more clear why you want to avoid it and we can get you a proper solution then.

In the mean time you could use cInput.Clear() before you use SetKey again. This erases all keys from PlayerPrefs. This also means you need to re-set all the keys again ofcourse.

I hope this helps...

 

The reason for it is quite simple. ChangeKey didn't actually work for me. I ran it in a Update loop and it didn't catch any new key being set unfortunately :/...

I'm currently doing extremely simple testing with it, by just trying to re-set a specific key (I need to be able to do it by name).

First I set it in the start function with:

Code (csharp):

1.  
2. cInput.SetKey("Move_Sprint_Key_test", Keys.LeftShift);
3.  

Then in the update:

Code (csharp):

1.  
2.         if (IsSelected)
3.         {
4.            
5.             cInput.ChangeKey("Move_Sprint_Key_test");
6.  
7.             Key.Text = cInput.GetText("Move_Sprint_Key_test");
8.             if (Key.Text != "[Press Key]")
9.             {
10.                 IsSelected = false;
11.             }
12.  
13.         }
14.  

And then when I try to set a key, it will automatically set it to ". . ." (before I even have the time to tap a key) and then obviously the key has changed, which makes the selection stop.

 

I think the problem is found here:

Code (csharp):

1.  
2.             Key.Text = cInput.GetText("Move_Sprint_Key_test");
3.             if (Key.Text != "[Press Key]")
4.             {
5.                 IsSelected = false;
6.             }
7.  

When should Key.Text ever be "[Press Key]"? It should be "LeftShift" or ". . ." but never should it be "[Press Key]"

This means that the if statement will always return true, which will make IsSelected false every frame immediately after it is true.

 

No, because I actually set it to [Press Key] before when you select that in the GUI. So it's correct.

What happens is, I set it to [Press Key], then I run the script, it changes it to "..." and then obviously the statement is true.

 

My point still stands. Compare to ". . ." instead of "[Press Key]" and it will work fine. The problem is with your code, not cInput.

If you insist on comparing to "[Press Key]" then edit cInput.cs on about line 1233 and change this:

Code (csharp):

1. name = ". . .";

to this:

Code (csharp):

1. name = "[Press Key]";

and then you should get the results you want.

EDIT: Alternatively, I think you could modify your if statement to something like this:

Code (csharp):

1. if (Key.Text != "[Press Key]"  Key.Text != ". . .") {
2.     IsSelected = false;
3. }

 

That actually didn't help at all . Neither of them solved the problem.

 

It might have to do with the fact that you're calling ChangeKey each frame in the Update function. It might work better if you call ChangeKey just the once in your OnClick2 function (that you shared with me privately in a pastebin).

I think what is happening is that the actual input detection is happening before or after the Update function of your script, which means that when your script runs it's Update function, it calls ChangeKey again which just resets it back to ". . ." all over again.

 

That works perfectly ! I was confused as the ChangeKey function was set in the OnGUI function in the Demo afaik, so I figured it would be called multiple times .

 

It is called in the OnGUI function, but only on the single frame that the mouse button has been released (Input.GetMouseButtonUp) after clicking a GUI button.

 

Hi, just a quick question regarding joystick names- I know that cInput sets up its joysticks according to whichever ones it finds first. My question is does it store them in the same order that unity stores Input.GetJoystickNames() ?

As in, will cInput's 'Joystick0' be the same joystick that unity recognizes as Input.GetJoystickNames[0]?
I would like the user to know which joystick they are selecting by name.

thanks!

 

Hi there,

I've got a question regarding rendering the built-in menu. When I try to render the menu in a new scene, the skin does not render correctly (Basically the menu does not have a bg and looks very different from the one provided in the demo).

Have a look at this screenshot: http://puu.sh/7fYoT.png

I looked at the setup.js file provided in the demo folder and I can't see anything that it is doing different than my code. You can see my code in the screenshot above.

 

I think I saw that Roidz already responded to you in an email, but just in case I'm wrong, I believe the answer is yes. cInput doesn't do anything with the order of joysticks that Unity detects. cInput just uses them as Unity gives them to it.

The alpha on your BGColor is at 0, so the background is transparent. Change it to 1 (or 255, whichever way is fully opaque) and your background will show correctly.

 

You are right! Thank you so much .

 

Some questions. I had purchased the plugin a while back and got around to looking at it recently:

1) Is there any reason Keys is not in a namespace? Keys is a very common name to not namespace.
2) Is there any reason why you use a billion arrays of values when you could just use a simple array of classes?
3) Is there an event for when a keymap changes? I.e. for "Action A" can you subscribe to an event when the keymap changes for that action?

Thanks!

 

Let me preface this by saying I feel my answers aren't very good ones, but they are the most accurate answers I can come up with.

1. There are two reasons as far as I can tell: The first is that at the time I created the Keys class, I didn't know enough about namespaces to realize they'd be useful in this scenario. The second is that to the best of my knowledge, you're the first person in two years who ever suggested that they Keys class should be in its own namespace. Keep in mind that I never said they were good reasons.
2. I can't really speak to the reasoning behind this, as I came onto the cInput 2.x project after Roidz had already done most of the work and thought it was ready for release. He asked me if I'd be willing to test it out for him, and I accepted. I offered a few suggestions on how to improve it and even coded up and sent some of the suggestions already implemented (such as the Keys class). We worked on it together for about another month and released it to the Asset Store almost two years ago. I was a pretty noobish coder back then, and I've learned a lot in the past two years. Mostly it uses many different arrays due to legacy code than due to current programming/coding practices. If I were to write it all up from scratch again, I'd definitely do things differently in that regard. And maybe someday that will happen for a cInput 3.x. But before we think much of cInput 3, we just want to get cInput 2 working as well and bug-free as possible.
3. There is not an event for when a keymap changes. There's no way for a keymap to change unless you specifically tell it to with a call to ChangeKey, so we figured you'd already know when that happened. And if you're the one coding the calls to ChangeKey, we also figured you could just as easily code whatever other functionality you wanted to happen when a keymap changed, too.

I hope this helps answer your questions.

 

Hey there, will cInput work for using positional offset data from a hydra (e.g. 5 cm distance(x) to default position(0,0,0)) as a joystick replacement?
Thanks!

 

Could you explain how to save an AxisInverted toggle? I have used the example in the reference guide to add a GUILayout toggle, which works until the game ends:

Code (csharp):

1. cInput.AxisInverted("Vertical", GUILayout.Toggle(cInput.AxisInverted("Vertical"), "Invert LeftStick"));

I believe I need something like this but it errors with "Array index out of range":

Code (csharp):

1. if(cInput.AxisInverted("Vertical", GUILayout.Toggle(cInput.AxisInverted("Vertical"), "Invert LeftStick"))  Input.GetMouseButtonUp(0)) {
2.             cInput.ChangeKey("Vertical", 2);
3. }

 

I really have no idea since I don't have a Hydra to test it with. You have two options to test it out:

1. See if you can use the Hydra using our webplayer demo
2. We're working on getting a developer's edition of cInput on the Asset Store, but for now you can try out a beta from the "demo" link at the bottom of this page: http://cmonkeys.itch.io/cinput2

I'm not sure I understand your question. The inversion status of an axis should automatically save and load to/from PlayerPrefs. And I really can't tell what you're trying to accomplish with your last code sample. It looks like it uses a similar format to that of a GUI Button, but clicking changes the keybinding for the secondary input of "Vertical"? I don't see what any of that has to do with saving an "AxisInverted toggle".

Because I am not sure what you're trying to do, I can only recommend you read the documentation on how GUI toggles work:

http://docs.unity3d.com/Documentation/Components/gui-Controls.html

I hope this helps.

 

Okay, thank you. I was under the impression that I needed to deliberately call a cInput.ChangeKey in order to save to PlayerPrefs. I was using the example given in "Making a Custom GUI Menu" as a guide, where you do this:

Code (csharp):

1. GUILayout.BeginVertical();
2. GUILayout.Label("Secondary");
3. for (int n = 0; n < cInput.length; n++) {
4.   if (GUILayout.Button(cInput.GetText(n, 2))  Input.GetMouseButtonUp(0)) {
5.     cInput.ChangeKey(n, 2);
6.   }
7. }
8. GUILayout.EndVertical();

Since that's not necessary, is there any advice on how to track down why the cInput.AxisInverted isn't saving/loading? As a side note, the code example above, that I am using as well, does correctly save to PlayerPrefs.

 

I'm still confused about what this has to do with an axis' inversion status. The code above does nothing with inversion. It merely makes a button you can click to change the keybindings.

That said, I suspect that the value you're using for your toggle button is not loading the inversion status of the axis. So essentially, your code is resetting it back to be not inverted each time the game restarts. But I really can't say for sure. It would be helpful to see the code you're actually using to display a toggle button.

 

Here is the actual GUI, that I am using to set the Inverted flag:

Code (csharp):

1.         GUILayout.BeginHorizontal();
2.         cInput.AxisInverted("Vertical", GUILayout.Toggle(cInput.AxisInverted("Vertical"), "Invert Move"));
3.         GUILayout.EndHorizontal();  

I think we can ignore the GUI code. It is functioning correctly as far as I can tell. I've verified that the PlayerPrefs are saving that Vertical is inverted. What I'm seeing is my "cInput.SetAxis("Vertical", "Up", "Down");", is wiping out all cInput_axInvs PlayerPrefs.

If I am doing something wrong it must be how I am using cInput.SetAxis in my Start() which looks like this:

Code (csharp):

1. function Start () {
2. cInput.SetKey("Left", "A");
3. cInput.SetKey("Right", "D");
4. cInput.SetKey("Up", "W");
5. cInput.SetKey("Down", "S");
6. cInput.SetAxis("Vertical", "Up", "Down");
7. }

I'll admit what follows is probably not necessary but I wasn't sure how to fix this:

I created a new function in cInput to get the inverted user prefs before they get wiped out by SetAxis.

Code (csharp):

1.     public static bool GetAxisInverted(string axisName) {
2.         Boolean AxisInverted = false;
3.  
4.         if (PlayerPrefs.HasKey("cInput_axis")) {
5.             string _invAx = PlayerPrefs.GetString("cInput_axInv");
6.             string[] _axInv = _invAx.Split('*');
7.             string _ax = PlayerPrefs.GetString("cInput_axis");
8.            
9.             string[] _axis = _ax.Split('#');
10.             string[] _axName = _axis[0].Split('*');
11.  
12.             int _axCount = int.Parse(_axis[3]);
13.             for (int n = 0; n < _axCount; n++) {
14.                 Debug.Log (_axName[n] + ">" + axisName);
15.                 if (_axName[n] == axisName) {
16.                     Debug.Log ("FOUND" + _axName[n]);
17.  
18.                     if (_axInv[n] == "True") {
19.                         AxisInverted = true;
20.                     }
21.                    }
22.             }
23.         }
24.         return AxisInverted;
25.     }

I then use it like this:

Code (csharp):

1.     // Revert Inverted if cInput._SetAxis sets _invertAxis[_num] = false;                                                                                                        
2.     var isVerticalInverted : boolean = false;
3.     if (cInput.GetAxisInverted("Vertical")) {
4.         isVerticalInverted = true;
5.     }
6.     cInput.SetAxis("Vertical", "Up", "Down");
7.     if ( isVerticalInverted  !cInput.AxisInverted("Vertical") )    {
8.         cInput.AxisInverted("Vertical", !cInput.AxisInverted("Vertical"));
9.     }
10.     if (cInput.AxisInverted("Vertical")) {
11.         Debug.Log("Inverted");
12.     }

 

Oh! I see what you mean now. It does seem as though SetAxis is wiping out the inversion status. What an embarrassing mistake!

In cInput.cs in the _SetAxis() function, comment out or remove the following lines of code (near line 460):

Code (csharp):

1.  
2. // Remove these lines of code
3. _invertAxis[_num] = false;
4. _SaveAxisInverted();
5.  

That should fix it.

Thanks for pointing this out. This fix will be in the next release of cInput.

 

I was thinking of doing that but I figured there was a really good reason it worked the way it did so that's why I wrote a workaround. Thanks for enduring my poor attempt at asking for help. Though, I have much better understanding of how cInput works now, so it was a good exercise for me.

 

The tricky thing was that there were two problems happening, making things worse.

If the defaults had already loaded from PlayerPrefs, line 2 in the example above would ignore them. I tried removing just this line and things still didn't work.
This is because line 3 usually executed before PlayerPrefs had finished loading, which saves to PlayerPrefs. So it was saving the "false" value to PlayerPrefs before it even had a chance to load the value in.

In the end, I realized that neither of those lines needed to be right there and as a result, things should work as intended now.

Thanks again. (c:

 

What is the maximum number of controllers, i can use with cInput2?

 

Unity only supports KeyCodes for up to 4 gamepads' buttons, so cInput only supports 4 gamepads.

 

Ok, i thought, the number of Controllers was increased in Unity 4.3.3.

 

I think the number of axes per gamepad was increased from 10 to 20, but the number of controllers itself with keycodes for the buttons is still only 4 according to the documentation.

http://docs.unity3d.com/Documentation/ScriptReference/KeyCode.html

So you could use the joysticks/axes on as many gamepads as you want, but if you intend to push buttons on any of them above the 4th one, you're out of luck, I guess.

 

aaahh, ok thanks, unfortunately, my game will support up to 10 local player

 

We'd really like to support more than 4 gamepads in cInput, but we don't really know how due to the KeyCode limitation. If you (or anyone else) finds a solution, please let us know.

 

A strange problem is happening here after I updated to cInput 2.7.1...

Everything was working normally, but after the update no new inputs are accepted. I edit the setup file to add new keys and nothing happens, if I try to call them with another script the log says such key does not exist.

At the same time, if I delete the setup file the inputs there were active before the update work perfectly, as if the file' still there.

I deleted all cInput related files and tried to reimport, and now I'm getting an strange error.

This is really strange and confusing... I don't understand why it doesn't allow any new input, much less how it can work without the input file.

Basically this is what is happened:

Everything Working > Uploaded to 2.71 > Tried to Add new Input but it failed > Deleted the Setup File > Every input made prior to Upload kept working even without the file > Reimported cInput > Picture Error > Still works without setup file > Doesn't accept new inputs.



This is my setup script, the new key I'm trying to add is the ''GPS'' key. Please not that changing the name of the previous inputs will make them stop working too, even if you call the new name in the other scripts.

:

Code (csharp):

1. #pragma strict
2.  
3. function Start () {
4.  
5.  
6. // this creates a new key called "Up" and binds W and the Left Analog Up to the key
7. cInput.SetKey("Forward", "W", "Joy1 Axis 2-");
8. // this creates a new key called "Down" and binds S and the Left Analog Down to the key
9. cInput.SetKey("Backward", "S", "Joy1 Axis 2+");
10. // this creates a new key called "Left" and binds A and the Left Analog Left to the key
11. cInput.SetKey("LeftStrafe", "A", "Joy1 Axis 1-");
12. // this creates a new key called "Down" and binds D and the Left Analog Right to the key
13. cInput.SetKey("RightStrafe", "D", "Joy1 Axis 1+");
14. // this creates a new key called "Run" and binds Left Shift and the Left Analog Right to the key
15. cInput.SetKey("Run", "LeftShift", "Joystick1Button1");
16.  
17. //Aim and Weapon Related Keys
18. // this creates a new key called "Aim" and binds Right Mouse Button (Mouse 1) and LB to the key
19. cInput.SetKey("Aim", "Mouse1", "Joystick1Button4");
20. // this creates a new key called "Fire" and binds Left Mouse Button (Mouse 0) and RB to the key
21. cInput.SetKey("Fire", "Mouse0", "Joystick1Button5");
22. // this creates a new key called "Previous Weapon" and binds 1 and LT to the key
23. cInput.SetKey("PreviousWeapon", "Alpha1", "Joy1 Axis 3+");
24. // this creates a new key called "Next Weapon" and binds 2 and RT to the key
25. cInput.SetKey("NextWeapon", "Alpha2", "Joy1 Axis 3-");
26. // this creates a new key called "Camera Strafe" and binds Middle Mouse Button (Mouse 2) and Right Analog Press to the key
27. cInput.SetKey("CameraStrafe", "Mouse2", "Joystick1Button9");
28.  
29. //Camera Related Keys
30.  
31. // this creates a new key called "Mouse Up" and binds Mouse Up and Right Analog Up to the key
32. cInput.SetKey("Mouse Up", "Mouse Up", "Joy1 Axis 5-");
33. // this creates a new key called "Mouse Down" and binds Mouse Down and Right Analog Down to the key
34. cInput.SetKey("Mouse Down", "Mouse Down", "Joy1 Axis 5+");
35. // this creates a new key called "Mouse Left" and binds Mouse Left and Right Analog Left to the key
36. cInput.SetKey("Mouse Left", "Mouse Left", "Joy1 Axis 4-");
37. // this creates a new key called "Mouse Right" and binds Mouse Right and Right Analog Right to the key
38. cInput.SetKey("Mouse Right", "Mouse Right", "Joy1 Axis 4+");
39.  
40. //Action Related Keys
41.  
42. // this creates a new key called "Skill" and binds Space and Digital Up to the key
43. cInput.SetKey("Skill", "Space", "Joy1 Axis 7+");
44. // this creates a new key called "Melee" and binds Space and Digital Up to the key
45. cInput.SetKey("Melee", "Tab", "Joystick1Button8");
46.  
47. cInput.SetAxis("Mouse X", "Mouse Left", "Mouse Right");
48. cInput.SetAxis("Mouse Y", "Mouse Down", "Mouse Up");
49.  
50. //GPS Keys
51.  
52. //this creates a new key called ''GPS'' and binds M and ''Back'' to the key
53. cInput.SetKey("GPS", "M", "Joystick1Button7");
54.  
55.                     }

 

It sounds as if you don't have write permissions in your project folder or something. Or that the PlayerPrefs where the cInput settings are stored are not being updated. Sometimes I get a similar error when opening Unity or importing something and I just try again or restart Unity and it works after that.

I'd recommend trying the following things in this order, and moving on the the next step if the previous step doesn't resolve your problem:

1. Use cInput.Clear() to get Unity to clear the cInput related PlayerPrefs values.
2. Restart Unity
3. Restart your computer.
4. Manually delete the cInput related PlayerPrefs from your registry. (These will be in HKEY_CURRENT_USER -> Software -> [YourCompanyNameHere] -> [YourGameNameHere] and all the entries will start with "cInput")

If that doesn't resolve it, let me know and we can try to figure something else out.

And this is unrelated, but FYI, you made a copy/paste error on line 44 of your code. (c:

 

I'm not sure if it solved the problem or not... I'm not longer getting any error for the new key, however, no input is working and I'm getting an error for the axis.

I'm getting this error now:


I remember having the same error right when I started using cInput long ago, but it ''fixed itself''. I'm creating a new project to make some tests and see if the problem is with my project or the asset. I'll return with feedback soon.


----------------------------
----------------------------
----------------------------
EDIT:

Found out what was going on Deozaan... God I feel like a complete fool by saying this lol

Happens that I just forgot to initialize the setup script... I deleted the GameController prefab from the scene for wahtever reason and forgot to add the script to the new one... Man, really...

Thanks for the help anyway.

Also, thanks for the correction on line 44, I'm surrounded by so many codes that I don't notice information online lines =)

 

Thanks for the followup. I'm glad you got it working. (c:

 

Hi,

I bought cInput and am evaluation it for our use. However, I am concerned about the use of strings to identify actions. Strings are very slow to compare and since we will be checking quite a few of them I am worried about creating unnecessary overhead. Any thoughts on this and/or are you planning alternative identification methods (hashes etc.)?

TIA!

 

At the moment we're not planning alternative identification methods. However, there are a couple of things that come to mind that might speed up the process a bit:

1. I suppose it wouldn't be that difficult to publicly expose the array index so you can refer to the actions by index. This seems fairly inconvenient to me though, since you'll be on your own to remember that action 13 is "Use Item" for example.
2. You could define some string constants so you're not repeatedly building new strings each time you want to compare.

 

Part 1 is trivial, that's what enums are for! ;-)
Hashes are probably the way to go though if you want ease of use. I also noticed you seem to loop over arrays quite a bit, it would be MUCH quicker to store the actions in Hash Tables. Any specific reason you are using arrays/lists instead?
Not to be overly critical, but I noted at least one instance where you looked up the same corresponding index twice in a row instead of storing it in a variable.

There are two reasons using strings in this way is a bad idea:
1. Using strings allocates new stuff for the garbage collector to deal with. And Unity's GC is not good. At all. So you really do want to minimize GC happening. This is not only a concern on mobile's either, desktops will stutter due to GC as well.
2. Comparing strings is (according to the docs - I have not benched it) 5x slower than using ints etc. So looping over string comparisons each frame is not good.

Given the above - would you consider taking a look at this soon or should we press ahead and modify cInput to perform better? It would be beneficial for you to do so, and us since we can keep in line with any future updates you release.

Thanks in advance!

 

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 live within a few (business) days. If you bought cInput from our website, then the update is available immediately.

cInput changes:

v2.7.2

• Axes no longer return 0 if deltaTime is 0. (Thanks Mel)
• SetAxis no longer resets the axis inversion to false. (Thanks SpectralRook)
• Changed Script Execution Order for cInput so that it runs before other scripts.
• No more errors if cGUI files are missing. (Thanks Shyam)
• An important debug log warning is no longer commented out. (Thanks Shyam)

 

This probably isn't a good reason, but the main reason is because cInput was created over two years ago when we were still fairly noobish to Unity. And I can't speak for Roidz's experience level, but I was also pretty new to C# and a lot of its concepts as well, at the time.

If you can tell me where that was, I'd be happy to fix that.

I think that changing from arrays and strings to hashtables, etc., would require a non-trivial amount of work. Right now we're focused on making cInput as stable and bug free as possible rather than worrying about theoretical performance problems. So while we do agree with you that what you're suggesting makes a lot of sense, it's not something we're likely to start pursuing right away.

 

No, not a very good reason....

Perhaps you have fixed this since I do not think we are fully up to date. But _FindKeyByDescription loops over your collection of actions. You first get the index and do a comparison against it. Then if > -1 you run it again. So you are basically running the loop twice for no reason whatsoever.

Please do correct me if I am wrong, but my impression from a quick look at the full code is that it is poorly planned and not optimised at all. If I read things correctly you are running a big loop every frame that updates all values regardless if they are in use or not. And it is all done using string comparisons. :-/

While I know there is a school of thought that states "implement first, optimise later when stuff works" it really still needs to be optimised. Sure, we run games on pretty impressive hardware these days, but many of us still push the envelope. And throwing away time for no reason is just...bad.

Apologies if you think I am being harsh. cInput will probably help many relatively new to game development to avoid the Unity default key setup screen. Which is good. But I call it like I see it and we will go ahead and roll our own as I am not very confident with cInput at this point. I hope you still appreciate the feedback.

 

Hey Foxxis,

We do appreciate every feedback we get. And as Deozaan said before everything you say makes perfect sense.
I also don't think your being harsh at all. Your being helpful and telling us what you see.
Over the last 2 years we streamlined cInput a lot and with the feedback from other users we made cInput a lot faster then it originally was to a point everyone is and was satisfied with the speed and the way it works.
I would suggest you do some tests to see how fast/slow cInput is in your experience before you start making your own system.

I also can understand that using non-perfect/uniform code in your own project might be a reason not to use it, but as i said i don't think speed is gonna be an issue here.

Deozaan and me worked hard improving cInput over the last 2 years and we agreed that if we would make cInput today we would do a lot of things different today.

Making changes that you suggest would improve cInput no doubt and together with your suggestions we have a lot of ideas how we could improve cInput even more but that would be something for cInput3 because it would require a total rewrite.

This won't happen this week or even the next month i'm afraid but we do have plans for it. As for now cInput is stable, fast and gets the job done more then adequate. Granted not always using the ideal uniform way to do things but i really hope you give cInput a proper testrun.

At least you can use our code to help you roll out your own system.

But as i mentioned before we really do appriciate your feedback and take it with us in our next projects, including cInput3.
If you are unhappy with your purchase and think you're not getting what you payed for we will refund you your money ofcourse. I do hope you give cInput a proper test spin though and hope you are still satisfied in the end.

 

Hi!

Thanks for the reply! Happy you appreciate the feedback. I may be blunt at times, but I really do aim to be constructive and helpful.

Regarding the current state of cInput, yes I had planned on clocking it on our target platforms. If speed is not an issue I will likely leave it be, but given the nature of the project we have a *lot* of inputs, so we will see how it holds up.

As for a refund that is out of the question. Regardless of how things turn out you deserve the fee you charged. For those that might read this considering cInput it should be stated that it is not a bad Asset, not at all. It could have been implemented in a more elegant manner which would automatically have meant it performed better. As it is now it takes a pretty brute-force approach to the problem.
But for most users with a limited number of inputs I am sure it will perform well enough.

I will keep you posted with any changes I might add if we stick with it.

 

Hey! i came from this post here: http://answers.unity3d.com/questions/233081/map-ios-joystick-to-the-input-manager.html to your asset

in this post someone asked if it is possible to map the WASD keys to an onscreen joystick. so, can this be done with cInput? if yes, how?

 

Thanks for pointing out that redundancy. It was done correctly in the function above your quote, but somehow we missed it where you quoted, and another nearby function as well. I've got this fixed for the next release (2.7.3).

Thanks again for your feedback.

That depends on how the onscreen joystick works. cInput doesn't do anything with screen touches, but it does work with, for example, virtual keyboards. So if the onscreen joystick is a virtual joystick, meaning it actually shows up as a joystick axis in Unity, then it can be done in cInput.

But if the onscreen joystick works by some logic similar to: The center of the joystick is at (x,y) and if you press at (x-5,y) then you've pressed left on the joystick, then cInput wouldn't know how to handle that.

In essence, anything that can be bound in the Input Manager can be made to work with cInput. Anything that gives other values (touches, etc.) cannot be remapped with cInput.

 

My friends and I have problem to config a steering wheel joystick with pedal and other joystick MaxFighter F16 , each axis is not reading correctly, we have followed the tutorials but we do not know what is wrong, the joysticks work well inside Windows and games. We don`t know what to do,this is important for our project.

What could be the cause of this issue??, help please.

 

So, I've just bought cInput and I'm trying to get it working with my project. Problem is, every time I load up a scene, I immediately get this error:

IndexOutOfRangeException: Array index is out of range.
cInput._LoadInputs () (at Assets/Plugins/cMonkeys/cInput.cs:1534)
cInput.Start () (at Assets/Plugins/cMonkeys/cInput.cs:165)

Have I done something terribly wrong?

 

Can you please be more descriptive? in what way are the axes not reading correctly?

My guess is that your steering wheel is a highly sensitive axis, and Unity by default has a fairly large deadzone for all analog axes. You might need to change the deadzone down from 0.19 to something lower, such as 0.05 in Unity's Input Manager and see if that helps.

Are you using cInput v2.7.2? It looks like it's having a problem with loading the axis inversion status, which would be due to a change I made in v2.7.2 to fix cInput overwriting the inversion status each time. I'll get this fixed, but in the meantime, you should be able to fix it by adding the following code anywhere within the cInput class:

Code (csharp):

1.  
2. void OnApplicationQuit() {
3.     _SaveAxInverted();
4. }
5.  

 

Worked like a charm! Many thanks for the quick response