kenlon

Just FYI, I went to grab this to test out the changes, and it flagged in Windows Defender, as "Trojan:Win32/Wacatac.B!ml". I suspect this to be a false positive, but I thought I should mention it.

You were correct about the Blast Off bind being my issue. However, there's a few other things I've noticed: 1: For some reason, hitting enter no longer starts chat, even though it's set in the chat binds section. 2. You can't actually bind the Enter key - if you try to bind it, hitting enter just closes the bind window, instead of setting the bind to enter. 3: Deselecting a power pool hides the associated powers, but does not change the binding settings. This led to some confusion when my default profile, with no power pools selected, was causing all my windows to vanish when I hit shift. And not actually a problem, but just weird: the default inspiration popper binds have almost all of them set to SHIFT+$KEY, but resist damage is S + SPACE. I could have sworn the old Citybinder bind was SHIFT+SPACE.

Flight bind works almost perfectly, from what I can tell. The only thing is that when you first hit F to activate it, both hover and fly come on. This is not a big deal as it sorts out as soon as you move, just noting it for the record. Thanks!

Glad to be of assistance! Looking at SoD.py, I don't envy you the task of refactoring into something more maintainable.

So I did a little poking at the binds, and came up with a shell script to edit them: #!/usr/bin/env bash grep -rl "powexecname Fly\$\$powexecname Fly" * | xargs sed -i "s/powexecname Fly\$\$powexecname Fly/powexectoggleoff Hover\$\$powexectoggleon Fly/g" grep -rl "powexecname Hover\$\$powexecname Hover" * | xargs sed -i "s/powexecname Hover\$\$powexecname Hover/powexectoggleoff Fly\$\$powexectoggleon Hover/g" Basically, it found every place that the binds turned on either Hover or Fly, and edited them so as to turn off the other power before turning on the new one. This results in, for example, the F/F111000.txt bind being: A "+down$$up 1$$down 1$$forward 1$$backward 0$$left 1$$right 0$$powexectoggleoff Hover$$powexectoggleon Fly$$bindloadfilesilent C:\coh\flight\F\F111010.txt" D "+down$$up 1$$down 1$$forward 1$$backward 0$$left 0$$right 1$$powexectoggleoff Hover$$powexectoggleon Fly$$bindloadfilesilent C:\coh\flight\F\F111001.txt" F "+down$$bindloadfilesilent C:\coh\flight\F\F111000r.txt" R "forward 1$$backward 0$$up 1$$down 1$$left 0$$right 0$$powexectoggleoff Hover$$powexectoggleon Fly$$bindloadfilesilent C:\coh\flight\AF\AF111000.txt" LCTRL+R "up 0$$down 0$$forward 0$$backward 0$$left 0$$right 0$$powexectoggleoff Fly$$powexectoggleon Hover$$t $name, SoD Binds Reset$$bindloadfilesilent C:\coh\flight\subreset.txt$$bindloadfilesilent C:\coh\flight\F\F000000.txt" S "+down$$up 1$$down 1$$forward 1$$backward 1$$left 0$$right 0$$powexectoggleoff Hover$$powexectoggleon Fly$$bindloadfilesilent C:\coh\flight\F\F111100.txt" SPACE "-down$$up 0$$down 1$$forward 1$$backward 0$$left 0$$right 0$$bindloadfilesilent C:\coh\flight\F\F011000.txt" TILDE "follow$$powexectoggleoff Hover$$powexectoggleon Fly$$bindloadfilesilent C:\coh\flight\FF\FF111000.txt" W "-down$$up 1$$down 1$$forward 0$$backward 0$$left 0$$right 0$$powexectoggleoff Hover$$powexectoggleon Fly$$bindloadfilesilent C:\coh\flight\F\F110000.txt" X "-down$$up 1$$down 0$$forward 1$$backward 0$$left 0$$right 0$$bindloadfilesilent C:\coh\flight\F\F101000.txt" So if you change the bind generation code to do powexectoggleoff/powexectoggleon combos, you'll be set. And I won't have to run this every time I regenerate binds. 😄 (And would also mean I don't have to come up with versions of this for all the alternate travel powers like Mystic Flight or the PB flight powers and whatnot. )

I did try using that version, but it had the same behavior. What it does now is that fly remains turned on along with hover when stationary, despite the notification messages in chat saying that it's being turned off. I believe that it used to rely on Hover and Fly being mutually exclusive, and now that they are not, the binds would need to include an explicit turning off of Fly when switching to Hover, and vice versa.

Is there any way to get the old (pre-Issue 27) behaviors out of flight with BindControl? My desired end state is that when I'm moving, Fly is toggled on, but then when I stop it is toggled off, leaving Hover on, so I can use non-SoD mousechord movement to reposition in combat without zooming all over the place inside buildings. As it stands now, I can't see any way to get that behavior short of figuring what edits to make to the keybind files directly, which sorta defeats the purpose of a utility like BindControl. Is this just a case of not having gotten around to it, or is there a technical issue I'm not aware of?

Because I'm lazy and don't want to do it myself, I did post in the Citybinder for Homecoming thread in case Tailcoat is still watching it. From looking at the source, it's just a fix to speedondemand.lua, I think, since it appears all the logic for what goes into the binds is contained there. It's not exactly the epitome of self-documenting code.

FYI for Tailcoat: The SoD flight binds in this are broken after the travel pool changes where you can have both Hover and Fly active at the same time. I fixed my personal binds with a little bit of sed to replace the paired "$$powexecname Fly$$powexecname Fly" with "$$powexectoggleoff Hover$$powexectoggleon Fly", and the reverse for the double Hover bind upon stopping. If you're still maintaining this, I suspect it wouldn't be too complicated to fix. If you aren't, then I'll have to see if I have enough give-a-fucks lying around to fix it rather than just running a bit of bash script against my binds each time I generate them. 😄

A bit of sed magic later, I have working keybinds again. grep -rl "powexecname Fly\$\$powexecname Fly" * | xargs sed -i "s/powexecname Fly\$\$powexecname Fly/powexectoggleoff Hover\$\$powexectoggleon Fly/g" grep -rl "powexecname Hover\$\$powexecname Hover" * | xargs sed -i "s/powexecname Hover\$\$powexecname Hover/powexectoggleoff Fly\$\$powexectoggleon Hover/g" Now the question is, I suppose, do I fix Citybinder for others to use, or just modify my own keybinds when I edit them?

I know they're text files: kenlon@DESKTOP:/mnt/c/coh/flight$ grep -ri "powexectoggleon Fly" * | wc -l 257 kenlon@DESKTOP:/mnt/c/coh/flight$ Like I said, it's going to be interesting figuring out exactly what's going on internally with the Citybinder generated keybind files (and then mangling them appropriately with sed.)

I've always used Citybinder to generate the binds, which means there are literally hundreds of text files for them. This will be interesting.

Huh. I know they're in the right directory and I can load them just fine - the issue is that both Fly and Hover stay turned on at all times after I hit F to turn on flight mode. And since I don't want a) the increased end drain from both being on at the same time and b) hover's pose overriding the one from flight, that's kinda a problem. (If they weren't getting loaded, then all my other binds in Citybinder - which work fine - would be failing.)

I've just come back to CoH again, and it looks like the travel pool changes made during my time away broke my SoD flight binds - I've been using Citybinder for them since before live shut down. Does anyone know how to fix them so they behave like they used to? (Hover while still, turning hover off and fly on while moving)?

As primarily a tanker player when it comes to EM, I'd like to add a vote for moving the stun combo mechanic off of Bonesmasher and on to Barrage.

I agree with this. Because having to eat up slots on pure range boosting removes the ability to slot sets in those places. Which is a reasonable thing to complain about, if /TA's range advantage is a core part of why you liked the set to begin with.

Not really, when you think about it. Modern games are much prettier, but they also take advantage of the increased capabilities of modern hardware (and, more importantly, the APIs that such hardware supports) much more than an ancient game like CoH.

I would be very surprised if they did that - even though you can now slot Acc SOs, having the extra early accuracy compensates for the lack of slots that you have to spend on powers. I can't really see any good reason to remove it.

Out of curiosity, were the two of you taking advantage of the fact that you can buy SOs at low level now? And if so, had you slotted stamina?

Even if it wasn't originally intended, the fact that it's been that way since introduction has led to it becoming a defining feature. This is not to say that "It's always been that way," is a good reason to not balance something, but it is a good reason to take into account what a set has been when changing it. I think the extra range that /TA has is something that could be balanced against without breaking the set, and there's clearly a lot of players in this thread who would miss the range.

So, just remove the ability to light the slick - problem solved!

Then you are a far more patient man than I. 😄

When I did this (though, admittedly, I didn't do it on live, because I already *knew* how painful it was), I used a Rad/Rad Corruptor. Being able to actually hit things, having damage that wasn't utterly anemic and not running out of endurance all the time was amazing.

It makes people strive towards getting in DFB groups and skipping low levels entirely. Sure, not having SOs makes the low levels 'challenging', but that just means no one plays those levels in normal content. . . .if you think that there's too much skipping of content, then why wouldn't you be in favor of a change that makes it more likely for players to actually do 1-22 missions rather than spamming DFB? Having access to enhancements that actually, y'know, enhance (as opposed to looking pretty) makes low level play much more fun. Seriously, try this: Make a character on live. Play through the Praetorian missions from, say, 1-20. Then remake the character on the beta, and do the same there. The beta version, with SO enhancements, will still be tough (simply because you have so few powers and slots to enhance them with), but it won't feel like you're slamming your head against a brick wall anymore. Especially with a squishy AT. This is a very, very good change.

The two aren't mutually exclusive - balancing sets around "this is the standard" and then picking specific attributes to break away from that standard is far better than just buckshotting out randomly varying powersets. For an example of this, TW was OP as hell because it broke the standard damage formulas in a big way, and this patch changes that. (And does it very well, making it just a very good set with better QoL than before, rather than "worst feeling to level" and "hit 50, slot IOs, become DESTROYER OF WOOOOOOOOOORLDS!" like before.) Hopefully the devs will listen to the feedback in this thread and take Tac Arrow back into the shop for tweaking. EDIT: You know, to expand on that, it might be a good design idea for the devs to look at sets and decide, per each, which normal design rule it should break (if any). Because being explict, at least internally, about what gimmicks a set should have (from a design perspective rather than mechanics) would probably be helpful, given the sheer number of sets in the game.