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.


  • Content count

  • 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, 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.
  3. 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.
  4. 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.
  5. 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.
  6. This is correct.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. Good afternoon, Happy first day of Spring to my fellow northerners! Also, if you're in North America, happy free DQ ice cream day. Time for a quick development recap for the last couple weeks. We've been plugging along and continuing progress, though it's been hampered somewhat by an extremely busy IRL for most of the staff. Asura is under a heavy workload and has been working extra hours every day at his job. I had a death in the family just a couple days ago and have had to divert a bunch of my time since to helping out with related arrangements. Nonetheless, we're still putting a lot of our spare time into development and things are moving along. It's worth noting again that we are developing TBC simultaneously with Vanilla. This is paying off in a few ways because we're identifying certain limitations of our scripting engine, loot engine, etc. that we need updated for TBC, but when we backport those changes to the Vanilla emulator, allow us to do some things in a much more efficient and authentic manner. Once we got the realm stabilized after the DBC changes, Asura started doing a few test scripts before we start handing out the Lua API to scripters. He identified a fairly straightforward way to vastly improve the SQL script engine using Conditions. I think I'll explain that in a little more depth. Our core supports scripting in three different languages, each has their own pros and cons. The core is written in C++, and we can write scripts in C++ as well. These scripts have the advantage of being able to call tons of different functions from all over the core. They're incredibly flexible and powerful, and we can do pretty much anything we want with them. However, anyone scripting in C++ would need core access in order to test their code (it has to be compiled with the new scripts), and we don't really want to give out core access. For that reason, we have very little scripted in C++ anymore. Lua scripts are the next level down. Each Lua command is "linked" to a C++ function that exists in the core, so you can call that function without actually needing access to the core code. I'm perhaps oversimplifying this, I hope that any experienced developer reading this will forgive me, but these updates are for mass consumption. Scripters upload their test scripts via FTP, and then the realm just gets a simple reboot, no recompile required. It's been developed to a point where is is nearly as flexible as C++ scripting, and we can always add functionality where necessary. SQL is database language. In this case, you're just populating a table with data, and the core knows how to deal with that data. The benefit to this over Lua is that it is extremely efficient, but it's not as flexible (yet). We originally started off with SQL scripting only for creature spells, using an updated version of an old Ascent system called AI Agents. So you'd load in a line with the creature ID, the spell ID, and a handful of parameters like maximum range, cooldown time, etc., and the core would process it and the mob starts casting the spells. We expanded that to include events.. in the first case, it was either a spell or an emote that would be triggered by a single condition, such as reaching half health, starting combat, or killing a player. After that, the SQL got expanded again, so that the events could trigger more than just a spellcast or an emote, but movement, phase changes, sounds, model changes, faction changes, etc. There's a list of 26 different actions now that can be triggered by any one of 24 different events. What's been happening most recently is Asura has implemented event conditions, so that now those triggering events can be conditional. For example, one of the events that can trigger an action is AI_EVENT_COMBAT_DAMAGE, which is called when the unit takes damage from any source during combat. With conditions, we can now make it so that it only triggers if that damage is from a specific spell school, or uses a specific spell effect (ie. Stun). This most recent functionality updating came from some preparatory work on Hellfire Peninsula, where there is a voidwalker mob that changes it's phase depending on the spell school it is first hit with. If you hit it with a fire spell first, it will become highly fire resistant and start throwing out fire spells. A common strategy was to hit it with a wand of another element first, then use your primary element. In any case, we realized we had no method of handling this dynamically, and so it was implemented by Asura over the course of a couple days. I've mentioned before that we have the flexibility to implement new functionality as necessary, and there's an example. When backported to Vanilla, this allows us to properly script the slimes that share this property.. I believe they are Evolving Ectoplasms, among with a bunch of other things. Conditions for power checking, aura checking, etc. will allow us to handle some of the more complex encounters like Obsidian Nullifiers without having to resort to hacky, unstable workarounds. When this is finished and tested, we'll have a few of our scripting volunteers give it a shot and get their feedback before we release the scripting API to the public and invite everyone who volunteered to contribute as they wish. We're also putting the finishing touches on a new Reputation/Faction system that's much cleaner and more efficient than the old one. Again, so that it better integrates with the scripting system for handling more complex quests and events. There has been a bunch going on but a lot of it is minutia not really worth rhyming off here, suffice to say all the work we've been doing most recently has been focused on getting things ready for scripting, and that's finally tapering off as well. While waiting for these changes to get finalized and pushed to the Beta realm, several of the testers have been assisting with math research, formula derivations, and the tedious drudgework of loot research and preparation for TBC. I'd like to acknowledge the efforts of Nogar in particular because he's been helping out with some of the more tedious work with TBC loot preparation. Alright, so enough technical stuff. A few pieces of errata to cover quickly: Our Beta realm is currently down for updates, once it is back online, we will be bringing in another pack of beta testers. They've already been selected and notified. We're pleased to welcome Chickengrease, Cornholi, Cragus, Cruzix, Ghostly, Indi, Nogar, Soulson, Soyoen, sQweegle, Roadblock, Wolfrig and Yavannie. I think that's everyone, if I left someone out, I apologize. We're also very happy to welcome Outstanding to the staff as a CM and go-between. He's been invaluable as a community member for pointing out things that needed addressing, and being a touchstone for predicting community reaction to different ideas and suggestions we've had. We're pleased to make his role as the server's conscience official. Okay, that's all for now. My next update will be Monday, April 3rd. 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. Coward.
  13. When I was just a raider, I'd make sure I had my consumables for the night, and then typically hang out near the front of Blackrock Mountain with a whole pack of friends and guildmates killing any horde who came in. We didn't need world buffs to progress so we didn't bother getting them, instead we just laughed at how much fun it was to kill the people who did and sabotage them. The most fun was catching <Bedlam> or <Blackdawn> trying to zone out of Blackrock Spire with the fire resist buff for Ragnaros or Vael and nuking them before they even got control of their characters. We probably set their progress back weeks just by doing that over and over until they gave up and logged out. We still did this even on nights when we weren't going to run MC or BWL because it was the most fun part of a PvP server. When I was raid leading.. I made sure I had my consumables for the night, then got my teeth grinding apparatus in position and started invites. Raid leading is an exercise in frustration when things are rough, but it is also unquestionably the most rewarding position when things go well.
  14. Human is best. I always root for the good guys. Yeah, not all humans are good guys, but the best guys are all humans. Dwarves and Tauren make up the second tier. Dwarves are like short humans, and Tauren are like the Horde version of an Alliance race. In both cases, generally amiable and honorable peoples. Orcs and Gnomes probably third tier. Don't particularly like or hate either one, as long as I don't have to hear the gnomes talking. Male gnome is right up there with troll for worst voicing in the game. Night elves and Undead fourth tier. Not a fan of the NE models at all. Dunno why, just seems like a goofy looking version of a human. Forsaken are alright looking but they are the bad guys in the WoW lore. No disputing that, they go so far as to attack and murder their own allies every chance they get. I don't like that. Trolls last. Hideous models, horrible voicing. The faux-Jamaican accent is just embarrassing. For expansion races, I'd probably put Worgen and Blood Elves (more for the aesthetic of their gear and cities/zones than their models, though they are better than the Night Elf models) into the second tier. Goblins and Draenei in the middle tier. Pandas in the 5th tier with Trolls because they're stupid. NPC races.. I dunno. Naga are pretty cool, I'd put them in the second tier as well just for the aesthetic. Gnolls, Murlocs, Quilboar.. probably all fourth tier. Troggs would go down with the Trolls and Pandaren, probably Harpies too. Can't think of anything else atm.
  15. My understanding is that Staff will have their names and obvious alternate spellings of their names reserved, this is to help prevent people from maliciously impersonating staff in an attempt to phish account information, or to besmirch the reputation of team members. Aside from that are no current plans to reserve any names.
  16. Main focus is classes, but a little bit of everything is being reported and addressed.
  17. I couldn't give a realistic estimate for open beta or release. It's also just a bad idea to make any estimate because it inevitably gets held against us, and we don't want the pressure. Suffice to say we are making good progress, haven't hit any major technical snags, and are still on track for a release this year.
  18. A lot of content changed, but the underlying mechanics are still the same in most cases. We've been building the emulator all along with an eye towards progression, so we can pretty easily convert back and forth between the two where changes are necessary.
  19. Yes and no. We don't intend to fully prepare TBC for launch before starting Vanilla, but we do want to keep it current with fixes we write and systems we prepare for Vanilla. The DBC loader, for example, is going to be used for every expansion, so it makes sense to port it forward into the TBC core immediately. For lack of a better way of describing it, it's just easier to add pieces of functionality into both Vanilla and TBC one at a time, rather than do a hundred pieces of Vanilla and then try to port all of them forward. We aren't going to bother much with TBC scripting for any content past Hellfire Peninsula until after the Vanilla realm launches, but we want to keep our TBC core functional, playable, and current with the latest fixes as we go along. It's also just a nice change of pace to work on something fresh every so often, and keeps us busy and productive when we're bored of working on Vanilla for a while, or in my case, when I'm stuck on a coding problem I lack the expertise to resolve, and Asura is too busy to deal with it immediately.
  20. Good evening, Okay, it's been a while since my last blog post. I think the last official update is a fairly decent summation of what's happened. I would like to say that none of that caused any delays, but that's obviously untrue. Still, we've been working and a lot of stuff is getting done. The most annoying delay came around the time we gave up on the LGN. I don't know if I'm supposed to be talking about this, but I think full disclosure is important. If you followed the drama at all, there was a lot leaking out of Elysium/LGN staff chats. There was some discussion amongst the admin staff about how to identify the source of the leak, and the solution decided upon was to create some documentation and distribute it to everyone who was in the general staff chat. Each document would be very slightly altered, in a unique way, so that if the document were leaked, it would be possible to trace it back to the originator. Unfortunately, it looks like the person responsible for producing them may have been, in true "The Departed" fashion, the leaker in the first place, and they may have embedded some malicious software into the document (a PDF file of supposed meeting minutes). There was at least reason to believe the files contained a RAT. Keeping with the doctrine of "better safe than sorry", everyone on the Crestfall staff who received the file wiped our computers and reinstalled as a precaution, which obviously is a good chunk of time lost. Security on our repository, personal machines, and critical assets was also altered and augmented once again, Crogge also included additional high-level security functions and 2FA in the places we didn't already have it. I believe it's safe to say that our code was untouched, otherwise it's likely that it would have been included in the source leak that occurred last week, and despite the annoyance, everyone learned a valuable lesson in internet security. We also had a problem with the host for our repository having two of the three hard drives in the storage RAID failing, and then trying to sell us insurance instead of fixing it. After a number of angry phone calls and several days of delay, we finally have a repository again. No data loss, we back everything up in multiple locations, but more wasted time. To prevent this going forward, Crogge implemented some hot-spare drives to the new RAID which take over automatically if one of the drives fails. Basically, the last three weeks have been a living hell. From the hardware issues, to reinstall issues, to the PR disasterpiece theatre that was the LGN. Being able to put all that behind us is a relief beyond my ability to express. Now, that all sounds rather grisly, but despite all that, we've still got a lot done. After my last update I was mostly clearing smaller bugs off the tracker, until things went completely crazy and I lost my access to the core. I do have it back now, but I just got it a couple days ago, so I've been pushing out database work, and started assembling loot tables and writing NPC script for Burning Crusade content, since that's all work that needs doing and I don't need core access for that. Soulson has been a huge help and has helped convert a ton of open-source creature AI into a format compatible with our AI engine. Saves a couple dozen hours of manual labor. We'll still have to go through the data and check everything over, but it's much faster than manually writing out hundreds of lines of SQL. We've also been collaborating on some pretty intense mathematical research. Soulson, Roadblock, sQweegle and either Cruzix or Cragus (sorry, I mix you guys up) were doing regressions and other mathematical techniques only people who stuck with math for longer than I did in college understand. They worked out the Blizzlike formulae for a number of things that until now had just been approximations or estimates. We'll be implementing those new formulae into the core code, and it should give us some great improvements in content accuracy. As I mentioned, I started poking away at loot for TBC. It's vastly simpler than Vanilla, which is nice. Still a lot of work, but it's nothing compared to Vanilla because the level range is so much lower. Instead of having like 10 templates just for raptor junk, no creature type has more than two junk templates. There's only one new tier of potion, one new tier of scroll, etc. etc. Quest items and tradeskill items will still be a bit of a bitch, but again, compared to Vanilla it's a dream. Hey, why all this talk about TBC? Why aren't you working on Vanilla? Again, it was largely just a time killer while I was waiting to get core access back, but getting HFP scripted and loot assigned gets us in a position where Legacy Crusade (Crogge's upcoming TBC-only realm, which will use the TBC version of the Benediction emulator. For more information, you can join the Legacy Crusade Discord and/or forums) can finally get into Alpha testing, and we can be more prepared for our own PTE experience. It's also nice to work on something different for a change, and after working exclusively with the Vanilla spell system for.. well, as long as I've been in emulation, it's interesting to script TBC content and get a feel for the differences. Also, Asura has been porting up fixes from the Vanilla version of Benediction to the TBC version, including a new DBC handler he wrote. It's important to merge those fixes up every so often so that the TBC branch doesn't fall too far behind - the longer you wait, the more difficult and complicated it is to merge. So, Asura has been working on all kinds of stuff. He fixed most of the reported bugs with Paladins and Warriors that are beyond my ability, found and fixed an issue with spellpower coefficients, identified an issue with creature AI that Drzej is fixing, wrote this fancy new DBC handler (he explained it to me, but I don't completely understand it, and so I forgot most of what he said. What I got out of it is that this new way is much faster and leaner than the old way). He's been working on refactoring the old Spell code to have a cleaner and more modern approach, taking advantages of changes in the programming language. The Spell System is a terrifying chunk of code because bloody everything is tied into it. It's not something where you can just change one thing, because five other things are always connected to it. It's largely old Ascent code, the biggest chunk remaining that hasn't already been wiped and re-written. I don't think we're going for a re-write at this point, it's just too much of an undertaking and would undermine a lot of the work we've done so far, so instead we're compromising on a thorough modernization of the existing code. Gorbulas and Daribon continue with database work, and Rodeg has picked away at a few things, though he is very busy IRL with school and so doesn't have much time atm. So yeah. It's been an interesting few weeks. Things are settling down, we're getting back into the swing of things and hammering out code every day. Within the next few days, we'll be roughly doubling our pool of beta testers, and really start pushing content out. We're finally getting close to the point where we can start giving reasonable timeframe estimates for task completion. Never thought I'd be able to say that, but there it is. I want to personally thank everyone who stuck with us through all the drama of the last month or so. I know it's been rough on you, it's certainly been rough on us. We're glad that things have quieted down and gotten back to a sense of normalcy. We look forward to sharing our progress with you. I would also like to reiterate that we don't want members of our community attacking other projects. While the LGN idea failed, even if we can't work together, we still believe that private servers and their communities attacking each other doesn't help either. That's all for now. My next update will be on Monday, March 20th. As always, feel free to leave questions or comments below. Talk to you soon, and thanks for your continued interest in Crestfall.
  21. 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.
  22. Yeah, this is unfortunately not actual Beta footage. 5/7 for effort though.
  23. Question and Answer I'll be answering questions that come up as a result of the post here. Q) Do I need to keep the Crestfall Discord active? A) Public channels will be muted and/or removed, so there won't be any general conversation there. However, we will keep the server running for future voice Q&A events or in order to contact volunteers who provided no other contact venue. For volunteer scripters, you can idle in the existing Discord if you don't mind that, but you can also PM me on Discord (or here) and I can add you to my personal contact list, or if you prefer, you can provide me with your forum account or email address if those are your preferred contact methods. Q) What level of transparency do you intend to have among staff members? A) We are going to have to investigate potential new staff members' past history with regards to private servers. I don't want to explain in detail here exactly how we will go about that since that would make it easier for someone dishonest to conceal any history of wrongdoing. We will not require them, however, to give us their personal information (ie. full name, location, etc.). In any case, new members would obviously join with limited access and responsibilities, and work under the direct supervision of the relevant department lead. The "old guard" of Crestfall's staff mostly know each other by name, but we have been together a long time and have a well-established trust and friendship between us. New members obviously won't have that kind of camaraderie, though we certainly hope to build friendships and a mutual respect with everyone who joins the team. Q) Will battlegrounds be linked if you eventually open more than one server? A) It's something that is technically possible but a great deal of work. We'll avoid it if we can, but if queue times or queue dodging are judged to be a serious enough problem, we can work on the implementation of cross-realm battlegrounds. I won't get into the technical details of this, but suffice to say it is quite complex. Some of the work for it has already been done, so we know it is possible, and we know how to do it, it's just low priority at the moment. Q) Assuming there only is one failing PVP and one failing PVE realm, which way would the merger go if the cash flow isn't great enough? A) We will consult with the community before any mergers to get some input on how they would prefer things to be handled. In other words, it will depend on the situation at the time, and isn't really possible to answer now. I would expect that the smaller realm being merged into the larger realm would be the most likely outcome, but again, it depends. One thing, we are investigating the feasibility of making it so that when you create a character, that name is then reserved across all realms. There's a bit of a technical challenge to this, but it would remove the worry about naming priority and who is forced to change names in the event of a conflict caused by a merger. No promises on this one, it's just an idea at this point, but it seemed relevant so I thought I would share it. Q) Will it be possible to transfer characters from Elysium to Crestfall? A) No. We no longer have any affiliation with the Elysium project. Q) Will Maraudon be available at launch? A) This isn't 100% guaranteed, but the idea is yes, we would like it to be available at launch. It makes more sense to have it available for levelling. Q) Will it be possible to transfer characters to Burning Crusade below level 60? A) Good question. We haven't really talked about this. I would think that you could flag a character of any level for transfer, it's certainly closer to Blizzlike. We'll discuss this internally and see if there are any problems that this creates, but I can't think of anything major offhand. Forcing players to level 1-58 on the Vanilla realms would certainly keep them more populated, but it causes issues with bank alts etc. that I would rather avoid. We'll address this with more finality later. Q) Where is the website? A) Our initial plan was to have a Wordpress site linking to the forums. Audio created a gorgeous one, but due to the amount of attacks going on we sidelined it due to some inherent weaknesses in that format. Our web team is slowly putting together a few things for some new web content. Soon(tm).
  24. Good evening, I apologize for the lateness of the hour on this update. Was working on some other stuff and got sidetracked. Alright, so I suppose by now everyone is aware that it's been an eventful past two weeks. On the development front, we've accomplished a surprising amount despite all the excitement, and that's mainly due to Asura's incredible work ethic. I've been writing a crazy amount on here over the last few days, so if you want to get some insight into all that, feel free to check out my post history and scan the last week or so. I'm not going to summarize everything here because I actually want to get back to what I was doing, more on that in a bit when I summarize my stuff. Suffice to say I'm happy with the new developments, I'm glad that things are settling down a bit and I can get back to work. I wish I had gotten more done but it's been a whirlwind of preparatory work, writing our announcement, frantic fire-fighting of the initial response, hashing out the FAQ with the Elysium staff, and then following up with individuals and answering questions on my own. It doesn't sound like much, but please keep in mind that I work full time and typically only have a couple hours a night to work on CF, so if I'm spending two hours answering messages or replying to questions, that's more or less my free time for the day gone. Anyways, that's largely behind me now that the furor has died down, so it's back into action. At present I'm working on a fix for swing timers not resetting correctly after spellcasts. I wrote a software fix for this, but it's quite hacky and messy. Blizzard was really weird about how they handled this, at least as far as I can tell. Some spells reset the swing timer for autoattacks when you cast them, some do not. There are a few factors that influence this, but it can be summarized somewhat simply.. If a spell has a cast time, or if it is instant but costs mana (ie. Fire Blast), it resets the autoattack swing timer when the cast finishes. Those are the general rules, but there are also a whole bunch of exceptions. Several Paladin spells ignore this rule, including Judgement, Exorcism, Holy Wrath, and (post-1.6) Consecration (thanks @maronics). Stormstrike for Shamans doesn't reset the timer, and neither does a Druid's Insect Swarm. As well, any kind of Dispel is excepted, Cleanse, Remove Curse, Dispel Magic, etc. So, my first shot at this was a software check, an inline boolean that would compare the spell being cast using a nasty check for all these things. It was really, really ugly, but it worked. I recorded a video clip of it, but I was talking to Rodeg in voice at the time and forgot to mute that so it's got him complaining about Discord lag, loudly, over top of it (it would also be showcasing a bug with Block that I haven't got around to fixing yet but will this week). I'll remake another clip once it's done and live on the Beta realm if I remember. Anyways, Asura saw it, said I was a bad coder and that I should do it a different way. As I mentioned in a previous update, Blizzard typically assigned attributes to spells that could be used to easily classify their behavior. Spell that ignore Line of Sight have the "Ignore Line of Sight" attribute.. this way when you want to write the core-side handling, you can just write a one line check in there, "If the spell has the Ignore Line of Sight attribute, then skip the Line of Sight check". That's maybe a bit of a simplification, but you get the idea. I don't want to get mega technical here. Problem is, there is no attribute for "Resets the Swing Timer" to make my job here easy. Fortunately, we have a fix for that. A little while ago Asura implemented support for custom spell attributes, so what I'm doing is creating a handler instead which will just check for the presence of a brand new custom attribute. If it's there, it resets the timer. The tricky part then is tacking that flag onto every spell that it applies to. I whipped up a filter that reproduces the code I was using before, plus some additional refinements to remove spells that can't be cast in combat anyways and things of that nature, and @Buki did me the courtesy of writing that code into a filter and making my job very easy. I'm in the process of setting up the query to add the flag to all the appropriate spells now. That done, the spell/autoattack interactions should be working beautifully. We've pushed a lot of my previous fixes to the Beta realm now, so those are getting a thorough once-over from the testers and we'll see how they hold up under scrutiny. I've also got a small handful more to push as well. I finally have a few days off work, and with the forum stuff largely under control, I'll be hitting the bug tracker again and clearing up some more issues. Speaking of clearing up issues, Asura has done a ton of work. The stability issues are almost entirely done with. My understanding is that in an earlier iteration of the item code, he'd tried to make use of some unused space, but as it turned out this just caused some subtle issues that don't get caught under normal testing circumstances. He undertook a fairly large overhaul of the item system and fixed a number of crashing and character saving issues all in one swoop. There were some fixes to gameobjects casting spells, the quest system, and aura stacking (the new system for this had a few bugs that the Beta testers found, we're pressing them out now).. Quite a bit considering how much OTHER stuff has been going on. There is still something funny with AI event-triggered spellcasting. Spells like Cleave or what have you, that just cast normally when the target is in range and the cooldown is up - they work fine. Spells like Enrage or Stealth, that cast when specific conditions are met (ie. a set health percentage, or when spawning, or leaving combat) don't cast. They used to, which leads me to believe that they probably broke due to changes made when we implemented the spell delay system. That's proved to be a bit more of a thorn than expected. I traced this issue back as best I could, but at this point it's beyond my capacity, so I'm leaving that one for Asura. Either it's not pulling targeting information from the spell proto correctly, or it's getting dumped into the spell queue and failing some kind of check before actually applying it's effects. After struggling with it for a few hours, I'm sure Asura will be delighted to embarrass me by fixing it in ten minutes and rubbing it in my face. As far as I know, that's the biggest problem left. There are plenty of little problems, don't get be wrong, but comparatively speaking, little problems are fun problems. We're also happy to welcome Drzej to the development team. He's a colleague of Asura and another professional software engineer. He doesn't have a huge background in WoW emulation, but he's an very skilled and experienced programmer. His insight into the efficiency and structure of the emulator is much appreciated. He's jumping right in, having already identified and repaired some issues with the character stat code, and at last check from me, is working on a bug with Resurrection Sickness. The benefit to adding a developer like him is fresh perspective, especially when it comes not just to "is this how it worked in Vanilla?", a common question that I (a Vanilla junkie, but not an experienced programmer) ask when I'm looking at the core, but "is this code up to snuff, and does it do what we want it to do, and ONLY what we want it to do?". In any case, we're happy to have him on the team. Alright, I've run on far longer than I intended, so I'm going to cap this off here. In general, things are proceeding as planned, we're making good progress in knocking off the remaining major issues before drilling down into the nitty gritty of spellfixes. After a few days of near panic, we're settling back into a more enjoyable routine of coding and testing. We look forward to being able to show off more very soon. That's all for now, my next update will be on Monday, February 27th. As always, feel free to leave comments of ask questions below. Talk to you soon, and thanks for your continued interest in Crestfall.