Rewired - Advanced Input for Unity

I'm probably going about this the wrong way, so I apologize if it seems just stupid. but I am trying to get Oculus touch up and running with rewired, which I know the docs say that it is not directly supported. Here is what I am seeing:

I was able to get the equivalent XBox buttons/sticks/triggers mapped and they seem to work ok now. I did have to disable Raw input or rather select Unity Input to get this working. I also needed to change the Max Joysticks per player to 3 to get them to show up in the mapper which makes sense.

I am stuck on getting it working on the game menus now. I added the UI Elements for unknown controller but this did not work. Any ideas what I am I missing here?

I have not tackled the whole motion thing yet, which is just scary. Anyway, one step at a time.

 

1. Are you using the Rewired Standalone Input Module.
2. Are you using Control Mapper?
3. Show me your UI Joystick Map configuration.
4. Did you assign the Joystick Map to your Player?
5. Did you set the Joystick Map to be enabled on start.
6. What are your Rewired Standalone Input Module inspector options set to?

 

1. Yes.
2. Yes, Using the control mapper. I used this to set the mappings for the other buttons/sticks/triggers for touch.

3.

4. Do you mean this?

5. Yes.
6.

I should also mention that the Xbox controller is working in controlling the menu navigation but I did that quite a while ago so maybe I am just missing something here.

This project is not currently using the latest updates but I did not see any mention of anything to do with oculus touch in any updates so assume it is not relevant for this. Seems this project is currently using .97

 

I see nothing obviously wrong in your configuration. Therefore, the problem must be something else. As the Troubleshooting - My Controller Doesn't Work page shows, use the Debug Information foldout in the Rewired Input Manager inspector to view all attached Controllers, Players, joystick assignments to Players, Joystick Maps, and individual ActionElementMaps to determine at what point it's not working.

Even though you said you changed Max Joysticks Per Player to 3, I'm guessing that controller assignment is the issue here. If you have an Xbox controller attached at the same time, you have 4 devices, which would cause it to leave one device unassigned.

Check the Joystick Maps assigned to the Player also. Make sure they're enabled and make sure the individual Actions are mapped.

 

I'll keep looking into it but in relation to the above removing the xbox controller has no effect other than to reduce the number of Joysticks from 3 to 2 in the debug info foldout. I should have mentioned that I can see all the controllers in there and they are showing values in response to usage of buttons and sticks.
The Player section shows all the controllers listed (3 joysticks)
Changing joysticks to max 5 did not help.

So looking into the joysticks that are shown I can see that the Button and axis maps for the Xbox controller shows correctly but the touch oculus touch controllers show 0 buttons and axis maps.

 

The maps are the problem then. Try clearing Player Prefs. If you're using Control Mapper, you probably have some XML save data being loaded. The console would be showing you warnings that the XML data is being loaded when you start.

 

You get so used to not seeing things.. Yep that was it. Cleared the data and they work. Thanks so much for the assist.

Now to work out the motion stuff. I am thinking that I can just use the Oculus stuff alongside rewired during game play for hand tracking or is there a better way to do that perhaps.

 

Good, glad that was it. I sent you a PM with some prelim Oculus touch controller definitions. (Only work with Unity Input as the input source.)

 

Hi, there is a warning in my Input Manager. How I can avoid this? I don't understand its hint. The argument of this warning is "You are editing a prefab instance of the Rewired Input Manager. Changes made to this prefab instance will not,,,,"

 

The help box explains the problem and solution exactly. I do not know how I can possibly clarify it further unless you don't know what Prefabs are and how to work with them.

Unity Documentation - Prefabs

As the help box says, edit the Prefab parent in the Project pane instead of the scene instance if you don't want to see that warning. Either that or do not make a prefab out of your Rewired Input Manager in the first place.



A Prefab consists of a Parent and potentially many Instances:

• Parent - The on-disk source object. This is the original object.
• Instance - A "copy" of the Parent, but not exactly because an instance only stores differences in data compared to its Parent. Changing data on an Instance does not affect the data on the original Parent unless you commit it by clicking the "Apply" button in the inspector. You can revert the Instance back to the original data contained in the Parent by clicking the "Revert" button.

When you see that warning box, you know are editing an Instance of your Rewired Input Manager. That means edits you make to that instance will only exist in that instance alone. Other instances of that Prefab in other scenes will not contain the changes you made to the instance and therefore you will end up having many copies of that Rewired Input Manager all with different data.

If you make a Prefab out of a Rewired Input Manager and you want to make changes that will be mirrored to all instances of that Prefab, do not edit the scene instance object. You have to edit the Prefab parent itself in the Project pane if you want those changes to be picked up by all other instances of that Prefab in your project.

This warning is shown because too many people didn't understand this and made a Prefab, then made changes to the instance, then they got confused because their changes seemed to have reverted when they opened a different scene with a different instance of the same Prefab. They'd end up with random different Rewired Input Manager configurations scattered throughout their project.

Rewired uses Unity's serialization system and therefore all rules that apply to any object in Unity also apply to the Rewired Input Manager. Understanding of Unity's core systems is extremely important.

 

Hey guavaman and everyone, hope all are doing well !

Guys, I'm having a bit of an issue wrapping my mind around something.

Anyone has a good way of handling combo buttons + remapping that allows overlapping bindings ?


On PC it's pretty easy to handle, we can use 4 new keys without issues so I made 4 new actions.

On gamepad, I mapped those actions to the D-pad by default and plan on checking it when used in combo with another suitable button since the D-pad is already loaded with other actions.


Problem is, players can remap all 8 actions mapped by default to the D-pad to anywhere, and can map other actions to the D-pad.

So while filtering the default setup is indeed easy, I don't know how I'm supposed to handle the case of otherwise valid remappings.

(ps: obviously I'm searching for a solution that involves the least non-user-assignable actions possible)


edit: hmm does something like controller.LockConcurrentBindingsOf(string action) exists / is possible to add ? Could call it when combo conditions are met and would solve the conflict issue in a pretty neat and easy to use way !

 

An example of what I see. The trigger is not being touched...

 

@guavaman @Steve-Tack

Rewired HOTAS templates are so amazingly helpful and time saving. I was just doing some testing to see how I can use them more effectively. So if you only use a subset of the HOTAS template you can handle all of the joysticks from the $20 ThrustMaster usb joystick to the CH FighterStick and everything works very nicely. I expect for at least name brand joysticks (ThrustMaster, CH Products, and Logitech's Saitek unit) should be a perfect fit.

The Rewired HOTAS template subset of components I have been using currently are: Stick X, Stick Y, Trigger, Stick Button 1, Stick Button 2 (also map the pinky on higher end sticks to match Stick button 2), and HAT1.

Need to do more testing with some other sticks but this is really promising for having basic mapping from low end joysticks to high end HOTAS sticks and only have to map everything just once. And yes I have a big grin on my face thanks to Rewired.

Have to spend some more time looking at the Throttles and Yokes in depth to see how I can get a good basic subset in those cases also.

EDIT: Example of POV HAT using the Rewired HOTAS templates.

https://forum.unity3d.com/threads/c...ship-or-aircraft-cockpit.455223/#post-2957041

 

Can you please give an example? I don't understand fully what you're trying to do here.

How do you allow the users to map 8 Actions to a D-Pad? Is this on multiple different Controller Maps?

If you let your users remap things completely at will, there's no way you can stop them from mapping impossible situations. For example:

To use "Grenade", press "Fire" plus "Run" simultaneously.
By default, "Fire" is mapped to "Button A" and "Run" is mapped to "Left Trigger"
User changes mapping and maps "Fire" to "D-Pad Right" and "Run" to "D-Pad Left"
They have just created a mapping which is impossible to use.

Edit: Are you trying to achieve something like this?

"Fire" = A
"Run" = L
"Run + Fire" = "Grenade"
Problem: When "Run" + "Fire" is pressed, both "Fire" and "Grenade" return True.
Goal: When "Run" + "Fire" is pressed, "Fire" is blocked and only "Grenade" returns True.

No. Bindings are completely handled in the ControllerMap which is used by the Player to determine the current values of Actions by looking up the value of a controller element pointed to by the binding. The Controller itself is not bound by or even aware of those mappings in any way. Controllers can be assigned to many Players at once and bindings in one Player do not affect any others, nor do they affect what values the Controller returns.

Again, can you give an example of what this function would do? I don't understand the goal.

 

Main issue is we're out of buttons on tradionnal gamepads (like xbox/ps4) and we need 4 new actions to add a quick item select feature so the goal is to find a work around.

On keyboard we got the new actions called ItemSlot1, ItemSlot2, ItemSlot3 and ItemSlot4 bound to the keys 1, 2, 3 and 4, so far so good.

On gamepads, we have 0 free buttons BUT we believe it'll be fine gameplay-wise to change the behaviour of a few buttons while the "block" action is held down.

That part is all good except that remapping complicates things a lot.

Example:

• D-pad down is bound to the "Inventory" action by default (that only runs when the "block" action is not held)
• It is also bound to the "ItemSlot2" action (that only runs when the "block" action is held)

Problem are:

1. If a player binds the "Inventory" action somewhere else, we'll be filtering out "Inventory" for nothing when "block" is held (but we can live with that, it's not the worst part)
2. If a player binds let's say the "Take" action to D-pad down, it will trigger that "Take" action when expecting only the "ItemSlot2" action to run

 

@_met44 Thanks for the explanation. I understand your problem now.

Your current approach is to make new Actions, stacking bindings, and allowing the user to customize both layers. Does it not make sense for your purposes to instead do the button combos by just checking for the value of two fixed Actions?

Code (csharp):

1. if(player.GetButtonDown("ItemSlot2") ||
2.     ((player.GetButton("Block") && player.GetButtonDown("Inventory")))
3. {
4.     // Run Item Slot 2 code
5.     // You could even throw some controller type checking code in here if you're worried about the same combination of key presses triggering this Action on the keyboard
6. }

If the user remaps Inventory to the L trigger for example, he would have to hold "Block" plus L in order to trigger the ItemSlot2 Action.

I know this is a simplistic approach, but sometimes it works fine depending on your needs. It's not as customizable for the user.

Otherwise, it gets pretty complex. I've done this before in Rewired for keyboard modifier key handling.

 

@_met44

You might consider using three separate Controller Maps for this if you're willing to have everything blocked when you press a button that has no modified version:

Map 1: (Only for the modifier Actions)
Block = Right Shoulder

Map 2: (Your primary Actions go here)
D-Pad Down = Inventory

Map 3: (Your modified Actions go here)
D-Pad Down = ItemSlot2

Default:
Map 1 enabled (always stays enabled)
Map 2 enabled
Map 3 disabled

Press "Block": Disables Map 2 and enables Map 3.
Release "Block": Disables Map 3 and enables Map 2.

For remapping, you'd have to make sure Map 1 triggers assignment conflict warnings with Map 2 and 3 and vice versa so they don't map something under the Block button.

This also has some other side effects such as making all your primary Actions inaccessible when Block is held. This may or may not be desirable. For example, if you want the player to still be able to move when he's holding Block, you'd want to put the movement bindings on Map 1 and probably keep them from mapping anything on Map 2 or 3 onto the movement elements.

Edit:
It may be helpful to be able to selectively enable and disable individual ActionElementMaps on the Controller Map in this situation.

 

hmm interesting, is disabling individual ActionElementMaps already available or something you have yet to add ? If it is i could roll my own LockConcurrentBindingsOf feature !

Anyways thanks a lot for the help, it's much appreciated as always.

 

It will be new. I've already added it to the code, but I don't plan on releasing 113 for a while yet. If you want a beta, let me know.

How would that function work? If you press "Block", you'd want to disable all other bindings to anything that can be used together with the modifier. You would have to know beforehand your list of Actions that can be modified, then call that method for each one of them. Then after, you'd have to re-enable everything which means you need to keep a list of what was disabled. You'd also want this to work across multiple controller maps.

Code (csharp):

1. int DisableConcurrentBindingsOf(string actionName, IList<ControllerMap> controllerMaps, List<int> disabledAEMIds) {
2.     // Look up what elementIdentifierId the actionName/id is bound to
3.     // Disable any other bindings to that same element on all Controller Maps
4.     // Populate a list of the Action Element Map ids (or the aems themselves) that were actually disabled
5.     // Return a count of disabled AEMs or-1 if there was no binding found for the action name
6. }
7.  
8. int SetActionElementMapsEnabled(List<int> aEMIds, bool state) {
9.     // Find each Action Element Map and enable it
10.     // Return count of changed AEMs
11. }
12.  

Is something like that what you're thinking?

 

@guavaman

Actually Realistic FPS with a racing wheel is not bad at all. If you have a racing wheel, 3 pedals (clutch/gas/brake) and a mouse it plays really nicely. Then map the clutch to the shift key (for sprinting) and gas pedal for forward and brake for reverse it works great. It really smooth and using the paddle shifters for switching weapons is perfect. It works best with a ThrustMaster style racing wheel with all of its buttons and d-pad on the wheel than you can handle all of the normal functions. The mouse is used for looking around and for firing.

It is amazing just being able to switch from keyboard(with a mouse), to a gamepad, to a flight controller and then to racing wheel/mouse at anytime without any effort. Sure makes it easy for testing so many aspects of a game so efficiently. Just having fun on a racing wheel Friday.

 

@longroadhwy

Lol! I never thought of playing an FPS with a steering wheel. Cheers to Racing Wheel Friday!

 

Important Annoucement:

I have just discovered (thanks to a user support request) that joystick support on Android has been completely broken by a recent Unity update. I do not know the exact version the change was made, but Unity 5.5.0f3 exhibits dramatically different joystick behavior than previous versions of Unity. Because Rewired does not implement a native input library on the Android platform, Unity's new bugs affect Rewired.

Controller connect/disconnect is broken

• When a controller is attached to the system, the Unity joystick list does not update until a button or axis is activated on the device. This includes at the launch of the application -- no joystick is reported as present until some input is received from that device. Previously connect/disconnect happened just by connecting or disconnecting the device. Rewired cannot accurately give device connect/disconnect events when devices change.
• Controller disconnections leave a ghost controller in the joystick list that never disappears. When the same controller is re-attached, it creates another entry in the joystick list appearing as 2 devices. Each time you disconnect and re-connect, yet another device appears in the list.
• Controllers no longer appear back in the same array position when disconnected and re-connected. This affects Rewired's ability to recognize the controller as a re-connected controller.

This behavior is exactly the same as the Unity 4.x Linux joystick behavior (the reason the Linux native library was created). There is currently no known solution to these issues except to use an older version of Unity that has working joystick support.

This has been reported to Unity (Case 880018).

Edit: According to this, at least part of this is fixed in 5.5.2:
https://issuetracker.unity3d.com/issues/application-detects-gamepad-only-after-its-input-was-made

According to the above, it does not happen in 5.4.4f1.

Edit 2: Unity has responded:

 

It can wait (we're releasing the patch in a few days and wont update right before).

Not exactly, the way I imagined it is higher level than this and more autonomous:
- Call LockConcurrentMappingsOf(string actio, bool onoff) (either call that on a controller or pass a controller type as parameter)
- Get mappings of the action
- Walk all actions for the target controller*
- Disable/enable all actions that have a concurent mapping

(possibly caching stuff if needed for performance but seems like it'll be quick enough to iterate through it all)

 

This approach appears to have several issues if I'm understanding it correctly:

1. How do you specify which of these mappings to keep enabled? Obviously you want just one of your mappings to be enabled and all other disabled, but this isn't specified anywhere. Or are you planning to just manually enable that mapping in a separate function call afterwards?
2. Since you're not receiving any list of changed mappings, you wouldn't have a way to restore the state of all the mappings to their previous state once you're finished (once you release the "Block" button). You could turn all mappings either on or off, but what if some were already off and you don't want them enabled when you do the reversion?
3. You would have to be processing all different Controller Maps for that controller in different categories that might be loaded since no list of Controller Maps to process is specified. This makes it less useful if you have only a certain category of Controller Maps or a certain few maps you want this applied to and not just across the board. (I suppose you could have it apply to only enabled Controller Maps at the very least.)

Anyway, what you want to do would be possible with the ability to enable/disable individual mappings.

 

Also it helps if you restrict how many degrees the wheel has move too. The ThrustMaster racing wheel defaults to 1080 degrees it can be much more work especially if you are trying to keep the other hand on the mouse. But it is great for those who like a real challenge. If you go into the windows control panel and restrict the racing wheel to 270, 180 or even the lowest possible value of 40 degrees it makes it much easier. On the really low end ThrustMaster T100 racing wheel should work out of the box since it is restricted to 270 degrees. Looking at the newer Logitech wheels (G29 and G920) they should be able to work in a similar fashion since they have enough buttons on the wheel itself.

My mapping should work on all higher end racing wheels since I used the Rewired racing template. The Rewired templates are such a huge time saver too.

There is really a point to testing a racing wheel in a FPS context it is not just crazy way to use input. The main goal is to be able to use a racing wheel for controlling a horse in a combat situation. If you look at @Malbers Horse Animset Pro 3.0 you can can get a good idea of how it would work. Check out his Horse Animset Pro 3.0 Melee Test 1 video is this message.

https://forum.unity3d.com/threads/horse-animset-pro-2-1b.375652/page-10#post-2918722

 

Let's say I have ItemSlot1 bound to Dpad left and Inventory bound to Dpad left. I should be able to target only the "Inventory bound to Dpad left" mapping no ? in which case the "ItemSlot1 bound to Dpad left" will still be there right ?

Does anything else cause mappings to be disabled ? If not then it's just a matter of not mixing calls to the feature (in my case i only have only place that would use it so it should be fine, nothing else will take over and risk leaving actions in unwanted state). Not sure how it should be handled in a more generic case, maybe limit to one active lock at a time ?

We don't use controller maps a lot but i supposed there could be an extra parameter if needed to be more specific.

So glad to read this, thanks. Looking forward to trying it out ^^.

 

If you're passing in just an actionName/Id, no, you would not be able to target "Action bound to X". If that's how you want it to work, you'd have to pass in the ActionElementMap. Without the AEM, all AEMs that map to that Action would have to be disabled. The AEM is the only object that contains both pieces of required information: Action and Element. Alternately, you could pass in actionId and elementIdentifierId at the same time instead.

Nothing disables individual AEMs at this point because that feature is brand new. Can't say that it will always stay that way. In planning this function, I was aiming for any number of possible use cases. If the only use case is what you have specifically in mind for your needs and how you use Controller Maps, etc. then it would be fine as originally proposed (with the addition of specifying the elementIdentifierId, etc). I would say it would be best for you to implement that on your end of things in that case while I expose something more multi-purpose.

 

Quick question that I couldn't find by googling. Is there any way to get a unique identifier for a controller that recently had a button pressed? For example, if I use GetButton("Attack") and it evaluates to true, what is the best way to find a unique id for the controller that pushed that button to determine if I want to perform the action?

For example, on a main menu when the user pushes a button, they become the "active" person. I only want to accept input from that gamepad going forward past that point. So what I'd like to do is record a unique id for that gamepad, then refer back in the future when new actions are detected on GetButton() or another similar command. I want to check the unique id of the controller that made that action with the controller used at the activation screen by comparing their unique ids, then only processing the input result if they match.

Any ideas are very appreciated. Thank you!

 

I think you should rethink your approach. Rewired works on a Player model where Controllers are assigned to each Player. Players never return any value for input received from controllers that are not assigned to them. Your unique id system sounds like a redundant replacement for the Player controller assignment model.

Detailed information on the Controller and Player systems is in the docs:
Controllers
Players

The idea:
Only assign a controller to a Player if you want that Player to be using that controller.

Most likely this is the topic you want to read:
Implementing a "Press Start to Join" Joystick assignment system

To answer your questions directly:
Determining which Controller was last used

And Joystick.id is the unique id of the Joystick.

 

Hmm ok I see thanks for the info. I'll see how schedule goes but might wait to see what you add to the API, got enough things to do to keep me busy in the meantime

 

Re: Unity 5.5+ Android joystick problems:

Unity has responded to my bug report:
We have fixed this problem and it should not appear in version 5.5.2p2 and newer (also 5.6.0b6 and newer).
If you are still able to reproduce it on the latest version of Unity, please respond to this email.

 

As do I. I think I will add the method I posted to the API and then I can give you the code to do it as you wanted but not include that in the API.

 

Ah that's very nice thanks ! (and yeah I bet you're busy enough as well haha sorry )

 

NP! That's what I'm here for.

 

I'm trying to integrate Rewired and NGUI. I'm new to NGUI so I have no idea where to start. Any ideas?

 

I don't own NGUI and have never used it. Sorry.

I imagine it would be as simple as changing references to UnityEngine.Input.GetButton/Key to your player.GetButton/Key instead. There's no point in changing any pointer position / mouse button click stuff to Rewired. The only thing that would need to be changed is joystick/keyboard navigation code.

 

@Steve-Tack has done some work in this area. See his forum message #1965 in this thread. You can start at this message and read a few that follow that.

https://forum.unity3d.com/threads/rewired-advanced-input-for-unity.270693/page-40#post-2613846

 

@guavaman I have gotten a few users over the last month that have said that that the Logitech G27 &G29 Throttle Axis and the Shifter is not recognized by rewired at all. Have you had any problems on any the Logitech axis? The G25 and G27 I have here are working fine and I cannot recreate the "bug". They say that the axis is not able to been seen in the calibrate menu or recogized at all. It is working in the Logitech Global Profiler though. I have had them reset all Player Prefs and that did not work.

Im using windows 10
- Unity 5.4.0
- Rewired 1.0.0.104 U5

Direct Input with XInput Checked.

Thanks again for all you do.

devotid

 

You are not using the latest version of Rewired. 1.0.0.112 is the newest version. 1.0.0.110 had changes to make the old Logitech wheels work when no driver installed. Logitech's drivers around October 2016 removed support for these wheels. The new driver (or rather lack thereof) does not support the shifter on G25 or G27. The only way to make these old wheels work fully is to install an old Logitech driver.

The G29 definition does not support the Logitech G Driving Force Shifter. The profile was made with the help of a Rewired user who owns the wheel and he did not have that optional hardware and therefore did not map the device to support it. I would need to get information about the button indices of each shifter element from the Rewired/DevTools/JoystickElementIdentifier in order to add support to the profile. Rewired's recognized hardware definitions do not allow mapping of additional unknown elements beyond those in the definition so these elements cannot be mapped in Control Mapper or by any other means without removing the controller definition forcing it use the Unknown Controller definition instead.

 

Just a general question. Are you using the Rewired racing wheel templates or are you mapping each wheel individually?

 

Ok. I would think that there is already group of people still using the G25 and G27 and that they are familiar with this driver.
So, I will upgrade rewired and check the controller maps to make sure to map each one. ie; G25, G27 and G29 instead of using that templates?

Im using the [T] Racing Wheel Template. I thought that was the best and easiest way to do it. I used to have them all setup individually. :/

Im going to upgrade rewired to the newest version and then make a individual map for each Wheel that I want to map.

Is this the best way to ensure each wheel is working properly. I do not own a G29. I only have a G27 and G25 (im a Thrustmaster guy...lol)

devotid

 

Hi, @guavaman, I'm using Rewired in our game Near Death (http://store.steampowered.com/app/327560/) and have a customer whose Xbox 360 wireless controller isn't working.

They think it's the same issue that was reported and fixed in post #34 in this support thread: https://steamcommunity.com/app/323580/discussions/0/364041432729422715/?ctp=3.

That thread is for a different game, but the customer thinks it's the same issue. The dev on that game mentions a name mismatch with the controller, and that they added the new controller name to the config files for Rewired. It isn't clear what config files he's talking about, though. Do you have any guidance on it?

Thanks!

 

I only use the Racing Wheel templates myself. I know in the past you had mapped individual wheels but I was just curious to see if you converted to Rewired Racing wheel Templates. I think Rewired racing wheel templates are only way to go.

It looks like we both prefer ThrustMaster wheels. I think ThrustMaster has a nicer ecosystem for their racing wheel line compared Logitech.

 

• What platform is this?
• What input source(s) have you chosen to use?
• What version of Rewired are you using?
• What version of Unity are you using?

The developer who added a name to the Linux definition for the controller contacted me about the problem. The name he added to the definition would not have achieved anything because the name was already covered by the regex expression being used for name matching.

 

How did templates get into this discussion? Templates are not a problem. You can use them or not, it won't make any difference on these issues.

Again, where have you gotten the impression that you shouldn't be using templates? @longroadhwy's advice was that you should use templates, not that you should avoid them.

The issue at hand is not one of templates. It's one of the actual controller definition file not containing mappings for the optional shifter attachment on the G29. There are only 2 possible ways to make it work:

Add mappings for the shifter to the definition file.
Remove the definition from the ControllerDataFiles connected to your Rewired Input Manager so the G29 is no longer recognized so it will use the Unknown Controller definition and be fully mappable.

You could build a new executable for your customer in a new scene with a blank Rewired Input Manager and the DevTools/JoystickElementIdentifier tool. He would be able to get the button mappings for the shifter.

 

Thanks Guavaman! I just realized the Shifter does not come with a G29. I now understand the "Aux shifter" problem. If i add the shifter mappings to the G29 ControllerDataFiles will that mess it up for folks that do not have the optional Shifter? Any way to make a template for a wheel with shifter and without?

Also, what about the Throttle Axis not working on a few customers? Is that going to be a driver issue aswell?

Thanks again for helping me.

devotid

 

Sorry, I should have included all that info originally.

• Platform is Linux.
• Not sure what you mean by input sources. We tested with XB1, PS4, and 360 controllers. Haven't heard about this issue from anyone else, so assume it's a weird Linux driver thing.
• Latest Rewired from the Asset Store as of yesterday.
• 5.3.4p3

Do you know why adding the name to the definition appeared to have worked in that thread? Could you tell me where to add it so I can give it a shot with the guy who's having trouble in my game? I'm totally stumped otherwise ...

 

I suggest you send me the mappings and I add them to the definition. No, there is almost certainly no way to differentiate the device with and without the shifter. The only way would be if they change the product id when the shifter is attached, which is extremely unlikely. If they did, the device would not be recognized as is.

By "Throttle Axis" I assume you mean the accelerator pedal? The only thing I can think of that might cause this is the driver change. By not using the latest version of Rewired, it is not going to work with the shared-axis pedals that the new driver (or no driver) causes.

 

See the Settings page of the Rewired Input Manager for your platform:
http://guavaman.com/projects/rewired/docs/RewiredEditor.html#Settings

I cannot. His change would not have made a bit of difference.

If you want to get the information for this user's controllers, build him a test tool using the DevTools/JoystickElementIdentifier tool included with Rewired. Add it to a new scene, add a new Rewired Input Manager, and build it. It will display information about the device(s) attached including name, product guid, etc. Send me this information.

 

Thanks to @longroadhwy, I've been able to get the mappings for the G29 shifter. I've sent you a PM with the new definition files.