Why don't i just install this instead of making my own shabby one....
Because you're a gross forestal and I don't support your classes.
It's true Rangor.. he hateses ussss.
I actually installed this with Wundersys to play with - WSys for ideas, this to hopefully replace my own cobbled together script - but there was a problem (one interfered with the other somehow, I dont recall). I have been meaning to reinstall it solo and fix it for forestals. Just... time is such a bitch sometimes.
It's more that I can't pick up the class myself so it's impossible for me to test or even get the lines. My counter also doesn't really support multiple weapons easily, which I think is probably important for Sentinel.
The counter itself appears to work, but when I install it my second prompt line disappears, and the prompt part of the the tracker doesn't show up. And thanks for taking the time to look.
@Khalyon Only thing I can see based on the errors you posted before is that the prompt trigger corresponding to 1st person rend (i.e. your own rends) wasn't correctly closing the trigger above it. That may have been the cause of your issue, though it seems a bit weird. There's an updated version on Dropbox, so install that and see if that fixes the problem. If it doesn't, try to grab me when we're both online and I'll do some debugging with you.
It's more that I can't pick up the class myself so it's impossible for me to test or even get the lines. My counter also doesn't really support multiple weapons easily, which I think is probably important for Sentinel.
I can get you the lines if you really want. What else do you need?
I'd like to get it going for forestals and I also have a knight class to switch to (and monk) that I would like to not have to go through all the testing for again.,
<[string "Script: Targetting"]:205: attempt to index field 'target' (a nil value)>
Any help would be appreciated.
It looks like antonius.target probably isn't being set, which tracks the current target for the limb counter to use (including for the prompt tags). Make sure you've changed your targetting alias to do antonius.targetting.target(matches[2]) so that it all gets initialised properly; that also sets a 'target' variable and sends the SETTARGET command to the game, so you can remove that stuff from your own alias (or do it twice, it won't hurt).
So not sure what I did wrong the first few times trying to set this up, even when I did remember to ad the targetting line, but it seems to work fine now. Thanks again @Antonius.
So hit a new snag with the counter. Picked up monk, and when I target someone I get the error...
[ERROR:] object:<End> function:<Trigger272>
<[string "Script: Tekura"]:45: attempt to perform arithmetic on local 'modifier' (a nil value)>
any idea on how to fix it?
My guess (without being able to check the code right now) is that there's no default value set for knuckles level. Try 'tconfig knuckles <level>' to correspond to the level of knuckles you have; use 0 if you don't have them.
Try 'tconfig knuckles <level>' to correspond to the level of knuckles you have; use 0 if you don't have them.
It came back ... [Antonius]: Invalid option "knuckles".
I went in and found the knuckles in the script and if I manually do ... antonius.targetting.conf.knuckles = 0 then it looks like it works. I might just add it to the log in trigger I have so it sets it when I log in, unless you have a better way to fix it.
Try 'tconfig knuckles <level>' to correspond to the level of knuckles you have; use 0 if you don't have them.
It came back ... [Antonius]: Invalid option "knuckles".
I went in and found the knuckles in the script and if I manually do ... antonius.targetting.conf.knuckles = 0 then it looks like it works. I might just add it to the log in trigger I have so it sets it when I log in, unless you have a better way to fix it.
Thanks again for the fast response, and the help.
Hm. That output would suggest there are some parts missing in the config script to handle the Monk specific options. I'll take a look at adding those in tomorrow, they must have been missed when I was moving that over.
You shouldn't need to create a trigger to set it every time - once it's in the conf table it should get saved between sessions - but it won't hurt if you do.
You shouldn't need to create a trigger to set it every time - once it's in the conf table it should get saved between sessions - but it won't hurt if you do.
Is there any chance of Blademaster support? Or did I just not read everything thoroughly
I did some work on Blademaster years ago, but the way its limb damage works presents some unique problems for certain parts of my limb counter. I'll take another look at it when I have some time, but I can't guarantee it will be soon.
Is there any chance of Blademaster support? Or did I just not read everything thoroughly
I did some work on Blademaster years ago, but the way its limb damage works presents some unique problems for certain parts of my limb counter. I'll take another look at it when I have some time, but I can't guarantee it will be soon.
I love the way this informs decisions, but I find that it doesn’t update the displayed count in the prompt very quickly / reliably. Wondering if it is my class (DWB Runewarden), my prompt (it displays the counts, just delayed) or my life choices (I use single prompt). Any thoughts are appreciated!
Struggling to get this counting properly for SnB/Runewarden.
I started by hitting Glathna at 6437 HP. My attacks according to Antonius LC do 7.7 limb damage. It took 115.4, which divided by 7.7, is 15 hits. I adjusted tconfig hits to respect this, but it didn't adjust my damage from 7.7. I adjusted tconfig hits 14 to 6000, and 8 to 1000 just to see if having lower options helped, no change. Same with higher. I adjusted longsword damage, turned off anti-illusion in case that was factoring in, and....
New development as I was typing this, turned off SnB formula and now it is adjusting to respect the changes I made. What is the SnB formula, and should I have it on and try to get it working?
there are errors in the snb formula, and i have found the errors exist in the HP ranges of 6100 to 6500. The adjustments I made to the formula are as follows:
if math.ceil(100 / (percent per hit)) * (percent per hit) < 101.16 then
(percent per hit) = 100 / (math.ceil(100 / (percent per hit)) + .5)
Does @Antonius still check this from time to time, or is there anyone brave enough to help me attempt some minor tweaks to these scripts? Recent WunderSys convert, and non-Svof limbcounters seem scarce; this one seems rock solid, but I'm kinda struggling with the output in percentages. I saw he mentioned possibly implementing a converter to raw hits, but doesn't seem like that made it in.
Primarily dual-blunt and dual-cutting Knight, and if I break someone at 89.75% calculating whether that's one or two hits off given ??? hits so far isn't easy on the fly. Even just adding the system's current hits.required to the prompt output would help, so I don't have to go searching mid-fight for what the system currently thinks it is.
-- Grounded in but one perspective, what we perceive is an exaggeration of the truth.
@aerek ok so, not sure if this will help you but I made this little guy precisely because I didn't really figure how to fix it all:
Each block represents a body part (head/torso etc)
The total limb damages are the percentages - so 100% is broken - it fills this information from antonius.target.hits - e.g. antonius.target.hits["left leg"] fills the left leg box (bottom left) with its current percentage.
It uses the antonius.targetting[isbroken|isprepped|ispreppednext] to set the colours for the limb state - red is broken, yellow is breaks in 1 hit, orange is breaks in 2 hits - e.g:
if antonius.targetting.isbroken(target, "head") then head:setStyleSheet([[ background-color:red ;]]) elseif antonius.targetting.isprepped(target, "head") then head:setStyleSheet([[ background-color:yellow ;]]) elseif antonius.targetting.ispreppednext(target, "head") then head:setStyleSheet([[ background-color:orange ;]]) else head:setStyleSheet([[ background-color:gray ;]]) end
You would need to call the function to update on either hits or prompt whatever you think is best
Unfortunately I'm not sure the best way to change his system to be #of hits so I found this a useful compromise - I know when which limb will break when, its current % of prep, and when its cured.
Does @Antonius still check this from time to time, or is there anyone brave enough to help me attempt some minor tweaks to these scripts? Recent WunderSys convert, and non-Svof limbcounters seem scarce; this one seems rock solid, but I'm kinda struggling with the output in percentages. I saw he mentioned possibly implementing a converter to raw hits, but doesn't seem like that made it in.
Primarily dual-blunt and dual-cutting Knight, and if I break someone at 89.75% calculating whether that's one or two hits off given ??? hits so far isn't easy on the fly. Even just adding the system's current hits.required to the prompt output would help, so I don't have to go searching mid-fight for what the system currently thinks it is.
This was something we talked about a long, long time ago, and he mentioned that it wasn't something he was interested in doing.
However, the functions for broken, prepped, and preppedonnexthit can be recolored pretty easily, and you can better color code your break thresholds. Right now they're yellow for prepped on the next hit and orange for next hit will break. The functions as is count dual cutting dsls as ONE attack, not two; functionally, this means the color changes when one OR two jabs from the dsl would break it.
I once changed it to better respect single hits (think razeslash), but by that point I was so used to the different percentage ranges that I didn't need it anymore. I used to think the percentages were more confusing than just a "hit" count, but now I wouldn't hange it for the world. It's a super big boon in groups because you can easily track other limb prep classes alongside of you!
Color coding is fine, I can follow that. My issue is that I'm re-learning everyone's breakpoints, and last time I was playing 6k health was rare. While I get a handle on that, the counter and I are going to be wrong a lot, and when that happens I'm not finding it easy to recalibrate on the fly. Tracking single hits is a lot more conducive to learning.
@Eryl Little concerning to hear that DSL = 1 hit. That seems like a problem if 1 DSL =/= 1 Undercut. What was the method you used to respect singles RSLs?
-- Grounded in but one perspective, what we perceive is an exaggeration of the truth.
Color coding is fine, I can follow that. My issue is that I'm re-learning everyone's breakpoints, and last time I was playing 6k health was rare. While I get a handle on that, the counter and I are going to be wrong a lot, and when that happens I'm not finding it easy to recalibrate on the fly. Tracking single hits is a lot more conducive to learning.
@Eryl Little concerning to hear that DSL = 1 hit. That seems like a problem if 1 DSL =/= 1 Undercut. What was the method you used to respect singles RSLs?
Oh, no no. I'm explaining poorly, I'll try to do better.
The function that considers if a limb will break on the next "hit" and therefore color it orange considers that "hit" to be a dsl. That means you will sometimes be going for that first leg break because it's colored and ready to go, miss one hit due to clumsy, and visually speaking an orange number changes to an orange number when you expected that orange number to become red because you confirmed the hit.
Similarly, sometimes a limb will display that it is prepped and ready to break on the next hit, but you can still RSL it once. That's because the function in charge of coloring it orange does so when the limb will break with one dsl ortwo rsls.
EDIT: In writing this out, I think I just convinced myself to go ahead and change that to something that makes more sense to me. I think I want it to be yellow when one dsl will break the limb and orange when one rsl will break the limb. That should be easily doable, but I'm not at my pc to see.
EDIT2: For clarification, TCONFIG HITS is the number of RSLs it will take to break a limb.
Comments
Results of disembowel testing | Knight limb counter | GMCP AB files
Results of disembowel testing | Knight limb counter | GMCP AB files
Results of disembowel testing | Knight limb counter | GMCP AB files
Results of disembowel testing | Knight limb counter | GMCP AB files
Results of disembowel testing | Knight limb counter | GMCP AB files
Any help would be appreciated.
Results of disembowel testing | Knight limb counter | GMCP AB files
any idea on how to fix it?
Results of disembowel testing | Knight limb counter | GMCP AB files
I went in and found the knuckles in the script and if I manually do ... antonius.targetting.conf.knuckles = 0 then it looks like it works. I might just add it to the log in trigger I have so it sets it when I log in, unless you have a better way to fix it.
Thanks again for the fast response, and the help.
You shouldn't need to create a trigger to set it every time - once it's in the conf table it should get saved between sessions - but it won't hurt if you do.
Results of disembowel testing | Knight limb counter | GMCP AB files
Results of disembowel testing | Knight limb counter | GMCP AB files
I started by hitting Glathna at 6437 HP. My attacks according to Antonius LC do 7.7 limb damage. It took 115.4, which divided by 7.7, is 15 hits. I adjusted tconfig hits to respect this, but it didn't adjust my damage from 7.7. I adjusted tconfig hits 14 to 6000, and 8 to 1000 just to see if having lower options helped, no change. Same with higher. I adjusted longsword damage, turned off anti-illusion in case that was factoring in, and....
New development as I was typing this, turned off SnB formula and now it is adjusting to respect the changes I made. What is the SnB formula, and should I have it on and try to get it working?
I think I had to adjust the damage on my longsword, maybe? Either way, you don't need to adjust your THITS when using SnB formula.
if math.ceil(100 / (percent per hit)) * (percent per hit) < 101.16 then
Primarily dual-blunt and dual-cutting Knight, and if I break someone at 89.75% calculating whether that's one or two hits off given ??? hits so far isn't easy on the fly. Even just adding the system's current hits.required to the prompt output would help, so I don't have to go searching mid-fight for what the system currently thinks it is.
background-color:red ;]])
elseif antonius.targetting.isprepped(target, "head") then head:setStyleSheet([[
background-color:yellow ;]])
elseif antonius.targetting.ispreppednext(target, "head") then head:setStyleSheet([[
background-color:orange ;]])
else head:setStyleSheet([[
background-color:gray ;]])
end
However, the functions for broken, prepped, and preppedonnexthit can be recolored pretty easily, and you can better color code your break thresholds. Right now they're yellow for prepped on the next hit and orange for next hit will break. The functions as is count dual cutting dsls as ONE attack, not two; functionally, this means the color changes when one OR two jabs from the dsl would break it.
I once changed it to better respect single hits (think razeslash), but by that point I was so used to the different percentage ranges that I didn't need it anymore. I used to think the percentages were more confusing than just a "hit" count, but now I wouldn't hange it for the world. It's a super big boon in groups because you can easily track other limb prep classes alongside of you!
@Eryl Little concerning to hear that DSL = 1 hit. That seems like a problem if 1 DSL =/= 1 Undercut. What was the method you used to respect singles RSLs?
The function that considers if a limb will break on the next "hit" and therefore color it orange considers that "hit" to be a dsl. That means you will sometimes be going for that first leg break because it's colored and ready to go, miss one hit due to clumsy, and visually speaking an orange number changes to an orange number when you expected that orange number to become red because you confirmed the hit.
Similarly, sometimes a limb will display that it is prepped and ready to break on the next hit, but you can still RSL it once. That's because the function in charge of coloring it orange does so when the limb will break with one dsl or two rsls.
EDIT: In writing this out, I think I just convinced myself to go ahead and change that to something that makes more sense to me. I think I want it to be yellow when one dsl will break the limb and orange when one rsl will break the limb. That should be easily doable, but I'm not at my pc to see.
EDIT2: For clarification, TCONFIG HITS is the number of RSLs it will take to break a limb.