Jump to content
Frequently Asked Questions
  • Are you not able to open the client? Try following our getting started guide
  • Still not working? Try downloading and running JarFix
  • Help! My bot doesn't do anything! Enable fresh start in client settings and restart the client
  • How to purchase with PayPal/OSRS/Crypto gold? You can purchase vouchers from other users
  • smart combat food increase endlessly cycling


    randalthor

    Recommended Posts

    http://pastebin.com/udK0i5f5

     

    My logic for this Edgeville man script is to start out withdrawing 1 trout each time I bank. I only bank when my inventory is full not when I'm out of food. If my health falls below 10% I increase the amount of trout I withdraw from the bank each time by one and start banking when I run out of food. Ideally this will allow accounts with varying levels and defense to adjust to the optimum amount of trout to  withdraw and I will not have to worry about withdrawing too much trout and limiting looting or too little and dying. 

     

    Unfortunately the following happens when I run my script after attacking guards to drop my hp on my str pure below 10%.

     

    emergency eat //expected because this case has the option that increases food withdrawn

    increase food withdraw amount

     

    go to bank

    withdraw 2 trout

    run to men

    eat all trout

    increase food withdraw amount

     

    go to bank

    withdraw 3 trout

    run to men

    eat all trout

    increase food withdraw amount

     

    go to bank

    withdraw 4 trout

    run to men

    eat all trout

    increase food withdraw amount

     

    go to bank

    withdraw 5 trout

    run to men

    eat all trout

    increase food withdraw amount

     

    go to bank

    withdraw 6 trout

    run to men

    eat all trout

     

    this pattern continues, not sure if all the way to 28 and higher but probably. Also, none of the other actions including looting and fighting are called after this cycle starts.

     

    For the life of me I can't find why this is happening. I traced the action route on paper and it looks like the withdraw amount should only increase by 1 each time the players health drops  below 10%.

     

    Finally, for some reason in my bank() method the player is unable to open the door leaving the house if it is closed

     

    I appreciate any help finding the problem. Also advice about scripting and how I could write my script better are appreciated. I'm also interested if people think I should submit this script to the SDN once I solve these problems and add a GUI to it. Is there any demand for this type of bot?

     

    Link to comment
    Share on other sites

    getLocalPlayer().getHealthPercent()
    

    Will return 0 if you're not in combat (how RS works), try using getCombat().getHealthPercent() instead :)

     

    In the API is says getLocalPlayer().getHealthPercent() should return 100 out of combat:   http://dreambot.org/javadocs/org/dreambot/api/wrappers/interactive/Character.html#getHealthPercent--

     

    I know that already that is why I have a boolean to store the case. To trace the code:

    line 150: 

     if(getLocalPlayer().getHealthPercent() < 50 && !eat) {
                            eat = true;
    set boolean eat to true happens every time this if statement passes during the onLoop()
     
    line 111: regular eat State only returned when eat = true. Regular eat only returns when player is not currently in combat. This prevents unnecessary eating when the player could be dealing damage
     
    line 165 & 177: set eat to false for emergency eat and eat cases and then do action eat. This should prevent eating until eat is set to true again or health drops below 20%
     
    line 104: emergency eat: other case of eating when health is below 20% this State can occur when player is in combat
    I did find an error here though. I need to check if I have food to eat before returning emergency eat
     
    my logic was at line 106 & 107: if health is below 10%, set tooLittleFood to true, and lowLevel to true. The first boolean tells my program to increment food withdraw on bank(line 222) and the later variable causes the player to start banking when out of food(line 102). At line 224 I increase the amount of food to withdraw by 1 and then set the boolean triggering that back to false on line 225.
     
    If this logic was followed, the program should increase the food withdrawn each time by 1 for the duration the bot runs each time the player's health percent falls  below 10% and then continue fighting, looting, eating, and banking like normal.
     
    It all comes down to what the API means when it says:
     
    public int getHealthPercent()
    Get health percent of the current Character if in combat.
    Returns: the current Characters health percent if in combat, otherwise 100% outside of combat.
    Is the 100% when out of combat 100, or 0. I believe it is 100 otherwise my emergency eat state at line 104 would trigger whenever I was out of combat. That isn't happening.

    I did not know about the getCombat().getHealthPercent() method until now otherwise I would have done it instead of using those booleans to work around only being able to check health percent accurately when currently in combat. However, my workaround should still be working...

    Link to comment
    Share on other sites

    In the API is says getLocalPlayer().getHealthPercent() should return 100 out of combat:   http://dreambot.org/javadocs/org/dreambot/api/wrappers/interactive/Character.html#getHealthPercent--

     

    I know that already that is why I have a boolean to store the case. To trace the code:

    line 150: 

     if(getLocalPlayer().getHealthPercent() < 50 && !eat) {
                            eat = true;
    set boolean eat to true happens every time this if statement passes during the onLoop()
     
    line 111: regular eat State only returned when eat = true. Regular eat only returns when player is not currently in combat. This prevents unnecessary eating when the player could be dealing damage
     
    line 165 & 177: set eat to false for emergency eat and eat cases and then do action eat. This should prevent eating until eat is set to true again or health drops below 20%
     
    line 104: emergency eat: other case of eating when health is below 20% this State can occur when player is in combat
    I did find an error here though. I need to check if I have food to eat before returning emergency eat
     
    my logic was at line 106 & 107: if health is below 10%, set tooLittleFood to true, and lowLevel to true. The first boolean tells my program to increment food withdraw on bank(line 222) and the later variable causes the player to start banking when out of food(line 102). At line 224 I increase the amount of food to withdraw by 1 and then set the boolean triggering that back to false on line 225.
     
    If this logic was followed, the program should increase the food withdrawn each time by 1 for the duration the bot runs each time the player's health percent falls  below 10% and then continue fighting, looting, eating, and banking like normal.
     
    It all comes down to what the API means when it says:
     
    public int getHealthPercent()
    Get health percent of the current Character if in combat.
    Returns: the current Characters health percent if in combat, otherwise 100% outside of combat.
    Is the 100% when out of combat 100, or 0. I believe it is 100 otherwise my emergency eat state at line 104 would trigger whenever I was out of combat. That isn't happening.

    I did not know about the getCombat().getHealthPercent() method until now otherwise I would have done it instead of using those booleans to work around only being able to check health percent accurately when currently in combat. However, my workaround should still be working...

    just do something like

    double percent = getSkills().getBoostedLevels(Skill.HITPOINTS)/getSkills().getRealLevel(Skill.HITPOINTS);
    
    Link to comment
    Share on other sites

    Here is the new code with getCombat().getHealthPercent() instead. Changes are at lines 39,104,106,114,153-155,169-174, and 182-187. I still have to check if the problem persists but I suspect it should. http://pastebin.com/JshRChAQ

     

    I checked this seemed to fix the problem. A problem still exists where emergencyEat is called twice once before and after banking so the increment is by 2, but I can change that by moving where I set the boolean to increment food withdrawal back to false.


    My edited and working code is here: http://pastebin.com/yHMcRDfY  I still welcome advice on any improvements that could be made to the code itself or the script's functionality besides adding a GUI which I plan to do next. Is there any reason to use to the getLocalPlayer().getHealthPercent method when the getCombat version works just as well without any limitations like being in combat?  Can someone think of an example of when the localPlayer version is better? 

    Link to comment
    Share on other sites

    Here is the new code with getCombat().getHealthPercent() instead. Changes are at lines 39,104,106,114,153-155,169-174, and 182-187. I still have to check if the problem persists but I suspect it should. http://pastebin.com/JshRChAQ

     

    I checked this seemed to fix the problem. A problem still exists where emergencyEat is called twice once before and after banking so the increment is by 2, but I can change that by moving where I set the boolean to increment food withdrawal back to false.

     

    My edited and working code is here: http://pastebin.com/yHMcRDfY I still welcome advice on any improvements that could be made to the code itself or the script's functionality besides adding a GUI which I plan to do next. Is there any reason to use to the getLocalPlayer().getHealthPercent method when the getCombat version works just as well without any limitations like being in combat? Can someone think of an example of when the localPlayer version is better?

    It's not just local player it's for all characters (npcs, other players)

    Link to comment
    Share on other sites

    Archived

    This topic is now archived and is closed to further replies.

    ×
    ×
    • Create New...

    Important Information

    We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.