Arcanaville

That's technically not true. Technically speaking, Magnitude Resistance decreases magnitude using the Scale * (1 - Res) formula. Duration Resistance decreases duration using the Scale / (1 + Res) formula.

Which one you use is based on the type of the attribmod. This is another important feature of the game engine. Strength and Resistance all affect the net scale value of the effect. But whether that net scale value is the magnitude or the duration of the effect depends on a type flag. Virtually all mez powers have their mez effects typed "Duration" and that's why slotting enhancements into them increases their duration. Damage effects are typed "Magnitude" and thus enhancements boost the magnitude of those effects, not duration. Its not baked into the attribute type nor the enhancements how this works: its keyed off a type field.

Interestingly, mez protection buffs are often typed magnitude, not duration. That means in theory if you could slot them with mez enhancement, your protection would get higher. You can't do that, so you can't see this effect. But you *can* see this effect if you have someone Benumb you in PvP: that will cause your mez protection magnitude to actually go down, because those debuffs affect mez strength, and that strength reduction in turn makes your mez protection pulses drop in magnitude, because they are typed magnitude.

In any case, this is just an informative tangent. The obvious reason why 10,000% equals confused dev is because someone put "100" into the powers spreadsheet for that resistance, thinking "100% resistance" when the correct thing to do was to put in "1.0" which is 100% resistance. This error was never corrected, because there's no obvious sign of a problem when you make this error: both make you absolutely immune to all (except unresistable) knockback. Because knockback effects are generally typed "Magnitude."

Moreover, at the beginning of time the res cap was 1.0 all around, so even though duration resistance could logically use higher values, higher values were not possible. cf: Hamidon.

The rule is: Strength and Resistance can only affect Magnitude or Duration, not both, and both always affect the same thing. So if slotting enhancements into KB powers increases the mag of the KB, KB resistance reduces the mag of those same powers. They go together because of a fundamental property of the way the game engine handles scale values of powers.

Coincidentally I was just starting to write some code for my attribmod engine and was thinking about that specific issue. Because for efficiency sake, it makes no sense to push around all the data for the attribmods; in a practical sense attribmods are static and all you need is to use pointers to them. That's almost certainly what the actual game engine does. But you do need to pass one piece of information around: the effective scale value of the attribmod when its instantiated. And that's because it will be modified by the entity's tables (usually) and the entity's strength. But you can precompute that because an attribmod's net scale value is immutable upon creation. It can be affected by variable target resistance, but not by variable caster strength.

Thus, you end up with something like this:

I believe that is the minimum amount of data you need to dynamically track for an attribmod: the rest is power database lookup. Technically, powerId is redundant, but I have a feeling for efficiency purposes I'm going to want to keep that around for the stacking code. Trigger time is a repurpose: without a powers engine surrounding the attribmod engine, there's no way to tell the engine to do a sequence of events. So I need that to allow for injecting a set of attribmods to simulate a sequence of powers. But that's not wasted code because trigger is just going to transmogrify into attribmodDelay tracking in the general case.

After 1.5 hours of coding, I have a data import routine for archetype tables, some class stuff for entities, and the definitions for basic attribmods. In terms of actual code that does something, here's what I got:

No, I'm not kidding. I believe if you don't start with thinking about clocking, you're screwed. Thinking about how I was going to track time led me to think about activation periods and attribmod expiration, and that led me to think about managing attribmod lists, and that led me to think about the minimum amount of data necessary to track an attribmod in a pseudo-queue, and that led me to think about entity structures, and that led me to decide to write an archetype data importer, and that brought me back to attribmod queues, and that led me to think about Scale computations, and that will lead me to getting ready for bed.

71 actual lines of code, ~90 minutes. Going to try to tackle Abs, Str, and Res tomorrow. I have an idea on how to manage Cur without having to track a lot of funky exceptions, but that will require more algorithmic thought.

Except that feature is relatively new, so that had to be arbitrated some other way in the past.

Well, I had a hint there were Cur/Abs issues going all the way back to beta when I realized melee had 10,000% resistance to knock.

I would have had at least two separate devs on my side to tackle refactoring this part of canon, sigh.

Except, Tim, that doesn't fully explain how its possible to devour or destroy a Well permanently. That would seem to be impossible under that theory.

The ability to speak and read English is a lot more common overseas than speaking and reading anything but English is in the US. But on the other hand I know someone that speaks pretty good Chinese and can't read it at all.

I believe that was painted across the Donner party's wagons.

I'm sure it was having a significant effect, but I am unaware of any human beings that react to being bombarded with unwanted emails by seeking out the senders to commiserate with them. Its important to remember that when considering putting NCSoft on the defensive, we have no actual offense. If they decide to dismiss us permanently, its over: we have no actual counter-move that reverses that in seventy days.

Did we even know with certainty that the email targets read English?

I'm not as consistently optimistic as Tony appears to be, but I respect the fact that he's riding a very fine line between attracting the attention of the right people, and doing so in a way that pisses them off. Being ignored is bad, piss off the wrong people and its all over, and we will never even know it happened.

I would say that is the most likely circumstance. That shouldn't stop people from sending emails anyway, since all player efforts are extreme long shots in the first place; in that respect the long-shot chance that you happen to be the player with the eloquence to get past the mail reviewers and reach an executive is no more of a long shot than anything else.

What is important to realize is that is the problem you're facing. The problem is not expressing yourself to an executive. The problem is expressing yourself to a screener in such a way they decide to pass your message along. Anything you write that isn't designed to convince a screener to pass your message along directly or indirectly might as well be written on barbeque kindling.

Its the ultimate bank shot: you have to say the right thing to cause a screener to pass your message to a decision maker, such that when the decision maker processes the exact same message causes them to think twice about the shutdown. That's a one in a billion email. On the other hand, expressions of outrage and venting have a zero percent chance of even reaching the targets of that expression, which makes them pointless.

Well, its almost impossible to make them any easier to get.

Zwill, I think you know exactly how I parse this, so let me just say thanks, and seriously, w-t-f. I think you can apply those two sentiments appropriately.

That's a good question. It seems unavoidable that this requires special handling. Actually, now that I think about it specifically, I wouldn't be surprised if Cur *normally* worked on the range of 0.0 to 1.0 and it was specifically the attributes tied to HitPoints and Endurance that had special handlers. It would explain some of the attribute structure in the attribute tables.

It wouldn't feel like our Lore otherwise.

No good. If you have an effect on the target that is resistable, and then the *resistance* expires, you have to recalculate all of the resistable effects. In the general case, you have to recalculate the attribmods for every tick of time in which its theoretically possible for resistance to expire, and dealing with this with special cases just makes things more complex. It makes more sense to recalculate attribmods on every tick of the clock. Otherwise, you're just asking for problems. And I haven't really fully thought about whether there are other failure modes besides expiring resistance, because it would never occur to me to take this short cut in the first place, because its already known to be broken.

Endurance has both Abs and Cur applied to it. And in fact, Cur modifications on Endurance are permanent. Which actually creates an unanswered question for me: are endurance cur effects flagged to be permanent, or does the game engine presume Cur effects on Endurance are permanent automatically? Both are theoretically possible at the moment, although I suspect its the latter that is true due to a bug that occurred several issues ago that demonstrated what the game engine does when you apply a Cur to health with a duration inadvertently. I would personally code it that way without direct evidence to the contrary.


The game engine doesn't deal in percentages at all. 1 def would be 1.0 def, which would in effect be 100% defense, but the game engine calls that 1.0. For reference, Focused Fighting offers a base 0.13875 buff to Melee_Attack Cur. To be more precise, it offers 1.85 Scale buff to Melee_Attack Cur, using the Melee_Buff_Def table. For Scrappers, that table contains 0.075 for all levels. So Focused Fighting offers a net 1.85 * 0.075 = 0.13875 buff to Melee_Attack Cur, which we players call "13.875%"


A Cur buff is Scale * Max in value.


I don't think it is, for the game engine to work in the general case. I believe the special case logic required to do anything else would not make the alternative significantly faster without breaking things.


Attribmods are time dependent effects, and there is no such thing as an effect separate from attribmods in the City of Heroes game. Attribmods are effects: Attrib-mod: Attribute-Modifier. They are the only mechanism for producing an effect in the game.


I'm aware of all that, but my comment stands. Based on what I've seen, there's no way to extrapolate this effort into a full combat engine in four weekends of work; there's no way to extrapolate this effort into even just a full attribmod calculator in four weekends of work: I'm dubious its even possible to extrapolate this into a stripped down version of an attribmod calculator that excludes extensions such as expression evaluation and entity spawning in four weekends. I still believe you're vastly underestimating the scope of the problem, and your code is doing much to narrow down the margin for error that exists for how fast you could possibly do it.

You're a goaltender in the NHL.

If only the gaming gods were that kind.

To be candid, if I ever actually found myself working on another MMO, I don't think you're able to recognize my design signature. You'd only know I was involved if I said so explicitly.

To elaborate, I'm unaware of any attempt to build a CoH2 by any former member of the Paragon team, or any other developer.

I said public because I have had a few private conversations with a number of the Paragon team after the shutdown, the contents of which I will not divulge. However, I am not in any way coyly suggesting the team is working on, or has approached me regarding, either continuing the development of City of Heroes or any explicitly stated successor. I have no explicit knowledge of that one way or the other.

All of them are. Movement buffs are sometimes Cur. Defense buffs almost always are.


Yes and no. The way the server works, the engine does an unresistable pass and computes intermediate results for resistance. Then it does a resistible pass and computes all other values given the intermediate resistance. In other words, lets say you have a target with 80% resistance (to something) and it gets hit with a -30% unresistable resistance debuff and a -20% resistable resistance debuff. The game engine calculates the target's intermediate resistance based on all unresistable effects, and gets 80-30=50%. Then it calculates the effects of all resistable effects given that resistance: the -20% debuff is reduced to -10% because of the effective resistance at that moment, and the final resistance drops to 50-10 = 40%.

However, one clock later, the server starts over. It does not start with the target having 40% res or even 50% res. It starts from scratch, recomputing the target unresistable resistance: 80% - 30% = 50%, and then applying the resistable resistance (de)buffs 50% - (20% * 0.5) = 40%.

Even if you punt the actual mechanics of the clocking, the code doesn't seem to even have any hooks for clocking. It applies effects in a way that makes it difficult for them to expire in random order, because the effects are entangled with resistances. You could create an expiration queue to basically apply the inverse effect upon expiration, but you have to be very careful to honor intermediate floors and ceilings when you do that. It seems very likely that this code doesn't just omit clocking, it isn't trivially extensible to being clocked.


I did say that, but being able to calculate "moment by moment" is exactly what it sounds like. You don't need to implement a clock, but you should be able to state what the current attribute values are for a *given* moment. If I say "+1.2 seconds" the calculator should be able to say. But it can't, because its not just unclocked, its completely time-unaware. And a completely time-unaware scale summer is something I could do in a single afternoon: that's an extremely tiny component of the whole. Its so small I would never write it time-unaware, because of the strong possibility my code would not be extensible to a clocked environment.

The engine has to be aware of the fact that Abs modifiers are permanent, but Cur modifiers are not and have to be able to be reversed at some moment in time. It has to be aware of activation period for attribmods that have it. That's all part of the attribmod engine, and I don't see how you are rationalizing it as part of the "powers" engine. The only thing that makes any sort of sense is you're thinking of making the attribmod equivalent of micro-ops and breaking down time-dependent attribmods into micro-attribmods and clocking them outside of the micro-attribmod engine. Which is fine, except that doesn't allow you to redefine the scope of the problem to be writing the micro engine, because that eliminates the bulk of the complexity of the problem.

No one says its impossible. What is true is all non-experts think they are far better than they actually are. In fact, most of the experts tend to think they are better than they actually are also.


That's a fair point. I'm working the next two weekends, so I'm going to try to steal some nights and write an attribmod calculation engine. My guess is that given the context we're talking about, that's about 40-50 hours of work for all except the expression engine, entity spawning, attribmod distance effects (basically, inner and outer radius), and boost templates (basically all attribmods will be assumed to be flagged to be powers not enhancements). Maybe some other little flags I'm not considering, like the set bonus ones.

Lets see how long it actually takes.

Conceptually no, but in City of Heroes that is a dangerous path to take - completely decoupling effects from powers - because in the general case it can cause balance issues. And it would be very difficult to manage this sort of gameplay option when you have to constantly explain exceptions to players, who will in the general case never accept your explanations for exceptions.

CO isn't offensively balanced in quite the same way, and is less vulnerable to this type of problem. Even so, there are still strong limits on how much of this sort of thing you're allowed to do. The intrinsic core behavior of the dev-designed attacks tends to remain the primary behavior, and the modifiers tend to be just that, modifiers, at least to the extent I've seen. But you stick Fire's DoT on Claws, or Sonic's res debuff on a fast set like Psychic Blast, and you've created fundamentally different offensive sets in City of Heroes.

I am unaware of any public statements addressing that topic specifically.

While my idea describes the technology, I hope the presumption is that the way this technology would initially be used is in a way that encourages "cloud play" even if solo. And the intent of the server technology architecture is not intended to imply the game would naturally be run on a blizzard of thousands of tiny servers, but would under normal conditions be run much like any other MMO: with servers operated by the game owners. Alternate servers would be secondary options, and a fallback if the primary servers were temporarily or permanently unavailable.

You totally don't see what Aeon is saying. He's not saying he's taking offense at your criticizing that set, he's amplifying a point you also had to stop and realize:

Consider how much different the final beta version of Bio Armor is from the very first version of beta, which itself was different from the first version dived.

In other words, its one thing to discuss what might have been, but its another to point out flaws in the design equivalent of a napkin doodle. The Wind Control we would have gotten on beta would have probably been a little different, and the Wind Control we would have gotten on live would have probably been significantly different than the data you're looking at. So the version of Wind Control you're posting is really your version, "loosely based on a true story."

Playing at 50 is just a crutch for people who can't calculate attribmods in their head. If I want to jump straight to level 50 performance I just design my characters in the costume designer and then play the game in my head before I go to sleep. It takes less time than PLing on Freedom and zoning is faster.

What makes you think that the one bastion of mathematical clarity on Earth is Korean executive board rooms?