So, full disclosure: the templar classleads are mine. I would like to do something similar for Deathknight but Cyr talked himself into it instead and I'm good with that, because Deathknight is a giant mess.
1. I feel a big part of it is basically another full knight revamp - I don't think this is necessary. Knights are unfinished, not flawed in the current design. The core mechanics are there and just need some love/tuning. I think we have an unfortunate issue to try to fix things that don't need fixing - I think many of the underlying knight mechanics fall into that category. There are some problem children, but by and large the foundation is solid.
2. I think we'd be far better off deriving the circle flavour from the secondary (necro, devo, runelore), because they're much more easy to thematically link to what you're going for.
3. I like the weapon types being universal across knights, because at the end of the day this makes things easier to balance. When everyone has the same basic core tools there is a vested interest in those tools being balanced by all parties. I'm going to use totems and vortex as my example (let's just say shaman and be done).
4. To go back to point one a little bit, most people really don't like relearning their class. I think we saw this with a lot of the class revamps - what you're getting might be objectively better but its still a significant time investment your average player will have wasted. This is why I favour adding things similar to runeflares to the two knights that lack them: this is a simple concept with a lot of design space, and learned mechanics remain mostly relevant with only a minor paradigm shift for the most part.
If I was doing the Deathknight classleads, I would think about repurposing vivisect. Its the iconic necromancy finisher and is currently a terrible version of cleave because at initial knight release there wasn't really a place for it. I think with some adjustments it could fix up some of the issues Deathknight is facing (and will face with the likely nerf of the teeth enhancement).
I would 100% stay away from blunt weapons, regardless. Absolutely agree with Naruj on that can of worms.
Leading on from Owyn's comment, a better way to handle that kind of thing is to pass a function rather than a prefix. I tried to avoid that in the example above because that can confuse a lot of people who aren't used to first class functions, but something like:
function queueEqbal(command) send("queue eqbal clear" .. your separator .. "queue eqbal " .. command) end
function rawSend(command) send(command) end
function ifeqbal(command) send("ifeqbal " .. command) end
function dispatch(sendMethod) command = join(action table, your separator) sendMethod(command) end
Etc. This is objectively better, but its also more complicated if you're not comfortable with how functions work. It does let you weather major gameside changes like queueing rewrites etc without significant problems, however. Of course, you can achieve similar behaviour using a prefix style with something like:
dispatch("queue eqbal clear " .. your separator .. "queue eqbal")
However, this limits what you can do and is also fragile. At this point you're starting to make the system do something outside of the obvious and are having to compose strings as arguments to get the behaviour you want. This isn't ideal. Some people like to pass a string to their dispatch equivalent then lookup the correct function from a separate table. This does work, but is almost always because they went with a prefix approach initially then didn't want to rewrite major sections of their aliases to conform to a more function based approach. Perfectly valid, regardless.
But basically, do what you're comfortable with. I tend to recommend a prefix approach to people who are just learning, because it works and has less abstraction from what you already understand (game mechanics). The function approach is better, overall, though.
In addition, you might want to consider abstracting all that out into a single function. Having a list of functions you call in every alias does not scale well (for instance, 2 weeks from now you're going to add a "pullArrowCheck" for incendiary. You now either have to put that somewhere unintuitive like your check mount function (this is what you'll do because its easier, its also a mistake and you'll hate yourself a year from now), or you have to add it to every alias that have your various checks. You have a few common approaches to this:
- You can define a table of functions, then have a preCommands function that is called in your aliases that just iterates over that table and calls each one in turn. - You can have a preCommands function that just calls a bunch of functions one after the other. This is fine though less flexible, not allowing you to trivially dynamically add/remove checks at runtime. Its quite possibly the simplest way and the benefit of a single abstraction like this is that you can rewrite that function later without actually having to change anything else.
Something else to consider is if you want to handle commands in this way. This might not seem important now but its a pretty key thing to decide, given you're not in a location with great ping. A linear list of functions that you call that then send commands does prohibit you from using ifeqbal/queueing/separators trivially. If you do want to use these you can: - Rather than sending the commands push them to a table, then have your own send function that joins those commands by your separator and dispatches them to whatever method you want to use (be that a standard send, a queue eqbal, an ifeqbal, etc). or - You can have your functions return strings and just append them. I see a lot of people do this and advise against it. It is inflexible and doesn't allow for clean lookups for if you're using a command already, etc. It also requires you to handle your separators yourself, and you'll inevitably miss one somewhere and then have to track down where you forgot to insert one. A join is just better in this case.
I'd go with something like this:
function prepare(command) append command to action table end
function exampleTrueassessCheckYouShouldNeverDoBecausePreTrueassessOnEveryActionWillKillYou(target) prepare("trueassess " .. target) end
function preCommands(target) reset action table to empty foreach check in checks check(target) end end
function dispatch(prefix) command = join(action table, your separator) send(prefix .. " " .. command) end
function spearStab(target, toxin) prepare("spear stab " .. target .. " " .. toxin) end
function yourSpearStabThing(target) preCommands(target) spearStab(target, "probably chiltran because chiltran is awesome") dispatch("queue eqbal") end
That's all very rough, but is how I would do things if looking for a good place to get started. Ideally you want to spend less time coding and more time playing the game, so having something that let's you throw attacks together quickly is ideal. Even if you do go with just a standard send and forget about queueing etc, I recommend writing your own wrapper around your client's built in send function. This is because down the line there's a good chance you'll want to double up commands or something like that when afflicted with stupidity etc.
I would think it worth posing the question if org deletion has actually solved any issues. From my (admittedly now limited perspective), it has not. Circle deletion is a very different beast and I think there are tangible pros/cons there, but I remain sceptical of the idea that single org deletions has any nontrivial benefit without a very specific aim in mind.
As for the event, I don't have the full picture (I turned up for the ending and got randomly mobbed by Kinsarmar and then got recruited by Khandava), but a couple of thoughts: - I think its important to give established characters a bit of hype when they do die. I suspect people would've cared less about Esmyrsia getting smashed if it'd been a bigger send off. - Liked that we got to decide who would die when it came to the lichs. - Like the thematic changes to death. - Sad we lost Lhortae because he's easily one of the toughest bosses in Ire and has some of the best(griefiest) mechanics. It takes a special kind of boss to only die twice to players in half a decade. - Obviously, I liked the pk chaos. Do think some more things to do for the rp types while they were being defended would've been good, and would've added an additional sense of urgency.
Re Grashella saving Antioch: going to disagree with the people who said it shouldn't have been allowed. I understand their side (that Antioch is struggling and a logical org to kill if one has to die), but most of the reason to play a mud in 2017 over typical multi player games is you get to tangibly influence the direction things go. Just look at the last few posts to see how people react when they feel they lose their agency to influence something they think they should've been able to.