Limb Damage - Solved

Argwin

You'll still need some kind of limb damage counter because it only shows you the damage that your last hit did, but it'll be a lot more accurate now.

Caelan

Yeah thus far it appears to be a decent compromise and allows for testing to be a lot clearer

Accipiter

Any huge revolutionary numbers that are a surprise yet?

Arcturus

It also seems to round up, so hits that would make slightly over 100% may still not break. For instance, I was hitting Accipiter for "7.7%" and it was at 92.4%, hit, and did not break. Still needed one more hit.

This will make testing a LOT easier though!

Shecks

@Accipiter There won't be any. This echo is less accurate than most of the approximation formulas that I've come up with purely due to rounding. E.g. I know that within realistic hp range my SnB formula is accurate to +/-2 damage.

However consider that against someone with 10,000 hp, a limb attack that does 5.0% according to this system, could have done anywhere from 490 to 510 damage (as we can only guess on how rounding is done). In this example, that 20 point uncertainty over 20 hits adds up to 400 damage over the course of prepping a single limb.

I'm not saying this is not handy. It can shave a lot of time off testing and the ensuing math work, but it's basically only an improvement for people who didn't have good formula already.

It's also vital to understand that this change doesn't help you at all in cases where your opponents max hp changes. If an opponent has 5000 hp and you deal 60% limb damage then they increase to 6000 max health, they are certainly not at 60% anymore. We will have to come up with thumbrules for how that works but at best they'll be thumbrules. (Noting there are quite a lot of legal ways to change max hp in fights without artefact swapping cheese).

So all in all, big thanks for listening to the community on this and taking action - sortof... But also not really because it doesn't solve the actual problem and still doesn't allow us to reliably know how much damage an attack is going to do before we do it. People will think this is a major change but it really isn't a change for high end fighters who already has something at least as accurate as this.

Shecks

Thanks @Arcturus that example does help a lot to understand what's going on here.

Shecks

Me:

It's also vital to understand that this change doesn't help you at all in cases where your opponents max hp changes. If an opponent has 5000 hp and you deal 60% limb damage then they increase to 6000 max health, they are certainly not at 60% anymore. We will have to come up with thumbrules for how that works but at best they'll be thumbrules.

Actually I'll walk that back. I do think I can figure this out by seeing how the percentage changes over some test data.

Makarios

There probably will be some other small adjustments, but this will definitely be an incremental process - I'm not really looking to make a ton of changes here all at once given what a core system it is.

That said, fair warning: a huge motivation for me making this change was to open up the limb damage design space to a more significant degree. As a result down the line the burden of calculating this clientside is probably going to grow much more involved for some classes looking to be optimal. I'm sure people will do it anyway because why not, but just something to be aware of. That is most likely a ways off, so not an immediate concern.

Accipiter

@Shecks you were finding surprises in your own data just a couple of weeks ago in this very thread...

Saonji

So far every single one of my Shikudo percentages match the in-game one, to within a 0.025% margin of error.

Have tried it on 7 wildly different health values so far.

Caelan

I like that this doesnt negate the need to "figure it out yourself" by hitting people and testing, but it provides a really good starting point for newbies and midbies to refine things making them better w application of that knowledge.

Cooper

All you need for a limb counter now is one script that someone can probably write pretty quickly. With a little more thought you could almost completely automate limb targeting (something those with limb counters could already do if they wanted).

Trigger your attack message and the followup limb damage message to:

• change a variable that saves the % of limb damage that attack did to the opponent
• add that % damage to current opponent's correct limb
• Calculate how many of those attacks you need to pass 100%, how many have occurred on which limb, and put that into a window or echo
• reset that info with a macro/alias

No need to save complicated formulas, no requirement to spend hours testing various health points (this will still be beneficial, but is no longer required).

Classes with multiple sources of limb damage will have it a bit rougher still, but that is a positive change!

Romaen

I might be forgetting features too, but you'd also need to

• Watch for salve applies (and tree/passive cures as a substitute to mending) after break to reset.
• Reset limbs three minutes after last hit.

Vinzent

Could also announce the % for each hit over PT and have people aggregate into their own counters live.

Akicita

You'll still need some kind of limb damage counter because it only shows you the damage that your last hit did, but it'll be a lot more accurate now.

Yeah! I meant that I wasn't looking forward to doing one off of guesswork, eg. "will this take eight hits or nine", etc. Knowing for sure now is great.

(an early version of my limb counter I wrote day of, lots of improvements since then)

Saonji

I was considering uploading my limbcounter to forums, which includes illusion-proofing of all these attacks and accurate tracking of salve applies (fake applies notwithstanding because those are impossible to do).

Then I thought fuck giving that much work out for free.

Savira

well the illusion proofing should be fairly simple though, the limb dmg msg is in bold white a colour you cant illusion in since it's the system msg colour (ansi 15). So just making the capture colour coded for that defeats all types of illusions...

Saonji

Looks pretty standard colouring to me. Regardless, there's more to it than that. Particularly when it comes to keeping tracking varying attack percentages to work out exact when each attack will break a limb. As well as updating percentages accordingly if their max health changes.

I like thoroughness.

Savira

Hrm weird, this is how it looks for me. Might be some setting somewhere or a latent trigger that change it for me... Guess I'll have to write down a colour based script and double check.

But I get your point about the work put into your code, I usually just go with the lazy but working methods which is probably why I'll never become more then average when it come to combat :P

Edit: if you look at the paralysis line compared to the limb dmg line there's a slight colour change, might be hard to tell on the picture but in mudlet it's a clear difference between the two

Saonji

Looks to me like your attack highlighter isn't deselecting, and is continuing to highlight on new lines. I just turned off all my triggers to test.

Savira

damn it, then I might have to put some effort into it... oh well guess it'll be a project for the future

Shecks

There are plenty of ways to be 100% illusion proof on this, primarily by enabling the trigger on "real" attacks.

My way of doing this is with a chained command that starts with an echo, then turning it off on prompt.

E.g. my command separator is // so I use:

send("queue add eqbal echo not an illusion//queue add eqbal [attack]")

Then you just make a trigger for "not an illusion" to turn on your limb damage triggers(s) and ofc gag that line, and a trigger to disable your limb damage trigger(s) on prompt.

There are more efficient ways to do this that don't require using one of your 10 multi-commands but I never need 10 so it's fine, and it can't be defeated (especially if you randomize your echo string).

Saonji

You can just enable them on the 'Running queued eqbal' command line, and disable them again on prompt. You're not allowed to illusion those messages. Doesn't "waste" any command.

Some other nuances to cover, but that'll get the vast majority of your things covered.

Atalkez

Are we allowed to illusion this new message? I’m guessing so but I don’t like it.

Shecks

Why would we not be allowed to illusion it? If anything this is a direct nerf to illusions as now we have to illusion 3 lines for a believable limb attack, and even then it's 100% preventable as mentioned above.

Sobriquet

Everyone:"This is awesome, gives us clearer numbers, makes limb classes easier and more accessible, especially to newbies"

Sheck:"This has nerfed my illusions"

Shecks

No it's awesome. Maybe you forgot but I'm the one who specifically asked for this specific change.

That doesn't mean, objectively, that it's not a nerf to illusions. It is.

Atalkez

I don't think taking a QoL addition like this and then requiring everyone to make gated triggers to open on attack/close on prompt is reasonable. I would prefer this line not be illusion-able at all and leave the coding requirement to use it much lower. There is a very big difference in someone making a single trigger to add these together, than doing that PLUS gating it all so that it only works on attacks you know you sent and then closing it properly. I think it's a bad thing to allow to affect what is a QoL upgrade.

Shecks

What do you mean, @Atalkez - we have always been able to illusion this. The only change this brings to illusions is that illusions have to include an additional line now to appear valid (and again, this can still be dismissed with 100% accuracy with a simple trigger, which anyone with a client-side limb tracker will have). Allowing this to be illusioned is a nerf, and banning it from being illusioned is a bigger nerf (as now we can't illusion limb damage at all).

Thaisen

Ez fix. Delete illusions