chinajade
Community Developer
- Joined
- Jul 20, 2010
- Messages
- 17,540
- Reaction score
- 172
In this post, Apoc wrote...
First, this is not a flame. My primary interest is in keeping the development team focused on productive tasks, and away from whiney users.
The Problem
I've already bumped into the "my CCs don't wait for rezsick debuff" problem and had to turn off HB's "Spirit Rez" feature. My guess is that my reaction will be typical of the user community. The result is that the development team will have wasted a lot of effort on something that nobody will be using.
I think is going to cause the HB developers no end of questions and whining in the forums when people try to use it. It basically means we can't use the new feature unless the CC supports it.
A Better Solution?
Using the principle of symmetry, whatever software area is responsible for accepting the spirit res should be the one responsible for dealing with its consequences. If the CC accepted the spirit res, then fine, it can deal with it. If the HBcore did, then IMHO, its the HBcore responsible for dealing with it.
Could the HBcore not provide a default method in whatever class that CC's derive from, and arrange for the HBcore to ask the CC if its capable of proceeding with RezSick? The default answer would be 'no'. Given this answer, the HB core would wait for the debuff to expire before transferring control to whatever should happen normally. If the CC overrides the method then says 'sure, I can fight with rezsick', then the HB core could transfer control immediately.
What this does for the community and the developers--both HBcore and CC:
I honestly believe that a little more time thinking about this problem will head off a lot of trouble down the road with the user base. As it is, its a feature I won't be using because my CC's don't support it.
Just my $0.02, and thanks for listening,
CJ
(By the way, we thank Apoc for providing such information to the community!)Apoc said:We intentionally did not add this into the core. CCs should be responsible for handling this [Editor: "this" means "waiting for the RezSick to time out"] (certain classes can still grind with res sickness, others can't). If the default CCs aren't handling this, then it's a valid issue.
First, this is not a flame. My primary interest is in keeping the development team focused on productive tasks, and away from whiney users.

The Problem
I've already bumped into the "my CCs don't wait for rezsick debuff" problem and had to turn off HB's "Spirit Rez" feature. My guess is that my reaction will be typical of the user community. The result is that the development team will have wasted a lot of effort on something that nobody will be using.
I think is going to cause the HB developers no end of questions and whining in the forums when people try to use it. It basically means we can't use the new feature unless the CC supports it.
A Better Solution?
Using the principle of symmetry, whatever software area is responsible for accepting the spirit res should be the one responsible for dealing with its consequences. If the CC accepted the spirit res, then fine, it can deal with it. If the HBcore did, then IMHO, its the HBcore responsible for dealing with it.
Could the HBcore not provide a default method in whatever class that CC's derive from, and arrange for the HBcore to ask the CC if its capable of proceeding with RezSick? The default answer would be 'no'. Given this answer, the HB core would wait for the debuff to expire before transferring control to whatever should happen normally. If the CC overrides the method then says 'sure, I can fight with rezsick', then the HB core could transfer control immediately.
What this does for the community and the developers--both HBcore and CC:
- No CCs need to be altered and the right thing will be done
- CCs that can handle it will take advantage of every second of botting time
- And most importantly...
It prevents a ton of questions in the forums, and faulty bug reports, and general moaning
I honestly believe that a little more time thinking about this problem will head off a lot of trouble down the road with the user base. As it is, its a feature I won't be using because my CC's don't support it.
Just my $0.02, and thanks for listening,
CJ