Tweeboy

I've found it to suck at generating code from scratch. Even if I provide instructions I still have to make a lot of edits. And these are edits beyond converting DB2>DB3, which will happen a lot because GPT likes to use DB2 However, if you provide some code as a starting point and then describe the desired script logic/changes you are seeking that it can help add features pretty seamlessly. Great at expanding on an existing script you've written.

I have personal accounts I play legitimately on the same PC I write and test scripts. Lost counts of how many accounts have been banned on the same IP. My personal accounts HAVE interacted with my bot accounts (my mega rares were all funded by dreambot) and I haven't been ban hammered yet. However I've only sold GP to friends, so my bot accounts aren't RWTing as much as others. Unless you're trying to sell a ton of GP I wouldn't stress about it too much (until you expand beyond one side account).

This will execute code more consistently around each game tick. This is additional code that would be executed in addition to your onLoop()/execute(). You could execute Sleep.sleepTick(); followed by return 0; in your main loop to mimic this kind of functionality, but that then holds your script hostage while it sleeps for the game tick. The best use-case I can think of for this, is prayer flicking. You can have the onGameTick() handle flawless prayer flicking, while the rest of your script focuses on the rest of your script's logic.

Glad to hear did you have menu manipulation on? I'm going to play around with this script over the weekend to see if I can fix that, because I've had this happen to me infrequently as well. You may need to increase your mouse speed, try increasing it all the way (Always Hop) first to see if that casts more consistent, and either leave it at that or decrease it to whatever you're comfortable with. The higher XP rates need you to pretty consistently cast all 3 spells each cycle. Menu Manipulation does make this script run much more consistent I'll see if I can play around with the delays between casts to make it more consistent at lower mouse speeds EDIT: Ran a few tests. Rates close to 200k likely no longer possible but it does appear to be casting much more consistently. The higher your mouse speed the better the xp rate. I'll run a few more tests throughout the weekend and push an update if all goes well.

It is not meant to successfully cast the spell; you must ensure you have AT LEAST -65 Magic Bonus The script is meant to splash a single target

Hey I haven't tested them all, but I have setup quickstart params for this script. This will be available in the next version.. The main post will be updated to outline all of the params available. You'll still need runes in your inventory. Hey unfortunately how my script is currently setup, this would require me to do a lot of rewriting which I cannot do anytime soon due to time constraints. The delay exists to handle the multi-skill functionality, which I'd recommend taking advantage of! Low Alch + Curse will get you to 55+ very quickly, post up at something like chickens or seagulls and you'll have it in a couple hours. Should be fixed in the next update, the current version on the SDN will ONLY alch noted items due to an issue with the script logic

Not yet I've just been lazy lol, I will add this to the next update! Can you post your settings here or DM me? I am investigating a bug where sometimes the script fails to cast stun and runs towards the target NPC before alching/teleing but so far I have not seen it happen consistently. If it is consistently happening to you I'd like to investigate further. Here's a 4 hour run at Ardy, doing tele-alch-stun for almost 200k xp an hour

This should just use the default mouse. I just ran the script for a few hours without menu manipulation and did not see any erratic. Could you describe what you saw the script do? When/where did you see strange mouse movement? Feel free to post in this thread or DM me! I will push an update later this week regardless to fix a small bug I encountered & update the mining logic as a fail safe for any wild mouse movement

This script mines coal to superheat steel bars in the Lumbridge Swamp mine. Requires 31+ Mining, 43+ Magic, 30+ Smithing, Staff of Fire. Need plenty of Nature Runes and Iron Ore to keep it running. It should support any pickaxe, but I haven't tested anything below adamant... it will upgrade to Rune pickaxe after 41 mining, if you have one in the bank Instructions: Progress Reports:

Next update will have a GUI, now the user can decide whether or not to have the script cook / bank.

Once client is back up I will test some changes & update this script I will test the latest version once the client is back up, ensure you have the item spelled EXACTLY as it is in-game. It is looking for an exact String match P2P Teleports & P2P Combat Spells will be added in the next version. It will alch whatever item you enter in the GUI Going to add an "Alch All Noted" option as well, so you can stack your inventory with various alchables and the script would go through each and alch them until your inventory no longer contains noted items. Good for lots of individual noted items (maybe crank out some alchs on an ironman idk). Think there's several scripts that already do this. I will release a standalone script that withdraws iron ore from bank and mines coal to superheat in lumbridge swamp.

Assuming Criteria Y is never valid unless Criteria X is first valid You could set Leaf A's accept condition to be ((Criteria X) && (!Criteria Y)) Specific to MLM what are your criteria you are trying to monitor/manage? Your boolean approach works too and may be better for monitoring the MLM sack since you can force it true, have it collect all the ore, then force it to false to go back to your miningLeaf

The script will need to open the bank at least once to create a Bank Cache The Bank Cache will remain empty until then https://dreambot.org/javadocs/org/dreambot/api/methods/container/impl/bank/Bank.html#getBankHistoryCache()

TaskScript uses TaskNodes to perform your script's function. Instead of managing your script's logic within the main onLoop(), you will create several TaskNodes to break up the script into different tasks TaskNodes have three methods associated with them: boolean accept() - this is the condition that must be met in order to trigger the TaskNode. int execute() - think of your AbstractScript's onLoop(). This executes the actions/logic we actually want to perform. int priority() - allows you to prioritize your TaskNodes. By default, TaskScript will iterate through your TaskNodes in the order you add them. The script will iterate through each task (either in priority order high to low, or in order that they've been added). If the accept() condition is found to be valid, the script will loop through that TaskNode's execute(). I will use a basic woodcutting script as an example. In the onStart() of our main class, we will need to add our nodes: @Override public void onStart() { addNodes(new BankTask(), new DropTask(), new ChopTask()); } First the script would iterate through our BankTask. So long as the conditions of accept() are found to be true, we will loop through BankTask.execute(). Once we've deposited our logs, this TaskNode will no longer be true (inventory is NOT full) and the script will move onto the next TaskNode: public class BankTask extends TaskNode { @Override public boolean accept() { return Inventory.isFull() && !isDrop; //isDrop is an internal boolean determined by the user within the GUI } @Override public int execute() { //Logic for Banking & depositing logs return 1000; } } Then the script would iterate through your DropTask, depending on the state of boolean isDrop: public class DropTask extends TaskNode { @Override public boolean accept() { return Inventory.isFull() && isDrop; //isDrop is an internal boolean determined by the user within the GUI } @Override public int execute() { //Logic for Dropping inventory of logs return 1000; } } If neither of our above TaskNodes return a valid accept() condition, the script would move onto the ChopTask(). In this example, I left the accept() as true since I know the script will only get to this node, if DropTask & BankTask are NOT valid. You're welcome to add a condition to be met (for example, verifying treeArea.contains(Players.getLocal()) ) public class ChopTask extends TaskNode { @Override public boolean accept() { return true; } @Override public int execute() { //Logic for Walking to the tree location & chopping desired tree return 1000; } } Once you've flushed out the execute() logic in each, and add your nodes in the Main class onStart(), TaskScript will handle the rest. It will loop through BankTask>DropTask>ChopTask, checking to see which one returns accept() first, and then run the appropriate execute() If you so choose, you could break out the script logic into even more tasks (Bank, Drop, Travel, Chop, Idle). Some people may find this excessive. Do whatever you find easiest. I personally like breaking down my script into smaller tasks and will opt to use either TaskScript or TreeScript. Similar to the previous poster, I learned using TreeScript at first (specifically this implementation), but I do find it overkill for simple scripts and have been using TaskScript far more often now. In TaskScript, your script logic is executed within each TaskNode. The script will check Task accept() > Task execute() if valid In TreeScript, your script logic is executed within each Leaf, which are stored in Branches. The script will check the Branch accept() > check the Leaf accept() if valid > Leaf execute() if valid.