G-Series Gaming Keyboards

[MemphiZ]

Thats exactly what im working on right now. Is it possible to assign a key in the gaming software to "null" and only give it a label?

[bystander]

---

MemphiZ wrote:

Thats exactly what im working on right now. Is it possible to assign a key in the gaming software to "null" and only give it a label?

---

Possible, but not simply.  You have to create  Multi-key macro, then delete the actions out of the macro.

[josick]

@bystander : "I like to visually see the layout."

It's because of that, i use table as select case.

Like in my example :

ref_table = {
[1] = function() --key1 --> E
		PressKey("lshift","e") ReleaseKey("lshift","e")
		OutputLogMessage("E\n") 
		end,
[2] = function() --key2 --> num2
		PressAndReleaseKey("num2") 
		OutputLogMessage("\tnum2\n")  
		end,
[3] = function() -- key1+key2 --> ctrl e
		PressKey("lctrl","e") ReleaseKey("lctrl","e")
		OutputLogMessage("\t\tctrl-e\n") 
		end,
}

 As I use  a simulation of a chord keyboard (not with two keys, but with six), this presentation is nice for me.

With two keys, you have three possibility, but with three -->7... and with six, I use only 29 possibilities.

The number of the first key is 1,

2 for the second key, 4 for the third,... and 32 for the last (6).

If I use the first three keys, the result is 1+2+4 = 7

In my exemple, it was the value of max.

And when all the six of my virtuel chrod keyboard are released, I make a treatment : 

ref_table[max]()

The () at the end of ref_table[max]() is because you call a function (in this cas without parameter).

This is little explanation of my coding (sorry with my very bad english) -for answer to MemphiZ : "For the style I prefer "bystander"'s code because I think its easier to understand."-

[bystander]

While I could do the same thing pretty easily, it still requires a lot of typing for every game I setup.  I just find it easier to setup my hotkeys in macro form, and if I want to do something special, I break out my scripting template which allows for all sorts of stuff, including the ability to read keyboard events, coroutines, timed events and what not.  Due to using this primarily for gaming, I don't do many multiple keystroke scripts.  The only one I've written was at the request of someone else who wanted to type similar to how you type on a phone dialer.

The last reason is that when I'm learning to play a new game, I like to see the layout of my G13 in the way LGS displays it.  It just feels easier for me.  That's not to say I have never gone all Lua script.  For Rift, I had a complex script that kept track of cool downs, global cool downs and had my skills in a priority list, so if I pressed multiple skills at once and held them, it would use the skills at the right time in the priority I setup.  Ultimately it was a little too close to cheating, so I stopped using it, but it was fun to code.

[josick]

@bystander : I understand. In fact, I use an excel sheet and excel macro for produced my tables (in lili2.lua).

And I have a command for actualise :

["actualiseTable"] = function ()
    ClearLog()
    dofile(pathfile.."lili2.lua")
    OutputLogMessage("Actualisation\n")
end,

Just for info :  I'm just discovered the lgs820 (nice interface) et searching why my coding don't walk on this new version. In Legacy, PressKey accepte empty string

string=""
PressKey(string,"e")

 lgs820 don't accept string empty. 

[kgober Logi Guru III]

this is what I do to make it easy to manage my keybindings even though I use Lua for everything:

Map[1] = {
    [1] = {fn_Multi, "lshift", "1"},
    [2] = {fn_Multi, "lshift", "2"},
    [3] = {fn_Multi, "lshift", "3"},
    [4] = {fn_Multi, "lshift", "4"},
    [5] = {fn_Multi, "lshift", "5"},
    [6] = {fn_Multi, "lshift", "6"},
    [7] = {fn_Multi, "lshift", "7"},
    [8] = {fn_Multi, "1"},
    [9] = {fn_Multi, "2"},
    [10] = {fn_Multi, "3"},
    [11] = {fn_Multi, "4"},
    [12] = {fn_Multi, "5"},
    [13] = {fn_Multi, "6"},
    [14] = {fn_Multi, "7"},
    [15] = "tab",
    [16] = {fn_Cycle, 0, Cycle1},
    [17] = {fn_Cycle, 1, Cycle1},
    [18] = {fn_Cycle, 0, Cycle2},
    [19] = {fn_Cycle, 1, Cycle2},
    [20] = "v",
    [21] = "m",
    [22] = fn_G22,
    [23] = "b",
    [24] = "c",
    [25] = "spacebar",
    [26] = "up",
    [27] = "right",
    [28] = "down",
    [29] = "left"
}

Map[2] = {
    [1] = {"lctrl", "lshift", "f1"},
    [2] = {"lctrl", "lshift", "f2"},
    [3] = {"lctrl", "lshift", "f3"},
    [4] = {"lctrl", "lshift", "f4"},
    [5] = {"lctrl", "lshift", "f5"},
    [6] = {"lctrl", "lshift", "f6"},
    [7] = {"lctrl", "lshift", "f7"},
    [8] = {"lctrl", "f1"},
    [9] = {"lctrl", "f2"},
    [10] = {"lctrl", "f3"},
    [11] = {"lctrl", "f4"},
    [12] = {"lctrl", "f5"},
    [13] = {"lctrl", "f6"},
    [14] = {"lctrl", "f7"},
    [15] = "b",
    [16] = "y",
    [17] = "p",
    [18] = "g",
    [19] = "k",
    [20] = "v",
    [21] = "escape",
    [22] = fn_G22,
    [23] = "b",
    [24] = "c",
    [25] = "spacebar",
    [26] = "up",
    [27] = "right",
    [28] = "down",
    [29] = "left"
}

Map[3] = {
    [1] = {fn_ClickSeq, 1},
    [2] = {fn_ClickSeq, 2},
    [3] = {fn_ClickSeq, 3},
    [4] = {fn_ClickSeq, 4},
    [5] = {fn_ClickSeq, 5},
    [6] = {fn_ClickSeq, 6},
    [7] = {fn_ClickSeq, 7},
    [8] = {fn_ClickSeq, 8},
    [9] = "2",
    [10] = "3",
    [11] = "4",
    [12] = "5",
    [13] = "6",
    [14] = "7",
    [15] = "tab",
    [16] = "f1",
    [17] = "f2",
    [18] = "f3",
    [19] = "f4",
    [20] = {fn_ClickRun, 3},
    [21] = "m",
    [22] = fn_ClickCtl,
    [23] = "b",
    [24] = "c",
    [25] = "spacebar",
    [26] = "up",
    [27] = "right",
    [28] = "down",
    [29] = "left"
}

I make a lot of use of Lua's type() function to determine what type a value is (a number, a string, a table or a function) and to handle it appropriately.  simple keybindings are as simple as assigning a string naming the key to press, or if there are multiple keys I assign a table that contains a list of keys to press.  if I want to do something special, I assign a function instead (optionally with arguments to be passed to it, if the function is the first element in a table).

this allows me to keep everything in Lua (more convenient for me than having some functionality defined in the Logitech GUI, and some of it in Lua, it works better for me to have all of it in one place) without the burden of having to write code for every little thing.

-ken

[kgober Logi Guru III]

and because I know the question will be asked, here's my OnEvent function:

function OnEvent(event, arg, family)
    if event == "PROFILE_ACTIVATED" then
        InitPolling()
    elseif family == "lhc" then
        if event == "G_PRESSED" then
            local mode = GetMKeyState(family)
            local map = Map[mode]
            local action = map[arg]
            local t = type(action)
            if t == "function" then
                action(event, arg, family)
            elseif t == "table" then
                local f = action[1]
                if type(f) == "function" then
                    f(event, arg, family, select(2, unpack(action)))
                else
                    PressKey(unpack(action))
                end
            elseif t == "string" or t == "number" then
                PressKey(action)
            end
            Map[0][arg] = action
        elseif event == "G_RELEASED" then
            local map = Map[0]
            local action = map[arg]
            local t = type(action)
            if t == "function" then
                action(event, arg, family)
            elseif t == "table" then
                local f = action[1]
                if type(f) == "function" then
                    f(event, arg, family, select(2, unpack(action)))
                else
                    ReleaseKey(unpack(action))
                end
            elseif t == "string" or t == "number" then
                ReleaseKey(action)
            end
            map[arg] = nil
        end
    end
    Poll(event, arg, family, st)
end

-ken

[bystander]

Those are pretty nice ideas.  I'm not sure I want to do it for everything, but it is pretty nice how you did it.  Heck, Maybe I could setup something similar, even for my limit use method, or maybe I'd go all in, copy pasting one script to the next may actually be faster.

About those fn_functions, are they predefined functions or will it work with any function you apply?  I'm assuming the number(s) following the function within the { } are variables the function will take.

The more I look at kgober's setup, the more I like that concept.

[h0rse]

hi ken ..

this is a very nice script!!

i did something similar, by assigning functions to each key like gL.G[12].p = function(self)...end. gL.G[12].r = ...

your script is more userfriendly providing the type function for keystrokes (normally about 50% of my keys) and i love the way you assign the release "on the fly" - which solves a lot of problems.

- but how do you handle a key that does different stuff on the release-event?? (you would map it to a function - i guess?).

- what i also came across is that you might temporarily assign a different mapping on a key-group (e.g. thumbstick G23-29). A sort of "Sub-Map". it should inherit the other key-setup (e.g. G1-22). i did workaround this by copying the current Map-Table (e.g. Map[5]) "on the fly" assigning a new index (e.g. Map[1005]) and overwriting the new keys (G23-29). to "unload" this Sub-Map i would simply run the "Master-Map" (Map[5]) again. it gets a little more complicated when you have several Sub-Maps running ...

do you have such an option? if not how would you handle this?

anyways, very inspiring!!

[kgober Logi Guru III]

yes, anything that's not handled by the 'normal' setup is done via a function.  if you look at the way the functions are called, you'll see that they all take the usual (event, arg, family) arguments, plus any additional arguments I may have specified.  so each function is able to use event/arg/family to make further decisions about exactly what to do (for example to do something different on release).

if I had to implement submaps, how I do it would depend on what exactly I was doing and why.  in general, I try to do as little work as possible to get the result I want, but "as little work as possible" is a long-term definition, and it includes avoiding rewriting older code that wasn't quite flexible enough for new requirements.  so I'll often write more code than I need right then and there, with the expectation that the extra features will find some use in the future, and the assumption that it is less work to code it now than to code a partial solution now, then have to rewrite it to be more flexible later.

I do have a few submaps right now, but because of the particular way that I use them, I can put them into small tables, for example:

Cycle1 = {
  [1] = "f1",
  [2] = "f2",
  [3] = "f3",
  [4] = "f4",
}

 and I write a function that knows what to do with those tables, which I invoke using something like:

Map[1] = {
  ...
  [16] = {fn_Cycle, Cycle1, 1},
  ...
}