Something is wrong with the feeder about node-vigemclient HOT 11 OPEN

Okay I think I found and fixed the issue. DS4 controllers have their analog stick values mapped from [-1,1] onto [0,255], which means that a "neutral" state is not actually 0 but 127. Unfortunately I overlooked this fact in the reset() method of the respective reports. This issue is now fixed and I can confirm that the analog sticks are no longer moved in the upper left corner.

One thing that I see in your code that I would definitely recommend against however is accessing or mutating any members which start with an underscore (like _report). These members are not "public" and can change at any time between updates, even patch-level updates. The controller has a built-in reset() method if you want to reset it properly ;)

One more thing: 1.4.0 also adds a reset() method to the InputAxis. The intended way to reset only parts of the report is now to use InputButton.setValue(false) and InputAxis.reset() in a loop over the respective objects (ideally while temporarily setting the updateMode to manual).

from node-vigemclient.

I didn't read through all of your code just yet, but let me try to understand what your problem is. You're creating a new feeder and are then reading the values of the axis and are then not getting all 0's for every value? That is really strange and should not happen, I'll try to reproduce your issue and then get back to you.

from node-vigemclient.

In summary :

1. When the controller first get created, the value of the left axis and right axis doesn't exactly zero ( Drifting )
2. When i move the left axis for the first time ( first buttons to be moved, the error only occur when the analog is between 0-90 degrees or 180-270 degrees ), even though i have fed the right value, the x axis will always be zero. Until either i moved out of the angle or i reuse the button. It only occur when the first time load the controller.

from node-vigemclient.

I tried reproducing your issues, and while I did find out some interesting things, I unfortunately couldn't reproduce them.

For your first issue I created a minimal example:

const ViGEmClient = require('vigemclient');

const client = new ViGEmClient();

const connErr = client.connect()

if (connErr !== null) {
	console.log("Error while connecting to the ViGEmBus driver:", connErr.message);
	process.exit(1);
}

const controller = client.createX360Controller();

let err = controller.connect();

if (err) {
	console.log("Error while connecting to the virtual controller:", err.message);
	process.exit(1);
}

controller.update(); // send an update to the driver for good measure

console.log(controller.axis.leftX.value, 
	controller.axis.leftY.value, 
	controller.axis.rightX.value, 
	controller.axis.rightY.value);

and as expected the output was 0 0 0 0. Everything else wouldn't have made any sense anyway, since those getters only ever display values from within JavaScript, so it's literally impossible for them to drift or contain values that you didn't set yourself.

For the second issue I'd be interested to hear how you actually tested that. If you simply set the value immediately as you start your application and then open the "Game Controllers" thing that Windows provides it will indeed not show anything, since that tool only shows changes that occurred after the menu was opened. If you instead set a timeout and then open the menu before the report was sent to the driver, you will actually see that first update as well.

from node-vigemclient.

I think I'm seeing a similar issue.

I'm trying to make an electron app that serves an angular web page that controls a programmable controller. I'm a big fighting game nerd, so I'm using this to create a game overlay that allows you to set up input sequences while playing any fighting game (most games have disappointing training mode options related to playback/record).

I'm mostly focused on just manipulating the reports wButtons value and that seems to be working correctly, but it seems like any update to the controller causes the axes to shift to the top-left.

On app init, I instantiate but don't connect. After calling connect, I see the controller register with window and the inputs seem valid and correct.

When I click my 'neutral' button. It sets wButtons and wSpecial to no inputs and no directions and calls update() on the controller. After this action, it loses all of the axes information and you see the axes input shift to the top right. The controller report still shows the correct values, so it seems like it's some issue with the interface to the raw vigemclient code.

I've just been using the raw windows controller tool, which is definitely pretty limited.

https://github.com/kyleryanbanks/game-ng12

All of the code is public here.

If you pull the repo > 'npm i' > 'nx serve' (wait until finished) > open new terminal 'nx serve roost' should run the app.

Click connect, open windows controller view > open controller > click neutral > see axes update.

It usually happens after the first time, but while writing this it took 2 clicks on 'neutral' at one point to get it to happen.

setNeutral() {
this.controller._report.reportObj.wButtons = 8;
this.controller._report.reportObj.bSpecial = 0;
this.controller.update();
console.log(this.report);
}

after connect - no axes

after neutral - top-right

Depending on what screen has focus you may or may not see the affect of the axes. I noticed that the axes were off after trying to open other windows apps while connected to vigem.

You can see in both cases that the controller report doesn't have any readings. This seems like it would be a pretty major issue if the root vigemclient did this after every update, so I'm hoping maybe the node interface just isn't passing all of the data correctly or something.

Thanks

from node-vigemclient.

Eventually, the plan is to have this as a transparent stream overlay and electron's already a bit heavy on resources so I'm worried about performance later on.

I want my eventual feed loop to be as thin as possible so setting the button value directly means I'm just saving and iterating over a list of numbers instead of a list of report objects and then having to build the value manually on every loop at run time. It's something like 3 functions calls per loop vs breaking apart and iterating over an object and doing up to 15 function calls per loop?

I'd be happy to get off private variables if there were an official way to set buttons and special directly instead of being forced to go through the input/axis classes?

Also, wButton = 0 gets set during reset(), but that sets the dpad to up. I'm manually setting to 8 to return the controller to a neutral state.

I don't know if the direction map is coming from you or root vigem, but I would definitely use reset() directly if it put the controller back to neutral.

Can we tweak the direction map to have 0 be no direction or reset to set wButtons to 8?

from node-vigemclient.

https://www.loom.com/share/33052a8568724353892f8e9df1be4f2c

Here's a short demo of where I stopped last night if you'd like to see it running.

Eventually I'll make some UI elements for the list so it's a bit more user friendly, but I'm trying to force myself to not get caught up on look and feel before functionality is in place.

from node-vigemclient.

Also, wButton = 0 gets set during reset(), but that sets the dpad to up. I'm manually setting to 8 to return the controller to a neutral state.

Another thing I overlooked, fixed in 1.4.1, thanks.

I don't know if the direction map is coming from you or root vigem, but I would definitely use reset() directly if it put the controller back to neutral.

The direction map was written by me and, like you said, there was a bug in it. It should of course set the dpad to its neutral state as well.

I'd be happy to get off private variables if there were an official way to set buttons and special directly instead of being forced to go through the input/axis classes?

Well, the way to set them directly is to go through the classes. The idea of this library was to abstract the report away completely so that you can focus on the actual axes and buttons without having to worry about bitmasks or the weird differences between the X360 and DS4 reports (axes always go from -1 to 1 or 0 to 1 for example instead of their native ranges).

Also I'm wondering why the performance of resetting the controller to neutral is even of that big an importance to you anyway. Usually that is not something you have to do, ever, or at the very least not very often. The way this library is intended to be used is to just update the specific buttons and axes that you want to change and then setting them to not pressed or neutral afterwards. And since you're only ever touching the axes and buttons you are actually changing for the next update, you're not iterating over all of them.

from node-vigemclient.

I'm focused on creating a UI that allows users to program controller sequences rather than individual button presses that supports 60 fps playback.

I'm essentially precompiling the button presses so that I don't have to do any of that calculation during the playback loop.

How do you suggest capturing the user inputs in a way that doesn't require me to unpack the object and call the button inputs on every frame? I want the playback loop to be as concise as possible.

Your API is great for live control, but I think it adds in overhead if you're trying to stream sequences.

from node-vigemclient.

Yea, you are not wrong. Maybe I could expose the report objects (so you can instantiate them yourself) and then provide a sendReport method, so that you could just prepare/precompile a list of reports and then send them straight to the driver one after another with almost no overhead.

from node-vigemclient.

The vast majority of my use case is probably focused around wButtons, with maybe some rare complex cases that need special or left axis.

I think still having a few options to access more low level API only makes the library more robust so it doesn't seem like there's much downside.

While I don't love the thought of carrying around lists of objects where I mainly only use one property, it would be nice to have a single call that sets the report and updates immediately. I only have wButtons wired up at the moment so it's only the one set and update, but I assume the eventual loop is set buttons, special, and maybe axis and then update, so sendReport definitely makes things a bit cleaner there.

from node-vigemclient.