I've spent the last few weeks trying to get this into a completely stable install for everyone, so if you notice any errors, just let me know.
Docs: I went through and deleted a lot of the useless information, and plan on working on updating them more as time allows. Installation instructions have changed slightly(mainly with regard to what you're putting in your targetting alias). If anyone has suggestions on more information that I can put here, just reach out, and I'll see what I can do. I'll try to put frequently asked things here as well, but this has never been my strong suit(I'm not sure I have a strong suit at this point). With that in mind, if you ask me a question I've answered there, I will ignore you. Sorry about the format..
Naming: I've been slowly working everything into the "ak" namespace. I've tried to retain most of the more commonly used variables(affstrack.score), just to have some mediocre amount of backwards compatability. I'd like to move more into this namespace as things progress, and deeply regret my ignorance as to proper coding habits when I first started releasing AK.
Classes: Serpent, Magi, Apostate, Shaman, Dragon, Sword & Board, Bard, Blademaster, Occultist, Sylvan, Alchemist, Priest, Runewarden, Jester, Sentinel, Monk, Depthswalker, Airlord, and Waterlord. It's a bit difficult for me to add and test classes I do not have hands on access to, but for the most part, all of these -should- function as intended. If you have access to a class I haven't listed and feel like you have something worth contributing, hit me up. I will also entertain options of adding classes on my own for the low low price of 2750 credits.
Limbs: I lost a lot of my previous information on limbs when I began completely rewriting this section of AK. At one point, due to Austere doing substantially less limb damage using the same attacks/class/skills as equitable companions, I chose to go for more of a plug and play approach vs seeking out some magical formula to apply 100% of the time. I'm sure I'm going to get a lot of questions here, so I'll keep you all updated when I touch docs again. Depending on interest, I don't mind looking into adding more here.
Version Control: This is no longer tracked in the script name. I've created a variable(ak.version instead) and gone ahead and bumped this up to a fresh 6.0(cause who's gonna stop me?)
Size: 1323 KB vs 521 KB. AK has over doubled in size since the last public release(ITS BEEN 3 YEARS GUYS!), so there are twice as many triggers and scripts that can fail. In the event something does go wrong, please be patient. I will try to prioritize you all as often as I can. When in doubt, reset!
Example Usage: I've transitioned AK away from an offense and more into a proper tracking system. With this in mind, you'll notice a distinct lack of examples here. If you have anything you wish to hold onto, I suggest you save them outside of AK before updating.
Akg: Updating this is on my list of things to do. Will it work with current AK? Who knows! If you try it, let me know!
Credits: I'd list everyone that's helped me with AK over the years, but I'm almost guaranteed to offend someone by forgetting to mention them. Ashtani, Targossians, Hashani, Eleusians, Rogues...I'm thankful for everyone that has put a piece of themselves into this.
Disclaimer: I'm human. I work 50 hours a week right now, have two small children, and a life outside of Achaea. I do not get paid to do this, I do not code for a living, and I never had a proper education on coding habits. If you have derogative comments towards anything inside AK(or lack of), feel free to start a journal entry.
The dropbox link remained the same. If anyone wants to pm me how to put it in my sig, I can do that!
As someone who doesn't use your work, I still want to thank you. While it can be frustrating to some to go up against this level of tracking, you've ultimately made the entire combat scene more accessible to everyone. To me personally, that's a win.
As someone who doesn't use your work, I still want to thank you. While it can be frustrating to some to go up against this level of tracking, you've ultimately made the entire combat scene more accessible to everyone. To me personally, that's a win.
^This.
The time and effort put in by people like Austere for scripts like this is providing Achaea with ever evolving strategies, combat situations and increasing the fun factor for many. Yes, it might also annoy some, but the sheer fact that someone has gone to all this effort for free shows what a community we have. Larkin with ACP is the the only reason I stayed all those years ago, then the move to svo, and I can see this having a similar affect.
hrm, downloaded the new release. Installed it, changed all the settings and even added the name of my scimitars into the script. Did everything the instructions says, but it doesnt seem to want to track dwc hits. Its almost as if, it tracks everything up to the prompt on the hit where it should tell the system it has an aff, but the trigger never gets enabled or something
Its something with the Confirmed Hit trigger, because I added the OppGainedAff() to my tracking and turned off AK triggers, and it was grabbing everything properly. I tried doing display(hitrelay) on the Confirmed Hit trigger and it wasn't displaying anything.
I'll check back on this when I log in again to check.
This is awesome. I'm hesitant to completely update because I've modified the old version so much, but I will definitely be playing with this. Thanks for all your work!
Its something with the Confirmed Hit trigger, because I added the OppGainedAff() to my tracking and turned off AK triggers, and it was grabbing everything properly. I tried doing display(hitrelay) on the Confirmed Hit trigger and it wasn't displaying anything.
I'll check back on this when I log in again to check.
I tried to look this over, and from the look of it you have a well enough rounded understanding of debugging that I hate to ask, but see if any errors are being thrown?
Make sure mudlet is updated to a version that supports "prompt" type triggers(not the lua hack around). I highly recommend the latest version(though I'm running 3.8.1 still)
After a DSL completes, check the currentvenoms["a Scimitar of Hawks"] variable to see if it is being cleared.
Its something with the Confirmed Hit trigger, because I added the OppGainedAff() to my tracking and turned off AK triggers, and it was grabbing everything properly. I tried doing display(hitrelay) on the Confirmed Hit trigger and it wasn't displaying anything.
I'll check back on this when I log in again to check.
I tried to look this over, and from the look of it you have a well enough rounded understanding of debugging that I hate to ask, but see if any errors are being thrown?
Make sure mudlet is updated to a version that supports "prompt" type triggers(not the lua hack around). I highly recommend the latest version(though I'm running 3.8.1 still)
After a DSL completes, check the currentvenoms["a Scimitar of Hawks"] variable to see if it is being cleared.
When i get home today I have an idea on how to fix it. Also I am going to play around with your frozen aff capturing. It should be shivering first then frozen if they dont have caloric. Meaning when they apply it should cure frozen. Then cure shivering and the afftracks.score.frozen = 0 should be caloric applied. If they have calroic they should only get shivering on a nairat proc. So ill change those around and see what I get as well. The log above shows it. He applied 3 times. 2 to cure frozen and 1 to apply caloric. Unlrss my unserstanding of curing frozen is off by a salve
Its something with the Confirmed Hit trigger, because I added the OppGainedAff() to my tracking and turned off AK triggers, and it was grabbing everything properly. I tried doing display(hitrelay) on the Confirmed Hit trigger and it wasn't displaying anything.
I'll check back on this when I log in again to check.
I tried to look this over, and from the look of it you have a well enough rounded understanding of debugging that I hate to ask, but see if any errors are being thrown?
Make sure mudlet is updated to a version that supports "prompt" type triggers(not the lua hack around). I highly recommend the latest version(though I'm running 3.8.1 still)
After a DSL completes, check the currentvenoms["a Scimitar of Hawks"] variable to see if it is being cleared.
When i get home today I have an idea on how to fix it. Also I am going to play around with your frozen aff capturing. It should be shivering first then frozen if they dont have caloric. Meaning when they apply it should cure frozen. Then cure shivering and the afftracks.score.frozen = 0 should be caloric applied. If they have calroic they should only get shivering on a nairat proc. So ill change those around and see what I get as well. The log above shows it. He applied 3 times. 2 to cure frozen and 1 to apply caloric. Unlrss my unserstanding of curing frozen is off by a salve
Nairat logic updated.
I cannot replicate DSL's failure to track, even on a completely blank mudlet profile.
Its something with the Confirmed Hit trigger, because I added the OppGainedAff() to my tracking and turned off AK triggers, and it was grabbing everything properly. I tried doing display(hitrelay) on the Confirmed Hit trigger and it wasn't displaying anything.
I'll check back on this when I log in again to check.
I tried to look this over, and from the look of it you have a well enough rounded understanding of debugging that I hate to ask, but see if any errors are being thrown?
Make sure mudlet is updated to a version that supports "prompt" type triggers(not the lua hack around). I highly recommend the latest version(though I'm running 3.8.1 still)
After a DSL completes, check the currentvenoms["a Scimitar of Hawks"] variable to see if it is being cleared.
When i get home today I have an idea on how to fix it. Also I am going to play around with your frozen aff capturing. It should be shivering first then frozen if they dont have caloric. Meaning when they apply it should cure frozen. Then cure shivering and the afftracks.score.frozen = 0 should be caloric applied. If they have calroic they should only get shivering on a nairat proc. So ill change those around and see what I get as well. The log above shows it. He applied 3 times. 2 to cure frozen and 1 to apply caloric. Unlrss my unserstanding of curing frozen is off by a salve
Nairat logic updated.
I cannot replicate DSL's failure to track, even on a completely blank mudlet profile.
Salve logic accounts for preapply, which is why you were getting double frozen cures on a single apply of caloric(it was pulling the unknown salve apply from your previous attack). This issue with this is you can't really reapply caloric. This has also been fixed
Its something with the Confirmed Hit trigger, because I added the OppGainedAff() to my tracking and turned off AK triggers, and it was grabbing everything properly. I tried doing display(hitrelay) on the Confirmed Hit trigger and it wasn't displaying anything.
I'll check back on this when I log in again to check.
I tried to look this over, and from the look of it you have a well enough rounded understanding of debugging that I hate to ask, but see if any errors are being thrown?
Make sure mudlet is updated to a version that supports "prompt" type triggers(not the lua hack around). I highly recommend the latest version(though I'm running 3.8.1 still)
After a DSL completes, check the currentvenoms["a Scimitar of Hawks"] variable to see if it is being cleared.
When i get home today I have an idea on how to fix it. Also I am going to play around with your frozen aff capturing. It should be shivering first then frozen if they dont have caloric. Meaning when they apply it should cure frozen. Then cure shivering and the afftracks.score.frozen = 0 should be caloric applied. If they have calroic they should only get shivering on a nairat proc. So ill change those around and see what I get as well. The log above shows it. He applied 3 times. 2 to cure frozen and 1 to apply caloric. Unlrss my unserstanding of curing frozen is off by a salve
Nairat logic updated.
I cannot replicate DSL's failure to track, even on a completely blank mudlet profile.
It might be on my end. I have the old ak that i rebuilt into my own system that changed a lot of the name spaces and weapon hit echos and everything. Ill look at it again tonight and report back.
@Austere yeah it is something on my end, just loaded a new profile blank, and it worked fine. Not sure. I'll have to go through my code and peel some stuff out or just redo everything
Here is my simplified copy I have been working on. This has updated code all over and I removed the stacks and offense scripting. I think it works but I'm not going to continue working on it since Austere is back. Unfortunately, since we had no timeline on when the new version was going to be released I thought I could resurrect it but it seems that's not really necessary. Thanks for your continued contributions, @Austere.
--Cleaned up the dstab trigger a little bit(Removed my example lines). --Removed a lot of personal Gui code(Yay, streamlining). --Cleaned up Apostate code slightly(still accepting criticism on this front) --Cleaned up Echo code for add aff/lost aff. --Applied Nairat logic to Deepfreeze.
if svo then
function svo.ml_oprompt()
promptset = promptset or {}
if not target then
return ""
elseif #promptset > 0 then
return ("["..table.concat(promptset, ", ").."]")
else
return ""
end
end
svo.adddefinition("@ml_oprompt", "svo.ml_oprompt()")
end
and 'oprompt Wys Script':
if wsys then
function wsys.prompttags.owysprompt()
promptset = promptset or {}
if not target then
return ""
elseif #promptset > 0 and not ak.disableAllEchos then
return (ak.prompt.default.."["..table.concat(promptset, ", ").."<yellow>]")
else
return ""
end
end
end
have you considered putting this on git if you want others to help? It would be easier then putting code snippets here on the forum.
if svo then
function svo.ml_oprompt()
promptset = promptset or {}
if not target then
return ""
elseif #promptset > 0 then
return ("["..table.concat(promptset, ", ").."]")
else
return ""
end
end
svo.adddefinition("@ml_oprompt", "svo.ml_oprompt()")
end
and 'oprompt Wys Script':
if wsys then
function wsys.prompttags.owysprompt()
promptset = promptset or {}
if not target then
return ""
elseif #promptset > 0 and not ak.disableAllEchos then
return (ak.prompt.default.."["..table.concat(promptset, ", ").."<yellow>]")
else
return ""
end
end
end
have you considered putting this on git if you want others to help? It would be easier then putting code snippets here on the forum.
This works fine if Wsys or Svo load before AK, but I've found expecting people to reorder their script files every time they update one of them to be asking a bit much. As it stands, I haven't found any major hiccups with doing it this way.
I have considered git, and this was my original goal until I found I could sync my dropbox with modules. You're welcome to PM me snippets(or github advice) if you like.
This works fine if Wsys or Svo load before AK, but I've found expecting people to reorder their script files every time they update one of them to be asking a bit much. As it stands, I haven't found any major hiccups with doing it this way.
yea, I realize the correct method would be to have the if statement within the function instead of outside the function.
Austere said: I have considered git, and this was my original goal until I found I could sync my dropbox with modules. You're welcome to PM me snippets(or github advice) if you like.
I sync my modules to my local Git folders, then upload changes as and when. The advantage to putting something on Git is the collaborative aspect - others can fork your repository and make changes, you can then review and include them if you wish. This is working very successfully for the mudlet-mapper script, and I'd be happy to chip in here and there with AK if it were on Git
Tharos, the Announcer of Delos shouts, "It's near the end of the egghunt and I still haven't figured out how to pronounce Clean-dat-hoo."
I might be missing something really easy, but how do I get the settings to save without restarting mudlet? I found when I add my name to the movement keys setting
ak.MovementKeys = ak.MovementKeys or {"Zekeros"}--add yourself here to allow num key movement
and after I hit save it doesn't change to my name? It's the same for the noDisplay setting too
I might be missing something really easy, but how do I get the settings to save without restarting mudlet? I found when I add my name to the movement keys setting
ak.MovementKeys = ak.MovementKeys or {"Zekeros"}--add yourself here to allow num key movement
and after I hit save it doesn't change to my name? It's the same for the noDisplay setting too
The top line in osettings is a return so that you can have multiple copies of that script(updates) without overwriting your personal settings. I suggest removing the return line and dragging that script outside of ak so that changes are real time vs onload. The line in question should be commented.
Could use some help on integrating this into the system:
Kythra eats a plumbum flake.
Lucidity returns to the eyes of Kythra.
When she eats the plumbum the system will apply it to all plumbum afflictions, but the second line indicates that shadowmadness was cured. It is the same for touching tree, passive cures, etc. Anyway to back track it to ensure the other plumbum affs are not affected?
Yeah I got that...and its easy to make it cure the Shadowmadness without hitting the other affs, the real issue is to keep it from affecting shadowmadness when they eat plumblum and there is no second message
Going off Aegoth's suggestion, you could just remove shadowmadness from curing pools, and check the next line on all plumbing eats before processing. Could do the same for all other cures relatively easy.
There are two ways that I know of to deal with this and similar issues (and probably more that I don't know of), I don't know AK itself so not sure which is easier to implement:
this means that the cure method will only fire if the line immediately after the eat is a prompt, so then if shadowmadness is cured on the eat it wont fire, and you make a second trigger for the shadowmadness cure that you can track directly
add/remove: first trigger: ^(\w+) eats (?:a|an|some) (.*).$ Perl Regex
in the code add to a table that they've eaten
second trigger: the shadowmadness cure if table.contains(curemethods, "plubnum") then removecure plubnum addcure shadowmadness
third trigger: prompt process the cures in the table, and clear the table
this means that when you see the eat, you add to the table that they ate plubnum, if you get the cure message for shadowmadness you remove it and add shadowmadness and all actual updating to the tracking itself is done on the prompt line, and then you clear the table after that and start over for the next cure.
Dunn tells you, "I hate you." (Party): You say, "Bad plan coming right up."
Comments
The dropbox link remained the same. If anyone wants to pm me how to put it in my sig, I can do that!
https://www.dropbox.com/sh/m6dnd61o8ncc5oe/AAAmY0FPLzuIDaYKDH0WVHsEa?dl=0
The time and effort put in by people like Austere for scripts like this is providing Achaea with ever evolving strategies, combat situations and increasing the fun factor for many. Yes, it might also annoy some, but the sheer fact that someone has gone to all this effort for free shows what a community we have. Larkin with ACP is the the only reason I stayed all those years ago, then the move to svo, and I can see this having a similar affect.
Nice one, dude.
https://ada-young.appspot.com/pastebin/wyEdeMJm
I'll check back on this when I log in again to check.
Make sure mudlet is updated to a version that supports "prompt" type triggers(not the lua hack around). I highly recommend the latest version(though I'm running 3.8.1 still)
After a DSL completes, check the currentvenoms["a Scimitar of Hawks"] variable to see if it is being cleared.
I cannot replicate DSL's failure to track, even on a completely blank mudlet profile.
Everything else looks amazing though, thank you!!!!!!!!
--Cleaned up the dstab trigger a little bit(Removed my example lines).
--Removed a lot of personal Gui code(Yay, streamlining).
--Cleaned up Apostate code slightly(still accepting criticism on this front)
--Cleaned up Echo code for add aff/lost aff.
--Applied Nairat logic to Deepfreeze.
and 'oprompt Wys Script':
have you considered putting this on git if you want others to help? It would be easier then putting code snippets here on the forum.
I have considered git, and this was my original goal until I found I could sync my dropbox with modules. You're welcome to PM me snippets(or github advice) if you like.
and after I hit save it doesn't change to my name? It's the same for the noDisplay setting too
When she eats the plumbum the system will apply it to all plumbum afflictions, but the second line indicates that shadowmadness was cured. It is the same for touching tree, passive cures, etc. Anyway to back track it to ensure the other plumbum affs are not affected?
Thanks!
Going off Aegoth's suggestion, you could just remove shadowmadness from curing pools, and check the next line on all plumbing eats before processing. Could do the same for all other cures relatively easy.
Multiline:
1. ^(\w+) eats (?:a|an|some) (.*).$ Perl Regex
2. prompt
this means that the cure method will only fire if the line immediately after the eat is a prompt, so then if shadowmadness is cured on the eat it wont fire, and you make a second trigger for the shadowmadness cure that you can track directly
add/remove:
first trigger: ^(\w+) eats (?:a|an|some) (.*).$ Perl Regex
in the code add to a table that they've eaten
second trigger: the shadowmadness cure
if table.contains(curemethods, "plubnum") then
removecure plubnum
addcure shadowmadness
third trigger: prompt
process the cures in the table, and clear the table
this means that when you see the eat, you add to the table that they ate plubnum, if you get the cure message for shadowmadness you remove it and add shadowmadness and all actual updating to the tracking itself is done on the prompt line, and then you clear the table after that and start over for the next cure.
Dunn tells you, "I hate you."
(Party): You say, "Bad plan coming right up."