srmalloy

That comparison is denigrating to empty wastelands.

Okay, let's turn it around the other way, and change all -- let's say just yellows and reds -- so that when you use the inspiration, you have to pick the one power that the inspiration will be applied to, and none of your other powers are affected. Because that's what MMs have to do when they use inspirations on their pets.

That's not what I'm finding in ESO, which is clearly based around game controllers and their limited buttonspace -- having only twelve abilities available to use, split between 'front' and 'back' bars, and any toggle power that isn't in both bars switches off when you swap bars -- feels a bit stifling when I play it instead of CoH, where I have trays for the up to thirty powers I use regularly, a fourth tray for common powers used irregularly (Fast Travel, Reveal, Ouro Portal), and a fifth where I put temp powers and non-MM pets (Knight Errant, Sing, Fluffy, the Lore pet(s), etc.).

You'll want to do whatever opens the extra tray and drag the power in it out of the tray first, or it becomes much harder to get it into a tray afterward.

I think the idea is to define a class of objects that will be destroyed if fully drained of End, not that this be a general mechanic. For example, the force field prison doors in Arachnos bases -- drain them of power and they shut down. Ghosts drained of End might lose their ability to manifest on this plane. But it shouldn't be a sweeping 'drain to zero End, and it's defeated' rule.

There is code that checks, when a sidekicked player dings a new level, whether the sidekick status should be terminated. The sidekick termination code automatically reaps the character's pets, to prevent the exploit of sidekicking to a 50, summoning your pets, quitting, and then running around with level 49 pets. What needs to be done is to have the sidekick termination code look at the before and after levels of the character, and if they're the same, not reap the pets.

In every other case when a MM goes up a level, their pets remain summoned and at the level determined by the MM's prior level -- i.e., they ding 13, their two tier-1 pets remain at 11 and their tier-2 pet remains at 12. This happens whether the MM is sidekicked or not -- except for the single case where the MM is naturally -2 to the leader/mission holder, and dings to become -1 to them, which causes all the MM's pets to die, because only in this specific case of leveling does the code that handles sidekick/exemplar level changes terminate the sidekick status, which triggers a second function that reaps all of a character's pets when they drop sidekick to prevent them from having pets that are higher level than the character should have. This is a bug; it is code working in an unforseen way that actively harms the character.

And with Atomic Manipulation -- I routinely recolor all my characters with a Radiation powerset to make them colored like Cherenkov radiation, not the toxic-green color that has become the stereotypical color for radiation (and which is actually the color of the phosphor stimulated by the radiation in radium illumination, not of the radiation itself, which is invisible) -- see this image for an example of Cherenkov radiation from a water-pool reactor -- and the combined-effect DoT is still the stock toxic green.

If you're supposed to be getting Incarnate XP for your incarnate slots when you defeat mobs that are 50+, shouldn't you be getting incarnate XP for defeating GMs and mobs that are affected by the autolevel code (i.e., Rikti raids, zombie invasions, et. al), since they'll be effectively the same level as the incarnate? I noticed earlier today when I had a level-50 Controller on a team working to take down the Council Goliath War Walker in Boomtown that, when we finally got it down, she received XP and influence, but no incarnate XP, despite having been purple to her.

Different timers for the /cc and /cce commands? I can see why that could be necessary.

That would make for a hell of an April Fool's surprise.

The function is working as designed -- when you drop sidekick, your pets despawn. Is it working as intended? Without the original devs to ask, that's going to be harder to answer, but since your combat level isn't changing when you drop sidekick as the result of leveling to [leader's level-1], then I believe the exhibited behavior of killing your pets is an unintended consequence of the code's function, and is therefore a bug.

Perhaps attach a check for 'safe' status, already used for the logout timer, so that if you're out in a 'combat' area you have the normal counter, but if you're in a safe area you get a much-reduced counter. This would prevent people from standing in the bowl during an MSR spamming costume changes, but allow them to switch quickly back inside the Vanguard base (i.e., at the tailor where you make a change to your power colors, save it, then quickly cycle through your other costumes loading the new .powercust file to update them).

You can also look in this thread for using the 'optionset' command for fine control of the buff/debuff display icons.

I wonder if just making them neutral -- like the yellow-frame Crey in Brickstown -- would be enough to deal with that.

Ding during the first of the mid-day MSRs, then swap to another character for the second. It's faster to hit the shield with the first character to log them out in Point du Hoc and swap than take them back to the Vanguard base and train first. If you get distracted, the character left at Point du Hoc might sit there for a day or more before you get back to them.

Also, as a similar 'nice to have' bit of information, a display of combat/security levels if the character is not fully trained -- i.e., "38/40" for a character who is level 40, but only trained to 38 -- so you can see who you need to train to bring up to full status.

Wasn't there a recent update that was supposed to make the visuals for Wild Fortress constant, instead of only showing on activation (zone Changes, etc.)? Sounds as if that change isn't working properly.

It would be a nice QoL upgrade if pet powers were made 'smart' using a derivative of the code that handles sidekick/exemplar status -- you rise in level, either by dinging or a change in leader, and your pets' level goes up in parallel. Go down in level, and your pets decrease with you -- although this is complicated by the need to desummon pets you no longer have the power for (i.e., below 21 for the tier-3 pet), and the number of tier-1 and tier-2 pets may need to be reduced. But I don't know if the code would support making a change like that without serious unwinding of the spaghetti code behind the façade.

In the same way that the Ouroboros portal power was altered so that you no longer have to be on the ground to summon the portal, can the P2W powers for the various buff pets be altered so that you can summon your pet while just off the ground?

With pets using groups that already exist in game, the problem becomes one of a) establishing visual differences for the base, first upgrade, and second upgrade versions of each tier of pet, and which abilities the pets get (and at what strength) foe each level of upgrade. This may or may not run out of existing art assets with the group, and may or may not require additional animations -- all of which would be more complicated than simply subbing in the models from the group for the base pets.

You could make the argument that, with the retention rate that City of Heroes had, its very existence challenged NCsoft management's preconceptions about what an MMORPG should be, so they nerfed it all the way into the dirt so that it would no longer exist as a counterexample to their fixation that high-churn team-centric cash-shop-based MMOs were the best way to go.

And while we're at it, can we go back to the old form of exemplaring for TFs, where someone who was too high level for a TF had to be paired with a character who was in the level range for the TF, so we can control the number of people bringing high-level characters to low-level TFs and being overpowered compared to the people who are "legitimately" doing the TF, diminishing their contribution and ruining their emjoyment? If you can't recognize it, yes, this is sarcasm. The changes I've seen made in the game over the years (barring certain nerfs I decline to address, and which are a matter of opinion, anyway) have been to expand the ways that you can play the game. Zones used to be level-locked, forcing groups to break up if someone had missions in them; now, if you want to, a high-enough-level character can take a bunch of low-level characters into any zone and run content there. Exemplar and sidekick used to be strict pairing, meaning that you had to have one high-level character to match to each low-level character to sidekick or exemplar, and you could be kicked from TFs if that broke, or have part of a team suddenly stop getting XP or get roflstomped by mobs now a dozen or more levels higher than they are; now, you just team up and it's all handled automatically. Wiping the zone MSR out of the game because you don't want to deal with the hassle and consider lower-level characters in an MSR to be useless is taking away options from the players. The existence of zone MSRs is not stopping you from forming instanced MSRs to your heart's content; go have fun your way, and let other people have fun their way. If you can't get enough people for your instanced MSRs because they're running zone MSRs, then that says something about what they prefer.

The "Council weapons rack" object that's used for mission glowies for weapons (the other being the 'Warriors weapons rack' with melee weapons) is either missing polygons or has several of them facing the wrong way, so the surfaces are not drawn correctly for the back part of the frame:

One mechanically simple way to address the issue is to create command IDs for each of the random power/emote effects -- for example, Propel would have separate messages for 'throw car', 'throw fan sculpture', 'throw pool table', 'throw dumpster', etc. -- and either have the server generate the random item and pass the correct command ID back to the originator and everyone who can see the power activation, or have the client where the user is activating the power generate the random item and pass the correct command ID to the server to be forwarded to everyone who can see the power activation. The latter relies on the client to generate a correct command ID, and goes against the "never trust the client" principle of online game design, while the former adds a trip to the server and back for the power animation, potentially adding lag. Since the message has to go to the server and back to the user originating the power use anyway to generate the correct 'hit/miss' animation, I think that putting the object determination on the server and passing it back to all the clients is going to be the best way to go in the long run, avoiding the possibility of the process being hacked.