Aetolia.com Lore Wiki Vote! Forum Rules
Looking for more active discussion? Join our Discord at https://discord.gg/x2s7fY6

[CMUD] Help! Moss overeating.

CorlinCorlin
edited June 2013 in Tech Talk
Disclaimer: I know that the way my system does things isn't as efficient as it could be, relying on internal variables instead of gmcp.

THE PROBLEM

Sometimes, when I take a lot of burst damage - so, anywhere endgame - my system sends the command to eat moss through twice, resulting in me going through moss at twice the speed I should.

HERE'S MY CODE

First, my prompt sends my healing check. This is the moss part:

[spoiler]

#if (%ismember( moss, @Auto) and @AbleOutc and !%ismember( moss, @LostBals) and !%ismember( EMoss, @MyFlags) and ((@currenthealth<@mosshealth) or (@currentmana<@mossmana) or %ismember( recklessness, @MyAffs))) {Feat moss}
    }

[/spoiler]

Assuming that flags as true on the required levels, it sends 'Feat moss' which is just my eat alias, and the plant I want eaten:

[spoiler]

#if (%ismember( %1, goldenseal) and %ismember( stupidity, @MyAffs)) {#2 outc goldenseal;#2 eat goldenseal} {
outc %1;eat %1}

[/spoiler]

In there, my 'eat' alias is called:

[spoiler]

Featcheck %1
~eat %1
LastCure=%1

[/spoiler]

It's my 'featcheck' alias that sets lost balances and flags to mark my having attempted to eat something:

[spoiler]

#if (%1 == moss) {
  Fadd MyFlags Emoss
  Fadd LostBals moss
  #T+ EMossCheck
  } {
#if (%ismember( %1, ash|bayberry|bellwort|bloodroot|ginseng|goldenseal|hawthorn|kelp|lobelia|cohosh)) {
    Fadd MyFlags EHerb
    Fadd LostBals herb
    #T+ EHerbCheck
    } {
#if ( %1 == kola) {
      Fadd MyFlags EKola
      #T+ EKolaCheck
      }
    }
  }

[/spoiler]

SO, HOW CAN I FIX IT?

I've tried most things I can think of. This issue doesn't happen with any other herbs, it doesn't happen with health -sipping- which is coded in essentially the same fashion. It's not a huge issue, but it does become sort of expensive when I go through 800 moss every time I'm in tiyen.

Comments

  • EzalorEzalor Emperor D'baen Canada
    edited June 2013
    You can just add a limiter to stop that. So for example in your moss code:

    #IF (%ismember(moss, @auto) and @ableoutc and !%ismember(moss, @lostbals) and .... and @eatingmoss!=1) {
    #VAR eatingmoss 1
    feat moss
    #WAIT 200
    #VAR eatingmoss %null
    }

    Then just make a variable called eatingmoss. Or eatingplants, whatever you want. 200 is just an arbitrary number I picked, shorten or lengthen it as you please.

    Also you should reeeally use GMCP, it makes life much easier. It's very simple, actually, if you'd like to know how to go about it I'd be happy to write up a short little instructions thing.
    image
  • DaskalosDaskalos Credit Whore Extraordinare Rolling amongst piles of credits.
    It's always been my understanding that using #ALARM is better than #WAIT because #WAIT is shared across all scripts whereas #ALARM is unique each time it's fired.

    image

    image


    Message #17059 Sent By: Oleis           Received On: 1/03/2014/17:24
    "If it makes you feel better, just checking your artifact list threatens to crash my mudlet."

  • HavenHaven World Burner Flight School
    Ezalor said:
    ...if you'd like to know how to go about it I'd be happy to write up a short little instructions thing.
    PLEASE.
    ¤ Si vis pacem, para bellum. ¤
    Someone powerful says, "We're going to have to delete you."
    havenbanner2
  • CorlinCorlin
    edited June 2013
    @Ezalor

    Those limiters DO exist - it's what keeps me from eating all my moss at once or something. This is literally a case of the parameters for moss eating being met BEFORE I eat the moss, and the command to eat being sent through twice, at the same time. By the time the first eat goes through and sets the balance to zero, the second has already been sent to the mud.

    Edit - Moss being part of lost bals means I don't have moss balance. Emoss being one of my flags means I've attempted to eat it, but it hasn't gone through. Making your suggested variable would do the.. same thing.

    #if (%ismember( moss, @Auto) and @AbleOutc and !%ismember( moss, @LostBals) and !%ismember( EMoss, @MyFlags) and ((@currenthealth<@mosshealth) or (@currentmana<@mossmana) or %ismember( recklessness, @MyAffs))) {Feat moss}
        }
  • MoireanMoirean Chairmander Portland
    Perhaps a silly question, but do you have the trigger clicked for "fire on prompt" or the default newline?
  • CorlinCorlin
    All my herbing is done through aliases. The healing scan - the alias that checks if I need to sip or moss - is run from my prompt. The line that sets my moss off (the eat line) is new line, though.
  • MoireanMoirean Chairmander Portland
    I don't mean what the trigger pattern is. There's an option in trigger editing that you can enable to set a trigger to fire off different things, which will (I think?) affect the order they are run in. Try switching it to fire on prompt for the prompt trigger, if you haven't tried that.
  • CorlinCorlin
    It's always run off prompt, for the prompt trigger. Sort of has to, for my system to run.

    It's not an issue of something not working - my system functions very well, in most situations.

    It even mosses properly, to a point. It never tries to eat moss if it's actually off balance, for example. But it's sending two 'eat moss' commands while it IS on balance for moss, causing me to use moss at twice the rate.
  • MoireanMoirean Chairmander Portland
    By looking at what you've written and without running the code myself, it sounds like the trigger is firing multiple times before the eaten balance alias goes through. That is, the trigger is working fine, but you've probably got the wrong variable values there at time of execution, based on the eaten alias not setting them fast enough. I'd verify this by putting #say Variable: @variable for all of the relevant variables into your various commands, so you can see real-time what is being set, when. This will help you pinpoint when exactly things are being executed and you'll probably find that there is a wonky order of operations going on, which leads to your system thinking that you haven't eaten moss when you had.
  • CorlinCorlin
    I have that!

    Well, all my stuff is output in debug mode.

    I already figured it's what you said - I'm just having issue figuring out what piece of my code needs tweaking to set the flag a little faster. It -does- set. It never eats more than two, and it only happens with burst damage - that a sip can't fix, so more than one prompt with moss-level health goes through.
  • MoireanMoirean Chairmander Portland
    Ok, I'm trying to plug your code in for testing. What do you mean by flags? Events? Sorry, still transitioning from zmud to cmud, maybe this is some new feature I haven't played with yet? Or do you just mean the term in a broader sense?

    Now, I tested this out by just setting mosshealth and mana above my max health and spamming a prompt echo and it's only firing once for me. However, I kinda just had to guess what your have in your fadd alias. I used:

    #if (%1 == moss) {
      #additem lostbals moss
      }  

    Now, the above seems to be working just fine and there's no repeated eats, so I'm going to tentatively say that the issue might be in the fadd alias.
  • AztonAzton
    Ezalor said:
    You can just add a limiter to stop that. So for example in your moss code:

    #IF (%ismember(moss, @auto) and @ableoutc and !%ismember(moss, @lostbals) and .... and @eatingmoss!=1) {
    #VAR eatingmoss 1
    feat moss
    #WAIT 200
    #VAR eatingmoss %null
    }

    Then just make a variable called eatingmoss. Or eatingplants, whatever you want. 200 is just an arbitrary number I picked, shorten or lengthen it as you please.

    Also you should reeeally use GMCP, it makes life much easier. It's very simple, actually, if you'd like to know how to go about it I'd be happy to write up a short little instructions thing.


    #IF (%ismember(moss, @auto) and @ableoutc and !%ismember(moss, @lostbals) and .... and @eatingmoss!=1) {
    feat moss
    #VAR eatingmoss 1
    #alarm "EatingMoss" +1 {
    #VAR eatingmoss 0}
    }


    is what I think Ezalor meant.. I have the same issue with kidney/moss but everything else runs fine...

    or instead of adding the eatingmoss you can do something like

    #additem lostbals "moss"
    #alarm "EatingMoss" +1 {#delitem lostbals "moss"}

  • EzalorEzalor Emperor D'baen Canada
    edited June 2013
    @Corlin that's exactly why I have the #WAIT thing. Or use #ALARM, apparently that's better, I've just always used #WAIT out of laziness.

    What happens is you get a prompt, it sends to eat moss, then you get another prompt before your eat moss command goes through, so it sends another eat command. Your limiter isn't actually effective without a small delay to ensure that doesn't happen.
    image
  • MoireanMoirean Chairmander Portland
    It would work fine if he moved the eat attempt into the same command stack as the rest of it, or put it into a class that gets very briefly disabled when an attempt is made.
  • EzalorEzalor Emperor D'baen Canada
    Moirean said:
    It would work fine if he moved the eat attempt into the same command stack as the rest of it, or put it into a class that gets very briefly disabled when an attempt is made.
    In my experience, enabling/disabling classes causes a bit of slowdown and lag. I used to do that to handle stupidity but it was noticeably slowing down my offense so I just built it into my normal attack function.
    image
  • AztonAzton
    Ezalor said:
    Moirean said:
    It would work fine if he moved the eat attempt into the same command stack as the rest of it, or put it into a class that gets very briefly disabled when an attempt is made.
    In my experience, enabling/disabling classes causes a bit of slowdown and lag. I used to do that to handle stupidity but it was noticeably slowing down my offense so I just built it into my normal attack function.
    I Agree, I never turn of a folder/trigger no matter what situation is.. :/

  • MoireanMoirean Chairmander Portland
    Really? In zmud, that was the most efficient way to manage things, versus having tons of variable checks.
    Isto
  • IstoIsto
    Yeah. I've always done that with Cmud. In the long run it actually speeds up your system. You can have redundant triggers that only fire small snippets of code instead of having to filter through it all. And variables that don't need to get referenced, so on and so forth. All my class based offense is run like that. Hella. Faster.
    image
    image
  • EzalorEzalor Emperor D'baen Canada
    edited June 2013
    I dunno. I had it so when I got stupidity, I'd turn off my normal offense class and enable a special stupidity offense class, and vice versa for when I cured stupidity. But then I noticed that I'd just stand around not doing anything for a while if I rapidly gained and cured stupidity a bunch of times in a row. It introduced a lag time of a second or more when that would happen. Possible that it was an error in my enabling/disabling function that caused it but it was pretty simple and I go much faster after deleting that section of my AI.

    Processing multiple variables is hardly any strain at all, if that slowed down CMud it really wouldn't be worth using. My offense runs through a billion variable checks and reshuffles my aff priority on every prompt and I have no slowdown from it at all.
    image
  • VharenVharen
    edited June 2013
    I use a .25s alarm and a command queue for everything, so I have to reuse my "don't eat 1000 things" bit a lot. I recommend the use of a database record named Sent_Commands or similar.

    doblah would have !%ismember(blahcommand,@Sent_Commands) in its #if logic. If it goes through, #addkey Sent_Commands blahcommand 0. Throw in a trigger to #delkey on a success message, potentially on failure messages for those odd occasions.

    I have my short tick increment the database values, and take them off at some value (6 ticks at current.)

    You still have to throw in triggers for things, but I think it's cleaner than creating new variables and adding a bunch of temp alarms.



  • CorlinCorlin
    edited June 2013
    @Moirean - I use a variable called 'MyFlags' that many things are added / removed to and from as required. This means I can use %ismember( mcguffin, @MyFlags) to reference any number of things, versus needing to do something like #if (@Variable=1) for everything I want to know.

    Adding 'emoss' to my flags SHOULD tell my system I've attempted to eat moss - that's the whole point of it. It's supposed to tell my system I've tried to do something, and not to try to do it again - the same flag exists for various salves, sips and there's an Eherb flag for every herb except moss and kola.

    @Azton Almost everything in my system has those reset alarms that deletes the 'attempted to' and 'lost balance' flags - such as emoss or moss - so, all the code suggested here is already in my system, except a hard wait between moss eats, which the emoss flag was supposed to negate the requirement for. My moss reset currently resets both my 'attempted to eat moss' and my 'lost balance from eating moss' on an alarm that's the same length as moss balance.

    The double eat should be stopped by the emoss flag, and it's not, because the flag isn't being set fast enough. I'll need to fiddle, though it's nice to know a similar issue has happened to other people.
  • MoireanMoirean Chairmander Portland
    Well, like I said, when I put the check into your more core alias, it worked fine. Maybe you've just inceptioned your settings too much. 3 levels down is too deep! 

    Or something. >_>
  • CorlinCorlin
    The code presented DOES work fine, in almost every situation. Just burst damage causes overeating, and since all endgame bashing means burst damage.. it happens a lot. I'll look into a timed check, versus having it look for the flag.
Sign In or Register to comment.