[F-Req] Controller Emulation in lue of Direct Controller binding

[Merith-TK]

Is this request related to a bug?

Not to my knowledge,

Describe the request.

I noticed that the gamepad config screen supports the DPAD mappings, which is what lead me to this idea

Since from what I have gathered directly binding a controller to the game is not feasible, why not create a middleman handler simular to how the launcher is now?

have an option to instead of Remap say BUTTON_A to KEY_SPACE, a toggle that is just "emulate mapping", where pojav exposes a emulated controller to the game. Which would allow controller support mods (such as controllify) to add support for pojav launcher's controller implementation.

Anything else?

Controlify uses a forked Native Library for interacting with controllers, and even has dedicated steamdeck controller support, making it by far one of the better controller support mods on the platforms (cf/mr), so much so that a semi-popular mod/modpack, legacy4j/Re-Console, has a option to use Xander's SDL library instead of the default one. Because it tends to work better.

Exposing a emulated controller, as stated above, would allow Xander and/or other modders to build a library/mod meant for interacting with pojav's emu-controller, which would allow for mod/modpacks like the one stated, to work on the go with controllers like the Backbone,

[artdeell]

SDL is a beast and would be rather cumbersome to integrate, as it supports so, so much more than just controllers. The problem with exposing an emulated controller is that each mod chooses its own approach to talk to it. Some older mods use the LWJGL2 built-in Controller oir the jinput library, some use the GLFW controller, some use SDL. Providing and maintaining an impelementation for all of these would take far too much, especially considering the much more severe issues that the launcher has at the moment.

[Merith-TK]

The idea behind the "emulated" controller was that a mod would have to add their own support for Pojav's implementation, wether it be LWJGL2, GLFW, or SDL, the basic idea remains the same. Effectively "opening the door" for modders to take advantage of

Pojav implements a way for the user to choose to use the emulated input,
Pojav exposes the "emulated" controller in a way a mod could reasonably detect and hook into
Controller Mod Devs hook into these values and use them.

Doesnt even need analog support to be honest, I would gladly take 4directional movement on my phone if it meant I could actually use a mod that was built from the ground up to redesign the entire game to use a controller supported UI (like how legacy4j rewrites damn near every vanilla menu to support the same style and controls as old Legacy/Console edition of minecraft)

[artdeell]

Convincing anyone to actually do that is pretty hard, though. If you want to try, sure. I will implement a driver if I can negotiate a common spec for this kinda stuff with someone

[isXander]

I, Controlify dev, would happily and in a flash implement support for Pojav if this was possible.

Could you not have a virtual XInput Xbox 360 driver like many do? Is x-input windows only? Surely there's already a standard you can virtualize?

[AHHHHHHHHHHRU]

We all need controlify in pojav The menu speed is pure garbage and the game sensitivity it even worse

[artdeell]

I, Controlify dev, would happily and in a flash implement support for Pojav if this was possible.

Could you not have a virtual XInput Xbox 360 driver like many do? Is x-input windows only? Surely there's already a standard you can virtualize?

Checked some stuff again, main issue with controlify specifically is that when something fails when loading SDL, it will crash the game. Other than that there should be no blockers on our side, we can just implement a GLFW gamepad

[Merith-TK]

Kinda true? Unless it's pojav specific. If legacy4j and controlify are next to eachother it will hang when loading SDL Controller libs. (As in, game will keep running but it never leaves the loading bar screen and the last thing to ever show in logs is the error from legacy4j that the library is already loaded) So I think the SDL crashes are implementation specific with the error handling Sent from Proton Mail Android

…

-------- Original Message --------

On 12/26/24 3:25 AM, Maksim Belov wrote: > I, Controlify dev, would happily and in a flash implement support for Pojav if this was possible. > > Could you not have a virtual XInput Xbox 360 driver like many do? Is x-input windows only? Surely there's already a standard you can virtualize? Checked some stuff again, main issue with controlify specifically is that when something fails when loading SDL, it will crash the game. Other than that there should be no blockers on our side, we can just implement a GLFW gamepad — Reply to this email directly, [view it on GitHub](#6400 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ACPQOXQ3MB3YTEVEQYNBMPD2HPRRNAVCNFSM6AAAAABUA2DQZ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRSGQ4TSMJSGQ). You are receiving this because you authored the thread.Message ID: ***@***.***>

[artdeell]

Kinda true? Unless it's pojav specific. If legacy4j and controlify are next to eachother it will hang when loading SDL Controller libs. (As in, game will keep running but it never leaves the loading bar screen and the last thing to ever show in logs is the error from legacy4j that the library is already loaded) So I think the SDL crashes are implementation specific with the error handling Sent from Proton Mail Android

It's pojav specific, controlify won't start properly because JNA has failed to initialize while loading the narrator

java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.NativeLibrary
        at knot//dev.isxander.sdl3java.jna.SdlNativeLibraryLoader.loadLibSDL3FromFilePathNow(SdlNativeLibraryLoader.java:34)
        at knot//dev.isxander.controlify.driver.SDL3NativesManager.tryOfflineLoadAndStart(SDL3NativesManager.java:96)
        at knot//dev.isxander.controlify.Controlify.askNatives(Controlify.java:461)
        at knot//dev.isxander.controlify.Controlify.finishControlifyInit(Controlify.java:323)
        at knot//dev.isxander.controlify.Controlify.initializeControlify(Controlify.java:224)
        at knot//net.minecraft.class_310.handler$zzf000$controlify$initControlifyNow(class_310.java:3133)
        at knot//net.minecraft.class_310.method_51736(class_310.java:743)
        at knot//net.minecraft.class_310.method_53465(class_310.java:731)
        at knot//net.minecraft.class_310.method_29338(class_310.java:714)
        at knot//net.minecraft.class_156.method_17974(class_156.java:656)
        at knot//net.minecraft.class_310.method_53522(class_310.java:709)
        at knot//net.minecraft.class_425.method_25394(class_425.java:135)
        at knot//net.minecraft.class_757.method_3192(class_757.java:540)
        at knot//net.minecraft.class_310.method_1523(class_310.java:1341)
        at knot//net.minecraft.class_310.method_1514(class_310.java:922)
        at knot//net.minecraft.client.main.Main.main(Main.java:267)
        at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:480)
        at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:74)
        at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23)
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native [in thread "Render thread"]
        at knot//com.sun.jna.NativeLibrary.<clinit>(NativeLibrary.java:90)
        at knot//com.mojang.text2speech.NarratorLinux$FliteLibrary.loadNative(NarratorLinux.java:67)
        at knot//com.mojang.text2speech.NarratorLinux.<init>(NarratorLinux.java:18)
        at knot//com.mojang.text2speech.Narrator.getNarrator(Narrator.java:41)
        at knot//net.minecraft.class_333.<init>(class_333.java:19)
        at knot//net.minecraft.class_310.<init>(class_310.java:687)
        at knot//net.minecraft.client.main.Main.main(Main.java:250)
        ... 3 more