I'm using Sphere 1.5 and I can't get any code whatsoever to run on an entity's On Activate Talk. Any given code will work fine On Touch and On Create, but not On Talk. I have D, S, E and W on the keyboard configured to be the A, B, X and Y buttons respectively, and I've tried them all to no avail.

I presume I'm missing something obvious, like some API command I need to call or something.

press spacebar or enter.

press spacebar or enter.

I hope this is fixed to be "default button 1" or something in alternative implementations? Space as default makes no when you remap things...

But I have Sphere configured to use DSEW. Why don't those work?

Damn, you have only one input key for talk, and it is not a Sphere configurable control. There is an API function you can use to change it:

Code: (javascript) [Select]

SetTalkActivationKey(keycode);

Which only accepts a keyboard key, mind you. Not sure what one would do with controllers with that function. I believe controller does react on button 1, but that can't be changed in code (in case you wanted to), only in config.exe.

To be frank, maybe we just need to look at the entirety of input handling. There's so much that could be handled better or just be more flexible: handling press/release states, having a single scheme that would provide both keyboard and controller input at the same time, handling different inputs for different players, setting mouse velocity speed and locking it in the window, etc.

Which only accepts a keyboard key, mind you. Not sure what one would do with controllers with that function. I believe controller does react on button 1, but that can't be changed in code (in case you wanted to), only in config.exe.

SetTalkActivationButton is in the API.

To be frank, maybe we just need to look at the entirety of input handling. There's so much that could be handled better or just be more flexible: handling press/release states, having a single scheme that would provide both keyboard and controller input at the same time, handling different inputs for different players, setting mouse velocity speed and locking it in the window, etc.

Definitely! Even in the config you can only set keyboard keys, despite the fact you can set certain Joystick Button keys in the API. I think the entire input API definitely needs as second look at. Plus the Joystick backend in vanila Sphere is pretty bad, the L/R triggers only half work, you can use one or the other but you can't hold down both at the same time - it reads that as if none are pressed. (They should be individually controlled).

Damn, you have only one input key for talk, and it is not a Sphere configurable control. There is an API function you can use to change it:

Code: (javascript) [Select]

SetTalkActivationKey(keycode);

Ugh, that's really annoying that it's not end-user configurable. I typically don't like the control schemes that people come up with, I almsot always prefer to change it. In particular, I loathe using Ctrl and Alt as game keys. Who originally came up with that idea?!

Which only accepts a keyboard key, mind you. Not sure what one would do with controllers with that function. I believe controller does react on button 1, but that can't be changed in code (in case you wanted to), only in config.exe.

To be frank, maybe we just need to look at the entirety of input handling. There's so much that could be handled better or just be more flexible: handling press/release states, having a single scheme that would provide both keyboard and controller input at the same time, handling different inputs for different players, setting mouse velocity speed and locking it in the window, etc.

Definitely. Pretty much any game I'd ever wanna make for Sphere, I'd have to create a custom input handler. And since Sphere is specifically made for gaming, that borders on unacceptable.

Plus the Joystick backend in vanila Sphere is pretty bad, the L/R triggers only half work, you can use one or the other but you can't hold down both at the same time - it reads that as if none are pressed. (They should be individually controlled).

That's because it presumably uses DirectInput, not XInput. I've run into the shoulder buttons thing in other programs (emulators mostly). DirectInput only allows one button axis, and each of the analog shoulder buttons needs its own, so they have to share an axis. XInput, which is proprietary unfortunately, allows mutliple axes.

Which only accepts a keyboard key, mind you. Not sure what one would do with controllers with that function. I believe controller does react on button 1, but that can't be changed in code (in case you wanted to), only in config.exe.

SetTalkActivationButton is in the API.

...I feel like I've been getting out of touch with the API lately. Even though it has hardly changed in years, hah.

Well, there is a lot of API to explore, too.

Plus the Joystick backend in vanila Sphere is pretty bad, the L/R triggers only half work, you can use one or the other but you can't hold down both at the same time - it reads that as if none are pressed. (They should be individually controlled).

The controller you're using might be an XBox360-compatible one, where LT/RT are treated as another set of analog axes (IIRC, Z- and Z+ respectively). Anything in Sphere expecting an XBox360-compatible joystick might have to use the joystick axis functions to handle those instead.

NEO, yes I am usng a 360 controller. There is 1 axis reserved for L/R triggers, called 'Z'. If I leave them be, Z = 1, if I move the left trigger, Z = -1, and the right trigger, Z = 1. If I move both at the same time Z = -1+1 = 0. But, Z = 0 is the idle case, so that means you can't have games that's require you to pull both triggers.

You can get the Xbox 360 controller to have separate trigger axes, you just have to use Microsoft's Xinput. Pretty sure there's a .NET thingy for Xinput, too, so you could have separate shoulder axes in Sphere-SFML.

I know people've gotten the triggers to work separately in Unity and (of all things) VisualBoy Advance, so I know it's possible. Just not with DirectInput.

TurboSphere (and Sphere-sfml?) fully support 360 controllers, also. It's not a matter of the controller and OS, it's the program itself.

You could try using higher values for the axis index in Sphere (possibly going above the reported number of axes?).