[Derubael]

Originally Posted by Drakakade [You must be logged in to view images. Log in or Register.]

Honestly, I do not what is going on here anymore, because "That being said, it is absolutely not ok for trackers to be parked on raid spawn locations" did not have any qualifying adjectives like "kos trackers". Sirken's statement was clear: no trackers in range, and hence Taken (rightly or wrongly) being upset when they perceived a tracker(s) were in range.

It may just be that I work with the guy all day every day, but I really clearly understood what he meant in his post. The lack of any kind of certification that a new rule had been made by the CSR staff (something that we try to make really clear when it occurs), and the fact that this rule essentially just doubles up on the "No tracker engage" rule, pretty much confirmed it for me that this was merely a common-sense suggestion sort of thing rather than a rule.

Clearly, folks were trying to inch up on the mob, and rather than the refs calling off-side we are now all going to have to go faction in MM? First, let's give some props to the prediction on 07/14/2014:

I'm confused by this statement. Why would everyone need to go faction in MM to track targets(which is pretty common anyway)? I suppose you may gain a slight competitive edge by doing so, but given the way aggro ticks land on this server, CotHing in a puller next to the target to gain FTE is still going to come down to who CotH'd first followed by how quickly you can hit your /target dragonname, /autoattack button that everyone has made by now.

Folks we need to put our egos aside here, because with this new interpretation to Sirken's tracker proximity rule all we have done is move poopsocking from a guild affair to a 2 man/guild tracking, 16 hour coh-ducking affair, with the factioned CoH tracker(s) winning the truncated poopsock... Was that the intent?

Do we really want to just limit the scale of poopsocking? I hope not. Next, think about those poor GT folks or Dojo guys when they were perplexed at the web of raid rules - now you want them to faction up a bunch of dedicated CoH trackers?

I suggest going back to the problem and seeing if we can fix the original issue: the ball first got moved when we allowed CoH FTE's. That spawned CoH ducking and 16 poopducksocking by 2 trackers. Now, we (possibly) are inching the ball a bit closer by allowing factioned coh duckbots... Can we agree to fix CoH ducking, and then this issue will go away? Trakanon can stay the same or we can all just clear down to Trakanon - whatever you guys prefer.

We as a staff can't stand the socking. We had hoped all the new rules regarding engage limitations would, at the VERY least, severely curb the desire to sock - if not eliminate it entirely. Instead, everyone just stands at "the spot" for each mob and bullshits their way to the target with a magician assembly line. Not exactly what we had in mind. It took maybe all of a couple weeks for this to happen, and that just cements in my mind that there is no staff-enforced solution that will solve this without creating a stupidly restricted, enjoyment-sucking set of rules governing every aspect of raiding, something we have less than zero interest in doing.

Next, and this is for the staff, who I want to thank again for putting up with all this BS lawyering, and for putting in their free time to police the mess. I know it is frustrating to make a rule and then have everyone pick it apart. It must feel like folks are nitpicking. However, I believe that communication via text is very difficult, and what is really happening is the raiding guilds are trying to fully understand the scope of the rule.

I would humbly submit that before any new rule is set in stone that you give the various guilds 1 week to do their rules lawyering best to see if they can find any loopholes / clarification so we don't have to go down this thorny road each time.

I think we already do this most of the time. The last rule we made was pretty simple, and had already been thoroughly vetted by the community prior to it's implementation: Trackers can't get FTE on a target. Whenever we come up with a new rule we sit down and spend a significant amount of time discussing why it's needed, who feels it's necessary, and what, if any, issues will arise as a result. We also weigh very heavily whether or not the reward is worth the potential downside. Rarely will we not thoroughly look at a new rule or rule-set without picking it apart ourselves, something I feel we are very good at because we spend large amounts of time stepping on rule lawyers and their arguments each year.

Problems or confusion are usually a result of rules needing to be rapidly put in place taht don't receive the proper treatment. I hesitantly present the current raid rule-set as a prime example of this. We had very little time to talk about these and get them right. I was also fairly spaced out when the actual rules were written as well, and I usually provide the actual write-up for new rules, or at the very least give the wording itself to the person writing it. Most times I spend lots of time making sure this is clear, easily understood, and lawyer proof, but again, I was mostly spaced out at this time (and to be honest, I feel like we all may have been a bit far away that day). As a result, I really think the current "raid rules" are vague, confusing, and sometimes outright misleading. We still get asked for clarification, with almost a year having passed since their creation. A good rule will be easy to write in a clear and concise fashion that demands little clarification, creates minimal confusion, and allows little room for lawyering or "purposeful misinterpretation" - something that many of you have gotten very good at doing, but I truly feel is less prevalent now than it was a year ago. At this point it's "too late" to fix these rules on our own, and I don't see much desire from the staff to do so, which is why I have been trying to gently nudge the community into doing so themselves, finally changing my nudge to a shove a couple weeks ago in a thread somewhere.

There are also times that we make rules we know will be extremely unpopular or outright hated, but are necessary anyway. At times like these, we rarely bother to do any kind of community "beta-test" prior to activating them.

Secondly, and this is a shameless plug, I would like to start thinking about Velious, and start to hear about any new rules the staff would like to work on prior to release. And i do have a horse in the race: Ziglark Whisperwing. At some point fairly soon, can we sit down and discuss what potentially will be a mess in Velious?

Again, thanks for your patience, and effort on our behalf.

This is something we want to address as well, and the community should expect a thread soon - possibly one in server chat and one in raid discussion. As always, we will do our best to create as few rules and restrictions while keeping the encounters enjoyable and largely worry-free, but some targets will absolutely require exceptions and stipulations. In the end this will be up to the staff to set in stone, but we will rely heavily on the community to provide these where needed.

Originally Posted by -Catherin- [You must be logged in to view images. Log in or Register.]

C/R Rotation, 100% FFA on simulated respawns.

puts this problem to bed entirely.

I don't see us backing this idea anytime soon because we still really want to encourage guilds to at least try to practice in preparation for a transition. While I'm fully aware this isn't happening right now, that isn't to say it won't in the future - for all we know, there may be a guild getting ready to rock-and-roll any day now. That being said, if 100% of the guilds agreed, we'd almost assuredly do it anyway. The problem is I really don't see a universal agreement as a possibility, so it's probably better to move onto something different.

As a side note, Anicheks idea would be really difficult to police. In addition, as previously stated, anything that requires a code-change that is more extensive than changing an integer or two is not worth talking about. Rogean and Haynar already have enough to do. A zone check or even an area within a zone check, for example, is not that hard to code (from what I understand) in itself. But any information collected in that check then needs to be outputted somewhere accessible by the staff - simply throwing it into a back-end table would mean only I can read it, and that's not likely to be good enough. That means new connections to the front-end, which means more coding, which means more time and testing and hair tearing. At this point in time we're doing our best to create less work for our development staff, I refuse to even mention something that would create more.

Still excited to see you guys coming up with new ideas in between my unnecessarily long and overly descriptive posts. Kudos and thanks to anyone who reads through all of these [You must be logged in to view images. Log in or Register.]