Number Six

Pretty sure I know why, I think one of the other environments' turnstile servers connected to Brainstorm by mistake. I'll restart Brainstorm's and see if it helps.

Not quite because the profiles and the bindings describe it in two different ways and it's a bit more complex. The Classic profile for instance binds w and uparrow both to +forward. That gets mapped into an internal table that manages a primary and secondary binding for the command itself (the +forward part). This mirrors how things appear in the options menu and is what drives that interface, but it's also used to manage the bindings for commands that have a specific name in the profile. When you bind W to something else, the bind that gets stored in the character is a straight key to command mapping like you're used to seeing. So if you /bind W foo, "W foo" gets saved on the server in the keybinds list. The internal mapping table removes W from +forward, so the +forward command has no primary, and uparrow as its secondary bind. If you then switch to the Joystick profile, it has two binds for +forward in it: w, and joystick1_up. Those get loaded into the internal state table first, as primary and secondary. Then the game loads in your "W foo" binding on top, so it removes w from +forward, leaving just joystick1_up. If you already had a manual "W +forward" binding then it would just do nothing with that one, because W is already assigned to +forward in the table. So both W and joystick1_up would work in that scenario. That all sound kind of convoluted, but the end result is that when you change profiles it actually ends up doing what you intuitively want it to do. W will still be bound to what you told it to, and the joystick mapping from the profile works correctly.

The characters created in the last 2 weeks would disagree with that assumption. And no, the selector is not new. It was always there. Just very few people used it because the options didn't really add much, and possibly also because it was somewhat broken. Yes, you did gain more control. Now what's the in the saved file represents reality rather than some artificial construct, which gives you more control as well as visibility into what's really going on. That's important when you start running into things like the server-side limit on number of saved key bindings. Previously the common consensus around key bindings was that it mostly works, but behaves oddly at times and nobody really knew why. This is hyperbole to the extreme. Nothing is broken. All your existing hand-curated bind files still work absolutely fine and you can load them with no change whatsoever in how it works. As a bonus, you can add the KeyProfile line if you want to select a specific profile when the file is loaded, but it's optional. If you want to edit the whole list at once, you can still do that too. There's a copy of the Classic keybind list on the wiki. I posted the list from Modern on the forums (exported using that existing dev-build command I mentioned earlier) and I'm sure it will be added to the wiki soon also if it hasn't already. Copy and paste it into notepad and you're good to go. I already said we're going to add a command to export it from in-game in case those defaults ever change, so that small extra step is temporary.

No, the reason is that the bind list saving was completely broken / unfinished, and that loading that saved file back in had bad effects that aren't immediately obvious but can bite you later. The way key bindings work in this game is that there's a default profile -- which the user can select -- that provides the base layer. When you customize your keybinds either through the options menu or the /bind command, only the changes you make are saved as part of your character record on the server, then layered on top of the default. So if you change two of the default bindings, your character record on the server only has 2 keybinds, in addition to the reference to which profile you have set. This is exactly why /unbind doesn't do what you might think and instead resets a key to default, because it's removing that saved key binding which no longer overrides the default. That's why since day one you've always had to bind something to "nop" to actually make it do nothing. There's some more subtlety to that, for example the SG base editor adds another temporary layer to remap some of the keys to edit commands but be able to change them back later, but that's the basics. The bind_save command on the other hand, didn't work like that at all. It scanned through every key possible and wrote out the command for that key, mashing all the layers together and saving whatever happened to be the result. You might say, that's great, it shows me what every key does and that's what I want, so give me that! Sure, but think about what happens when you then load that file back in. /bindload and the automatic equivalent that happens when you create a new character is really stupid, it just reads the contents of that file, slaps a "/bind " at the start of every line, and executes it. Incidentally, that's why with careful use of the $$ token, bind files can and have sometimes been abused to work as longer macros -- for years I've had a "bind" file I load on new characters that issues all sorts of non-keybind commands to set up options and windows and stuff. You're loading in all those default key bindings and then saving them to your character as if you had defined them as custom binds. That works okay so long as 99% of players use the Default profile and never change it, maybe somebody uses Joystick, but that's about it. Consider this scenario however: Joey create a new character on a new account with no saved binds, they get the Modern profile by default They change 1 or 2 key bindings and hit the button to save defaults, which writes out ALL the default keys, in this case the keys from the Modern profile They create another character, load the bind file, and it creates custom bindings based on every single key It turns out they actually played COH a lot back in 2009 and really hate all this newfangled crap, so they change the profile to Classic ... nothing happens? what is wrong with this game? Turns out switching to Classic can't do anything if every single key is already overridden from the file they saved! If Joey had never used /bind_save it would have worked fine, but because they did it invisibly broke profile selection with no obvious reason why. The change to the way the file works is two-fold: 1. Adds a special token to actually save the profile to the file, which it wasn't doing before. This is specifically to make it possible to have your preferred choice of profile as the default for newly created characters without having to change it every time, and to make setting that up as easy as selecting Classic and clicking the "save to default" button that's right next to the dropdown. 2. Makes the contents of the file match what is actually saved on the server in your character. That is so that loading binds accurately recreates that state, instead of doing something completely different that just happens to kind of look the same if you squint. I can't emphasize enough that this is a fix to make the command actually do what it says it does and should have always done from the start. The only real loss is the ability to easily see the default keybinds. I don't mean to downplay that because it is an inconvenience, but that's something that can be easily addressed without breaking the whole system again. There's already a separate command to print out the current state of all the keys, just like /bind_save_file used to do, but it's locked behind development mode for some weird reason. With only a few minor adjustments that could easily be adapted to be player-usable and/or save to a file -- just don't stick the entire contents of it in your keybinds.txt without being aware that it will break profile selection!

I'm pretty sure I managed to find the crash reports @funcleb sent in (were 2 of the 3 on a character who name is a pun on a popular singer best known for hits in the 80s?)... but they're kind of all over the place. Each is in a different and seemingly random place in the graphics code, with "impossible" conditions. One was checking texture flags to see if it needs to be alpha sorted, one was calculating clip planes for Z-occlusion. The third one happened while decompressing model data from the disk files -- revalidating files may be warranted here but that's usually the first advice given out so I have to assume it's probably already been done. That kind of random behavior sounds like something may be corrupting data in RAM. It could definitely be a bug somewhere in the code and you just happen to be unlucky or really good at hitting a particular trigger, but since it's happening so frequently may also be worth running memtest just to be sure.

Sort of, the original version of it was called SummerIO and it nerfed the Bonfire and Tornado tick rates when the Overwhelming Force: KB to KD unique enhancement was slotted, using the same globalchacemod method. That was before the Sudden Acceleration set existed, of course.

Aaaand Impervium beat me by about 2 seconds!

Rookie is for parity with Villain and Praetorian starting areas, which have an exploration badge out in the open and likely to be accidentally stumbled into by new players, cluing them in that exploration badges are a thing that exists. I believe Silent Sentinel was chosen as the one to swap so that it could be moved back to its original location, before the Atlas Park changes from Issue 21. Undefeated is the other badge that was moved to a different building then, but Silent Sentinel's new location was a completely different style of building that didn't fit as well with Gargoyle.

You actually can bind it from the options menu. Go there, click on the first entry next to quicklook, then when it's waiting for a keypress don't just click but drag the game world outside of the window, like you were trying to pan around with the left button. It's not super intuitive but it does work. Failing that, you can also use this, which is the previous default: /bind leftdragworld "+camrotate$$camturn" LeftDragWorld is a new input event that fires only when dragging outside of any UI element -- necessary for that kind of control so that it doesn't interfere with left button clicks and dragging in the UI.

Try the Reset graphic settings on next run checkbox in the launcher settings and see if it helps:

A couple small fixes going on beta today, above notes are being edited to include these. Missions Striga arcs fixed to be playable with mixed alignment teams. User Interface Cleaned up a few items in the option menu that were applying clientside immediately, but not saving to the server unless some other option changed that triggered sync. Powers Fixed a bug in Dark Mastery's Tar Patch that could cause the power to sometimes fail to summon the patch.

FYI, fixes for both issues just hit the beta server, so if you want to try it there and verify if things look correct it would be appreciated!

Yes, it's not actually causing pop-in, but what's happening is the fog distance calculation is wrong*, so the fog isn't hiding the transition like it normally does. Also if you have SSAO enabled, the difference in the scene fog calculation and the separate fog calculation that SSAO does causes abrupt transitions in brightness that look like pop-in. * (the variable from the vertex program is not consistently getting passed through to the fragment program, thinking we may have hit a limit in the number of uniform variables but it's not showing up on the error console)

Thanks, it's was quite frustrating. I ended up scrapping the whole thing and re-implementing it in postprocessing. There's a couple downsides to that but nothing major -- and it works without graphical glitches, so good enough.

That one is a different issue specific to that map. A fix for it is in the pipeline and should be out soon.

Hahahaha, no, it's a complete nightmare I've been fighting for hours. out_color.rgb = calc_gamma_correction( out_color.rgb ); should work. It works fine in half a dozen other fragment programs. But in that one, it causes the fog calculation to go screwy in a way that defies logic. Reversing the order or changing random other things causes different seemingly non-deterministic behavior that makes no sense. I went so far as to rewrite how the fog is handled so I can change the order and do it the opposite way, which makes it work correctly for multiplyRegfp (yay!). But doing that somehow breaks it for colorBlendDualfp, in a similar way. And let's not even talk about the headache that SSAO adds to the mix. So yeah, about to throw up my hands and just do it in a postprocessing pass instead. I really didn't want to do that because you lose a little bit of color fidelity that way, but it may be the only way that's feasible with the house of cards that is the renderer.

Take a Gravity Controller on a HMLGTF and find out. 😉

There is definitely something screwy going on with that shader, had already identified it as a problem but it's been acting very strange and producing output that makes no sense. Finally got it to cooperate. There's one other problematic one that needs to be fixed as well that's making scene fog not affect some trees.

This is a completely separate issue specific to that mission (and a couple of Dark Astoria cave missions); we've got a fix in the pipeline for it.

@JelloMold's first issue looks like possibly a corrupt shader cache. That can be cleared using the "Reset graphics settings on next run" option in the launcher, or if you don't want to do that, manually deleting [cohinstall]\cache\shaders. What @Night and I think @Nishastra are seeing I believe is an issue with the new gamma correction not applying to the skybox fog... and apparently fogged-out water. I did a comparison between page 6 and page 7 in Ouroboros and it looks identical at 100% gamma, but moving gamma to the extremes in page 7 makes it obvious what's happening. Workaround for now is to use 100% gamma or close to it when outdoors until that oversight can be fixed.

I believe this is what you're after. Note that these are the bindings from the Beta server, which have leftdragworld and mbutton swapped from the current live build, but this is most likely what it will be going forward. ' "quickchat" / "show chat$$slashchat" 0 "powexec_slot 10" CTRL+0 "powexec_serverslot 10" SHIFT+0 "powexec_alt2slot 10" ALT+0 "powexec_altslot 10" 1 "powexec_slot 1" CTRL+1 "powexec_serverslot 1" SHIFT+1 "powexec_alt2slot 1" ALT+1 "powexec_altslot 1" 2 "powexec_slot 2" CTRL+2 "powexec_serverslot 2" SHIFT+2 "powexec_alt2slot 2" ALT+2 "powexec_altslot 2" 3 "powexec_slot 3" CTRL+3 "powexec_serverslot 3" SHIFT+3 "powexec_alt2slot 3" ALT+3 "powexec_altslot 3" 4 "powexec_slot 4" CTRL+4 "powexec_serverslot 4" SHIFT+4 "powexec_alt2slot 4" ALT+4 "powexec_altslot 4" 5 "powexec_slot 5" CTRL+5 "powexec_serverslot 5" SHIFT+5 "powexec_alt2slot 5" ALT+5 "powexec_altslot 5" 6 "powexec_slot 6" CTRL+6 "powexec_serverslot 6" SHIFT+6 "powexec_alt2slot 6" ALT+6 "powexec_altslot 6" 7 "powexec_slot 7" CTRL+7 "powexec_serverslot 7" SHIFT+7 "powexec_alt2slot 7" ALT+7 "powexec_altslot 7" 8 "powexec_slot 8" CTRL+8 "powexec_serverslot 8" SHIFT+8 "powexec_alt2slot 8" ALT+8 "powexec_altslot 8" 9 "powexec_slot 9" CTRL+9 "powexec_serverslot 9" SHIFT+9 "powexec_alt2slot 9" ALT+9 "powexec_altslot 9" ; "show chat$$beginchat ;" \ "menu" A "+left" B "++first" BACKSPACE "autoreply" C "chat" COMMA "show chat$$beginchat /tell $target, " D "+right" DELETE "+lookdown" DOWN "+backward" DOWNARROW "+backward" E "+turnright" END "+zoomout" ENTER "show chat$$startchat" ESC "unselect" F "follow" F1 "inspexec_slot 1" SHIFT+F1 "team_select 1" F10 "say $battlecry $$ emote attack" F2 "inspexec_slot 2" SHIFT+F2 "team_select 2" F3 "inspexec_slot 3" SHIFT+F3 "team_select 3" F4 "inspexec_slot 4" SHIFT+F4 "team_select 4" F5 "inspexec_slot 5" SHIFT+F5 "team_select 5" F6 "local <color white><bgcolor red>RUN!" SHIFT+F6 "team_select 6" F7 "say <color black><bgcolor #22aa22>Ready! $$ emote thumbsup" SHIFT+F7 "team_select 7" F8 "local <color black><bgcolor #aaaa22>HELP! $$ emote whistle" SHIFT+F8 "team_select 8" F9 "local <color white><bgcolor #2222aa><scale .75>level $level $archetype$$local <color white><bgcolor #2222aa>Looking for team" H "helpwindow" HOME "+zoomin" INSERT "+lookup" LEFT "+turnleft" LEFTARROW "+turnleft" LeftDragWorld "+camrotate" M "map" MBUTTON "+camrotate$$camturn" MouseChord "+forward$$playerturn" MOUSEWHEEL "+camdistadjust" N "nav" P "powers" PAGEDOWN "camreset" PAGEUP "+camrotate" Q "+turnleft" R "++autorun" RBUTTON "+mouse_look" RIGHT "+turnright" RIGHTARROW "+turnright" S "+backward" SPACE "+up" SYSRQ "screenshot" T "target" TAB "target_enemy_next" CTRL+TAB "target_enemy_near" SHIFT+TAB "target_enemy_prev" UP "+forward" UPARROW "+forward" V "+ctm_invert" W "+forward$$playerturn" X "+down" Z "powexec_abort"

Should be hitting Brainstorm tonight hopefully, but as of that same patch, when a tip is replaced because your tips are full, the floating text is suppressed entirely and does not appear.

That's how /unbind has always worked: https://homecoming.wiki/wiki/Unbind_(Slash_Command) You want /bind C "nop", which is what the options menu does when you unbind something there, either with the new Escape key shortcut or by overwriting it with a different key.

I'm surprised you were able to consistently. Might depend on which shard. GMs were often getting tickets about being unable to fight Adamastor because of people AFK camping the summoning spot with masterminds and the summon power on auto.