WunderSys: an Achaean ServerSide Curing System

Aeacus

Hmm.

@Tynil Are there installation instructions?

Tynil

Aeacus said:

Hmm.

@Tynil Are there installation instructions?

Nothing that I've added to, but @Nemutaur 's documenation here should still be relevant

Acknu

How you write an alias or a keybinding with the wsys.doadd() function that wouldn't try to queue when you have balance/equilibrium and tries use the wsys.doadd() function when you don't have balance/equilibrium? I looked through the code but I am not very good at it. Thanks!

Fusco

I had to reinstall Mudlet, including wiping the .config folder. After the install and putting a fresh version of Wundersys on it, Wundersys won't cure. All of the other functionality seems to work, and it recognizes when I take afflictions, but it won't actually try to heal.

Isaiah

Have you tried curing on, do you have the necessary herbs, is it set to use the herb type you have?

Fusco

Thanks! Transmutation had been set off, and when I had turned it back on it didn't save the setting. I should've thought to check it again.

Isaiah

No worries, glad to help

Tynil

Acknu said:

How you write an alias or a keybinding with the wsys.doadd() function that wouldn't try to queue when you have balance/equilibrium and tries use the wsys.doadd() function when you don't have balance/equilibrium? I looked through the code but I am not very good at it. Thanks!

wsys.doadd will add the command to the server-side queue right away if you already have balance and eq. That means it should execute right away. If you didn't have balance/eq, it will be added to the end of the queue. (Reminder: wsys.doadd acts as a First-In-First-Out queue, where if you queue multiple things, e.g. A, then B, then C, they will be executed A then B then C. wsys.dofirst is Last-In-First-Out, so if you wsys.dofirst for A, then B, then C, they will be executed C then B then A)

If you only want to add to the queue when you don't have balance/eq, and do nothing when you do, you can do something like:

 if wsys.bals.b and wsys.bals.e then
    --You have balance and eq, do something directly?
 else
    wsys.doadd( "kick rat" )
 end

Fusco

For some reason, Wundersys isn't putting up (through BDEF) or keeping up blindness. I've tried removing and re-adding the upkeep of it and it doesn't change anything. I'm not sure where to look to find the problem.

Fusco

Please disregard my previous post I figured it out.

Tynil

WunderSys v1.1.1

https://github.com/tynil/WunderSys/releases

Not too much here, but the three major fixes: now tracks and displays burning stacks, stops showing torntendons(1) (and things like that) in the affs tag, and it should now correctly check github for the latest version of the system on login, so you'll automatically know when a new version is available.

Changelog:

• Added: Add event when do actions ran - Keneanung
• Fixed: Updated Curseward gained line. (@Ethoas + @Praxides)
• Fixed: highlighting limbs on limb attacks (@Miriew)
• Fixed: Class timers from afflictions
• Added: Missing pacified trigger
• Added: Burning stack tracking
• Fixed: Check for updates automatically on login

Ariete

I'm having trouble getting the 'lasthit' parry strategy to work. Any suggestions?

Calaurn

Is there a way to check for available tattoos (maybe via GMCP)? Or does wundersys set wsys.bals.tree to false in absence of tree tattoo? The lockqueue function has first condition that tests for paralysis and tree balance (which turns out true) and therefore tries to touch tree when instead it should move on next conditions (such as isFitnessClass() in my case) and use those cures.

Acknu

Is there any way to stop or clear multiple uses of the wsys.doadd() function. If you spam it will just keep going. You can send clearqueue all but when you use the wsys.doadd() function again it just starts off where it was at you stopped it. Any ideas?

Ahmet

I see a wsys.dofreeclear() function and a wsys.dorclear() function, but no others in the docs, try wsys.doclear()? Or see if wsys.dorclear() works? I know svo uses the same table for dor and doqueue, not sure about wsys.

Acknu

Ahmet said:

I see a wsys.dofreeclear() function and a wsys.dorclear() function, but no others in the docs, try wsys.doclear()? Or see if wsys.dorclear() works? I know svo uses the same table for dor and doqueue, not sure about wsys.

Thanks for checking. I tried that but no go.  I think I figured it out though, there is a small function called wsys.undoall() that was tucked away in a script. It does what I want it to do but I'm not sure if it is the mostly optimal way. 

Calaurn

wsys.undoall() will clear out entire queue.

Tynil

Acknu said:

Is there any way to stop or clear multiple uses of the wsys.doadd() function. If you spam it will just keep going. You can send clearqueue all but when you use the wsys.doadd() function again it just starts off where it was at you stopped it. Any ideas?

I'm slowly starting to add some documentation to the wiki on the github project. I added some info on the do queue functions here: https://github.com/tynil/WunderSys/wiki/Commands

Short answer: wsys.undo and wsys.undoall are what you want

Sola

Hi, all. I came across a weird issue with putting up my Monk defences. I had Regeneration and Boosting enabled. For some reason, there was no check to see if Regeneration was put up before Boosting in the queue rather than Boosting being put up first and THEN Regeneration. I got an error message that I don't have Regeneration up. I checked the defences tables for both defup and keepup. Both of those abilities from Kaido are enabled.

Does this latest version include a fix for this issue that might have been discovered by other Monks or not? I can follow directions and fix the problems, but I myself is starting to get into the coding stuff for Mudlet 3.

Oh, I have Wundersys rc 3 currently. Just needed to know if someone can point out what needs to be done to address this problem.

Found the answer for Battlerage on the github site.

Cynlael

That would be a serverside problem, not a wundersys problem. BUG it, and it should be fixed soon enough.

Tynil

@Sola use wshow defprio to see the priorities, and wconfig defprio <defence> <#> to set the priority. It'll work fine as long as boosting is a lower (i.e. closer to 25) priority than regeneration.

Tynil

WunderSys v1.1.2

https://github.com/tynil/WunderSys/releases

Major changes of note: improvements for multiclass and auto-mounting

Changelog:

• Fixed: Send correct got/lost aff on diagnose - Wyd
• Added: Dualblunt class timers - Wyd
• Fixed: Profile copying now uses a deepcopy
• Fixed: Don't send curing status on any gmcp skills event (fixes issues with Keneanung's scripts)
• Added: Boar, moss, moon def subs
• Added: Reset defences on soulcage triggering (it might say 'MOGGED' but it still works. I was just too lazy to make them separate)
• Fixed: Recognize tree balance recovered line
• Added: Auto-mounting keepup. (VA to toggle)
• Improved: Defence/profile management for multiclass
• Fixed: Only use kaiboost when you have kai

See https://github.com/tynil/WunderSys/wiki/Commands for new auto-mount commands, andhttps://github.com/tynil/WunderSys/wiki/Basic-Setup for profile setup. The profile changes include the ability to copy defences from one class to another in the same profile (i.e. for shared defences). Also adds a new alias DEFUP to switch to a profile and raise defup defences for that profile.

On class changing now, you should automatically switch to the new class's profile, and update your defences accordingly. The intent is you should have a few profiles (e.g. "basic", "combat", "starburst", etc.), while each class has it's own defences and priorities in each profile.

Chthonia

Might anyone know why my prompt would disappear on Wundersys when using @Keneanung 's bashing script flee toggle button?

https://ada-young.appspot.com/pastebin/a433f704

My prompt only returns when I hit F2 and begin attacking the target again.

Keneanung

I guess the prompt is erroring out on something. First thing to look at is the error view (scripts -> errors button on left). First guess is the target health in there.

Chthonia

@Tynil, 

I've been messing around a bit and it appears the issue may be when adding the @npchp tag manually to prompt.

I've removed the prompttag, and I'm no longer having the issue of my prompt disappearing.

Isaeah

I have been attempting to get the @npchp to work in my prompt. I use the st alias atop mudlet's vars and, according to the script, the gmcp.target.info having a value should populate the health percent of the denizen.

Is the tag broken?

Mizik

Courtesy of @Wyd

Fix for 'va on' or 'va off' for auto mounting:

--Inside Mounting script

function wsys.mountUp( mount )

  if type(mount) == "string" then

    wsys.setSettings( "mount", string.trim(mount) )

   wsys.autoMount( true )

 else

wsys.autoMount(mount)

 end

end

--Automounting alias

if matches[2] then

local mount = matches[2]

if matches[2] == " on" then mount = true end

if matches[2] == " off" then mount = false end

        wsys.mountUp(  mount )

else

        wsys.mountToggle()

end

Isaeah

Mizik said:

Courtesy of @Wyd

Fix for 'va on' or 'va off' for auto mounting:

--Inside Mounting script

function wsys.mountUp( mount )

  if type(mount) == "string" then

    wsys.setSettings( "mount", string.trim(mount) )

   wsys.autoMount( true )

 else

wsys.autoMount(mount)

 end

end

--Automounting alias

if matches[2] then

local mount = matches[2]

if matches[2] == " on" then mount = true end

if matches[2] == " off" then mount = false end

        wsys.mountUp(  mount )

else

        wsys.mountToggle()

end

Oddest thing: Putting this into my script for auto-mounting fixed the @npchp. 

Medi

A. I'm a code noob

B. I cannot figure out why changing keepup defs (using the WSHOW KEEPUP click thing) is making the change across all profiles. I upgraded from rc3 to Tynil's newest version to see if any sort of fix was implemented and before that I searched through a lot of the rc3 wsys code and couldn't find anything that would make the change across all profiles.

C. Sorry if this was already covered, but minions are spawning.

Tynil

Medi said:

A. I'm a code noob

B. I cannot figure out why changing keepup defs (using the WSHOW KEEPUP click thing) is making the change across all profiles. I upgraded from rc3 to Tynil's newest version to see if any sort of fix was implemented and before that I searched through a lot of the rc3 wsys code and couldn't find anything that would make the change across all profiles.

C. Sorry if this was already covered, but minions are spawning.

If you used wconfig profile copy, then that was a bug that was just fixed in 1.1.2. After updating to 1.1.2, did you close and re-open mudlet before trying to change settings again? You shouldn't need to, but try that if you haven't. If that doesn't work, try creating a new profile, use the wconfig profile copy command, and see if changing things from WSHOW KEEPUP still changes them in both profiles.

Just to be sure, you are switching using 'swp <profile>' to change profiles, right? Or 'defup <profile>' is also a valid command to switch and defup to a new profile too.