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

    775
  • Joined

  • Last visited

Everything posted by Darkrasp

  1. Happy Friday, We're excited to announce the beginning of Beta Signup. We appreciate your patience over the long delay, and we're looking forward to working with you to make Crestfall the best server it can possibly be. I would like to go over a few important pieces of information with you before you sign up. 1) The server is not finished. This isn't a pre-release "final polish" beta test, this is a working closed beta with the realm under heavy development. We will be working directly with the testers to identify/fix problems and add content. There is a bug tracker, and beta testers will be expected to identify problems and describe, as carefully and accurately as possible, the correct working behavior, with sources when they are available. 2) Beta applicants should fill out the form honestly. Try to identify your area of highest expertise, even if you don't feel you are particularly strong at any one thing. 3) Everyone interested should fill out an application, even if you don't think your knowledge is up to snuff. The purpose of the form isn't to exclude people, it's just to ensure that we get the expertise we need at the most relevant times, and can give each area of the game the attention it deserves. That said, there are going to be times when we just need warm bodies to fill queue spaces, and as the beta progresses we will be inviting more and more people in. 4) You will need to verify your email in order for us to process your application. After you have submitted your application, you will be sent an email to verify that you are the one who applied. Applications that have not been validated will not be considered, so please make sure you do this. 5) Be patient after your application is submitted. We won't be getting back to anyone immediately. When we start contacting people (a few days in advance of the beta itself), we will email you a unique password and a link to a registration page where you will have to enter that code (which can only be used once) to create an account. As mentioned above, just because you aren't contacted immediately doesn't mean you are rejected, it just means that we aren't ready to test what you indicated you know best. Our development resources are limited so we will be pushing through various areas of the game and it's content sequentially. We don't want to waste people's time by bringing in more testers than our devs can work with. 6) Beta testers must have a forum account and be on our Discord. This is pretty straightforward, we want to be able to talk directly with the testers to resolve problems as quickly, efficiently, and thoroughly as possible. 7) Beta testers are under a limited Non-Disclosure Agreement. Applicants, once they are invited into the beta, will be given access to special forum and discord sections where discussion of the beta is permitted. Outside of those venues, discussion of beta content will result in immediate suspension of beta access. I think that about covers all the fundamentals. Read the form carefully, fill it out honestly. We're looking forward to hearing from you. Thank you again for your interest in Crestfall's Closed Beta. Proceed to the signup form by clicking here: http://beta.crestfall-gaming.com/
  2. Good evening, About time for another post. I'm going to keep this short (seriously this time) because Asura wants to do a post for next week and doesn't want me to spill the beans on everything that's been going on, so all you'll get is a brief summary of what I've been doing. First thing was to finish off the level-up stats for players and getting the proper Blizzlike formulas in there, rather than the estimated junk used previously and on other realms. Our Beta team spent a tremendous amount of time and did an awesome job on the research and mathematical proofs for the correct formulas, so it was important to get that working. It took a little bit longer than expected to figure out some of the implementation, but it all got done and the code works flawlessly now. While we were at it, we looked into the formulas used to derive spell crit from intellect. In most cases you'll see formulas similar to the ones described on Wowwiki, which are fine at level 60, but have been flatly refuted by Blizzard as being correct in any other situation, yet they are still widely used at all levels on most realms. Tseric, a Blizzard CM at the time, posted that spell critical strike was determined based on an "expected intellect at level 60", which varied by class. Having that much intellect at level 60 would give you 5% spell crit. After that, it would scale at a rate of approximately (and again, it varies by class) 1% crit per 60 additional intellect. Using this, players came up with a pretty simple formula that fit the pattern for each class. (Note: The correct amounts here have been rounded off to make this easier to read.) For example, a shaman's "expected intellect" at level 60 is 160. That's ~85 from base white stats, and you're expected to have another ~75 on your gear. The point was that at 160 intellect, you would get 5% spell crit. If you got up to ~220 (adding 60 int), you'd be up to 6% spell crit. Add another 60 intellect, gain another 1% crit, and so on. The players reversed this to create a general formula, assuming that every 60 intellect means 1% crit, and figured that the spell crit calculation for the Shaman class is [2.3% + Int/60], which gives the correct 5% amount with 160 intellect. Here's the problem: Tseric also states that the formula only works at level 60, and that intellect is worth more at lower levels. This formula breaks completely when you look at Mages, for example, where their base value only works out to 0.2%, which is an absolute pittance. When you try to use that same formula at all levels, a low level Mage will stay at sub-1% crit for a looong time - I believe they don't break the 1% mark around level 18. Anyways, I won't drag out the mathematics, but I basically figured out a proper scaling calculation that adjusts for the relative value of intellect at different levels. It's a little complicated, but it works very nicely, and has the result that you should be seeing a more stable baseline crit percentage along the entire leveling curve. We also fixed up the formulas for Attack Power, since two of the classes had incorrect ones from Burning Crusade, leftovers from the old Ascent code. I also finally got Extra Strikes working and implemented exactly how I wanted them to work. That was a trial and a half, and extremely frustrating (Windfury!!!!), but it's done. Spells which generate extra strikes can now multiproc, but cannot double proc, and if multiple procs occur on the same swing, only the highest one applies. To clarify that, a small example: You swing once, and proc Windfury. Windfury AP buff is added, and two extra attacks get queued up. You take your first bonus swing (from Windfury, with bonus Windfury AP) -> No procs occur. You take your second bonus Windfury swing (from Windfury, with bonus Windfury AP) -> This swing procs Ironfoe and Hand of Justice. The Windfury AP buff falls off - only the two attacks granted by Windfury benefit from it. You gain two additional swings from Ironfoe, the Hand of Justice proc is ignored as it has lower value. You take your third bonus swing (from Ironfoe) -> You proc Windfury again, but it is ignored because it has already procced once in this chain. You take your fourth bonus swing (from Ironfoe) -> You proc Hand of Justice again, but it is ignored because it has already procced once in this chain (even though it was ignored). All five swings have now been processed, swing timer is reset. Before anyone loses their mind.. I know. The thing with how extra strikes work is that it changed a bunch of times through Vanilla and can basically be proven to work any one of three or four different ways. Rather than fight it out, we just decided on a way that is neither the weakest or the strongest iteration and went with it. It isn't necessarily exactly the way it worked in 1.5 or 1.9 or 1.12 or any other patch, but it's a fair middle ground and players will at least know what to expect in terms of behavior so they can theorycraft around it. It's stable, logical, and I believe reasonable. So there you have it. Windfury even plays it's animation properly. The only thing left to look at is a small bug in the combat log, but since it's only visual I'm not really concerned about it and I'm happy to put that on the backburner while I work on some other stuff. You can see what it's doing from this screenshot: The text for when you gain/fade the buffs is delayed and showing up in the wrong order. Not sure why, and I can't figure out which packet is causing those messages to be sent to the client in the first place so I can't figure the timing issue out. Maybe someone reading this knows offhand, if so, feel free to let me know. And if you're going to suggest SMSG_UPDATE_AURA_DURATION, I already tried that one. Doesn't seem to have any effect. I guess I might be missing something though. Anyways, last thing was a tiny patch that now gives proper threat for spells like Power Word: Shield, and another tiny patch that corrected the durations on a handful of temporary weapon buffs, like fishing lures or shaman weapon enhancements. Alright, that's plenty long enough for now, you're all caught up with my work. My next update will be on Monday, June 12th. As always, feel free to ask questions or leave comments below. Talk to you soon, and thanks again for your continued interest in Crestfall.
  3. Asura is not announcing a date for release or open beta. He just wants to do a project update because it's been a long time since he last posted anything. Take a deep breath and relax.
  4. Good afternoon, As most of you are well aware, the last couple weeks have been a bit of a whirlwind. We think the idea behind the LGN was a noble one, or at least, it seemed like a good idea at the time, but later events and revelations showed we had made some poor choices. Things didn't turn out the way we had planned or hoped; we're a little disappointed, and to the community members we offended or let down, we're very sorry. We want to assure you, that's over now: we're still working, still engaged, and excited for the future of Crestfall. First, I have to address the major changes we intend to make going forward. We were unprepared for the level of scrutiny and personal privacy invasion that accompanied the most recent dramatic outburst, and for a time did strongly consider cancelling the project entirely. We have elected instead to go a different route. This weekend, we will be muting or removing all public Discord channels and ceasing all involvement on reddit. Discord will still be utilized for internal communication, but discussion with the community will come on these forums only. Our CMs and mods have been working overtime, but the amount of time spent attempting to control communication via instant messaging has proven to be too much of a distraction from the work of developing the project. Going forward, we are going to establish a better internal communication mechanism to allow our staff to more effectively answer questions and resolve situations that come up. We plan to thoroughly (within reason) examine any future additions to the staff to make sure we maintain a good reputation, and our good internal relationship, as we grow. We also plan to consult with trusted community members before deciding on any major changes or considerations so we can better predict the response and potential pitfalls. As for the server itself, our plans for the project are reverting to our original intentions. We still plan to release in 2017. Our closed beta for class testing is still ongoing. We will continue to invite additional beta testers as necessary and will contact them individually using the information provided in their applications. Volunteers interested in scripting will be contacted in the same method that they contacted us, whether on Discord or the forums. When we are ready for launch, Crestfall will have a PvE and PvP realm, with a 5k population cap. If the peaks begin hitting 4k, we will open additional realms as necessary to keep potential queue times down. We will do progressive content releases - as originally planned, not perfectly patch by patch, but a close approximation that will be easier for us to manage. We will accept voluntary donations but there will be no purchase of in-game items for real money. In the event that voluntary donations are insufficient to maintain the realms we will consider opening a cash shop for vanity items such as TCG items or Blizzcon pets, but at no point will we sell levels, gear, gold, or anything else with an in-game effect. We'd rather just shut down the realm than compromise our integrity in that way. When we are ready to progress to TBC, we will provide a period of time where we allow players to flag their characters for transfer to TBC. At the end of this period, flagged characters will be moved along with their entire inventory to the TBC realm in a 2.0.1 pre-patch state. This new TBC realm will experience the Dark Portal event and continue on with Burning Crusade content. At any time, characters left behind on the Vanilla realm can be manually flagged by the player, and at the next server maintenance, they will be transferred to the TBC realm. No copies of characters will be left behind, but new characters can be rolled on any realm at any time. After the new realm is open and players have transferred, we will monitor realm populations. If there are insufficient players remaining on the Vanilla realms to maintain a reasonable play experience or financial viability, we will merge realms. We will of course consult with the community before merging any realms to make sure it is handled in a responsible manner. If players are happy with their current populations, even if they are low, then we have no problem leaving them open as long as the realms are financially sustainable. While we reserve the right to make changes if glaring problems are exposed with the process, this is the plan we intend to follow for all expansion progressions. The reason we are going to do transfers rather than copies is that it bypasses a major problem with resources. We can't have people shuffling around gold or items to alts and transferring up an infinite amount of resources for themselves or their guild. We would have to implement a very restrictive cap on what could be carried forward in order to prevent duping and exploitation, which penalizes any player who earned their gold and items legitimately. This way, items that are moved from Vanilla to TBC are removed from the Vanilla economy, preventing massive imbalances. So, a player can roll on the Vanilla realm, enjoy their levelling and progression experience, and when it's time for TBC, if they want to progress to the new expansion, they can do so immediately. If they decide with their guild that they want to stay in Vanilla for a few more weeks or months and complete Naxxramas or hit Rank 14, or complete whatever goals they set for themselves, they can do that before transferring up and rejoining the main stream. Players who wish to stay in Vanilla permanently can also do so, though they will have to be prepared for the potential of a server merge if the populations drop too far to be sustainable. There's the plan. We're past the delays and back to work on our own project. Our focus is 100% on getting Crestfall up and running as soon as possible. We're glad to be free of distractions and once again excited about the future. I will continue with bi-weekly development blogs to give some insight into what we're working on, but due to this message going out so close, I'm going to push it back by one week. My next blog post will be on Monday, March 6th and will continue every other week from then on. For people who are interested in contributing to the project, you can do so by contributing to the forums, as this is where the community will always be. While we are no longer working with teams from other projects, we will continue to be respectful and polite towards them, and we also ask members of our forums to do the same. We hope you'll enjoy following along with us as we work to make Crestfall the next stage in WoW emulation.
  5. 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.
  6. +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.
  7. 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.
  8. 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.
  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. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. Edited original post for an addendum.
  17. Good evening, Time for a quick rundown of the last two weeks. The database bugs have been slower in coming so we've been focusing more on core work. We've also been taking a bit of vacation and dealing with other miscellaneous real-life business. Asura has been doing a lot of work on spellpower coefficients, buffs and debuffs, and spell family assignments. We've been fixing a bunch of triggered spells and spending an inordinate amount of time on Bloodrage. I'm quite sick of that spell by now. Some other miscellaneous bugs we've fixed up include issues with item saving, a weird bug that made abilities go on permanent cooldown, and some junky old Ascent hacks that needed to be removed and done properly. What else.. mana shield fixes, polymorph health regen, some visual bugs.. Just a lot of miscellaneous stuff rather than one or two big things. Rodeg, for example, wrote up a handler so that rested XP properly applies to mob kills. Of the things I mentioned we were working on last update, two of the three are done. The save/load issue with Auras is fixed, it was actually a problem with Warriors such that the threat modifier from Battle Stance applied all the time on top of whatever stance you were in at the time. I just put the finishing touches on some code that properly handles the threat from Energize effects, which ended up having to be done in two different stages. First was preventing threat from periodic mana gains (ie. Mana Spring Totem). Originally the Ascent spell code for this effect just directly modified the target's Mana field, so it never got into the threat code. Asura did some updating and modernization of the code, and now those periodic Energize effects call the regular Energize code, which does have a threat component, so it became necessary to identify and ignore threat generation from periodic mana sources like Mana Spring or Blessing of Wisdom. Secondly, research from our Beta testers indicated that threat from Rage gains (also an Energize effect) should be unmodified by percentage threat modifiers (ie. Stances). That is, when you gain a point of rage from an effect like Shield Specialization or Bloodrage, it should give you 5 threat, only 5 threat, and always 5 threat. Salvation, Tranquil Air, Defensive Stance, etc. cannot modify that amount. This was corrected by implementing a custom attribute that allowed threat modifiers to be ignored and applying it to the relevant spells. I tried a couple different ways of doing this but the custom attrib came out the cleanest. I still need to look at that junk about combo points. I'm pretty sure I know what the problem is, likely something to do with the sequence of events and the timing of when the combo points are removed again. We had a problem with this before when the spell delay system was implemented, where the combo points were being removed as soon as the cast completed, but if the effect was delayed by the queue, then when the effect fired off, the combo points were already gone. We put in a fix for this that worked for a while, but obviously the spell system refactoring has broken that again, so I'll have to take another look at the sequencing. The other thing I'm working on and am currently neck-deep in is Extra Strike processing. This is a fan favorite and never fails to generate a huge amount of acrimony, contradictory evidence and utter confusion in the beta chat. Nobody seems to really, fully understand how these things are supposed to work and interact with each other. It doesn't help that Blizzard used some doublespeak and confusing terms in their spell descriptions. Sword Specialization, for example, says "Gives you an x% chance to get an extra attack on the same target after dealing damage with your sword", where Thrash (the triggered spell from the Thrash Blade) says "Grants an extra attack on your next swing." When they say "next swing", does that mean it applies that second swing instantly, or does it save up the attack and the next time you autoattack, it hits twice? If that is the case, does it matter how long it is between attacks? Can you proc an extra attack for "your next swing", run around a bit, and then use it against a different mob? When do extra attacks "on your next swing" actually get used up? Can the extra attacks you get proc additional extra attacks? If so, do they apply on the same swing, or on the next swing? Can the same ability proc multiple times on the same initial swing? (Btw, right now, ours is applying on the next swing, which is goofy. Similar to the issue I mentioned above with combo points, I believe this has to do with the sequencing of when the extra attacks are queued up versus when they are executed. I'm going to look into that.) Some of these are rhetorical questions to which we already know the answers, but people ask nonetheless, and with good reason. Blizzard changed many of these abilities several times over the course of Vanilla, so contradictory evidence exists for a number of different situations. I've seen screenshots of quadruple Ironfoe procs, or Windfury proccing Sword Spec proccing Windfury again. I've seen combat log entries where three different abilities proc on the same swing but only one extra attack is actually granted. Given that there seems to be virtually no consensus on how this stuff is supposed to work, my opinion is that I'm going to go Blizzlike+ and try to untangle it into something coherent, removing some of the shenanigans that Blizzard apparently tried to remove. - First, I'm going to have all extra strikes process immediately after the strike that procced them. You can't build up extra strikes on one target and carry them to another (Except for Reckoning, different story there). If the target dies or becomes immune/untargetable, any remaining extra strikes will be wasted. This is a bug affecting us right now but I mean to get rid of that ASAP. - Secondly, a single strike can only proc one "extra strike" counter. For example, if you have Ironfoe enchanted with Fiery Weapon, and a Hand of Justice, you make an autoattack and all three proc on that swing, what will happen is you get the Fiery Weapon proc on the initial autoattack, and you gain two extra strikes (both from Ironfoe - the Hand of Justice proc is ignored because it is a weaker version of the Ironfoe proc), instead of adding them together for three extra attacks. This behavior is made fairly clear in 1.12-era references whereby Sword Spec, Windfury Totem and Hand of Justice all proccing simultaneously only results in 1 extra attack rather than three. In short, only the highest procced value applies on a given strike. This is the tricky one, not sure how to do this just yet. - Thirdly, the extra strikes can proc additional extra strikes, but only from other sources, and only once per source. I already have a working version of this code but it needs further refinement. Ie. This is OK: Initial Autoattack procs Windfury -> Windfury extra attack procs HoJ -> HoJ extra attack procs Ironfoe This is not: Initial Autoattack procs Windfury -> Windfury extra attack procs ANOTHER Windfury This is also not: Initial Autoattack procs Windfury -> Windfury extra attack procs HoJ -> HoJ extra attack procs ANOTHER Windfury I realize this isn't 100% Blizzlike, but it's obviously something Blizzard was trying to correct all along; they made a number of efforts to resolve it, and I don't like the idea that you could have the stars align and just keep chain proccing extra attacks back and forth and one-shot anything in the game. That kind of behavior is clearly unintended and exploitative, and I see no reason to leave in a broken mechanic just because Blizzard's attempts to fix it were a hamfisted series of half-measures, stealth patches, nerfs, buffs and mechanic reworks. I'm willing to listen to opinions on this, but I don't promise I'll change my mind. It's obvious that there are a lot of contradictory evidences for this mechanic working a lot of different ways, so I'm just setting out an intention and saying, "this is how I plan to have it working on CF". Alright, I suppose that bit of discussion has thoroughly enraged all horde players reading this for one reason or another. I'll leave it there for now, and again, I'm willing to listen to some opinion on it. If I wasn't I wouldn't mention it, but don't take that as license to go ape crazy on me, please. That's all for now. My next update will be on Monday May 1st. As always, feel free to leave comments or ask questions below. Talk to you soon, and thanks again for your continued interest in Crestfall.
  18. 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.
  19. 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.
  20. 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.
  21. This is correct.
  22. People do know that the ability for Windfury to proc itself was patched out of retail in 1.4, right? This is exactly what I was talking about when I said there had been a lot of changes to how extra strikes are processed and there is lots of contradicting evidence as to how it worked. In this case, I'm taking what I believe to be a balanced, sensible and logical solution and implementing it.
  23. It's hard to gauge exactly what the effect will be since Windfury has been variously broken on pservers for years, and it was frequently broken on retail as well. The underlying mechanics were adjusted a few times by Blizzard, so there isn't even really a reliable retail baseline to compare to. I think we'll see Windfury still being very strong, and the extra strikes from it capable of proccing additional on-hit effects, which is really the important thing. It will be stronger than it is on realms where Windfury can't chain proc at all, and weaker than on realms that allow for infinite chaining procs. In reality, the odds of chaining Windfury into Sword Spec into HoJ are extremely small, it's not something that would happen often anyways, so it is probably not a huge nerf versus allowing infinitely chaining procs, but having a standardized system that works in a predictable fashion should be a benefit across the board. Provided my coding kung fu is up to the task, of course.
  24. Good evening, Time once again for a recap of the last couple weeks. We're back into the full swing of development and a lot is happening. Honestly I wish I'd taken better notes during the week because we've pushed out a lot of fixes and I can't even remember what all of them are. I'll do my best to summarize. First of all Gorbulas and I have both been addressing lots of database issues from the tracker. They're typically quick fixes. He does a lot of fixing npc waypoints, quest levels, quest rewards, missing tags for elite mobs or quests, group quests, etc. I do a lot of npc ability fixes and droprate adjustments, or adding missing drop items. Gorbulas' fixes come in large part due to the fact that a lot of our database is backported TBC data, so it's just a matter of reverting the information back to Vanilla stats. Alternatively, there are some things he does that are just errors in the database due to better research having been done since the data was originally compiled. My spell bugs tend to come from a few things.. One is typos that I made myself when I wrote the scripts, another is from changes to the scripting engine since those scripts were written that require addressing. Thirdly is just broken spells, which are addressed separately with spellfixes or spell scripts. Drop corrections for missing items, bad drop rates, etc. tend to come from the nature of how I built the loot database. Certain quest items didn't get added properly, some droprates were estimated by me based on data from a few sources, and of course, there are a bunch of typos and copy/paste errors. Fortunately, these are all super easy fixes. I don't mind sitting down in the evening and seeing a dozen of those reports because I can typically clear them all up within 30 minutes or so and feel good about knocking a bunch of issues off the tracker by barely lifting a finger, before I start banging my head against larger and more substantial bugs. More good news is that Rodeg has got some free time from his studies and is back to work. He's got a bunch of issues assigned to him and has already pushed a few fixes, including a couple just today. Asura has been working like a fiend.. This is where my memory gets hazy because he's been working on a bunch of different things. In the last five days he's worked on the reputation and faction systems, fixed a major AI bug with triggered creature events, fixed bugs with flightpaths, implemented an extremely draconian server-side anti-cheat and started working on the false positives, fixed a bunch of spell bugs, got rid of a dirty fallback for data loading and implemented a proper fix for it, along with a whole bunch of other smaller things. Including fishing. In his words (more or less), "I never fished when I played retail. I've fished more in the last four weeks than I ever did in all my years of playing." I don't remember what he was working on before that. It's been pretty crazy. I've put in a handful of core fixes this week myself, though nothing that impressive. I did some work on pickpocketing, fixed an issue with the armor reduction calculation and prepared the TBC version of it as well, another pass to improve the Avoidance math (dodge/block/parry), a couple fishing fixes of my own, and I started some work on Energize threat. It's a partial fix, though. What this means is popping a mana potion, rage potion, or Bloodrage will give you threat, as will gaining rage or mana from talents like Improved Shield Block. However, the threat from those gains are not supposed to be modified by "percent threat generated" auras, such as Warrior stances, and right now they are. Also, it's apparently somehow bled into periodic energizes like Mana Spring Totems, even though those shouldn't give threat. I'm going to have to figure those ones out. I started work on a bypass for the aura modifier code on my local test machine, but my first attempt went horribly wrong and I was getting all sorts of bizarre effects, so I just reverted the changes and I'm going to try a new way tomorrow or Wednesday. Win some, lose some. Anyways, our bug tracker is pretty lively. Elicas is the king of bug reports, a huge percentage of the bugs are from him alone. We're maintaining a pretty solid percentage of resolved bugs, and we have lots of issues that we have written fixes for and are waiting to be pushed to the test realm for a recheck. Many of the bugs are, as I mentioned before, very simple fixes. We can usually write the patches for about 75% of the bugs that come in on the same day they are reported. Others take a little more time, or we kind of ignore since we know they are part of larger issues already being worked on, or are duplicates of other reports (mechanically, though affecting a different NPC or whatever). As an example, we had three separate reports about pickpocketing not working for certain Rogue quests.. the bug in that case was a larger issue with pickpocketing in general. The "big issues" undergoing work right now, for me anyways, are an issue with aura saving for players when they log in and out, some funkiness with combo points that was fixed earlier but recent changes have caused to break again, and the Energize threat I was talking about before. Should have all those cleared up by the weekend, I think. Roadblock, Soulson, and sQweegle have been doing some incredible work on the math for stat/hp/mp gains on levelup, so I'm also looking forward to working with them on implementing that in the core. So, things are progressing well. No snags or delays, and we're working away nicely. Everything still on track. As far as more videos or a website frontend, our focus recently has just been on writing code and fixing mechanics. We have a list of things we want to get done before we are comfortable taking our feet off the gas and spending time on videos or other "side-projects". We've decided to stay focused on development until we get close to Open Beta, and then we'll start the work of producing promotional materials. Right now we're full steam ahead on development and want to keep our momentum going. Alright, that's all for now. My next update will be on Monday, April 17th. As always, feel free to ask questions or leave comments below. Talk to you soon, and thanks again for your continued interest in Crestfall. P.S. I know that the date in the thread title and the image are reversed. Inari is kind enough to make the banners for me, and prefers the European dating format, whereas I use the North American one.
  25. Questions.. @Pvt_8Ball @raiko We brought people in to test classes, but they tend to report all kinds of things, we're just fixing everything that comes at us. Classes are still the main focus but we're working on a little bit of everything, mostly prioritizing by severity. We're satisfied with our rate of progress so far. @Aurigon I realize that having just our current dev staff scripting every little quest and event, in addition to our other work, would take just about forever. That's why we are crowdsourcing the scripting to volunteers. We're starting internally with a couple of the beta testers who have extensive programming experience, and then having them teach additional volunteers after we work out deficiencies with the scripting engine. With any luck, we'll have a dozen people writing quest/event scripts Soon(tm), and we won't have to spend any time on that at all other than reviewing and inspecting the completed scripts for exploits, instability, errors, etc.