Help with Attack - Page 2

ChaosSlayer · #16 02-24-2009, 12:35 AM

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** · #17 02-24-2009, 01:28 AM

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 · #18 02-25-2009, 04:17 PM

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 · #19 02-25-2009, 04:57 PM

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

thepoetwarrior · #20 02-25-2009, 05:17 PM

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** · #21 02-25-2009, 05:37 PM

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 · #22 02-25-2009, 06:17 PM

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

**trevius** · #23 02-25-2009, 06:20 PM

Quote:

Originally Posted by ChaosSlayer

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

Yes, it does.

**KLS** · #24 02-25-2009, 07:03 PM

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** · #25 02-25-2009, 07:37 PM

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** · #26 02-25-2009, 08:43 PM

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 · #27 02-25-2009, 10:16 PM

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 · #28 02-25-2009, 11:09 PM

Quote:

Originally Posted by 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** · #29 02-25-2009, 11:18 PM

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** · #30 02-25-2009, 11:59 PM

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).