Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Einstein

Premium Scripter
  • Content Count

    2,742
  • Joined

  • Last visited

  • Days Won

    117
  • Feedback

    100%

Einstein last won the day on March 30

Einstein had the most liked content!

Community Reputation

1,088 Excellent

About Einstein

  • Rank
    Energy = Mass × Speed of Light ²

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @ScriptsForMains This is what I believe to be a cleaner, more readable version of your script. Notable differences: I no longer cry when I read it Half the amount of lines of code The actions are split into multiple short methods Code takes heavy advantage of the API returned values All values are properly null checked, and the arrays are length checked Nested statements in such a way that the pyramid of doom is avoided You may or may not choose to adhere to this coding style.
  2. The code never executes. It can't get stuck. The only bad thing that can happen is a null pointer exception a few lines below, as this value is used without being checked. if (Interfaces.get(300, 1, 11).click("Close")) {
  3. I'm more than happy to help. It's a good thing that you question things instead of following advice blindly. This way you are more likely to get a solid understanding of what you are doing. You can keep the "redundancy" if you want, but try to find a more elegant solution. I would suggest using a simple boolean flag on which the script will decide whether or not it should continue running. As soon as the script encounters a problem from which it cannot safely recover, crash the script and log out. However, given how basic this script is, the only situation that could possibly render the script unable to continue would be running out of gold. All the other imaginable scenarios, from repeatedly failing to trade the NPC, to a retarded player closing the door when the bot attempts to enter the shop, can all be solved through code. Our API is more nuanced than it appears at first. A lot of methods return values based on the success of the interaction. You can learn how to use those methods and their return values to overcome any obstacle and make the script run indefinitely. It should be. I would say that making the code look nice is the third most important goal. The first being functionality (the code works), followed by efficiency (the code is time or resource efficient). By no means I am saying that you should remove features from the code for the sake of simplicity, but what I am saying is that the same thing can be written in many different ways, some being better than others. I'll re-write your script to show you an example in a few hours, when I'm back home.
  4. private int stuck=0; //used if anything in script fails (ends main loop) Variables that will only hold one of two values (0 and 1 in this case) should be of type boolean. The boolean values 'true' and 'false' are much more intuitive, they make the code easier to understand, and when compared to integer values, they are impossible to mistype (your compiler will immediately notify you if you typed "trie" instead of "true", but it won't do the same if you are using integer flags and typed 2 instead of 1). This might not be a problem when your code base is 200 lines long, but as you will get more experience and your programs will consist of tens of thousands of lines of code, those bad practices could end up costing you hours and hours of debugging. However, my suggestion would be to remove the "redundancy" system all together; I don't think it serves any purpose other than making the code extremely difficult to read.
  5. Thank you for perpetuating the insanity.
  6. Of course. Feel free to submit suggestions until July-August. That's when I will re-write the script.
  7. Shift dropping was originally implemented into the script, but it was removed after the script was re-written. It may or may not be re-added; I've yet to decide.
  8. Searching by ID is the most efficient1 way of finding game entities. The reason is that integer comparison will always be cheaper than string comparison. I've recently had a discussion with @Fluffee on this subject. In this particular test, the ID search was 23 times faster than name search. Sure, a 22 millisecond difference is completely neglectable, but it was a 2300% increase in efficiency nonetheless: Also, as @Miracle pointed out, IDs also have the huge advantage of allowing you to distinguish between two objects that have the same name. That's the recommended way to do it (if you don't need to use the ID trick mentioned above, of course). 1 - Source: TRiLeZ
  9. You should post the debug. Edit: Sorry, I mean: YOU SHOULD POST THE DEBUG!
  10. It's already implemented. You can use the progressive mode to stop at a certain level.
  11. This information can be found here: View > Runtime Information This seems to be a small User Interface error which can be safely ignored.
  12. Exactly. All my scripts are using https://imgur.com/ as a image host. If you wish to view the paint images, you will need to use proxies that allow you to connect to https://imgur.com/. If this is not possible, simply ignore the error message because the script will still work fine, it's just that the paint (visual only) will not be visible.
  13. The ISP is your internet service provider. Do you have any idea why you are unable to access the website while connecting through your proxies? Can you access the website without the proxies?
  14. The default delay between iterations used to be 5 milliseconds. Source: TRiLeZ At the time of writing, the delay appears to be 10 ms, which was probably changed after Condition got deprecated. Whether you should further increase this delay or not depends entirely on your view on resource efficiency. Pros: Increased efficiency: checking a condition 100 times / second is redundant, as the game itself updates every 600 ms. Cons: Bloats the code. The efficiency gains are marginal, as most users only run 1 instance of the script at a time. I would personally increase the delay only if the said condition is critical to the script's execution and the code is executed very often during runtime, so it would actually make a difference.
×
×
  • Create New...