Jump to content

Telephone

Homecoming Team
  • Content Count

    20
  • Joined

  • Last visited

Community Reputation

48 Excellent

10 Followers

  1. All three of these will actually be placed in our NA data center. Read on for more details! Reunion Reunion's already a bit of the odd one out - we've got a mini-cluster of three hosts in EU for it (the shard host itself, the SQL database host, and the mapserver host). The hardware there is a little bit overprovisioned for Reunion's actual load, but we've found a number of creative additional uses for it to use that spare capacity without affecting player experience (for example, the SQL host also has bulk storage attached and serves as one of our backup tiers and our WSUS update server in addition to its normal SQL duties). We don't have any plans to change the EU cluster at this time since doing so would probably be an increase in costs or decrease in flexibility without any gains. The A1s and the A4 When we originally built the Homecoming cluster a year ago, we allocated physical hardware for each shard's main host, as well as a separate host just for running authentication (the five A1s mentioned above). Since then, we've done a lot of optimization, fixing memory leaks, and profiling to determine how the cluster scales. In addition, all of our beta and prerelease shards (as well as our build servers) are running entirely on the single A4. So we're now a lot more comfortable running more of our game infrastructure on VMs. This will give us a lot more fault tolerance, since if one goes down we can temporarily run its VMs on the other two. Some of you may also recall the authentication issue a few months ago - that was an actual hardware failure on our physical authentication host, and we had to build a new one as a VM on the fly while that was being fixed. The A2s Not addressed yet are the two A2s - those are our general purpose VM hosts. While they're not struggling to handle the load, they're actually not as flexible as we had hoped: - They aren't very good at handling our build infrastructure (which wants lots of cores, but these only have six physical cores each). - We underestimated how much disk space they would need, so we occasionally have to juggle services to avoid a crunch. - Because two is no better than one in the world of high availability, we have to run backup instances of some of the services on these hosts on other hosts to ensure they are fully reliable. What's Not Changing Those of you who have kept up with our other technology posts may remember that we have a few other hosts in NA: - One more A1 which is used as a citadel host (most places would call this a bastion host, but this is CoH) - Three A3s which are used as SQL database hosts (two hot and one warm spare) - Six A5s which are used as mapserver hosts None of these are changing at this time. It's not that we're not confident of our ability to run the services of these hosts on VMs, but after analyzing the required capacity and the types of host we can purchase, we didn't feel there would be any significant cost savings while maintaining our desired reliability and performance criteria. The Future The net result is that the three new A4s will be running the following: - The authentication server (and warm spares) - The four NA live shard hosts (and we'll be able to quickly migrate if there is a failure) - All hosts for beta and prerelease (shard hosts, services hosts, and mapserver hosts) - Our forums - Our development infrastructure and build servers - Our other infrastructure (e.g. petitions/GM tools, system administration, patch and manifest management, CDN, our Kubernetes cluster). The hardware will be better than what we have now: - We'll have the same number of physical cores (48 - but note that the A4 cores are superior to the ones in the A1s/A2s, and also that many of our current cores are just not in places where it is convenient to use them) - We'll have more RAM (544GB -> 768GB). - We'll have more disk space in the right places (4.5TB -> 6TB). TL;DR - We'll reduce our footprint and long-term costs, increase our flexibility for future changes, and be more robust. - Nothing is changing in the EU cluster at this time. Finally, thank you all for donating! We wouldn't be here without you.
  2. Development work is always ongoing! I can't say when we will have something to announce, but be assured that the team has plenty of plans to move forward and an internal roadmap.
  3. You're absolutely correct that this is a bit confusing and needs a little more explanation. On the live shards, there are three pre-defined 'modifiers' (Shift, Ctrl, and Alt). These can be used in any keybind, etc. The patch allows you to define up to six additional modifiers: two 'Controller Modifiers' and up to four 'Extra Modifiers'. The 'Controller Modifiers' are special, as pressing them together enables Virtual Mouse Mode. They do work as bindable modifiers just like the pre-existing three. The up-to-four 'Extra Modifiers' are just additional inputs (either keys or buttons) that can be treated as modifiers when no other modifier is pressed. So for example, you could do /extra_modifiers LBumper RBumper to make the bumpers modifiers on your XInput gamepad. You could then use (for example) LBumper+Joy1 as a /bind (but also still be able to use LTrigger+LBumper as a separate bind). The 'Extra Modifiers' aren't limited to just gamepad buttons, however! If you want, you can bind any key on your keyboard as one (but note that due to some things that still need refactoring, you can't bind a specific Shift, Ctrl, or Alt key on your keyboard yet). You also point out that you both controller- and extra-modifiered the triggers. That could definitely cause issues and we'll fix that. We also don't (currently) have way for you to clear _all_ your extra modifiers, so we'll have to fix that as well (you can just specify a single one with /extra_modifiers and it should clear the other three). Not noted in the patch notes is that we added a number of other convenience aliases which you may have already noticed (e.g. LTrigger, LeftTrigger, RightBumper, StartButton, AButton, and so on). Thanks for the feedback! Please let us know if you have other questions as well.
  4. I'd just like to note that the above patch notes don't encompass the full extent of the controller changes (the fault is mine, as I have been tracking notes in a long-running merge request and the notes there are from an earlier revision in a commit message). New Slash Commands /extra_modifiers [mod1] [mod2] [mod3] [mod4] Allows setting up to four extra modifiers. These (currently) only work when no other modifier is pressed. Recommended for XInput users is /extra_modifiers LBumper RBumper /controller_modifiers <first> <second> Allows setting two controller buttons as modifiers. On non-XInput devices, when both of these are pressed together, the controller will enter virtual mouse mode. The arguments are the button numbers to use (from 1-24). Recommended for XInput users is /controller_modifiers 7 8 (the two triggers, since these are currently hard-coded as virtual mouse mode on XInput) /controller_vmouse <LMB> <RMB> [MMB] [Snap] Configures virtual mouse mode buttons. By default, button 1 is the LMB and button 2 is the RMB. The other two are unset. Recommended for XInput users is /controller_vmouse 1 2 4 3 (which will give you the configuration from the above patch notes). Virtual Mouse Mode The above patch notes are largely correct, except that the middle mouse button and snap button are not configured by default. Note that on XInput devices, the Back and Start buttons are also hard-coded to pass through (so you can configure the Start button to activate the menu and then open it in VMM). There is no current way to modify VMM passthrough configuration, but this is planned. Note that only XInput devices can currently snap diagonally. Due to various controllers reporting inputs differently, this is difficult to fix, but we're looking into it. Future Potential Enhancements A real GUI to configure all these things. Passthrough configuration for VMM. Properly stackable modifiers (so you can finally bind Ctrl+Alt+X to your nuke). Latching modifiers (so that you can set up a bind for Left Trigger, then Left Bumper, then the X button). The ability to independently bind LShift/RShift/LCtrl/RCtrl/LAlt/RAlt as actual modifiers if you wish. Analog movement and camera control when using analog sticks. A bindable 'interact' which will interact with the closest thing in front of you (e.g. opening a door or talking to a contact). Questions for Users How does Virtual Mouse Mode feel? Any specific issues? Does the pointer move at a good speed? Are the snap positions good? Do binds save and restore well? Can you load a bind file from live without issues? There's currently a very unusual behavior in City of Heroes where if you bind Ctrl+X and Alt+X, then press Ctrl+Alt+X, both keybinds will fire. Do you depend on this behavior? We're considering removing it as it will make many of the above features much easier to implement. One More Thing If you copy your launch line from Tequila and then launch the game from Steam, any controller can be an XInput controller. (I personally use this on my DS4).
  5. Farming itself was and is not an exploit. The base use of the option was also not an exploit. However, there were specific things you could do in combination with the option to significantly increase your Influence gain. Those are the exploits to which we are referring.
  6. I'm sure it's a feature we could look to add in the future if there was enough demand. As you say, though, it's something very low on the priority radar. We have some longer-term plans to rework the authentication system (it's in need of some heavy cleanup) and when we do so we'll consider this feature. No guarantees, of course.
  7. Yes, this is a slightly unfortunate but expected side effect of the change.
  8. I have resynchronized AE on Beta from a recent live backup.
  9. This is actually a very good question and a reason that the wording was changed to 'existing' (you quoted the old wording, which did indeed have 'signature'). I think most people will agree that a signature character is one that could appear on the box art, in promotional material, etc.
  10. We've added a note to the GMOTD to ensure that everyone knows you can always see the WSTs by looking at the LFG window.
  11. The marketing statements are just to make everything explicit. As the Policy states in 4.1(D): And in 4.2(A): Presumably you are not requesting any marketing from us, and have not given your consent for us to share information with any third parties. The Homecoming Team considers the privacy and security of our players to be extremely important.
  12. An update to the text rendering library that was still undergoing final review inadvertently slipped into this patch. The change should have been minor, but I've alerted our developers to look into this. You may be contacted with requests for more information, as we would definitely like to stomp out any bugs related to this change. (EDIT) I've just been informed that this is more likely due to UI scaling work than the text rendering library. We still may contact you, and sorry for the inconvenience!
  13. I have some experience with PS4 controller issues under Windows. I know SCPTool was mentioned earlier in this thread, but I've had no luck using that to turn a DS4 into XInput. I've had marginally more luck using DS4Windows, but that is also quite flaky (at least over Bluetooth; wired is probably more reliable). My personal suggestion is (if you have Steam and are inclined to poke around with settings): 1. Add City of Heroes: Homecoming to Steam as a non-Steam game (you'll need to dig at the Tequila settings to get the exact executable and launch arguments) 2. Configure your PS4 controller through Steam 3. Launch City of Heroes: Homecoming through Steam You _may_ also be able to solely use the Steam driver for your DS4 and not have to launch CoH directly through it, but I haven't tried that.
  14. We will look into this. Please use the Safe Mode client for now until we can work on this more.
×
×
  • Create New...