Creating a system to run alongside server side curing HALP!

Hi, I'm Paku! I just started playing about a week ago! I've been spending most of my time hunting and have talked with a few people that mentioned that serverside can be better used with a clientside system supplementing it. For those that have created their own system to work along side serverside, what did you first implement? What should I look into, what should I focus on finishing first within my system?


I've managed to get GMCP aff/defs working but no logic behind them. My first step in creating my own system I want to setup defense handling. Any ideas on how I can get this started?

Answers

  • edited February 2021
    You really don't need such a system, until maybe intermediate level of combat.  The in-game curing system along with a good set of aliases is more than enough for pve at any level and pvp up to even high levels (with good manual control).

    Instead of sitting down to build a system, maybe just build it one single thing at a time as you learn new things.  E.g. you die to darkshade, add a check to prio darkshade.    Do that enough times and you'll have a great system pretty soon.

    Same is true for defence management.  

    For both curing and defences, don't forget to set up good tree scenarios or the fact that you can have multiple pages you can swap between on the fly (e.g. a page for vs serpent and another page against priests, etc).

    To answer your question though, starting blank page with good server side setup is to set up some automatic prio swaps or prio overrides (PRIOAFF) for special cases where static priorities will get you in trouble, but in order to know when and how to do this, you'd need a great deal of experience.

    I don't really recommend SVO (a popular free curing system that sits on top of server side curing) because it trains your brain to think that you don't need to watch your own curing (you do!) but I do like its defences management GUI (when it isn't bugging out).  It's nice to have visual and aliase-based toggles for everything instead of using the command-line style of server side.
  • I haven't looked at any curing systems as of yet. I've mostly just been toying around with some LUA on Mudlet as I hunt. I do like the idea of just piecing it together as I go, it makes the whole process a lot less daunting!


    For defense management, This is what I have so far. I'm curious as to how I might cross reference my gmcp defs to my defences list to show a completed defup that I could call my removeDefences() function to.

    I have gmcp new, add, and remove functions that will populate a table called 'ctr.defs.list'
    --This is where I define my defences, I started with just one for now that I called basic. defences = { ["basic"] = { "blindness", "deafness", "insomnia", "temperance", "levitating", "thirdeye", "kola", "insulation", "speed", "fangbarrier", "mindseye" }, current = "basic" --Defaults to basic defences } --Function that will add all my defences to priority defence list slot 24 function addDefences(type) for i,v in ipairs(defences[type]) do send("curing priority defence "..v.." 24") end defences.current = type end --Function that will remove all defences from curing priority defence list. function removeDefenses() for i,v in ipairs(defences[defences.current]) do send("curing priority defence "..v.." reset") end end



  • My first step in creating my own system I want to setup defense handling. Any ideas on how I can get this started?

    One of the things to take in mind when dealing with defence upkeep is that you don't want to be keeping up defences that take equilibrium or balance to raise all the time, like certain class specific defences or something like mindseye. If you're unlucky, you'll end up in a situation you should be running as far away from your attacker as possible in, and serverside will delay you with some defence you've had stripped.

    One way to fix the problem is to remove defences from keepup when you're attacking, and set a tempTimer to re-raise them in, say, 10 seconds. Every time you attack, kill the timer and restart it. This way, as long as you're attacking the defences won't be on keepup, but if you stop for 10 seconds (after having run away from that pesky enemy) upkeep will be enabled again. There are other, arguably more efficient ways, but this is a pretty good start. 

    -- On attack:
    
    if defTimer then 
      killTimer(defTimer) 
    else
      send("curing priority defence inspiration reset heresy reset mindseye reset", false)
    end
    
    defTimer = tempTimer(10, [[
      send("curing priority defence inspiration 4 heresy 4 mindseye 3", false)
      defTimer = nil
    ]])
    
    -- You might want to gag the serverside defence upkeep line or colour it something dull.
  • ArchaeonArchaeon Ur mums house lol
    the way I do it is I have a table of defs to def up with, and a table with priorities.  Whenever I type DEFUP, if I don't have the defs already I'll set the priority to whatever, and then when I get the def from GMCP I'll send a prio reset for the def based on the table with the priorities. 




  • edited February 2021
    Romaen said:
    My first step in creating my own system I want to setup defense handling. Any ideas on how I can get this started?

    One of the things to take in mind when dealing with defence upkeep is that you don't want to be keeping up defences that take equilibrium or balance to raise all the time, like certain class specific defences or something like mindseye. If you're unlucky, you'll end up in a situation you should be running as far away from your attacker as possible in, and serverside will delay you with some defence you've had stripped.

    One way to fix the problem is to remove defences from keepup when you're attacking, and set a tempTimer to re-raise them in, say, 10 seconds. Every time you attack, kill the timer and restart it. This way, as long as you're attacking the defences won't be on keepup, but if you stop for 10 seconds (after having run away from that pesky enemy) upkeep will be enabled again. There are other, arguably more efficient ways, but this is a pretty good start. 

    -- On attack:
    
    if defTimer then 
      killTimer(defTimer) 
    else
      send("curing priority defence inspiration reset heresy reset mindseye reset", false)
    end
    
    defTimer = tempTimer(10, [[
      send("curing priority defence inspiration 4 heresy 4 mindseye 3", false)
      defTimer = nil
    ]])
    
    -- You might want to gag the serverside defence upkeep line or colour it something dull.

    Erm, there are quite a lot of defs you can and should have on keepup during combat...

    I think the way SVO does this is ideal, which is just to have a defup mode where it assumes you're not in combat, and then a keepup mode that's active all the time.  For things that use balance (like caloric, deafness, etc) it prioritizes them against curing appropriately.  For example it may defup caloric before curing a broken arm, in some cases, which is actually necessary to prevent several kill strategies.  Another obvious example is keepup of kola and insomnia.

    Again, make sure you FULLY read and understand the capabilities of the built in system, including defence management, before building on top of it.  It is simple but does the job well with the main exception being that it doesn't manage prio swaps for you or toggle defences on/off automatically.

    Something to note here is that once you start looking at combat, anti-illusion is a big concern, and everything in server side is effectively immune to illusions, so the more you use it instead of client-side control, the safer you'll be from clever illusion-users.

    Tip: I think most people would agree that it's best practice to never put any defence that consumes 'balance' or equilibrium on keepup.  This should always be done manually via individual alias or through batch defup command.
  • Yep, it's a lazy way of doing it. I use the timers because heresy and inspiration are, themselves, on timers, and I can't be assed to keep an eye on them.
Sign In or Register to comment.