If you want to find and fix ALL the bugs - that's not going to happen. No expansion in the history of EQ went live bug free. I was talking about the obvious things described in the post I was replying to: totally wrong spell IDs, etc. That kind of bugs is caught and fixed even with minimal testing. If you don't want more raids just because there will be bugs in them, you are playing a wrong game.
I'm playing around with you because EQ beta is nothing like what a real beta should be. I have beta tested other games, and had much better results. The majority of people understand this, and is why most people don't care to beta test, because they know what they report isn't making much difference because he bugs that are reported still make it into the game post beta. I have beta tested for my job, and hold myself to a much higher standard. If I were to release product with as many and as much glaring holes as this, I probably wouldn't be as gainfully employed as I am. If you see a huge glaring bug, you fix it, that's the difference between a closed project and a still progressing one. The finesse is the difference between a product with not many/very hard to find bugs, and ones that are easily seen and talked about extensively on the forums, and more than that, not even addressed or acknowledged by the development team. I don't see any other game out there that has as many issues coming out of betas as EQ, and I have played the majority of major MMO's that have come out. Mind you, this is a game, so I don't care that much, but I am paying for it, and would like to hold them to the same standard I hold myself to....
Teehee I thought Beta testing was only for the top 15 guilds to get raid events on farm before the expansion comes out!
You. I like you. Anyways, this Tearsin fellow is clearly trolling and knows little of development. There are a *lot* of people that know quite a bit about scripting raids. And yes, it is quite easier to "copy/paste" existing content, retune said spells/events, maybe add in a few more quirks, and be done with it. You don't have to pay an art team to design a new zone (which wouldn't be done in the TDS case anyways, they'd probably just add new raids to existing TDS zones to save money). Art teams are a very large budget and time factor in new content. You don't have to dream up new encounters and spells and emotes and mobs and triggers and placements and leashes and counter tactics and... well, you get my point on this subject. CToV was likely much eas*ier* to make as opposed to a new raid, as the content was there. Tune the mobs to the scale of the expansion, rework a few scripts, add a quirk here and there. Boom. Entry level raid (though perhaps too easy) that people can get their feet wet in and say "Hey, I raided RoF". This is the primary reason I love CToV. Confidence booster, some mild gear, a stepping stone. As for whether this should happen with TDS, I'd love to see it. Whether it should give Darkwater similar to how CToV gave Gelid? No But make it easier than AM raids with less script and add in CoTF T2ish loot. It's also an incentive to buy the darn expansion if your guild can actually defeat a raid there. I myself am stuck in ToR/AH.
All trivial frankly compared to writing it the first time! Changing NPC and spell IDs is just a basic search and replace job. It could even be automated if you give an input file of old and new values to change. Yes it takes time, but copying a spell and updating the numbers and copying an NPC and updating the stats is quite simple. So while it's not just a single click to up the levels of the zone, it's got to me MUCH simpler than rewriting a completely new raid script, zone geometry, zone artwork, mob models, etc from scratch. Massively quicker. Even if we ignore the zone things (and we shouldn't - it all costs time and money) and focus purely on the raid script, copying an old one and changing the spell/NPC IDs is much easier to test. There have been countless bugs in scripts before, but you can be 90% sure that this won't be the case if you start from a known good one, thus reducing the debugging time.
