Faultline

Invention recipe drops don't check for villaingroups at all. Invention salvage drops do, and Cimerorans are on the Magic group alongside a bunch of other groups. I'm not seeing anything that would result in them having less drops than any other group. Need more information on where the perceived lack of IO drops is.

Again: you are not taking into account the expense of parsing the text string in the first place. Remember this is done at run-time -- there is no compiler translating the string into nice checks. Everything you said is true when you're writing code to be compiled, because then all the string parsing is done at compile time. But when the string parsing is done at run-time, the extra processing expense is much, much higher.

But think about all the processing power you'd have to waste parsing the expression in the first place. The equivalent expression in more legible code would be char(level) == 50 && (!TokenOwned(EnhancementCatalystToken) || ((now() - TokenTime(EnhancementCatalystToken)) > 72000)) and just parsing that at run-time would use more power than the few "wasted" calls. RPN means it just executes the function calls one after another, without having to first figure out what it should be executing first. Think about it, what uses more processing power: fetching the current time, subtracting 0 from it, ORing and then ANDing it; or lots of string manipulation to find parenthesis and checking order of operations when there's not enough parenthesis? String manipulation may seem trivial nowadays, but try writing an evaluator for it in assembly and you'll quickly be singing the praises of RPN. MOV, SUB, OR and AND are a single processor instruction each. String parsing needs hundreds or thousands of instructions. In other words: you spent ~1000 instructions parsing in order to decide that you don't need to run ~50 while performing checks. Sure, it's better than running all ~1050, but with RPN you just evaluate the whole thing using ~100. When functions are this simple (nothing the evaluator looks at takes more than 10 lines of code) it's just more efficient to let it run.

The opposite! It's actually very simple, because it does the parameters in order, left-to-right; no need to check for order of operations or to use parenthesis. It just needs a stack: - If the next token is a value, PUSH it to the stack. - If the next token is a function, POP parameters (as many as the function needs) then PUSH the result At the end of the evaluation, the stack should have the final value, and only the final value - if more than one value is left in the stack (or you can't POP enough arguments for a function at any time), the requested evaluation was malformed. If you never coded in assembly or have the concept of a stack it will seem odd, but this is super natural for a computer. You could easily write a RPN evaluator in assembly for any system with a stack. The performance gains from this simple parsing outweight short-circuiting gains on anything but the most insanely complex expressions.

Here's a real-life example with the Enhacement Catalysts, since they were mentioned before. Every time you defeat an enemy of Boss rank, it triggers the Boss reward table (simple enough). That table has a lot of different rewards with various chances, this is one of them: Chance 3 Everyone { Requires level char> 50 == EnhancementCatalystToken TokenOwned? ! now EnhancementCatalystToken TokenTime> - 72000 > || && DropGroup 100 { ItemSetName PL.EnhancementCatalystDrop, RT.EnhancementCatalystToken } } The first line means that this specific reward has a 3% chance to trigger for everyone on the team. The second line is the actual requirements string. This is using what is known as Reverse Polish Notation, which will look bizarre if you never saw it before; it's a type of evaluator that is very simple to implement for a computer, and used in scientific calculators. The rewads code sees that this reward has a Requires string (if it doesn't have one, it always triggers) and ships it to the evaluator, asking the evaluator, "hey, what is the result of this gibberish". The evaluator then does the following: - Call the char> function with the level parameter. Let's say this returns 50. - Call the TokenOwned? function with the EnhancementCatalystToken parameter. Let's say this returns true. - Call the function now (no parameters) to get the current time (in seconds). At the time I'm writing this, it would be 678483161. - Call the function TokenTime> with the parameter EnhancementCatalystToken to get the time (in seconds) that the token was awarded. Let's say it returns 678480000. At this point, we've translated the Requires to look like this: 50 50 == true ! 678483161 678480000 - 72000 > || && - Call the == (equals) function with the parameters 50 and 50. This returns true. - Call the ! (negate) function with the parameter true. This returns false. - Call the - (subtract) function with the parametes 678483161 and 678480000. This returns 3161. I'm now going to show the evaluator after every step since seeing all the functions piled up at the end often confuses people: true false 3161 72000 > || && - Call the > (greater than) function with the parameters 3161 and 72000. This returns false. true false false || && - Call the || (OR) function with the parameters false and false. This returns false. true false && - Call the && (AND) function with the paramters true and false. This returns false. The evaluator is now done and tells the rewards code "the requirements evaluated to false". The rewards code goes "thanks bro" and doesn't give the reward. What failed here? You were level 50, but you had a token marking that you recently received a catalyst, and the timestamp says you received it 3161 seconds ago -- which is less than the 72000 seconds allowed between drops (20 hours). The rewards code didn't look at your character level, didn't look at your tokens, didn't look at the current time; and the evaluator didn't either, it just called functions that did. This means that a bug in the evaluator would affect any functions it calls, because it doesn't know the difference (so no way it's just the badges one) and a bug in an evaluator function would only affect that one function (so no way for a reward that isn't checking for badges to be affected by the badges owned function). I "solved" the above function a bit out of order to make it more legible, but RPN always works left-to-right; Here's the same example, but assume that you don't have the EnhancementCatalystToken (and because of this, TokenTime> returns 0), in the way that it would actually be processed: level char> 50 == EnhancementCatalystToken TokenOwned? ! now EnhancementCatalystToken TokenTime> - 72000 > || && 50 50 == EnhancementCatalystToken TokenOwned? ! now EnhancementCatalystToken TokenTime> - 72000 > || && true EnhancementCatalystToken TokenOwned? ! now EnhancementCatalystToken TokenTime> - 72000 > || && true false ! now EnhancementCatalystToken TokenTime> - 72000 > || && true true now EnhancementCatalystToken TokenTime> - 72000 > || && true true 678483161 EnhancementCatalystToken TokenTime> - 72000 > || && true true 678483161 0 - 72000 > || && true true 678483161 72000 > || && true true true || && true true && true The evaluator returns "the requirements evaluated to true", the rewards code goes "thanks bro" and gives the reward. The reward in this case is EnhancementCatalystDrop (which drops the actual catalyst) and EnhancementCatalystToken (which gives the token mentioned above, to check it the next time the reward triggers).

No, that is too simplistic a view because it assumes the code is looking at badges directly, which is isn't. The requirements are a string which is basically a list of functions and parameters. For example, if the requirements are "onMissionMap? VanguardEnabled owned? &&", the evaluator code would: - Run the "onMissionMap?" function and get a result of 1 or 0. - Run the "owned?" function with the "VanguardEnabled" parameter and return 1 or 0. - AND both values together to get a final result of 1 or 0. The "owned?" function is the one that would check for a badge, but that's not something the evaluator knows, it just goes through the list of functions and gets results. And more critically, if the Requires text doesn't have any calls to "owned?", then the code that checks for a badge is never called at all for that evaluation.

The reward side doesn't look at what badges you have got at all. Rewards can have requirements that go through a general evaluator which can check badges, the enemy group you defeated (Vanguard Merits use both), what powers you have (Windfall uses this), whether you are in a zone or mission map (Tour Guide tips), whether the map is Arena or Architect (used to disable things like Candy Canes in those) and a lot of other things. But the rewards code just hands off that list of requirements to the evaluator (which is just a line of text, like "VanguardEnabled owned? onMissionMap? && Loot_Booster ownPower? &&"), it doesn't look at anything directly, and the evaluator doesn't look at badges unless the requirements passed explicitly ask for it. No rewards check for any veteran badges. The same evaluator is used *everywhere* for many things, so any bug on it would be instantly and very obvious.

Are you willing to take the harsh diminishing returns that the PvP versions have for it?

This is planned but not before page4, page3 will add the remaining Tour Guides for the 15ish zones that have exploration accolades but no tour guides. The mission team is working on other content for page3 that has priority over the historian badges.

PvP Powers Changes These changes will not be going live in this patch - they are for testing only. Please provide your feedback if you would or would not like to see these changes go live! All travel power speed cap increases from Issue 27, Page 2 now also apply in PvP Modified the PvP diminishing return curves for travel speeds for testing purposes SpeedRunning set to 0.45, SpeedFlying set to 0.60, SpeedJumping set to 0.45 Sorcery > Arcane Bolt / Arcane Power Arcane Power can now trigger in PvP Damage bonus in PvP is 50% of the base damage rather than 100% Fortunata Hypnosis (IO proc): PvP placate effect reduced from 5.336s to 4s This puts it in line with the Presence pool's Pacify, which also does 8s PvE and 4s PvP Electrical Affinity: Rejuvenating Circuit: Increased the Main Target heal to do an extra 0.41 scale in PvP only. This makes the main target get the equivalent of a 1.96 scale heal (same as Heal Other from Empathy). The chain heal still works off of the 1.55 scale heal, so no change for the healing of secondary targets. Faraday Cage: Increased the duration of PvP-only effects to 20s (up from 5s). This includes mez protection, mez resistance, kb protection and repel protection. The other effects (PvE and Both) still use 5s. This increase in duration is to allow PvPers to have more time outside of the faraday cage bubble before wearing off. Faraday Cage: Decreased the activation period from 1 second to 0.2 second. The faster rate should allow for the Faraday Cage buffs to apply more quickly/reliably when moving through the Faraday Cage bubble. Note: This does not affect Static build up, that will still use a 5s activation period. Super Reflexes PvP tweaks (All ATs): Lowered the activation period of powers with scaling resistance from 2s to 0.5s (all ATs) Increased PvP Elusivity in Focused Fighting, Focused Senses and Evasion to 20%. Reverted scaling resistance and scaling elusivity changes from last patch. Added Toxic Resistance to all scaling resistance powers (all ATs) Bug Fix: Corrected Brute's Evasion elusivity duration. It was set to 0.75s when it was supposed to be 2.25s. This resulted in AoE elusivity dropping out between each 2s tick application. EMP Arrow PvP tweaks: Increased the duration of all PvP effects to 20s (up from 0.65s). This will allow players to buff themselves inside the EMP field, then exit for up to 20s of protection. These effects only include the following: Resistance to Mez, Teleport Protection to Mez, Knock, and Repel Power Surge and Unstoppable PvP tweaks (All ATs): Removed the HP crash Added Psionic Resistance (2.45 scale). The amount of psionic resistance is 35% of what the T9 typically gives to other damage types. Granite Armor PvP tweaks (All ATs): Added Psionic Resistance (1.75 scale). The amount of psionic resistance is 35% of what Granite Armor gives to other damage types.

Assuming Sunrise uses Tequila-compatible manifests, it is located at https://patch.savecoh.com/manifest.xml for the live servers and https://patch.savecoh.com/beta.xml for the beta servers.

This is not always the case - each Paladin Construction site is actually composed of many "Heap" spawn locations and one "PaladinEvent" spawn location. When the "PaladinEvent" spawn triggers, it spawns gear piles or waves of clockwork in the "Heap" spawn locations, and those spawns created by the event script will follow the Paladin when he is finished building. But those "Heap" locations can, and will, spawn either gear piles or clockwork defenders on their own, without the event being active, and those spawns, generated by the normal spawn mechanics of the game, will not follow the Paladin once its built. Note that currently, each spawn location is set to wait a random number between 0.001 and 36 hours before spawning the Paladin. If the event is too rare I can easily lower the maximum time, but that's what it was set during the entire lifetime of the game and I saw the event relatively often.

I'm tiptoing here because, again, I don't want to appear to attack the Ascension sysadmin, but citing a DDoS attack as a reason doesn't make sense. All OVH services include their Anti-DDoS solution. This is one of the things they explicitly, actively work to mitigate.

Don't worry. OVH doesn't generally suspend accounts for no reason. I don't want to speculate on what the reasons are because the could be construed as an attack on Ascension's sysadmin, but even if OVH were to actually suspend HC out of nowhere for no reason and delete everything in our servers, it'd only take us a couple of days to find a new host and restore from off-site backups. The worst case scenario is not a server death for us, because we have contingency plans in place. This does, once again, highlight the importance of backups. It's been two months since all the data on Sanctuary was lost, that should have been a big incentive to back up Ascension off-site every single day, from the start. Why they were operating without off-site backups after the giant wake-up call two months ago is beyond me.

Closing poll since this is getting patched to live now. To those suggesting changes to the event: noting those down for when the event gets revamped, but the whole point of this patch was to not have to spend development time on the event right now.

Here:

Again: the level is a check on the story arc, not the contact. It doesn't matter if the metacontact will talk to you 1-50 when the story arc is what prevents you from joining. In order for the second contact to give you the "expanded level" TF, then a copy of the TF file would need to be made that works for those levels, and I am not willing to have two copies of the same TF that need to be kept track of separately in any future changes for this.

They are a solution in search of a problem. They won't do what you want here, because again, even if you skip the checks on the contact, the story arc has its own requirements that are checked for the whole team. Changing the contact that gives you the story arc won't remove those requirements from the story arc. Positron is pretty much the only situation in the game where a metacontact remotely makes sense, because a Task Force contact can only ever give their one and only Task Force. The metacontact is a layer on top that makes the Positron standing in Steel not give you a Task Force, but instead give one of two other contacts, each with a different Task Force to give.

Task Force contacts are never introduced by other contacts, that would create all sorts of problems. You can certainly add additional checks (for everyone to have a badge for example) but I don't see how that's relevant since the point here is to reduce requirements, not add more. Check on the contact, not story arc, as described before. Positron in particular is messy, because it's three contacts, not one: when you talk to it, you get a "metacontact" which checks the requirements for two other contacts, and when you click on either of the two options at the bottom you're talking to a different contact, internally. The Positron that stands in Steel Canyon is Positron_2, which has a level range of 10-16 (but as a metacontact this is meaningless and not checked) and it links to the contact Positron_2_Task1 if you're 8-15, and to the contact Positron_2_Task2 if you're 11-16 and have the PositronRevampPart1 badge. There aren't many metacontacts in the game, in fact I think Positron is the only one remaining. That should not be a problem. I do not think there are any Rikti critters that are 45+ only, but I could be wrong.

The badge or token check is on the contact, not the Task Force. When the check happens, it's no different to you talking to any of the contacts in your list, so no requirements are checked on your team. When the Task Force starts, there are checks on the story arc (task forces and story arcs are the same in this context) and those do check your team for requirements. For a player it's hard to differentiate the two since it all happens on the same window, but from this side there's a clear distinction on the checks that happen just when you talk to a contact, and the ones that happen when you try to start a story arc. Ouroboros is similar in that you can consider the crystal interface to be a contact that displays every arc in the game; it has its own set of checks (have you completed the arc before or are you above its max level or are you at the level cap), then it checks if any contact would offer the arc to you personally (this is what stops you from seeing EAT story arcs on a normal character), then it checks the story arc requirements. Ouroboros doesn't allow you to skip existing requirements, it just adds more of its own on top. I did look into reducing the whole arc to 35, but the Weakened Hamidon is only part of the issue. There are several enemies that only spawn above 40, some of which only appear on the TF and should be no problem to reduce (Dra'gon, Honoree, the Horsemen Four) but others are part of the normal Rikti faction (such as Mesmerist boss) and reducing them would cause them to start spawning on level 35 missions where they never spawned before. At that point it becomes a balance concern I'm not ready to deal with, since I know some of the late game Rikti can be pretty brutal and introducing them to lower level missions could be a problem.

Those sets were introduced last year to be used in damage powers such as Electrical attacks. The inclusion of damage and accuracy on them is by design, not a bug, and won't be changed. Relevant patch notes: Synapse's Shock (Endurance Modification, Rare, 21-50) The first of two new Endurance Modification sets with a damage focus, designed to be useful in endurance-draining attack powers. Enhancements: Endurance Modification Damage / Recharge Endurance Modification / Recharge Damage / Recharge / Accuracy Damage / Accuracy / Endurance Reduction UNIQUE: Endurance Modification / 15% Increased Run Speed Set Bonuses: 2: 7.5% Movement Speed 3: 10% Slow Resistance 4: 8% Regeneration 5: 6.25% Recharge 6: 4.5% Energy / Negative Resistance + 7.5% Mez Resistance Power Transfer (Endurance Modification, Rare, 21-50) The second damage-focused Endurance Modification set. Enhancements: Endurance Modification Damage / Recharge Endurance Modification / Damage Damage / Accuracy / Endurance Reduction Damage / Recharge / Accuracy / Endurance Reduction Chance to Heal Self (3 PPM) Set Bonuses: 2: 6% Regeneration 3: 1.35% Max Endurance 4: 1.875% Max Health 5: 9% Accuracy 6: 7.5% Recharge

Can you cite an example of a Task Force that works this way? As far as I know, this is not possible. All members in a Task Force must meet the minimum level to start it.

I can reduce the TimeToHeroSuccess to 10 minutes, but that's pretty much it for tweaks - the event runs on the original COH scripthook+spawndefs system which is not very pleasant to work with, and I don't want to waste a lot of time on it. When the event is properly redone it will be using a different scripting system that we have been expanding recently, but that won't be patched to Live until Page 3 for use in the [redacted], and it's unlikely the Paladin event will be looked at before Page 4.

I have no idea. That's a question for @Captain Powerhouse or maybe @UberGuy or @Bopper know. I'm not a powers person.

Take it with @Jimmy, he likes the trucks and wants an interdimensional van network.