jack_nomind

(It seems like the pdf is gone. I'm going on what the two articles say.) I'm an inveterate cynic. When I saw the early hype for No Man's Sky, I said they couldn't do what they were promising on consume-grade hardware (at the time). Games that I thought could potentially deliver on their promises (enough that I bought in on backer packages) included Champions, Firefall, and Warframe; Champions and Firefall almost made it (but were mismanaged) and Warframe pulled through. I think Paragon/NCSoft could have delivered some version of everything claimed in the document. Sort of. One of the... layers... to this cynicism is realizing that marketing will promise everything developers say might be possible, and then the developers are held to delivering some version of that thing. This leads to kind of an "evil genie" effect where a promised feature is implemented in a way that is technically true (or close) to what was promised, but hideously different than players expected. (Or worse, leadership comes up with a feature deliberately intended to drive revenue even against player and/or developer interests and marketing spins it as a positive feature.) What I read as actually being promised, then, are: Character creation, probably somewhat similar to Champions. Powers customization, probably somewhat similar to Champions. A skill, attribute, or enhancement system that has progress bars to mastery, with powers doing some % of full effectiveness before mastery is achieved. Progress happens both on- and offline. Maximum active abilities locked to some number, probably 4 to 8, somewhere between Warframe and Guild Wars. This is necessary to make a console-friendly game. More PvP focus and destructible (but non-persistent) PvP zones. Most likely this would be structured or event-based PvP, not open-world; I imagine this would work about as well as it did in Champions, Warframe, or Firefall. More 'physics objects.' There probably would be a Big Red Ball. More locks/gates on content to provide a more structured experience; think SWTOR, which was released around that time. Overall I think Champions gives us a very good preview of what CoH2 would have looked like in many ways. I'm a little happy that the Paragon devs rebelled and tried to develop a totally different game, even if it ended up biting us all in the ass.

Hmm. I wonder how hard it would be to create a utility that just lets you automatically replace sound files. It could be packaged into Tequila.

well -- tanks couldn't take SR on live, so that's possibly part of why. this is going to sound strange but, skip parry. Tank SR doesn't benefit much from it while you're levelling, and not at all when you're maxed. while you're levelling you should take all your (other) attacks, but at the end you really only want four: Hack, Disembowl, Whirling Sword, and Head Splitter. In order to chain these as quickly as possible you'll need Hasten and a lot of global haste in general; thankfully SR helps with that. Since you're skipping Slash, Slice, and Parry at the end, you get a little bit of leeway to work in some more pool moves if you want. You can skip Weave at end-game (i recommend picking it up while levelling because on basic enhancements SR comes in short on Defense by almost exactly the value of basic-enhanced Weave), but you can't skip Tough (you need it for resistance set slotting) so unfortunately you're locked into at least Speed and Fighting. You don't absolutely have to take Combat Jumping or Hover, but your life will be noticeably easier with one or the other thanks to the mobility advantage. While you're levelling, I recommend filling the fourth pool spot with Medicine. At end-game you can go a bit weird with the build if you want because SR is very self-contained -- but get there first.

this conforms with the best knowledge i have on internal cooldowns.

all of the villain classes are intentionally solo-friendly role hybrids and making a 1:1 list of H:V ATs is futile. since the prototype for 'solo-able dps AT' at the time was Scrapper, here's one that's equally as valid: Brute : Scrapper Stalker : Scrapper Dominator : Scrapper Corruptor : Ranged Scrapper Mastermind : Six Scrappers on the original topic, Taunt is bar-none the most effective encounter control tool available to Brutes and Tankers. it's skippable purely because the threshhold of viable utility for encounter control now is so high that even Controllers don't always hit it; but there's always at least fringe benefit to killing the range on a group of enemies on demand.

okay. i meant generally. but sure; there's no hover component to the jump pack.

I'm neither pious nor posturing; I clearly think you're mistaken and blowing the issue well out of proportion. Your rhetoric is escalating to a place I don't feel comfortable following.

you move up the vertical axis without limit that's literally what flying is we might have some semantic disjunction. maybe easier? "Jump pack is neither jumping nor flying but a different mode of movement than either, just like Beast Run is not running."

The thing I think is blindingly obvious is that Afterburner is an indirect buff on pre-i20 Fly and nothing else, and the high base speed of Fly is a direct buff on i-18 Fly and nothing else. The position I argued against earlier today is that these things somehow make Fly worse because it "needs" Afterburner to work as a power pick (it doesn't) or that it is hurt by lacking a benefit from slotting (it used to need slotting, but now has the fully-slotted efficacy at one slot). I don't want to give the impression that I'm minimizing the importance of Afterburner. It changes Fly from a mobility-focused travel power into a speed-focused one. Afterburner is an enormous change to a mechanical function -- and it's not the concept tax. For characters that don't benefit from Fly in combat, Fly is the concept tax of Flight. I wouldn't put it quite like that... I think to warrant a pick even for a concept build, it would have to be at least as fast as Sprint along with the vertical movement. But to the larger sentiment... we'll have to agree to disagree on that. To me, it sounds like you're contorting into knots to illustrate whatever it is you're trying to illustrate. We're at a point where we have the flying Super Strength melee concept build who can't use Hover and doesn't want to rely on temp powers to fly and doesn't have the picks available for Afterburner and...

We're not on the same page here. HPT and Fast Healing are not toggles and do not consume endurance. Endurance reduction in those powers from a set or any other source will not affect your endurance usage. Half of zero is zero. Each of your powers that does consume endurance needs its own, individual, endurance reduction enhancements.

SS's Stealth is, itself, also obsolete for highly optimized builds. But really, your point about travel qua travel isn't well taken to begin with; that's entirely what the anti-Afterburner comments in thread have been about, and it absolutely was the basis of my comparison. I don't understand what very specific world you're angling for here -- it's not 2007 but it's also not really today, because we're discussing travel powers as concept-necessary picks when you yourself have given a list of reasons they aren't. It's not a world without temp powers but it's also not a world with all of them. At the beginning you said we were essentially in agreement, but you're clearly at issue with something and I don't think I understand exactly what.

But you don't have any endurance reduction slotted in your toggles. Whatever's slotted in your attacks isn't relevant here. I didn't say that; I said they are not toggles. You can't turn them off and they don't consume any endurance.

Speed absolutely is the most attractive pool in the game... but that doesn't transitively make Super Speed the most attractive travel power in the game. And all of the powers you show exchange SS's speed for vertical mobility -- you'd have an equivalent argument by somehow getting SS-like ground speeds from a temp power as an augmentation for Fly. Well. If you're making the argument that travel powers are entirely obsolete in this stage of the game, fine; but it applies equally to every one of them (except i guess Teleport?), not selectively to one particular mode of speed.

Those add up to exactly 2.33/s... if you have zero endurance reduction slotted. (HPT and Fast Healing are not toggles, btw.)

/jranger on /jrangering /jranger. Community memes are what bind us together.

Two things. First, endurance consumption as a stat doesn't include end used by click powers -- only toggles. Second, that's absurdly high. Full WP, full Fighting + CJ + Maneuvers with no endurance reduction is 1.94/s. Have you ever tried turning Sprint and Ninja Run off while fighting?

Your "little bit" is another mans "whole lot" or "too much". One man's "little bit" being given up "in exchange for speed" is mobility when SS is taken instead of Fly. In that case, it's not a second speed power that needs to be taken to make the power usable; it's a pick from entire second power pool, Leaping, to provide a measure of the 3d mobility Fly has innately. (I suppose a more literal parity would be giving Fly speeds like SS's ground speed on the vertical axis, and speeds like SS's vertical mobility on the horizontal plane. Glad we don't have that.) It seems like all of the anti-Afterburner arguments in this thread would be resolved just as well by returning the Fly pool to its i17 state (as base Fly speeds were buffed in i18 and Afterburner was added in i20): at that point, Fly needed enhancements to reach its speed cap and did not need (could not take) a second power to improve its effectiveness. It'd be a great April Fool's prank from the HC devs but I think it mostly just suggests that the argument is weak and a different approach is needed.

I like the confidence. For what it's worth, I was simplifying before; the Jump Pack doesn't exactly grant flight. But... it also isn't jumping, at least, not the way you mean. Here's the power data: ======== Entry 7806 ======== FullName = Inherent.Inherent.prestige_Jump_Pack_Temp CRCFullName = 1273101745 SourceFile = DEFS/POWERS/INHERENT_INHERENT.POWERS Name = prestige_Jump_Pack_Temp ... AttribMod = -------- AttribMod 0 -------- Name = Ones ... Attrib = Jumppack (288) ... -------- AttribMod 1 -------- Name = Ones ... Attrib = kSetMode (465) ... -------- AttribMod 2 -------- Name = SpeedFlying ... Attrib = SpeedFlying (192) Aspect = kStrength (8) ... -------- AttribMod 3 -------- Name = Leap ... Attrib = JumpHeight (204) In plain language, activating the power modifies four attributes: sets you to jump pack mode, sets you to mode 465, improves your flight speed, and improves your jump height. Mode 465 isn't interesting; it has something to do with 'react' animations or related modes. Jumppack, on the other hand, is interesting. It's a status attribute -- like everything else in the game, ranging from Flight Speed, Endurance Discount, Movement Friction, or Confuse. What it does is grant the player a movement mode. Unlike baseline movement modes, though, it doesn't have any corollary strength attributes. As an example, Flight has an attribute just called Fly and another attribute called SpeedFlying; Jump has SpeedJumping and JumpHeight. And drilling down a little into Flying -- how does the game know you're flying? You have a Fly attribute of greater than zero. What does that do? It changes the behavior of your 'ascend' key and your character's physics. The tl;dr version of all this is that Jump Pack changes your character's behavior to act mostly like flying as long as you're holding the spacebar down. So that's how Fly and Jump work... but here's where it gets interesting. Those aren't the only movement modes (control states) in the game... there's actually a pretty familiar-looking list in the player definition file. The salient portion: server_state.fly = pktGetBits(pak,1); server_state.stun = pktGetBits(pak,1); server_state.jumppack = pktGetBits(pak,1); server_state.glide = pktGetBits(pak,1); server_state.ninja_run = pktGetBits(pak,1); server_state.walk = pktGetBits(pak,1); server_state.beast_run = pktGetBits(pak,1); server_state.steam_jump = pktGetBits(pak,1); server_state.hover_board = pktGetBits(pak,1); server_state.magic_carpet = pktGetBits(pak,1); server_state.parkour_run = pktGetBits(pak, 1); server_state.no_physics = pktGetBits(pak,1); server_state.hit_stumble = pktGetBits(pak,1); All of these (and a few others in the file) change how your control inputs work. The ones that don't have corollary speed attributes just inherit/modify them from elsewhere (like how your jump speed is modified by your momentum, your friction, your movement control, and your SpeedJumping). For a lot of these it's pretty obvious where they're taking them from; your beast_run control speed comes from your run speed, your magic carpet speed comes from your fly speed, etc. What's weird about the Jump Pack, though, is that it doesn't seem like it should care about either Jump Height or Fly Speed, the two other attributes it buffs. Your "jump height" while in jumppack mode is unlimited, the same as in flight. Your horizontal speed also is affected much more by Momentum than by your Fly Speed attribute. So what gives? ...well it turns out that what happens when you let go of your spacebar in Jumppack mode is that you fall, just like you'd turned off a fly power. When you hit the ground, your safe falling distance is measured based on where you started from and what your Jump Height attribute is. So the JumpHeight attribmod is there to stop people from doing massive damage if they don't remember to tap "up" before they hit the ground. SpeedFlying, on the other hand, is... actually just because they felt like it. The devs just wanted the jump pack to be a mini-afterburner. Back to the original point. What does this mean for the initial suggestion? Well... you could just always have everyone in jumppack mode when they're near the ground. You could even do it with regular flight, and it would behave very much like Wile E. Coyote (you'd keep moving off the edge of a platform for a brief period and could run back onto it); my earlier comment wasn't that the idea is impossible, just that it doesn't work the way you seem to believe. But... I honestly don't know how well either flight or jumppack would work for this. One thing I haven't figured out is how simultaneous control modes interact with each other; I know from in-game you can have e.g. ninja run and jump pack active at the same time, but I don't know how priority is decided/shared. I think this would make movement very frustrating at times because it seems like jump pack mode mostly only cares about your momentum and friction, so you wouldn't get expected results from speed buffs. Honestly though... spin up a server, change Hurdle to grant jumppack mode, and see how it goes?

We know from those powers (which grant flight) that we can make the Fly status switch on or off immediately when players press or release the ascend key. We also know from that that the Paragon devs were clever and tricksy.

No increased target limit. Taking advantage of the change would intentionally require players to revise their builds and strategies. Although I propose it elsewhere, I actually don't love the idea of Tankers having much more direct Control or Support. Giving them strong direct debuffs or etc starts to erode the value of other team contributors, which shifts the problem we're dealing with (AT redundancy) rather than resolving it. Making Tankers a "Support support" is much more appealing to me, and having them weaken enemy protections is one way of doing that. This is more or less what I mean. AoE damage and AoE DoTs in particular are a way of further bypassing the current aggro functionality, and they don't have to do a lot of damage to accomplish this. Basically, a Tanker team combo system to help combat Tanker redundancy. If different sources of Bruising stack and Tanker attacks all do, say, 10% more of their secondary effect (e.g., -Def) on a target per stack of Bruising, each additional Tanker on the team makes all the other Tankers a little bit better. That sounds interesting! But I would worry that it's too narrow in application. The play that's promoted by that is to have one single Tanker on the team and to make sure all aggro goes to that one Tanker. My goal isn't to make Brutes (or Khelds, Veats, or even MMs) less desirable tanks -- it's to make Tankers able to bring things to play beyond just being designated damage sponges. I think I'd love to see a power like that in a primary, or even an EPP, though.

Only Tankers get the proposed aggro cap increase. To clarify, this proposal is to revert or mitigate a previous change that is no longer necessary in the current state of the game. I know where the change would need to be made in the code -- or at least the principal place -- and roughly what it would need to be. I concur with reasonable arguments why this change is warranted. This is very structured wishful thinking, in the Wishful Thinking forum, in a wishful thinking thread.

for any tanker set with Dull Pain or equivalent, you don't need any IO set bonuses at all -- just accolades and an enhanced DP. i heavily recommend doing your build in Pines first.

So what's the verdict, yes to scrapper SS or no, nerf TW instead?

Aside from AoEs, if the Tanker is holding enemies' attention with or without Taunt, -tohit is only going to affect attacks targeting the Tanker. No matter how long you make the debuff last, the Tanker's goal is just to not lose aggro at all; they'll reapply Taunt well before either runs out. Including AoEs, you're going about this in a roundabout and ineffective way. -Tohit is in function identical to +Defense, except it has to land on the enemy and can be resisted. A much better way for a Tanker to improve team resilience to AoEs is with Maneuvers, which will automatically improve anyone near enough to the Tanker against all AoEs, not just those of five or ten specific enemies... but that power is regularly skipped. Support generally do more than well enough in that area. A weak or moderate effect isn't going to make Taunt any more attractive to the people already skipping the -range aspect of it. Really Large Numbers probably could sell it. If a Tanker could, say, halve the hit chance of most enemies' AoEs, it'd be appealing to Tankers as a way of dabbling in Support. I hope you see the problem there; halving most enemies' hit chance is a -25% tohit effect, a free and potentially far stronger Parry being added to every single Tanker kit. I'm absolutely with you that expanding Tanker support and control is one good way to distinguish them from Brutes, but there's no strength of single-effect approach that is the right size for the problem. We need a suite of changes that can be individually adjusted to find the overall sweet spot.

Three complimentary reasons. First, most AoE powers have a fairly small target limit. So you can only nuke so many targets at once, and you want un-nuked targets hanging around and not switching aggro over to support or w/e. Second, for powers with much higher target limits -- like Judgements -- you want to have as many targets in range as possible to maximize their use. Third, while not everyone here is talking about truly large aggro caps, I am. I'm fully in favor of somewhere between triple and unlimited aggro for Tankers. Herding the map is an incredible tool for 'overwhelming' things as well as, imho, incredibly fun.