LostCreation

[ QUOTE ]
[ QUOTE ]
<QR>
Can we get one thing clarified, please. If I'm doing /ignore_spammer because of an RMT tell, is that enough to get the folks dealt with or do you really want us to send a /petition too? I can understand needing the follow-up petition for other types of "disruptive behavior", but for things as blatant as RMT tells I really don't think anything beyond /ignore_spammer should be necessary.

[/ QUOTE ]

A petition to follow up, in whatever case, is always ideal.

[/ QUOTE ]
Which is really unideal.

I just read through this thread on the test boards to see if it had what I'm looking for, and judging from that thread and the conversation here, there seems to be some confusion about what players like myself are asking for and the clarifications you're providing, Lighthouse.

First, this is how I understand /ignore and /gignore to work. You and some others seem to misunderstand what these commands actually do. (And if I'm wrong, someone please correct me):

/ignore<ul type="square">[*]Only blocks specific character-to-character communication. [*]If I do "/ignore A Spammer", my current character will no longer receive /tells from the character named "A Spammer" and I won't see any dialog from that specific character in any of the server and zone chat channels (e.g. Help, Local, Broadcast, etc.).[*]If I switch characters, I will not be ignoring "A Spammer" on that character unless I do "/ignore A Spammer" on every character I have on that server. If "A Spammer" switches characters he will not be ignored.[*]I will still receive tells sent from that player account to my global handle (e.g. "/tell @Me") and will still hear anything that player says on any of the global chat channels I may subscribe to.[/list]
/gignore<ul type="square">[*]Only blocks handle-to-handle communication, and communication in global chat channels.[*]If I "/gignore @Spammer" then the player account with the handle @Spammer can't "/tell @Me" or talk to me on any of my global channels (e.g. Radio Freedom, or whatever), regardless of what character I may be playing or what server I'm playing on.[*]He can still send tells from any of his characters to any of my characters that are on the same server (e.g. "/tell My Character,"), and I can still see anything he types on one of his characters in any of the server chat channels (e.g. Help, Local, Broadcast, etc.).[*]If I "/gignore A Spammer" the server looks up A Spammer's global handle first, but the effect is the same. "A Spammer" is not ignored unless I explicitly "/ignore A Spammer".[*]Since I've yet to encounter or hear mention of RMT spammers using global channels or global tells, /gignore is essentially useless for blocking any RMT communication.[/list]
/ignore_spammer

We have asked but not been answered if this command is doing anything that can't be done with /ignore, /gignore, and /petition. The consensus is that it's merely a shortcut for /ignore and /gignore, and flags the spammer as a possible "Disruptive" presence. Since we have been told that we should send a petition anyway, we're basically being asked to use /ignore_spammer instead of /ignore (remember "/gignore" is really not doing anything to block RMT), and then /petition.

This does not help us. Worse, it stinks of posturing (by that I mean, pretending to do something about a problem without actually doing anything, if I have the term wrong).

The tools I'd want as a players to deal reactively with this problem are:

1. A way to completely block player-to-player communication. Call it "/ignore_player" and have it work as a /gignore and an /ignore for every character created by that player account now or in the future, regardless of which character or server I am playing on. AFAICT, /ignore_spammer did not add this functionality, and so the functionality does not currently exist in the game.

2. A way to more easily /petition these folks, since it's happening so often. A command such as "/petition_spammer" that automatically opens a petition window on my client and fills it in with reasonable defaults, would work well. This way, I can easily edit the petition if needed, and do my best to ensure it's actionable, before hitting "Send Petition". If the command can include the last bit of dialog I received from the spammer or his last tell, even better. For example:

<font class="small">Code:[/color]<hr /><pre>Petition Type: Harassment

Summary: 'A Spammer' is a spammer

Full Description: I believe the character named 'A Spammer'
on the account with the handle '@Spammer' broke the TOS with his
last communication to me: "Blah Blah Blah."</pre><hr />

&lt;QR&gt;
Can we get one thing clarified, please. If I'm doing /ignore_spammer because of an RMT tell, is that enough to get the folks dealt with or do you really want us to send a /petition too? I can understand needing the follow-up petition for other types of "disruptive behavior", but for things as blatant as RMT tells I really don't think anything beyond /ignore_spammer should be necessary.

[ QUOTE ]
I'd say leave it out of all chat tabs. Create a mouseover/clickable button that gives the current status of any/all zone events.

[/ QUOTE ]
I'd like them to put these things on the in-game world map. Like the in-game map for Recluse Victory that shows who controls what sectors, the world map could show a colored border around zones that are threatened -- be it by Rikti, a Giant Monster, or whatever. Maybe have the Map (or the tab) turn red when somethings going on.

Even if they address the ADMIN event spam, I would still like to be able to assign the ADMIN channel to a specific tab. Perhaps they can rig things so you must have it in at least one of your tabs, that would be best. Another option (in addition or instead) would be to have it always show up in whatever tab you have active. (Do "/target_name Whatever" to see what I mean.)

[ QUOTE ]
The problem is that when the buffs stack mechanically the effects don't.

If I have 80% resistance and get +10% resistance I go from taking 20 dmg from that attack to 10 dmg. That +10% resistance means I can twice as many attacks before I go down. A tanker with 80% resistance on their own is twice as powerful with a +10% resistance buff from a defender.

But a blaster with 0% resistance on their own with +10% from a defender is only 10% more resistant. The buff is useless to them.

So with the current system a buff can be both overpowered and useless depending upon who gets buffed.

With diminishing returns you could make it so the buff reduced damage for anyone by 50%. So a blaster would take 50 dmg instead of 100, and the tanker would take 10 dmg instead of 20. Everyone wants the buff. It is useful for everyone but overpowered for no one.

[/ QUOTE ]
I always felt that the conceptually simplest solution would be to have a non-stacking base defense (or whatever) and then stacking additive defense. You could give every defensive power a relatively high base % and a relatively small additive defense. If you only have one defensive power active your defense would be base + additive. If you have multiple defenses you'd find the max base, and then add the sum of all additive defenses.

So, if Combat Jumping was a 5% + 1.875% for a Scrapper, used alone you'd get 6.875% defense. That's not bad, considering it's about half Super Reflex's tier 1 defense power. If Focused Fighting had a 10% + 3.875% (sum is what the power gives you now), it would stack as Max(10, 5) + Sum(1.875, 3.875) or 15.66. This is exactly what SR gets from the two powers today, so isn't anything to write home about if you're SR. But if you're an "I don't have any defenses" scrapper (or blaster, or whatever), I'd imagine you'd be pretty happy with getting hit ~13% less often.

You could make all the "marginal" buffs more worthwhile used alone, while simultaneously preventing stacking "abuse" and "easy mode" play. I'd imagine that most pool powers and many auto powers, would be greatly improved when they're used alone. For most other powers, you wouldn't loose any of the current power if they're used by themselves, but you'd also prevent them being so crazy effective when stacked.

Using Radiation Infection as an example of this last point, it could be done as 26.25% + 5.00%, or perhaps 21.25% +10.00% -- basically whatever numbers make stacking worthwhile without flooring the tohit as easily as stacked debuffs do now. If another debuff is applied, but has a larger base debuff, you'd use that instead (maybe Hurricane would have a 32.5% + 5.00% -- together with RE that'd be a 42.5% tohit debuff, whereas two REs would *only* be 36.25 using "X+5%" numbers.) (I don't actually know what the tohit floor is, so if these number don't make sense, substitute some that do.)

Anyway, that's how I'd do it, if I had a magic wand.

[ QUOTE ]
My #3 says "its a bug".. so we dont need a #5 saying the same thing. I also explained why it most likely is not a bug.

[/ QUOTE ]
And I disagreed with you completely for the reasons I stated. I probably should have omitted the number, but felt that adding a new one was clearer because I was not saying the same thing as you were. This most likely is a bug because it was most likely taken by someone who either a) worked in PR and didn't know any better, or b) knew better but didn't notice (it really isn't all that obvious if you don't play spines), didn't care, or didn't have time to care.

If it wasn't a bug, then the most reasonable explanation (and one already given, but after you posted your list) is that a dev specifically removed the VFX for those screenshots because it is ugly.

Move along folks, there's nothing to see here.

[ QUOTE ]
1) It is a temporary power from an invention.

2) Its a custom picture to hide the spines and show off the samurai armor.

3) Its a bug

4) Limited power customization. The ability to suppress certain graphics.

[/ QUOTE ]

5) It's a screen shot taken from a testing build of the game, and the spines power animations in that build were a bit bugged.

Since these screen shots are of up-coming changes, they are almost guaranteed to be from an internal testing build. We know that there's been a lot of animation work going on (check the dev digest). From there, it's reasonable to conclude that some work-in-progress was interfering with part of spine's animation when these screen shots were taken. I doubt the person who took the screen shot was familiar enough with spines to even notice the animation bug, and even if that person were, he or she no doubt had better things to do than agonize over a small "I'm sure no one will notice it" animation bug.

[ QUOTE ]
God, that would suck big for several powersets across ATs. That's fixing a fly with a big sledghammer, IMO.

[/ QUOTE ]
LOL, good to have at least one person's opinion on it, though calling my idea a "big sledgehammer" seems a bit excessive.

Remember, this power really isn't supposed to be dependable during combat, but "several powersets" can use this power reliably during combat because of their high defense. My idea would bring them back in line with other power sets that aren't def based (maybe too far back in line, I don't know) without any additional changes to the power itself.

Like I said, I'm just brainstorming here.

[ QUOTE ]
Builds using ATs which have inherently high defense and/or include a lot of defense pools (Stealth/CJ/Weave/Hover) have a distinct advantage in Aid Self usage over builds that do not.

[/ QUOTE ]
I'm just brain storming a bit here, but I wonder if they could make a distinction between attacks that miss because the attacker's to hit roll whiffed, and those that miss because of the targets defense. If the target aims about as well as an Imperial Storm Trooper, a miss shouldn't interrupt Aid Self. But if they miss because your "armor deflected it" or because "you dodged it", shouldn't Aid Self be interrupted? (Arguably this should apply to all interrupting powers, not just AS.)

If I understand how ToHit/Defense works, this would mean that even level minions would have approximately 50% chance to interrupt AS if they attack while AS is activating. Your defense wouldn't effect this chance at all, but ToHit buffs and debuffs would.

Is this idea good, fair and fun, and would it help balance out Aid Self?

[ QUOTE ]
I maybe dippy, but I don't understand why having one power set that is better then the others?

[/ QUOTE ]
Let's pull out an example. Right now, some players have an attitude about tankers that, if it ain't a Granite tanker, don't invite it. While I disagree with their conclusion, there's little doubt that this sort of attitude is bad for the community. It makes folks who play non-stone tankers feel dejected. There's nothing worse than accepting a team invite, only to be asked "R U Stone?" before they kick you. This does happen, and it creates a hostile community that drives people away. This is true anytime a large number of players get an opinion like this stuck in their heads.

So how do you fix it? Really depends on the big picture. If the other powersets in the AT perform acceptably then the simplest solution is to nerf the one powerset that's outperforming the rest. If the other powersets are under performing it's better to buff the other powersets. The goal isn't to make all the powersets perform identically, but to get them so that (a) they can all do the job the AT is supposed to do, and (b) there's no one powerset that's always the optimal choice under any circumstances that matter.

Right now, most people who play tankers feel like tanks, as a whole, are under performing. The consensus seems to be that the Def changes and ED hit tanks too hard. To some extant, the dev's seem to agree. Tankers should be seeing some relief for their woes once the defense changes in I7 hit. For most primaries, there's a lot of cautious optimism that this change will allow non-granite tankers to actually tank for a group again, but only time will tell.

[ QUOTE ]
[ QUOTE ]
Leveling the field is a much more rational (and in the long term good for the game) approach than a change like the BossBuff that really benefited a few specific powersets and hurt everyone else.

[/ QUOTE ]
That is just silly, why not just have 2 or 3 archetypes?

[/ QUOTE ]
Powersets are not the same thing as Archetypes. If you have one powerset in an AT that's outperforming the others (say, for example, the old Regen when compared to other scrapper secondaries), it's much easier to bring a single power back down to earth (nerf Regen!) than raise all the other powersets to godhood. Not only is it more work to buff all the other powersets, but if these powersets are already performing admirably, you'll have to rebalance the entire rest of the game to keep things challenging for these gods among heroes.

From a player's perspective, buffs are always better than nerfs. But from a developer's perspective it's just not practical to rebalance the entire rest of the game in order to avoid nerfing a single powerset.

[ QUOTE ]
I've just seen less and less dev posts as the amount of dev bashing has been going up.

[/ QUOTE ]
If I'm not mistaken, there's always been a downturn in the number of dev posts during the last push before an issue hits the test server. Usually we'll only have one or two threads that discuss a proposed change (and you'll obviously have Devs responding to those threads) and the occasional silly reply that doesn't require a whole lot of time investment to make. Other than that, the Dev's highest priority is almost certainly I7, whose eminent arrival is taking the bulk of their time.

While the dev bashing may be going up (it doesn't seem to be any greater or lesser than the storms that preceded other issues to me) there isn't necessarily a causal relationship here.

[ QUOTE ]
No Dev would respond to the discussion of this in the Test Server (Training Room) forum, so, we don't know the extent of the problem or why they chose this fix.

[/ QUOTE ]
If you don't like the answer, ask a different question.

Could there be a reason that they fixed this problem that has nothing to do with chat spam? A reason that they would have, I don't know, some sort of policy that would prevent them from publicly discussing it? This isn't an assertion -- I have no idea what other reason, if any, they could have for implementing this system -- I'm just offering you all a different question.

First of all, I disagree with many of the people here on how big of a deal this change is. I think it's welcome and know that it will have negligible impact on the way I play CoH (keyword, I, me, myself). In my opinion, you should be both actively contributing something and actively risking something if you want to be rewarded. This means that a street cleaning team that splits into two sub-teams should not receive kill XP for kills they didn't "risk and contribute" too, neither should a hero receive mission bonus XP if he doesn't "risk and contribute" to that mission. (Note that the proposed change doesn't actually impact mission XP at all, this is just my opinion.)

That being said, I do have three misgiving with the change:

[ QUOTE ]
If a player is in a zone, did NO damage in a combat and has dead for more than a minute, he receives no XP.

[/ QUOTE ]
First, XP shouldn't be based on damage. If I use a power on a teammate who then kills a mob, or if I use a non-damaging power on a mob, I should be eligible for XP the same as a player who did damage that mob. It shouldn't matter if I'm standing in the thick of things or cowering 301 ft. away.

Second, as other's have stated, I can easily imagine several more-or-less legitimate circumstances where a toon is dead for longer than a minute but still contributed (or at least contributed enough to warrant XP). I think the main idea behind this specific change is that a contributing hero--regardless if she's a support or attack AT--will be alive (and nearby) much more frequently than she will be dead (and far away). Alive, the hero will presumably be (a) contributing to the team, and (b) risking death and debt.

1. As a positive example of this, we'll use a bubble (i.e. force field) controller. These guys can often just bubble folks up before a battle then drink soda and watch TV. As long as no one's bubble bursts before the fight is over, everyone's more or less happy with the controller's contribution. Assuming, however, that the controller does try to do something else and gets himself one shot early in the fight, he should still get XP for the fight.
   
   
2. As a negative example, you have the dead hero being teleported to each battle in order to leach XP without risking (further) debt. He is not contributing and not risking, he should not get experience. Note that this example has nothing to do with the corpse power-leveling. Any time a player is being rewarded without taking any risk, there's a problem with the game that needs fixed. The presence of power-levelers is not the problem, it's the exploits they are, um, exploiting that are the problem.

I've brainstormed a few suggestions that may help minimize the impact on hero "A", while still curtailing the behavior of hero "B". All of these suggestions assume that the dead hero would be eligible to receive XP if he were still among the living (i.e. did damage, was within 300 ft., etc.). The XP referred to is exclusively XP from kills, I believe that anyone who contributed to a mission (be it a street sweeping mission or an instanced mission) should get the mission bonus XP regardless of whether they are among the living when the mission is completed. Each suggestion is independent and not really meant to be done together. Any numbers I give are completely arbitrary. While they sound reasonable to me, they're mostly meant to give you a ballpark idea of what I'm thinking--a starting point, nothing more.
<ul type="square">Suggestion 1: Dead-to-Live
Track how much experience players receive while dead and how much while alive. As long as the ratio of dead-to-live is reasonable, the hero should continue to accrue XP while dead. If the ratio gets too unbalanced the hero stops gaining XP while dead. For example, a hero may only be able to earn 1 XP while dead for every 100 XP he earns while alive--and this ratio can get more divergent the higher the hero's level, etc. It's reasonable to assume that our bubble controller will earn the majority of his XP while alive, so this won't impact him. It will, however, impact the XP-earning corpse very quickly. This is my favorite suggestion because it would probably be easy to implement, is conceptually simple, and seems the most fair.

Suggestion 2: Dead-to-Debt
XP while dead only goes toward XP debt. This suggestion was mentioned by GadgetDon. While it's simple and reasonable (assuming mission bonus XP is exempted) there is the possibility that large XP hauls from AV/Monsters/Etc. may be missed because the dead hero no longer has debt to get rid of. This suggestion is also the most unfair to our bubble controller who (unless he's in a lot of debt already) will be missing out on an entire battle's worth of XP. It's also most... unfair... to our XP-corpse too, which is a good thing. Regardless, this is my second favorite suggestion.

Suggestion 3: Start-to-Death
Reward the player experience as long as he was alive when combat was initiated and would be eligible to receive XP if still alive. The bubble controller example will receive experience for the entire fight because he was alive when combat began. The corpse will receive full XP the first time he does this but will need to be rezed before each fight (and will therefore be risking death and debt, if not actually contributing). This would be my least favorite suggestion if it weren't conceptually more simple than the next one.

Suggestion 4: Total Dead
Give every hero a "total dead timer" (or TDT) in addition to the 1-minute timer. Every time a hero dies, he would be given a full minute during which he will receive full experience from his mates' kills (i.e. what Statesman says will be happening). After this minute elapses, he will then receive experience only if he has time left on his TDT. Unlike the 1-minute timer, the TDT does not reset with each death, but is persistent over a period of time. For example, the TDT could be 5-10 min for every hour played. As long as a hero has time on either (a) his 1-minute timer, or (b) his TDT, he'll receive full XP for kills while dead. Our bubble controller who (hopefully) isn't spending too much time on his back should have a comfortable buffer remaining in his TDT if he dies but can't be rezed for little while. The corpse, however, will quickly eat through his TDT and then only have the 1-minute per death XP. Even though I like this suggestion better than #3, it's my least favorite because it sounds like it would be the most difficult to implement. To work best, you need some way to distinguish combat dead time from just plain dead time; that is the TDT should only be counting down when the player could actually be earning XP, not just when the player is dead.[/list][ QUOTE ]
He'd get XP with the 3 person team multiplier...BUT that XP would still be divided appropriately between each teammate. The others, however, wouldn't receive their shares.

[/ QUOTE ]
This is my third misgiving. If you're splitting XP, but the other players aren't getting their split than the bonus should be calculated against the number of players who'll actually get a share of the XP, then divided among those players. I'm guessing that would take a pretty big change to the way experience is calculated though, otherwise Statesmen would be doing it that way already. (Well, that and the bridging PL issue, which is as much a problem with the SK/Mentor system as it is a problem with the experience system itself, and this post is too long already.)