Long Live Wundersys

Anze

I recently decided to switch from Svof to Wundersys. The most recent version I've found is located here: https://github.com/tynil/WunderSys -- not updated since October 2015. I like working with this system and I'd like to work on getting the reported bugs fixed with it. However, I imagine that with the pace of changes that are released to the game that a number of things are outdated and/or still an issue but not reported to that repository.

Before I go ahead and backtrack through game changes to start that effort: has anyone been quietly working on something similar? At minimum, if anyone has been keeping track of changes needed that information would be really helpful.

Please let me know!

Jovolo

It's a shame there's no clan/forum thread dedicated to supporting it. I've used wundersys for a while but the most in-depth I ever got with it was creating event handlers for managing priority swaps. Literally just today a bug popped up that's causing my moss health and mana to continuously be set to 90%, and every time I log-in I get spammed six times with the curing status messages and each time the notification from wundersys saying "Finished checking Curing Status". Can't figure out why it's happening.

Cynlael

Jovolo said:

It's a shame there's no clan/forum thread dedicated to supporting it. I've used wundersys for a while but the most in-depth I ever got with it was creating event handlers for managing priority swaps. Literally just today a bug popped up that's causing my moss health and mana to continuously be set to 90%, and every time I log-in I get spammed six times with the curing status messages and each time the notification from wundersys saying "Finished checking Curing Status". Can't figure out why it's happening.

That's not a bug. It's the mossThresholdUp() function, which sets your moss health/mana up to 90 when you're off sip balance.

Jovolo

It's permanently set to 90. By continuously I meant when I manually adjust it back down, it sets it back up to 90. It's nothing to do with my sip balance because I have my sip at 80, if I stand around and let my health/mana drop to below 90, I automatically eat moss. I've been turning moss eating on and off once I hit my regular moss threshold of 65 as a work-around for now, but it's pretty irritating.

Ahmet

Or just help get svo's issues fixed

Atalkez

Dislike the embedded aspect of svo. Too difficult to see the guts in comparison.

Wundersys is definitely out of date at this point, I've not heard of anyone taking the time to fix it so far. We do have a clan, but it's rarely used (I think I even quit it), which would be good for fixing the system if you wanted to really do it.

Ahmet

Atalkez said:

Dislike the embedded aspect of svo. Too difficult to see the guts in comparison.

Wundersys is definitely out of date at this point, I've not heard of anyone taking the time to fix it so far. We do have a clan, but it's rarely used (I think I even quit it), which would be good for fixing the system if you wanted to really do it.

Perhaps, but it's also more robust and expandable, without having to handle all those xml quirks and escaping when making direct changes, on top of pretty decent documentation.

Protip: in your profile folder, /<class> Svo/svo <------ that file is like 99% of the svo system, all plain lua code.

Anze

Atalkez said:

Dislike the embedded aspect of svo. Too difficult to see the guts in comparison.

Wundersys is definitely out of date at this point, I've not heard of anyone taking the time to fix it so far. We do have a clan, but it's rarely used (I think I even quit it), which would be good for fixing the system if you wanted to really do it.

The clan is an excellent idea, thank you. I'll be sure to see if anyone can provide an invite when I get home. 

Re: Svof, I'm not too interested in working on that platform right now. I've been keeping a close eye on its development, though, and would happily jump in if that ever changes. It would be awesome to rip out a bunch of the non-curing system functionality and make it available to all, regardless of which system they've chosen. That's my big issue with it now: the consequence of building a commercial product.

Aesgar

@Ada Not sure if you have tweaked it at all? I know you're a current user!

@Anze Was just talking about this the other day. Would love to switch back to Wundersys if it was up to date

Anze

I've forked the repository over at https://github.com/sailgoat/WunderSys so I can keep track of the changes that need to be made.

This is all being done through announce posts for now, my best source of information. If anyone knows of anything else please feel free to add an issue or otherwise let me know! My momentum for getting these pushed through is largely based on how quickly I can find people to demonstrate the associated affliction lines.

Atalkez

Incorporate gmcp afflictions and you only need to handle the ss affliction priorities instead of a line-by-line affadd function.

Anze

Atalkez said:

Incorporate gmcp afflictions and you only need to handle the ss affliction priorities instead of a line-by-line affadd function.

Is there 100% coverage for GMCP afflictions at the moment?

Ahmet

Anze said:

Atalkez said:

Incorporate gmcp afflictions and you only need to handle the ss affliction priorities instead of a line-by-line affadd function.

Is there 100% coverage for GMCP afflictions at the moment?

Gmcp doesn't recognize blackout or recklessness properly, nor does it recognize afflictions given under blackout, nor does it handle lust. Until recently, double leg breaks in blackout wouldn't register at all until you manually diagnosed, but I'm told there's a fix in place, so that may or may not be the case anymore.

Armali

Should diagnose under blackout anyways!

Antonius

GMCP shouldn't recognise afflictions under blackout unless you can see the affliction line. That's kind of the point of blackout. Recklessness is handled properly, unless you expect "properly" to include telling you about hidden recklessness (or any other hidden affliction), in which case your expectations need adjusting, not GMCP. Lust isn't even an affliction, no idea why you'd expect it to be communicated over GMCP.

GMCP doesn't work with stackable afflictions. You get the Add message when you first gain the affliction, and you get Remove when you cure all stacks, but there's nothing to indicate changes to stacks.

Ahmet

@Antonius there are some that it doesn't recognize under blackout, even with the lines.

Serverside -rarely- catches recklessness at all, especially from bashing attacks. And yes, if I get hit with loki at 50hp and jump to 4k, I'd expect any reasonable system to say "hey something's wrong here".

Mentioned lust cause why not, idk. Relevant for curing systems. Would be nice to have a serverside option for it, but probably not gonna happen.

And I think I heard stacking affs works properly with magi burning, but I'm not certain on that one.

I've also run into some non-loki bashing attacks that it refuses to recognize, even without blackout/whatever to stop it, but those may have been bugfixed at some point.

Armali

That sounds like your expectations are a little off, and it's poor excuse not to use GMCP aff tracking because of those edge cases. GMCP aff tracking is for more reliable than anything else -- hidden affliction checks you'd have to code in ANYWAYS.

Ahmet

Armali said:

That sounds like your expectations are a little off, and it's poor excuse not to use GMCP aff tracking because of those edge cases. GMCP aff tracking is for more reliable than anything else -- hidden affliction checks you'd have to code in ANYWAYS.

Well, I mean, that's not what I was saying at all, nor do I avoid gmcp aff tracking because of these edge cases, but sure.

I mention them specifically because someone was asking if anything needed to be taken into consideration when using gmcp aff/def tracking with a curing system.

Armali

Okay, I misread a bit. Sorry!

Anze

Looks like I have everything I need to get this up to date. There were also some issues reported on the previous GitHub repository which I'll need to investigate. I conservatively hope to have a non-disastrous version of this up by the end of next week.

Aylek

I've experienced the use moss at 90% all the time every time error.

It seems to bug out for a while, then you manually change it using the curing status, sticks to what you change it for a while, then just resorts to eating moss before sipping etc.

It hasn't happened for a while now, but deffo something a bit buggy there.

Jovolo

Dumping issues in this thread, if you want to add them to your project. 

I experience this error multiple times upon logging in: 

 object:<event handler function> function:<wsys.vitalsUpdate>

         <Echo: wrong argument type>

while "curing status" gets spammed roughly 5 times with the echo "Finished checking curing status". It's a bit of an inconvenience to be spammed with this every time I log in. https://ada-young.appspot.com/pastebin/c0293054

The function in the error:

function wsys.vitalsUpdate()

wsys.gotEquilibriumValue(gmcp.Char.Vitals.eq)

wsys.gotBalanceValue(gmcp.Char.Vitals.bal)

end

gmcp.Char.Vitals.eq and gmcp.Char.Vitals.bal both send through "1" (or "0" if no bal/eq) and I see nothing incorrect in the functions that are being called (in bold).

I'm just looking through the error myself now and will post if I find a solution.

Jovolo

So I haven't had any luck figuring out the cause for the error thrown in the mudlet error window, but it seems the Curing Status spam is linked to the wsys.curingstatuscheck variable inside Curing Status Check triggers and the wsys.abilityCheckAnalyze function. Looking into it now. It's entirely possible I'm the only one experiencing this, but if it pops up for anyone else at least we'll have some documentation here on it.

Solved it for now by moving this code block:

if not wsys.curingstatuscheck then

wsys.curingstatuscheck = true
enableTrigger("Curing Status Check")
send("curing status", false)
end

out of the wsys.abilitycheckanlyze function and into the wsys.abilitycheck function. The former is being called by an event handler many times after log-in and thus ends up spamming the curing status check, whereas the latter is only called once upon log-in. It achieves the same function but without the spam. 

Kenway

If you need any help with this i have been keeping my wundersys up to date with new prio swaps and lines and such. Let me know if theres anything in particular i can help with. Ill look at the page when i get home.

Jovolo

Anyone know how to get rid of these echoes for limb breaks? I can't find them in the system.

 --------------------------------------------------------- 

|     DAMAGEDRIGHTLEG BROKE! | DAMAGEDRIGHTLEG BROKE!     |

 --------------------------------------------------------- 

Fendo

I added in a pull request with a ton of documenting since my initial fixes a few months back were really messy.
Hopefully they make sense. I check github so comment there. 


@Jovolo
Wundersys Folder > Prompt Folder > Prompt Checks 
Remove Line 21 and Line 29 (or comment it out)  wsys.boxDisplay(v[1] .. " BROKE!", "white:orange")

Theodus

Not sure how much effort it would be to bring this back to date - I do like the system and how "open" it is though i'm not sure if i could code in all the fixes/updates. I believe the only thing I did with the system was fix the focus change to weariness.

Anze

@Theodus If the pull request that @Fendo provided is merged into the main repository it will be effectively "up to date". I'll try to get that reviewed soon. 

Theodus

How hard would it be to add in gmcp afflictions? it does seem a lot easier to play with prio switches than the line by line if statements that @atalkez mentioned.

Aylek

I think Wundersys already uses the GMCP names for afflictions as a it is, so shouldn't be too hard to add GMCP.

I'm working on it in my spare time at the moment.

Antonius

I have no idea how hard it would be to add into Wundersys because I've not seen the code, but it took me a couple of hours total (though not consecutive) to implement GMCP affliction tracking into my own system, identify the issues with certain afflictions and code work arounds.

Using GMCP isn't hard and it doesn't take long to code anything to use it once you know what the messages contain, that's kind of the beauty of it.