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

    808
  • Joined

  • Last visited

Everything posted by Darkrasp

  1. Hey, it's me. Since Elicas is no longer here, I'm going to take over this time. I'm also going to shamelessly steal most of the header bit from his previous Q&A. All questions for this Q&A were taken from replies to the last Q&A post. As always, we'd like to remind you all that questions regarding a release date will be ignored and that Asura currently remains committed to a 2017 release. You will be the first ones to know about the release date as we approach it. There is currently no further news regarding the Open Beta release we are working towards. Please note that I'm going to suspend writing the Q&A posts until we get a new CM willing to take on the task. This takes a couple hours to write up and I'd rather spend that time on actual development. You can still ask questions, but I'm not going to set a timeline on when they will be answered right now. Without further ado, away we go: Does the recent Gummy server drama have any effect on Crestfall's plans? No. Does Crestfall intend to make a list of all the retail WoW changes you are implementing? No, but it's not a bad idea. I suppose it would probably be possible to draw something up. Might not be totally comprehensive but it wouldn't be a bad call to let people know of any custom changes we make and our reasoning behind them all in one place. It might be more of a personal question, but what do you guys think of the course that retail WoW has taken in general, and the Legion expansion in particular? Are there any good ideas or features somewhere along the way you'd be really excited to (re-)implement on Crestfall? I can't say I speak for the team on this one, but I'll answer from my own perspective. I think retail WoW has become an entirely different game, by an entirely different team, for an entirely different audience. The current team has made no bones about how their intention was to turn WoW into a fantasy-themed Candy Crush game. Anyone can play, microtransactions are omnipresent, and the purpose isn't to make a good game, but to squeeze as much money from it as possible. To that end they introduced "features" which made it easier and easier for players to play alone, to the point that you can now run full raids without having a single person on your friends list, or even being in a guild. They changed the itemization system from a dynamic and involved process where people theorycrafted, and eventually decided on which items were optimal for which specs, at what point crit is worth more than hit, or hit is worth more than spell damage, or how much itemization you need for stamina, etc., to one where "the upgrade to Sword +500 is Sword +501". All the itemization decisions have been removed from the game, character building is virtually automated and no thought needs to go into it. If I remember right, this came from the fact that so many items were being discarded because they were only good for a certain class or spec.. As legacy players, many of us are familiar with farming a raid and after a few weeks, melting a ton of gear just because nobody wants or needs it. In the new WoW, items rarely go to waste because they can be used by anyone, but at the same time, you lose the excitement of finally getting that drop you've been waiting for. The most fun thing for me about WoW was playing with friends. I was in four or five guilds over my time playing retail, and even though I quit in 2009, there are still a half dozen people I keep in touch with regularly. Nobody ever called each other by their character's names. Everyone was on a first name basis. Our guild ran two Karazhan runs in TBC, I was raid leading the "Red" team. The tanks were Greg and Ryan. My healers were Charles, James and Joey. The DPS was Rob, Trey, Joe, Christina and Me. Our alternates were Jenn and Tony. I still talk to most of them. The environment on a retail Vanilla/TBC server was radically different. Retail had population caps around 3000. You didn't see much of the other faction, you recognized guild tags of the top guilds and you'd know a few people who were top PVPers, or maybe specific rivals, but not many. Mostly you just saw your own faction. So cut that population in half, down to 1500. Some of those players would be in different time zones, or only played during the day. We did have a couple overseas guilds who played while I was asleep, or in school. So cut that population in half again, down to about 750. Now, you probably went to a school with that many kids. You weren't friends with all of them, but after a couple years you certainly recognize most of them. In WoW, that meant knowing who the good guilds were, who the bad guilds were, who the ninjas were, who you had to call to get a Lionheart Helm crafted, etc. There was a legit community, and the experience of getting to know all those people, joining a guild, doing dungeons and group quests and raids with the same people week after week built actual, lasting friendships. I enjoyed that aspect of the game far more than I enjoyed the game itself. For that reason, I don't particularly like the way WoW has gone. It's dumbed-down and antisocial where it used to be complex and communal. There's nothing about the later expansions that I would want to bring back into Vanilla. What would you do if, even after retuning, guilds find the content easy after launch? Or vice versa, how quickly would you nerf content if it was not being cleared? We don't intend to spend a lot of time on re-tuning content over and over after launch. If we undershoot with some bosses, then we undershoot. We don't want to go into funserver territory by making huge changes. Encounters that are clearly overtuned beyond any realistic means of defeating them would likely be hotfixed, though we think this is unlikely to occur. Making bosses into uber-challenge-mode encounters or significantly changing the fights is something we might try, but that would be done as a side-project unconnected to the main servers. Kind of like a special, temporary, tournament realm. Will add-ons like bigwigs and other raid add-ons become obsolete due to significant changes in raid encounters? They'll still be useful, but we do intend to modify ability timers, and make them more random, so they won't be as accurate. Will there be a /world channel or will chat be kept to specific zone or linked through cities? We aren't going to create or maintain a /world channel. If players decide to create a custom channel with this function, it will be up to them to moderate it - we aren't going to be the chat police. Gold selling/account selling aside, what happens in a private channel is private. If you don't like what you see in a private channel, leave it. How will you address AH botting and add-ons like auctioneer. I don't want to go into any detail on our proposed techniques because that would make it easier for botters to attempt coding work-arounds. More sophisticated anti-cheat leads to more sophisticated bots. That's just a fact. We do have a few ideas, but there's no point in giving the cheaters a heads up on how we plan to slow them down. Do you have any plans to police monopolizing like cartels/mafia? A lower population cap and randomizing of spawn locations for certain controllable resources should reduce the effectiveness of cartels. To an extent, this is metagame behavior and beyond our control, but there are some measures we can take that make domination of a resource significantly more difficult. These are likely to be dealt with post-launch, should the need arise. Any official information on how procs with weapons/totems/trinkets will work together and their official proc rates that you can share? I did a lot of exhaustive research, and I need once again to recognize the assistance of the community in doing so, that got a lot of proc rates out of old comments from the web. After that, I derived an itemization formula that let me basically break down itemization points and solve them for weapon DPS. Uhh.. it's complicated, but basically you can figure out how much DPS a proc should be "worth" on an item if it doesn't have a documented proc rate. If you know how much damage it does, and you know how much DPS it should be doing, you can easily determine how often it should proc based on the speed of that weapon. A weapon with 2.0 speed hits 30 times a minute. If it needs to proc 10 times per minute, then it's proc rate is going to be 33%. Mathemagical. I won't share the full list of proc rates simply because it was a lot of work and I don't want to give it away for free to every other realm. Armor set procs tend towards a flat 4 or 5%. Totems I think are around 20%, but don't quote me on that. I'm pretty sure they're fine anyways. On the PvE realm will PvP be flagged on during world boss encounters? We are considering this, and some more radical changes such as making the areas around those bosses into FFA-PVP zones, though it's unlikely that we'll actually make any custom changes of that nature. For now it's likely that they will stay Blizzlike. Will node spawns end up clustered around less trafficked areas, or will they be evenly spread around the map at all times? Our pooling system will work by having a group of nodes in an area, and then activating some number of those nodes at random, so for example, in a cave there might be 10 spawn locations for a Copper Vein, of which no more than 6 at a time can be active. Whenever one is harvested, a node is selected at random from the empty positions and queued up to spawn after the appropriate delay for that resource type. Furthermore, when a node spawns, it doesn't always spawn in the exact same location. The initial spawn point is a fixed set of coordinates, but the item is generated using the random movement generator, so basically we just set the initial possible location, and then the node can generate anywhere within say 15 yards of that point. Because it uses the pathfinding generator, we know that it spawn in a pathable location, so they shouldn't be spawning inside walls or under floors. It does mean that sometimes a node will appear in a slightly unblizzlike location, maybe out in the middle of a cave floor instead of along the walls, but we consider this worth the benefit of breaking glider bots that use a path of pre-set coordinates to harvest resources. This system is still in development, and will require a lot of work to build the database of shared pools. For that reason we anticipate this being implemented and worked on late in the beta process, and will likely require refining even after launch. We may also delay implementation until post-launch, or change the implementation, should it prove too time-consuming or complicated. Will all the RP-Stuff be well scripted? As much as possible, yes. A lot of it is already done. I'm sure there are things we have missed, but the world is pretty lively already and we will continue to work on it when we find missing events. Will custom channels be disabled or have limitations placed on them? We're not going to disable them, though we are considering putting a limit on how many people can join them. I don't know what that limit would be. Fifty people? Two hundred people? No idea. Very little discussion has been had on this topic and no final decisions have been reached. Custom chat channels, in our opinion, are a use-at-own-risk platform. We won't be moderating or monitoring them except for gold/account sellers. If you don't like what's on the radio, you don't have to listen to it - you can change the station, or turn it off. Same with private chat channels. Since it is possible to use an alt account in major cities, will that account be tied to the main account? And in fact, will there be separate game accounts under the "forum account"? We don't have any of this functionality at the moment. It's something we can investigate. We can already determine if accounts are being accessed from the same IP address, but we haven't tied this into the forums or any type of account management page. Where will the proxies be and how much will they affect my ping? We have not decided on final locations for the proxy servers yet. They cost money to set up and more money to maintain, so we will not activate them until right before launch. The effect they will have on your ping is going to vary greatly depending on where you are. We will provide more information on this prior to launch. Does Crestfall have the movement lag or "stutter" that affects a lot of other private servers? No. Alright that's all the questions for this round. As I mentioned, you can continue to ask questions, but we won't have another official Q&A post until we get a new CM willing to take up the job. We'll announce when that happens. Thanks again for your continued interest in Crestfall.
  2. Good evening, Another two weeks passed. We're still plugging away but not that much has been going on. Asura has been busy with IRL stuff and hasn't had much time for code review or getting done a lot of the stuff we wanted to get done. We're currently looking at ways to address that and speed things back up, when we get something figured out we'll make an announcement, whether it's moving around some people, bringing on new people, or something more.. radical. In any case, when we know, you'll know. Also, it's partly my fault; I've been lazy and spent a bunch of time playing Path of Exile with a buddy from work. Got bored of that pretty quick though. After you finish A10 the game is literally just an endless treadmill with no purpose whatsoever. Waste of a week, imo. I regret it now. So I'm still waiting on patches to be approved and for a core push. In the meantime, we're still getting some small things done. Nogar has been dilligently scripting away and is presently working on the Undead starter areas. He asked me for some help the other day with an interesting problem for the quest The Dormant Shade. There aren't a whole lot of quests like this in the game.. basically it's something we refer to as a subquest.. which is a quest only available while you're another quest. In this one, the big quest is to go get some candles from a box, use the candle on a table which then summons an NPC and kill that NPC to complete the quest. Blizz were a bit funky with it though and made using the candle on the table into it's own subquest. It's one of those quests that you don't have to accept, you just have the candle, walk up to it, and hit Complete. A script condition summons the NPC when that quest is completed. The trouble is with those quests that you don't have to Accept. Hmm.. another example is like, turning in Marks of Honor from battlegrounds after the first one. You just walk up to the NPC with the stuff in your inventory, talk to them, and hit "Complete" in the bottom of the dialog box. Little bit of background on that system, the dialog box is a constructed packet sent to the client by the server. The packet contains a bunch of information, and there are three or four different ones. One is the "Quest Details", which is basically the mob saying what they want, (displays the Details text) and giving you the option to "Accept" or "Cancel". If you accept, then you accept the quest and the dialog box closes. The second one is the "Request Items" version, which is where it shows the Progress text and checks to see if the player has the required items/conditions for that quest. If they do, it gives them the option to "Continue" (which takes those items, and moves along to the Offer Reward packet), or cancel. If they don't meet the completion requirements, it greys out the Continue option. The third one is the "Offer Reward" version, which shows the completion text and offers the reward for the quest. The player options are "Complete" or Cancel. Completing marks the quest as done and gives the player whatever reward is called for. So the trouble is with quests that go straight to the Offer Reward section, but also require items. The Offer Reward page doesn't actually check to see if the player has anything, or remove the items - that's done by the Request Items dialog, so we can't go straight to that. The Request Items dialog doesn't work either because hitting "Continue" in this case doesn't have anywhere to go to. It bugs out because it's looking for quest details that don't exist, since the player never actually accepted the quest in the first place. I spent a few hours on this one and the best conclusion I can come to is that either there is some alternate version or way of building of one of these packets that just isn't documented, or there's a whole different packet that I don't know about. We got it working by displaying a blank details page for now, so you have to accept it and then complete it. It's not a huge deal, it's two extra clicks, but it's kind of annoying. We can also just bypass the subquest entirely by careful scripting of the framing quest. Either way, it's playable, but not perfect. I've been meaning to ask Asura about it but haven't been able to catch up with him. I'll take another stab at that once the boss has had a look. The other thing I've been working on is absorb mechanics. Asura recently rewrote the whole absorb system and it's not working perfectly yet. I'm pretty sure his method is fine, but it's behaving a little strange so there is something off in the procedure. First problem was just a typo that caused the server to go into an infinite loop and crash whenever I cast Ice Barrier. Thanks to some help from Cragus we nailed that one pretty quickly, and now I'm onto the strange behavior. Basically when you get an absorb buff applied to you, there's a dynamic list of absorbs attached to your character that it gets pushed onto. When you take damage, it iterates through that list in order and figures out if that spell is capable of blocking the school of damage in question. If so, it pulls from that shield first until it's gone. If there is still more damage, it moves onto the next shield, if one exists, until there are no shields left, at which point the rest of the damage is dealt to the player. The first problem is that when a shield runs out of "absorption points", the buff isn't actually removed. It doesn't work anymore, mind, damage goes through fine, but the aura still sits on the player until it times out, so that's one thing that needs fixing. The other problem is Mana Shield, specifically when used in conjunction with another absorb. Mana Shield has it's own goofy handling because it has to also do mana damage, which complicates things a little bit. It still counts as one of your absorbs in the list but is handled differently because it's a different aura type, and has some special handling in the absorption code after the rest of the stuff is dealt with. The result in-game is that Mana Shield works fine on it's own, but when used simultaneously with Ice Barrier or another shield, sometimes the Mana Shield buff is disappearing before it should, and I'm not certain why yet. Whether damage is incorrectly being applied to both Mana Shield and the other shield, or somehow shared between them, or some bizarre multiplier is happening, I don't know yet. I'll crack it shortly, it's not that big a deal. It's just what I'm working on presently so I figured I'd talk about it. Alright, I think that's enough for now. I'm working late shift the next two days, then going backpacking for a few more. I'll be in the woods for four days with no tech higher than a sharp knife, so I won't be around for the next week or so. Depending on what happens in the following week, I may or may not delay my next blog post depending on whether or not I have time to get anything of substance done after I get back. I'll let you know when I return, for now we'll say I'm going to keep the schedule and my next post will be Monday, August 28th, subject to change. As always, feel free to ask questions or leave comments below, and thanks again for your continued interest in Crestfall.
  3. I'd rather things not run off in wild speculation. Suffice to say it's a big deal, but not as big a deal as Crogge is making it sound. It wouldn't be fair for me to post something and then just take off for four days and not have anyone answer questions. We also need to bring the rest of the staff up to speed before we make it public. The announcement will come Sunday or Monday, once I'm back from backpacking.
  4. I asked you to stop. You didn't, so now I'm making you. Topic is closed. If this pops up again somewhere else I'm just going to start handing out "vacations". Keep your drama to yourselves or go flush it down the toilet of /r/wowservers where shit like that belongs.
  5. Good afternoon, I'm sure many of you have read the recent round of drama on wowservers. We had hoped that moving to silent development after the LGN fallout would allow us to move forward with our most dedicated, committed beta testers and focus purely on development. Obviously, someone wasn't on the same page as the rest of the team. Said post was clever. Just enough truth, twisted to be presented in the worst possible light (and mixed with some outright lies), in order to make things look significantly worse than what they are. So, to the truths from said post. Yes, around 15 people from the beta team have become inactive over the last 2-3 months. Yes, Ghostly is now 'leading' the testers. This isn't because Asura can't be bothered, but because we did learn from when Outstanding quit and decided to start delegating some of the responsibility to others. Yes, the dungeon/raid clustering node is currently switched off, we already know clustering works and aren't interested in working on that content at this time. Yes, we recently missed a deadline for Q&A 4. It's drafted, Asura got back from his business trip on Saturday and it is just waiting for review. It should be with you shortly: As you can see from when Q&A 3 was closed, we anticipated a delay because of Asuras business trip. This is not news to anyone who was paying attention to the forums. On to the meat of the matter: Bugged classes unfixed since January/February? True, and untrue. Class fixes have been a lower priority over resolving underlying mechanics like dodge chance calculations, pathing, and things of that nature, but they've been getting picked at, and are now a major focus. The last big push of class fixes was 11 days ago, which fixed about 200 broken player spells. Our first scripters have access to the scripting machine and are now active. It's behind schedule, but it is active. Soulson has some connection issues which are taking time to fix, hopefully those are resolved soon. Crogge is not, has never been, and will never be, a dev or a scripter on Crestfall. He handles hardware and the website behind the scenes, so as long as the machines are running, he's doing his job. He has also never threatened beta testers with removal from the project, aside from one time whe he did warn people to stop carrying on a personal vendetta on the Elysium forums which was reflecting badly on the Crestfall team. While many events remain to script, the 1-60 experience is far from unfinished. It is entirely possible to level 1-60 through every zone in the game and the majority of quests can be completed. Does this mean we're ready for release? No it doesn't, hence why we're still in beta and still have scripters working through the content polishing it. PvP has been informally tested throughout the project and is far from "completely" untested. A PvP-specific testing wave is planned to come in before open beta. We are completely rewriting this emulator using the Ascent framework. This isn't the hackfixed Mangos realms we've been used to for the last seven years. There are no band-aid fixes to get things to an approximation of blizzlike. We have completely torn out whole sections of code and written them from the ground up, in line with modern professional coding standards. This includes systems such as the spell attribute system, loot templates and profiles for every mob and boss in the game, the clustering system and many more. These haven't been patched over by a team working from a relatively modern Mangos release, they have been personally rewritten from scratch by our core and database devs. Testers have reported well over a thousand issues so far, and our fix rate is currently around 65%. That doesn't mean there aren't still more things to find, but it should show the percentage and how far we have moved along as a project. Currently, Asura is working on an in-depth debug system for testers in cooperation with Roadblock, who is building a custom addon that will feed more data back to the devs and allow testers to get detailed info on combat calculations. This gives testers unheard-of ability to scrutinize the internal workings of the code, and should help expose any remaining core bugs still undiscovered. Now, on to the accusations made against Asura personally: Regarding the slip to 2018, is it possible? Yes it is. Do we remain committed to trying to release this year? Yes we do. The moment we change the aim of our release from 2017 to 2018 we will let you know. It's basically a matter of things being done when they are done. This is a hobby project that we work on because we want to. Reality is, yeah, the project could probably be better managed, but this is the way we do it. Asura is the only one with the knowledge and expertise to run the show, not to mention that the entire project, from conception, was his idea. Maybe you don't like his style of leadership, but that's too bad. Maybe he's not the hero you deserve, but he's the one we need right now. We haven't been setting deadlines for our teams; we allowed people to contribute what they can, as they can, knowing that everything is building towards the final goal. When we state an estimated date for something, that means it's an estimate based on current progress, not a deadline we're setting for ourselves. Estimates change, and while some people seem to want that to indicate that nothing is being done, all it actually means is that "shit happened", whether that's real-life obligations, particularly difficult code rewrites, building additional debug functionality for testers, or just taking some time off to recharge. All of us, staff, testers, and the community at large, are volunteers here. We haven't asked for or accepted one dollar from the community. Crogge, Asura and Darkrasp have shouldered the entire cost of development (hosting and domains for these forums, the code repo, the beta realm, hardware and software for security, etc.) without blinking an eye. I stress: We do this because we enjoy it. The work, spending time with friends, the whole thing. This isn't a business, or a PR firm, or a government project.. it's a hobby. The only way we quit this is if it is no longer enjoyable, something a good chunk of our contemporaries seem dead-set on making it. Happily, we're perfectly content to tell them to screw off and keep on doing things our way, regardless. If you want this to be a professionally run and managed enterprise, you're in the wrong place. Go call up Viper and Daemon, if you can find them. Crestfall, by hook or by crook, is going to get finished, but it will be done on our terms. Period. All that said, we do recognize that the undisciplined approach we have been taking gives people hesitations as to our progress, since, although work is always being done, it's difficult to put that into any kind of a timeline or flowchart. This was intentional on our part, since, as a hobby project, we didn't want to be held to a deadline, making something that we should be enjoying into a source of stress. What we would like to do is develop a clear plan of attack, some sort of progress checklist where we can mark off items as being formally finished or in-progress. Due to the complex nature of what we're making, this list would be obviously be subject to changes, but at least it would give some sort of visual indication of progress, so the community can actually see what's being tested, what's being worked on, and what's finished. This will take some time to assemble, and we're not completely certain how exactly to set it up for display yet, but we feel it will be a useful way to keep the community in touch with what is happening and allow you to see that yes, things are getting done, and yes, we are moving towards release. We had envisioned and started building a number of tools that would somewhat automate this process, so we'll be investigating exactly what would be required to integrate those into something publicly visible, to determine how much time that would take and whether or not the outcome justifies the delay. In the meantime, we wish to do at least a little bit of a return to our roots, and begin engaging with our community again more frequently. While our forum schedule will remain largely the same, we have reopened the public discord and invite you to join us. This will be a little bit of a distraction for us, but we feel it's an important part of building the realm and worth the time investment. In order to keep things to a manageable level for us, we are interested in selecting a few additional mods/CMs to assist with management of the public discord. Interested applicants should message Darkrasp on the forums. Further to that, we will also be adding some additional beta testers to replace the few who left recently. So, in conclusion, and we thank you for sticking around long enough to read this wall of text, our team is still motivated and still producing. Our intention in scaling back our communication with the community was to avoid drama and be able to work faster with less distraction, however the lack of communication seems to be driving too much doubt about our project. We're trying to find a balance point that allows us to maintain our communication without compromising too much on lost development time. It's also important for us to restate that this is a project we do as a hobby; we do it because we enjoy it, and we won't be pressured into making promises or holding ourselves to deadlines. We are committed to releasing, but we won't release garbage. This is going to be done, and it's going to be done right. We thank you very much for your patience, your understanding, and of course, your continued interest in Crestfall.
  6. Not liking the way this is going. Don't make this stuff personal. Only warning.
  7. We're actively avoiding hype at the moment. That Alpha Preview took a huge expenditure of time to create. Hours to pick what features to showcase, hours to get the footage, hours to decide on and create the logo, writing the text, rewriting the text, figuring out how long we wanted the whole video, figuring out how long each feature should be on for, cutting out footage, going back to get more footage, then actually doing the editing. Then finding mistakes and having to go back and do things over again. We're a very small team and none of us specialize in video production, so it's very time consuming for us. Right now we feel that time is better spent on development. As far as building hype up, we're actively trying NOT to build hype. As Rawne mentioned, hype gets us more page views on the forums, sure, but it also gets more trolls on the forums, and more drama on reddit/Discord, more attacks from other private servers, and more junk mail from Activision. A whole lot of nonsense that none of us want to spend time dealing with, especially with so much work left to do. I get about 10-20 hours per week of free time to spend working on CF. Writing a blog post is roughly 2 hours. Filling out the Q&A is roughly 2 hours. Browsing the forums and responding to threads like this, you guessed it, roughly two hours. The more PR I do, the less coding I do. As a junior dev, my time isn't nearly as valuable as Asura's time is, which is why I'm the one doing these things instead of him. When things get out of hand and he has to deal with them personally, that really slows the project down. For that reason, we're still trying to keep things on the down-low for the time being. More videos will come, but not until we're closer to release.
  8. 1) Auctioneer should still work, at least mostly work anyways. Might be some limitations, but we don't intend to ban or entirely break the addon at this point. Don't want to get into specifics at this time. 2) More random. Call it un-Blizzlike if you want, you also didn't have 1.12 talents during patch 1.4 on retail either. 3) We don't have a huge team or unlimited time, so the vast majority of custom changes that people request are ignored or discarded. When we decide on how something will work, the topic is typically closed. People are welcome to make suggestions, but there are plenty of things they're just going to have to live with. We are very aware of the dangers of entering the custom changes rabbit hole. We don't make a lot, and the ones that we do are for specific reasons. 1) It's an anti-griefing measure. As I said, we're unlikely to make any changes like this unless it's becoming a serious problem. 2) The idea is to release content at first in a highly buffed state to give the tryhards a challenge, and then tune it back so other guilds can catch up, much like what Blizzard did on retail. 3) It will be one difficulty for everyone, but that difficulty will change over time. 4) Probably not going to happen, though we may seek community input when it comes time to tune down the encounters. 5) I have my own question: Why do you put a space between the end of your sentence and the question mark? 1) As long as someone scripts it, yes. Our scripting engine will support it. 2) Yes.
  9. Locking this thread now so I can start putting together the answer post.
  10. Good evening, I forgot about this update, so it's already very late. I'll try to keep it short so I can get to bed at a reasonable time. First the other guys, Asura's been working on a ton of stuff, we've been making a push to get our TBC realm alpha-ready, so he's been working on a bunch of things for that. Before you go off and complain that we should be focusing on Vanilla.. we know. Working on TBC is a nice change of pace, and it exposes problems and optimizations in the core that apply to TBC and Vanilla, so there's benefits to the Vanilla realm from doing this work, aside from that of just showing how serious we are about progression through expansions. Right now, with the same realmlist, you can connect to our loginserver with both a Vanilla and TBC client. The Realmserver will automatically detect which client you are using and direct you to the appropriate server selection. TBC is still pretty unstable, but you can login and play. Quests work, creatures work, AI works, flying works, etc. Asura has been converting the guild bank system over to support clustering. It's pretty ridiculously complicated compared to a regular bank. If you recall back to my last blog post, the inventory system in Vanilla only ever applies to one character at a time, and all your items are indexed as a combination of a container ID and slot ID. In the case of guild banks that no longer works. You have to be able to handle multiple characters, so they have their own unique database storage, but you also have to allow specifications for which characters have access to which banks, and which items and pages within those banks. The banks have to be able to transfer items back and forth to players, and back and forth amongst themselves, so we need both worldserver and realmserver handling for it. Complex stuff that's well over my head, but he seems to enjoy it for some reason. So yeah, we have a pretty big push coming. Asura was supposed to get it done this weekend, slightly delayed due to time restrictions and just the sheer amount of code in it. This patch includes all the new debug tools, and a lot of fixes for problems found while working on TBC, plus some reported issues, Nogar's patches, and my pending patches, so we're excited to push that out to our testers, but it's complex enough that it is taking a little more time than anticipated. I figure a couple days and it will go live on our Beta realm. Nogar has been going through the zone checklists our testers have been submitting and both fixing generic database issues like drop rates, and also messing around with both the SQL and Lua scripting systems. My understanding is that he's been fighting through the early shaman totem quests, getting them scripted. We accepted four applications for Discord moderators. Djlovedrop, Maronics, Seefly and Swen. They're settling in nicely and public chat is generally a friendly place, so happily keeping it under control isn't too onerous a task. Alright, now for my bit I guess. The last little while I've been working on two things, both of which are now done and submitted, just waiting for approval and the push now. First was a collaborative effort between Gorbulas and myself. We have a database table that specifies what items a new character is created with, and some of the testers were making reports about characters being created with weird items. Elf and Troll hunters, for example, were starting at level 1 with a level 32 cloth belt equipped and no ammunition. Orcs also had a waterbreathing elixir with 0 charges that couldn't be used, moved, or deleted. Real bizarre stuff. We tried changing around items in the database thinking it must be a bug with how that table was being loaded into memory on server boot. If you have a problem with your loading code, you can store garbage vaules, or just whatever random value happens to be in a specific memory location at the time of boot, so we figured these items must be a result of bad db loading code. Turns out the db is loading just fine, but those items weren't being pulled from the database at all, they were being pulled from a client file that's supposed to specify which items a player starts with, and since our code for loading was using the db structure instead of the dbc structure, we got some extremely weird results. So, we ditched the dbc code and just made it load correctly from the database, then fixed up a few errors in the database. Now it's working very nicely, and we were able to chop out a whole bunch of now-extraneous code, which is always nice. Next thing I worked on, and this took the bulk of the time, was a reorder of the loot template IDs and some adjustment code in the core. Our loot system, which I've also described in significant detail, is based on templates. A mob will be assigned some number of templates it gets to roll on in order to generate loot, and it does so in ascending order of Template ID. That's all well and good, but it had the side effect of also displaying the loot in the loot window in order of Template ID, which I knew was going to be an issue for players. I mean, the same loot is there, it's just the order that's incorrect, but that kind of thing will drive people crazy, and by extension, drive me crazy, since I'm the one who would have to deal with the complaints about it, so I wanted to get that cleared up. When I first built the system, I did use a system for numbering the templates, just for ease of use while assigning loot, but the order was arbitrary, and again, just for ease of use at the time. I wasn't thinking about the display order. What I had to do was more or less write a series of SQL queries that changed the Template IDs and put them in an order much closer to what they should be. There will still be a few items out of order, mostly either quest items that are also equippable (quest items have the highest set of template id numbers and will always be the last thing in a creature's loot list, but equipment should appear early in the list). Or mobs that have a static drop or zone drop that isn't equipment (certain tradeskill items, mostly, and a few quest starter items). In any case, there are few enough of them that they can be addressed individually as necessary, the larger part of the work is now done. It did create an issue with world drop items, which are handled differently in the core. As we've covered before, our world drop templates are generated dynamically based on the level of the NPC in question, meaning a level 62 elite can drop a Teebu's, but a level 61 version of the same mob cannot. What we did in the was set the Template Id of those to a negative number, and then in the core when you wanted to generate loot, it would know if it saw a negative number to use the world drop generation algorithm, and otherwise use the regular generation algorithm. Problem is world drops in that case would ALWAYS appear first on the list, which might be okay for trash mobs, but makes boss loot tables look very strange. I reordered those templates into a spot in the order more appropriate to them, after the static and zone drops, but before tradeskill and junk items. This also required changing the core handling because those numbers were no longer negative, and it also affected loot tables for items (think Kum'isha's Junk), and gameobjects (think Cache of the Firelord, or just regular old treasure chests). Bit of a nightmare to juggle all that without inadvertently screwing something else up. Accidentally missing a template, or doing them in the wrong order such that one overwrites another, would be a nightmare to try to identify and fix later. It was absolutely essential that I be painstakingly careful with it and get it right the first time.. A mistake there would have far-reaching effects that we might not even notice until we had gone to open beta, or worse, release. That is absolutely not the kind of thing you want to get wrong and have to try to fix afterwards. So, with few exceptions, you should be seeing all equipment unique to that mob first, then any special zone equipment drops, then any world equipment drops, then tradeskill items, then junk items, then quest items. Pretty sure that's the way it's supposed to shake out. I'm happy with it, anyways, and I don't particularly want to spend more time on it anyways. Alright well, I'll leave it there for now. It's after midnight and I need to get up early tomorrow. My next blog post will be on Monday, August 14th. As always, feel free to ask questions or leave comments below. Talk to you soon, and thanks again for your continued interest in Crestfall.
  11. I'm not sure I understand what you're saying. Having the most powerful proc take precedence on any given swing is blizzlike, so I don't know what you're on about here. The only thing about the system I've got that isn't blizzlike is the ability for items which grant extra strikes to proc off themselves, which was possible for a while in retail but was eventually nerfed. We're starting with it nerfed and leaving it that way. The clamor in here is for an un-blizzlike change, which would be so negligible a buff that it would be nearly impossible to even notice a difference in-game. How this topic always manages to spiral out of control like this is utterly beyond me. I said I would look at it, but it's unlikely that I'm going to make any changes to the system as it is already described.
  12. It's something I'm willing to look at, but extra strikes are extremely complicated due to how they are stored and tracked in the core, so if it turns out to be a whole lot more work, I'm not going to bother. The reason it was implemented that way in the first place was that genuine evidence was presented to prove that only the highest value proc applied on any one swing. Also, it's hardly "quite a nerf", since the odds of multiple procs on the same swing with something like Hand of Justice (1% proc rate) or Ironfoe (2% proc rate) are pretty low. You're talking about a "nerf" (but not really, since that's how it worked on retail) of some tenths of a percent. Nothing to write home about. Extra strikes are a crazy powerful mechanic that really need to be kept in check as much as possible, aside from being insanely complex relative to most combat mechanics. When you preform just about any action, the server checks your character for any auras you have which proc off that action. Cast a spell, the core iterates through your list of auras that can proc off a successful spellcast, ie. Clearcasting. Take a crit, the core iterates through your list of auras that can proc off a critical hit taken, ie. Enrage (Warrior). When you strike an enemy, the core iterates through the list of auras that can proc off a successful strike. Here's where your extra strikes come in. So the strike lands, damage is calculated, and then it checks for a proc. When a proc happens, the core jumps out of the strike code, and into the spellcasting code. The spell effects for that proc all have to get processed now. So for Windfury, for example, that's these two effects right here: First, the aura that increases attack power gets applied to the caster. Pretty simple buff with a 1.5 second duration which is handled in the ApplyAura code. Second, we jump into the handler for SPELL_EFFECT_ADD_EXTRA_ATTACKS. We're going to carry in the SpellId, so we know which spell brought us here, and the BasePoints, that's the number of swings added. In the effect handler, a lot happens: We have a multiproc register that tracks the source of the extra attacks for that swing. If that spell or one like it (ie. different rank of same spell) has already been seen, it dumps out without doing anything else and goes back to the strike code where it left off. If it hasn't been seen, it sets a flag in that register and continues on. Next thing is to check for the doubleproc flag saying that an extra strike has occurred on this swing. If it has, it will compare the amount of strikes added so far, and ensure that the highest value takes precedence. If not, it just uses however many strikes are listed in the effect and sets the flag. Now it's going to add in the extra strikes to a counter which is a part of your specific character stats. You can't see it, but it's a counter of "pending extra strikes". Ok, so the spell code is now finished, and we go back into the Strike code to finish it off. Right at the very end of the strike code is where extra attacks are handled, and there we check there to see if the "pending extra strikes" counter is higher than zero. If so, we just clear the doubleproc flag, decrement the counter, and call another strike. The whole strike happens again from top to bottom, including the proc checks, in a loop, until either we run out of strikes, or the target is dead, at which point the initial strike code is actually allowed to finish, clearing the multiproc register and preparing it for the next attack. What you're suggesting is to change the code in the handler such that we un-set the multiproc flag for that source in the event of a doubleproc flag failing it's check. It's somewhat tricky because we then have to know what the previous spell was, which might be able to be inferred from the multiproc register, and might not be, depending on how many things actually procced. If you're on your third proc, then some very bad things can happen if it has to guess which one was first and which was second. That information just isn't carried through forever, and increasing the amount of variables we have to track on every swing is bad for efficiency. The system is quite complicated enough already. Again, I'll look at it, but I can say that changing it us unlikely to happen because: 1) It's demonstrably not Blizzlike (If I can dig up the screenshot I'll post it, asking Beta Team now) 2) It's a crapload of work.
  13. 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/
  14. Good evening, Been a busy couple weeks. Asura pushed about 20 patches in the last ten days, which fixed a huge amount of stuff, mostly to do with AI and creature events, as well as starting work on a bunch more. We're also in the process of properly re-implementing all the spellfixes that got disabled when we started this project. This way we can fix the spells in such a way that they aren't just messy hacks, but actual stable, efficient handling. One quick example of this, Gorbulas and I resolved a crash caused by Far Sight (fix is done, just optimizing the code before it gets submitted). The Far Sight spell, Eagle Eye, and Sentry Totem all work in a very similar way. Far Sight and Eagle Eye both create an invisible, passive NPC, and then transfer your vision into that NPC, something like when you mind control another unit. It's necessary to disable the AI in that NPC so that it cannot move, enter combat, or take any other kind of action. It's simple enough to write a hacky "If we're spawning NPC 14495, don't enable the AI," but that's rather a lazy and inefficient way to do it, and it presents a risk of duplication, as well as the fact that it won't fix any similar bugs. You don't want a big chain of one-offs that has to get checked and processed sequentially every time you cast any spell. The code gets hard to read, inefficient, slow, and unstable. It's far better to implement fixes in a way that any similar spell is also fixed at the same time, without needing to check each specific case. (We fix this through implementation of a custom creature attribute we can apply to any NPC that needs it's AI disabled, one fix for many problems.) So, spellfixes have been going back in, affecting about 200 spells so far, plus a few spell scripts for dummy effects on things like Preparation and Cold Snap. Diminishing returns got some work, which caused a bug with crowd control always lasting 20 seconds on the first application (made Hammer of Justice slightly overpowered), and that was fixed within a few minutes of the patch going live on the beta realm. The big work has been done on Creature Events, which ended up being broken due to a database snafu. Took Asura a bit of time (not hard work, just time consuming) and things are working pretty smoothly now. With that working, we now have our scripting realm online, and the first two scripters are sorting out their security access. Nogar has also been messing around with some SQL scripting and I guess he's getting the hang of it. I believe he scripted the Argus Shadow Mage NPC from Alterac Mountains, the one that transforms into a skeleton at low life, just to test out some of the mechanics. There was another crash with item saving where inventory items were getting loaded into equipment slots and causing characters to just hang at the loading screen forever. I found that one and fixed the symptom, then Asura did some work on item saving to prevent the initial cause. This could probably use some explaining.. In order to minimize the effect of any crashes or server outages, we save characters frequently, but in order to improve performance, we don't necessarily save all aspects of a player every time one thing changes. A character is fully backed up every so often, inventory, position, health, etc.. all these things are backed up on a timer. I'm not sure offhand how frequently that is, though. Asura could tell you for sure. Some things though, are additionally saved on-demand. Your inventory, for example, aside from being saved on the timer, are also saved whenever you loot something, and in order to improve that even further, we only save the things that have changed since last time a save happened. Items are "marked" for saving if they are moved or added between save events. An issue with items not being "marked" was causing item duplication. When an item tries to load into a slot where there is already an item, the server attempts to find an empty inventory space to put it in. Our problem was a failure in that function to account for bags other than the backpack. I'm going to get a little technical here for a moment. If you're a dev, you probably already know this, and if you're an unabashed casual, you probably don't care, but I find it interesting so too bad. The way the WoW inventory is set up is by a two-part system, Container and Slot. Almost everything is in Container -1, and then there are 97 slots, which start off at Slot 0, which is your Helmet, then goes through the rest of your equipment slots. Slots 19-22 are your bags (other than backpack). 23-38 are the contents of your backpack. 39-62 are the contents of your bank, then bank bags, then vendor buyback slots, then your keyring. So you can identify any item you have that is NOT in a bag other than your backpack by those two numbers. Your equipped shoulders? Container -1, Slot 2. Third item in your backpack? Container -1, Slot 25. Etc. Items that are in bags use the Container ID appropriate to the bag slot they're in, and then have however many slots of their own. If you have a Traveller's Backpack in Container -1, Slot 20, then the fifth item in that bag would be found at Container 20, Slot 5. That's how the information is saved in the database. So, our problem. Due to a bug with items not getting marked when they should (which, I reiterate, was fixed, but it's still important to fix both sides of this in case a similar situation does happen due to a particularly badly timed crash), items would get "duplicated", not in the sense that you get two of them, but if you had say a helmet on, saved your character, and then switched it, but the old one wasn't being marked as having changed, then when you logged back in, it tried to equip both those helmets simultaneously. The first one works fine, the second one attempts to load, wigs out because there is already something there, then tries to find a spot in your bags for it. That function was ignoring Container when placing items. If the "find a free inventory slot" function found an open slot at the aforementioned Container 20, Slot 5, it would just try to place the item in Container -1, Slot 5 instead, which happens to be your belt slot. Now we get players wearing un-equipable items, items getting overwritten and deleted, and characters that bug out and can no longer log in. Fix for that was just to implement it so that the placement function took Container into account, and bada bing, bada boom, problem solved. Alright, that was a really long winded thing, so I'm just going to quickly rip through the rest of what we're doing. I'm fixing a few loot issues, tedious db work involving splitting a bunch of templates up so they work correctly, done about 100 of 190 so far, and also trying to get them to sort so they display in order of quality instead of by TemplateId. Fixed the formula we use to determine weapon and defense skill increases. Found and fixed some db errors with random properties caused by earlier typos. Fixed a bug with DoT and HoT spells where their damage coefficients were being calculated on tick, instead of on cast. Found the cause of a tiny loot bug with unskinnable mobs showing skinnable, even though they have no loot. Helping Nogar out with a bunch of db junk, he's going through fixing a whole lot of miscellaneous stuff, which is great. Probably a few other things as well that I can't recall right now. Point is, we're busy beavers. I'm going to wrap this up now because I want to get a few more templates split before I go to bed. Alright, that's all for tonight. My next post will be on Monday, July 24th. Worth noting, Asura is out of town on a business trip for a week starting today. As always, feel free to ask questions or leave comments below. Talk to you soon, and thanks again for your continued interest in Crestfall.
  15. Good evening, Since I've been doing a ton of writing for the forums and busy at work IRL, I haven't gotten as much done this week as I would have liked. A lot is going on right now and I figure it's probably best to leave my blog post until next week when I can do a more substantial post, having had time to catch up more thoroughly with the rest of the team. You'll have to make do with the project update posted on Saturday and the Q&A posted yesterday for now. We're also working on a few things we want to keep quiet for a little bit longer, so again, best to have a slight delay and then we can talk about all that next week. So, this week's blog will be postponed and I'll write one on Monday, July 31st. If you're anxious for discussion, it's worth mentioning again that we have reopened our public discord - you can access it from the "Browse" button in the bar right below the Crestfall Forums banner. The team is in there pretty frequently chatting, and as mentioned, we are looking for some more mods. I've gotten a couple applications so far and the more the merrier. Note that we're not making schedules or demanding you spend so many hours modding; if you're in there lurking or chatting already, you'll get some loose guidelines on keeping things under control, and that's all we'd ask you to do. Just make sure things aren't getting out of hand while you're around anyways. If you're interested, PM me on the forums, or on Discord. Alright, better stop before this actually does turn into a blog post Talk to you soon.
  16. It has come to our attention that someone is impersonating Asura on reddit. Both Asura and myself completely ceased all reddit activity months ago, and Crestfall does not have an official reddit presence. All Crestfall staff members were requested to stay away from /r/wowservers and /r/legacyrealms long ago. We do not know who this person is, nor do they have any affiliation with Crestfall. Please treat anyone claiming to be a member of the Crestfall staff as an impostor. Thank you.
  17. We have addressed this matter officially, therefore I will now close this thread.
  18. We have a detailed response forthcoming. This crap always pops up at the worst possible times. Worked a 12 hour day out in the heat, stop after work and blow a bunch of money on a new TV since ours died last night and my wife cannot live without television, get everything assembled and running for her, and then sit down to relax and I'm greeted by this disaster. There's a reason I killed my reddit account and stopped reading it entirely. Long story short: I'm still working on Crestfall now, and I'm going to keep working on it until either it's released, or I'm dead. It's not the only thing I'm working on, I'll admit that it's just the largest of three or four hobbies I spend free time on, but I've got no intention of quitting. I think a lot of this comes from a specific event that happened recently. We invited a bunch of beta testers, and also a handful of community members who provide us good feedback and no drama, into our beta discord. It was a nice, relaxed atmosphere where we could talk freely and not worry about troublemakers and trolls. By and large, it still is. We asked people to test specific things, and typically they just tested whatever they wanted instead. That frustrates people who like things structured, but we were still getting bug reports, things were still getting fixed, and we weren't about to start cracking the whip on people who were volunteering their free time to help us out, so we just let that slide. More recently, we have been trying to increase our throughput and get more testing done. We set Ghostly about pushing the testers harder than we had in the past, making assignments and trying to set deadlines, and there has been some, (not a lot, but some) backlash against that. We're trying to strike a balance between the laissez-faire, hands-off approach, and the corporate "assignments/deadlines" approach. None of the staff wants to jump on volunteers, but at the same time, we have testers who maybe made a handful of reports when they first joined but since then - and we're talking about months here - haven't reported anything at all. Some of them had very legitimate reasons for this, so it would be unfair and inappropriate to name names; suffice to say I don't want any of the former beta testers hassled. Life happens. We did some cajoling in an effort to get testers working more, and that's when the majority of the people who left, did so. Mostly voluntarily, and mostly amicably. Most frequently because they just didn't have the amount of time to dedicate that we were asking for. In most cases they were also offered the opportunity to stay in the discord as contributors, because they're good people and can still offer valuable insight, and also just good conversation. Some accepted, most preferred to leave. I suspect whoever posted all that was one of the few who were not amicable. Of course, I could be wrong. It could be a current tester who is upset at having deadlines where there were none before, or at not having strict enough deadlines. Honestly, I don't really care, because it doesn't change anything for me, other than waste a bunch of my time having to respond to it. I'm still going to keep writing patches and working toward release even if I'm the only one left (which I'm not). Again, a detailed, "official" response is forthcoming, so I don't want to get into anything else at the moment. In the next day or so, likely. I just need to catch up with the European staff before it gets posted, which will depend on how busy I am at work tomorrow. I've seen the draft and I'm pretty happy with it but I won't be able to sign off on the final version until tomorrow at the earliest.
  19. Then your best bet is to hope Asura disagrees with me on this one. A bot that scans repeatedly for even ten minutes would get locked out from buying anything very quickly. Bots run a query every three seconds, which is as fast as the query packet will be accepted by the server. Twenty searches would take only one minute of constant requests, at which point the lockout would kick in and prevent it from buying or bidding for fifteen seconds. By the time that's expired, the bot has made five more searches and increased it's lockout time again, etc. Basically it's sending queries too quickly and cannot avoid the lockout timer, unless it changes it's rate of querying to something spaced far enough apart not to ever trigger the lockout - which could be on the order of one query every several minutes. At that rate a full scan of the AH would take hours, and the effectiveness of the bot is severely degraded. If the bot is programmed to make 20 or fewer searches every three hours, then it's almost indistinguishable from regular human activity, and not as big a problem. If the bot is only making a couple queries every few hours, it might get a good deal every once in a while, but it's not really going to have much impact on the economy in a macro sense, which is more my concern as a developer. There are some server-side things we can do to counteract more complex bots, but I'd rather not get into that. Don't want to make it any easier for bot makers. Speaking of which, you seem to know a lot about how AH bots function and how to program them, and a keen interest in what possible countermeasures we might use to stop them. I'll just make a note of your IP address now and keep it handy for future reference.
  20. If you're taking 10 minutes to run a full scan every time you use the AH, then you're doing it wrong. Once your client has a db built, you rarely need to run full scans anymore, unless I am entirely mistaken about what exactly that addon does. And no, it would still break for a botter, since it is counting number of queries, meaning the lockout counter increments every time the list is refreshed. Searching for 25 items once each, or one item 25 times, in a short period of time, both have the same effect. Players don't stand still in one spot refreshing the AH every three seconds for hours at a time in case someone happens to lowball a single stack of wool cloth, robots do.
  21. Not in any meaningful way. Auctioneer works by scanning the AH with a hundreds of searches to build a database of average costs for different items. The player could scan and build a database just fine, but they would incur the lockout timer and almost certainly max it out. To be clear: the addon would work fine, but after running it, they would be prevented from listing, bidding or buying out any auctions for the duration of the lockout. The good news is, you don't run the full scan every time you check the auction house, you do it a couple times to initialize the addon, and only sporadically thereafter to update it. Normal, everyday use would be unaffected. Banning Auctioneer isn't something we want to do. In and of itself, it isn't a bad thing, and it's use is so widespread that banning it would just upset too many people. The problem is having to differentiate between an addon like Auctioneer, which automates searching the database, and a bot, which automates searching AND buying/selling. Personally, I think the lockout is the best way, and the least invasive for regular players. As long as players know in advance that after they first initialize their Auctioneer addon they won't be able to use the AH for a couple hours, I think that's a reasonable tradeoff.
  22. I agree with you here, which is why I specified carefully that it was a brainstorming exercise and not server policy. Limits or restrictions would need to be carefully considered, of course. The pervading theme of our discussion was that if we decide to set limits, they would be set in such a way that a human wouldn't likely be affected by them. No human is going to preform 10 or more actions (query/purchase/list) per minute for hours on end. Yes, anyone could potentially list or buy out 30-40 auctions all at once - but they aren't going to do that minute after minute, hour after hour.. only bots do that. Any restrictions that get put in place would be designed with that in mind, and carefully monitored to ensure they aren't affecting a normal player's ability to use the auction house. The concept of a lockout timer would basically put a counter on how many searches you had made in the last, say, 30 minutes. I don't know what the time would actually be. Maybe 5 minutes, maybe a day. Didn't think it through that far at this point. Let's say 30 minutes for the sake of an example, keeping in mind that it, and every other number for this example, is pulled out of thin air and is present only to present a possible example and to clarify how the lockout timer would work. Got that? Okay. So it keeps track of how many searches you have done in the last half hour. The first say, 20 searches all just work fine. No delay at all. After that, further searches add a stacking timer of say 15 seconds each between when the search is preformed and when you can actually preform a list or buyout action. When you make your 21st search, you will get a 15 second lockout before you can buy or list anything. After your 22nd search, the lockout increases to 30 seconds. After 23 searches, 45 seconds.. and so on, to a maximum of, let's say two hours, which would require some 500 searches in 30 minutes or less. Waiting the 30 minutes out would reset your counter, and after the lockout period has ended, everything starts over fresh. To a player, they can search for their cloth or herbs or what have you and then list or snap up as many stacks as they like. Even if they want a large variety of items, they'd probably be looking at a delay of maybe a minute or two, though realistically most players are hopping on the AH for a couple of items and probably aren't going to get to 25+ unique searches, especially not in 30 minutes or less. A player who isn't a big time AH player is unlikely to ever see a lockout at all. Bots, on the other hand, would be hitting the lockout point in about one minute after being turned on, rendering them incapable of buying or selling much of anything, and vastly limiting their ability to affect the server economy. I'm afraid I have to disagree with you there. Any kind of botting is a problem.
  23. I don't have weight of law on this, Asura would make any decision regarding custom changes to the auction house. Personal opinion follows, not official server policy: I loathe auction bots; I think they're basically cancer to a server economy and drive price inflation to unreasonable levels, quickly. I have spent some time with the beta crew brainstorming a number of ways to defeat auction bots, and to improve database preformance. Some of the suggestions include 1) a limit to the number of searches that can be preformed over a given period of time, 2) a limit to the number of auctions that can be created or purchased over a given period of time, or 3) a scaling lockout timer on buying based on the number of searches done over a period of time. In each case, regular human users would be largely unaffected, but anything attempting to do high-volume trading (consistently making dozens of searches/purchases/sales per minute) would quickly be logjammed out of the system, as well as being flagged as a possible cheater for GM investigation. The question is how to do this without breaking auction addons such as Auctioneer, which rely on hundreds or thousands of rapid searches in order to function, and in many cases behave similarly to a bot, except without making purchases. The third option is probably the best one. Players would have to wait out the lockout period after initializing their addons, but afterwards could use them normally without penalty, while bots would remain broken. All things considered, if it comes down to breaking an addon in order to prevent auction bots, personally, I'm more than willing to make that trade.
  24. Thought about it, but it's unlikely for three reasons. One, we don't want to release our research out into the open where it's just going to get sniped right away. I have no problem making it public once we've moved past Vanilla, but until then the smart move is to keep it closer to the chest. Two, because building a site is a waste of developer time while we still have core and database work to do. Three, because I really like the idea of players doing it on their own using loot addons to make their own Crestfall-Wowhead. I'd love to be able to compare the drop rates I programmed in with what the players are actually seeing. There are several assumptions for Paladin int/crit rating, all based on spotty, observed information rather than hard math. The 28 int for 1 spellcrit comes from Paladins with approx 150 intellect getting roughly 5% crit. The issue is that's not exactly how spellcrit works. Tseric made a whole post about how classes have an "expected intellect" value, ie., the amount of intellect they expect you to have through a combination of gear and base stats. If you have the expected intellect, you have exactly 5% crit, then you gain additional crit per point of intellect above the expected value, and are penalized below it. The problem with 1% crit per 28 int isn't that it's wrong, it's actually pretty close, since the Paladin expected intellect at 60 is, I believe, 150 (Mage is the highest at 286, the rest of the classes all fall in between those two). The problem is that the formula doesn't work at any other level. Tseric specifically mentioned this, and yet the same formula is in use for all levels pretty much everywhere. My formula scales the value of expected int with level. As long as you are equipping "average" gear as you go along, your spell crit rate should be hovering around 5% from level 1 through to level 60.
  25. It would be interesting to have a dump of proper formulas for Vanilla. In the process of building Crestfall, we've encountered a large number of mechanics that previously had been estimated, hacked, or just used TBC or Wrath versions of the calculations. Due to some excellent research and generous contributions of time and trouble from our alpha and beta testers, we've successfully reverse-engineered a number of them, but that information won't be made public at the present time. We may decide to release it later, at which point a wiki page might be a good way to do it. As it is, the biggest weakness the wiki pages have is a reliance on generalizations, or formulas that only work at level 60, if the formulas exist at all. It was mentioned in one of my blog posts how I reverse engineered a more accurate formula for converting intellect to spell crit. Roadblock and a few of the other testers reverse engineered proper formulas for hp, mp and stat gain for each levelup. Work was done to develop a much more accurate formula for advancing weapon and defense skill points. I was able to crack itemization point values using a fairly simple formula as well, so that I could derive proc rates for various weapons appropriate to their level, the strength of the effect, and the other modifiers on the weapon. Those are just a few examples, it gets worse when you have mechanics that changed frequently (see: extra strikes) or for which there are several competing theories (see: glancing blow damage reduction.) All these things had to be worked out by hand through a lot of hard work; there's no readily available resource for them. The wiki pages are heavy on the "player advice" side, but often vague to useless from a developer perspective. For now, it makes sense for us to protect our work, as it will be what separates us from other projects. Once that is no longer a point of necessity, I'd be more than happy to share all that information with the rest of the community.