[HL] Implement gamepad connected/vendor/id and fix float value conversion

[MoritzBrueckner]

This PR implements gamepad.connected, gamepad.vendor and gamepad.id on HL, and fixes wrong axis and button values due to the previously missing conversion between floats used by Kinc and doubles used by Haxe.

I would also really like to implement the mentioned gamepad properties for Armorcore, but since Armory uses Kode's version of Kha (plus some minor adjustments Lubos manually applies after each update which I can't influence with a PR) this means that I would also need to implement the changes for Kode/Krom to make Kha work in all cases, but Kode/Krom doesn't build at the moment... @ Rob it would be awesome if you can implement the gamepad properties for Kode/Krom so that adding these to Kha's Krom backend would work correctly independent of whether Krom or Armorcore is used.

---

Slightly off-topic question: for gamepad sticks, how should the y-axis behave? Should a y value of 1 correspond to "stick up" or "stick down"? Currently the y axis seems to be inverted on html5 compared to all the other targets: https://github.com/armory3d/armory/issues/2886#issuecomment-1728450149.

[RobDangerous]

Sorry but I won't work on Krom any time soon. But shouldn't be too hard to do something that returns default values when Krom doesn't have some property. For the y direction please open an issue.

[MoritzBrueckner]

Hi, sorry for my late answer.

Sorry but I won't work on Krom any time soon.

What about moving the current main branch to another branch then and restoring Krom's old main branch (is the chakra branch still up to date with the last working non-node version?)? This way there's at least a working version available (and it's the default version), and changes to it can be migrated to the node-based Krom branch once that is ready.

But shouldn't be too hard to do something that returns default values when Krom doesn't have some property.

If working on the non-node Krom version is not an option, there are a few possibilities (each with their own disadvantage). Which one do you prefer?

• Run-time reflection (slow, although it might not matter in this particular case)
• #if armory check (inverted dependency, Krom should not depend on Armory code)
• A custom compile-time reflection macro (complicated to implement, and I'm not even sure whether it's possible at all since Haxe might not know about all class fields at macro evaluation time)

Armory would still need to provide its own Krom.hx in all those cases, but that's no big deal.

Simply adding a default implementation in Krom.hx doesn't seem to work, it causes a runtime error Krom.xyz is not a function.

[RobDangerous]

Simply use the chakra branch, no need to make it the default branch for that. But isn't Armory's Krom very different by now anyway and an #if armory check therefore useless?