Welcome to Crestfall Gaming

Register now to Crestfall Gaming. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

Darkrasp

Developer
  • Content count

    768
  • Joined

  • Last visited

Community Reputation

2830 Excellent

About Darkrasp

  • Rank
    Knight-Lieutenant

Recent Profile Visitors

5176 profile views
  1. Of course, it reduces overall incoming damage over the length of the fight if the fight is shorter, but I'm talking about incoming damage over the course of 2-3 batch processes - if no heals are forthcoming. A tank with high mitigation can usually survive a few seconds without healing. A tank without mitigation.. not so much. Late into Vanilla you had healing rotations set up such that the tank would be getting a heal every batch or two whether they needed it or not, because you never knew whether or not they would need it. Couple paladins spamming Flash of Light, a priest (or two) dropping shields and downranked heals, and a stack of HoTs were pretty much a permanent fixture on the MT during an encounter. If you're dedicating 6-7 healers to spamming tanks, you don't have enough left to heal the raid through incidental AoE when you're only bringing 8. Retail raid comps had 11-14 healers, depending on the encounter and the skill of the players, and we expect a return to those numbers. Seriously, get rid of the ability to cancel casts and just watch what happens to the healers. The first while after launch when people are still getting accustomed to that is going to be a gong show.
  2. +1 Similarly, if you play a gnome mage rather than a human, you have to deal with the gnome's voice. ..and the fact that you are playing a gnome at all.
  3. What's better, a geared Undead tank that knows how to play, or a Tauren tank that's a scrub and keeps forgetting to pop cooldowns appropriately, or has a 200ms higher latency, or never gets BIS gear to drop? People act like min-maxing is such a vital part of the game, when in reality it's just a more work for incremental differences that matter a lot less than skill, luck, and lag. Also, people are going to be shocked at how badly it works out trying to turn every encounter into a DPS race. Spell delay changes everything. You've been playing private servers using timing mechanics from Warlords of Draenor, simply because nobody bothered to implement a proper spell queue. The spell delay system means that most spells affecting another target (including heals) don't take immediate effect. They're loaded into a queue, which is batch processed and the final result is downloaded to the player on a 400ms tick. That means you only get to see the effects of heals on a 400ms tick. If a couple attacks come in (autoattacks DO take immediate effect - they aren't spells and aren't subject to delay), and you cancelled your heal because the tank's health was fine 400ms ago, your tank just died because there were no heals in the queue to keep him breathing, and there won't be any until the next tick either. Higher mitigation means it's easier to survive between batches. This was a fact of retail life and it'll be a fact of life on Crestfall. Watch what happens when healers are forced to heal proactively and cannot safely cancel heals anymore, but they try anyways. Tanks without mitigation are going to spend a lot of time face down on the ground. When healer efficiency drops like a rock, the strategies and raid compositions will have to change to compensate for it.
  4. Probably worth mentioning that dodge isn't a great stat in the higher tiers of PvE, especially with functioning spell delay. Mobs hit so hard that healers can't cancel their heals or risk having the tank die from spike damage, and their heals are subject to delay, meaning they have to complete the heal to get it in the queue before they can see whether or not it's absolutely necessary. Yes, a dodge means that you don't die, which is obviously important, but if that hit wasn't going to kill you, it's really just a waste of healer mana. If you have a choice, you're better off with more absorption in the form of resists (including armor) and health. For a feral tank, min-maxing, you want the Tauren HP buff. (Note: It's not a Stamina buff, it's an HP buff. There is a difference.) Paladins do provide better buffs than Shamans do, or more accurately, they have Kings and Salvation. The tradeoff is no Chain Heal. Windfury has it's advantages but only if you're not threat capped already. I'd say that Chain Heal is page one of "Raiding for Dummies" (page two is Fear Ward) and simplifies raid healing to an absurd extent. If you have bad healers, you want them playing Shamans. Paladins make great tank healers but terrible group healers. So it's really situational depending on who else is in your raid and how good they are. Put nicely, the difference in capability between an Alliance raid and a Horde Raid has a lot more to do with the relative ability of the players than any other factor. If you suck at the game, buying a $200 mouse and a $300 keyboard aren't going to make you any better. Neither is picking one faction over another. The difference is only really going to be visible at the highest level of play, in which case clearing the content isn't typically going to be enough of a challenge for faction to be a meaningful factor anyways. You'd be rolling a specific race/class combo purely with the intention of hopefully shaving off a few seconds on a speed run, which is more likely to be decided by a string of lucky crits than anything else anyways, while hoping for those "optimal best in slot" items to drop, which they may never do. Long story short, min-maxing is largely a waste of time and effort. Your skill, and your luck, matter far more than your race.
  5. Our numbers aren't up for discussion. We chose them for two reasons, one, as a middle ground between retail "High Pop" and private server "High Pop". More importantly, though, when we transition to TBC, there will likely be a significant chunk of the population that chooses to make the move, and we want there to be enough people on both realms for them to be viable. Therefore we're going a little bit above normal for for Vanilla in anticipation of it being split when we launch TBC.
  6. Stacking world buffs, flasks, etc. is a way of reducing the relative difficulty of an encounter. The retail philosophy was typically to use flasks and buffs only on progression content, not to waste time and resources collecting all that rubbish for content you were already farming. Most guilds actively looked for ways to spend less time farming and less time on preparation. The fun for us wasn't in spending four hours getting everyone buffed up so we could run Molten Core in 30 minutes, it was rather in seeing just how much we could lowball things and still clear the content. Farmed content meant we didn't even bother even using food buffs, much less flasks or world buffs. Hell, half the time we didn't even bring a full raid. A good chunk of our main raiders, myself included, stopped running Molten Core altogether by the time we'd cleared BWL, and MC became a "fun run" for alts and pugs. I do find it somewhat paradoxical that the players who tend to complain the most about the game being too easy are largely the same ones going to absurd lengths to make the game as easy for themselves as possible. If you're stacking your buffs and MC is too easy for you, leave your flasks in the bank, and try it with two split raids of 25 people each instead. Challenges like that were always more fun and interesting to me than "see how much you can intentionally trivialize the content". It's kind of the reason the Ulduar Hardmodes were widely considered the pinnacle of Blizzard's raid design thinking. Even if the mechanics themselves were somewhat stale, the idea of "intentionally make this fight harder for yourself by doing it differently" was appealing - especially to players who'd been doing that for fun all along. After I quit running Molten Core in Vanilla due to progressing past it, the next time I ran it was in TBC with two friends, so we could challenge ourselves to clear it with just three players. Resto shaman, protection paladin, and frost mage. Took us two days, and we had to swap out for a feral tank on Ragnaros (the Sons' mana burn made it impossible for a paladin tank), but we got it done, and it was one of the most rewarding and enjoyable experiences I had playing retail. I would equate world buffing, flasking, etc. in order to get a fast time on farmed content to running through Razorfen Downs at level 60, buffed and flasked up, just aoeing everything you see. Sure, you can do it quick, but so what? You've completely trivialized it. You don't get props for that. I dunno, I suppose it appeals to some people, but I don't pretend to understand why.
  7. No question you're right about this, which is why I mentioned (albeit in an edit, not in the initial post) that the idea would be to alter different bosses in different ways.. So make a boss that is dangerous for melee.. moreso. Make a boss that hits hard on tanks.. moreso. Make a boss that is an endurance fight for healers.. moreso. Rather than just give all bosses the same buff, which would obviously end up creating a favored DPS/healer "type", handle the buffs on a boss-by-boss basis to create different preferences within the same zone, giving as many class roles as possible a chance to excel. In this way a raid that tries to stack a ton of melee DPS might do great for a few encounters - until they run into one that has been tuned to demolish melee DPS. I think that we can see Blizzard doing this through many of the raids, making certain fights cater to certain playstyles and roles. Patchwerk is a snoozefest for DPS - stand still and nuke without a care in the world - but it is a nailbiter for healers. The next fight in that instance, only a few pulls later, is a much more complicated fight where DPS have to be super aware of what's going on or they'll wipe the raid. If we are careful about making adjustments along those lines, I think we can discourage class stacking by the simple expedient of making a big stack of <insert class here> into a huge liability for several of the encounters. All but the most antisocial raids will prefer to bring in a balanced composition well suited to all encounters over having to play musical chairs and shuffle players in and out of the raid between every boss. As far as plans to buff anything beyond MC/BWL, I think I'm going to hold off on commenting on that for now. Currently the plan is no, but we'll probably see how things go in testing and early release before we make a final decision on it.
  8. Blizzard introduced catch-up gear, better talents, and bugfixes, rather than directly nerf content, except in the rare case (C'thun) where the boss was unintentionally made far too difficult. (We're also talking about MC/BWL here, not Naxxramas. I think it would be quite a stretch to say that the top 1% of guilds struggled with Molten Core even towards the end of Vanilla.) That's more or less the route we intend to follow, but this isn't an elitist's club either. Personally I think it's a novel idea to heavily overtune the content at first to give the top 1% a struggle, even in MC/BWL, and then once they've muscled through it and had their fun, revert it back to the intended (still buffed) state. Hopefully that works out and we can do that. The difficulty for us as developers comes from the manner in which we implement the buffs. The plan with buffing, again, is to reduce margin of error. Just making mobs hit 2x harder so they can 1-shot a tank doesn't do that; it just makes the game arbitrary and unfair. It'll be a balancing act to subtly modify each encounter in a way that enhances it's own inherent difficulty without making success or failure based on RNG.
  9. Good evening, Another two weeks gone already. Time flies when you're having fun. Or staying busy, I guess. It's been an adjustment period for our devs in new roles. Gorbulas is fiddling around with the spell system and getting used to the core. He's like Asura in that he's got a near obsession with clean code, which is good, but it's also pretty funny to see him run across bits of sloppy old Ascent code. I can practically feel his eyes bulging out of his head through the internet. Xaverius has been fighting with some faction stuff, something is set wrong so Argent Sentries at LHC are fighting the other NPCs in the neighbourhood, and he's been trying to get to the bottom of that. Not as simple as you might think if you want to do it right, especially for someone just starting out. Factions are a little weird because there are two different lists of IDs in two different clientside DBC files and the flags for them are poorly documented. Anyways, they're getting up to speed and I expect they'll be making meaningful contributions soon. Asura hasn't been working on CF much over the last two weeks due to IRL issues, I won't get into it because it's personal but it's pretty serious stuff. Suffice to say, he's still working but he's got limited time for the next couple weeks so I'm attempting to pick up the slack and get twice as much done. I've finished and submitted that big immunity update I was talking about last week. Getting immunities to Area of Effect abilities and Debuffs proved a little bit harder than anticipated, and took a couple days longer than I thought it would. Asura wanted the AoE immunity separated into unique masks for positive and negative spells, so we could use that for things like pets, which can be AoE healed, but cannot take AoE damage (from mobs, anyways). I struggled with that after work for a couple days before Asura got me sorted out, but it's done and the code patch to implement the handling and the SQL patch to apply those immunities to the NPCs have all been tested and submitted. I also wrote up a quick patch to implement proper naming for Warlock pets. Each different pet type has it's own list of 32 prefixes and suffixes and randomly selects one of each to build a name. So far it doesn't save the name so you get the same imp every time, so it'll still generate a new name each summon for the time being. I didn't even try to implement that, just wanted to get the name randomizer in there because I knew I could do it in a short time, and it only took a single day, so hooray for me. The research for the prefixes and suffixes was already done, I spent some time a while back poking through old "Post your warlock pet names!" forum threads and was able to build the full list for each pet type after a few hundred posts. I believe I mentioned before that Roadblock, Soulson and sQweegle (maybe also Cragus or Cruzix.. I'm afraid I don't remember who else) did a huge amount of research on player stats, hp and mp. How much you should have at level 1, how much you should have at level 60, and how much you should have at every level inbetween. The formulas we were using previously were a decent but not great estimate, and it turns out that's pretty widespread across emulation. I won't give away their secrets, but there were a few keys they found that unlocked the actual formulas used by Blizzard for all these parameters, and they found enough video evidence to prove that they got it all correct. For the last couple days I've been working with Roadblock to update our database with correct starting values, and implement the proper formulas in the core to generate the rest of the leveling attributes. Yesterday I implemented the extra database columns required, got them loading and storing on server boot, and today we fixed up the calculations to determine how much HP comes from base (white) stamina at any given level (note: it isn't always 10), and mana from intellect (note: it isn't always 15). We're presently working on updating the function that determines base hitpoints and mana at all levels for all race/class combinations, and the last thing will be updating the function that generates the stats at all levels. It might not seem that important to most people that you gain the correct amount of health when going from level 37 to level 38. Most people would probably only care about having the right amount at 60, but I'm making this a priority for a couple reasons. One, the calculations as they were, were wrong. The values at 60 were not correct, and if you're going to fix something, you may as well fix it once and for all. Secondly, these guys spent a lot of time and trouble to get the research for this, and it's important to me that their work get implemented and live on the beta ASAP. Best way to discourage a volunteer is to let their work languish unused for a long period of time. I consider it my privilege to work with a great team of beta testers, and it's important to me to show them their hard work is appreciated and useful. Hm. Elicas asked me to write a thing in here responding to questions about our methodology for raid tuning/balancing, but this is already kind of a wall of text, and I believe he's doing a monthly Q&A next weekend. I'll try to summarize it briefly, and I can provide specific answers in the Q&A if necessary. Obviously, even if you were to make the game an exact copy of what it was on retail, most if not all of the raid content would be a walkover. Plenty of players have had plenty of time to get plenty of practice with the encounters. I recall my retail guild struggling for weeks, months, to clear Vaelestrasz, but sure enough after a few clears, we could fly through the whole raid nearly effortlessly. We weren't a top guild at the time, we weren't intentionally speed running, we weren't using world buffs (or even flasks, the retail philosophy was to only use "expensive" buffs on progression nights - you didn't waste them on farmed content), but we were efficient, and a 45 minute Blackwing Lair clear was kind of expected for us. It's probably worth noting that BWL is largely about execution. Vael is a little bit of a resist wall, but you had fire resist already if you were killing Ragnaros, the rest of the fights can almost all be done by an undergeared group who have experience with the fights. Not so much in AQ, where without significant nature resist on a good chunk of your raid, Huhu is pretty much going to eat you alive, but again, if you have reasonably geared tanks, the rest of the fights can be beaten by undergeared players who know what they are doing. For these reasons, I'm not overly surprised to see raids getting cleared on release day on many private realms, especially considering there is the advantage of knowing which members of the guild are going to need which items and being able to farm up resist materials or items in advance. So, how do you turn a simple execution fight into a progression-keyed wall? Resists are one way, DPS races are another way, HPS races are another way, and Tank Checks are another way. I'm old and out of the loop so I'm not sure what the modern day terminology for these things is (not so long ago I got reamed out for not knowing what a BRD "Lava Run" was.. back in my day it was called an "Emp Run"), but the Huhuran fight is a reasonable example of all of them. Resist walls are obvious, plenty of elemental damage going out from the boss, and you can tweak it so that without sufficient resists it's impossible to heal though. A DPS race is something where you have an enrage timer to beat: if you can't kill the boss fast enough, you lose. An HPS race is one in which a huge amount of damage goes out, or the fight is very long, and you have to worry about healer mana running dry (this kind of goes hand in hand with the others. You can turn a resist wall into a healing race by using less resist gear and trusting your healers to heal through the extra damage). A tank check is something along the lines of Patchwerk, where an undergeared tank is just going to get obliterated by raw DPS from the primary enemy, or Huhu where your tanks have to manage threat well enough to swap aggro without being able to taunt. Our intention with tuning and buffing the encounters is to keep the execution requirement, but also to increase the influence of the other elements, meaning you will still need to execute properly, but the margin for error will be much smaller, and the importance of having a proper, retail-like raid composition and gearing will be more blatant. That means in a fight that's supposed to be a resist wall, you can safely bet you're going to *need* that resistance. The mobs may hit a little bit harder, so the tanks will need a little more gear. The AoE damage hitting the raid may be on shorter cooldowns, so healers are going to have to be on their toes. Mobs may have increased health, armor or resistance to reduce DPS, making for longer fights, and putting more of a strain on the healers. Retail raids typically brought 12-14 healers, and we intend to tune things with that in mind. Now, this isn't going to happen immediately or without a lot of thought for each individual encounter. Our methodology for this is to first get it as close to retail-accurate as we can, erring on the side of making things more difficult when we are forced to guess on anything. It's already going to be significantly more difficult thanks to the work we've done with threat and immunities working more accurately than anywhere else (as far as I know). We'll let our Beta testers have at the content and make sure we have it running nice and bug-free in that Blizzlike state. Once the dents are hammered out, we'll go to staff-only internal testing, where we start cranking up the difficulty level and cutting down the margins for error through measures such as those mentioned above. No funky new tricks for the bosses, they'll just be meaner versions of themselves. When we're happy with what we have internally, that's what we'll release, and of course we reserve the right to increase or reduce the difficulty after the content is released if we discover we've been too harsh - or too lenient. (Edit: Probably also worth mentioning the idea would also be to buff different bosses in different ways, so you might see - purely as a speculative example - one boss with higher armor, and the next boss with higher resists, and the next with high frequency melee AoE, so that while a given encounter may allow one kind of DPS or another to excel, over the course of a raid, a balanced composition will preform better than one which stacks a specific DPS type.) It is also our intention to follow Blizz's example and, if required, nerf the content over time to allow more players to experience it. It's been mentioned plenty of times that it's a bad idea to tune the entire experience around the top 1% of players, so that's not what we're going to do - but we might tune the first few weeks for the top 1%, just to see how that goes. Alright, that's plenty enough text for anyone. My next update will be Monday May 29th. As always, feel free to leave comments or ask questions below, and thanks again for your continued interest in Crestfall.
  10. Horror/Turn/Fear are three separate mechanics, all attached to spells that apply the Fear aura. We can make them work however we want. Plan is the following, which I believe is Blizzlike. Correct me if I'm wrong: Mobs that are immune to Fear effects are also immune to Horror effects. For players, items and abilities which grant a player immunity to Fear don't grant immunity to Horror. Horror effects are, however, subject to diminishing returns.
  11. Good evening, Just want to start by once again apologizing for the delay on this post. Had some family business to attend to that took me out of town for the weekend. In any case, we're back now. First thing, I'm changing the name of these posts from Update to Blog, since that's really what it was supposed to be all along. We were actually going to call this forum section "Developer Blogs" but we liked the sound of "Developer's Corner" better. Hopefully that clears up any misconception about what these posts actually are, my own semi-coherent ramblings, and not official project updates. I'll have to remind Inari of that so the banner image gets the same treatment (Edit: Done. Thanks, Inari ). Alright, to business, I guess let's ignore everything I just said and update everyone on what we've been working on for the last two weeks. Unfortunately, we lost a bit of working time due to a major illness; Asura has bronchitis bad enough that he was bedridden for about a week an was unable to do any work. Fortunately, he's feeling somewhat better, and he's home from work on doctor's orders with nothing better to do than work on CF. So, he's been pounding out a lot of work for the last few days. I suppose the end result is a push. Most recently, he completed the work for event and spell conditionals in the SQL scripting system. I may have touched on this slightly before, but more in-depth explanation follows. Previously we had a couple tables for AI, "creature_spells" and "creature_events". For spells, without getting into too much detail, you'd give a spell ID and a handful of parameters, but the only real conditions we could apply to a spell were range (min/max/only melee/only range/no restriction) or combat (in/out/both). Events could do a bunch of different things, such as changing model info, moving to a waypoint, casting a spell, doing an emote, etc. Off the top of my head I think it was twelve or fifteen different event types. We set them to trigger when a specific condition is met, and had about a dozen triggers set up (spawn/start combat/half health/etc.) We can now add to both of those a far more robust condition system, capable of enabling or disabling both spells and events based on the presence/absence of an aura, health/mana greater than, less than, or equal to any given value, phases, having items equipped or just possessed, quests (or quest groups) active/not active/completed, being in a specific zone, being on a specific terrain, etc. etc. I believe we can attach up to four conditions to any spell or event as well, so there is tremendous flexibility there. This basically means that just about anything can now be scripted in SQL or LUA, including complex quests and events. We expect to push this to the Beta realm this week and have people working by the weekend to play with the system and generate content. He also rebuilt the diminishing returns system (thanks very much to our Beta team, who compiled amazing research on the subject), fixed that spellqueue issue, and a bunch of other stuff I can't remember at the moment. Just to give an idea: Moving on, we had a couple submissions from Rodeg involving item containers, and a few small patches from me. I didn't get as much done as I would have liked but we're in a bit of a limbo state until we get a new database from Asura tomorrow with the AI Condition formatting so I've been doing research and preparing documentation for a big immunity update, also, as mentioned, out of town for a couple days. I did manage to push a couple small fixes before the big change, simple stuff like implementation of orientation in player creation (previously they were just hardcoded to face 0 degrees when spawning a brand new character, which looked alright for most races but Undead were staring right into a wall), and removing the threat from Holy Nova. Pretty trivial stuff there, but it was reported, so it gets fixed. More work on extra strike processing is still to come once the spellqueue stuff Asura altered gets pushed to the Beta realm. Not looking forward to it, Windfury is such a hot mess of an ability. I spent a bunch of time on Graveyards as well, made some progress but not great progress. Learned how to do a little bit of core-side database loading, so that was interesting at least, and I think I'm closer to getting graveyards to work the way I want them to work. Picking away at it. Alright, I want to talk a little bit about the immunity update I'm working on presently. Immunities for a creature are stored in two separate fields, one for their spell school immunities (Fire, Arcane, etc.) and one for their aura immunities. School immunity is pretty self-explanatory but aura immunity is a little more complicated. The value itself is stored as a mask, and we can make this mask as long as we need it to be. Previously it was pretty limited, we use a binary value to store the immunities, set up like this: Confuse | Fear | Disarm | Charm | Pacify | Silence | Slow | Root | Stun | Taunt If a mob is immune to, say, Fear, Silence and Roots, you would express that as a binary value like this: 0100010100 Ones in the places where the mob is immune, zeroes where it is not. That gets converted to an integer value and is stored in the database. Then, when a spell hits, it does a comparison for the auras in the spell, and the immunity mask of the target. If the spell silences, and the mob is immune to silence, then the mob is immune to the spell. It's a pretty simple system and it works pretty well. Not great though, and certainly not good enough. First of all, there aren't enough options, and several of the options overlap in a sketchy way, which will become clear shortly. Secondly, there's no provision for spells that both deal damage and have a crowd control effect. Meaning that if you try to frost nova a mob which is immune to root, the mob will be immune to the entire spell instead of still taking the damage, but being immune to the root. So, I've addressed both those issues by first, adding to the list and expanding several of the categories. For Fear, as an example, you have to be able to distinguish between a Fear and a Turn effect, since Undead are by default immune to fear, but not to Turn. Similarly for Stun, you need to be able to distinguish between a Stun, a Banish, a Shackle, a Freeze, and a Sleep, all of which apply the stun aura, but using different mechanics. A mob that is immune to sleep isn't necessarily immune to all stuns, so they had to be separated out. So I've added that, as well as new handling for Poison, Disease, Bleed, and a few other mechanics I don't recall at the moment. I've also changed the way we handle spells with multiple effects where a creature is immune to the mechanic, but the spell should still land and deal damage, Frost Nova and Frostbolt being excellent examples. Rather than iterate through each of a spell's effects and send an "Immune" response, we instead detect whether the spell is mechanic-only (ie. Fear) or damage-plus-mechanic (ie. Frostbolt). If the spell is mechanic-only, and the immunity check fails, then the spell does not land, and the"Immune" response is sent. If it does damage, however, the spell is allowed to hit and deal it's damage. In the processing for aura application, there is a subtly different check for immunities, and should the target be immune to the mechanic, the debuff simply doesn't apply. Now we can have mobs with proper responses to spells which deal damage plus a crowd control effect. Along with a lot of research, some generously provided by Fuzedknight (along with a heap of other information we are working on implementing), we can now set up proper immunity data and behaviors for all NPC types, so the various subtypes of mechanicals, undead and elementals should all have proper spell interactions. There's a bunch of other stuff going on, but it's more suited to a proper project announcement than a personal blog, so in keeping with the idea of separating my posts from actual updates, I'll leave that out for now and talk to Elicas and Asura about scheduling an official status update with some news you'll undoubtedly be more interested in, sometime in the next week or so. If we can stagger my blog posts, the monthly Q&A, and a monthly project update, that would give us roughly a weekly presence, which seems reasonable, especially if I only have to write half of them. That's all for now. My next update will be Monday, May 15th. As always, feel free to ask questions or leave comments below. Talk to you soon, and thanks again for your continued interest in Crestfall.
  12. Edited original post for an addendum.
  13. Asura did some preliminary work on cross-realm battlegrounds.. I think a couple months ago. I've explained before how it works where you need a worldserver that can talk to multiple realmservers, which is the reverse of what normally happens. Anyways he got it so that characters from two different realms could log onto the same worldserver, and it was unstable and lacked a ton of functionality but you could at least log in and see players from other realms. It was more a proof of concept than a real intention to proceed with the code. As mentioned before, crossrealm is possible, but getting it fully working would eat up a lot of Asura's time, since he's the only one with the expertise to do it, and he's busy working on many other things for our emulator. It would represent a significant delay. For that reason we have no plan to launch with it available, and is something we will only consider post-launch, and even then, only if queue times are so bad as to make it a necessity. I understand the arguments for and against it, but in this case they are moot. Our dev team isn't big enough that we can just assign someone new to this - it would come at a cost of stopping development on other things, and for a considerable amount of time. Purely out of a desire to have the server ready for launch as soon as possible, we are not pursuing further work on crossrealm at this time.
  14. Spent a few hours on it today, found the combo point bug, fixed that and most of the Extra Strikes stuff locally. I have to do some more work and more thorough testing still before I submit it for code review. I just got bored after four or five hours and spent the rest of the day painting and watching TV. The combo points thing was just a copy/paste error Asura made while he was doing some work on channeled spells. The spell system was pushing every spell into the queue (spell delay) regardless of whether or not it should, so that was a simple one-line fix. I did have to do some work on the queue check because there needed to be a skip queue case for triggered spells, which previously also got dumped into the queue all the time. I've got extra strikes properly activating on the current swing, chain proccing, proc capping per swing, and not allowing double procs (read: all the behavior I wanted in my initial post), but there are still some issues with the combat log, and Windfury's AP buff isn't always applying at the correct time, which is very strange because the spell's effects should technically all apply simultaneously. Why it applies the extra strikes perfectly but the AP buff sporadically, I'm not certain yet. I have a feeling it has to do with targeting, but we'll see. More debugging to do tomorrow.
  15. Don't hold your breath. One, the evidence proving his claim didn't come from him, but from Cornholi, who was credited with providing it. Two, Killerduki doesn't read these forums anymore, and if we keep having to moderate your posts for insulting our forum community, you'll be invited to leave as well. Three, what am I supposed to be apologizing for? His repeated ad hominem attacks on myself and the other staff members? Your post in this very thread stating your "proof" (ie. the patch note from Beta stating that Holy Resistance is no longer a "collectable stat") is not useful in this case. There are many unit fields, or stats, that are not "collectable" which unquestionably exist in the game. There aren't any items that increase Proficiency skills, for example. Does the lack of items giving players the ability to "collect" Gutterspeak skill mean that it doesn't exist at all? How about your chance for a glancing blow.. no gear for that, so I guess it doesn't exist either? Equipment procrates? Taxi speed? Let's pretend, just as a mental exercise, that the carrot on a stick and spurs items, in beta, made you fly faster while riding a flightpath. They didn't, I know, but just for the sake of the example, pretend. It's a neat idea, reduces downtime due to travel, but that it was removed as a stat before launch. No more +5% taxi speed items would generate anymore, and they got switched instead to general "+% mounted speed". Your argument is effectively that since "+% flightpath speed" got removed as a "collectable stat", taxis should no longer move at all. Holy resistance doesn't generate on items (read: is not a "collectable stat"), and with respect to items that increase "all resists", it is simply zeroed out for that school at the beginning of the resist calculation, prior to level-based resistances and hit/miss chance being factored in. That's all. Killerduki gave, like you did here, a scattershot mess of vaguely-related errata, much of which was of questionable veracity in the first place, and presented in a format verging on complete incomprehensibility. I'm willing to admit when I'm wrong and implement proven mechanics and formulas where it is in my ability to do so, but I'm going to go with game data extracted from the client over videos from Feenix every time, and I wont apologize for that stance.