dannuic

Okay, I was just wondering why this was in here. But it will still always enqueue a second attack, which is not desirable.

Sorry, I didn't follow that at first. fix the tabbing, it's hard to read.

No, I said a constant array of strings, not an array of constants for this situation. This is very hacky, which is why it's not a good fix. Which buff has a skillmod of melee_defense that should go above the cap?

This would cause AI to always attack a second time. Before, they would only attack twice in one round if the second attack was a special. I also don't see how this affects a % chance of choosing attacks?

private_defense is not already getting added generically? It should be affecting all defenses, there shouldn't be a reason to break it out to the individual primary defenses.

This is an odd way to do this. Why don't you just use specific skillmods that go above the cap? None of the skillmods that go over the cap are the same as the ones that stay under it (which I'm certain is why they were special in the first place in the live code). Directly using the buffs is a little hacky and causes lots of room to apply bonuses twice due to small code errors. Using the same system for both pre-and post-cap mods would be preferable.

Test it again, make sure you aren't having cap issues. They definitely show.

They definitely show up in the client if you don't add private. Check for yourself, if you send something garbage, you'll get a garbage entry in your skillmod box. the only thing that prevents it is private_

I don't understand, how are they not being handled properly as it is? If they are special cases, you handle the special case in the skill itself. Do they have damage components? Do they have any other calculation that depends on normal combat stuff?

probably

Acc has a different meaning than hit chance. Acc has no cap, hit chance has a 100% cap. I'm not saying the other variable isn't poorly named.

If you read all the posts about intim (post-9), you'll find that there are so many varied reports of percentage that this made the most sense. It is not a straight damage reduction, but it might be something else.

I did a lot of research, and found that yes, states and dots apply even without hitting (the exception being dots that have ticks based on initial damage, which would be excluded automatically in the current code since they have 0 damage ticks)

more efficient than string mangling. having a constant array of strings to loop through is way more efficient than that.

That doesn't mean they can't. Think generically instead of specifically. Extensibility is key.

You can implement a % in the lua attack pools (I thought we did that at one point). That would be used in whatever iteration of AI, if done well.

There is no need to mangle strings like that. A better solution would be an array of strings to loop through for post-cap additions.

Don't do that. The point of these skill mods is so we can generically pass modifications to combat manager instead of having a ridiculous amount of parameters.

As for which mods take def over the cap, there are multiple sources that say multiple things. I am pretty sure it was chef food (indirectly!), SL and city bonuses after doing way too much research. I never implemented the SL bonuses properly, but you can't assume that all private mods are post-cap. You need to make a specific set of post-cap mods.

Just don't implement it if it's not like it should be in the end. We aren't making a "good-for-now" server, that was a mistake of the past.

not a const, an array of consts... they are already consts.

Oh, then the variable is poorly named.

Same here, this shouldn't be explicitly checked. Use the skill mods.

There are other sources post-9 that say otherwise. In any case, this shouldn't be an if-check. This should be in the skill mods like it currently is.

It should be negated, and since I can't find any info otherwise, it should probably stay that way.

What about other private mods? the point of putting private_ in front of a mod is that it tells the client not to display it. You can't assume it's before or after the cap.

The fundamental assumption is wrong here though, states and dots were applied even when the enemy wasn't hit, which is why we did it like this in the first place. This doesn't need to be here.

Scratch that, I remember why COUNTER was 0x05 now, it's so the client displays the correct animations. This isn't so bad then. But please work on your tabbing and formatting. Consistency = readability.

EDIT: It might be cleaner to implement grouped consts into arrays then when we need to random them, we could just get the member. Food for thought.