City of Data v2.0

[BillyMailman]

See, I thought that might be the case back when I'd originally asked about this, but when I looked yesterday, it turns out that no, incarnate.hybrid has just the actual Hybrid powers themselves, incarnate.hybrid_silent has the other crap. Same with the other slots. So while the list is ugly, it's exactly the list of powers a character can actually take, so I figured it might be a good (and quick) first pass to just add those.

[UberGuy]

You're right!

 

It looks like I was looking at their display names and not their internal powerset names. "Hybrid_Silent" displays as "Hybrid". Similar thing with "Interface".

 

So with that cleared up, I see no problem with your suggestion.

Edited January 23, 2023 by UberGuy

[UberGuy]

While there are no outwardly obvious benefits from this yet, I can now (re)generate CoD's data significantly faster than I used to.

 

With the old code, building a full dataset for the site used to take about 10 minutes. I would often start it and leave the room to do something else for a while.

 

Now it takes about 2 minutes.

 

This is due to a combination of things.

 

• Code changes mean CoD's ingestion of data from the Rust language bin parser sped up dramatically.
• Code changes mean CoD's writing of JSON data out of Python sped up a little
• I have a new home computer. My old one was about 11 years old. While I bought the same nominal model of Intel CPU, it's 11 generations newer.
• I run my CoD development in a Linux VM, and that VM is running from an SSD. It did on the old computer too, but it was a SATA attached SSD running from a USB3.0 dock. The new system has the OS and any VMs running from internal NVMe SSDs. which have something like 5x the sequential write speed before considering the old drive was USB attached.
• Edit: I also upgraded the version of Python in use from 3.8.2 to 3.11.1. The 3.11 version of Python had some significant speedups, and in the general case it's about 15% faster. Note that this would only affect stuff in CoD's codebase that's pure Python (of which there is a fair bit).

 

The code changes were because I did finally come across a data serialization/deserialization library for Python which I had not seen before and which was worth gutting the code to swap it in.

 

• The new library has excellent speed compared to the library I was using, which I knew was among the slowest.
• The new library is much simpler to write code for.  I reduced the data model codebase by about 50%.
• The new library calls for the use of "type hints". More on that below, but this is something I wanted to add to CoD's Python codebase for a long time but the effort wasn't worth it without something like this to motivate it.
• The new library interfaces with one of the fastest JSON parsing libraries available to Python. I was using the 2nd fastest (depending on benchmark) previously, so not a lot changed here, but the seamless integration in the code is nice.

Basically this really speeds up debugging, especially for code that doesn't run until all the game data is parsed and ready to use. You can imagine the annoyance in debugging such code previously since I hadn't gotten around to adding any "extract just this bit of the data" logic. It also helps since I plan to add more data extracts / transformations - those will add to the run-time, but now adding to a much smaller base.

 

Re: "type hints" - like most mainstream languages, Python is a "typed" language, meaning objects are of specific "kinds", where their kind determines what you can do with an object. You can multiply numbers, capitalize strings, sort lists, and so on, but you can't sort a single number, capitalize a list or multiply strings. But while Python cares what objects are and can do, it doesn't generally care where you store them. A lot of languages are "strongly typed" and require you to say (for example) "X is a variable that you can only put integers into." Python is like, whatever, man, you can store anything anywhere. Which is great for fast prototyping but not always great for complex codebases where you might assign the wrong kind of object to a variable, and Python won't complain until you try to ask the thing in that variable to do something that it can't.

 

For this reason, strong type requirements are popular, even for languages that don't usually support them. ("Typescript", for example, is a strongly-typed variation on JavaScript that compiles to valid JavaScript code.) Python got on this bandwagon a while ago, and recent-ish versions added a way to specify variable types in the code. You could do before using specially formatted comments and tools that understood how to read them, but these new "type hints" are accepted by the Python interpreter itself and pretty clearly aren't something else (like a vanilla code comment). Python itself doesn't actively do anything with type hints - you could label your integer's "Potato" and it would not care. But Python does update the the compiled code with the type information so that other tools can use it to check the code for correctness in how it uses variables. Well, that's the main intended use. The new serialization/deserialization library, for example, uses them to know how to transform data. Which is a very handy way to achieve two useful things in one place.

Edited February 7, 2023 by UberGuy

[UberGuy]

CoD's data files and code have been updated. There should be no visible changes to how it displays things, and no live data should have meaningfully changed. I briefly broke the "Attribute Tables" page, but it's working again now.

[UberGuy]

I found and fixed an obscure and fairly long-standing bug that was due to a few critter powers having periods in their internal power names. Previously I had assumed that periods were used as separators between power category, powerset name and power name. Where necessary, I would split "full" power names on periods and pick the last element as the power name. However, a very small number of critter-only powers actually have periods in the power name, causing that heuristic to produce strange results. In one case, the power name ends with a period, meaning splitting on periods and picking the last bit meant the power had a blank name, resulting in a power data file called simply .json.

 

The affected powers were:

v_arachnos.explosive_drone.intangible.
v_security_guards.security_guard_advanced_assaultrifle_butt.adv._assaultrifle_butt
v_security_guards.security_guard_advanced_submachinegun_butt.adv._submachinegun_butt

 

Yes, that first one's internal power name is "intangible dot". That means its "correct" filename for CoD's purposes is intangible..json. (Two dots.)

 

These are the powers' internal names, which for critter powers (especially pseudo-critters like bombs or patches) are often quite different from their display name, if they even have one. This is why I rely on the internal names to create CoD's data files, since using the (sometimes empty) display names would lead to at least very confusing or at worst overlapping power names.

 

It was a little painful to find and correct all the places that CoD's code assumed it was safe to split blindly on periods, but I think I did so. Usually the correction was to split a fully-qualified power name no more than twice. (This still assumes no powercat or powerset name will have a period in their internal name.) Often the correction was simply to not bother splitting the name when I know I shouldn't need to - usually because I know I'm working with a power name. This unnecessary splitting being done in like 5 places, which is a teeny, tiny bit of the codebase.

 

It should be noted that this bug did affect the "raw" JSON power files as well as the massaged ones used by the site to display powers data, so if you are using the "raw" files and had the latest versions you might want to download the "raw" archive(s) again.

[UberGuy]

Updates with new features!

• There is now a "Set Conversions" page. This is similar to the "Boostset Groups" page, but lists sets by the conversion "group" they are part of.
  • One the conversions page you can choose one of the sets in that group that you'd like to see the conversion options for.
  •  When you pick a set to convert, you get additional controls for things like what level of enhancement you want to convert and whether you're converting an attuned version.
    • Attuned versions always convert as though they are the lowest level available in the set, so you lose the slider if you enable this (or if the set exits only as an attuned set, like ATOs).
  • As you change things, sets in the conversion group that are ineligible as conversions you could receive turn red.
  • When a conversion is selected, levels ranges also pop up next to the list of sets, to help make clear why they turned red.
  • The controls and the set / conversion lists default to a wide, desktop browser friendly layout but will collapse vertically on narrow screens.
• On the "Boostset" pages:
  • The "Member of:" line is now a link to the appropriate Boostset Group page (meaning you can go right to a list of other sets in that group).
  • The "Allowed Conversions" entries are now links to those "Set Conversions" pages.
• On the "Boostset Groups" page:
  • The list of groups on the bottom of the page finally sorts top down then across instead of across first then down.
  • The lists should still collapse vertically on narrow devices. Having them do this was the only reason I accepted the old sort order (which I found super visually unintuitive) for so long. I finally found a way to make it both work on narrow screens and sort down then across. (Embarrassingly, doing what I always wanted was actually simpler than what I was doing before...)
  • This same "fix" is in use on the new "Set Conversions" page.

The idea behind the set conversions pages and the conversion controls are to allow you to easily see what a set can convert into, in order to make it easier to find smart conversions (or avoid ones with poor odds or poor chances of market returns).

 

 

 

 

 

 

 

Separately, I stumbled across (and fixed) an old bug in the Rust bin parser. It deals with very internal details of how the game code looks up text.

 

Due to bugs over CoH's lifespan, a lot of you probably have some familiarity with "P-Strings". These are things like P2315351 - they're used as placeholders for "real" text, mostly useful to keep from repeating the same text in lots of places. While reading most bin files, both the game and the bin parser find these placeholders instead of the real text and have to have to look up the actual text in a big lookup table that itself is stored in another bin file. You end up seeing the "raw" placeholder when it can't be found in the lookup table where the text for it should be found, which used to be really common because the Cryptic and even Paragon devs had kind of crap tooling.

 

P-Strings get used for "dynamic" stuff, where you have lots of the same "thing" with many different incarnations. Think of things like a power's description, a missions' text or an NPC's dialog. These are things where the texts are created by powers devs or content writers working on those things. Very roughly, the P-Strings are generated from this content by tools that parse it for later building into bin files.

 

But a lot of things in the game are much more static - think things like drop-down or pop-lists menus, or some of the fixed text on various screens. That stuff also gets a keyed lookup, but it's not a dynamically generated P-String. Instead it's a fixed lookup string, probably hand-rolled by a dev. The map from this key to the text is maintained in a flat text file that also gets fed into the bins.

 

The conversion groups for boost sets use these "fixed" keys. "Rarity: Uncommon" is mapped to lookup key ECUncommon. (I presume this stands for "Enhancement Conversion Uncommon".) The other conversion names have similar keys.

 

It turns out that some of the places these keys are defined have different case than the way they're referenced in the game's data. One conversion group was defined as ECPvP, but used everywhere as ECPVP. It seems CoH doesn't care about the case of letters in the lookup keys, but the bin parser did. Believe me, I spent way more time figuring out what that problem was than it took me to actually fix it. I was so confused why some conversion names were correct and some were "raw".

 

It's fixed now, and it probably changed a small number of other things in the game's data. This includes the "raw" data archives (since they basically come right out of the bin parser), so you care about those, grab them again.

Edited February 21, 2023 by UberGuy

[UberGuy]

Fixed a long standing display oversight.

 

Some powers have a collection of effect groups where one is defined as a "default" effect that will be only used if no other effect group in the collection triggers. The other groups might fail to apply because they had requirements that were not met, or they had chances to activate but didn't "roll" well enough to do so. The special group is called the "fallback" group.

 

CoD always displayed the group, but confusingly displayed it without any information about this conditional behavior, making it look like it would always happen.

 

There's now an icon on these groups with a pop-up text explaining this restriction. (The example here is from this power.)

 

 

Thanks to @Bopper for noticing the oversight.

[UberGuy]

Something I've been working on for some time is a way of generating enhancement information programmatically, based on what an enhancement's power definition actually does, and not just taking its name at face value.

 

The reason is that, like many thing in CoH, enhancements follow conventions, not rules. That is to say there are "rules" the powers devs follow when creating them, but the game has zero code-based enforcement for nearly any of them. The HC powers devs do use tools to create and edit powers (far better tooling it seems than the Cryptic or Paragon devs had), and these tools do offer sane defaults and some guardrails, but they still don't require following the "rules".

 

There are ... a lot of things to take into account here. Because of the conventions we see as players, what we think of as enhancements roll up a lot of fairly complex behavior into a somewhat neat package. For example, Damage enhancements always bundle the eight distinct damage types. Defense enhancements bundle the eleven defenses (8 typed and 3 positional), and so on. Heal enhancements bundle boosts for +maxHP, +HP, +regen and +absorb. When you inspect an enhancement's power data, what you see are a bundle of attribute modifiers, not these enhancement names.*

 

Some groupings are more complicated than others. For example, movement enhancements don't all boost the same set of  things. Some include Range (for teleport) and some don't. Some boost jump speed but not jump height, while others boost both.

 

One way to construct an enhancement's name from its attribmods takes a process I call folding, where you recognize a group of attribmods as mapping to a single enhancement "aspect" like Damage, Defense, Heal, etc. You pop out the recognizable groups an build up a name from the aspects. As mentioned above for travel boosts, different groupings of attribmods might map to the same nominal "aspect". You keep mapping groups to aspects until you don't have any recognizable groups left, and then you're left with things that don't usually belong to a group (like, say, Accuracy or Recharge) - their attribmod name is their aspect.

 

Note that this would be impossible general for powers across the board - this really only works because enhancements usually only do certain things. They apply strength aspect buffs to effects in a power.

 

But then we get into procs and "globals".

 

These are much more general powers, and can, within some limits basically do anything. Describing what they do programmatically was really challenging. There's not as much use for "aspect folding" as I describe above, though there are some patterns we see where it's still useful. The process is usually simpler though - powers like these tend to do one thing, and if it's provide a "bulk" benefit like +Dam(All) or +Def(All) that's usually easy to see directly without having to pluck "aspects" out of the bag of things the power does one at a time. But still, procs do a lot of things. They summon entities. Sometimes those entities are "patch powers" that just fire off a power once and then disappear. Other times they grant the caster or the target another power. In both the summoning and granting cases, you have to look up that power and see what it does. And you have to distinguish "patch powers" from actual combat entities like Fiery Orb.

 

"Global' bonuses are a whole other bag - a lot of "global" enhancements do absolutely nothing on their own. For example, the Aegis "F" (sixth) piece provides no actual enhancement benefit. Instead, the Aegis set definition defines a rule which says that having the 6th piece slotted means you automatically get the "Set Bonus.Set Bonus.Aegis: Psionic/Status Resistance" bonus. So to create a display name for that, you need to know this is what happens and know to go look up what that power does, and not just inspect the boost itself. (You'll never see the "global" bonus anywhere if you look only at the raw power definition for the sixth Aegis". You'll see it in CoD's data because I explicitly build that relationship into CoD's data so CoD can tell you about it.)

Finally, the naming conventions we see, especially for procs, globals and other special enhancements are pretty free-form. Writing code that would actually match every name we see is basically impossible, even when the names are right. Mostly, what I've written is very close, if not identical to existing naming standards. Sometimes it's more wordy - I try to limit how wordy it gets, but I've chosen to leave some generated names alone because they are actually informative. For example, the generated names make a distinction between "Chance of A, B" and "Chance of A / Chance of B". In the first case, A and B are linked and only happen together. In the second case, A and B can happen independently.

 

There are two special effects whose generated names I "cheat" on. This was because their conventional name is very well understood but a bit hard to back into from first principles. The two powers are the various "Chance for Build Up" procs (which all grant the same power) and the Blaster ATO chance for +mez res/protection. When I see those powers referenced in a computed effect name, I just emit their known name rather than try to derive it. Given how many special boost effects there are, I'm pretty proud of only needing to resort to that in two cases.

 

Once I threw in some additional logic for inspecting and auditing the rules for expected enhancement scales (think about things like the way set pieces divide boost strength between aspects in multi-aspect enhancements) and I've written around 1800 lines of code just dedicated to enhancements. Now, bear in mind, this is Python code with generous comments and whitespace (4-space indentation and 1-2 line spacing between important sections, plus a lot of data declaration devoted to things like what attribmods make up a boost "aspect". Still, it's a lot of code, and something I've been crafting on and off in the background literally for months.

 

I plan to use this to augment the display of powers that are themselves enhancements (boosts), providing a computed name (as a way to audit against the dev-written display name) plus a bunch of other summary information about the enhancement's behavior. Some of this is nominally obvious from the name, but with these added displays it will be easier to confirm that the boost really does what its name says it does.

 

As of this posting I have not yet updated the site's with the output of this new enhancement parsing logic, but plan to do so in the next few days. I'm still combing over the generated data to sanity check it. So far though, it finally looks good.

 

* To be fair, the tooling does tag effect groups with useful names but they don't always map cleanly / directly to enhancement naming standards, especially once we get into non-boost templates (procs), global effect and so on.

[BillyMailman]

BTW, you may need to triple-check what the Superior Essence Transfer F piece does, and make sure your name stuff handles it properly. As I found out last year, it definitely doesn't work in any way that could ever have been intended, being a 100% proc that gives a power that is a global proc. Not sure what a good name would even be, but it's definitely an interesting edge case in enhancement behaviour, even if it's clearly a bug.

[UberGuy]

4 hours ago, BillyMailman said:

BTW, you may need to triple-check what the Superior Essence Transfer F piece does, and make sure your name stuff handles it properly. As I found out last year, it definitely doesn't work in any way that could ever have been intended, being a 100% proc that gives a power that is a global proc. Not sure what a good name would even be, but it's definitely an interesting edge case in enhancement behaviour, even if it's clearly a bug.

 

It comes out as "Attuned Essence Transfer: Recharge/Chance for +Health". Which seems legit, despite the piece's functional oddity. (I remember discussions about this thing coming up before. It really doesn't seem right.)

 

Edit: While I don't think this piece would trigger this logic, I did have to handle an interesting edge case where you have procs that have < 100% chance to give you a power that has its own < 100% chance of triggering. I forget what thing it was, but I found something with a name that included "Chance of Chance of X", heh. That's silly so I now collapse that down to a single "Chance of".

 

Another interesting case along the same lines is the Preventive Medicine "proc". This is a "proc" more in the old-school "procedural" meaning of that contraction than what we usually mean here for CoH. It grants a global power that essentially acts as a health monitor and fires of the +Absorb based on two different conditions.

• If your health is between 31% and 75 of max it has a 10% chance to give you +20% of your max HP as absorb
• If your health is below 31% of max it has a 100% chance of the same

The name generation for this is a bit weird, but I've left it as-is for now, as it's ... kind of right. "Preventive Medicine: Chance for +Absorb/+Absorb". It works out that way because the naming logic doesn't have any handling for non-random conditional behavior. It sees both a non-100% chance for +Absorb and a 100% chance for +Absorb and lists them both. Which is ... kind of legit - I can't think of any of the existing proc/global names handling conditional logic either. (The dev-granted name for this thing is perhaps less confusing, but it's much more opaque.)

 

Another similar example I've caught is the Kheldian form bonus global.  It comes out as "Attuned Kheldian's Grace: Recharge/+Dam(All)/+Max HitPoints/+Res(All)". Now clearly it doesn't do all those things at the same time - what it grants is a function of what form your're in, and again the code doesn't process conditiions. But I'm leaning towards leaving it as-is, because it really is a lot more informative this way.

 

I could give in and just put these pieces in the same bucket I did with the "Chance for Build Up" procs and hard-code their dev-granted names. Or, maybe there's a concise way to say "Conditional X / Conditional Y". I'd prefer a shorter worth than "Conditional" but maybe that'd be OK. It's not like "Chance for" is super short either.

Edited March 8, 2023 by UberGuy

[Bionic_Flea]

6 hours ago, UberGuy said:

Or, maybe there's a concise way to say "Conditional X / Conditional Y"

 

Maybe: "If X/If Y" as in "Chance for +Absorb If health X/or If health Y" for the Preventive Medicine?  But does it have to have an awkward name as long as the details give the correct info?

[UberGuy]

3 hours ago, Bionic_Flea said:

Maybe: "If X/If Y" as in "Chance for +Absorb If health X/or If health Y" for the Preventive Medicine?

 

The problem there is that I'd have to start parsing expressions to turn into plain-ish English wording, which is a level of challenge I don't think I'm up for (or that probably makes sense to invest in this feature - I realize this is already super gold-plated). I believe to achieve that realistically I'd just end up having to build special case handling, like looking for certain operations (comparing your health to thresholds for example) and hope they weren't buried in something more complex that changed their meaning. At that point I think the right thing to do would just short-circuit most of the process and say: "If this power, say this effect description."

 

An alternative I was noodling for handling things like Preventive Medicine is saying that if we see the same effect (like +Absorb) with both a 100% chance and a non-100% chance, but both with (different) conditions, just report that simply as a single "Chance of X". 

 

Quote

But does it have to have an awkward name as long as the details give the correct info?

 

No, but I do rather like the idea of having a more accurate name as a summary of the effect. Fortunately, most effects aren't so silly as the few examples above. They're definitely outliers.

[UberGuy]

Whoops. It seems like some of my recent updates broke the "set bonus finder" part of the site. I changed some of the data layout (merging a couple of repetitive data files into one that included both but was smaller overall) and forgot to update the logic for that page. The fix was really easy, once I noticed it was busted, but it's probably been broken for a few weeks. 😜I'm guessing a lot of people don't use that or maybe people who noticed it was busted just don't post here.

 

In somewhat related news about fixing busted things, I went through nearly all of the Python code and applied type hints, when then let me run a static checker against the code. This did a number of things. First, it forced me to better document what all the variables in the code are, which then the checker could verify I was using as intended (or not). Nothing like being told "Hey, you said that was an orange, but you shoved a box of wrenches into it." to make you wonder what your code actually does. Most of that kind of thing was just me having documented the variables badly, but it sometimes made me realize the code was fragile due to not actually verifying what was in some dynamic thing before using it. (The most common example would be assuming a thing is not "null" when it technically can be.) But most important,, this exercise cause me to find a few typos that were syntactically legal but meant the data didn't contain what I meant it to. For example all the AT data on the site was missing inherent hold protection values, because I typo'd the word "hold" as "hlod". (In case you're wondering that only matters for critters - the value is always 0.0 for character ATs.) 

 

I've also been doing some setup of my home dev environment that will ultimately make it a lot easier to update the Alpha and Live datasets independently. For example, if I update the code to parse new data elements that the devs add in alpha, it effectively breaks the parser for live data since those new elements would be missing. It's not exactly hard to deal with this, but I didn't originally set anything up in my environment up to make it easy. Right now that's still a small pain, but it's already way simpler now than it was say a year ago. just because my data build and deploy pipeline logic is better.

 

The logic for CoD (back-end and front-end) still needs decent unit tests, so I can more easily notice when my code changes break something. Making the code more "testable" will almost certainly involve reorganizing it, so this stuff I'm doing now lays groundwork that will make that easier and itself less error prone.

 

Edited March 20, 2023 by UberGuy
Typos

[UberGuy]

CoD updated for today's patch.

 

There's new CoD features in the works, but my hobby coding time a little thin currently. Hopefully I can provide some useful updates in the next few weeks.

[UberGuy]

Some very minor, mostly cosmetic / behind-the-scenes changes to the site today.

• The HTML pages on the site were lacking a tag that ensures browsers treat them as modern in terms of features. I added this tag to all the pages, since I have long coded the site to expect modern browser behaviors.
• The "copy link to this page" feature actually wasn't using a modern approach, and the above change made some of its hacky nature literally visible. I updated the mechanism involved (which is much simpler now, honestly).
• The "overflow cells" present on some pages (where the cell content overflows out of the cell on hover so you can read really long names) used to displace the cells to the right, making the visual extra janky. It no longer does this.

It's possible that the first bullet point might break things I didn't expect and didn't test. If you see weird behavior (especially if it seems to be new weird behavior), let me know!
 

Edited April 29, 2023 by UberGuy
Typos

[UberGuy]

Something I need to start working on is a kind of significant rewrite of the website. Not the data extraction back-end (which is in decent shape right now), but the actual web-specific stuff that runs in our browsers.

 

When I wrote CoD, I was relatively new to web front-end design. I knew my way around HTML and CSS, and was mildly dangerous with JavaScript. While the approaches I used in the website were (usually) not bad, they did sometimes suffer from various naivety about the best and worst ways to do things.

 

Modern "serious" website design done by companies use a lot of tools and tech. Using these tools basically mean you don't really use plain HTML, CSS or JavaScript when creating a site. You usually write in something that looks like these things and which your tools will convert into the "real" thing during a sort of compilation stage. This "transpiled" and bundled code is what you deploy and is served to end users by your web servers.

 

When I started working on CoD, I was aware of a few of these tools, but not at all familiar with their hands-on use. In order to get CoD off the ground quickly, I found a way to create the website that bypassed them. There's nothing too terribly wrong with what I did, but it does mean that I have to craft a lot of HTML and CSS in something of an "old fashioned" way, losing the benefit of a lot of modern tools that could streamline the process or simplify the results. I also have to write "pure" JavaScript, which has been super useful as a learning experience, but again this denies me some tooling benefits.

 

CoD's dynamic web-page functionality is based on a web framework called Vue. It's really not the most popular framework of its type, but definitely has an active community and it was probably the best framework at the time (and maybe still) for a newcomer to get into. At the time I created CoD, Vue version 3.x had been out for some time, but version 2.x was still very common, and most of the third-party Vue "widgets" and also Vue how-to documentation on-line was written for Vue 2.x. So CoD was created using Vue 2.x.

 

Nowadays there's a lot more Vue3 stuff out there, and Vue2 will cease to be supported by its makers at the end of 2023. That means info and widgets for Vue2 will become harder and harder to come by. If I want to keep the site modern, I should rework it to use Vue3.

 

After creating and maintaining the site for several years, I am not as green as I was at the beginning, having more exposure to the bundling / transpiling tools I mentioned above, so if I am going to migrate to Vue3, I think that's the right time to also tear off the other band-aids and build CoD with more modern tooling. The site itself should be simpler to maintain, though the tool setup to update and deploy it will be a bit more complex.

 

When this happens it will probably be a big-bang kind of thing. By that I mean I will probably build a parallel version of the site and eventually "throw a switch" to transition between them when I think the new site is ready. If I do this well, the switch should be reversible, so I can revert if the new thing breaks badly. The goal though will be fully demise the Vue2 version of the site and not update it any more - new CoD would only be written the "new way".

 

There probably won't be an big or immediately visible benefit to y'all, which is a big reason I've put this off as long as I have. But like several other changes I've made recently, this work should eventually mean I can iterate faster on future site changes, with better confidence that the changes didn't break something unexpected.

 

Edited April 30, 2023 by UberGuy
Typos

[AboveTheChemist]

I found an issue that, while minor, I thought it might be worth pointing out. There is an enemy NPC called 'RIP Official' (Rogue Island Police group) in Mercy Island that doesn't show up in an entity search on the site. I searched through all the entity JSON files (from the downloaded CoD archive) as well and can't find an enemy NPC with that name.

 

I also searched through the leaked i24 data and found some info on the Rogue Island Police NPCs, but the names are all P-strings in that data. Unfortunately, I don't have a way to correlate the P-string to the actual text.

 

I've attached a screenshot, and these NPCs are found in the general vicinity of [-2414.0 240.4 296.0] in Mercy Island if you want to see them in game.

 

 

I thought it might be the NPC that belongs to rogueislandpolice_officer_official.json, but the NPC in that file is named 'Ripper'. The 'Ripper' name is also used by the enemy NPCs in the various level ranges of the rogueislandpolice_officer_<level_range>.json entity files.

[Number Six]

6 hours ago, AboveTheChemist said:

I found an issue that, while minor, I thought it might be worth pointing out. There is an enemy NPC called 'RIP Official' (Rogue Island Police group) in Mercy Island that doesn't show up in an entity search on the site. I searched through all the entity JSON files (from the downloaded CoD archive) as well and can't find an enemy NPC with that name.

 

It's this guy

 

https://cod.uberguy.net/html/entity.html?entity=rogueislandpolice_officer_official

 

Mercy Island has a few custom spawndefs for that entity that override the display name.

[UberGuy]

6 hours ago, Number Six said:

 

It's this guy

 

https://cod.uberguy.net/html/entity.html?entity=rogueislandpolice_officer_official

 

Mercy Island has a few custom spawndefs for that entity that override the display name.

 

Interesting! I don't think I have any way of getting that info (the overrides) client side, either. Is that correct?

 

Edited May 6, 2023 by UberGuy
Clarification

[UberGuy]

Updated CoD for Tuesday's patch. Not a whole lot of powers changes in there, but definitely some (as the patch notes indicate).

[Number Six]

1 hour ago, UberGuy said:

Interesting! I don't think I have any way of getting that info (the overrides) client side, either. Is that correct?

 

That's right. Since the entity names get translated when they're spawned and sent by the server as-is, they might not even be in the clientside messages at all.

[Nitrogen]

Hello, I'm looking for information about the chance to hit values of enemies, do you know where I could find this information? The wiki provides us with a table for the character's to hit chances but nothing concerning the enemies.
Thanks for your help.

[Bionic_Flea]

@Nitrogen:  "Hello, I'm looking for information about the chance to hit values of enemies"

 

In CoD you can look up any NPC to see what powers they have.  For eg.:  https://cod.uberguy.net/html/powerset.html?pset=praetorianresistance.boss_officer

 

If you look at his powers, you'll see a list and then can click the power for more info.  His aimed shot has a base accuracy of 1.05 and Overcharged Shot has a base of 0.9.  So even within NPCs different attacks can have different tohit.  And this particular critter also has "Leadership", which is essentially like Tactics on a player.  So he and all his allies will have bonus tohit.

 

From the Wiki article here we get: (https://homecoming.wiki/wiki/Attack_Mechanics)

 

Quote

The master hit chance formula is:

HitChance = Clamp( AccMods × Clamp( BaseHitChance + ToHitMods – DefMods ) )

 

Further down you will also see:

 

Quote

So for critters, we have a slightly longer formula for figuring AccMods:

AccMods  =  the power's inherent Accuracy  ×  the Accuracy of the enemy's Rank  ×  Accuracy factor due to level difference

 

And then at the very bottom you have charts showing the differences based on rank and level.

 

But then you also have to take into account any player defense and any debuffs placed on the player.  So it can get pretty complicated!

Edited May 6, 2023 by Bionic_Flea

[Nitrogen]

It's good, I managed to find the right formula thank you ^^

Edited May 6, 2023 by Nitrogen

[Saiyajinzoningen]

Sup Uberguy, thank again for all your effort. As per our earlier interaction im making a request to include the anim filenames for each power on your site. this will make modifying animations easier for everyone. I've already started and while the process isn't terribly difficult its horribly time consuming since I have to test each anim file individually and reload the game between each attempt. Stage 1a.pigg/Player_Library/animations/male

 

1_2punch                                      Barrage (energy melee)    
1H_smash                                      Punch (super Str)
1H_throw_chunk                           unused asset (pulls sign out of ground and throw)
1Hslam                                         unused asset (very slow ground punch NOT SS stomp alt)
2hand_cast                                   Power Blast (energy blast)
2hclub_block                                  Unused asset (blocks 2 attacks from 2 angles with a 2handed weapon)
2hclub_cycle                                Unused asset (intermediate for 2 handed weapons probably)
2hclub_pre                                  Unused asset (intermediate for 2 handed weapons probably)
2hclub_run                                  Run while dragging 2 handed weapon on the ground behind you
2hclub_slam                                Stone Mallet (stone melee)
2hclub_upcut                              Heavy Mallet (stone melee)
2hlarge_absorb                          Build Momentum (Titan Weapons)
2hlarge_block                             Unused asset (dodges attacks while holding 2 handed weapon)
2hlarge_brawl                             Divine Avalanche (katana)
2hlarge_cast                                Taunt (Titan weapon intermediate)
2hlarge_draw_basic                      Draw Weapon (Titan weapon)
2hlarge_eye                                  Unused asset (intermediate defensive sweep or psionic dart with 2 handed weapon) 
2hlarge_hop                                 Jump UP holding 2 handed weapon
2hlarge_HQ_High                          Collision reaction holding 2 handed weapon (punched in the face)
2hlarge_jump                                Fly UP with handed weapon
2hlarge_jumppost                          Unused asset (intermediate for 2 handed weapons probably)
2hlarge_knockback_fierce              Knockbacked HARD
2hlarge_quick_getup                      Kip up
2hlarge_ready                                 Unused asset (intermediate for 2 handed weapons probably)
2hlarge_run                                     Run with 2 handed weapon
2hlarge_run_backward                     Run backwards with 2 handed weapon
2hlarge_run_left                               Strafe left with 2 handed weapon
2hlarge_run_right                              Strafe right with 2 handed weapon
2hlarge_runpost                                 Unused asset (intermediate for 2 handed weapons probably)
2hlarge_sweep                                    Knocked up (lol....seriously)
2hlarge_sweep_flip                             back when flying with 2 handed weapon
2hlarge_taunt                                      Taunt (Titan weapon)
2HPowerThrust                                   Energy Tranfer (energy melee)
2Hsmash                                            Air Superiority (fly pool)
2sword_mid                                       Gamblers cut (katana [slow])
a_shield_2HPowerThrust                    Air Energy Transfer (energy melee)
a_yes                                                  Hover Heroic Pose
a_yes_nod                                          Heroic Nod
a_yes_wave                                         Hover Heroic Wave
a_yes_wave_left_only                          Hover Heroic Nod & lefty wave
a_yes_wave_right_only                        Hover Heroic Nod & Righty wave
absorb                                                intermediate Animation
AFK_newspaper                                  Read newspaper emote
air_1_2punch                                       Air Barrage (energy melee)
air_1H_smash                                     Air Punch (super Str)
air_1Hslam                                        unused asset (very slow Air punch NOT SS stomp alt)
air_2Hcast                                          Air Power Blast (energy blast)
air_2hclub_cycle                                 Air Unused asset (intermediate for 2 handed weapons probably)
air_2hclub_smash                              Air Stone Mallet (stone Melee)
air_2hclub_upcut                              Air Heavy Mallet (stone melee)
air_2hlarge_absorb                            Air Buff Reaction (Titan Weapons)
air_2hlarge_brawl                             Air Divine Avalanche (katana)

               

 

Ill post more when i can if it helps, if not let me know.