OOC Regen Enable/Disable

[ChaosSlayer]

Originally Posted by trevius

So, say your max level is 50, your scaling is currently set to 50%, and your OOC Regen is set to 20%. In this case, a level 1 would take exactly 30 seconds to regen from 0 to 100%, a level 25 would take exactly 45 seconds to regen from 0 to 100% and a level 50 would take exactly 1 minute to regen from 0 to 100. Now, say you upped your max level to 75, then you would just need to lower your scaling to compensate for that.
.

yes the this the excatly the recalculating problem I was poiting too - everytime I alter the max lev cap , I have to tune the other numbers to match with it. Given it won't happen very often but will happen eventualy in the long run (specialy on custom servers), and having to go back and rethink what the number should be with new effect kind of pains me. Thats why I propose than max lev cap is not made to be a part of the formula

But, by doing it this way, people with more mana and hps will have to wait longer than people with less

actualyl I see this as a positive side =) If you got yourself a large ass mana pool (more than the average for the level) - you don't get to regenerate it for free =)

And then you would have Items, AAs, Buffs etc all making that system a bit of a nightmare if they factored in

the regen items and buffs SHOULD NOT be part of OOC regen multypliers.
The OOC should be calculated by itself (based on level and/or total pool) and effects from items and buffs added in on top of that unmodified. (since they work In and Out of combat, its alreday a huge bonus to the player that he gets active in combat regen from them)

Either way, it seems like if you wanted a balanced perfectly scaling custom system, you would need to just build the whole thing manually in the source code.

hey my whole system is 2 lines long =)

as I propose before you have 2 Rule variable: Base and Growth.
The only thing you add in code is
Final regen = Final regen + (Base+level*Growth) =)

yes it does not been based on your total mana/hp pool, but I guess its just my view on this is diffirent =) I simply don't see a legit reason why say a lev 65 wizard with 5k mana should regain mana faster than another lev 65 wizard with 4k mana pool. (yes they regain at equal % rate BUT the actual ammount of mana gained per tick will be HIGHER for the guy with larger mana pool, which result in person with lots +mana also gets EXTRA free mana regen on top of that, which is IMHo unfair advatange. Large mana pool- simply means more mana, not more mana per tick)

and then when you start talking actual mob killing vs downtime- the guy with larger pool nto only has more mana during combat - he also has smaller downtime to regain same ammount of mana.

So if your rate is say 1% per tick.
Wizard with 4k pool will regain 2k mana in 5 minutes, whiel wizard with 5k pool will regain 2.5k mana in SAME 5 min. Now let say you need 2k mana to solo mob X. First wizard can solo mob X every 5 min, 2nd wizard can solo same mob every 5min AND get extra 500 mana on top of that, so over course of 25 min wizard B can solo an additional mob. NOT becuase he has superior regeneration (via buffs or items) but becuase he mana pool is larger, which IMHO is wrong.

This approach leads to that +mana items/buffs automaticly outweight +mana regen items/buffs, since the gain from % based OOC regen is MASSIVE compared to what +regen item/buffs can give you.
This will lead to players ONLY going after +mana(or +hp) items/buffs rather than +regen items/buffs, which usualy (if you take LIVE - MUCH rare and harder to obtain)

thats why I belive why OOC should not be based of your pool size

[trevius]

I can understand some of your points, but I think the benefits of one system would outweigh the other. And I really don't see much of a reason to have both systems that could ultimately be so similar.

If anyone knows how the system works on EQLive, maybe we should try to emulate that, since that is what the emulator team normally tries to shoot for. I know in games like WoW and others that I have played that have OOC Regen, they all appear to be % based as far as I can tell.

Downtime in games is probably one of the more annoying things out of anything. It has been reduced to a minimum in all modern MMOs and apparently even EQLive has it reduced now. There really is no positive side about making someone wait 20+ minutes for their mana to regen to 100%. You will notice that many custom server have CH and Regain Mana clickies on something like a 2 minute or so timer to remove the downtime from EQ. I think that makes a huge difference in the enjoyability of the game.

From what you are saying, it seems like you think that players with considerably better gear should get penalized for having that better gear. They get more downtime the better their gear is. Yes, they will regen more mana in the same amount of time as someone with lesser gear/manapool using my system, but their gear is much better, so why shouldn't they? You mentioned a scenario with a wizard that has better gear than another getting an extra kill more than the lesser geared one every now and then. Shouldn't that be how it works? Shouldn't casters with better gear be able to kill more then ones with lesser gear?

Using your system and increasing a base HP regen rate by a multiplier would mean that you are making all casters equal no matter how nice their gear is. Let say a wizard with 10k mana has 50 mana per tick from items/spells/buffs and natural regen. That means it would take them 200 ticks (20 minutes) to regen to full mana. So, if you want to get that to a reasonable timeframe, you would probably want to lower that to take 5 minutes max. So, to get 10k mana in 5 minutes you would need to have a bonus of 150 mana per tick + the 50 normal regen mentioned above to equal 200 per tick. Already, that 50 per regen from having good AAs, items, buffs is only making a minimal difference. The, factor in that a lesser wizard of the same level with 5k mana would still get at least 20 regen without even having great buffs/AAs/items to add more regen. So, even though the more powerful wizard has much better items and has spent much more time on their character, they only have a very small increase (15%) in OOC Regen per tick.

With your idea, these 10k and 5k mana wizards would both be almost equal. They would both have almost the same downtime to kill ratio. And in this case, the powerful wizard has 2X as nice gear as the other! The 10k wizard should be getting considerably more kills IMO.

The more you up that multiplier, the less important the other bonuses are from buffs/AAs/Gear in both systems. And in order to set what I would consider OOC regen, you would want it to increase HPs much faster than the base + bonuses, which means that no matter what, during non-combat the bonuses are going to be less important and not much of a factor in either system. The main point for having +bonuses for mana and regen when you have OOC Regen is for regen during fights. OOC Regen will basically take over when not in combat.

If 2 people group together, they should have the same downtime IMO. I wouldn't want one wizard with 5k mana to have to wait 2X as long for the other wizard with 10K mana that they are grouped with to get to full so they can start their next encounter. And, I wouldn't want a raid that is ready to fight to have to wait a few more minutes so their uber cleric can get to full even though everyone else is full already.

The main point of OOC Regen is to reduce downtime. There are no in combat benefits to having OOC Regen other than less time between fights. If a group is pulling steady pulls, I don't think they should have to stop for 20 minutes every few pulls so that the casters can regen. I also don't think that casters should be less useful in groups or raids than melee. By having a decent OOC Regen rate, it lets them maintain mana so they can help with every pull instead of doing a few pulls and then going AFK for 10 minutes while they regen.

As for adjusting the max level effecting OOC Regen, I think it is a very minimal issue if at all. If you really care about making sure that all levels remain the exact same regen rates and you have scaling enabled, then you can easily adjust the scale rule. But, in most cases, even custom servers aren't going to be increasing their max level by more than 5 or at most 10 at a time. If your server is jumping from level 50 max to level 100 max, then you got more issues than regen rates to worry about :P And, if they are only adding 5 levels, the difference for mid levels would be minimal and hardly noticeable. And, it isn't like you have to retune all mid level encounters because OOC Regen rates changed. It only effects out of combat, so it really doesn't matter.

You could easily write your code yourself and submit it to the server code submissions if you like. But again, I really don't see any reason to have more than 1 system for this. I imagine that most servers that would even use it would have it set so high that it wouldn't really matter how it was being done. I plan to try setting my OOC Regen rates at 10% per tick with a 50% scale, so a level 1 will regen to full in 1 minute max and a level 75 will regen to full in 2 minutes max.

Both systems would work to yield similar results. I don't see much of a point to draw out a big debate on the subject unless someone has some enlightening information that should point one way or another. My code is all done with the exception of 1 piece, so I am not going to rewrite it. I really only care to finish the code by figuring out how to check if the player is in combat or not.

[KLS]

You guys seriously talk too much, we'll put something in.

[trevius]

LOL, honestly it would probably take me all of 10 minutes to write the code that he wants and just add it to the code that I wrote so you can use either type of out of combat regen. But, since HPs are constantly being updated, I am concerned that the extra calculations for extra rules will just make more potential server performance impact. Ya, 2 extra rules and an equation probably isn't bad, but Chaos wants rules for every little thing lol :P They would start to add up quickly and take a toll on performance at some point. I have been looking into increasing server performance where possible, and adding 2 systems to do essentially the same thing is a bit redundant. As soon as I get this done, at least there will be a flexible option for OOC Regen. I don't know if there really needs to be 2 separate OOC Regen systems considering we made it this long without any. And if people don't like the one I made, we can always change it at any point. :P

Here is the post from this thread with the code that I have written so far:
http://www.eqemulator.net/forums/sho...98&postcount=8

It is all done beside getting the IsEngaged check to work to see if the player is in combat or not.

[ChaosSlayer]

Hehe KLS is right =)

Anyway, Trev,

Shouldn't casters with better gear be able to kill more then ones with lesser gear?

the word "gear" is too vague for this specific case. YES they should, but you need to be specific what gear you refering to:

If you playing a warrior- you can go for for STR to do more damage , kill enemies faster and take less dmg in the process OR go for AC items to get hit for less dmg to begin with, but then your fights will last longer since your DPS is lower. Each has pros and cons depending on specific encounters

Same thing happens when you look at the 2 wizards- one wizard went for +mana items while another went for +mana regen items.
The first wizard should have larger mana pool, while 2nd wizard should have faster mana recovery. The first wizard can put out far more spell dmg in combat before he runs OOM, while 2nd wizard can last longer while fight goes on for a while (liek a raid fight).

When you putting OOC regen on pool % bases - you bluring this diffirence in char gear customization away.

In either case - the debates help find the "golden middle"

[ChaosSlayer]

Oh Trev we forgeting one more- OOC Endurance Regeneration =)

[Congdar]

it seems the svn version no longer uses the hate list for clients unless they are charmed. it was probably part of the fix to the feign death bug. this means that IsEngaged() would only work on a charmed client or a npc