Long Live Wundersys

13

Comments

  • Austere said:
    Tysandr said:
    Until you realise how flimsy it is
    Wsys is far from flimsy. A significant portion of "top tier" uses their own modified version.  Thats not to say it's not without issues, but calling it flimsy when it's base has such a firm hold on combat is just silly
    Uh, not targeting Wundersys in particular. My bad?
    "All we have to decide is what to do with the time that is given to us."

  • Antonius said:
    Morthif said:
    What else would you use?
    Your own system coded to do what you need it to rather than a system generalised to be usable by other people?
    I am actually pretty surprised people don't appreciate it more.  Mine sucks currently, but it's come a long way and given me a better understanding of combat since coming back from dormancy.  And when it breaks, typically I don't have to ask someone else how to fix it.  

  • Amranu said:
    There's also little point to coding an entire system for yourself even if you can code. Taking what others have made available and building on it is a far more efficient use of your time.
    In hindsight, it is very easy with the GMCP and a few functions to establish a curing system.  

  • Amranu said:
    There's also little point to coding an entire system for yourself even if you can code. Taking what others have made available and building on it is a far more efficient use of your time.
    This really depends on how experienced/comfortable you are with coding. For some - possibly even most - people, this may be true. For others, building the core of a system that works around server side curing (i.e. precisely what Wundersys does) can take less time than getting to grips with how somebody else has structured their code.
  • I finished up my proposed solution for (properly) using CURINGSETs for curing purposes. The file can be obtained from my GitHub over at https://github.com/sailgoat/WunderSys.

    Once that's complete and I finish up a few other housecleaning tasks I'll release it an "official" version 1.2. Will pop some documentation on the GitHub around that time as well, finally.

    Please report any issues you find either on the GitHub repository itself or via WBUG -- sends a message to me directly.

    Thanks as always, folks.


  • My proposed solution had a few curingset-related issues which are corrected now -- grab the latest version on my GitHub repository at https://github.com/sailgoat/WunderSys.
  • Looks like everything is loaded up and working for me. I'm now happy to (finally) announce the release of WunderSys version 1.2. You can grab your copy at https://github.com/sailgoat/WunderSys/releases/tag/1.2

    I do not currently have any new features planned for WunderSys. That being said, this should be a decent baseline for newer players interested in a system that they can easily adjust and learn from. Still have some documentation to put up -- coming together slowly but steady on the repository's wiki section.

    As always, please feel free to contact me here, via Discord or in-game with any bugs, questions or concerns and I'll be happy to help out.
  • Awesome news. I'm currently running 1.1.3, or what passed for 1.1.3. More of a bastard child at this point.

    Just to be on the safe side, do you have any formal upgrading instructions to better facilitate the switch over? Don't want to break anything!
  • All the changes I've personally made should be compatible with older versions. I'd recommend the following:

    1. Zip up your profile and keep it somewhere safe.
    2. Uninstall the old package.
    3. Install the new one. Once it reads your settings, QQ and then close Mudlet.
    4. Open Mudlet back up, say a quick prayer to the hurricane gods and all should be well.
    This all comes with a caveat, though. If you've modified core WunderSys functionality (in the WunderSys folders) -- and have custom aliases/triggers/scripts outside the WunderSys folder that rely on that modified functionality -- that will probably break.

    If you made huge, breaking changes on your WunderSys installation ages ago it might not be worth having to rip out all the custom stuff you've created. The specific, larger changes I'm responsible for can be added in separately with maybe an hour or two of work.
  • Are there any docs around for Wundersys? I'm happy to write some as I figure it out if there are not. 
  • Nevermind, found it!
  • Here are the original docs slightly updated, you can fork and edit as you see fit.
    My version of WunderSys is around the 1.1.3 area so I would not want to use the system itself right yet.
    I kept the docs as simple as possible (they are in plain html and unminified css).
    http://zpaav.github.io/WunderSys/
  • ArchaeonArchaeon Ur mums house lol
    extra end on the lock queue script.  Just delete the last END and you're g2g.
  • Archaeon said:
    extra end on the lock queue script.  Just delete the last END and you're g2g.
    Thanks Archaeon. I've made that change and modified the 1.2.1 release to include that. So anyone who hadn't already grabbed 1.2.1 before yesterday-ish should be good to go.
  • Important note: Wundersys 1.2.1 requires at least Mudlet 3.11 or higher (I've started using some useful new API's, like tempPromptTrigger). Most things may appear to still work with older versions, but I can't guarantee there won't be major issues (blackout would probably cause issues). I recommend just grabbing the latest version from https://www.mudlet.org/download/. I'm testing everything myself using Mudlet 3.18 currently.
  • I've been having issues switching from svo to wundersys. I want to have one profile and be able to switch classes easier since I now have 3 classes plus air elemental and also dragon, so it's been a higher priority but I can't seem to get it to work. My defenses are broken in wundersys upon switching from svo on a new profile, I clear out the serverside, try to reconfigure, and it's just not keeping them up or looking at them. The k bashing script also breaks using wundersys, it gets stuck in a loop trying to break shield and I don't know how to clear it. I think they're both similar problems, in not making a "clean transition" between systems. Does anyone have some advice on steps to make it work more reliably? 
  • Did you know you can use modules across platforms for mudlet? You can have the same settings but different svof copies running.

    You still have to switch profiles when you switch class, but you can have the same bashing triggers or target alias or whatever between profiles.

  • I did not know that, I will look into doing that as well. Thank you!
  • Jethan said:
    I've been having issues switching from svo to wundersys. I want to have one profile and be able to switch classes easier since I now have 3 classes plus air elemental and also dragon, so it's been a higher priority but I can't seem to get it to work. My defenses are broken in wundersys upon switching from svo on a new profile, I clear out the serverside, try to reconfigure, and it's just not keeping them up or looking at them. The k bashing script also breaks using wundersys, it gets stuck in a loop trying to break shield and I don't know how to clear it. I think they're both similar problems, in not making a "clean transition" between systems. Does anyone have some advice on steps to make it work more reliably? 
    First off, you're free to choose between svo or wundersys (or anything else) as you like. I mostly like to develop wundersys to offer an alternative, rather than saying it is necessarily better (and honestly, I've never used svof, so I don't have anything to compare to anyway)

    So anyway, stick with svo if you want, or if you want to try wundersys again  (or general info for anyone wanting to get started with it), I recommend taking a look at https://github.com/tynil/WunderSys/wiki/Basic-Setup. Create a profile, set up your defences using wshow keepup/defup and clicking what you want, then wshow defprio to shift those. The related aliases for those commands are:
    - wconfig defup/keepup <profile> <defence> (I should probably add an option to do this without needing to specify profile. I'll add that for the next release version)
    - wconfig defprio <defence> <#>

    It does not read/import anything from your current defenses. And testing a little myself, it looks like it won't clear out anything that you already have added (Also probably something I can eventually add, but that's a longer-term effort, not for the next version). So you'd probably need to manually clear out all the defences that you don't want, then configure what you do want with the wconfig/wshow commands.

    Once you have it setup for one class, switch to your next class and 'WCONFIG PROFILE COPYCLASS <previous_class>". That'll copy all the setup you just did with one class to the next, though you'll probably still need to configure your new class defences again.

    As for k bashing, did you explicitly set kconfig bashing system wundersys? Alternatively, if you're uninstalling svo, make sure you close mudlet after doing so. Uninstalling a script doesn't clear out all the functions/event listeners it may still have running, so you'd want to close and re-open mudlet to be sure it's clean. I played around with that a little and did get it to work with the latest prerelease versions, though I made some small changes to make it play nicer (it was clearing my doqueue when I get un-prone even when I had it disabled). I'll see about committing my changes there sometime soon as well.
  • how do I make it show the defup/keepup lists instead of a blank?

    there seems to be some sort of trick to making it start appear, I usually fuss around with it until the command works but for some reason I'm not able to stumble upon the right sequence today:



  • I think I found it, the table in the defenses folder was lit up with a bug icon. I went to the file to look for the error, but as soon as I clicked into it the bug icon disappeared. I hit save, then the wshow defup command presented the menu as expected.

  • Thanks @Shub, it sounds like wsys.tb might not have been initialized by then? I confirmed I saw that when I loaded a fresh copy of WunderSys, though I'm not sure why I don't see it when I load my normal copy. Either way, that's an easy fix: just add >> wsys.tb = wsys.tb or {} << before the wsys.tb.defenceTable = { line in the Defence Tables script. I'll add that in the next release.

    Also, to follow up, I helped @Jethan figure out some issues with configuring defences, and it turns out that using the "wconfig defup/keepup" aliases probably isn't recommended at this point. We found a bug where if you try to configure something that isn't a valid defence, you might hit errors. Configuring using the WSHOW KEEPUP/DEFUP/DEFPRIO tables and clicking what you need is safer, until I've fixed some of the odd cases and made those aliases more robust.
  • I think it might have something to do with the way I have it installed, as a module with sync enabled, im guessing is syntax checking the defense table mid-sync and giving up until I click into the table to make the validation fire off again. It seems to happen about 1 in every 2 mudlet launches, still playing with it, thanks!

  • WunderSys v1.2.2

    WunderSys v1.2.2 is now available. See https://github.com/tynil/WunderSys/releases for details. It's mostly just small changes. I'm still testing the changes to switch to (near) pure GMCP aff tracking. One change I want to note is that I've moved releases to the production/stable branch. If you install a copy of WunderSys from that branch, or any of the stable releases, it will only check for updates on that branch, which should be less frequent and only after they've been reasonably tested.

    If instead, you're interested in the latest changes that I'm working on, which may not always be 100% tested yet, you can download any of the pre-releases (I don't have any up yet), or download WunderSys.xml directly from the master branch (https://github.com/tynil/WunderSys/blob/master/WunderSys.xml). These versions will check for updates on the master branch, which I may be releasing more frequently and with less testing. If you're willing and interested in testing these, then check these out and let me know if you find any issues!

    Also, since I'd like to make it easier for people to update WunderSys, let me know if there are any things that you typically have modified for your own preferences within the system. If possible, I'd like to try and provide ways to make those modifications outside, so it's less of a hassle to update. For example, thanks @Gilliam for suggesting the changes to customize the aff tag short names and colors.
  • edited April 2019
    @Tynil Just so you know, unnameable isn't random. It gives, in order, stupidity > confusion > dementia.
    So assuming you have no mentals...
    • If it gives 1, you get stupidity.
    • If it gives 2, you get stupidity and confusion.
    • If it gives 3, you get stupidity, confusion and dementia.
    • If you have confusion and it gives 2, then you get stupidity and dementia.
    Etc. Don't use Wsys, so can't do a pull request for you. But figured I'd point it out.

  • How sure are you on that? I wasn't able to find an Occultist to sit down and thoroughly test with, but I have a log where I was diagnosing every time Dosu used it against me in a rampage, and I see at least:
    • 1 insanity gave dementia
    • 2 insanities gave stupidity, dementia
    • 2 insanities gave stupidity, confusion
    I didn't see any consistent pattern from that.
  • edited April 2019
    Also, for an update:
    I plan to release a 1.3-beta build in the next couple of weeks (this Tide event thing may delay progress some). The main goal for this upcoming release is to make the jump from the current trigger based aff tracking to nearly pure GMCP aff tracking (with some triggers for stackables, including unweaves and pressure), using the WunderSys Foundation.xml script that I've quietly put up. I've been working with and using it myself for at least a couple weeks now, but I'm still finding and fixing things I've missed (thanks for breaking me @Santar ). After I think it's in a reasonably good place, I'll push it up and do a beta release for others to start testing with as well. As this will be a significant change, I can't guarantee everything is perfect in the first go, so hopefully others can help with testing when it gets to that point.

    If you wanted to try out just the aff tracking piece, you're technically free to download and install WunderSys Foundation.xml separately (it only tracks things and puts them in tables/raise events. It does not perform any actions). Then change your affTags call to use wsysf.affs instead of wsys.aff. That'll change the prompt tag to reference the new table. It will not use the new table to change curing priorities yet though.

    Note that if you want to be notified when the first 1.3 beta is out, in the "Check for Updates" script, change the branch = "production/stable" to branch = "master" (or install WunderSys.xml directly from the master branch)
  • Is it using gmcp for just aff's or are you gmcp tracking targets/room items/inventory and everything else too?

    I'm wondering if this will eventually grow to replace my existing gmcp parser that drives my gauges/consoles/antitheft/etc.

Sign In or Register to comment.