Codewalker

I said not many, I didn't say 'none'.

(though the values I posted above are from a much more reliable place than the string table dumps that people usually spot things like that in)

Um... somewhere reliable.
So much attention has been focused on the data tables in the piggs that not many people have looked elsewhere, to find those elusive missing bits of info that are compiled in through auto-generated headers.

MaxMax, et al aren't attributes in the same sense of the word. They aren't maintained on a per-entity basis like the 5 aspects are (possibly 4 if Abs is a pseudo-aspect). Those are defined in the class tables and are static data that never changes. There's no such thing as a MaxMax buff.

Things that are defined there apply to every entity that belongs to its class, whether it's a player archetype or a NPC class. They are.

Per-class attribute info
(these exist once and are static across all levels)
AttribMin
AttribBase -- the starting value for the attribute
StrengthMin
ResistanceMin
AttribDimin[Str|Cur|Res][In|Out] (PvP diminishing returns)

Per-level attribute info
(these are still per-class, but come in a table form that defines values for levels 1-50 for players and 1-55 for NPCs)
AttribMax -- the starting value for the attribute's Max aspect
AttribMaxMax
StrengthMax
ResistanceMax

I think it's been around at least since CoV. At a glance some very old powers use OnActivate (5th column inherent resistances), so whenever it was added, the defaults must have been populated from whatever used to determine that behavior.

Technically the engine has separate flags for whether resistance (and combat mods) affect magnitude or duration.

Practically, and this is something I went back and forth with Arcana on a while back, it seems that these flags are automatically assigned by whatever tools the devs used to compile the data. So effectively it is based on the type of the effect. IIRC, based on datamining, I determined that there is a fourth option -- if a Constant type effect is resistible, both its magnitude and duration will be resisted.

Constant attribmods are ones where the Scale is not used at all; instead the base Magnitude and Duration from the power definition is used. They're fairly rare, however, and almost always use one of the 'special' Attribs that isn't really an attrib at all, like GrantPower.

It's the Type field of the attribmod. I don't know of any way to directly determine that in-game, though real numbers gives you some clues based on how it formats the numbers.

CurAbs is just an alias for Abs. I have no idea how often it's used, as we only have the binary representation of the data, not the source text files that it's compiled from.

Many of the constants in the game engine are prefixed with 'k'. That doesn't really mean anything, it's just a convention that they used for some of the constants. Probably because all of them go into a giant global hash table, and it's to try to prevent the inevitable namespace collisions.

Here's the binary representations that are defined for attribmod type:
kCurrent=0x00000000
kMaximum=0x00000004
kStrength=0x00000008
kResistance=0x0000000C
kAbsolute=0x00000010
kCurrentAbsolute=0x00000010
kCur=0x00000000
kMax=0x00000004
kStr=0x00000008
kRes=0x0000000C
kAbs=0x00000010
kCurAbs=0x00000010

You'll notice these are separated by 4. The normal attribs themselves are as well. For attribs, the ID number also doubles as an index into the memory block where the attributes are stored (32-bit single precision floats). My theory is that on the server side, it keeps a separate copy of that block for each aspect, so the server keeps 2300 bytes worth of data on hand to describe the combat state of every entity. That's 115 attributes * 4 bytes = 460 bytes * 5 aspects = 2300.

Meter (aka kMeter) is an attrib just like HitPoints or Endurance. The client uses it to draw the 'tertiary bar' for things like Fury or Domination. It's one of the few attribs that is kept in sync between the client and the server, because it's used for the UI.

'Rage' is the attrib that is actually granted by things like Brute and Dominator attacks. Brutes have an inherent power that on every tick gives them Meter based on how much Rage they have. IIRC, the damage buff is based on the current value of Meter, forming a kind of feedback loop (which the inherent power that handles Fury decay takes advantage of).

Now that I think about it, that probably depends on the ApplicationType of the attribmod. If it's OnTick, it'll try to reapply every tick, but if it's OnActivate then it will only apply when the power is first activated.

Not sure if serious...

Wait, how can that possibly work for defense?

Max for the attack type attribs increase as you level, that much is evident from the class tables. That hard cap seems to apply even though all the buffs are Cur. Or do you think the code that handles defense just reads Cur and clamps it to Max explicitly, ignoring the normal logic?

Mezzes, and by extension mez protection powers, are Cur effects with a limited duration. As are defense buffs, movement speed, and just about everything except for damage, come to think of it.

Cur applying as a percentage of anything seems to be a quirk of the implementation and as far as I can tell only applies for certain attrib types (damage, endurance, hitpoints). The Cur effects for defense powers certainly don't end up adding a percentage of the defense cap for that level.

Arcana beat me to it, but CoD reorders some of the effects in order to make the display a bit friendlier to read. It generally preserves the order within a certain target type, but does change it in order to group effects with a certain target together. It also tries to merge together similar effects to present them on a single line, such as damage, defense, or mez types, if they're "close enough" (generally with the same Scale, duration, and a few other things).

So don't depend on city of data being accurate for the exact order that the engine applies effects in, as it intentionally lies about that in some cases.

Don't forget there's multiple versions of that flag.

There's the "ignore outside buffs" flag on powers that still allows enhancements slotted in the power to work, but ignores outside strength buffs.

There's the "ignore buffs and enhancements" flag on individual attribmod/effects that ignores ALL strength buffs, even ones that come from slotted enhancements.

There's also the "list of attributes to disallow buffing" on the power, where if you put say, Recharge or Range in that list, the entire power will ignore all strength buffs to that particular attribute, whether they're from enhancements or outside buffs.

It's also important to note that those addresses are not the personal addresses of the people indicated. We're not bothering them at home. They are @ncsoft.com, so even though they may be obfuscated, they are still business addresses. They are there to be used for things relating to NCSoft business, and that's exactly what this effort is.

I don't think the line that many people think is being crossed is actually one at all.

All evidence to date shows that the positive, well spoken members of this community outnumber the naysayers by nearly 10 to 1, and the trolls by even more.

Like it or not, the information is out there now. The trolls will be trolling. Our choice now becomes whether to drown out that unhelpful signal with something better, or stand still wringing our hands worrying about it and doing nothing.

We can't afford to do nothing anymore.

The decision was made before my time, and I never pushed to have it changed. As far as I know, it was made so that the public-facing data was only things that could reasonably be determined by player experimentation (albeit a lot of it). Over time that eroded slowly as things like the exact text of the conditions became shown, but that was less of an issue since they were integral to the way that the powers function.

Also, going strictly of secondhand information here so I may be way off, but I was under the impression that getting in trouble for leaking NPC powers from the Hami revamp was part of why Iakona "left".

Probably because all of the animation data is specified in terms of frames, and there are 30 frames in a second. That and discussions with a developer who worked primarily on the animation side of things.

30hz would be awfully inefficient for a combat loop just because of how much time you'd spend re-evaluating things that don't really change all that often, relatively speaking. The server DOES have to process animations, if for no other reason than to figure out how long to root a player, since the only place that information exists is on the flags of the animations themselves (the ones flagged CantMove). Not to mention the timing for things like weapon redraw.

I think it's been fairly well established by information posted by developers that there are two separate loops going that interact with each other periodically.

We have access to that, just haven't advertised it. Come to think of it I'm not really sure why the client would possibly need that data, but I guess I can't complain that it was included.

That's an RPN expression, which I alluded to earlier as they are used extensively throughout the combat system. From deciding whether or not to automatically grant you powers when you log in, to if you can access a particular power set or pick, or if certain effects of a power apply or not (think combo levels, Disintegrating, Dual Blades combos, and just about any other dynamic behavior a power can have).

City of Data pretties them up a bit before displaying them as conditionals -- it contains a parser that re-arranges them into algebraic notation. It also evaluates them in order to try to figure out if a certain effect is PVP or PVE-only, and whether or not to count it in the "average damage" total.

Incidentally, I did write that parser over a weekend, but it's a grossly simplified version. It implements all of the grammar I believe, but when evaluating most of the variables just dummies them out as zero or a predefined default.

No, I wasn't. Diellan is in charge of the Mids code. I helped out a tiny bit here and there, mostly with suggestions. I was involved in planning the project to eventually write an HTML-based replacement for smartphones, tablets, and desktop, but it never got especially far.

The Mids database is somewhat far removed from the actual source data, just because a lot of the special case stuff was written before some of the mechanics were fully understood. For a long time it was populated by TopDoc's csvs, which I assume are dumped from the bin files.

The source code was originally written by Mids -- who the name comes from. He allowed a few people to maintain it after he stopped playing, on the condition that it remain closed.

I did take over maintaining City of Data a about a year and a half ago; and started producing our own bin dumps internally. Mids was switched over to use those about 8 months ago IIRC. I have a pair of programs that dump the powers data (the full attribmod/effects data was not included in the client until Real Numbers was added in around I12.5). One into a database format compatible with City of Data, and the other into TopDoc-compatible CSVs for Mids, with some cleanup of the misnamed fields and attribs, and a few extensions added later like PPM.

Neither form completely represents the true state of the data, which was compiled by the devs from simple text files. From what I've gathered those text files were generated out of Excel by some custom tools.

PS: I apologize if yours was one of the PMs that came in requesting powers data that I ignored. Due to the nature of obtaining it, which technically went against the ToS, it wasn't something that we really talked about outside of a small group. Unfortunately that made some people seem a bit cliquish, but it was a necessary evil given the sensitive nature of the work.

And all the newer chaining powers -- from reworked Chain Induction to Electric Control and forward -- use pseudopets that have a single power with a spherical AoE and 1 or 2 target max -- a power that in most cases does damage and summons another psuedopet for the next hop.

There's often more than one way to skin a cat with the engine. Dual Pistols probably could have been reworked with the newish "OwnPower?" RPN conditions and work exactly the same, while being completely different behind the scenes.

There's some attribs in there that never got used at all. PowerChanceMod finally made an appearance when Overwhelming Force was 'nerfed', it apparently works like GlobalChanceMod but is limited to a single power like the name would imply. Normally pretty useless since it doesn't extend outside the current power, but when used on an enhancement it makes it only apply to the power that the boost is slotted into. That also partially confirms one of my theories about how enhancements work internally, but there's still a bit of mystery to it.

Not to mention all the possibilities that hooking Lua up to the powers system could have offered...

(I've brainstormed this quite a bit myself, as for the eventual Mids successor I wanted to push for doing a more accurate simulation of the combat system rather than a ton of special cases that are a PITA to maintain)