Number Six

Even if you are at aggro cap, you'll be able to grab them now. Since they're sorted in reverse order by threat, a freshly taunted target (remaining duration of taunt effects gets a large multiplier) will be at the top of the list and will be the first one re-evaluated. So what will happen is the one you taunted will move into your 17 'uncapped' attackers and run towards you, while the one with the lowest threat gets pushed 'out' and will go find a more interesting target.

Also, account activity is not something that's possible for the system to access due to the game's distributed architecture. Account data lives on a separate system from the individual shards. It would take a much more substantial rewrite of the character list code to for it to be able to query that efficiently.

I'm a little confused because this is already the case. The yellow triangle warning indicates a name that will be up for grabs "soon", with the length of the warning being proportional to the tier that it's in. 7 day, 14 day, and 30 day warning periods for the 3 tiers. The orange triangle indicates a name that would be at risk, but isn't actually because the system isn't in enforcement mode yet. At some point in the future, when enforcement is turned on, the orange icons will become the red icons with the white exclamation mark you see in the screenshot above. That's the "do something now!" indicator. Or ignore it if it's not a name you really care about.

Hmm, looks like the older patch notes got used and not the revised ones that include that information. It's in feet. The default (and max) distance in most zones is 100. Pocket D is 50.

Reducing lag in starter zones is another side benefit. AE is badly implemented and horrendous with the amount it causes. It used to be worse -- we fixed a number of the really bad synchronous waits that could stall the whole zone, but it's still a bear when heavily used.

Attack type changes are thataway, please direct feedback there.

Neither. get_global_name_silent isn't a command and doesn't exist. get_global_silent does the same thing as get_global_name except it doesn't print the results to the chat window. So it's not useful as a manually typed slash command. It's used internally by the player note system to retrieve the global name when you add a note to a character the client doesn't already know the global for.

Apropos of nothing at all, here's an unrelated comic

Cool idea i like it

Version 4772 File Downloads Add defensive timeouts and low transfer rate detection to automatically cancel downloads from servers that don't fail but are not transferring data or are downloading extremely slowly. This should prevent a flaky connection from being able to stall progress forever; after some time it will move on to another source. Add more detail to log message about failures to create destination files. Be faster about cancelling download tasks and immediately closing the files when a user cancels an install; this should resolve access denied errors when restarting the same install right away. Miscellaneous Redesign how disk caching works to prevent the newsfeed from sometimes failing to detect an updated copy on the server if the files were updated in a certain order. Command Line Interface Fix a race condition that caused launchercli to often crash when running the list command. Rewrite old code that hadn't been updated to handle the new way package dependencies work; this caused the list of profiles to not always wait for the information to be fully populated and sometimes show "unknown" state in CLI mode even when the packages are installed.

It's not new, I had it happen to me back on the Paragon servers. Weird glitch that happens rarely where it gets its wires crossed somehow about which map to send you to.

kScriptNotify is the correct attrib name, I know because I wrote it. 😛 It doesn't execute anything, it sends a notification to a script that's already running and has registered to listen for the event. Notice how the param type is correctly shown as ScriptNotify. It should match the attrib name but it doesn't here. I can only assume "Execute_Script" was put in as a friendly name to describe the old attribute that used to occupy the same index number. There's never been an attribute with that exact name. - case kSpecialAttrib_LuaExec: return (friendly ? "(exec Lua)" : "SpecialAttrib_LuaExec"); + case kSpecialAttrib_ScriptNotify: return (friendly ? "(script notify)" : "SpecialAttrib_ScriptNotify");

I think your attributes names may be a little out of date, what's showing up as "Execute_Script" in the json dump is actually ScriptNotify. kLuaExec was removed because it was unused and implemented badly. The replacement probably ended up in the same slot so you might not have noticed since the attribute numbers didn't shift around.

Yes, the Homecoming launcher and game client both support Windows 11 natively. A decent portion of our players are already running it. Over the last week, based on user agents hitting the web servers checking for updates, the player base looks like: 18,588 unique users 62% HC Launcher 38% Manifest-based launcher (approx 94% Tequila or derivative, 4% Island Rum, 2% Other) 8% Windows 11 85% Windows 10 1% Windows 8 3% Windows 7 3% Wine Is Not an Emulator (Mac or Linux) 4 brave souls running Vista 3 oddballs running Windows Server 2016/2019 1 lonesome Windows XP user

It does it to work around all your pets getting the +1 level shift from Alpha slot applied to them. Otherwise the dummy would be +1 and make it not have the same stats as a pylon anymore.

That's a very odd place for it to stop. The next thing that should happen after that message is it determines if you have a 64-bit machine, and if the right C runtime library is installed, but that seems to be getting stuck somehow, neither succeeding or failing. If you do have a 64-bit OS (the vast majority these days), you could try running the appropriate binary directly and not depending on the handoff from the 32-bit installer. Look under bin\win64 and try running the launcher.exe there.

Did it get far enough to create a log file in the location that you picked for the install? From the variety of symptoms (disappearing files, modder not working, blocked internet connectivity) it sure sounds like your AV or something else isn't respecting your exclusions and it causing all sorts of issues.

Gamma is unfortunately broken due to a Windows API change after a certain Windows 10 patch a couple years ago — something to do with the nighttime color shift they added. It works on *some* graphics drivers for some reason but definitely not all, including mine. I have a possible workaround in the pipeline but multimonitor setups make it difficult to do right without the risk of the game closing and not resetting the gamma back to what it was. Also investigating doing it at the shader level instead, but that may reduce color quality so I’m not sure if it’s the best way to go.

Nothing quite so interesting. That expression is the result of several iterations of development to try out different rates of pull and find something that felt right. It started out with distance 7 -, using an assumption that the inner radius should be the starting point of the calculation, and everything was built up around that but left separate so it could be easily tweaked. By pure chance the final version of it ended up using a construct that made the outer radius be the starting point and ignored the inner entirely, but I didn't bother to simplify the expression. The CoD parser tries to reformat it, but it's partly hampered by not being written to handle things like exponents. I not sure if UberGuy even knew the dup keyword was a thing until this power went in. You might be interested to know that I speculated about this possibility when writing up the design for vectored knock. This is one of the extra notes or 'useful tricks': The way that works is by adding a proc to every activation of the power the enhancement is slotted in that does a mag 0 knock. That will normally do nothing at all, but because it has a Priority 10 downwards vector, the one thing it does is to override any other knock from that source entity on the same server tick and replace it with the higher priority down vector. After some thought I came to the conclusion that while it's a neat trick, that wouldn't actually work for every case because some powers deal the knockback on a delay timer rather than right when the power hits, so this trick would miss converting those. Doing it properly will require some mechanism to override effect parameters of another power at activation time.

Afterward - What about ForceMove? Some of you reading this may have dug around enough to be familiar with an unused special attribute in the code called kForceMove, and are thinking ‘Hey, wait a minute, why not just use that?’ For those who haven’t, ForceMove is a special attribute that does what it says on the tin and forces an entity to move to a specific location. After about 15 minutes of looking at the ForceMove implementation it was clear that it would be a bad idea to use it for anything, ever. It’s obviously a very early work in progress meant only to test the idea. How ForceMove works is: If the target is a critter (NPC), it instructs the AI to move to that location. The AI constructs a path and walks there. It doesn’t even use wire movement, it just walks along the path. Worse, if the target is a player - doesn’t matter if we’re talking PVP or a power you use on yourself - it sends a network packet to the client that tells the client to lock autofollow on the destination coordinates. Then the client tries to move there just like you had click-to-move turned on. The latency alone between the client and server’s view of the world makes this a bad idea, and I’m sure anyone who’s used autofollow while multiboxing is shuddering right now just because of how unreliable it can be. There’s also the issue of targeting the ForceMove. The test powers that use it make use of another new feature called kPosition targeting which is a good idea, but also was still fairly early in the design process and there are a number of issues with the implementation. The biggest one is that the target location is resolved not at power activation, but rather at the moment the power is queued. For NPCs that’s not really a problem, but players queue powers all the time while they’re out of range or out of endurance or otherwise in a situation where it won’t actually activate for a long time. In that case, the location used for the power would be relative to the place where the player queued the power rather than where they were when it became able to activate. TL;DR: The idea of ForceMove is interesting, and its best use case would probably be something like a “Charge” power that runs toward a target. However before that could happen the implementation needs to be scrapped and rethought.

Part 4 - Pull in Practice The first player-facing application of the new tech was the Singularity change. This was chosen because it’s not an extremely common powerset and would let us evaluate it at a small scale. Being a pet power it would also be more difficult to take advantage of if there was some bug that allowed it to be use exploitatively or for griefing, etc. The power def for Singy’s new trick looks like: Effect { RadiusInner 7.0000 RadiusOuter 45.0000 Requires enttype target> critter eq AttribMod { Attrib kRepel Aspect kCur Type kExpression Target kTarget Table "Ones" Scale 1.0000 Duration 0.6250 MagnitudeExpr 38 distance 7 - - 19 / dup dup * * Magnitude 1.0000 StackType kReplace CancelEvents Teleported Flags IgnoreCombatMods Params Knock { VecStart Target VecEnd Source Vel 0.0000 VelMag 0.1000 } } } That’s only the PvE version of the effect for brevity. It’s a fairly standard Repel attribmod but with the vector swapped from the normal direction, and the velocity calculation overridden. The magnitude expression here is to simulate a dense gravitational source and translates to ((45-dist)/19)^3. In other words, the pull is very strong near the event horizon and quickly falls off to very weak for targets further away. We learned some valuable lessons from this, including finding out that players teleporting while under the effects of a Repel effect caused all sorts of terrible rubber banding. That particular bug in motion prediction predates the vectored implementation and has probably been around for as long as Repel has, but it was never noticed because teleporting while being repelled was such a rare occurrence. Once the pets of Family bosses had access to it that changed very quickly. The same bug affects Knockback, but since KB effects only last 1 server tick it’s even harder to trigger there. The same effect appears on a larger scale in Dr. Aeon’s Strike Force under conditions that I won’t reveal because it’s a spoiler, but it plays a role in a particular boss fight and draws all the players in to a big portal during one of the phases. The motion prediction problem with teleport turned out to be a blocking issue for that encounter, and so the bug is fixed in Page 3. There are a few more subtle uses of the tech in the upcoming update. Seismic blast has a knockdown patch that uses a down vector to avoid becoming knockback when effects get stacked. Scrapper/Stalker Stone Armor’s new Geode power uses reverse Repel internally for better control over the position of the pseudopet that it spawns. Given how flexible the system is, I think it’s fair to say we’ll be seeing it used more as the powers team gets more comfortable with it.

Part 3 - Anatomy of a Power With all that history out of the way, I’ll jump straight into the design. Here’s a copy and paste from the documentation for how to use the new effects: Effect { AttribMod { Attrib kKnock Scale [num] Params Knock { VecStart [Anchor] VecEnd [Anchor] AdjustPYR [pitch] [yaw] [roll] Priority [integer] Vel [num] VelMag [num] Height [num] HeightMag [num] } } } A few bits of context here. kKnockback was renamed to kKnock, though the old name was retained so powers could be loaded without changing them immediately. kKnockUp was deprecated. Now that powers can specify what direction they want to knock something, having a separate attribute for it became wholly redundant. It still exists for compatibility reasons, but will eventually be fully replaced by kKnock effects and removed. The Knock parameters above also work for kRepel effects. The important part of that structure are the VecStart and VecEnd parameters, they put the vector in vectored KB. A ‘traditional’ knockback would use VecStart Source, VecEnd Target. A ‘get over here’ grappling hook power would use VecStart Target, VecEnd Source. VecEnd also accepts things like Up, Down, and Facing, which is where the KnockUp replacement comes in. The ‘Down’ vector is especially interesting, because it allows for the creation of powers that cause Knockdown but have a high magnitude and can punch through KB protection. This is something that was not possible before, since a high magnitude would normally mean a long knockback distance. Knockdown powers with a ‘down’ vector also cannot merge together into KB and will always stay as Knockdown. AdjustPYR is also quite a bit of fun and was used in the April Fool’s Day Brawl. After the knock vector is calculated, that setting can be used to rotate the vector along an axis and point almost any direction you can think of. Imagine a sweeping strike with a Titan Weapon that knocks the target left. Or a Whirlpool that uses vectored repel to actually drag things in a spiral. Priority is used to disambiguate effects that happen on the same tick. The new system is fairly smart about it and unlike the old one that could only remember a single source, it now merges multiple vectors together, so you end up with a final direction of everything averaged together. But if you wanted to make a power that takes precedence over everything else, a designer can do that by setting a higher priority. The last 4 are for fine-tuning the velocity of the effect and just how much of it is derived from the magnitude, as well as doing the simulated arc that traditional knockback effects have. Back to the design doc, the defaults that correspond to each type of effect are: kKnock (aka KB): Vel = 1.0, VelMag = 0.025, Height = 3.0, HeightMag = 0.25 kKnockup: Vel = 0, VelMag = 0, Height = 6.0, HeightMag = 1.0 kRepel: Vel = 0.5, VelMag = 0.2, Height = 0, HeightMag = 0 Velocity is in world units per tick, being roughly feet per 1/30th of a second. Val is a fixed constant, while VelMag acts as a multiplier on the magnitude from the kKnock attribute. Height is a fun one, having a Height is what simulates being knocked in an arc. It’s also… complicated so I’ll just snip part of the design doc rather than try to break it down. A lot of math for something that we take for granted.

Part 2 - Visualizing the Change You Want to Be When I first began thinking about how to do something along the lines of reverse knockback, I decided that we needed to plan something that would be flexible and future-proof. A very early proof-of-concept prototype was done that added two new attributes, called kKnockIn and kAttract, just to test the concept. Those attributes worked exactly like Knockback and Repel, but with the source and target entities swapped. Those attributes were never intended to be anything more than a proof of concept, and indeed never even made it out of a development branch. Somewhere gathering dust I have a copy of Assault Rifle with an M30 grenade that makes big groups hilariously get flung right on top of you. There were obvious problems with that approach, the least of which being the annoyance of having to fill out class tables for these new attributes for 10+ archetypes, add them to every KB protection power or enhancement in the game, etc. Ultimately though, I thought that we could do better. There weren’t any real tools for moving entities around from powers other than Teleport (and ForceMove but that’s terrible, see the afterward), and I could think of all sorts of interesting things that could be done if the designers had more control there. So then came the brainstorming. After a lot of design revisions and bouncing ideas off the team, we came up with the sketch for the Vectored Knock system. It would be built on Effect Parameters - an innovation from the Issue 25 power system revamp that lets different effects take any number of arbitrary parameters in an efficient way - and would let designers specify not just the direction of the knock, but also fine-tune exactly how the velocity is calculated, so that the strength of the effect would not necessarily have to be tied directly to the magnitude. A priority system was also devised to give us the ability to decide exactly what happens if multiple conflicting effects are applied on the same tick.