Jump to content
The 20th Anniversary Event is now live!

emersonrp

Members
 View Profile  See their activity

  • Posts

    58

  • Joined

  • Last visited

 Content Type 

Everything posted by emersonrp

  1. emersonrp
    Finally got around to tinkering with this. The .ini file itself is fine, but it did show me that if the prefs are set to load the last profile used, and something goes wrong with that step (like, say, the profile file simply not being there), bindcontrol will crash. So it's possible your profile was missing or corrupt, then when you removed the ini file, bindcontrol no longer had the path to that missing/corrupt profile, and started up just fine. That's all I can come up with so far. I'm fixing that issue so bindcontrol will recover gracefully to a blank profile if something goes wrong. Thanks!
  2. emersonrp
    One other thing worth trying - I suppose it's possible either the preferences file or your current profile has become corrupt in some way the program doesn't like. I -believe- it should recover gracefully from that situation, but you might try setting those files aside to see if it suddenly decides to launch. The preferences are in %APPDATA%\bindcontrol.ini and the profiles are, by default, stored at %USERPROFILE%\Documents\bindcontrol\ If you discover this is the case, please send me the file that causes it to misbehave. Thanks!
  3. emersonrp
    OK, that's strange but let's dig in and see what we know. Sorry I'm being a little slow right now, real life is intruding a bit. I'm going to try to roll up a version that will dump error output to file and see if that helps. If you're comfortable trying it, you could use the "install python and wx, clone the repo, and run it from the command line" scheme to launch the app, and it should let you know right there what's happening, but no worries if you don't want to go down that rabbit hole. I'll let you know if and when I get a test version rolled up; please let me know if you do try the more complicated approach.
  4. emersonrp
    Nono, no worries, wanting to hear peoples' luck with this. I'd been working with another person offline who'd had some trouble like this, but I'd thought 0.13.6 fixed up that whole class of problem. Clearly I was wrong. First thing I'd ask is whether you are installing BindControl on top of itself, ie, unzipping the different versions into the same folder? I'd like to say that shouldn't be a problem, but I don't think we're actually there yet. Be sure you delete the BindControl folder between installs. It doesn't keep any state in that folder by default, so unless you've explicitly saved profiles or binds in there, it should be safe to do. Let me know if that helps, and if not, I'll move to roll up a version that does some spammy logging to a file so we can see what might be happening. I'm also going to look into whether I can roll a proper installer that will do that for you instead of making people delete and unzip over and over. Thanks for the report.
  5. emersonrp
    Released v0.13.4 which is just a repackaged 0.13.3, once again using pyinstaller as the packaging mechanism. Apart from the packaging and associated scripts, it's identical to 0.13.3, so don't worry about upgrading if that one is working for you. https://github.com/emersonrp/bindcontrol/releases/tag/v0.13.4
  6. emersonrp
    Released 0.13.3 which, at least on my rig, fixes the key combo problem. Please let me know. https://github.com/emersonrp/bindcontrol/releases/tag/v0.13.3
  7. emersonrp
    Aah yeah something broke during the merge of the controller support. I will get on it. Looking forward to being able to test changes better, but that's going to be several weeks still.
  8. emersonrp
    I've just released 0.13.2, which contains a few under-the-hood changes here and there, but most importantly is packaged with a different scheme that shouldn't cause these malware/virus false positives. BindControl lives in a folder in a ZIP file now, which will be the way of things moving forward. Please let me know your luck. Though I've done some basic smoke testing, it's not impossible that it simply doesn't work outside my environment, in which case please fall back to the nearly-identical 0.13.1 and open a github issue for me. Thanks, all. https://github.com/emersonrp/bindcontrol/releases/tag/v0.13.2
  9. emersonrp
    Oh ugh. This is an occasional problem with Windows Defender and Pyinstaller, the "make a windows executable" system I'm using. I'm going to investigate alternatives to that because that's just embarrassing. Meanwhile, I've scanned the 0.13.1 exe, as downloaded from Github, with Windows Defender using today's virus/malware definitions (1/17/2024 11:01am), and it came up clean, so it's possible the pyinstaller people have their latest version of stuff correctly identified in the latest MS definitions? I'll keep an eye out for this more, going forward, and look for alternatives to pyinstaller. Thanks for the heads-up.
  10. emersonrp
    Quick bugfix to non-speed-on-demand "back" key: https://github.com/emersonrp/bindcontrol/releases/tag/v0.13.1
  11. emersonrp
    I've gone ahead and folded the controller changes into the main branch, and released an official 0.13. Not completely sure that the controller changes are working as desired yet, but I'm needing to get more eyeballs on it to be sure, so I'm glad to hear you're interested. Thanks! https://github.com/emersonrp/bindcontrol/releases/tag/v0.13
  12. emersonrp
    Bugfixes galore: https://github.com/emersonrp/bindcontrol/releases/tag/v0.12
  13. emersonrp
    What does it do instead? Do you have the typing notifier or custom colors or both enabled? Does it put anything at all in the chat window? What does the bind in reset.txt say? These three are fixed in git and will be in the next release. This also surfaced a bug where often it wasn't possible to do multiple mod keys in a bind, ie, "SHIFT+CTRL+S" or the like. That also is fixed. I'll roll up a new release in the next day or two.
  14. emersonrp
    These two things might be related. I am on it. Ah that's a good one, I already understand what's going on there, but getting it to act the right way may take a little tinkering. There's a whole balance between remembering hidden controls so they don't lose state, and accidentally writing them to the binds files. Oh this is a regression -- when the button labels get too long for the buttons, ie "SHIFT-PRINTSCREEN" or something, I have it change SHIFT to S, CTRL to C, and ALT to A, and use smaller text. So where the display says "S+SPACE" it actually means "SHIFT+SPACE". -EXCEPT- that it's supposed to store the actual state and write that to the bind files and to the Profile, and instead it's storing/writing the display string. I will re-fix this. I'll also maybe change it to be "Sh+SPACE" in the display so it's a little less confusing. Thanks for testing. Oh also: I'm going to keep looking at whether there's a way to make this work more smoothly because yeah that's a little irritating.
  15. emersonrp
    I've just released version 0.11, rolling this movement power updates into an official release to get more eyeballs and testing. Please check it out and let me now your luck. https://github.com/emersonrp/bindcontrol/releases/tag/v0.11
  16. emersonrp
    OK, looking at the 'F' behavior, I think it's related to the notion CityBinder originally had, and that BindControl has inherited, of "Blast Off," where if you hold down the F key when toggling flight mode on, it launches upward until you release it. In tinkering, I feel like tapping 'F' triggers blast off, then releasing it triggers the stationary/Hover state, but if the tap and release happen too fast, it ends up with both Fly and Hover activated because of lag. If you hold down 'F' for just like half a second, you end up launching upward a little bit, but then releasing it does the right thing. Is this the case for you? Just trying to decide whether I'm on the right track here. It might be that "Blast Off" is a corner case that nobody wants to use, and removing it could simplify the code and the binds a bit, but if it's actually useful, I'll try to figure out how to make it work better.
  17. emersonrp
    Excellent. Yeah I'll track down the "F" behavior; I do want all of that to act right. Thanks for checking it out. Let me know if you find anything else. I've been doing a bit more tidying up and polishing of the code, though still not any sort of major refactor, but I'm planning to release it as the official version here in a little while, since, at the very least, Speed on Demand is no -more- broken.
  18. emersonrp
    Try it out! Given my very light testing, I think it is doing the right thing as far as toggling Hover and Fly in particular. I still need to test it out with other movement powersets, and with some of the alternate movement powers like, say, Mystic Flight. It also seems a little laggy but that might just be the laptop I'm currently confined to. Anyway, please check it out and file issues on github as y'all find them. Hopefully we're on our way to making Speed on Demand work as intended in a post-issue-27 world. https://github.com/emersonrp/bindcontrol/releases/tag/movement-0.2 Edit to add: Also briefly checked it with Super Jump + Combat Jumping and it works fine.
  19. emersonrp
    This is actually some very helpful guidance. The innards of the SoD code in BindControl are a python port of the original lua innards of CityBinder, which are themselves an adaptation of the original BASIC code released by Gnarly, lo those many years ago. It's been fairly untouched in its logic since early CityBinder, and is like 1500 lines of twisty passages, all slightly different. The code that actually outputs the bind strings is called in every possible permutation of travel powers and options, so it's the same 25 lines, packed with inscrutable looping config, that format the hundreds of bind strings depending on what your default SoD mode is, or whether or not you -have- hover, or if you're doing jump-vs-combat-jump, or teleport, or non-speed-on-demand Sprint, or or or or. Any quick change to that area of the code is gonna require *rigorous* testing to make sure it doesn't destroy the universe. That said, the original code does have a fairly modular notion of calling powers by name versus using toggleon and toggleoff. For Fly, it's using the by-name code path and relying on the mutual exclusivity to twiddle the states of Hover and Fly. If we're all extremely fortunate, it'll be possible to tinker the inscrutable config to force it down one path or another. I am starting to look at what it would take to get Hover-vs-Fly to use the toggleon/toggleoff path and see if that magically just does the right thing without making any actual changes to the output code. If we're less lucky, I'm basically going to have to dismantle and rebuild like 25% of this 1500 line giant nested loop, which will take a -lot- of tinkering. All of that to say, this might be a complete yak shave, still, but your testing with the powexectoggleoff etc was extremely helpful in guiding my thinking, and has me at least hoping this might be a fairly straightforward fix. I'll be poking at it on and off over the coming days and will hopefully have either something to show off or sad head-shaking reports of dismal failure by the weekend or early next week. I still only have spotty and occasional access to the game so it's also possible I'll just make some changes, roll up an alpha build, and let y'all test it for me. Thanks again for doing some of the legwork on this.
  20. emersonrp
    Yeah it almost certainly relies on that behavior. I'm seeing this as a bit of a technical hurdle, as a given bind can only manipulate one power, typically, so the SoD stuff won't be able to toggle both Hover and Fly, for instance. In a scheme that works post-27, it'll probably have to be that the player is expected to turn Hover on and leave it, and the SoD binds will simply toggle Fly on and off. This doesn't give -quite- the same endurance savings as the original behavior, but it may just need to be that way. I'll be able to tinker with this some in the next couple of days.
  21. emersonrp
    Not currently near a machine where I can actually play the game to look at this, but I wanted to reply: That's almost certainly a case of not having gotten around to it. The SoD stuff is basically unchanged in design since Gnarly's binds came out like 20 years ago. They almost certainly don't work as designed post-issue-27, and that's on the TODO list for sure. The SoD code is so tangly and fragile that I have a bit of fear getting into it to change behavior, but it needs to be done. So, to make sure I understand, though, what you're wanting is that here in a post-27 world, the SoD stuff works the way it used to, ie, toggles between Hover and Fly, or at the very least leaves Hover running while toggling Fly; and then mousechord can be left non-SoD for minor adjustments in combat and inside missions etc. And currently, instead, it's doing something undesired with turning Hover on and off? Again, not near a machine where I can test it for the next several days, but wanting to understand what it's doing wrong ('cause it almost certainly is doing several things wrong in the post-27 world). Thanks for the feedback, and I'm hoping I can get around to making SoD less broken here in 2024. BTW, a few months ago I released a preview of some initial work on including some of the post-27 power changes into the existing code, which can be found on Github: https://github.com/emersonrp/bindcontrol/releases/tag/movement-0.1 ...but this won't address your issue almost certainly.
  22. emersonrp
    "Real Soon Now" is now. I have just released controller prerelease 0.2, which has working-but-fiddly support for modifier binds like "LTrigger+Joy2" and the like. Please read the release note for more info. https://github.com/emersonrp/bindcontrol/releases/tag/controller-0.2
  23. emersonrp
    Ah cool, I was originally developing with a Logitech F310, which I assume works similarly under the hood. Discovered that a bunch of the problems I was having with Windows was that the controller itself is faulty (though Linux seems to handle it fine) -- moving to an actual XBox 360 controller fixed up all my Windows issues, though this actual controller is old and decrepit and has some trouble registering some button pressed sometimes, ugh. I'll maybe grab an F710 just to have a modern working controller for this. Ow yes that sounds awful. Don't worry about collecting extra hardware unless you're really excited about it. I plugged in a PS3 controller and it mostly Just Worked in Linux (don't get me started about how Linux behaves better with old hardware than Windows ever did or will) so I'm guessing that layers like XInput are going to make this pretty portable. If you're on fire to try it out with a bunch of different hardware, though, I'm totally happy to hear reports. That's where I was angling, more stuff in the "preferences" dialog, or maybe a separate controller tab in that dialog, to select the /controller_modifiers and/or /extra_modifiers which will then act as Mod Keys in the key-picker-dialog logic. I'm redoing the latter to be smarter and more general with some success, so I expect it to be possible to bind, for instance, "Joy9+Joypad1" using the controller inside BindControl, Real Soon Now. For the moment, I have the six controller buttons/triggers you mentioned hard-coded as mod keys but yeah exposing some UI for that will be next up once it's working. And then, the "Write Binds" button currently offers up a copyable "/bindloadfile" line to paste into the game; I'll make that include multiple lines with the /controller_modifiers etc incantations, as appropriate. I think this can be all pretty smooth. The only part that's still a big question mark is the larger issue of binding more than one thing to a function, which as I said, is a longstanding low-priority feature failure that I'd like to figure out someday. Conveniently, I have a bunch of free time right now after the holidays, so I'm being all on fire to get this done. 🙂
  24. emersonrp
    I've put up a release with rudimentary controller support, just as a proof of concept. It needs plenty of work -- it's certainly not capable of creating most of the binds in your document yet -- and plenty of testing, I'm sure. Let me know your luck. https://github.com/emersonrp/bindcontrol/releases/tag/controller-0.1
  25. emersonrp
    Oh this is fantastic for working on possible use cases, thank you! What controller are you using? I ask because all I've been working with so far are a couple of XBox 360-flavored controllers, and they're a bit of a hassle with wx, the toolkit that BindControl uses. I have my controller working perfectly well now, in Linux, but it requires a little bit of a kludge, and in Windows the same code doesn't work and is going to need to be modified. I also start to suspect, from my initial Windows tinkerings, that the dpad on this controller is simply not supported in wx in Windows. So I'm thinking I'm going to have platform-specific and controller-specific code in there, which is going to be a bit of a headache but I'm game to try. Hopefully most controllers are going to fall into a few general classes that I can support. I also have access to PS3 controllers, and I'm not averse to getting a more modern controller or two, to tinker with this. Oh I also have Steam Controllers but I think they're such strange beasts that they oddly might not be helpful here. Also, looking at your setup, I'm discovering I'm going to need to do a little bit of internal restructuring of BindControl -- it currently thinks of "Mod Keys" and "Keys" mostly separately because of how wx keyboard events work, but there's a lot of combinations of buttons and bumpers and triggers in your examples, so I'll have to make a more general case for combining inputs that doesn't have strong opinions on what qualifies as a "Mod Key." Finally, there's a longstanding UI concern that I might need to address finally -- currently BindControl has one spot to pick, for instance, the bind for Forward, even though the game of course supports binding any number of keys or buttons to +forward. So, this is an existing feature failure -- BindControl can't bind both "W" and "Up Arrow" to +forward (or, more interestingly, to the Speed-On-Demand versions of "Forward"), and this is just made more apparent when we add controller support into the mix. Thanks again, this gives me a lot to think about and work with. If I can get this 360 controller working in Windows, I may release a beta for you to play with and see whether it works at all in your case or whether I have a lot more work to do. 🙂
×
×
  • Create New...