gmcl_joystick - DirectInput module with simplified interface
316 replies, posted
So is the new one? Or is it still old? in the OP you said something about a new version coming last month, I assume this is not it yet.
I need a weekend to standardize the binary - I only want to make one release to ease the update process. Previous updates only changed the script. Maybe next weekend.
I still have 12 days. :3:
[QUOTE=Night-Eagle;17647249]I need a weekend to standardize the binary - I only want to make one release to ease the update process. Previous updates only changed the script. Maybe next weekend.
I still have 12 days. :3:[/QUOTE]
Glad to see you're still contributing
Cannot wait for this. The current one is soo slow behind what you are actually doing, it makes any vehicle difficult to drive with a wheel + pedals.
Are you going to release it this week? Today? right now?... please.
Hopefully soon, one of the mot useful things in gmod.
Will this fix the bug with prop protection? The "receiver" can't bind itself to the joyconfig command. If you need more info I can probably get it for you relatively quickly.
I'm not aware of a bug with prop protection.
The reason the current version sucks is a .125 second delay on the server. The new version is as fast as using Garry's numpad thruster.
Release the new version!!!!!
It's Simple Prop Protection that it doesn't work with, but I don't know what version it is either, for both, sorry.
The update you've all been waiting for:
[img]http://eagle.undo.it:8083/img/joystick_gui.jpg[/img]
Now supports 800x600 resolutions!
Did you forget a DL link?!!!?
No, my server is down.
Garrysmod.org put a ban on awesome files, so I can't upload it there.
[editline]11:45AM[/editline]
Server is back up.
THANK YOU! I will test and report back to see if it works, if not i will bring the lua error.
FINALLY! Thank you. It is up on ZeosPanteras Private Build Server for the truck competitions now.
Getting an infinite loop error on my dedicated server, but not on singleplayer. Complains about line 2 in the joyserializer.lua. The line that's like
[lua]
local serials = string.explode("", LotsOfCharactersAndSymbolsAndNumbers)
[/lua]
Thanks for your time.
[QUOTE=TomatoSoup;17819234]Getting an infinite loop error on my dedicated server, but not on singleplayer. Complains about line 2 in the joyserializer.lua. The line that's like
[lua]
local serials = string.explode("", LotsOfCharactersAndSymbolsAndNumbers)
[/lua]
Thanks for your time.[/QUOTE]
Hrm. I remember that string explode wasn't working correctly at one point, but garry fixed that months ago. Try deleting your lua includes extension folder (the one that includes the string.explode definition) then running the dedicated server update.
The actual code is:
[lua]
local serials =
string.Explode("",[[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz,.<>?:[]{}\|1234567890-=!@#$%^&*()_+]])
[/lua]
(Perfectly legal)
Well this update blows my semi-related project out of the water.
*scrunches up source code*
I'm glad actually, since this will probably work better and has already got a lot of people following it.
I wonder if the following are feasible additions
[list]
[*]Adding Mouse input, the change in position would be useful as would the mouse buttons.
[*]The ability to add a callback for when an input has changed, with parameters for the player and the new value, possibly also the old value.
[/list]
This is just the addon I needed to get into Contraption mood.
[QUOTE=Night-Eagle;17822040][lua]
local serials =
string.Explode("",[[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz,.<>?:[]{}\|1234567890-=!@#$%^&*()_+]])
[/lua][/QUOTE]
holy shit.
[lua]
local serials = {}
for p, c in string.gmatch("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz,.<>?:[]{}\|1234567890-=!@#$%^&*()_+", "().") do
serials[p] = c
end
[/lua]
Or the right way to do it:
[lua]
local serials = {"A","B","C","D","E","F","G","H","I","J","K","L","M","N","O","P"
,"Q","R","S","T","U","V","W","X","Y","Z","a","b","c","d","e","f","g","h","i","j"
,"k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z",",",".","<",">"
,"?",":","[","]","{","}","|","1","2","3","4","5","6","7","8","9","0","-","=","!"
,"@","#","$","%","^","&","*","(",")","_","+"}
[/lua]
[QUOTE=Deco Da Man;17826093]holy shit.
[i]*wall of text*[/i]
[/QUOTE]
Yes, let's save 8 picoseconds.
That's only called once per initialization.
[QUOTE=Deco Da Man;17826093]
[lua]
local serials = {}
for p, c in string.gmatch("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz,.<>?:[]{}\|1234567890-=!@#$%^&*()_+", "().") do
serials[p] = c
end
[/lua]
[/QUOTE]
You forgot backslash. ("\|")
...he comes at night, so I wouldn't go to sleep if I were you...
[editline]09:42AM[/editline]
[QUOTE=Deco Da Man;17826093]
[lua]
local serials = {"A","B","C","D","E","F","G","H","I","J","K","L","M","N","O","P"
,"Q","R","S","T","U","V","W","X","Y","Z","a","b","c","d","e","f","g","h","i","j"
,"k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z",",",".","<",">"
,"?",":","[","]","{","}","|","1","2","3","4","5","6","7","8","9","0","-","=","!"
,"@","#","$","%","^","&","*","(",")","_","+"}
[/lua][/QUOTE]
...backslash is going to be [i][b]pissed[/b][/i]...
[editline]09:51AM[/editline]
[QUOTE=fishface60;17825974]Well this update blows my semi-related project out of the water.
*scrunches up source code*
I'm glad actually, since this will probably work better and has already got a lot of people following it.
I wonder if the following are feasible additions
[list]
[*]Adding Mouse input, the change in position would be useful as would the mouse buttons.
[*]The ability to add a callback for when an input has changed, with parameters for the player and the new value, possibly also the old value.
[/list]
[/QUOTE]
I do intend to add mouse clicks, but mouse movement is a bit more of a challenge.
I guess I could track delta for one, but this may require locking the player's view.
I could track absolute direction, but this breaks into a few cases: dealing with the fact that there is twice as much yaw than pitch and what to use as the forward direction.
Perhaps the easiest way to do it is to have the binding register require the user to supply a forward frame of reference and allow the user to select between absolute and delta.
For delta, the register will lock the view towards the provided direction.
For absolute, the register will use the forward direction as the center.
I'm not sure [i]exactly[/i] how I should implement mouse movement, anyone else have an opinion on this?
[QUOTE=fishface60;17825974]This is just the addon I needed to get into Contraption mood.[/QUOTE]
Same here. :v:
[editline]09:58AM[/editline]
Oh, and there is a callback function for joystick updates:
[lua]
hook.Add("JoystickUpdate","gmod_wire_joystick",function(pl,header)
//DON'T MODIFY header, IF WE DO, ALL INPUT WILL BE FUBAR
for uid,bit in pairs(header) do
for k,v in pairs(jcon.wireModInstances[uid]) do
k:PollJoystick(pl)
end
end
end)
function ENT:PollJoystick(pl_upd)
if self.lastpoll == CurTime() then
return
end
self.lastpoll = CurTime()
local pl
if self.Pod then
if self.Pod:IsValid() then
pl = self.Pod:GetPassenger()
end
else
pl = self:GetPlayer()
end
if pl == pl_upd and IsEntity(pl) then
self.value = 0
if joystick and joystick.Get then
self.value = joystick.Get(pl,self.uid)
if self.type == "analog" then
self.value = self.value and (self.value)/255*(self.max-self.min)+self.min or 0
else
self.value = self.value and self.max or self.min
end
Wire_TriggerOutput(self.Entity,"Out",self.value)
end
else
//TODO: Reset outputs to 0 on player pod exit as option - this can be done by the player using adv pod controller and if statements
end
end
[/lua]
Header is basically a table with all UIDs that the player currently has bound.
A few important points:
[list]
[*]The table is indexed by the UID
[*]The table values probably mean nothing to you
[*]You should not change the table in any way (for efficiency reasons, the table is shared with Joystick Module)
[/list]
I'll look into making a register-specific callback.
I say you do not need mouse movement. It can easily be done within e2.
Yay new version of awesomeness!
More wire inputs buttons is a necessity, how could one survive otherwise?
[QUOTE=evan_madore;17828569]I say you do not need mouse movement. It can easily be done within e2.[/QUOTE]
The point is that this way you can have a single interface for your own customisable controls, if you went the E2 route you've got to explicitly say to do something on mouse click, whereas the Joystick module (change the name, it's got more than just joysticks in it) lets you pick any key, mouse button or joystick button to control it however you want.
[QUOTE=Night-Eagle;17828244]I do intend to add mouse clicks, but mouse movement is a bit more of a challenge.
I guess I could track delta for one, but this may require locking the player's view.
I could track absolute direction, but this breaks into a few cases: dealing with the fact that there is twice as much yaw than pitch and what to use as the forward direction.
Perhaps the easiest way to do it is to have the binding register require the user to supply a forward frame of reference and allow the user to select between absolute and delta.
For delta, the register will lock the view towards the provided direction.
For absolute, the register will use the forward direction as the center.
I'm not sure [i]exactly[/i] how I should implement mouse movement, anyone else have an opinion on this?[/quote]
Paradukes implemented some form of mouse movement for the boarding pods in SBEP by getting the mouse from the SetupMove hook
[lua]function SBEPCCC(ply, data)
local cmd = ply:GetCurrentCommand()
ply.SBEPYaw = cmd:GetMouseX()
ply.SBEPPitch = cmd:GetMouseY()
end[/lua]
I think this gives the delta of the mouse, the Boarding Pods lock the view themselves, I think it should be up to the addon maker whether to lock the view and how to implement it, so you could have a mouse look toggle.
[quote]Oh, and there is a callback function for joystick updates:[/QUOTE]
I had a bit of a look at it, it always seemed to have the values in the header as being 1 and it won't tell you which of the inputs was updated so you'd have to do your own checking to see if it was yours which updated.
Plus it was only available serverside and I can see uses where it'd be useful clientside as well.
[editline]07:22PM[/editline]
There's also a minor memory useage concern in the jcon.register function.
The catreg.getdigital, catreg.getraw ... functions are defined separately for each registered bind. This means each function
If you defined the functions outside the jcon.register function, in another table and made the catreges inherit the functions from that then the functions would take up the same memory for one bind as n binds.
The usual way of doing this is metatables.
I've made the [url=http://pastebin.com/m611e6e63]changes[/url] to my local copy to see if it works ok and I've had no errors so far.
Instead of setmetatable(destination, source) you could do table.Inherit(destination, source), this is faster to index, has a reference to its inherited table (as destination.BaseClass) and iteration will return all the values of it, but takes up more memory.
[QUOTE=fishface60;17829151]I think it should be up to the addon maker whether to lock the view and how to implement it, so you could have a mouse look toggle.[/QUOTE]
This is the part I want an opinion on. The interface behind this - think from the perspective of someone writing an interface for the Joystick module. They do joystick.Get(pl,uid) to fetch a value of an input, but how does the script know where to lock the view/the forward direction?
If you say joystick.Get(pl,uid,dir), what if the programmer doesn't really have a forward direction in mind? We could set it to the player's current direction, but what if they're making a third-person gamemode and are updating the player's direction all the time?
How does the programmer let JM know that the view should be locked?
What if the player wants to override the programmer's decision - should that be handled by JM or the programmer? Should it even be allowed?
Are we really sure we want the default behavior to lock the player's view?
Adding mouse movement functionality does complicate fetching data - how do we provide this functionality with minimum input from the interface programmer?
About the extra memory usage - eh, that's a simple fix. Define two locals in outer scope and reference 'em.
[editline]12:09PM[/editline]
I'm seeing four different types of mouse input:
[list]
[*] Delta, explicit forward (I can't think of a use for this...anyone?)
[*] Delta, locked (Apply a force)
[*] Absolute, bounded 180 pitch, 360 yaw, explicit forward (Aim a turret with player view) (This is a bit impractical to make interchangeable with a joystick input, we must consider what the user had intended to make.)
[*] Absolute, bounded 180 pitch, 180 yaw, locked (Used in Diamond Blue) (How does the user know where center is?)
[/list]
(explicit forward means unlocked with the programmer providing a forward direction as a reference)
Can we agree on this, or does someone see another possibility?
Perhaps some of these problems could be solved by mapping a joystick input to the mouse...
Another possibility is that we deal with mouse input on a per-interface basis. This could get a bit hairy, and I'd want some examples to test first.
[QUOTE=Night-Eagle;17822040]Hrm. I remember that string explode wasn't working correctly at one point, but garry fixed that months ago. Try deleting your lua includes extension folder (the one that includes the string.explode definition) then running the dedicated server update.
[/QUOTE]
Tried, still getting infinite loop.
[QUOTE=TomatoSoup;17830502]Tried, still getting infinite loop.[/QUOTE]
Does this cause an infinite loop?
[lua]
function a()
seperator = ""
str = [[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz,.<>?:[]{}\|1234567890-=!@#$%^&*()_+]]
if ( seperator == "" ) then
local tab = {}
for i=1, string.len( str ) do
table.insert( tab, string.sub( str, i, i ) )
end
return tab
end
local tble={}
local ll=0
while (true) do
l = string.find( str, seperator, ll, true )
if (l != nil) then
table.insert(tble, string.sub(str,ll,l-1))
ll=l+1
else
table.insert(tble, string.sub(str,ll))
break
end
end
return tble
end
a()
[/lua]
Or this
[lua]
function a()
seperator = ""
str = [[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz,.<>?:[]{}\|1234567890-=!@#$%^&*()_+]]
if ( seperator == "" ) then
return string.ToTable( str )
end
local tble={}
local ll=0
while (true) do
l = string.find( str, seperator, ll, true )
if (l != nil) then
table.insert(tble, string.sub(str,ll,l-1))
ll=l+1
else
table.insert(tble, string.sub(str,ll))
break
end
end
return tble
end
a()
[/lua]
Or this
[lua]
function a()
seperator = ""
str = [[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz,.<>?:[]{}\|1234567890-=!@#$%^&*()_+]]
return string.Explode(seperator,str)
end
a()
[/lua]
I'll test those in JUST a second, I have another symptom:
[code]
autorun/server/joystick.lua:179: Infinite Loop Detected!
[/code]
And the third one causes an infinite loop.
Does this string.Explode work?
[url]http://luabin.foszor.com/code/lua/includes/extensions/string.lua[/url]
If it does, copy that code into lua/includes/extensions/string.lua
Actually, I just discovered I had an addon that enhanced/added more functions, and string.Explode was one of them. I've changed the modified string.Explode to string.LongExplode (because it says it's for use with longer separators). I'll tell you how it works in just a minute.
Yeah, it works now. If anybody else has GLX and is getting errors, try removing it.
Tell whoever made that addon to look at this thread.
That's exactly why we don't make copies of anyone else's original code and release a modified version of it.
Sorry, you need to Log In to post a reply to this thread.