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

    731
  • Joined

  • Last visited

Everything posted by Darkrasp

  1. 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.
  2. 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.
  3. Main focus is classes, but a little bit of everything is being reported and addressed.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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/
  10. Yeah, this is unfortunately not actual Beta footage. 5/7 for effort though.
  11. 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).
  12. 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.
  13. I am in the process of being briefed on, and putting together the information we have, in order to prepare an official statement & explanation of our decisions and next steps. Unfortunately this came at a terrible time because of my IRL work shift, I'm out of the house 14+ hours a day until Friday, and when I'm home the rest of the team is asleep, but we'll have something to release and clear the air entirely in the next 24-72 hours. I apologize for the delay, but we want to make sure we get all the facts out clearly and correctly, and it will be very difficult for me to communicate with the team for the next couple days. Our initial intention is to revert to our pre-LGN setup and plans, continuing the development of Crestfall as a PTE project on our own, though we do need to take a short time to consider our position and any potential changes that might need to be made. We thank you for your patience. Edit: Since this has some external links now, I'll clarify this: we have terminated all partnership and association with the Elysium project due to strong evidence of corruption in high-ranking members of their staff. The extent of the problems there became clear as we engaged more closely with them as partners, and as things were brought forward by the community, therefore we could not in good conscience remain in any form of partnership with them. It is worth mentioning that no members of the Elysium team, at any time, had access to any of the Crestfall source code, database, or networking assets - they are safe, and development work on the Benediction emulator is continuing. We are still in the process of collecting and verifying information, but we will release a document with our future plans as soon as possible.
  14. Afaik we don't have any of those issues. Mobs with PBAOE are set to cast them only if there is a target within range. It doesn't necessarily have to be the primary target though, any valid target will do (this is on purpose, we can run it either way but this makes the mobs a little bit nastier if you try to kite them and they're still chewing up your friends). Spellcaster-type mobs prefer to stay at range and obviously cannot autoattack the player from outside melee range. If they are silenced or run out of mana, they will attempt to engage their target in melee combat. Also, if you enter melee range, they will in most cases stop attempting to cast spells with a cast time to avoid spell pushback, and instead switch to melee attacks while still using available instant-cast spells. A mob will not attempt to cast a spell while another spell is being cast. It will always finish it's current cast before starting a new one. Scripted conditions that force spellcasts such as Enrage will interrupt the spell in progress if necessary though - there really isn't any other option because the spell is a forced, triggered event that bypasses normal spellcasting checks. It might be possible to implement an NPC spell queue, though considering how few mobs have both an enrage and the ability to cast ranged spells with a significant cast time, I'm not sure it would be worth the hassle. There are other ways to work around that using the existing AI in the handful of cases where it would make a difference, using clever manipulation of the existing scripting engine instead of forcing the spellcast with a standard event trigger. I figure we'll deal with these as necessary. It's a relatively simple fix for the few cases where it applies.
  15. With respect to the last few questions, we already have a bugtracker page, but it is limited to Beta testers only at this point. We thought about the dev progress page and decided that core work isn't really great for showing dev progress. Reason being, it just doesn't translate well.. Something that you'd think would be very simple can take a ton of time because it can be tied into a number of things. A tiny change to an important piece of code can have far-reaching consequences across the core, as we have seen from the spell delay implementation affecting a TON of things we didn't necessarily expect it to. It's not that they are unfixable, in the case of the spell delay, Asura already found and fixed most of the issues, it's just that what we thought was 100% done at the time was actually only 60% done, and we had no idea until the testers got at it. At least, I had no idea. Asura knows a lot more than I do, he may have expected it and just not told me. Instead what I think we'll do is post something publicly once we get to the point of pure content creation. That's also when we intend to push out a lot more videos and things. From a development perspective, underlying core mechanics are the most important parts, but it isn't much to show off. All you'd be seeing is a video of something doing exactly what you'd expect it to on any server. A mob gets to half health and casts Enrage. Big whoop. It's important to us, because we handle that entirely differently than anyone ever did before. So, for us, to see that system working is huge, but to a player it's just meh. Players care more about intricately scripted content, and we just aren't working on that much at the moment. When we can showcase that stuff, that's when I would expect to see the dev progress page and more video content. As far as the website, the version we had was a Wordpress page that, while gorgeous, presented some security concerns. It was sidetracked by our recent security update and is on the back burner once again. Our web team is working on something, I think, but they talk gibberish in their channel so I tend to stay out of there. I'll ask them about it.
  16. This is covered in the FAQ.
  17. It was decided not to make any response until the FAQ was ready to prevent any further misinformation. If you have further concerns or questions after you have read the FAQ, please ask them then.
  18. Good day, Time for another progress update. It's been one of those hurry-up-and-wait weeks, so while a lot has gotten done, there has also been a lot of downtime to circumstances beyond my control. More on this later. First thing, the major stability issues from the Script branch merge I was talking about have been resolved, and more major things have taken place. This probably sounds like ancient history now, but most people would have heard about the security breach at Elysium that occurred a couple weeks ago. This event had us checking into our own security situation and we found a number of potential vulnerabilities. The majority of last week and the first half of this week was spent on increasing the security measures around our core, database, and even the personal computers we use to work on the core code. I'd love to go into more detail about this, but even a cursory description of the changes would be hints for malicious parties attempting to hack us, so the safest thing is just to keep away from specifics. Suffice to say the team spent a tremendous amount of time, effort, and we all spent some money in order to improve our existing security and implement a bunch of additional security measures. For about a week I had no access to the core entirely while my personal system was secured, so that's why I didn't get as much done as I'd like. Once those changes were done and the new code merged in, several new bugs appeared to do with character saving. Asura already identified the problem and this is high on our priority list to fix. A couple more popped up that are related to the spell delay system, I fixed one already that had to do with rogue combo points being removed prior to the effect taking place on a finisher, there's another to do with totems that still needs to be addressed as it causes a crash. It's on my list. Those are the only major bugs that came up with the security merge, so that's good. The testers are picking away at rogue and shaman testing, but it's made difficult due to those stability bugs, which is why they're high on the list of priorities. Asura is now working on some cross-platform compatibility. We hadn't run the code through a unix compiler in quite some time, so he took the time to get that going and it pointed out a number of warnings and errors that the VS compiler bypassed, a few of which were serious enough to potentially cause a crash. That code has largely been cleaned up and he's undertaking an overhaul of the networking code that will make it far more efficient, as well as finish off the unix compile so that we can run the realm on a unix server. Once that's done I think he'll finally actually be working off the same bug tracker I am, which is a relief because he's much faster at these kinds of things than I am. When the stability issues from these major merges are ironed out I think we'll also finally get those quest scripters rolling. Yeah, I know I've said that a million times but this time I mean it. It's probably worth a quick mention here.. there's a misconception that we have zero scripting done. A vanilla emulator needs about 7000 scripts in order to be complete. That's about 6300 NPC scripts, 400 quest scripts, and we'll say 300 event scripts. Much of that is handled in the database, and a lot is handled simply by the AI system in the core. I personally wrote scripts for about 6000 npcs. Everything in Kalimdor/EK, and all instance trash, and first drafts of all the instance bosses up to and including Blackwing Lair, with a handful of exceptions. The only NPCs that haven't been touched at all are in ZG, AQ20, AQ40 and Naxxramas (I've got pretty exhaustive research done for them, but haven't written any code for them as yet). A good chunk of the quest scripts involve an NPC simply doing an emote or doing a spellcast animation when you turn in the quest.. those are also handled in the database and are already done. What we're ending up with is needing to script the more involved quests where there are escorts, or you need to defend a point against waves of spawning enemies. There are a couple hundred total we'll need to look at, and our list of scripting volunteers has grown to more than twenty, so even if only half of them show up, there shouldn't be any major issue splitting the load into manageable chunks. Event scripts are triggered events like the fountain in Blackfathom Deeps, or the staircase in Zul'Farrak. I'm not sure how many of them there actually are, I'm probably being generous, but better safe than sorry, I suppose. There are certainly a handful in each of the later dungeons, though not many in the overworld (most are actually connected to quests). Point is, we're not super concerned about scripting, though the sooner we get people actively working on it, the happier I'll be. Anyways, now that my core access is restored, I'm back to making generic fixes again. This week I pushed out a fix for a better randomized gold drop generator, the proper amount of mana you get when you reclaim your corpse, proper implementation of the dodge and crit formulas (we still had TBC data in there.. oops), aggro ranges, and a handful more database fixes. I don't remember what all for.. I think a couple loot bugs and a scale fix for a boar that was too big, along with cleaning up some double spawns. Currently I'm working on the mechanic where NPCs move slower when they're at very low life. It's a bit of a tricky one because it doesn't apply to certain mobs but there's no real simple filter you can apply. What I mean by that is it's not just "everything except mechanicals" or "all non-elites", it's very mix-and-match and appears to apply to everything except bosses (including 5 man bosses) and raid mobs, unfortunately there is no general case for selecting those that I can think of. We can create a custom flag and add it to the NPCs who slow down (or don't) and check for that, which is probably the tidiest solution. I did something similar to fix mobs with bonus aggro range beyond the norm for their level (ie. "Starving" mobs, etc.). That'll take some research and a bit of manual labor, but it's certainly possible. Anyways, it's working at the moment on my local build, and it looks pretty good. Only problem is a bit of a janky movement visual at the highest value of slowdown because they're still using the running animation instead of switching to the walking animation. I'll be figuring that one out and fixing it shortly, along with implementing that flag and either doing the research for the affected mobs, or coordinating some beta testers to help me out with it (currently I just set it to slow down all non-elites so I could test it). I gave up on the graveyard fix. I know what's wrong, and I know how to fix it, but there's something with the MapManager that isn't doing what it's supposed to do, and I don't understand enough of how it works to get around that. I asked Asura about it, and he pretty much just told me to fix something easier instead, and he or Rodeg would take care of it. No complaints from me, I took it as far as I could and learned quite a bit along the way. I know that my updates here sound kinda like I have no idea what I'm doing. I recall a specific comment saying that they sounded like the blogs of someone who is learning to program. I found that a little funny because honestly that's exactly what they are. I took some basic programming courses in college for C, that's more than ten years ago now, and when I got into emulation all I did was research work for years. When I finally got involved in development, I was just working off templates doing simple scripting and database work for Crestfall and it's earlier iterations. Everything I did was very monkey-see, monkey-do. I followed directions but didn't really understand what was happening underneath it.. I mean, I understood a little bit, but no more than your average driver understands how a car works. I know there's pistons and gears, there's a motor and a fuel-air mix that gets smashed and the explosion makes the car go somehow. I get the general idea, but I'm no mechanic. Likewise with code. I didn't know the first thing about object oriented programming two months ago; I learned how to properly use the tools for our code repository literally three days ago. While it is in my Canadian nature to be self-effacing, I would like to point out that I'm learning a tremendous amount by expanding my responsibility here and taking on new tasks. In a matter of about two years, I went from doing only research, to scripting and database work (which really took a very short time to learn, although I spent nearly two years doing only this), to core development, without any IT experience whatsoever. If you're a player and you're interested in emulation, programming, or even just stretching your brain muscle a little and learning something new, I encourage you not to underestimate yourself. Learning about Lua, or SQL, or C++ will put you in good shape to contribute to many projects, and it doesn't take long. Heck, we're always looking for interested people to add to our scripting roster. My primary motivation for being in this project isn't to make money, or "be the biggest server", or anything like that. I do this because it's a challenge, and because I learn new things all the time. If my fumbling efforts end up leaving me any kind of legacy in this community, I'd rather it be that I encouraged a whole lot of people to get involved in recreational software development than for any specific fix or research or anything else I manage to produce. Alright, enough rambling for now. My next update will be on Monday, February 13th. As always, feel free to ask questions or leave comments below. Talk to you soon, and thanks for your continued interest in Crestfall. p.s. Since it's topical, yes, we did see the leaked Netherwing chat. While there was a lot said in there about us, I think it's fair to say we learned our lesson earlier and don't wish to take anything personal, or make anything personal. We've talked to our own Beta testers and made it very clear that disrespectful behavior towards staff at other projects, even out of public chat, is unwelcome and will result in removal from the team. I believe it's fine to criticize code, but not the coder. There's a difference between a professional criticism and a personal attack, and while I know we have said some inconsiderate things in the past, we do strive to stay on the courteous side of that line.
  19. Damn, yeah. You're on the list.
  20. Particularly effective spots like those mentioned have been tweaked slightly, but not broken completely. Those should still all drop the same items, though with slightly less frequency. Players do have to be able to farm gold somehow.
  21. Thanks, yeah. We do have a copy of this.
  22. Good morning/afternoon, Well, I woke up to a bit of a firestorm this morning, and things are presently flying completely off the rails. Obviously the dust has not yet begun to settle, and nobody has the full story yet. I'm not going to pretend that I have more information than anyone else because I do not, but the recent post from Nostalrius has called for Elysium to stop using their core and character database, and there is speculation that Elysium appears to be willing to comply with this. I stress, again, that this is purely speculation at this point. The truth of the matter will become apparent in good time. I just want to make it clear to the community that, like last time, our intentions for Crestfall remain unchanged. We didn't rush a buggy launch in order to capitalize on the initial shutdown of Nostalrius, and we won't rush a buggy launch in order to capitalize on any other circumstance either. Our Closed Beta is progressing nicely and at a manageable rate for us. We are still focused on quality above all else. Our intention is still to launch our server when it is ready, and to progress through the expansions as far as the community is interested in going. We aren't doing this for money, so compromising in order to absorb additional players isn't in our plan. We appreciate the patience and continued interest of our fantastic community while we continue development of Crestfall. I know it's been a long wait, and the closer we get to releasing, the longer it feels. Believe me, it's the same for us on the team. We certainly hope that once we launch you will all think the wait has been worth it, as much as we believe the effort we put into development will weigh out against the end result. My next progress update will still continue as planned on Monday the 16th. Talk to you soon.
  23. Our plans for this currently extend no further than fixing the bug that allows players on private servers to reset an instance from inside the instance, and to make the Gordok Tribute chest unobtainable unless Guard Slip'kik and Captain Kromcrush are dealt with in some way - either by frost trap, ogre suit, or killing them in combat. Alternatively, we can set a script condition such that unless Slip'kik is frozen, he is considered "dead", and unless Kromcrush preforms his Ogre Suit routine, he is also considered "dead" for the purposes of generating Tribute loot. There is clearly expressed intention from Blizzard on how the Tribute was supposed to work: you got the option of killing Mol'dar and Fengus, or avoiding them by pathing carefully around them. Slip'kik and Kromcrush were positioned such that they were obviously only intended to be either killed, or bypassed through usage of the special scripted mechanics provided. Failure to do so should result in forfeiture of the associated loot. Though some things may of course be tweaked, other than the aforementioned cases, there are no plans to drastically alter any other loot tables or mechanics.
  24. We have a plan to begin advertising, but we want to get further along in development before we do. Right now we are very content to keep our project on the down-low. We don't want to build too much hype and then keep people waiting around so long that they lose interest. Have a little patience, work is being done every day, and once we reach a certain point, we'll start churning out promotional materials. No sense in doing that before we're ready. Thanks for the post, Outstanding.