My fellow Ximmers, connect your kb direct to the T2

[antithesis]

I've taken the plunge into the deep end of T2 scripting lately and have learned a tonne in the past few weeks. One of those things is that connecting a kb direct to T2 instead of the Xim increases its functionality tenfold. Every key on the board becomes usable for combo or macro bindings and it opens up completely new gameplay possibilities.

For example, I got back into The Division, mostly because it was previously such turd with a Xim that it was an unfulfilled challenge to get it playing friendly with m/kb. Rapid-fire and anti-recoil would lag it out by a couple of seconds and weapon wheels were unusable with a Xim. Over the last week, I've managed to overcome all of these obstacles and it's now highly playable with m/kb.

I've got some pretty funky stuff going on, like 1-second loadout swaps (blocked during combat by the game), 1-button weapon swaps (works in combat), hold Grenade button to rotate through the wheel, 1-button consumables (I could never use these or grenades before with a Xim), auto-sprint, auto-mark, auto-scope, auto-pulse etc and have removed half of the controller bindings in the process. It makes all the stuff that was buried in menus and wheels accessible at a touch and The Division feels much more customisable and PC-like.

I've bound or modifier-bound all of these functions to keys 1-10 on a Z-Board Fang, or tied things like auto-pulse, auto-mark, sniper mode & auto-scope on ADS, auto-sprint & faster turns on W etc. It plays like a dream... Modifiers like Shift, Ctrl and Alt expand the number of available keys, so even a keypad like the Orbweaver has hundreds of potential combinations, all without affecting in-game button functionality in the slightest.

By including the keyboard.gph header in a script and viewing the output via J2K's example built-in keyboard functions GPC, it's very easy to find the keys to bind to in-game buttons, while leaving the rest at your disposal as combo calls. I now have only four mouse buttons bound on the Xim, the rest of the bindings have moved to the T2-connected kb, or have been made completely redundant.

The biggest challenge I'm facing is supporting controller users. I'm a Ximmer first and foremost and my scripts are written for m/kb, so that'll be the core focus from now on and they'll be much more feature-rich as a result. I'll largely leave the controller stuff to those who use them, or pump out separate controller versions if the script is good enough to warrant it.

Long story short, I strongly encourage you to disconnect your kb from the Xim and plug that sucker into the T2 (note that G13 is not yet supported on T2, but it's coming). It's so worth it and you'll miss nothing in the process. There is a little bit of work to setup bindings on T2, but that can largely be managed by creating Input Translators and simply dragging them onto the T2 script. More complex stuff like binding combos to keys does require the keyboard header, but it significantly opens up your options.

This is everything I needed to make my Z-board Fang work on T2 (no Input Translator required) -

Code: Select all

 
#include <keyboard.gph>
 
init {
 
//------------------------------------------------------------------------------
// KEYBOARD BINDINGS
 
    // Load Keyboard Mapping to reproduce FANG layout
    const uint8 map[] = {
        KEY_W,                STICK_2_Y | KEYMAP_NEGATIVE, 
        KEY_A,                STICK_2_X | KEYMAP_NEGATIVE, 
        KEY_S,                STICK_2_Y, 
        KEY_D,                STICK_2_X, 
        KEY_ESCAPE,            BUTTON_1, // PS4_PS
        KEY_PAUSE,             BUTTON_2, // PS4_SHARE
        KEY_CLOSEBRACKET,      BUTTON_3, // PS4_OPTIONS
//                            BUTTON_4, // PS4_R1
//                            BUTTON_5, // PS4_R2
//                            BUTTON_6, // PS4_R3
//                            BUTTON_7, // PS4_L1
//                            BUTTON_8, // PS4_L2
        KEY_M                  BUTTON_9, // PS4_L3
        KEY_V,                BUTTON_10, // UP
        KEY_LEFTALT,                 BUTTON_11, // DOWN
//                            BUTTON_12, // LEFT
                                   BUTTON_13, // RIGHT
        KEY_LEFTSHIFT,        BUTTON_14, // TRIANGLE
        KEY_F,                BUTTON_15, // CIRCLE
        KEY_SLASH,            BUTTON_16, // CROSS
        KEY_LEFTCONTROL,            BUTTON_17, // SQUARE
        KEY_OPENBRACKET,            BUTTON_18, // TOUCH
                                 BUTTON_19, // LTOUCH
                               BUTTON_20,  // RTOUCH
    };
    keymapping(map);
}
 
main {
 
//------------------------------------------------------------------------------
// KEYCODE
 
    // Output the key code of pressed keys
    output_keycode();    
 
//------------------------------------------------------------------------------
// LOAD-OUTS
 
    // Use && key_status(KEY_LEFTSHIFT) etc as modifiers to increase available toggles
        if(key_status(KEY_1))      { combo_run (Combo_1); }
        if(key_status(KEY_2))     { combo_run (Combo_2); }
        if(key_status(KEY_3))        { combo_run (Combo_3); }
        if(key_status(KEY_4))    { combo_run (Combo_4); }
        if(key_status(KEY_5))     { combo_run (Combo_5); }    
        if(key_status(KEY_6))     { combo_run (Combo_6); }
 
} // main
 
//------------------------------------------------------------------------------
// KEYBOARD SUPPORT
// view pressed key
void output_keycode() {
    static uint8 previous_keycode;
    uint8 keycode;
 
    keycode = key_get();
    if(keycode != previous_keycode) {
        if(keycode) {
            printf("Key Code: %02X", keycode);
        }
        previous_keycode = keycode;
    }
    return;
}
 
 

If you can understand all that, then you'll know it needs to be cut up and placed in the correct sections of your script...nothing difficult there.

Note how some bindings are missing, simply because a few are still on the Xim (L1,R1,L2,R2), or I no longer need them as those functions are either automated in the script or called via kb keys instead. You have to adjust your thinking from which button to press to which function you want to use and bind the keys to your preferred layout. That can make for some big changes to a game's default layout, but ultimately it's a better user experience.

I plan to further experiment to see what we can do with a mouse. Sensitivity stuff is already an option, so sprint turning, ADS and HIP shooting sensitivities that stack on top of Xim sensitivities is already an option, but there's also deadzone stuff we can play with on T2 that have long since been removed from Xim.

I'll post a quick video of some of the stuff I can do in The Division when I get a chance (going camping with the fam for the next week).

Titan Two is an amazeballs product that fits hand in glove with a Xim and J2K is a bona-fide genius. We've only just begun to scratch the surface of what this man and this device are capable of. The T2 scripting community is starting to mature a year into the beta and some incredible stuff is starting to be produced. Expect to see a lot more of it come retail release of the T2.

[Scachi]

Feel free to upload your enhanced "The Division" script to the library.
Would be cool to see a more "xim based users" version available,
and I would be happy to clone some ideas of yours back to my division script ;-)

[antithesis]

Ooh, I just realised we can quadruple-bind buttons, if we really wanted to. Two on the Xim, multiple more on a T2-connected kb.

There's still some rust to knock off the Division script. I've just about wrapped up the functionality, but there's no IC and no individual weapon settings yet (aside from basic rapid-fire and anti-recoil based on weapon slot).

I think I'm going to struggle to fit the bytecode limit without loading presets from another slot as the script is already sitting at 75%, with some bloat.

Let's encourage J2K to help with loading pmem from another slot (I did see it in the documentation, but I'm unsure of how to implement it). Loading presets from a second GPC has the biggest potential of any mod and I can't wait to see a solution. I'm sure we'd all like to see the Bluetooth module too, so there are clearly higher priorities

[J2Kbr]

wow ... this is really cool. Very happy to see you exploring the potential of the Titan Two.

On a note for the G13, the update released last Sunday add support for it. However, differently of it seems, the G13 is not a keyboard like device, but a HID joystick. For this reason the inputs from it can't be accessed using the keyboard builtin function (i.e. key_status). Instead, all buttons and analog stick are mapped to the GPC designators, much like a regular gamepad. Everything is accessible, but button remapping may be required to configure the G13 to specific needs.

Related to access pmem from another slots, I suggest use the pmem space dedicated to the Test and Debug. The memory slot number in this case is 255, use with pmem_load(255) and, if needed, pmem_save(255). this will avoid potential conflict with other scripts the user may have on different memory slots.

[jayjack]

Crazy seeing you coders concerned about the bytecode limit of the T2.
When it was announced/released, seemed like everyone was impressed over the limits of the T1.
Sure shows the great development for the device.

I need to get my kb skills up.
I've been playing Halflife and Bioshock on the PC for training.
Will be tough replacing the NAV controller I love.

Also, anyone play both The Division and Wildlands?
I have no interest in The Division but Wildlands is on sale and I might pick it up.
I'm wondering if that would be a good candidate for kb as well.

[antithesis]

The concern about bytecode is because we're no longer supported just one, two or three weapons, but potentially hundreds. The more complex the script, the more complex the UI and the more pmem it eats. I can fit everything I need into a script for my personal use and edit values on-the-fly, but making it easy-to-use for those not comfortable in an IDE is a different kettle of fish.

It'll be far easier to load an external, editable GPC stacked with weapons and have the end-user adjust values there than muck around with adjusting one weapon at a time, which largely prohibits loadout experimentation in-game. Personally, that's a little bit out of my depth, but once I see a working example of pmem_load and pmem_save, that'll expedite the process.

We're really close to pumping out some killer scripts. Anti-recoil has come along in leaps and bounds thanks largely to xenologer. bonefisher and sky have add their own flavour there, as well as writing a great RPM-based rapid-fire mod. And now we're talking about loading up to hundreds of weapon presets into scripts so all the end-user needs to do is plug-and-play...it's an exciting time for modders!

[Scachi]

Regarding hundreds weapon presets : viewtopic.php?f=23&t=6967

[antithesis]

And let's not forget Scachi and his pmem acrobatics! I'm still trying to wrap my head around your Division script, there's some pure gold going on in the code

[Scachi]

And let's not forget Scachi and his pmem acrobatics! I'm still trying to wrap my head around your Division script, there's some pure gold going on in the code

After looking (and borrowing) some code from your Destiny2 script, you are doing very fine yourself
The biggest difference in handling the array stuff seems to be I am loading all three weapon slots data into a array where you are saving them to a variable.
I can easily switch between the data to use by changing the index of the array according to the active weapon slot, without needing to copy around some data first.
It also allows my weapon data load function to be reused, as I only need to add some pmem offset for the next weapon slot to the current pmem value.
Like

Code: Select all

pmem_read(1+slot*offset,antirecoil[slot]);

I think my approach may save some bytespace, where yours looks more easier to understand.

I love your code commenting style/usage. It takes up some space but makes it really easy to understand what you are doing in each place. My code looks like a mess compared to yours.

[antithesis]

I need to get my kb skills up.
I've been playing Halflife and Bioshock on the PC for training.
Will be tough replacing the NAV controller I love.

There's no need to replace the Nav, just plug a keypad into the T2 and keep the Nav on the Xim. The benefit of attaching directing is really just the extra buttons on-hand for combos and macros.

I love your code commenting style/usage. It takes up some space but makes it really easy to understand what you are doing in each place. My code looks like a mess compared to yours.

I'm mostly fumbling around in the dark and need to comment the code to follow along with what I'm doing! I'm getting there and am understanding functions, switches, consts, arrays etc better, but there's no real underlying knowledge or plan, I just poke around and see what happens