kenlon

For things that are simply tweaks to existing things in game, this may make some sense. However, it very often verges on being capital C Clever. "Here's this thing, can you understand why we did things this way without hints?" When dealing with something new - like a new powerset that doesn't do things quite the same as the existing powersets for an AT - then some design notes would make feedback more useful, and make players less likely to feel they're being ignored. For example, if Arsenal Control had been explicitly described as intentionally seeking to use sleep powers instead of aoe immobilize, then there wouldn't be several pages of posts saying "just add an AOE immob already, why are you ignoring feedback?"

I just came to this thread to post the exact same idea - having the bomb go off when the target enemy dies just feels like a smoother experience to me.

Maxing out a character with IO sets is something that can be done over time, rather than in one single expenditure, so it doesn't *feel* as expensive. I suspect that's the root of some of the complaints. Personally, I have no issue with there being some ludicrously expensive cosmetics, just an observation on where some of the objections may be coming from.

The suggestion for having the bonus kick in when you have five different ATs on the team has come up repeatedly, and I think it's a good one. Devs, is there a technical reason that this wouldn't work? If it's something that would be a giant pain to implement, then I'm not going to keep pushing for it, but otherwise it's really a better way to encourage team variety than requiring certain ATs based on very fuzzy "roles".

I would like to echo this - multi-spawn is fine, multiple instances of Tar Patch not so much.

The sad part is, if this had been called something like "Archetype Diversity Bonus", it probably would have gone over fine. But people saw "role" as constraining what the archetypes could do, and started flipping out.

If you have a problem with the new Council, you can change difficulty settings. Because that's what they are for. People who want the Council to not be complete pushovers do not have the option to go to higher difficulty than +4/x8.

I take that back - I had a messed up inspiration popper bind, and when I went to fix it, I discovered that I can no longer bind key combos - trying to bind Shift+Space results in it just binding Space.

0.13.2 seems to work fine for me. Also, if you're looking for a really handy python syntax checker, check out black: https://github.com/psf/black I've found it to be very helpful.

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.