emersonrp

Saturday at 05:31 PM

I've gone ahead and released the Power Selector feature officially as v0.33:

https://github.com/emersonrp/bindcontrol/releases

Also in there is a scheme to pre-cache a lot of the powerset and incarnate icons in the background as BindControl loads. This should result in *significantly* less delay when first popping up a menu that contains icons, like a PowerPicker. Previously, the lag between clicking the button and seeing the menu sometimes was a couple of seconds. It should be much much much more responsive now in those situations.

As always, please give feedback and report bugs either here or in the Github issues page.

Friday at 11:52 PM

Already been doing some UI cleanup to the Power Selector.

https://github.com/emersonrp/bindcontrol/releases/tag/v0.33-maybe-test2

Friday at 04:06 PM

Two releases to note:

First, I've gone ahead and officially released the edit-default-profile logic, even though I'm not 100% happy with its level of polish. It works as best I can tell, so I'm wanting to get it out there more for people to poke at:

https://github.com/emersonrp/bindcontrol/releases

Secondly, I've released a very early (but working) test of a new "power selector" feature on the General tab. You can now pick which powers from each powerset / pool your Profile has, and that'll inform things like PowerBinder's selection of powers etc. This is optional, and if you leave it untouched, everything should act the same as it always has. I'm not in love with the UI yet, so any input on improvements to that is especially welcome, but as always, let me know what y'all think!

https://github.com/emersonrp/bindcontrol/releases/tag/v0.33-maybe-test1

Edit to add: This is what the new UI elements look like - the checkbox list/menu is a popup spawned by the little buttons to the right of the powerset pickers.

October 10

And since I'm throwing things at the wall, I've just released a VERY experimental stab at editing the default profile. It's ugly and crufty and wants a lot of love before I call it released, but I wanted to get it out there where people (@kenlon) could fiddle with it and see. It shouldn't be dangerous in any way apart from possibly blowing up your existing / saved default profile. I mean... at least not any more dangerous than v0.32.1, which is itself pretty bleeding-edge.

You'll want to read the release notes before fiddling with it.

https://github.com/emersonrp/bindcontrol/releases/tag/very_experimental_default_profile_editing_test

October 10

I've gone ahead and released the "Escape Configurator" as v0.32.1, along with the /wdwsave and /wdwload additions, and a few cleanups and bugfixes to the v0.32 Profile rework.

https://github.com/emersonrp/bindcontrol/releases

October 7

49 minutes ago, kenlon said:

Yeah, my assumption was it would be separate, I was just using the name. Which I probably should have clarified. Maybe make "Edit defaults" one of the available buttons at startup and go from there?

That's an interesting first step. There's currently no actual way to edit the Default Profile, as I'm sure you've noticed in all this, apart from make a new profile, make changes, and resave as default. Longish ago, the Default Profile was actually a "Default.bcp" file that was treated specially based on the name, but people kept accidentally loading it and tinkering with it when what they were after was making a new profile. The whole flow is better than it was but not perfect or great yet. Having a special "working with the default profile" mode sounds a little fiddly to try to create, but is probably a good idea. Would have to do things like disable the normal "save" and "write binds" and so forth.... Hmm.

October 7

5 minutes ago, kenlon said:

Yeah, doesn't matter what you call the "default". I named my default profile to "base binds" which seemed appropriate to me, since all the other profiles are build on them.

I mean, I'm wondering about more than a naming thing -- like, whether there wants to be a functionality for "merge these changes with a base profile" that's separate from "set defaults for new profiles" which still seems like a desirable thing. The notion of Profiles in general was originally that they might be more modular like that, but it's never actually worked that way in practice, apart from the notion of "Load a different profile's binds" which is squirreled away somewhere in PowerBinder, and that's not really what we're talking about, at all.

I could imagine a scheme where there's a separate entity from a full Profile that you can load/import that would just splat on top of whatever's loaded . Then you'd load up your Base thing and apply your various overload/merges and save each one. That isn't as elegant as the business you're talking about, I think, where a profile is auto-updated when its base is? Still trying to get my head around how that might work mechanically and UI-wise, but it's a fascinating exercise.

October 7

3 minutes ago, kenlon said:

I ended up binding ESC to "/wdw_load" (after saving the window layout I want to use to Homecoming/settings/live/wdw.txt with /wdw_save) since I use the same layout for all characters. I used a custom bind, since your wdw save/load option uses wdwsavefile/wdwloadfile and I don't need separate window layouts at the moment. Just FYI.

Oh yeah I can make PowerBinder know about wdwsave and wdwload, for sure. Not sure why I didn't in the first place, probably UI laziness.

3 minutes ago, kenlon said:

Another thing, the "default profile" being just a regular profile that you then use when creating new profiles has some drawbacks. If I add a new bind (custom or otherwise) to my default, or change one of my custom binds, I have to either recreate all my character-specific profiles or make the change to all of them myself.
What I would really want, as an end user, is the following:

(*snipped description)

I see where you're going with that, and I wonder whether it wants to be a separate notion from the Default Profile. I have certainly ever thought about the fact that BC saves the -entire- Profile every time, even the values of controls you haven't populated etc etc. That's a deliberate decision, at least so far, so that if, say, you configure a bunch of speed-on-demand settings, and then turn off the "Enable SoD" checkbox and save, it doesn't get rid of all your historical setup. It is a little heavy-handed, though.

3 minutes ago, kenlon said:

From looking over the code, that would be a bit of a pain to implement (at the very least), but I figured I'd at least mention it, given that you're already mucking around in the "which powers does this profile actually have" bits of Bindcontrol. The simplest way to do it, seems to me (though it may not be the best), would be to change up the file format so that each bind entry has an additional field that marks whether the bind is profile-specific or not. If the bind is from the default, not profile specific, then when opening the profile BindControl will update those binds to whatever the default has been changed to.

It would be a pain, but I'm intrigued enough to mull it pretty seriously. It's certainly within the realm of possibility to mark each bind as "explicitly set" versus "part of a default profile" or the like. Again, I'm thinking that this might be a separate notion from Default, though. Base Profile? I guess I'm wanting not to make things stop working as expected on the one hand, but I see your pain in updating many profiles when you want to make the same change in each one. Hmm. I'm going to think about this a bit more.

October 6

And, because I'm wanting not to let things sit around and get stale, I've already rolled up the first beta-quality version of the "Escape Configurator" Wizard as v0.32.1-test1. It works fine as best I can tell but might want some UI / UX fiddling and/or functionality expansion. Check it out:

https://github.com/emersonrp/bindcontrol/releases/tag/v0.32.1-test1

October 6

I've gone ahead and made this into an official v0.32 release. There are a few wee fixes from -test6, so go ahead and grab it.

https://github.com/emersonrp/bindcontrol/releases

Release Notes:

This release radically reworks the internal representation of the
Profile, making it separate from the UI state. This allows it to be
tested without instantiating the UI, which will make it easier to avoid
certain classes of bugs and regressions.

This release has seen six test releases which were extremely helpful in
finding issues with it, and now seems stable and workable. Please of
course file bugs if you find them.

Change notes from v0.31:

Giant rework of storage of Profile data, as described above
Many many many updates and additions to the pytest-based test suite
"Remove default team select binds" option on Gameplay tab when using
the Combined Team/Pet Selector binds
Default Profile will now be honored / used when importing a buildfile
New "Getting Started with BindControl" link on default start page to
try to surface the wiki / documentation a bit more.
"Miscellaneous Helpful Binds" on the Gameplay Page were simply not
being written out, and now are.
Added support for powexec_location to PowerBinder's "Use Power"
command.
It is now possible to bind "ESC" with the KeySelect dialog;
previously trying to do this would simply close the dialog.
Better flow adding a Custom Bind; several paths to weird behavior
have been cleaned up.
Multiple malformed / incomplete binds on the Custom Binds page will no
longer each throw a separate warning dialog when writing binds;
instead there will be a single dialog with a list of such binds
Many more tiny updates and fixes that didn't merit individual notes at
the time.

October 5

Also cooking in a branch:

Not in love with the UI yet, but it's being an interesting exercise.

October 5

Just released -test6, which fixes a couple of weirdnesses that would happen if you canceled adding a custom bind, and generally streamlined the "add custom bind" logic.

https://github.com/emersonrp/bindcontrol/releases/tag/v0.32-test6

October 4

19 hours ago, kenlon said:

I was considering binding ESC to the close all windows option, so I was curious about binding it.

You got me all inspired:

Coming soon....

October 4

OK, I've just released a -test5 version with those two changes: bindable ESC key, and support for powexec_location in PowerBinder's "Use Power" command. The latter was a little hairier than I'd originally expected because I needed to provide UI for the various options for powexec_location, which I'm not 1000% happy with but it's better than nothing; also I had to gate all of that behind "if Homecoming" logic since Rebirth doesn't (yet?) have that slash command.

Speaking of Rebirth, the server picker on the General page was not working at all and everything was Homecoming. I've fixed that, I believe. Rebirth players let me know if anything's weird with that.

https://github.com/emersonrp/bindcontrol/releases/tag/v0.32-test5

October 3

5 minutes ago, emersonrp said:

That's mostly the latter - the game handles binding ESC kinda weirdly, iirc, so I never dug into how to override the default toolkit behavior and capture ESC in the keybind dialog. If you have a use case for that, and I suppose you do or you wouldn't be asking, I can look into making that possible.

Wow OK, I have misremembered some of that. Apparently long long ago I explicitly grabbed ESC to close the KeySelect window and had forgotten in the intervening years. All I have to do is undo that, basically. So yeah, that'll be in -test5 for sure.

Also now pondering adding an "Escape Wizard" that offers up a set of things one might want to do with the ESC key, like unselect, unqueue power, close extraneous windows, maybe a couple others, in a simpler UI. Possibly I'm just looking for things to do with the Wizard functionality that's just got the one thing so far.

October 3

1 hour ago, kenlon said:

Saw you had a v0.32-test4 tagged, so I checked it out. The Incarnate powers are bindable now, but I ran into a small issue. PowerBinder doesn't have /powexec_location so I had to do it as a custom command. (I bound my Lore pet with "/powexec_location me" so they'd just drop at my feet in one click.)

Oh yeah that's just an oversight. I'll add that in.

1 hour ago, kenlon said:

Edit: Additionally, is there a particular reason that ESC is unbindable, or is it just because hitting ESC to close windows is the default assumption of BindControl?

That's mostly the latter - the game handles binding ESC kinda weirdly, iirc, so I never dug into how to override the default toolkit behavior and capture ESC in the keybind dialog. If you have a use case for that, and I suppose you do or you wouldn't be asking, I can look into making that possible.

October 2

25 minutes ago, kenlon said:

Found an issue with test3: If you try to bind Incarnate powers, it doesn't quite work right. Example: the preview bind string for Ageless Core Epiphany is "powexectoggleon <class 'type'> Core Epiphany".

Yeah I just found that one earlier today, too. I have a fix out in the main branch already, so it'll be part of -test4 whenever that happens, maybe tonight.

Also, out to the side, working on the business of importing the actual power picks from buildfiles, and using them to inform the PowerPicker popups and eventually things like movement power defaults.

October 2

3 hours ago, kenlon said:

I really wish I knew what about your setup keeps getting the exe flagged by Defender. It's heuristic, since it's always a 'ml' detection. How are you packaging this?

EDIT: I did just update the defs in the hopes that a new set would have clue, but no luck.

Oh, it's PyInstaller, it's always PyInstaller. I even wrote up a thing about it: https://github.com/emersonrp/bindcontrol/blob/main/Help/MalwareWarnings.md

Not that that helps in any way. It's so completely aggravating, especially since I have explicitly pinned the version of python and of pyinstaller in the build script, so that they shouldn't be changing and confusing Windows Defender.

Interestingly, on my Win11 laptop that I'm shackled to this week, I didn't get any malware warning with -test3, even when I explicitly scanned the folder. My Windows Defender virus defs here are 1.437.261.0, dated today, 10/1. Not that this should be a big deal, as PyInstaller 6.10 has (mostly) worked with Defender for months.

If you're feeling extra adventurous, the "Running From Source" instructions in the README on GitHub can get you working with the raw Python source which will sidestep this entire problem completely, but it is more fiddly than just downloading release ZIPfiles.

October 1

10 hours ago, kenlon said:

Nope, this doesn't work, sadly.

Yeah, boy, that was just not the right thing at all, was it? OK, there's a -test3 out there now, where it -does- work, at least to a first approximation. There might still be a little weirdness because mashing one set of profile data on top of another is actually a bit more fiddly than I'd like. Check it out.

https://github.com/emersonrp/bindcontrol/releases/tag/v0.32-test3

September 30

OK I have released a -test2. I'm about to climb on a plane and be out of the loop until evening, so I'm just tossing this out there to see. Release notes:

New "remove default team select binds" checkbox. This is smoke-tested
but still might react weirdly with different / changing "Keybind
Profile" settings.
Bugfix: Various keybuttons were simply not getting fully initialized
from the Profile data -- frankly I'm not sure how anything was working
at all, but it should be working better now.
Untested: Honor Default Profile when importing buildfile. This
should just work fine, but because of time constraints today, I can't
test it adequately. Check it out.
Updated test_icons file to the new --forked version since I'm running
pytest --forked by default now.

https://github.com/emersonrp/bindcontrol/releases/tag/v0.32-test2

September 30

9 hours ago, kenlon said:

Honestly, you make a good point. Just having a checkbox for "Clear any existing team selection binds" would probably split the difference nicely.

As a first pass, that works.

Cool, I'll try to roll those up for -test2.

Edit: Oh I see that I already did the "no default movement key" thing for -test1.

September 30

7 hours ago, kenlon said:

Found a bug with v0.32 - if you do "Import saved build" it doesn't bring in any of your default profile settings. (And I did a "save as default" with my basic profile in 0.32 in case anything had changed with how it was saved in the ini file). Doing "new profile" inherits settings just fine.

Ah good catch, yeah I'll get that for a -test2. I'm probably doing things in the wrong order during Profile initialization.

September 29

I have released v0.32-test1, which contains the immense rework of the Profile data, as well as dozens and dozens of other changes around the edges. It's almost certainly buggy. Check it out if you feel brave, and report bugs as you find them.

Important: BACK UP YOUR PROFILES. This release changes almost everything about how the Profile Data are handled in code, and so the chances of bugs accidentally altering your Profile in undesirable ways are pretty good.

Let me know your luck with it. I'll be continuing to test it myself, and releasing further -test releases as we go.

https://github.com/emersonrp/bindcontrol/releases/tag/v0.32-test1

September 29

8 hours ago, kenlon said:

Hell, I'll throw my self on the unexploded refactor, whenever it's ready.

Muahaha. I'll probably roll up a -test1 of that in the next day or so. It's extremely likely to have bugs both gross and subtle, so be sure to back up your Profiles. The deep innards of how Profiles are represented inside BindControl have changed -drastically- and so has the logic for reading, writing, and parsing the profile files. That said, the actual -format- of the Profile files hasn't changed, so it should cheerily read and write files that v0.31 can use. Probably.

September 29

I've gone ahead and re-released -test5 as v0.31.0.1 just to have a new 'latest' release out there. There's no change from -test5 apart from the version number.

Sign In

Profiles

Forums

Events

Store

Articles

Patch Notes

Posts posted by emersonrp