-
Posts
2314 -
Joined
-
Last visited
-
Days Won
6 -
Feedback
100%
Everything posted by Explv
-
leaked https://unsee.cc/nigepobu/
-
Is Bethesda actually releasing Skyrim again for the 7th time?
Explv replied to ez11's topic in Spam/Off Topic
It's called business bro. Nerdy nerds will buy Skyrim again just so they can play it on their dumb Nintendo. It's easy cash money for Bethesda, and probably quite a lot of it, which will help fund their future titles. It's not like they haven't released any games since Skyrim, they have. It just happens that Skyrim is probably one of the best games in recent times, and the most successful game their studio has made, and so they can resell it easily. Why tf wouldn't they? I'm sure they're working on the next elder Scrolls, they're just taking their time to make it good. -
Game of thrones?!?!!!!!?!! Westworld Stranger things Better call Saul Taboo Prison break is good for first few seasons Lost
-
What IRL things have you purchased with the money you made from Runescape?
Explv replied to koszmar's topic in Spam/Off Topic
A gat, 2016 Benz and pizza -
@reiska You cannot make API calls like myPosition() before onStart() is called. It doesn't make any sense for that to be there anyway because you'll only get your position once. You should do it onLoop after you walk. You also have a pair of {} after your call to walk() that shouldn't be there.
-
This is why "States" suck: What looks cleaner, this: enum State { CHOP, WALK_TO_BANK, WALK_TO_TREES, BANK } @Override public int onLoop() throws InterruptedException { switch(getState()) { case CHOP: chop(); break; case WALK_TO_BANK: getWalking().... break; case WALK_TO_TREES: getWalking().... break; case BANK: bank(); break; } return 0; } private State getState() { if (whatever) { return State.BANK; } else if (whatever) { return State.WALK_TO_BANK; } else if (whatever) { return State.WALK_TO_TREES; } else { return State.CHOP; } } Or this? : @Override public int onLoop() throws InterruptedException { if (whatever) { chop(); } else if (whatever) { getWalking().... } else if (whatever) { bank(); } else { getWalking().... } } Unless you are completely blind, I think you would agree the second is far more readable and much less code. Instead of having to look in a different method for the conditions, they are right there next to the code I am executing when they're satisfied. I don't need to maintain a redundant enum either. People will argue that using "States" are cleaner, however this is probably because they are not making use of the DRY principle, not making effective use of methods etc. and without "States" they would just throw all of their code into onLoop. As for "Tasks" or "Nodes", they have the exact same issues as "States" and more. People will argue they are cleaner because now each of their actions is in a nice self contained class, and the condition is in there too. However using this pattern you have now even less of an overview of the script as you did with states, and it's even harder to debug. Consider this: List<Node> someRandomAssNodes = new ArrayList<>(); @Override public int onLoop() throws InterruptedException { for (Node node : someRandomAssNodes) { if (node.validate()) { node.execute(); } } return 0; } The problem with this is that now in order to figure out how this script will execute I need to go into each of those Node classes, in the same order that you add them to the List and look at each of the validate methods and try and figure out how they all fit together: I mean, that pattern is pretty bonkers don't you think? Instead of having: WalkToBankNode ChopNode BankNode WalkToTreesNode DoSomeOtherShitIDKNode Why not just just write something simple, and easy to understand like my previous example. IF your script gets massively complex, then you should be making use of OOP principles to simplify it. You still don't need to use a weird 'Node' or 'Task' pattern, you can have a generic banking class without needing to add a validate method inside of it, and you can have a mining class without having a validate method in there either. Sorry if the some of the syntax is off, or I rambled.
- 20 replies
-
- 14
-
-
I personally use neither. "States" are a complete waste of space and makes your code far less readable. And if by tasks you mean classes with a validate and execute method, those are just as shitty as states, except instead of having all your conditions in one weird method they're now split up in different classes. You shouldn't really follow any of the weird design patterns people post on here Structure your script how you would any other Java program. Use design patterns appropriately and don't be a ?, create your own design patterns if an existing one doesn't work
-
I have also pushed a change for fire runecrafting, once the SDN is updated you will have the option to use a ring of dueling for faster fire rune runs.
-
This is now fixed on the SDN
-
Yep I can see the bug, will push a fix tonight. Thanks. Thanks, i'll keep it in mind as a possible future enhancement I think some users are still having issues with GUI saving / loading. I will be investigating that tomorrow, once fixed I will then add the ability to launch from the command line.
-
Pushed a fix, will be available when the SDN is next updated.
-
You're thinking about it completely wrong. It doesn't make sense for getLastRequestingPlayer to be null unless no one has traded you. What you should do is have a global boolean variable, let's call it shouldTrade. You initialise shouldTrade to false. Then you add a message listener using getBot().addMessageListener(MessageListener listener) or override the onMessage(Message message) method in your script class. Inside the onMessage method you then check if the message is of type RECEIVED_TRADE. If it is of that type set shouldTrade to true. In onLoop you check if shouldTrade is true, if it is then you can begin trading. Once the trade is complete, set shouldTrade to false. There are other ways to do it, but that's probably the simplest
-
Yep that's the issue, I will take a look at fixing it this weekend. Thanks
-
Try going to pollnivneach with an empty inventory. Will try to add a fix later Will push a fix tonight
-
You could try checking getBot().isLoaded() I will try it out myself tonight and update the snippet usage. I also have some additional account status checks I will be adding to the handler.
-
This should now be fixed on the SDN What do you mean by the menu doesn't load properly? It works fine for me, perhaps saving or loading messed it up? I will take a look at saving and loading, just avoid it for now.
-
Write 100 good scripts
-
Have you tried following these steps?
-
Pushed a fix for Canifis agility course, it will be available when the SDN is next updated (I will post here again). Thanks
-
Damn, that's the one course I didn't test. I'll push a fix for the issue tonight.
-
-
Hello hello hi Hope you enjoy your stay