Forum


Notice to all users

We are migrating towards a new forum system located at community.teamspeak.com, as such this forum will become read-only on January 29, 2020

Page 1 of 2 12 LastLast
Results 1 to 15 of 22
  1. #1
    Join Date
    March 2010
    Location
    Tacoma
    Posts
    68

    Plugin hotkey issues

    With Direct Input going away what do you propose as an alternative for custom PTT key handlers in plugins?

    ACRE users DirectInput to capture keyboard events and do our own PTT implementation right now, so I'd like to have a good path to go down for an alternative before it is removed and we both get spammed with bug reports.

    Honestly I am not sure why our implementation requires TS to also be using it...

  2. #2
    Join Date
    October 2012
    Location
    Germany
    Posts
    553
    You can register Plugin Hotkeys as well as handle plugin commands using the API and let TS handle the triggering, I dunno why ACRE bypasses that - maybe the api function wasn't available back then?

  3. #3
    Join Date
    March 2010
    Location
    Tacoma
    Posts
    68
    Quote Originally Posted by Philosound View Post
    You can register Plugin Hotkeys as well as handle plugin commands using the API and let TS handle the triggering, I dunno why ACRE bypasses that - maybe the api function wasn't available back then?
    Is there any API documentation for the hotkey commands?

    The thing with ACRE is that we have a number of different PTT keys at once for different radios, and then of course normal PTT is used for 3D speaking.

    I was hoping to move all of our radio PTT handling out of TS and into Arma, but there is no totally universal key handlers in Arma (text boxes in in-game dialogs will steal focus from all key handlers registered).

  4. #4
    Join Date
    October 2012
    Location
    Germany
    Posts
    553
    I don't think it's described anywhere but as an example in the Demo Source in the pluginsdk Folder.
    It's pretty straight forward though. You'll have to reimplement the PTT functionality however. Luckily, both G-Key and CrossTalk are Open Source and do that, with g-Key probably being easier to read, being Std oriented, while I'm a Qt fanboy.

  5. #5
    Join Date
    March 2010
    Location
    Tacoma
    Posts
    68
    Yea, I don't think that was ever there in the original code examples, at least when we wrote the PTT engine back in 2010.

    This should just raise an event in the plugin right? If so thats all I need, I can handle everything else internally to ACRE, since we already do the mic activation/deactivation... Unless this doesn't do an event for key up and key down... if that is the case then ugh...

  6. #6
    Join Date
    October 2012
    Location
    Germany
    Posts
    553
    It's just an event, yes.
    If it's Onup or ondown is part of the User interface for setting hotkeys of the Ts client.
    If you want to even use the API function for showing a GUI Widget for Setting the hotkey instead, you'll be stuck with ondown, programmatically registering onup also a nogo. Scheduled for feature parity for one of the last Updates.iirc.

  7. #7
    Join Date
    March 2010
    Location
    Tacoma
    Posts
    68
    Ugh... People already complain ACRE is hard to set up, getting them to implement two options in the settings per PTT key is just not acceptable.

    Why remove DI... Back to the drawing board (or maybe this is an excuse to ditch TS altogether haha... ugh).

  8. #8
    Join Date
    October 2012
    Location
    Germany
    Posts
    553
    Tell me about it, had to make users set a key for on up too.
    My users have been able to cope, probably got sth. to do with me shouting it in the wiki.
    One mention though, it ain't a problem to make the keyUp universal - just remember the specific keydown in it's function and act accordingly to that value on the universal keyUp. Less of a pain, still meh.

    Reference
    Last edited by Philosound; September 19th, 2013 at 05:46 AM.

  9. #9
    Join Date
    March 2010
    Location
    Tacoma
    Posts
    68
    Also I just noticed in their default mode that Num Lock doesn't respond at all to PTT events, even the default PTT binding. Great. I use Num Lock bound to a mouse button (unbound thumb button from back in browser) and now that doesn't even raise in their default mode. That is pretty sad.

    *edit*

    Nevermind, I don't know what is going on there...

    When ACRE is on Default mode will not accept any keybindings in TS, at least for me, for some people it does.

    Argh... Yea something with our keybinding DI system breaks default mode in TS... We are still capturing our events, its just broken everything else. So confused now, haha.
    Last edited by NouberNou; September 19th, 2013 at 06:23 AM.

  10. #10
    Join Date
    June 2008
    Location
    Krün, Germany
    Posts
    510
    Hi,

    if ACRE implements its own standalone Direct Input hotkey system, why does it require TeamSpeak to implement Direct Input hotkeys as well? That should be two different, isolated systems. I may be missing some point here, but I don't see why the TeamSpeak Direct Input is required? If you select the "Default" (raw input) hotkey system in TeamSpeak, Direct Input is not even initialized.

    Anyways, as Philosound already pointed out, the more elegant solution would be to hook the plugin into the TeamSpeak hotkey system. We added this feature for the Overlay, as the Overlay originally implemented an own hotkey mechanism but we found that repetitive. So now the overlay reuses the TeamSpeak hotkey system. The idea is quite simple: A plugin registers itself for a certain hotkey. When TeamSpeak detects the hotkey press, it will just forward it to the plugin. As mentioned, the test plugin shows how to use plugin hotkeys. It sounds better to me to have only one hotkey system in the process and share its functionality.

  11. #11
    Join Date
    October 2012
    Location
    Germany
    Posts
    553
    What about the onUp issue, though?
    Any plugin that implements PTT (well, I guess besides Acre and CrossTalk, that's G-Key, making us three) would quite benefit that from a setup pov.
    I get the point mentioned in the thread, at least that part of breaking plugins that are API 19, but have inactive authors by now, it's sensible to give that some weight. On the other hand, it's been a while.

    Two non-exclusive ideas could be worth considering.

    1) An addition to the API, as opposed to modifying a function's arguments shouldn't break anything, right? I'm the first to admit that ain't super clean, but hey, it's a real world, time passes. (Having two values, api version minimum and api version current, would remove that dirtyness, though.)

    Add an addHotkey function (ui-less).
    We could (try to) read the added hotkey after requestHotkeyInputDialog and add our onUp that way.

    You know, the thing is, with "just" adding onUp and onDown to requestHotkeyInputDialog PTT-like functionality would still require us to force users to do the procedure twice for one key.

    2) Open a window of opportunity, put a sticky on the plugin forum for API requests, I'm positive some of us plugin devs would be able to find some useful requests. That change isn't required to go alone xD
    Perception wise, it may also help us third-party volunteer developers to not feel buried under new features like delayed channel deletion and straight client requests. That somewhat also goes for api bug reports, I put some in there I don't even know are read, let alone made it to the tracker. I know it's annoying to have all those users battling on which feature to do next and everything's the most important, however a simple one liner that the carrier pigeon made it to it's destination alive would already make us sleep better

  12. #12
    Join Date
    June 2008
    Location
    Krün, Germany
    Posts
    510
    Regarding onUp... Yes, good point. That is probably the showstopper for plugins implementing PTT. The fix already exists but is currently commented out. I had implemented this last year on request by Chris but we decided to postpone the feature as it did not seem us worth all the hassle with a API update. In this implementation there is a new parameter, so of course breaks the API:
    Code:
    void (*requestHotkeyInputDialog)(const char* pluginID, const char* keyword, int isDown, void* qParentWindow);
    We have a couple of other things which we need to change and will result in an API increase, so time may be good for some more changes. I would really like to avoid increasing the API with each TeamSpeak client release, then our users will probably want to lynch us (rightfully).

    One central point to collect plugin API requests sounds like a good idea. It would certainly help us to get an overview quickly. We do read the forums, but the biggest part of the time of the devs should be spent with programming. So, if you want to prepare such a central suggestions/requests/critics plugin API thread, please go ahead.

  13. #13
    Join Date
    March 2010
    Location
    Tacoma
    Posts
    68
    Quote Originally Posted by PeterS View Post
    Hi,

    if ACRE implements its own standalone Direct Input hotkey system, why does it require TeamSpeak to implement Direct Input hotkeys as well? That should be two different, isolated systems. I may be missing some point here, but I don't see why the TeamSpeak Direct Input is required? If you select the "Default" (raw input) hotkey system in TeamSpeak, Direct Input is not even initialized.

    Anyways, as Philosound already pointed out, the more elegant solution would be to hook the plugin into the TeamSpeak hotkey system. We added this feature for the Overlay, as the Overlay originally implemented an own hotkey mechanism but we found that repetitive. So now the overlay reuses the TeamSpeak hotkey system. The idea is quite simple: A plugin registers itself for a certain hotkey. When TeamSpeak detects the hotkey press, it will just forward it to the plugin. As mentioned, the test plugin shows how to use plugin hotkeys. It sounds better to me to have only one hotkey system in the process and share its functionality.
    Yep, it shouldn't but I was actually confusing the issue. The issue is that for some people (including myself) our own DI system blocks the default key handling system in TS, when using DI mode it works fine. Our key binds get registered and fired, but they never make it to TS in default. Again, this happens only to some people. I am going to dig around in it a bit more.

    The main thing about the system in TS is that it requires additional user steps to get it working. ACRE has a huge install base and we have found that even copying a DLL is difficult for a lot of them, so the less work the better. If there was an API to assign hotkeys from inside the plugin dynamically that'd be amazing.

    Also having one hot key entry both fire up and down key events would be nice, because most people, again, would be confused having to implement both.

    Basically the less people have to do themselves the better.

  14. #14
    Join Date
    March 2010
    Location
    Tacoma
    Posts
    68
    Having investigated a bit further it seems TS and our plugin conflict on keyboard events somehow.

    If I start TS with ACRE already enabled and the hotkeys mode set to Default then ACRE will get its correct keyboard events and process them fine, but TS will not get any keyboard events related to its hot key handler.

    If I then switch to Direct Input in the Hotkeys section and then switch back to Default ACRE will no longer get keyboard event data and TS will for its hotkeys.

    I assume there is some sort of conflict. When TS first starts it initializes plugins before you start your hotkey engine implementation, and that is causing a conflict when we use direct input and you use your implementation that is not based on direct input. If I change it after TS has fully initialized then it restarts your hot key engine and it now is some how super-ceding our hotkey engine.

    Any insight on this? Why would us spooling up direct input before your implementation break your implementation, and why would yours spooling up after ours initializes break our implementation?

  15. #15
    Join Date
    June 2008
    Location
    Krün, Germany
    Posts
    510
    Hi,

    I moved this discussion out of the client release thread.

    > If there was an API to assign hotkeys from inside the plugin dynamically that'd be amazing.

    Understood and agreed. Please add this to the new sticky plugin requests thread, that will make it much easier for me to remember and keep an overview.
    http://forum.teamspeak.com/showthrea...ues-Collection

    > Any insight on this?

    To be perfectly honest, I have no idea right now. But it reassures me that the idea of sharing the TS hotkey system with plugins is the better solution. So I'd suggest to rather cooperate to get the sharing working so it's usable for you than trying to figure out incompatibilites with two hotkey systems in the same process.
    Not for the next release (too soon), but for the one later. So we have enough time for proper testing.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Plugin issues
    By falconfury in forum Windows
    Replies: 1
    Last Post: March 30th, 2015, 08:08 PM
  2. Plugin to change Channel Settings with a hotkey?
    By Mike78426 in forum Client Plugins / Lua Scripts
    Replies: 0
    Last Post: August 23rd, 2014, 07:26 PM
  3. Hotkey issues
    By MinDokan in forum Windows
    Replies: 2
    Last Post: January 16th, 2013, 01:36 PM
  4. [Resolved] HotKey/Run Plugin command bug
    By Screech in forum Bug Reports [EN/DE]
    Replies: 1
    Last Post: July 27th, 2011, 04:16 PM
  5. [On Todo] Wrong hotkey command shown under Plugin
    By Meelkee in forum Bug Reports [EN/DE]
    Replies: 1
    Last Post: March 14th, 2011, 10:26 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •