Help with Attack

[thepoetwarrior]

Also since updating from 1129 to current revision, some players appear to be bugged and unable to hit mobs, yet mobs hit them for full damage.

Does ChanceToHitDividedBy affect mob chance or player chance? Or both?

Any help with bugged chars. Its a few days now of tweaking with players complaining about the new source code making our server completely unplayable.

[trevius]

Just try replacing that line of code that I posted in the other thread. It keeps my melee running perfectly still. When that other change was put in, it wasn't done very well imo. I just don't have time to really do it the right way and test it enough and then adjust all of my content to be balanced again. One of the main issues is that the Evasive discipline is multiplied by 10 before it goes into the hitchance equation and I don't think they took that into account. So, if someone hits evasive, they get insanely high avoidance up to 100%. And, even if you adjust the rule for that part, the extra 10 multiplier on evasive causes avoidance stats to be unbalanced.

Really, the solution should be pretty simple in that we just remove the 10X multiplier on the spell effect for evasive. I see no reason for it to be there in the first place.

Really, unless you just replace that line that I posted, you will have to redo almost all of your content for it to be balanced again. Other than that, I would recommend leaving those other new hitchance rules at their default values. Ideally, the best way would be to actually adjust your content and play with the rules until they feel right. But, if you don't have the time to do that properly, simply replacing that one line will get things back to normal for you.

[KLS]

The reason we mult by 10 is so it's compatible with the item bonuses, which is clearly labeled in the comments right by it. You can either multiply it by 10 in the bonuses or in the combat code, either way it has to get done to combine them in one call but bonuses are called much less frequently than combat typically so it makes sense to put them in bonuses.

The problem was until recently it was divided by 100 instead of the 1250.. tho I'm not sure where the extra 250 is supposed to be coming from it should be 1000. So avoidance was 10x more powerful than it was supposed to be. Coupled with the fact that the hit chance calculation goes kinda low atm it's just a mess.

You take item avoidance where 10 = 1% and you take spell avoidance where 1 = 1%

Say you have capped avoidance at 100 and have evasive running at a 65% chance to be hit.

100 + (50 * 10)
100 + 500
600

65 - ((600 * 65) / 1000)
65 - (39000 / 1000)
65 - 39

26% chance to hit

That's how it should work but not how it was working which was more like:

100 + (50 * 10)
100 + 500
600

65 - ((600 * 65) / 100)
65 - (39000 / 100)
65 - 390

-325 < 5
5 % chance to hit

As to the original question: it will affect both but players are far more likely to have avoidance mods than npcs.

[thepoetwarrior]

I played with ChanceToHitDividedBy values, and most of the players were doing good, but a few players claimed they couldn't hit mobs when they could hit them before. I watched and verified. So finally I decided to use Trevius quick fix and changed

chancetohit -= ((bonus * chancetohit) / RuleI(Combat, ChanceToHitDivideBy));

to

chancetohit -= (bonus) / 10;

and now the users are very happy.

Would probably take a lot of work to re-balance the whole custom database. Thanks for the help guys.

[cavedude]

I played with ChanceToHitDividedBy values, and most of the players were doing good, but a few players claimed they couldn't hit mobs when they could hit them before. I watched and verified. So finally I decided to use Trevius quick fix and changed

chancetohit -= ((bonus * chancetohit) / RuleI(Combat, ChanceToHitDivideBy));

to

chancetohit -= (bonus) / 10;

and now the users are very happy.

Would probably take a lot of work to re-balance the whole custom database. Thanks for the help guys.


That's what I just changed, the value needs to be 1000, not 10. Lowering the number INCREASES the avoidance, so your players are lying to you. Let me guess the warriors have the most "problems" right? Yeah, that's because with your change their Evasion AA jumps from being a 50% increase in avoidance to a 5,000% increase for them :P

To-hit is off in the code, and has nothing at all to do with that. Though, I believe a fix for that is coming soon as well.

[thepoetwarrior]

I watched the players. Some players were fine, and some players were actually bugged. Wierd. But when I edited the 1 line of code, they were ok.

Yes, Warriors are upset over Evasion.

Will continue to look for updates and discussions on attack. Thanks for the info!

[cavedude]

Hey if it works for you, it works! :) But, keep an eye on Warrior evasion or try it out yourself. With your value, it will make player Warriors immune for the length of the ability.

[trevius]

Yeah, the new way the code is set is actually the way it should work. I just don't have time right now to go through and rebalance each of my end game encounters to the new formula, so I use the old one. As a fix for evasion with the old code, I just adjusted the spell so it doesn't give way too much. Warriors with Stonewall should really never, or very rarely ever need to use evasion. If they are, it means that things aren't working right. That was the reason for the new code, and it should correct that issue. But, at least changing 1 line of code for now is easy enough for us that may not have time to redo everything that has already been finely tuned. Ultimately, at some point, I would like to get things rebalanced to use the new proper system. Until then though, I will be using that old line to keep things as they are.

[thepoetwarrior]

What spell ID did you edit for Evasion and what did you edit to fix it in the spells_us.txt file? Im using spell editor from Georges website.

[thepoetwarrior]

Did my own home work real quick with the Spell Editor. A quick search/find in the spells_us.txt did the trick. Found out Evasive is Spell ID 4503. Only thing I saw of interest would be...

Effect Type: 172 Chance to Avoid Melee
Minimum: 50

So would edit that value of 50 to something else?

Maybe remove chance to Avoid Melee all together (Although that would be cruel).

If I fix that spell, then we can use the old calc you shared without Evasive making a Warrior perma immune?

Please advise. Thanks.

[ChaosSlayer]

you should be aware that in that that "rule fix" which broke the avoidance has been removed from the code and next version of the server build will be released wihout it - hence you don't need to fix anything on your side - simply wait till next release.

[cavedude]

No, the rule DID NOT break avoidance. Avoidance was broken from the start. It had a value of 100. I added the rule because I wasn't sure of the Live value. I set the rule default to 1250, turns out it should have been 1000. So, the rule was much closer to Live than it was previously... Besides, it was a rule meaning you could have changed the value to match your server.

But, your advice to them is flawed. They mention above that they are using altered combat code where the value of 100 (or 10, whatever they use) is correct for them. That means by removing the rule I am again forcing them to manually change the line to match their code. It has to be done because as KLS said the rule never should have been added. The value is 1000, no need to change it in stock EQEmu code.

[trevius]

Yeah, Hunter, that is the setting you need to change. I think something like 5 instead of 50 would work fine.

As I have said already, the new code is the correct way things should be done. But, even with the rule that was there before, you couldn't get the same results as you do by pasting in the original formula that was used. This is because the new one actually reduces hit chance for avoidance by a percentage instead of subtracting a flat amount like it used to. Subtracting a flat amount is a really bad way to do it, but for databases that were built around using that formula for avoidance, it works and would be a pain to switch over. At some point, I definitely want to do the switch to the new way, but I am hoping to wait until hitchance is tweaked and finalized enough so it doesn't have to be done again and again as it is a pretty major headache and nearly impossible to get encounters feeling the same as they did before.

[KLS]

I'm adding some new hit chance stuff soon, it's getting there but not quite there. This new hit chance feels better than the old one but I'm still not convinced it's perfect by any means.

[trevius]

Any idea what these rules would need to be set to to make it almost exactly the way it was before this new change? If I put this in without the option to keep things how they currently are on my server, Kayen (my main GM) is gonna kill me!

Unless these changes are completely final and most likely won't be changed for a very long time, it will be extremely tough to justify rebalancing all end-game content around this. I am not worried about low to even high level content because those won't see a huge impact, but for a few of our high tier zones, each boss encounter has been tuned to be an extremely tough fight. By changing melee this much, it is sure to require tuning each one individually and watching players over and over until they are perfect again. That is the whole reason that I replace the hitchance bonus line each time, because it would have caused a headache to fix it no matter what.

INSERT INTO `rule_values` VALUES (0, 'Combat:BaseHitChance', 69);
INSERT INTO `rule_values` VALUES (0, 'Combat:AgiHitFactor', 0.01);
INSERT INTO `rule_values` VALUES (0, 'EventLog:RecordSellToMerchant', 'false');
INSERT INTO `rule_values` VALUES (0, 'Combat:HitFalloffMinor', 5.0)
INSERT INTO `rule_values` VALUES (0, 'Combat:HitFalloffModerate', 7.0)
INSERT INTO `rule_values` VALUES (0, 'Combat:HitFalloffMajor', 50.0)
INSERT INTO `rule_values` VALUES (0, 'Combat:HitBonusPerLevel', 0.4)
INSERT INTO `rule_values` VALUES (0, 'Combat:WeaponSkillFalloff', 0.33)
INSERT INTO `rule_values` VALUES (0, 'Combat:ArcheryHitPenalty', 0.25)
INSERT INTO `rule_values` VALUES (0, 'Combat:MeleeHitChanceMod', 1.0)
INSERT INTO `rule_values` VALUES (0, 'Combat:PriestHitChanceMod', 0.85)
INSERT INTO `rule_values` VALUES (0, 'Combat:CasterHitChanceMod', 0.7)
INSERT INTO `rule_values` VALUES (0, 'Combat:HeavyAvoidChanceMod', 1.0)
INSERT INTO `rule_values` VALUES (0, 'Combat:ModerateAvoidChanceMod', 0.96)
INSERT INTO `rule_values` VALUES (0, 'Combat:LightAvoidChanceMod', 0.91)
INSERT INTO `rule_values` VALUES (0, 'Combat:UnarmoredAvoidChanceMod', 0.86)


I am not trying to complain about this. I know for sure that combat needed improvements and that some formulas had just been done the wrong way from the start. As long as the changes can be somehow set to work nearly identical to how they used to, it isn't a problem at all. The main issue I have is that I can't avoid putting this update on my server lol. I can't even really delay it. With all of the work I have been doing on SoF, it means updates to the Storm Haven server code almost daily directly from the SVN. Also, since SoF has kept me so busy and will for a while to come, it makes it very hard for me to find time to even make an attempt at rebalancing all end-game content. I am just hoping that there is a good solution for this. I don't think I can manually switch all of those changes back each time I update, lol. If there isn't a good solution, I may have to add in some defines to let people easily define which combat system to use, old or new with new being default. At least as long as that change (adding defines) is ok with the other devs.

Like I said, sorry if this seems like a whine. I don't want it to be, but I am sure I will hear it 10 fold from my players and GM if I let this go through as-is right now.

[ChaosSlayer]

thats why I said many times - dear devs please make a COMPLITE wiki about ALL rules you introducing into a code and IN DETAIL explanation how they work and what do these values mean and HOW they affect the server IN DETAIL with IN DEPTH examples

Most these rules Trev listed never even appeared in the changelog file... How I even supose to know what rules are there, much less what set them to?

[KLS]

It should be fairly similar to how it was for raid mobs, you may want to bump the base chance to hit down a notch is the only thing I can think of as I bumped it up a bit. Perhaps set the archery thing to 0.0 also.

Oh and the agil factor was 0.015.

[thepoetwarrior]

Sourced in the combat SQL's and updated source code to Rev361 etc, players not getting hit enough again.

Tried Trev's edit of attack code and still same.

Blah

[ChaosSlayer]

did you tried rising COmbat Hit Chance in rules? - I belive default is 54, make it 65

[thepoetwarrior]

I rolled back my version to a few days ago. Looks like that was not working too, but not as bad as the new code with new sourced SQL. Anyways, I did

UPDATE npc_types SET accuracy = 3000;

as a temp fix and seems to work. Lost 4 hours of sleep for work tonight already, will hammer at this issue again on Saturday, my day off.

Thanks for the responses.

[trevius]

I have spoken with a few admins who are a bit hesitant to update their source for a while with this new change in it. I am sure that the new rules and formulas can be adjusted to make a standard PEQ DB install feel much more live-like. But, many admins of custom servers may just not have the time to rebalance all of the balanced custom content on their servers, myself included. I would definitely like to do it at some point, but just don't have the time atm.

KLS, do you think it would be ok if I put a #define in the attack.cpp that will by default be set to use the new system, but will also allow a simple change to enable the old chancetohit code? The define could be removed later at some point, but for now it should be able to save some potential headaches. If you think that isn't a good idea, then I am sure we can all deal with it as time sees fit. I just don't have much time for that right now and can't hold back on doing updates on my server almost daily.

[ChaosSlayer]

Shoudn't Combat Hit Chance affect hit ratio for both players and mobs?

[trevius]

Shoudn't Combat Hit Chance affect hit ratio for both players and mobs?

Yes, it does.

[KLS]

Honestly, I wish people would try it instead of complaining about trying it. I realize some people are busy coding SoF but some people are not busy and would rather complain about it I'm sure. I can't really put off changes to the server that make it better and more accurate just because it inconveniences people.

Really if you bump the rules I said to where I said to bump them you shouldn't really notice a difference against anything but low blue and light blue npcs.

Also, when people have problems with how things are done I really wish they'd just say so instead of sneaking around my back about it. I'm not some mean ogre that's going to eat your bones if you disagree with me. =(

All that said if you want a define for now go for it, but I expect it to be completely finalized within a few weeks and anyone who doesn't take their chance to complain about it in this time pretty much is screwed. =p

[trevius]

I didn't mean to upset you with my post. I was kinda afraid that might happen though. It isn't that people are talking about you behind your back or anything. I just speak with a few other admins that normally don't voice themselves on these forums too often.

You are right that I should try it before I complain about it :) My main concern was that more changes may be on the way and it sounds like that is the case. I can handle redoing content where needed once, but not multiple times if more changes will be going through. If possible, it would be nice to have just 1 big change to deal with that will hopefully be finalized for a year or so. That is another reason I think a #define would be nice. Cause it would let the new code get in and be usable, but would also give an option to let admins hold off until it has been fully tested and has been finalized for a while. Maybe just leaving a define in for a month after the last change is done to make sure there isn't anything else that needs to get changed right after. Once things are definitely final, it would be a good idea to just remove the define(s) and make it the new standard. I don't have a problem with doing it that way at all if that is ok with you.

Hopefully by making the define set to use the new system as the default, enough servers will try the new system to fully test it before it is finalized. There really aren't a ton of servers that use the source to even have the option to change the define anyway, so most Windows servers will be testing it if they update.

I don't mean to be complaining about this and I know your changes are good for the emulator, so I am sorry about having to even bring this up. I just figured a #define would make a nice temporary solution for this while the new combat changes are being finalized. Though, I admit that alot of the reasoning for me posting about it is just because it would be a fairly big inconvenience for me right now lol.

I just don't have the hours it would take to parse current fights and compare them with post-hitchance change fights. Hopefully by the time your changes are all finalized and have been proven for a month, SoF will be mostly done and I won't be having to update my server daily, and I will have more time to work on rebalancing content where needed. When I put these changes on Storm Haven, I would like to use the new hitchance values so players and NPCs hit more often. That will mean adjusting mob HPs/AC and probably min/max hit and attack and accuracy ratings at least.

We know you aren't a big mean ogre! More like a nice quite little woodelf :)

[KLS]

Yeah one big change would be nice butttttt... this stuff requires play testing which requires me to put it out there. There's only so many situations I can test myself and I can't sit here and log hours of combat experience at every level to see if it feels right.

[Secrets]

I agree with the define option, though I would rather see rules to define them instead of defines. That way rules can be set for Win32 pre-compiled servers and ServerOPs are not in a mess if they use precompiled code. I personally had to remove it on Raid Addicts when I helped them upgrade it, simply because all the existing content was balanced torwards the previous combat changes. When you have a level cap above 75, things get wonky with the code (and in general!) and stuff messes up. Not everyone uses PEQ as their database either. I would MUCH rather see a rule for the new combat changes, while still keeping in the old combat changes as a separate rule.

I use the combat changes on my own personal server and they work great; though, I balanced my server around PoTimeB-level of characters. I had to tweak a few things, but in the end they worked out great. I think a lot of the issue is ServerOPs tweak NPC stats without looking at the formulas and end up having overpowered players & NPCs. When you make both overpowered and the only thing that is stopping them is HP, that's when it gets a bit hard to balance with new combat changes. Sure, the combat changes are great, I just don't think they are for every server out there, especially people who throw stats on NPCs at random, or tweak the cap on stats, etc.

I'll see if I can get this coded later, it should be fairly easy to implement. Whether you want it is up to you.

[Secrets]

I agree with the define option, though I would rather see rules to define them instead of defines. That way rules can be set for Win32 pre-compiled servers and ServerOPs are not in a mess if they use precompiled code. I personally had to remove it on Raid Addicts when I helped them upgrade it, simply because all the existing content was balanced torwards the previous combat changes. When you have a level cap above 75, things get wonky with the code (and in general!) and stuff messes up. Not everyone uses PEQ as their database either. I would MUCH rather see a rule for the new combat changes, while still keeping in the old combat changes as a separate rule.

I use the combat changes on my own personal server and they work great; though, I balanced my server around PoTimeB-level of characters. I had to tweak a few things, but in the end they worked out great. I think a lot of the issue is ServerOPs tweak NPC stats without looking at the formulas and end up having overpowered players & NPCs. When you make both overpowered and the only thing that is stopping them is HP, that's when it gets a bit hard to balance with new combat changes. Sure, the combat changes are great, I just don't think they are for every server out there, especially people who throw stats on NPCs at random, or tweak the cap on stats, etc.

I'll see if I can get this coded later, it should be fairly easy to implement. Whether you want it is up to you.

Under further investigation, I think we need a define for this. Would basically have to copy the whole code twice to get a rule to work, heh, unless the way it was handled was reworked.

The only problem I see in a define is for novice server ops to 1) compile, and 2) get the correct rule_values set for combat depending on what they use. I sure didn't know what the heck to do when I first started. But typically most ServerOPs I see starting out use PEQ anyway, so it's not that bad in the end. More experienced ServerOPs should know how to look at svn revisions and remove the code if they balanced it around the old code.

So, I guess we're kind of in a mess here. :<

[KLS]

Any define would only last a short while anyway, eventually I would take it out and then anyone who wants to use custom code would have to do what they always do, keep track and patch it in.

[trevius]

Yeah, I think the only thing that can even justify a define is that the combat changes aren't finalized yet. So, server admins might have to adjust their content multiple times while things get all tweaked. The define would just let them avoid the adjustments until everything is finalized. It would only be temporary. We can't have defines and rules to keep every original formula, otherwise the code would be quite a mess.

For most of the experienced server admins that have been running a server long enough to actually have to do some work to adjust their content, it shouldn't be too hard for them to figure out how to compile it if they have to. And, if that is too much for them, they can always wait out doing an update to their code until everything is finished.

For the new servers, these changes won't even be noticeable, as their content will be made around the new settings and they or their players won't ever be the wiser.

It is always a pain when something major changes. But, without change, nothing would ever get better. I am sure many of you remember when the new AC changes went in about a year ago and then Attack Rating and Accuracy for NPCs. Those were some big ones, but they have been a big help in making combat feel right. I am sure the latest changes will help hit chance considerably. Really, hit chance has been horrible in the past and it is nice for it to finally be getting a good fix and more options for tweaking it. Maybe 2 handed weapons will actually be a valid choice over 1 handed again :)

I will try to get the define in tonight. I think a temporary define is a good solution. Admins will still have to make changes after it is removed for good, but at least they will only have to make the changes 1 time only (for a while again anyway).

[Secrets]

Yeah, I think the only thing that can even justify a define is that the combat changes aren't finalized yet. So, server admins might have to adjust their content multiple times while things get all tweaked. The define would just let them avoid the adjustments until everything is finalized. It would only be temporary. We can't have defines and rules to keep every original formula, otherwise the code would be quite a mess.

For most of the experienced server admins that have been running a server long enough to actually have to do some work to adjust their content, it shouldn't be too hard for them to figure out how to compile it if they have to. And, if that is too much for them, they can always wait out doing an update to their code until everything is finished.

For the new servers, these changes won't even be noticeable, as their content will be made around the new settings and they or their players won't ever be the wiser.

It is always a pain when something major changes. But, without change, nothing would ever get better. I am sure many of you remember when the new AC changes went in about a year ago and then Attack Rating and Accuracy for NPCs. Those were some big ones, but they have been a big help in making combat feel right. I am sure the latest changes will help hit chance considerably. Really, hit chance has been horrible in the past and it is nice for it to finally be getting a good fix and more options for tweaking it. Maybe 2 handed weapons will actually be a valid choice over 1 handed again :)

I will try to get the define in tonight. I think a temporary define is a good solution. Admins will still have to make changes after it is removed for good, but at least they will only have to make the changes 1 time only (for a while again anyway).

Yeah, I think this is a fair compromise. I'm all for a temp define, especially if it gets removed when everything is all done and over. I personally would like to see less hardcoded values and more rules -- which the combat changes are starting to do. I like that.

[trevius]

BTW, ChaosSlayer, while we don't exactly have a wiki page or anything that describes each rule in great detail and shows every formula, you can still find out alot of info on most of them directly from the source code.

The rules are stored in /common/ruletypes.h and many of them have comments next to them to explain them a bit.

Here is a link to the ruletypes.h from R358 as an example:
http://code.google.com/p/projecteqemu/source/browse/trunk/EQEmuServer/common/ruletypes.h?spec=svn358&r=358

[KLS]

I'm adding more rules if you've noticed. And I really have a choice, add more rules or make huge pages explaining them, I choose the former. Most of them are pretty easy to understand and if anyone ever has a question I'll be glad to answer it and hopefully someone observing keeps the wiki up to date.

[ChaosSlayer]

yeah I just discovered ruletypes.h today =P Never saw them mentioned before. Last time I picked into the soruce was a while ago and since then thigns changes so much I can't make heads or tails of it anymore =P

So its helpfull however few of the rules stil could use few clarification on exactly how they work. I mean its one thign for me to sit and read these short sentences over and over till I figure out what they mean while for person who created the rule its clear as day =P

Atm I am trying to udnerstand these few - perhaps you could explain me better:

RULE_REAL ( Combat, HitFalloffMinor, 5.0) //hit will fall off up to 5% over the initial level range
RULE_REAL ( Combat, HitFalloffModerate, 7.0) //hit will fall off up to 7% over the three levels after the initial level range
RULE_REAL ( Combat, HitFalloffMajor, 50.0) //hit will fall off sharply if we're outside the minor and moderate range


What is a FALL OF??? :? I See that its... SCALES.. but whats it do? =) And is difirence betwin minor, major etc.


ANother question:

RULE_REAL ( Combat, WeaponSkillFalloff, 0.33) //For every weapon skill point that's not maxed you lose this % of hit


-ok what it does well epxlained but curious quetsion: won't this mean that the MOMENT you level your performance sudenly become WORSE? Basicly you some lev 55 with X max skill, you ding 56 - and you swing your sword now worse than 5 sec ago vs same mobs


Next one:


RULE_REAL ( Combat, HeavyAvoidChanceMod, 1.0) //plate wearers
RULE_REAL ( Combat, ModerateAvoidChanceMod, 0.96) //chain + leather melee
RULE_REAL ( Combat, LightAvoidChanceMod, 0.91) //druid
RULE_REAL ( Combat, UnarmoredAvoidChanceMod, 0.86) //rest


Shouldn't classes who use HEAVIER armor- have WORSE avoidance chance??? (I knwo I can adjust them in reverse but just asking) After all its much easier to dodge while wearing NOTHING rather than full plate. (mitigation on other hand should get better the heavier the armor).
On other hand - this thing seem to be tied to a CLASS rather than - what player is wearing atm (which creates an issue where clumsy Paladin wearing full plate can avoid better than a Monk or Ranger???). IMHO - rather than do this by pre-made type - do this by INDIVIDUAL classes. So warriors AVoidChanceMod, Paly, Sk and so on.


same thing with :

RULE_REAL ( Combat, MeleeHitChanceMod, 1.0)
RULE_REAL ( Combat, PriestHitChanceMod, 0.85)
RULE_REAL ( Combat, CasterHitChanceMod, 0.7)


I would not put monks/rogues into same group as clumsy palies/sk (in some specific case I can go as far as say than druids far more agile and dexterioes than say clerics and so on) - So perhaps again- separate Mod for each class? That would be nice for extrime fine-tunning. :cool:



And finaly. New price system: most of them easy enouhg to udnerstand, few a bit unclear:

RULE_INT ( Merchant, PriceBonusPct, 4) // Determines maximum price bonus from having good faction/CHA. Value is a percent.

---mmmm example please?

RULE_INT ( Merchant, PricePenaltyPct, 4) // Determines maximum price penalty from having bad faction/CHA. Value is a percent.

---mmm?

RULE_REAL( Merchant, ChaBonusMod, 3.45) // Determines CHA cap, from 104 CHA. 3.45 is 132 CHA at apprehensive. 0.34 is 400 CHA at apprehensive.

----mmm a bit more details please, not realy folowing... =(

RULE_REAL ( Merchant, ChaPenaltyMod, 1.52) // Determines CHA bottom, up to 102 CHA. 1.52 is 37 CHA at apprehensive. 0.98 is 0 CHA at apprehensive.

---same as above...

[KLS]

Mmm well I'll answer the ones that pertain to me as I haven't looked at CD's stuff yet.

Basically there's 3 levels of hit falloff: minor moderate and major. Minor is inside the level range of the defender which I believe is (level / 4) + 3 or something close to that. Basically what this minor rule says is over those levels you will lose up to 5% hit.

Then there's moderate which is the three levels over the minor range so (level / 4) + 6, what this says is if we're in this range we then lose the 5% hit from minor then 7% hit over those 3 levels.

Then the major is just some factor for the falloff past that which as you can see jumps in a huge way. I believe it works out to 50% for every 12 levels outside of the moderate range.

So for a level 48 spider: they can hit a level 63 before they start getting the 2nd level of falloff and can hit a 66 before they really start getting major fall off.

Hopefully you understood that! The weapon skill is a lot easier.

Say you have 100 weapon skill and your maximum at this level is 180:
180-100 = 80 * 0.33 = 26.3% hit lost from your main calculation. And yes it does mean a situation like that can happen but it's small enough that it's not likely to be noticeable except over long periods of time where your weapon skill would max out anyway.

From a purely logical standpoint yes those in plate would dodge more but from a gameplay standpoint I'm not sure I want those warrior tanks breaking down my door just... you can have them if you'd like. =p

A separate mod for each class is doable, it just wasn't something I was willing to invest the time in at that time though. I'll see about changing it up.

[trevius]

Rules are great, but too many could be a bad thing IMO. I dunno if we really need 16 new rules just to set individual class settings. If we did that, then we might as well do 16 individual rules for all formulas lol. I think it would just get out of hand quickly. I don't even thing live takes armor type or class into the calculation at all. It should all be based on Skill, AC and other stats IIRC. So, the fact that the emulator even has that option for customizing is pretty cool :)

[ChaosSlayer]

Thank you for reply KLS!

Yes I understand the Fallof now, thanks.

As far as avoids go - well logicly its should be a trade off:

heavy tanks are easy to hit - but they mitigate dmg down
vs
light classes (say monks) - much harder to hit - but their mitigation very very small

So in practice it would turn out into something like this (abstract numbers):

A mob swings 100 times 100 dmg each swing.
A warrior will get hit all 100 times (cuase he can't dodge), but he will mitigate the dmg by say 50%
A monk will only get hit 50 times, but he takes full dmg from each swing

So tanks mitigate, while monks dodge. Now depending on how hard and how fast given mob hits - in a specific situation some mobs wuld be more chalanging for warriors while others would be more chalanging for monks (and all classes in betwin accordingly)

Thats kind of combat logic that would make sence to me (of course with per class rule - each server dev can put in his own numbers)


As far as SKill max out goes - I understand that you trying to do with it , but it just feels kind of in reverse - instead of giving player To Hit BONUS for having higher skill, you penalizing them with to hit PENALTY for not having one. On one hand it does sounds like it the same thing, but in practice- as you noticed yourself it has this silly adverse sideffect that your get penalized not because your skill too low but becuase you just dinged and your cap has increased, cretaing this weird effect with feeling "leveling BAD" :cool:

I know I can use this rule to set it to 0 and forget about it but just thinking of alternative solution

Perhaps it would be more logical if you would start from skill of 0 and lower initial To Hit base (again we have it now nicely controlled via a Rule- thank you very much), and then give bonus based on actual skill , not basing it on the fact if ist maxed for the level or not. This way weapon skill will DIRECTLY contribute to your hit chance. (if person has 183 in 1hs - then he gets bonus from 183 in 1hs, regardless what level he is or what his curent max cap)

So let say:

Base Hit CHance: 50%
To Hit bonus from Skill: +1% per say 25 skill (abstract number)
so with 250 weapon skill - you have +10%

logicly this can grow unlimitly but on other hand- mobs avodance and dodge should also be growing. So even if players has +150% to hit chance, but mob has 75% chance to avoid - thats 150-75=75 only leave actual 75% chance to hit the mob (again abstract numbers)

I know you guys have coded hit and miss WAY diffirently, it just I had I am coming from extensive background of running number of custom developed table top combat games, but unlimited To Hit and To Dodge growth substracted from each other seems like most straight forward appraoch I can think of.


Trev


Rules are great, but too many could be a bad thing IMO. I dunno if we really need 16 new rules just to set individual class settings. If we did that, then we might as well do 16 individual rules for all formulas lol. I think it would just get out of hand quickly. I don't even thing live takes armor type or class into the calculation at all. It should all be based on Skill, AC and other stats IIRC. So, the fact that the emulator even has that option for customizing is pretty cool


Oh no-no. Not offering to do this by "the armor you wearing" - they tried that in eq2 once- the result was that Warriors started showing up to the raid in CLOTH cuase their AC was maxed out anyway and they were reciving +60% dodge bonsu from wearing "very light" armor type =)
BUT I still thing that the clas groups should be a bit diffirent (monks should have one hellova better avoidance than anyone else, followed by chain melees, and only then plates)

[cavedude]

As for the merchant system:

The first two are really easy. Depending on your faction and charisma, you will get better or worse prices from NPC merchants. Those values specify exactly how high or low that can be. So, the default setting is 4% for both. That means that with maxed CHA/faction you will get a 4% discount on wares, and on the flip side extreme bad CHA/faction will get you a 4% markup on wares. The reverse is also true, this value will also effect how much you will get by selling to a NPC by the same percentage.

A cloth cap has a price of 200 in the db so:

Base price: 2g
NPC sell price (1.05 modifier): 2g 1s
NPC buy price (0.95 modifier): 1g 9s
NPC sell price w/max CHA @ 4%: 2g 0s 2c (we always round up)
NPC buy price w/max CHA @ 4%: 1g 9s 1c
NPC sell price w/bottom CHA @ 4%: 2g 1s 8c
NPC buy price w/bottom CHA @ 4%: 1g 8s 2c

Be careful about using these values! If you set the bonus percentage too high, you'll get into a situation where you can sell for more than you buy. The rule to avoid this is take your two modifiers (in this case 1.05 and 0.95) and subtract them. Take half of that, .05 . You want the bonus percentage to be LESS (NOT equal) than that value, so 4% converted to a decimal is .04 and is indeed less, so in this example you can never buy for more than you sell.

The next two rules are a bit more tricky to explain and I debated even adding them, but for the sake of custom servers I decided to do it. Basically, they control your Charisma caps. Meaning, at a certain Charisma you will max out the bonus percentage and adding more charisma will no longer lower prices for you. The default bonus value of 3.45 will cap you at 104 with indifferent faction, and 132 with apprehensive. Lowering that number to 0.34 will cap your charisma at 400 apprehensive. You should not need to plug in a lower value than that, although you can if you never want players to cap.

The penalty value controls your bottom cap. 1.52 is 37 (lowest possible base CHA) meaning that even if you get hit with a CHA debuff, merchants will not raise their prices any more for you. If you want to lower the bottom cap to 0 CHA, the value would be 0.98. Since it scales that would mean at 0 that even players with 37 starting CHA would have a leg up price wise, and only could get worse prices if they got hit by a CHA debuff.

Players will always see base prices (with the modifier of course) at 103 CHA with Apprehensive faction, or 76 CHA with Indifferent or higher faction. Above those numbers they get a bonus, below a penalty. This is hardcoded and cannot be changed without modifying the code, and also breaking the rules ;)

[ChaosSlayer]

Just wanted to add that Trev is right

It should all be based on Skill, AC and other stats

we allready have all 16 classes fine tune system - in the class skill table in DB! =)

If we set warrior to one cap per level in say Defensive, and monk to another- then the server should NOT even care what class player is - it will look at players current Defensive skill and calculate accordingly.

The only thing thats always bugged me is why we have weapon skill AND offensive? By default they both contribute to same thing - ATK - so whats the difirence?
Unless we make one of then resposible for ATk only (ofensive) and weapon skill for To Hit chance

then you have nice layout of:

Offesive (atk) vs Defensive (AC) = dmg done
Weapon Skill (to hit) vs Dodge (avoid) = final chance to hit

Of course I have no idea how you guys actualy coded it - so all my assumption can be very very flawed :D

[trevius]

Ok, I just got the defines added into attack.cpp. They seem to work fine though I had a small issue with the first commit because I didn't realize that some rules had changed or been removed. I had to add the old level diff rule back in for now and I also made a second rule for the agi bonus for when using the define in place of the new agi rule bonus settings.

To use the old system, simply edit /zone/attack.cpp and uncomment the define(s) near the top of the file. There are 2 different defines. One is for reverting the most current chancetohit changes and the other is for reverting to the very old avoidance bonus formula.

Both of those defines and related rules will be removed when the new chancetohit is all definitely completed and maybe tested for a month or something. I think this will also give people a little more time to fit getting their content balanced again in whenever they want to do it, at least within a reasonable amount of time.

Lemme know if there are any questions or issues about the new defines. They should be good and are pretty straight forward. Before anyone asks; yes, you have to compile the source code yourself in order to set these defines.

[ChaosSlayer]

Cavedude, ok I see now, but somehow I invisioned this to be soemwhat simpler =)

ChaSell: 0.04 - the % modifier you get per 1 point of CHA when npc selling to you (discount) (so for each 25 cha you get 1% discount of base sell price)

ChaBuy: 0.04 - the % % modifier you get per 1 point of CHA when npc buying from you (so for each 25 cha you get 1% better price above base buy price)

ChaMax (integer): 400 - the point at which having even more CHA no longer benefits you
ChaMin (integer): -50 - the point at which having even less CHA no longer penalizes you

Merhcant mark up - is no longer needed at all - since you have Sellrate specified on items which automaticly becomes the mark up price, or unless you want this as optional "affect all items" rule:

MerchantMarkUp: 200 (if item is priced at 1 plat, then merhcnat by default sell it 200% mark up - which is 2 plat)


ANother thing which is still missing: is price scaling by faction

[cavedude]

More simple for you would be much harder for me! :P

The problem with the first two rules is it would be really easy for a Server OP to get to a point where their players sell for more than they buy, so they would have an unlimited ATM. With my rules, I can clearly define and say, if you do this, then you will go over.

ChaMax and Min I agree with, but that would require a whole new rewrite. Perhaps one day...

Merchant markup is still required for two reasons. 1. sellrate for most items is 1, and 2. the NPC sell modifier on live is 1.05.

I wanted to include a way to actually scale against faction, but I got lazy and didn't go ahead and do it. It would only benefit custom servers anyhow, since on Live the only two factions that matter are apprehensive and indifferent and it doesn't scale. In our system faction is still important. For example, a player with 37 CHA and indifferent faction will not get the worst prices. They need apprehensive faction for that. Overall, faction is weighted a tiny bit less than CHA in our setup.

I think my point was to get us Live Like, but still offer some rules for custom servers. I spent a day on Live before KLS found me a gem of a page discussing how the pricing works, with actual caps and numbers. I then spent another day on Live confirming the data on that page, and found it was still very accurate. So, the default rule values are as close to Live as we can be.

[ChaosSlayer]

well given even my appraoch to the rule system- I am sure there values you can put it to give you exact to Live match up - by defining boundaries of CHA and CHA per point scaling.

It just my appraoch is much esier to read on the user side :D

well perhaps one day =P (preferably sooner than later :D )

[ChaosSlayerZ]

Sorry for bumping this one, but:

Cavedude: excatly HOW you derive "1.52" from 37 CHA ?

and 0.34 from 400 CHA?

whats the formula?



KLS:

I was hoping to continue discussion on Avoidance and Hit chance Rules given by entire group of classes (heavy, Light etc)

Do they realy work for anyone? The way I see (the way classes are assigned to the groups) they create more restriction than freedom (see my prevous comments) I endded up setting everyone to 1.0 since I could not find a reason to justify why paladin can dodge as well as monk =)

I serously sugest you scrap the current 4 types approach and do them by class - then we can REALY customize.


And once again on To HIt chance- again doing it by gruop types is bad, cuase it forces number of classes into a single pattern. And what is realy important these Hit Bonuses feel artificial.

Yes I know that on LIVE Hit Chance is not realy based of anything, but if you realy wish to give a useful customization rule, why not a make a diffirent (set OFF by default) to use appraoch I described before:



Perhaps it would be more logical if you would start from skill of 0 and lower initial To Hit base (again we have it now nicely controlled via a Rule- thank you very much), and then give bonus based on actual skill , not basing it on the fact if ist maxed for the level or not. This way weapon skill will DIRECTLY contribute to your hit chance. (if person has 183 in 1hs - then he gets bonus from 183 in 1hs, regardless what level he is or what his curent max cap)

we allready have all 16 classes fine tune system - in the class skill table in DB! =)

If we set warrior to one cap per level in say Defensive, and monk to another- then the server should NOT even care what class player is - it will look at players current Defensive skill and calculate accordingly.

The only thing thats always bugged me is why we have weapon skill AND offensive? By default they both contribute to same thing - ATK - so whats the difirence?
Unless we make one of then resposible for ATk only (ofensive) and weapon skill for To Hit chance

then you have nice layout of:

Offesive (atk) vs Defensive (AC) = dmg done
Weapon Skill (to hit) vs Dodge (avoid) = final chance to hit

So let say:

Base Hit CHance: 50%
To Hit bonus from Skill: +1% per say 25 skill (abstract number)
so with 250 weapon skill - you have +10%

logicly this can grow unlimitly but on other hand- mobs avodance and dodge should also be growing. So even if players has +150% to hit chance, but mob has 75% chance to avoid - thats 150-75=75 only leave actual 75% chance to hit the mob (again abstract numbers)





or alternativly let us have a Rule where DEX contributes to Hit CHance (off by default) - this way players other than rangers will seek to build it up

[KLS]

I took that out actually, a person's ability to tank is not completely based off their defensive skill and gear. When I implement softcaps it should help to further differentiate classes by tanking ability, but for now there are no artificial blocks in place other than what gear you can wear and AAs you can get.

Why I took it out? I agreed with you it was a bad way to do it =p

[ChaosSlayerZ]

bah you telling me those rules don't even exist anymore? - someone should bothered to write that into changelog file =P

OK ok I am with you - lets do it logicly =)

I will be patient. But consider what I have said about Weapon Skill and Offense been redundant and both producing only ATK bonuses, and about DEX :cool:

[Capheus]

I'm not sure what direction this is going or who's doing what or whatever. As I am hearing on my server (EQ World), monks can't hit the broadside of barn, they are complaining the most. Nobody else is complaining. Using 1129Rev535 that I put in place on Monday the 25th. Hopefully this gives some direction on what has been changed and what is being seen. I don't have hard numbers but there is a very noticeable difference.

I am reluctant to go into the attack.cpp and change numbers that will affect everyone. If I have time I'll try to get numbers. Will be tough while I sort out the bugs with the new build and the content I added.