Number Six

To help clarify the difference between the now 3 different clients, there are two different branches: New client: The new client (and server) have undergone a significant amount of modernization work and this is our "future-proof" branch for ongoing development. It's built with a much newer compiler & development tools, has support for modern operating systems, has been reorganized and had a lot of old and useless code removed, has undergone a lot of cleanup to fix problems that made it incompatible with 64-bit architecture, has upgraded third-party libraries, etc. It also integrates some changes to make development easier. For example the memory allocator was replaced with one that allows us to do memory profiling in production mode without a significant performance impact - an invaluable tool for tracking down memory leaks that only show up under real-world load conditions and can't be reproduced on a developer's PC or even the test server. As a result of shifting so much around, it's also uncovered a lot of bugs that have been present in the client forever, but were rendered harmless or just never noticed by chance. A good example is off-by-one buffer issues that write 1 byte too far, but due to how the old compiler laid out memory never overwrote anything critical. We've fixed a number of these, but there may be more lurking. There are two builds of this client: 64-bit: The preferred client going forward. Supports Windows 7 and later. Requires Visual C++ 2015/2017/2019 runtime installed (included by default in Windows 8+, can be installed on 7 and most people should already have it). 32-bit: For compatibility with systems that do not have a 64-bit OS installed, or rare cases of other incompatibility. Supports Windows XP and later. Does not require any external runtime. Both of these builds will get all new features and enhancements; though some features like XInput controller support require newer operating systems to function. Legacy client: This is the current client being used on the live servers. It's built with the old compiler. The data format changes necessary for the 64-bit client have been backported in order to make it continue to work. It is being provided as a fallback in case people run into compatibility problems on the new branch. This client will not be getting any new features. As it requires extra work to backport fixes to this branch, it is being provided as a temporary measure to keep people running and will not be maintained indefinitely. The goal is for all systems to be able to run either the 64-bit or 32-bit build of the new client. If you find that you cannot use at least the new 32-bit client for some reason and must use the legacy client, please let us know! We're working hard to make sure that there is an upgrade path that will work for everyone, so we need to find out about any issues with it and resolve them before the legacy branch is retired.

The 64-bit client won't impact server load any -- as far as the server is concerned it is no different than the 32-bit client. The 64-bit mapserver (also being tested on the beta server) has a much bigger possibility of impacting server utilization. The most obvious effect is there should be fewer instances where a long-lived map reaches the danger level (1.8GB private memory usage for 32-bit) and goes into drain mode -- forcing everybody to for example Atlas Park 2. However, consolidating shards doesn't really make any sense due to how the COH server architecture works. All of the shards in a region share a pool of mapserver hosts, and the map instances on each physical server use shared memory so they only need to load the static assets once. For example, Atlas Park on Torchbearer could be running on the same server as Port Oakes on Excelsior, an Incarnate trial on Indomitable, and a mission that somebody on Everlasting is running. Shards themselves are fairly lightweight as a result -- the only piece unique to the shard is the dbserver, and that can be virtualized. The only shard that has dedicated mapserver resources is Reunion, because it's in a different datacenter on the other side of the planet. Shards exist because the dbserver, which has always been 64-bit, tends to get unstable around 2,000 concurrent players. This is the same reason that server merges were never going to happen on live and would not have been a cost savings. There's a ton of downside and support nightmare dealing with name conflicts, and little to no benefit from doing it.

That means you're missing the Visual C++ 2017 runtime. Most people should already have it because it's bundled with newer versions of windows and many other applications also require it. You can download it from Microsoft here: https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads Download and install the 'x64' version of the 2015/2017/2019 runtime to get the files required for the 64-bit client.

Paragon wiki has a lot of stuff mined from the data files. There's quite a few powers that were either unfinished, no longer used, ideas that were abandoned before they ever went live, etc. Most of them really old ones rather than anything in progress before shutdown.

I don't think that power was ever in game. People may be remembering Quantum Flight, the Peacebringer secondary power that gives you phase shift+fly.

If you just recently created your account, it probably doesn't exist on the beta server, which has its own separate authentication. Generally we refresh that only every once in a while -- this round it was done shortly before the beta server was patched.

"Trust, but verify." - Russian proverb, as quoted by Ronald Reagan

Thanks, this is a known issue that I'm looking into. It is very likely PhysX related. There are a couple of PhsyX changes in this build that apparently got missed when the patch notes were being prepared. The amount of debris that is allowed to exist was increased for the Medium, High, and Very High settings. Also: When particle physics quality is set to "High" or above, mutual collision is enabled between all PhysX objects. This means that junk from Propel will stack up instead of passing through other debris, bullet casings, trash, and leaves will bounce off of and can even come to rest on it, etc. These objects also affect each other, so pushing leaves around causes other nearby objects to move (depending on their mass). It's really fun to roll a gravity controller and push the junk around to see how it all interacts now. When physics quality is set to "Very High", the simulation step resolution is increased by 50%, and the step rate is allowed to scale up to 120fps rather than being capped at 60fps. While this all seems to work fine most of the time (provided you have a spare CPU core with enough horsepower), there have been scattered occurrences of extreme frame rate drops for no apparent reason. Leaves seem to be a common cause of this, I've also experienced it with rocks left over from earth assault powers. It doesn't happen all the time, just sometimes, and when it does it completely murders your framerate. My current thinking is that we may need to scale back the increased debris limit some, or implement some form of dynamic scaling that removes objects if the scene can't be processed fast enough. I'm also probably going to disable certain collisions between small objects (for example leaf-leaf collisions or bullet casings colliding with each other), while still allowing them to interact with larger objects, though that will require some fx data changes to properly categories the items. In the meantime, the easiest way to get out of it if you run into this on beta is to set your physics quality to "Medium". The problem shouldn't occur at that level, and changing the setting instantly clears out all debris from the scene.

Patch incoming in 3... 2... 😉

That's fairly normal for overzealous AV. New executable, never seen anywhere before, not signed by one of the Chosen(TM) big software publishers. It's a huge problem for small, independent developers.

Heh. Well, it didn't make it in, but my suggested patch note was "Ragdoll is still broken, but it's broken in new and different ways." So you'll probably still see defeated enemies in some anatomically improbable positions, even if they don't collapse into a limp pile of jello anymore.

This is a common thing I see a lot, so let me just go ahead and shoot it down. The code for in-game advertising is gone. It was licensed from a third party and could not be used or even bundled with the game anymore once their agreement with DoubleFusion ended. Paragon had already removed most of it, and the SCORE team ripped out what little was left. That system is dead and it's not coming back.

Jolting Chain will be an autopower on a pseudopet, so it'll probably do the calculation with 10 second period regardless of the actual summoning power. Old-style chain type powers are autopowers on pets, and they're typically spherical AoEs with a 1 target max (so they always pick the closest eligible target). I don't think area factor takes the target cap into account so it'll probably be calculated like an AoE for the extra jumps.

@BopperLooks like there are a couple powers that use ExecutePower after all. Savage Leap from Savage Melee uses it to deliver the AoE Damage after teleporting to the target. This is actually a really good use of the tech - dropping a pseudopet is problematic due to the teleport, and getting it in the right place would be tricky to do without introducing a noticeable delay on the damage. Since the top-level power affects kCharacter (a single target), it has an area factor of 1.0. The area factor combining does technically happen, but results in the same area factor that the AoE would have if it were a standalone power. Feral Charge from Savage Assault works the same way.

That's not in the source code. It's in the powers data, which is part of the client and can be decoded from the bin file, but I don't believe anyone has created a parser that can read the format that the i25+ powers.bin file uses.

That only applies to powers with the kChain area type. That wasn't a thing prior to i25, so this does not apply to Electric Melee's Chain Induction or things like Ion Judgment, which use the old pseudopet method of chaining. The i25+ chaining doesn't require manually defining a bunch of different pets and can do things pseudopets can't like hit all the chain targets in a single combat tick. I think the only powers that currently use it are Sentinels' Refractor Beam and Chain Heal from the epic pool. It's another post-shutdown development. It was created as part of a big powers system revamp that introduced a bunch of new features intended to streamline power creation and make it easier for power designers to do cool and interesting things. However development of new powers stalled for a while after that, and the powers developers tended to use existing old-style powers as a sample template rather than experimenting with the new features. ExecutePower is an effect that allows a power designer to directly call one power from another, allowing for more flexible targeting. The primary two use cases it's designed for are: Fulcrum Shift Instead of a targeted AoE that spawns a bunch of pesuedopets (some at the target and some at the caster) which all have autopowers that deliver an AoE damage buff, then immediately die... Fulcrum Shift could be redesigned as a targeted AoE that executes AoE damage buff powers on the target and the caster, making it less complex, less resource intensive on the server, and easier to design similar powers. Tanker Gauntlet Gauntlet is a massive hack. They made every single-target tanker attack power actually a spherical AoE, but with the damage attrib having a radius override of 0. This wreaks havoc with real numbers and the streakbreaker, and things like PPM all need special-case hacks for it. It also doesn't work with cones at all; only the targets directly hit by the cone get taunted because there's no way to make the hack work in that case. With ExecutePower, Gauntlet could be redesigned as a global boost granted by an inherent, that simply adds an ExecutePower to every tanker attack. The attack powers stay single-target, but when they connect they fire off a second power that does a spherical AoE taunt (which could even have a subtle visual fx if desired). For Cones and AoEs, this actually shows off the power of this technique, because every target hit by the cone would then have a spherical region around it affected by the taunt. That's the exact circumstance in which area factors would be combined, say if you had a perfect zinger proc slotted in a cone. Neither of those were implemented, though there is a partially finished Gauntlet rework in the tree that might be resurrected at some point. The PPM code uses the ActivatePeriod of the proc rather than the power. So it always uses 10 seconds for the calculation. That actually penalizes toggles that have an ActivatePeriod longer than 10 seconds, but I don't know if any actually exist that do.

I'm kind of juggling a lot of things and there's a bunch of discussion in the thread so I'm not completely clear on what's resolved and what's not. Could you or someone ask a few direct questions about the parts that are unknown or in doubt? Until then I'll type some random stuff that may or may not be helpful. Power area factors are: Single target: 1.0 Sphere: Radius * 0.15 Cone: (1 + (Radius * 0.15)) - ((Radius * 0.00036667)*(360 - Arc)) Chain: MaxTargets * 0.75 The power's area factor is adjusted by (AreaFactor * 0.75) + 0.25 before being used for PPM. The original area factor is still used for things like DoubleHit damage procs, IIRC. Area factors for executed powers accumulate multiplicatively, but I don't think there are currently in powers in the game that take advantage of kExecutePower in a way that would trigger that. There isn't any kind of system-wide internal cooldown on procs in general (outside of toggle powers, see below), but there may be one or two that have one implemented in the powers data with grantpower tricks or other methods. In toggle and auto powers the ActivatePeriod of the proc is used as an internal cooldown of sorts. I believe every proc has this set to 10 seconds in the data but can't promise there are no exceptions. After the timer is up they are eligible to proc again, though doesn't happen until the next ActivatePeriod of the power it's slotted into.

Just now saw this thread. Please note that this block of code from up-thread is wrong. Specifically, this line: fChanceFinal *= (ppowOrig->ppowBase->fRechargeTime * ppowOrig->pattrStrength->fRechargeTime / pSrc->attrStrength.fRechargeTime + ppowOrig->ppowBase->fTimeToActivate); multiplies the base recharge time (which is later divided by 60) by the proportion of the power's recharge strength (enhancement+global) over the character's global recharge strength. Since the enhancement value ends up in the numerator, it causes the code to have the exact opposite effect as intended. As the amount of slotted recharge enhancement increases, so does the calculated cycle time and the eventual %chance. It also doesn't completely remove the global recharge from the equation, since recharge strength accumulation is additive rather than multiplicative. This particular bug was present in the Issue 24 beta that was being tested before shutdown. At some point, it appears the SCORE developers fixed it and changed the calculation to match the final version that Synapse had posted on the forums and is being discussed in this thread. The code block above is from the original leaked i24 source, before the bug was fixed. As far as I'm aware none of the servers based on that code have found or fixed this bug, so PPM proc rates on those servers likely go completely bonkers once you start slotting recharge enhancements. The Homecoming servers are based off of i25, which contains the fixed version and behaves according to the formula that Synapse intended. If you're looking for insight into how things work on Homecoming, I highly recommend looking at the i25 source instead. I can't link to that for hopefully obvious reasons, but it's not far away from where the i24 source can be found. The equivalent code there is a bit different because of how activation chance and tick chance were split into separate things but the corrected formula can be found by looking for RechargeDivisor.

We're doing well. Definitely nothing bad to report. There are a lot of exciting things happening behind the scenes in a wide variety of areas. Can't say any more because fueling speculation would be unhelpful, but hopefully the reasons will become apparent in a future update.

It's possible, all it needs is some VFX work to make a tintable version. The UI for customizing Inherent & Temp powers has already been added to the Issue 25/26 code.

This is something I pitched early on as a possible project. It would be a lot more work than you'd think to hook globals into everything (like team invites), just because chatserver is an external thing that isn't always up and running. The dbserver/mapserver that handles all of the game logic isn't even aware of what your global name is. A ton of work to redesign all that but I didn't think it was completely impossible. Surprisingly, the idea was really divisive even among the Homecoming staff. I can only imagine what it would do to the playerbase, so it's been shelved and probably won't happen here.

Because powers designers are notoriously terrible writers? I mean, have you read some of the power descriptions?

It's not really a guaranteed thing -- although not having one is guaranteed to get you flagged with certain vendors. What it helps with is that if we sign the binaries with a Homecoming LLC certificate, when those binaries get flagged and people report them as false positives, any reputation gained through that process is often partly applied to other (new) versions signed with the same certificate. It's not something that will fix it overnight but in the long run should help reduce the problems.

My two cents to the powers designer, since I've been told you're reading this thread carefully: I understand the intent here and don't entirely disagree. The 22% to-hit threshold for fast snipes is problematic for a number of reasons. It's clunky and unintuitive. It is a big performance boost but is also very binary - either you have it perma or almost never. The indicator is flaky due to floating point precision issues. And it breaks one of the fundamental design rules - creating a class-wide mechanic and locking it behind IO builds. However, making fast snipes always available in combat seems to go too far in the other direction to me. It's too good of a buff and it seems only a hair away from just removing snipes altogether and replacing them with a regular attack. So here's my proposal: Every blaster primary attack has a small chance (5 or 10%, whatever is balanced) of putting a "fast snipe" mode on the character that lights up the fast snipe indicator for a few seconds and gives you a short window of availability for it. The more global +ToHit buff you have, the greater this percentage becomes, scaling all the way up to 100% chance at 22% to-hit. This has the advantage of not being such a huge buff at the base levels, while still allowing people who don't build for perma-snipe to have more frequent access to it. It gives to team buffs, taking powers like Tactics, and +ToHit IOs even if you're not near the magic number. It doesn't invalidate the perma-snipe builds that people have been making over the last month. And it doesn't make it seem like /Devices is getting the short end of the stick. I'll also echo the chorus here of strongly disliking the nerf to range in fast snipe mode. Maybe the full range is too much, but it should definitely be more than the standard 80'.

Removing it isn't out of the question, especially on the Tanker version. It would be nice if there was something else besides just the -Dmg to make the power have some sort of tradeoff (note that earlier I said this could even be something to replace the -Dmg). The endurance mini-crash is borderline since it's only -25 end, which can hurt in some circumstances but depending on the build and the team is fairly likely to be ignorable. It's not that much worse than Hasten. I'm not a powers balance person so I can't say for sure if just removing it would make SS overpowered or not. I do have a couple experts in that area on speed-dial that I'm going to be running these ideas through, and also wanted to get a feel for what the community thought.