Uncanny Dodge Fix

[oldgrayrogue]

Having played a rogue and a barb I say if it can be fixed fix it, but NOT if it is going to stress the server in ANY way. My two scents.

[dirsa]

well, i'm just shooting from the hip here with some simple solution... if it turns out not to be simple, i'd have to go with ogr here... i've been playing a rogue for quite a while now, and if not for this thread i would have never noticed any issues with uncanny dodge...

[Swift]

The only reliable way we are going to know how much this change will add to server load is to actually throw the change onto a server and get it tested.

I vote that we don't decide on whether to go with this fix or not until after a field test.

[Zelknolf]

Having played a rogue and a barb I say if it can be fixed fix it, but NOT if it is going to stress the server in ANY way. My two scents.

This is a very hard line to draw, OGR, and one that confuses me greatly. Everything we do to every mod adds stress to the servers. To catch you at your own game: the static content you asked me to work on for BG just this month (inbox says Dec 17) would add more stress to our least-beefy server.

[oldgrayrogue]

I am all for a field test. Not shooting the idea down entirely just wanted to offer my opinion that we should avoid stressing the server for fixes like this iff possible. I assume if the feat worked properly it would not add to server load yes?

I believe that a cost/benefit analysis should apply to any type of new content vs adding load to a server. New static content on BG (or any other server) potentially benefits every present and potential new player, as well as taking some of the load off of DMs who are now providing all RP content and context. Fixing Uncanny Dodge, while certainly something I would like to see done, only benefits some players.

[Brokenbone]

I'd have thought a global class change, applicable across all servers in all combat situations would outweigh any little static in any cost benefit analysis? A static you tend to do once, Fedex this beer to the thirsty guy five screens away. Rogues are squishy, and despite being skill monkeys, half the skills they are monkeys for are going to be RP-focused, requiring a DM. Uncanny dodge is something that helps with respect to their squishiness. (Barbs and dorf defenders aren't all that squishy, but they're a hammer, and every combat situation is their nail)

Anyhow, interesting proposal, maybe an HDM will step up and offer their spot as a test bed. Moonshaes for example, presumably it's the "lightest" on static content but also pretty heavy traffic for people checking out shiny newness. *shrugs*

[mogonk]

I'd have thought a global class change, applicable across all servers in all combat situations would outweigh any little static in any cost benefit analysis?

I would think so. When put in the context of being weighed against a single static or a couple of NPCs, the cost seems pretty negligible. Seems like a no brainer.

Still, the test run people are asking for couldn't do any harm, even if we're fairly sure what the results will be. I doubt Castano would have a problem with doing it on MS.

[oldgrayrogue]

I am not trying to derail this with a debate about static content, but in my experience statics get people logging on even when no DMs are around. DMs come and go, and DM coverage has highs and lows but available static content is always there to provide a context for RP when DMs are not. DM'd content is certainly preferable but unfortunately is also often inconsistent. As someone who played a rogue to level 9 without Uncanny Dodge I think additional static content trumps an uncanny dodge fix in that it ultimately benefits more players and the game world as a whole. So not such a "no brainer" in my estimation.

[mogonk]

I didn't mean to raise the issue of the worth of static content. My point was that the scale is so small. We're talking about fixing a major class feature possessed by two of the core classes for the same amount of server load that just 2-3 NPCs create. If it created such a burden that we would be forced to forgo large quantities of static content, that would be one thing. But it won't. Zelk was pretty clear that the scale of the server load created would be quite small.

I also didn't mean to be harsh in the way I phrased my opinion. Sorry if that's the way it came across.

[Zelknolf]

To be fair, I'm gonna make the static content too. My rhetorical purpose was to get the "Well, yeah. It's a cost-benefit analysis." out of OGR, because then I can argue the realistic "The cost is low; I mention it because it's there and I like being honest about that kind of stuff. Math uses cycles. No way around it." rather than a complete B.S. "There is (virtually) no performance cost!"

In this case, I get to say that it will be cheaper than a static, cheaper than spawns, cheaper than a PrC, cheaper than your average PC, significantly cheaper than PCs who cast spells frequently and at regular intervals (like the warlocks who make up 1/3 of ALFA's population), and cheaper than pathfinding. And it makes it so that our quick and alert PCs don't die instantly in ambushes (except, curiously, for monks. But screw them anyway).

And I've also learned to not talk about performance impacts to people who don't script. Won't make that mistake again.

[oldgrayrogue]

To be fair, I'm gonna make the static content too. My rhetorical purpose was to get the "Well, yeah. It's a cost-benefit analysis." out of OGR, because then I can argue the realistic "The cost is low; I mention it because it's there and I like being honest about that kind of stuff. Math uses cycles. No way around it." rather than a complete B.S. "There is (virtually) no performance cost!"

You're so sneaky! <3

And it makes it so that our quick and alert PCs don't die instantly in ambushes (except, curiously, for monks. But screw them anyway).

And since I am playing a monk I can say without hesitation that there is no way I shall ever support this fix ever, no way no how

Wait -- how about a multiclass rogue/monk -- go do the math on that ya smarty pants! =P

[Zelknolf]

Strictly speaking, uncanny dodge should be the same regardless of those monk levels, on account of this yummy little bit:

When unarmored and unencumbered, the monk adds her Wisdom bonus (if any) to her AC. In addition, a monk gains a +1 bonus to AC at 5th level. This bonus increases by 1 for every five monk levels thereafter (+2 at 10th, +3 at 15th, and +4 at 20th level).

These bonuses to AC apply even against touch attacks or when the monk is flat-footed. She loses these bonuses when she is immobilized or helpless, when she wears any armor, when she carries a shield, or when she carries a medium or heavy load.

But I don't think the engine actually works that way. I would need to test stuffs to verify, though. And that is, thus, another (related!) fix -- and it would fall into the category of things that only make a difference for a small portion of a fight, but that we really should do something about.

[Regalis]

I think you may be going about this backwards by trying to go about it directly.

You can't get the person who is about to attack you to provide a preemptive AC bonus. You can go into the AI and apply an attack penalty before the attacks take place. The only inconveniences to this system are 1) that cleaves would likely also suffer this penalty, unless you rewrote the feats to account for all of the times npcs get to use cleave..., and 2) it would only help pcs or npcs being attacked by npcs and never pcs or npcs being attacked by players. That just means that current npcs would not need to be rebalanced and pvp should only happen under dm supervision.

This is less resource intensive than using a custom heartbeat--pseudoHBs should never be used per OEI's lead programmer--and less of a kludge than using concealment scaled to a fighter BAB.

[Zelknolf]

Two parts, firstly!

This is less resource intensive than using a custom heartbeat--pseudoHBs should never be used per OEI's lead programmer--and less of a kludge than using concealment scaled to a fighter BAB.

This ship has sailed, Reg. ACR lives and breathes on the pseudoheartbeat, and our performance would suffer if we tried to run our pseudoheartbeats off of actual heartbeats. I'll grant that were you to ask me to post on a forum accessible to everyone scripting for NWN2, I would also say to never ever ever ever write a self-referencing function (and I would write "ever" three times there, too), but if you want an event to occur on a schedule for an indefinite amount of time, there are two options: pseudoheartbeats and heartbeats (and the latter is more resource intensive).


To the first part!

*ahem* No you're backwards! Asking for attack penalties instead of defense bonuses! You backwards person, you.

Seriously, though, I'm mostly worried about the PvP aspect, and would want to have something in place to handle that. A rogue getting sneak attacked to death by a flanking rogue is just plain B.S., and I'd hate to see that come up in any kind of PvP scenario, because I guarantee it will cause much drama and fussing and fighting, likely with an IC solution that will be nearly impossible to reconcile with existing RP. Then we've got retcons and rollbacks and all stuff I don't want to deal with. I'd agree that modifying the NPC is better in terms of accuracy and resource usage, and I could even use feat-modifying functions to account for improved uncanny dodge, but I would want to have something that pops up when a PvP happens to give these people their appropriate protection. AI code is more complex and more fragile, in my experience, so testing would be a larger investment -- but meh. That's a one-time investment of work

[Regalis]

Where did you get your benchmarks for pseudoheartbeat vs. custom heartbeat rate?