Deep Slayer

@ImLife
 
Hey mate,
//this solution was already given to you by someone else, just add the dodging logic.
Tile playerTile = Players.getLocal().getTile(); List<GraphicsObject> graphicsObjects = Client.getGraphicsObjects(); for (GraphicsObject graphicsObject : graphicsObjects) { if (graphicsObject != null && graphicsObject.getTile().equals(playerTile)) { log("about to take damage"); //add your dodging logic here break; } } //all u have to do for the brazier breaking is check for a unique characteristic of the projectile being fired, in this case it's the height. List<Projectile> projectiles = Client.getProjectiles(); for (Projectile projectile : projectiles) { if (projectile.getID() == 501 && projectile.getHeight() == -1268 ) { log("brazier is about to break"); //add your dodging logic here break; } }  
you might want to filter out which brazier the projectile is going to as well, its a pretty easy fix

I’d like to share my project I've been working on recently, the Modular State Machine (MSM) for DreamBot, designed for smooth sequential execution in bot scripts. MSM uses DreamBot’s onLoop cycle to maintain awareness of game updates while advancing through tasks without re-evaluating the entire state tree each cycle. This setup allows MSM to handle complex task sequences, skip steps if conditions change, and execute multi-step actions across cycles efficiently. Each module acts as a reusable building block, making it easy to create adaptable, responsive bot scripts.
Since MSM is still new, it may have a few quirks to work out. It’s by no means perfect, but the current design should be useful for creating adaptable, sequential bot tasks in DreamBot.
Modular State Machine for DreamBot
github: https://github.com/deepslayer/Modular-State-Machine-for-DreamBot
Overview
The Modular State Machine (MSM) is an adaptable and efficient state machine framework designed specifically for DreamBot scripting, enabling streamlined, responsive bot behavior. MSM uses modular state management, leveraging DreamBot’s onLoop cycle to allow background processing between bot actions. This approach allows for efficient and highly responsive scripts, prioritizing a structured, linear flow ideal for building scalable, complex bot logic.
 
Components and Features
ActionState
Core Task Management: Represents individual tasks within the bot's logic and includes lifecycle methods (enter(), execute(), exit()) for controlled initiation, execution, and termination of tasks. Loop Integration: Operates during DreamBot's onLoop cycle, allowing for consistent background processing between bot actions. This keeps the bot responsive to real-time game updates and events. No isValid() Requirement: Typically part of a SequenceState, ActionStates do not require individual isValid() methods. The SequenceState itself contains the isValid() check, simplifying the logic by executing each ActionState in the sequence without additional validity checks. Flexible Task Completion: Can mark itself as complete using markComplete() or by overriding isComplete(). This allows actions within a sequence to skip specific steps if conditions make them unnecessary, providing adaptability within a predefined sequence. Partial Task Completion: Supports early returns, enabling incremental task progress that resumes exactly where it left off in the next loop. This is ideal for complex, multi-step tasks that may require multiple cycles to complete fully. DecisionState
Adaptive Decision-Making: Provides dynamic control over nested substates by selecting the next state to execute based on current conditions. Controlled, Linear Flow: Instead of looping through nested substates, it identifies and activates a valid state in a single pass, then returns control to the main StateMachine. SequenceState
Sequential Task Handling with Early Exits: Manages a chain of subtasks, executing each in a fixed order. Each substate can exit early and move on to the next based on custom conditions defined in the isComplete() method. This allows for a flexible, condition-based progression through the sequence, ideal for routines that may need to adapt mid-sequence. Modular Hierarchy Support: Can be nested within DecisionState or another SequenceState, or used standalone, offering a flexible structure for linear task sequences without the need for re-evaluation each loop cycle. Efficient Control Return: Once all substates are completed, control automatically returns to its parent, whether that's a DecisionState, another SequenceState, or the root StateMachine. SelectorState
Selective Action within Sequence: SelectorState  allows for flexible decision-making within a sequence, enabling a choice among multiple substates rather than fixed sequential execution. It is similar to DecisionState but placed within a SequenceState, allowing for non-linear action selection in a structured sequence. Adaptive, Non-Sequential Execution: Unlike SequenceState, SelectorState evaluates a range of possible substates and selects one to activate based on specified conditions. Once a substate is selected and marked complete, SelectorState returns control to its parent SequenceState. Lifecycle Management: Includes methods for lifecycle control (enter(), execute(), exit()) for structured entry, task execution, and exit, maintaining continuity within the parent sequence. During each execution cycle, SelectorState evaluates its substates and selects a valid one to activate. Partial Task Completion within Sequence: Just as with ActionState, substates within SelectorState can complete incrementally, enabling tasks to span multiple cycles if needed. Once a substate completes, SelectorState returns to the parent SequenceState, resuming its place within the broader sequence. StateMachine
Centralized Control: Acts as the root manager for all states, handling transitions based on validity and completeness. Loop-Driven Execution: All state transitions and updates occur within DreamBot's onLoop function, allowing individual states to run without blocking background processes.  


 
How Modular State Machine Differs from TreeScript
Both the Modular State Machine and DreamBot's TreeScript offer robust frameworks for state management but differ significantly in structure:
Execution Flow and Background Responsiveness
Modular State Machine (MSM): Utilizes DreamBot's onLoop cycle for efficient decision-making and action execution. MSM processes conditions from the root when making decisions, determining which path or state to activate. Once a state is selected, MSM executes actions directly without re-evaluating conditions from the root, allowing for efficient sequential execution. It returns control back to onLoop between each cycle, enabling the game to process updates (such as inventory changes, NPC changes, or health checks) before the next action. This approach maintains both performance and responsiveness in dynamic, sequential tasks. TreeScript: Also returns to the root after each onLoop pass, re-evaluating the tree to locate the next valid Leaf node. While this supports organized decision-making, it requires condition checks from the root each cycle, which can add overhead in complex scripts with many branches. MSM's direct, linear action execution minimizes repeated evaluations, enhancing efficiency while still supporting game updates between cycles. Modularity and State Reusability
Modular State Machine (MSM): Designed for flexible modularity, allowing states to be organized both sequentially and conditionally through SequenceState, SelectorState and DecisionState. This structure enables handling of sequential tasks without complex tracking mechanisms. Actions can be arranged in a predefined order within a SequenceState, which automatically manages progression. Each action within the sequence can independently determine completion status using markComplete() and isComplete() methods, allowing specific actions to skip or finish early based on conditions. This adaptive setup reduces the need for additional flags and makes MSM's modular sequences reusable across different workflows. TreeScript: Structured as a branching hierarchy of Branch and Leaf nodes, optimized for conditional decision-making rather than linear task sequences. Performing a series of sequential actions often requires multiple boolean flags to track progress between Leaf nodes, as the framework lacks a native way to enforce order within a single branch. While effective for certain hierarchical flows, this becomes cumbersome when handling sequential tasks, making it less suited for workflows that require ordered actions without extensive flagging. Hierarchical and Controlled Flow
Modular State Machine: Uses indexing and state tracking within each SequenceState, SelectorState and DecisionState, allowing execution of substates in sequence without deep recursive calls. It returns control to the root StateMachine between each loop and only re-evaluates conditions from the root when making new decisions. This design keeps execution layers shallow and efficient, improving performance for complex scripts. TreeScript: Maintains a structured tree hierarchy with Branch and Leaf nodes. Each Branch sequentially evaluates its children, with control returning to the root on each loop. While not recursive in execution, its structure requires repeated condition checks from the root to Leaf nodes in every cycle, which can increase CPU usage as script complexity grows. In contrast, MSM executes actions directly in sequence without re-evaluating conditions from the root each cycle, optimizing for performance in sequential tasks. Incremental Task Completion and Early Returns
Modular State Machine: Allows partial task completion within states. Each ActionState can perform a partial task and return to the main onLoop cycle, resuming exactly where it left off on the next loop. This fine control is ideal for tasks needing multiple cycles to complete. TreeScript: Executes Leaf nodes based on conditional validity but doesn't inherently support partial task completion within branches. It re-evaluates each branch each loop to locate the next valid action node.  

______________________________________________________________________________________________________________________________________________
How Modular State Machine Differs from TaskScript
1.      Execution Flow and Task Selection
MSM processes each task in sequence through onLoop, re-evaluating conditions only when switching states. Once active, tasks run to completion or skip as conditions dictate, which avoids frequent re-evaluation and focuses on sequential flow. TaskScript evaluates all added TaskNodes every loop cycle and selects the highest-priority task whose accept() condition is met. While effective for priority-based scripts, this structure requires repeated priority checks, which can add overhead as tasks increase. 2.      Modularity and Task Order
MSM organizes tasks using SequenceState and DecisionState for flexible linear and conditional flows. Actions can progress in sequence, skip steps, or be conditionally activated, allowing MSM’s modular blocks to be reused and arranged easily across scripts. TaskScript handles tasks individually through TaskNodes, each with its own priority() and accept() condition. Tasks with higher priority() values take precedence, but sequential ordering must be manually controlled through additional checks or flags, making strict task sequences more complex to manage. 3.      Control Efficiency and Layer Depth
MSM maintains shallow execution depth by only using root re-evaluation when changing states, which avoids multiple conditional checks and enhances performance in complex, multi-step scripts. TaskScript evaluates each node’s priority() and accept() condition every cycle, keeping the framework simple but potentially increasing CPU usage as complexity grows. 4.      Partial Completion and Reusability
MSM supports partial task completion within states, allowing tasks to return to onLoop mid-process and resume on the next loop. This capability is valuable for multi-step tasks needing flexibility. TaskScript executes each TaskNode to completion once selected but lacks inherent support for partial completions, meaning complex actions must be split or managed with additional tracking for incremental progression.  

I’d like to share my project I've been working on recently, the Modular State Machine (MSM) for DreamBot, designed for smooth sequential execution in bot scripts. MSM uses DreamBot’s onLoop cycle to maintain awareness of game updates while advancing through tasks without re-evaluating the entire state tree each cycle. This setup allows MSM to handle complex task sequences, skip steps if conditions change, and execute multi-step actions across cycles efficiently. Each module acts as a reusable building block, making it easy to create adaptable, responsive bot scripts.
Since MSM is still new, it may have a few quirks to work out. It’s by no means perfect, but the current design should be useful for creating adaptable, sequential bot tasks in DreamBot.
Modular State Machine for DreamBot
github: https://github.com/deepslayer/Modular-State-Machine-for-DreamBot
Overview
The Modular State Machine (MSM) is an adaptable and efficient state machine framework designed specifically for DreamBot scripting, enabling streamlined, responsive bot behavior. MSM uses modular state management, leveraging DreamBot’s onLoop cycle to allow background processing between bot actions. This approach allows for efficient and highly responsive scripts, prioritizing a structured, linear flow ideal for building scalable, complex bot logic.
 
Components and Features
ActionState
Core Task Management: Represents individual tasks within the bot's logic and includes lifecycle methods (enter(), execute(), exit()) for controlled initiation, execution, and termination of tasks. Loop Integration: Operates during DreamBot's onLoop cycle, allowing for consistent background processing between bot actions. This keeps the bot responsive to real-time game updates and events. No isValid() Requirement: Typically part of a SequenceState, ActionStates do not require individual isValid() methods. The SequenceState itself contains the isValid() check, simplifying the logic by executing each ActionState in the sequence without additional validity checks. Flexible Task Completion: Can mark itself as complete using markComplete() or by overriding isComplete(). This allows actions within a sequence to skip specific steps if conditions make them unnecessary, providing adaptability within a predefined sequence. Partial Task Completion: Supports early returns, enabling incremental task progress that resumes exactly where it left off in the next loop. This is ideal for complex, multi-step tasks that may require multiple cycles to complete fully. DecisionState
Adaptive Decision-Making: Provides dynamic control over nested substates by selecting the next state to execute based on current conditions. Controlled, Linear Flow: Instead of looping through nested substates, it identifies and activates a valid state in a single pass, then returns control to the main StateMachine. SequenceState
Sequential Task Handling with Early Exits: Manages a chain of subtasks, executing each in a fixed order. Each substate can exit early and move on to the next based on custom conditions defined in the isComplete() method. This allows for a flexible, condition-based progression through the sequence, ideal for routines that may need to adapt mid-sequence. Modular Hierarchy Support: Can be nested within DecisionState or another SequenceState, or used standalone, offering a flexible structure for linear task sequences without the need for re-evaluation each loop cycle. Efficient Control Return: Once all substates are completed, control automatically returns to its parent, whether that's a DecisionState, another SequenceState, or the root StateMachine. SelectorState
Selective Action within Sequence: SelectorState  allows for flexible decision-making within a sequence, enabling a choice among multiple substates rather than fixed sequential execution. It is similar to DecisionState but placed within a SequenceState, allowing for non-linear action selection in a structured sequence. Adaptive, Non-Sequential Execution: Unlike SequenceState, SelectorState evaluates a range of possible substates and selects one to activate based on specified conditions. Once a substate is selected and marked complete, SelectorState returns control to its parent SequenceState. Lifecycle Management: Includes methods for lifecycle control (enter(), execute(), exit()) for structured entry, task execution, and exit, maintaining continuity within the parent sequence. During each execution cycle, SelectorState evaluates its substates and selects a valid one to activate. Partial Task Completion within Sequence: Just as with ActionState, substates within SelectorState can complete incrementally, enabling tasks to span multiple cycles if needed. Once a substate completes, SelectorState returns to the parent SequenceState, resuming its place within the broader sequence. StateMachine
Centralized Control: Acts as the root manager for all states, handling transitions based on validity and completeness. Loop-Driven Execution: All state transitions and updates occur within DreamBot's onLoop function, allowing individual states to run without blocking background processes.  


 
How Modular State Machine Differs from TreeScript
Both the Modular State Machine and DreamBot's TreeScript offer robust frameworks for state management but differ significantly in structure:
Execution Flow and Background Responsiveness
Modular State Machine (MSM): Utilizes DreamBot's onLoop cycle for efficient decision-making and action execution. MSM processes conditions from the root when making decisions, determining which path or state to activate. Once a state is selected, MSM executes actions directly without re-evaluating conditions from the root, allowing for efficient sequential execution. It returns control back to onLoop between each cycle, enabling the game to process updates (such as inventory changes, NPC changes, or health checks) before the next action. This approach maintains both performance and responsiveness in dynamic, sequential tasks. TreeScript: Also returns to the root after each onLoop pass, re-evaluating the tree to locate the next valid Leaf node. While this supports organized decision-making, it requires condition checks from the root each cycle, which can add overhead in complex scripts with many branches. MSM's direct, linear action execution minimizes repeated evaluations, enhancing efficiency while still supporting game updates between cycles. Modularity and State Reusability
Modular State Machine (MSM): Designed for flexible modularity, allowing states to be organized both sequentially and conditionally through SequenceState, SelectorState and DecisionState. This structure enables handling of sequential tasks without complex tracking mechanisms. Actions can be arranged in a predefined order within a SequenceState, which automatically manages progression. Each action within the sequence can independently determine completion status using markComplete() and isComplete() methods, allowing specific actions to skip or finish early based on conditions. This adaptive setup reduces the need for additional flags and makes MSM's modular sequences reusable across different workflows. TreeScript: Structured as a branching hierarchy of Branch and Leaf nodes, optimized for conditional decision-making rather than linear task sequences. Performing a series of sequential actions often requires multiple boolean flags to track progress between Leaf nodes, as the framework lacks a native way to enforce order within a single branch. While effective for certain hierarchical flows, this becomes cumbersome when handling sequential tasks, making it less suited for workflows that require ordered actions without extensive flagging. Hierarchical and Controlled Flow
Modular State Machine: Uses indexing and state tracking within each SequenceState, SelectorState and DecisionState, allowing execution of substates in sequence without deep recursive calls. It returns control to the root StateMachine between each loop and only re-evaluates conditions from the root when making new decisions. This design keeps execution layers shallow and efficient, improving performance for complex scripts. TreeScript: Maintains a structured tree hierarchy with Branch and Leaf nodes. Each Branch sequentially evaluates its children, with control returning to the root on each loop. While not recursive in execution, its structure requires repeated condition checks from the root to Leaf nodes in every cycle, which can increase CPU usage as script complexity grows. In contrast, MSM executes actions directly in sequence without re-evaluating conditions from the root each cycle, optimizing for performance in sequential tasks. Incremental Task Completion and Early Returns
Modular State Machine: Allows partial task completion within states. Each ActionState can perform a partial task and return to the main onLoop cycle, resuming exactly where it left off on the next loop. This fine control is ideal for tasks needing multiple cycles to complete. TreeScript: Executes Leaf nodes based on conditional validity but doesn't inherently support partial task completion within branches. It re-evaluates each branch each loop to locate the next valid action node.  

______________________________________________________________________________________________________________________________________________
How Modular State Machine Differs from TaskScript
1.      Execution Flow and Task Selection
MSM processes each task in sequence through onLoop, re-evaluating conditions only when switching states. Once active, tasks run to completion or skip as conditions dictate, which avoids frequent re-evaluation and focuses on sequential flow. TaskScript evaluates all added TaskNodes every loop cycle and selects the highest-priority task whose accept() condition is met. While effective for priority-based scripts, this structure requires repeated priority checks, which can add overhead as tasks increase. 2.      Modularity and Task Order
MSM organizes tasks using SequenceState and DecisionState for flexible linear and conditional flows. Actions can progress in sequence, skip steps, or be conditionally activated, allowing MSM’s modular blocks to be reused and arranged easily across scripts. TaskScript handles tasks individually through TaskNodes, each with its own priority() and accept() condition. Tasks with higher priority() values take precedence, but sequential ordering must be manually controlled through additional checks or flags, making strict task sequences more complex to manage. 3.      Control Efficiency and Layer Depth
MSM maintains shallow execution depth by only using root re-evaluation when changing states, which avoids multiple conditional checks and enhances performance in complex, multi-step scripts. TaskScript evaluates each node’s priority() and accept() condition every cycle, keeping the framework simple but potentially increasing CPU usage as complexity grows. 4.      Partial Completion and Reusability
MSM supports partial task completion within states, allowing tasks to return to onLoop mid-process and resume on the next loop. This capability is valuable for multi-step tasks needing flexibility. TaskScript executes each TaskNode to completion once selected but lacks inherent support for partial completions, meaning complex actions must be split or managed with additional tracking for incremental progression.  

I’d like to share my project I've been working on recently, the Modular State Machine (MSM) for DreamBot, designed for smooth sequential execution in bot scripts. MSM uses DreamBot’s onLoop cycle to maintain awareness of game updates while advancing through tasks without re-evaluating the entire state tree each cycle. This setup allows MSM to handle complex task sequences, skip steps if conditions change, and execute multi-step actions across cycles efficiently. Each module acts as a reusable building block, making it easy to create adaptable, responsive bot scripts.
Since MSM is still new, it may have a few quirks to work out. It’s by no means perfect, but the current design should be useful for creating adaptable, sequential bot tasks in DreamBot.
Modular State Machine for DreamBot
github: https://github.com/deepslayer/Modular-State-Machine-for-DreamBot
Overview
The Modular State Machine (MSM) is an adaptable and efficient state machine framework designed specifically for DreamBot scripting, enabling streamlined, responsive bot behavior. MSM uses modular state management, leveraging DreamBot’s onLoop cycle to allow background processing between bot actions. This approach allows for efficient and highly responsive scripts, prioritizing a structured, linear flow ideal for building scalable, complex bot logic.
 
Components and Features
ActionState
Core Task Management: Represents individual tasks within the bot's logic and includes lifecycle methods (enter(), execute(), exit()) for controlled initiation, execution, and termination of tasks. Loop Integration: Operates during DreamBot's onLoop cycle, allowing for consistent background processing between bot actions. This keeps the bot responsive to real-time game updates and events. No isValid() Requirement: Typically part of a SequenceState, ActionStates do not require individual isValid() methods. The SequenceState itself contains the isValid() check, simplifying the logic by executing each ActionState in the sequence without additional validity checks. Flexible Task Completion: Can mark itself as complete using markComplete() or by overriding isComplete(). This allows actions within a sequence to skip specific steps if conditions make them unnecessary, providing adaptability within a predefined sequence. Partial Task Completion: Supports early returns, enabling incremental task progress that resumes exactly where it left off in the next loop. This is ideal for complex, multi-step tasks that may require multiple cycles to complete fully. DecisionState
Adaptive Decision-Making: Provides dynamic control over nested substates by selecting the next state to execute based on current conditions. Controlled, Linear Flow: Instead of looping through nested substates, it identifies and activates a valid state in a single pass, then returns control to the main StateMachine. SequenceState
Sequential Task Handling with Early Exits: Manages a chain of subtasks, executing each in a fixed order. Each substate can exit early and move on to the next based on custom conditions defined in the isComplete() method. This allows for a flexible, condition-based progression through the sequence, ideal for routines that may need to adapt mid-sequence. Modular Hierarchy Support: Can be nested within DecisionState or another SequenceState, or used standalone, offering a flexible structure for linear task sequences without the need for re-evaluation each loop cycle. Efficient Control Return: Once all substates are completed, control automatically returns to its parent, whether that's a DecisionState, another SequenceState, or the root StateMachine. SelectorState
Selective Action within Sequence: SelectorState  allows for flexible decision-making within a sequence, enabling a choice among multiple substates rather than fixed sequential execution. It is similar to DecisionState but placed within a SequenceState, allowing for non-linear action selection in a structured sequence. Adaptive, Non-Sequential Execution: Unlike SequenceState, SelectorState evaluates a range of possible substates and selects one to activate based on specified conditions. Once a substate is selected and marked complete, SelectorState returns control to its parent SequenceState. Lifecycle Management: Includes methods for lifecycle control (enter(), execute(), exit()) for structured entry, task execution, and exit, maintaining continuity within the parent sequence. During each execution cycle, SelectorState evaluates its substates and selects a valid one to activate. Partial Task Completion within Sequence: Just as with ActionState, substates within SelectorState can complete incrementally, enabling tasks to span multiple cycles if needed. Once a substate completes, SelectorState returns to the parent SequenceState, resuming its place within the broader sequence. StateMachine
Centralized Control: Acts as the root manager for all states, handling transitions based on validity and completeness. Loop-Driven Execution: All state transitions and updates occur within DreamBot's onLoop function, allowing individual states to run without blocking background processes.  


 
How Modular State Machine Differs from TreeScript
Both the Modular State Machine and DreamBot's TreeScript offer robust frameworks for state management but differ significantly in structure:
Execution Flow and Background Responsiveness
Modular State Machine (MSM): Utilizes DreamBot's onLoop cycle for efficient decision-making and action execution. MSM processes conditions from the root when making decisions, determining which path or state to activate. Once a state is selected, MSM executes actions directly without re-evaluating conditions from the root, allowing for efficient sequential execution. It returns control back to onLoop between each cycle, enabling the game to process updates (such as inventory changes, NPC changes, or health checks) before the next action. This approach maintains both performance and responsiveness in dynamic, sequential tasks. TreeScript: Also returns to the root after each onLoop pass, re-evaluating the tree to locate the next valid Leaf node. While this supports organized decision-making, it requires condition checks from the root each cycle, which can add overhead in complex scripts with many branches. MSM's direct, linear action execution minimizes repeated evaluations, enhancing efficiency while still supporting game updates between cycles. Modularity and State Reusability
Modular State Machine (MSM): Designed for flexible modularity, allowing states to be organized both sequentially and conditionally through SequenceState, SelectorState and DecisionState. This structure enables handling of sequential tasks without complex tracking mechanisms. Actions can be arranged in a predefined order within a SequenceState, which automatically manages progression. Each action within the sequence can independently determine completion status using markComplete() and isComplete() methods, allowing specific actions to skip or finish early based on conditions. This adaptive setup reduces the need for additional flags and makes MSM's modular sequences reusable across different workflows. TreeScript: Structured as a branching hierarchy of Branch and Leaf nodes, optimized for conditional decision-making rather than linear task sequences. Performing a series of sequential actions often requires multiple boolean flags to track progress between Leaf nodes, as the framework lacks a native way to enforce order within a single branch. While effective for certain hierarchical flows, this becomes cumbersome when handling sequential tasks, making it less suited for workflows that require ordered actions without extensive flagging. Hierarchical and Controlled Flow
Modular State Machine: Uses indexing and state tracking within each SequenceState, SelectorState and DecisionState, allowing execution of substates in sequence without deep recursive calls. It returns control to the root StateMachine between each loop and only re-evaluates conditions from the root when making new decisions. This design keeps execution layers shallow and efficient, improving performance for complex scripts. TreeScript: Maintains a structured tree hierarchy with Branch and Leaf nodes. Each Branch sequentially evaluates its children, with control returning to the root on each loop. While not recursive in execution, its structure requires repeated condition checks from the root to Leaf nodes in every cycle, which can increase CPU usage as script complexity grows. In contrast, MSM executes actions directly in sequence without re-evaluating conditions from the root each cycle, optimizing for performance in sequential tasks. Incremental Task Completion and Early Returns
Modular State Machine: Allows partial task completion within states. Each ActionState can perform a partial task and return to the main onLoop cycle, resuming exactly where it left off on the next loop. This fine control is ideal for tasks needing multiple cycles to complete. TreeScript: Executes Leaf nodes based on conditional validity but doesn't inherently support partial task completion within branches. It re-evaluates each branch each loop to locate the next valid action node.  

______________________________________________________________________________________________________________________________________________
How Modular State Machine Differs from TaskScript
1.      Execution Flow and Task Selection
MSM processes each task in sequence through onLoop, re-evaluating conditions only when switching states. Once active, tasks run to completion or skip as conditions dictate, which avoids frequent re-evaluation and focuses on sequential flow. TaskScript evaluates all added TaskNodes every loop cycle and selects the highest-priority task whose accept() condition is met. While effective for priority-based scripts, this structure requires repeated priority checks, which can add overhead as tasks increase. 2.      Modularity and Task Order
MSM organizes tasks using SequenceState and DecisionState for flexible linear and conditional flows. Actions can progress in sequence, skip steps, or be conditionally activated, allowing MSM’s modular blocks to be reused and arranged easily across scripts. TaskScript handles tasks individually through TaskNodes, each with its own priority() and accept() condition. Tasks with higher priority() values take precedence, but sequential ordering must be manually controlled through additional checks or flags, making strict task sequences more complex to manage. 3.      Control Efficiency and Layer Depth
MSM maintains shallow execution depth by only using root re-evaluation when changing states, which avoids multiple conditional checks and enhances performance in complex, multi-step scripts. TaskScript evaluates each node’s priority() and accept() condition every cycle, keeping the framework simple but potentially increasing CPU usage as complexity grows. 4.      Partial Completion and Reusability
MSM supports partial task completion within states, allowing tasks to return to onLoop mid-process and resume on the next loop. This capability is valuable for multi-step tasks needing flexibility. TaskScript executes each TaskNode to completion once selected but lacks inherent support for partial completions, meaning complex actions must be split or managed with additional tracking for incremental progression.  

Blood runes option not showing up in GUI
 

nevermind i was using pure essence for nature runes XD

Dude, love this script. Works great once you know how to set it up. Currently running with Melee (lower stats) and getting around 500k gp per hour. I only run while working and can watch it as one time it skulled me which made me almost poop my pants. 
 
Some fixes or ideas (ill still use it either way)
Script freezes if pulling out a ring of wealth uncharged on initial start up. You have to pause the script to manually select gear and then this works as expected. 
If you have a ring of wealth equipped you will be teleported to the GE once inventory full/out of food/ or PKer close. This is great but, once the ring of wealth is out of charges this is not replaced with a fully charged ring from your bank. instead this switches to using the ring of dueling for teleports which means you have to run to at least level 20 wilderness.
Just because people are jerks you have run in with PKers who kill you just for fun. They usually hit you with a tele block and snare so you aren't getting away, it would be nice to have some kind of self defense mechanism placed into the script. Ideas below.
1-If tele blocked turn on protect from magic and save additional item prayer. Turn on auto retaliate, activate special, and smoke that guy. This is really fun if you can get to them as they are usually just wearing robes and don't have much food
2-if you are stuck and cant move it would be nice to burry the bones, this would show the PKer that they get less loot for messing with you. 

doesnt work anymore

Every day I pray for colosal pouch, one day my dreams will come true

oh and pls add colosal pouch

Disclaimer: Roast incoming as per OP request.

Don''t read if your soft
You skipped adding void to onStart(), onStop(), and onPause() —This isn’t Python where you can just leave things out and hope for the best. You’re supposed to be writing code, not a guessing game for the compiler. This is the kind of sloppy mistake that makes other developers lose faith in humanity.
Path(), SelectionofRock(), Mine() —This isn’t some casual scripting language where you can play fast and loose with conventions. Java has standards, and you’re breaking them left and right. Do you want your code to look like a complete amateur wrote it? Because that’s exactly what this says.
You’ve turned Store()— into a recursive nightmare by calling onLoop() within it. Did you even think about what you were doing? This isn’t just bad—it’s potentially catastrophic. One simple mistake, and you’ve got a stack overflow that’ll crash your bot faster than you can fix it. 
Mine(), Furnace(), Smelt()—these methods are as empty as your commitment to finishing this script properly. You can’t just throw in a bunch of placeholders and call it a day. If you’re not going to bother coding the actual functionality, why even bother writing the method in the first place?
new Tile(0,0,0)— You might as well send your bot to nowhere and back. That’s just lazy. Put in some actual effort and use real coordinates. 
The D4t4 class is nothing more than a dumping ground for static variables. This is code clutter at its finest. You’re using static like it’s the only trick in your book. You’ve managed to turn a simple task into an over-complicated mess. It’s like you’re actively trying to make this harder for anyone else (or even yourself) to maintain.
A binary dice roll to select a rock—brilliant. What’s next, flipping a coin to decide if the bot should work or crash? This is lazy, uninspired coding. How about putting in some logic that actually makes sense? Instead, you’re relying on randomness to get the job done, and it shows.
D4t4? Trying to be edgy or cool with that name? All you’re doing is making your code look ridiculous. Naming conventions are there for a reason, and you’ve ignored them completely. No one’s impressed with your creative spelling—it just makes the code harder to read and maintain.
You’ve turned the D4t4 class into an over-engineered disaster. There’s no reason this should be its own class. You’re making things unnecessarily complex, and for what? This isn’t clever design—it’s just making the code harder to follow and more prone to bugs.
Returning 0 every time? Great idea—if your goal is to burn out your bot in record time. This bot isn’t a race car, it doesn’t need to run full throttle with no breaks.
//To and //From—what is this, a treasure map? These comments tell me nothing about what the code does. If you’re going to comment, make it useful. Otherwise, you’re just wasting space and time. Put in some effort and write comments that actually help someone understand what’s going on.
The GUI() method is just sitting there doing nothing. Why even include it? This isn’t a museum; dead code has no place in your script. Either finish it or remove it, but don’t leave it hanging around like a reminder of all the things you didn’t bother to complete.
An empty onPaint() method? So you’re just here to waste space? This method is supposed to do something, anything, but you’ve left it blank. It’s like hanging an empty picture frame on the wall and calling it art.
Your control flow is a mess—random if-statements and switches with no real logic or purpose. It’s like you’re just throwing things at the wall and seeing what sticks. There’s no structure, no plan—just chaos. If you want your bot to actually do something, maybe take a step back and think about how the logic should flow instead of winging it.
You managed to get the ScriptManifest right, but that’s the easiest part of the script. It’s like you put all your effort into the intro and then just gave up.
Lastly but not least you labeled this as a WOODCUTTING script, yet you’re writing code for mining and smelting. Do you even know what your script is supposed to do? This is misleading at best, incompetent at worst.

https://github.com/deepslayer/TreeScriptExample/
 
TreeScriptExample
This repository demonstrates a hierarchical tree structure for scripting in DreamBot, an Old School RuneScape botting framework. The project showcases a Tree Branch Leaf framework that organizes bot tasks into a tree structure for better modularity and scalability.
Project Structure
The project is divided into packages that represent different levels of the tree hierarchy: high-level branches, low-level branches, and leaves.
Packages and Classes
highBranch
CombatBranch.java: This class represents a high-level branch in the tree structure. It contains logic for combat-related tasks and aggregates lower-level branches like MeleeCowBranch and RangeCowBranch.
SkillingBranch.java: This class represents a high-level branch for skilling tasks and aggregates branches like MiningBranch and WoodcuttingBranch.
leaves
AttackCowMeleeLeaf.java: This leaf class handles the logic for attacking cows using melee combat.
AttackCowRangeLeaf.java: This leaf class handles the logic for attacking cows using ranged combat.
BankInventoryLeaf.java: This leaf class handles the logic for banking inventory items.
ChopTreeLeaf.java: This leaf class handles the logic for chopping trees.
EatFoodLeaf.java: This leaf class handles the logic for eating food when the player's health is low.
MineOreLeaf.java: This leaf class handles the logic for mining ores.
lowBranch
MeleeCowBranch.java: This branch class checks if the player has a sword equipped and contains leaves that handle eating food and attacking cows with melee.
MiningBranch.java: This branch class checks if the player is equipped for mining and contains leaves that handle mining ores and related tasks.
RangeCowBranch.java: This branch class checks if the player has a bow equipped and contains leaves that handle eating food and attacking cows with ranged weapons.
WoodcuttingBranch.java: This branch class checks if the player is equipped for woodcutting and contains leaves that handle chopping trees and related tasks.
myscript
MyTreeScript.java: The main script class that initializes the tree structure and starts the script. It contains the root node and adds the top-level branches to it.
Framework Overview
The DreamBot Tree Branch Leaf framework is a hierarchical system where tasks are organized into a tree structure with a root node, branches, and leaves. Here's how the framework works:
TreeScript: The main class that initializes the tree structure and starts the script. It contains the root node.
Root: The top-level node that contains branches.
Branches: Intermediate nodes that contain other branches or leaves.
Leaves: The executable actions or tasks.
Execution Flow
The TreeScript class initializes the root node and adds top-level branches.
Each branch's isValid() method determines if it should be executed.
If a branch is valid, it iterates through its leaves to find a valid leaf.
The first valid leaf's onLoop() method is executed.
 
PLEASE NOTE THIS EXAMPLE IS OVER SIMPLIFIED FOR LEARNING PURPOSES

You Guys keep aksing for it, 
 
I think this weekend ill add it

been running the script from 72 to 85 RC, amazing script, highly recommend!
OP if you get the time, just like others have asked, Colossal pouch! please

okay, thanks so much for your help. this is a pretty good script, it's made me about 100m in coins so far in the last few weeks. i may just try to do a factory reset on my pc its been acting up lately. 

Script is making much more progress now with the anti movement. Appreciate you hearing the concerns. However theres still one small error. Every now and again the bot tries to pull food from the bank in this case Lobster and it says failed to withraw. Even with the lobster being right there in plain sight. Can you make it try again before it stops the script? Ive walked away a few times and come back to it being logged out and thats all logger says. Failed to withdraw food stopping script.

Amazing stuff.

I’d like to share my project I've been working on recently, the Modular State Machine (MSM) for DreamBot, designed for smooth sequential execution in bot scripts. MSM uses DreamBot’s onLoop cycle to maintain awareness of game updates while advancing through tasks without re-evaluating the entire state tree each cycle. This setup allows MSM to handle complex task sequences, skip steps if conditions change, and execute multi-step actions across cycles efficiently. Each module acts as a reusable building block, making it easy to create adaptable, responsive bot scripts.
Since MSM is still new, it may have a few quirks to work out. It’s by no means perfect, but the current design should be useful for creating adaptable, sequential bot tasks in DreamBot.
Modular State Machine for DreamBot
github: https://github.com/deepslayer/Modular-State-Machine-for-DreamBot
Overview
The Modular State Machine (MSM) is an adaptable and efficient state machine framework designed specifically for DreamBot scripting, enabling streamlined, responsive bot behavior. MSM uses modular state management, leveraging DreamBot’s onLoop cycle to allow background processing between bot actions. This approach allows for efficient and highly responsive scripts, prioritizing a structured, linear flow ideal for building scalable, complex bot logic.
 
Components and Features
ActionState
Core Task Management: Represents individual tasks within the bot's logic and includes lifecycle methods (enter(), execute(), exit()) for controlled initiation, execution, and termination of tasks. Loop Integration: Operates during DreamBot's onLoop cycle, allowing for consistent background processing between bot actions. This keeps the bot responsive to real-time game updates and events. No isValid() Requirement: Typically part of a SequenceState, ActionStates do not require individual isValid() methods. The SequenceState itself contains the isValid() check, simplifying the logic by executing each ActionState in the sequence without additional validity checks. Flexible Task Completion: Can mark itself as complete using markComplete() or by overriding isComplete(). This allows actions within a sequence to skip specific steps if conditions make them unnecessary, providing adaptability within a predefined sequence. Partial Task Completion: Supports early returns, enabling incremental task progress that resumes exactly where it left off in the next loop. This is ideal for complex, multi-step tasks that may require multiple cycles to complete fully. DecisionState
Adaptive Decision-Making: Provides dynamic control over nested substates by selecting the next state to execute based on current conditions. Controlled, Linear Flow: Instead of looping through nested substates, it identifies and activates a valid state in a single pass, then returns control to the main StateMachine. SequenceState
Sequential Task Handling with Early Exits: Manages a chain of subtasks, executing each in a fixed order. Each substate can exit early and move on to the next based on custom conditions defined in the isComplete() method. This allows for a flexible, condition-based progression through the sequence, ideal for routines that may need to adapt mid-sequence. Modular Hierarchy Support: Can be nested within DecisionState or another SequenceState, or used standalone, offering a flexible structure for linear task sequences without the need for re-evaluation each loop cycle. Efficient Control Return: Once all substates are completed, control automatically returns to its parent, whether that's a DecisionState, another SequenceState, or the root StateMachine. SelectorState
Selective Action within Sequence: SelectorState  allows for flexible decision-making within a sequence, enabling a choice among multiple substates rather than fixed sequential execution. It is similar to DecisionState but placed within a SequenceState, allowing for non-linear action selection in a structured sequence. Adaptive, Non-Sequential Execution: Unlike SequenceState, SelectorState evaluates a range of possible substates and selects one to activate based on specified conditions. Once a substate is selected and marked complete, SelectorState returns control to its parent SequenceState. Lifecycle Management: Includes methods for lifecycle control (enter(), execute(), exit()) for structured entry, task execution, and exit, maintaining continuity within the parent sequence. During each execution cycle, SelectorState evaluates its substates and selects a valid one to activate. Partial Task Completion within Sequence: Just as with ActionState, substates within SelectorState can complete incrementally, enabling tasks to span multiple cycles if needed. Once a substate completes, SelectorState returns to the parent SequenceState, resuming its place within the broader sequence. StateMachine
Centralized Control: Acts as the root manager for all states, handling transitions based on validity and completeness. Loop-Driven Execution: All state transitions and updates occur within DreamBot's onLoop function, allowing individual states to run without blocking background processes.  


 
How Modular State Machine Differs from TreeScript
Both the Modular State Machine and DreamBot's TreeScript offer robust frameworks for state management but differ significantly in structure:
Execution Flow and Background Responsiveness
Modular State Machine (MSM): Utilizes DreamBot's onLoop cycle for efficient decision-making and action execution. MSM processes conditions from the root when making decisions, determining which path or state to activate. Once a state is selected, MSM executes actions directly without re-evaluating conditions from the root, allowing for efficient sequential execution. It returns control back to onLoop between each cycle, enabling the game to process updates (such as inventory changes, NPC changes, or health checks) before the next action. This approach maintains both performance and responsiveness in dynamic, sequential tasks. TreeScript: Also returns to the root after each onLoop pass, re-evaluating the tree to locate the next valid Leaf node. While this supports organized decision-making, it requires condition checks from the root each cycle, which can add overhead in complex scripts with many branches. MSM's direct, linear action execution minimizes repeated evaluations, enhancing efficiency while still supporting game updates between cycles. Modularity and State Reusability
Modular State Machine (MSM): Designed for flexible modularity, allowing states to be organized both sequentially and conditionally through SequenceState, SelectorState and DecisionState. This structure enables handling of sequential tasks without complex tracking mechanisms. Actions can be arranged in a predefined order within a SequenceState, which automatically manages progression. Each action within the sequence can independently determine completion status using markComplete() and isComplete() methods, allowing specific actions to skip or finish early based on conditions. This adaptive setup reduces the need for additional flags and makes MSM's modular sequences reusable across different workflows. TreeScript: Structured as a branching hierarchy of Branch and Leaf nodes, optimized for conditional decision-making rather than linear task sequences. Performing a series of sequential actions often requires multiple boolean flags to track progress between Leaf nodes, as the framework lacks a native way to enforce order within a single branch. While effective for certain hierarchical flows, this becomes cumbersome when handling sequential tasks, making it less suited for workflows that require ordered actions without extensive flagging. Hierarchical and Controlled Flow
Modular State Machine: Uses indexing and state tracking within each SequenceState, SelectorState and DecisionState, allowing execution of substates in sequence without deep recursive calls. It returns control to the root StateMachine between each loop and only re-evaluates conditions from the root when making new decisions. This design keeps execution layers shallow and efficient, improving performance for complex scripts. TreeScript: Maintains a structured tree hierarchy with Branch and Leaf nodes. Each Branch sequentially evaluates its children, with control returning to the root on each loop. While not recursive in execution, its structure requires repeated condition checks from the root to Leaf nodes in every cycle, which can increase CPU usage as script complexity grows. In contrast, MSM executes actions directly in sequence without re-evaluating conditions from the root each cycle, optimizing for performance in sequential tasks. Incremental Task Completion and Early Returns
Modular State Machine: Allows partial task completion within states. Each ActionState can perform a partial task and return to the main onLoop cycle, resuming exactly where it left off on the next loop. This fine control is ideal for tasks needing multiple cycles to complete. TreeScript: Executes Leaf nodes based on conditional validity but doesn't inherently support partial task completion within branches. It re-evaluates each branch each loop to locate the next valid action node.  

______________________________________________________________________________________________________________________________________________
How Modular State Machine Differs from TaskScript
1.      Execution Flow and Task Selection
MSM processes each task in sequence through onLoop, re-evaluating conditions only when switching states. Once active, tasks run to completion or skip as conditions dictate, which avoids frequent re-evaluation and focuses on sequential flow. TaskScript evaluates all added TaskNodes every loop cycle and selects the highest-priority task whose accept() condition is met. While effective for priority-based scripts, this structure requires repeated priority checks, which can add overhead as tasks increase. 2.      Modularity and Task Order
MSM organizes tasks using SequenceState and DecisionState for flexible linear and conditional flows. Actions can progress in sequence, skip steps, or be conditionally activated, allowing MSM’s modular blocks to be reused and arranged easily across scripts. TaskScript handles tasks individually through TaskNodes, each with its own priority() and accept() condition. Tasks with higher priority() values take precedence, but sequential ordering must be manually controlled through additional checks or flags, making strict task sequences more complex to manage. 3.      Control Efficiency and Layer Depth
MSM maintains shallow execution depth by only using root re-evaluation when changing states, which avoids multiple conditional checks and enhances performance in complex, multi-step scripts. TaskScript evaluates each node’s priority() and accept() condition every cycle, keeping the framework simple but potentially increasing CPU usage as complexity grows. 4.      Partial Completion and Reusability
MSM supports partial task completion within states, allowing tasks to return to onLoop mid-process and resume on the next loop. This capability is valuable for multi-step tasks needing flexibility. TaskScript executes each TaskNode to completion once selected but lacks inherent support for partial completions, meaning complex actions must be split or managed with additional tracking for incremental progression.  

Thank you for releasing this, I will be using it!

I’d like to share my project I've been working on recently, the Modular State Machine (MSM) for DreamBot, designed for smooth sequential execution in bot scripts. MSM uses DreamBot’s onLoop cycle to maintain awareness of game updates while advancing through tasks without re-evaluating the entire state tree each cycle. This setup allows MSM to handle complex task sequences, skip steps if conditions change, and execute multi-step actions across cycles efficiently. Each module acts as a reusable building block, making it easy to create adaptable, responsive bot scripts.
Since MSM is still new, it may have a few quirks to work out. It’s by no means perfect, but the current design should be useful for creating adaptable, sequential bot tasks in DreamBot.
Modular State Machine for DreamBot
github: https://github.com/deepslayer/Modular-State-Machine-for-DreamBot
Overview
The Modular State Machine (MSM) is an adaptable and efficient state machine framework designed specifically for DreamBot scripting, enabling streamlined, responsive bot behavior. MSM uses modular state management, leveraging DreamBot’s onLoop cycle to allow background processing between bot actions. This approach allows for efficient and highly responsive scripts, prioritizing a structured, linear flow ideal for building scalable, complex bot logic.
 
Components and Features
ActionState
Core Task Management: Represents individual tasks within the bot's logic and includes lifecycle methods (enter(), execute(), exit()) for controlled initiation, execution, and termination of tasks. Loop Integration: Operates during DreamBot's onLoop cycle, allowing for consistent background processing between bot actions. This keeps the bot responsive to real-time game updates and events. No isValid() Requirement: Typically part of a SequenceState, ActionStates do not require individual isValid() methods. The SequenceState itself contains the isValid() check, simplifying the logic by executing each ActionState in the sequence without additional validity checks. Flexible Task Completion: Can mark itself as complete using markComplete() or by overriding isComplete(). This allows actions within a sequence to skip specific steps if conditions make them unnecessary, providing adaptability within a predefined sequence. Partial Task Completion: Supports early returns, enabling incremental task progress that resumes exactly where it left off in the next loop. This is ideal for complex, multi-step tasks that may require multiple cycles to complete fully. DecisionState
Adaptive Decision-Making: Provides dynamic control over nested substates by selecting the next state to execute based on current conditions. Controlled, Linear Flow: Instead of looping through nested substates, it identifies and activates a valid state in a single pass, then returns control to the main StateMachine. SequenceState
Sequential Task Handling with Early Exits: Manages a chain of subtasks, executing each in a fixed order. Each substate can exit early and move on to the next based on custom conditions defined in the isComplete() method. This allows for a flexible, condition-based progression through the sequence, ideal for routines that may need to adapt mid-sequence. Modular Hierarchy Support: Can be nested within DecisionState or another SequenceState, or used standalone, offering a flexible structure for linear task sequences without the need for re-evaluation each loop cycle. Efficient Control Return: Once all substates are completed, control automatically returns to its parent, whether that's a DecisionState, another SequenceState, or the root StateMachine. SelectorState
Selective Action within Sequence: SelectorState  allows for flexible decision-making within a sequence, enabling a choice among multiple substates rather than fixed sequential execution. It is similar to DecisionState but placed within a SequenceState, allowing for non-linear action selection in a structured sequence. Adaptive, Non-Sequential Execution: Unlike SequenceState, SelectorState evaluates a range of possible substates and selects one to activate based on specified conditions. Once a substate is selected and marked complete, SelectorState returns control to its parent SequenceState. Lifecycle Management: Includes methods for lifecycle control (enter(), execute(), exit()) for structured entry, task execution, and exit, maintaining continuity within the parent sequence. During each execution cycle, SelectorState evaluates its substates and selects a valid one to activate. Partial Task Completion within Sequence: Just as with ActionState, substates within SelectorState can complete incrementally, enabling tasks to span multiple cycles if needed. Once a substate completes, SelectorState returns to the parent SequenceState, resuming its place within the broader sequence. StateMachine
Centralized Control: Acts as the root manager for all states, handling transitions based on validity and completeness. Loop-Driven Execution: All state transitions and updates occur within DreamBot's onLoop function, allowing individual states to run without blocking background processes.  


 
How Modular State Machine Differs from TreeScript
Both the Modular State Machine and DreamBot's TreeScript offer robust frameworks for state management but differ significantly in structure:
Execution Flow and Background Responsiveness
Modular State Machine (MSM): Utilizes DreamBot's onLoop cycle for efficient decision-making and action execution. MSM processes conditions from the root when making decisions, determining which path or state to activate. Once a state is selected, MSM executes actions directly without re-evaluating conditions from the root, allowing for efficient sequential execution. It returns control back to onLoop between each cycle, enabling the game to process updates (such as inventory changes, NPC changes, or health checks) before the next action. This approach maintains both performance and responsiveness in dynamic, sequential tasks. TreeScript: Also returns to the root after each onLoop pass, re-evaluating the tree to locate the next valid Leaf node. While this supports organized decision-making, it requires condition checks from the root each cycle, which can add overhead in complex scripts with many branches. MSM's direct, linear action execution minimizes repeated evaluations, enhancing efficiency while still supporting game updates between cycles. Modularity and State Reusability
Modular State Machine (MSM): Designed for flexible modularity, allowing states to be organized both sequentially and conditionally through SequenceState, SelectorState and DecisionState. This structure enables handling of sequential tasks without complex tracking mechanisms. Actions can be arranged in a predefined order within a SequenceState, which automatically manages progression. Each action within the sequence can independently determine completion status using markComplete() and isComplete() methods, allowing specific actions to skip or finish early based on conditions. This adaptive setup reduces the need for additional flags and makes MSM's modular sequences reusable across different workflows. TreeScript: Structured as a branching hierarchy of Branch and Leaf nodes, optimized for conditional decision-making rather than linear task sequences. Performing a series of sequential actions often requires multiple boolean flags to track progress between Leaf nodes, as the framework lacks a native way to enforce order within a single branch. While effective for certain hierarchical flows, this becomes cumbersome when handling sequential tasks, making it less suited for workflows that require ordered actions without extensive flagging. Hierarchical and Controlled Flow
Modular State Machine: Uses indexing and state tracking within each SequenceState, SelectorState and DecisionState, allowing execution of substates in sequence without deep recursive calls. It returns control to the root StateMachine between each loop and only re-evaluates conditions from the root when making new decisions. This design keeps execution layers shallow and efficient, improving performance for complex scripts. TreeScript: Maintains a structured tree hierarchy with Branch and Leaf nodes. Each Branch sequentially evaluates its children, with control returning to the root on each loop. While not recursive in execution, its structure requires repeated condition checks from the root to Leaf nodes in every cycle, which can increase CPU usage as script complexity grows. In contrast, MSM executes actions directly in sequence without re-evaluating conditions from the root each cycle, optimizing for performance in sequential tasks. Incremental Task Completion and Early Returns
Modular State Machine: Allows partial task completion within states. Each ActionState can perform a partial task and return to the main onLoop cycle, resuming exactly where it left off on the next loop. This fine control is ideal for tasks needing multiple cycles to complete. TreeScript: Executes Leaf nodes based on conditional validity but doesn't inherently support partial task completion within branches. It re-evaluates each branch each loop to locate the next valid action node.  

______________________________________________________________________________________________________________________________________________
How Modular State Machine Differs from TaskScript
1.      Execution Flow and Task Selection
MSM processes each task in sequence through onLoop, re-evaluating conditions only when switching states. Once active, tasks run to completion or skip as conditions dictate, which avoids frequent re-evaluation and focuses on sequential flow. TaskScript evaluates all added TaskNodes every loop cycle and selects the highest-priority task whose accept() condition is met. While effective for priority-based scripts, this structure requires repeated priority checks, which can add overhead as tasks increase. 2.      Modularity and Task Order
MSM organizes tasks using SequenceState and DecisionState for flexible linear and conditional flows. Actions can progress in sequence, skip steps, or be conditionally activated, allowing MSM’s modular blocks to be reused and arranged easily across scripts. TaskScript handles tasks individually through TaskNodes, each with its own priority() and accept() condition. Tasks with higher priority() values take precedence, but sequential ordering must be manually controlled through additional checks or flags, making strict task sequences more complex to manage. 3.      Control Efficiency and Layer Depth
MSM maintains shallow execution depth by only using root re-evaluation when changing states, which avoids multiple conditional checks and enhances performance in complex, multi-step scripts. TaskScript evaluates each node’s priority() and accept() condition every cycle, keeping the framework simple but potentially increasing CPU usage as complexity grows. 4.      Partial Completion and Reusability
MSM supports partial task completion within states, allowing tasks to return to onLoop mid-process and resume on the next loop. This capability is valuable for multi-step tasks needing flexibility. TaskScript executes each TaskNode to completion once selected but lacks inherent support for partial completions, meaning complex actions must be split or managed with additional tracking for incremental progression.  

I’d like to share my project I've been working on recently, the Modular State Machine (MSM) for DreamBot, designed for smooth sequential execution in bot scripts. MSM uses DreamBot’s onLoop cycle to maintain awareness of game updates while advancing through tasks without re-evaluating the entire state tree each cycle. This setup allows MSM to handle complex task sequences, skip steps if conditions change, and execute multi-step actions across cycles efficiently. Each module acts as a reusable building block, making it easy to create adaptable, responsive bot scripts.
Since MSM is still new, it may have a few quirks to work out. It’s by no means perfect, but the current design should be useful for creating adaptable, sequential bot tasks in DreamBot.
Modular State Machine for DreamBot
github: https://github.com/deepslayer/Modular-State-Machine-for-DreamBot
Overview
The Modular State Machine (MSM) is an adaptable and efficient state machine framework designed specifically for DreamBot scripting, enabling streamlined, responsive bot behavior. MSM uses modular state management, leveraging DreamBot’s onLoop cycle to allow background processing between bot actions. This approach allows for efficient and highly responsive scripts, prioritizing a structured, linear flow ideal for building scalable, complex bot logic.
 
Components and Features
ActionState
Core Task Management: Represents individual tasks within the bot's logic and includes lifecycle methods (enter(), execute(), exit()) for controlled initiation, execution, and termination of tasks. Loop Integration: Operates during DreamBot's onLoop cycle, allowing for consistent background processing between bot actions. This keeps the bot responsive to real-time game updates and events. No isValid() Requirement: Typically part of a SequenceState, ActionStates do not require individual isValid() methods. The SequenceState itself contains the isValid() check, simplifying the logic by executing each ActionState in the sequence without additional validity checks. Flexible Task Completion: Can mark itself as complete using markComplete() or by overriding isComplete(). This allows actions within a sequence to skip specific steps if conditions make them unnecessary, providing adaptability within a predefined sequence. Partial Task Completion: Supports early returns, enabling incremental task progress that resumes exactly where it left off in the next loop. This is ideal for complex, multi-step tasks that may require multiple cycles to complete fully. DecisionState
Adaptive Decision-Making: Provides dynamic control over nested substates by selecting the next state to execute based on current conditions. Controlled, Linear Flow: Instead of looping through nested substates, it identifies and activates a valid state in a single pass, then returns control to the main StateMachine. SequenceState
Sequential Task Handling with Early Exits: Manages a chain of subtasks, executing each in a fixed order. Each substate can exit early and move on to the next based on custom conditions defined in the isComplete() method. This allows for a flexible, condition-based progression through the sequence, ideal for routines that may need to adapt mid-sequence. Modular Hierarchy Support: Can be nested within DecisionState or another SequenceState, or used standalone, offering a flexible structure for linear task sequences without the need for re-evaluation each loop cycle. Efficient Control Return: Once all substates are completed, control automatically returns to its parent, whether that's a DecisionState, another SequenceState, or the root StateMachine. SelectorState
Selective Action within Sequence: SelectorState  allows for flexible decision-making within a sequence, enabling a choice among multiple substates rather than fixed sequential execution. It is similar to DecisionState but placed within a SequenceState, allowing for non-linear action selection in a structured sequence. Adaptive, Non-Sequential Execution: Unlike SequenceState, SelectorState evaluates a range of possible substates and selects one to activate based on specified conditions. Once a substate is selected and marked complete, SelectorState returns control to its parent SequenceState. Lifecycle Management: Includes methods for lifecycle control (enter(), execute(), exit()) for structured entry, task execution, and exit, maintaining continuity within the parent sequence. During each execution cycle, SelectorState evaluates its substates and selects a valid one to activate. Partial Task Completion within Sequence: Just as with ActionState, substates within SelectorState can complete incrementally, enabling tasks to span multiple cycles if needed. Once a substate completes, SelectorState returns to the parent SequenceState, resuming its place within the broader sequence. StateMachine
Centralized Control: Acts as the root manager for all states, handling transitions based on validity and completeness. Loop-Driven Execution: All state transitions and updates occur within DreamBot's onLoop function, allowing individual states to run without blocking background processes.  


 
How Modular State Machine Differs from TreeScript
Both the Modular State Machine and DreamBot's TreeScript offer robust frameworks for state management but differ significantly in structure:
Execution Flow and Background Responsiveness
Modular State Machine (MSM): Utilizes DreamBot's onLoop cycle for efficient decision-making and action execution. MSM processes conditions from the root when making decisions, determining which path or state to activate. Once a state is selected, MSM executes actions directly without re-evaluating conditions from the root, allowing for efficient sequential execution. It returns control back to onLoop between each cycle, enabling the game to process updates (such as inventory changes, NPC changes, or health checks) before the next action. This approach maintains both performance and responsiveness in dynamic, sequential tasks. TreeScript: Also returns to the root after each onLoop pass, re-evaluating the tree to locate the next valid Leaf node. While this supports organized decision-making, it requires condition checks from the root each cycle, which can add overhead in complex scripts with many branches. MSM's direct, linear action execution minimizes repeated evaluations, enhancing efficiency while still supporting game updates between cycles. Modularity and State Reusability
Modular State Machine (MSM): Designed for flexible modularity, allowing states to be organized both sequentially and conditionally through SequenceState, SelectorState and DecisionState. This structure enables handling of sequential tasks without complex tracking mechanisms. Actions can be arranged in a predefined order within a SequenceState, which automatically manages progression. Each action within the sequence can independently determine completion status using markComplete() and isComplete() methods, allowing specific actions to skip or finish early based on conditions. This adaptive setup reduces the need for additional flags and makes MSM's modular sequences reusable across different workflows. TreeScript: Structured as a branching hierarchy of Branch and Leaf nodes, optimized for conditional decision-making rather than linear task sequences. Performing a series of sequential actions often requires multiple boolean flags to track progress between Leaf nodes, as the framework lacks a native way to enforce order within a single branch. While effective for certain hierarchical flows, this becomes cumbersome when handling sequential tasks, making it less suited for workflows that require ordered actions without extensive flagging. Hierarchical and Controlled Flow
Modular State Machine: Uses indexing and state tracking within each SequenceState, SelectorState and DecisionState, allowing execution of substates in sequence without deep recursive calls. It returns control to the root StateMachine between each loop and only re-evaluates conditions from the root when making new decisions. This design keeps execution layers shallow and efficient, improving performance for complex scripts. TreeScript: Maintains a structured tree hierarchy with Branch and Leaf nodes. Each Branch sequentially evaluates its children, with control returning to the root on each loop. While not recursive in execution, its structure requires repeated condition checks from the root to Leaf nodes in every cycle, which can increase CPU usage as script complexity grows. In contrast, MSM executes actions directly in sequence without re-evaluating conditions from the root each cycle, optimizing for performance in sequential tasks. Incremental Task Completion and Early Returns
Modular State Machine: Allows partial task completion within states. Each ActionState can perform a partial task and return to the main onLoop cycle, resuming exactly where it left off on the next loop. This fine control is ideal for tasks needing multiple cycles to complete. TreeScript: Executes Leaf nodes based on conditional validity but doesn't inherently support partial task completion within branches. It re-evaluates each branch each loop to locate the next valid action node.  

______________________________________________________________________________________________________________________________________________
How Modular State Machine Differs from TaskScript
1.      Execution Flow and Task Selection
MSM processes each task in sequence through onLoop, re-evaluating conditions only when switching states. Once active, tasks run to completion or skip as conditions dictate, which avoids frequent re-evaluation and focuses on sequential flow. TaskScript evaluates all added TaskNodes every loop cycle and selects the highest-priority task whose accept() condition is met. While effective for priority-based scripts, this structure requires repeated priority checks, which can add overhead as tasks increase. 2.      Modularity and Task Order
MSM organizes tasks using SequenceState and DecisionState for flexible linear and conditional flows. Actions can progress in sequence, skip steps, or be conditionally activated, allowing MSM’s modular blocks to be reused and arranged easily across scripts. TaskScript handles tasks individually through TaskNodes, each with its own priority() and accept() condition. Tasks with higher priority() values take precedence, but sequential ordering must be manually controlled through additional checks or flags, making strict task sequences more complex to manage. 3.      Control Efficiency and Layer Depth
MSM maintains shallow execution depth by only using root re-evaluation when changing states, which avoids multiple conditional checks and enhances performance in complex, multi-step scripts. TaskScript evaluates each node’s priority() and accept() condition every cycle, keeping the framework simple but potentially increasing CPU usage as complexity grows. 4.      Partial Completion and Reusability
MSM supports partial task completion within states, allowing tasks to return to onLoop mid-process and resume on the next loop. This capability is valuable for multi-step tasks needing flexibility. TaskScript executes each TaskNode to completion once selected but lacks inherent support for partial completions, meaning complex actions must be split or managed with additional tracking for incremental progression.  

Amazing script so far! I run it with items that are free to reclaim from death. (achievement armor and reminent eye gear)
I think the addition of a death measure, like reclaiming items from death and world hopping and this would be an undefeatable script!
But its not gonna stop me from using it regardless hahaha

DS Abyss Runecrafter

Overview
This script automates Abyss Runecrafting, handling everything from teleportation to banking. It supports crafting all runes through the Abyss up to Death runes,  without the need for constant monitoring.
Features
Banking Options:
The script supports banking at either Edgeville or Ferox Enclave, allowing players to choose their preferred method.
Abyss Tool Selection:
Choose which tool you'd like to use in the Abyss for accessing the inner ring, optimizing the runs based on your preferences.
Rune Crafting Choices:
Craft any runes from Air to Death runes through the Abyss. Simply select which runes you want to craft in the GUI.
Pouch Support:
Full support for Small, Medium, Large, and Giant pouches. You can choose whether or not to use pouches, and the script automatically repairs them during runs. (Note: Script supports up to Giant pouch only.)
Health Management:
Automatically eats food when your health gets below 80% the next time it uses the bank. You can select from a variety of foods, including:
Shark, Monkfish, Swordfish, Lobster, Tuna and Salmon. Run Energy Support:
The script uses Stamina potions or the Pool of Refreshment at Ferox Enclave to restore run energy.
Essence Handling:
The script only supports Pure essence. (Note: Rune essence is not supported.)
Supply Management:
If supplies run out (such as pure essence or food), the script will automatically stop.
Note: The script does not restock from the Grand Exchange.
Real-Time GUI Display:
The GUI shows statistics including:
Total gold earned Gold per hour Runes crafted Runtime Teleportation Support:
Depending on your chosen banking method, the script will use either a Glory amulet (Edgeville) or a Ring of Dueling (Ferox Enclave).
Humanizer Tab:
Efficiency Deteriorator: The bot will progressively become more and more idle(AFK) as time goes on. (Please note that this will reduce Gold per hour) Camera Adjustment: The bot will adjust the camera more frequently at the start, and slowly adjust it less and less as time goes on  

Requirements & Recommendations
Pure Essence: Make sure you have a sufficient supply as the script does not purchase more from the Grand Exchange.
Pouches: The script supports up to Giant pouch. Make sure you have the pouches and the required levels of the ones you'd like to use.
Teleportation Items:
Amulet of Glory for Edgeville banking Ring of Dueling for Ferox Enclave banking Defence Level:
It is highly recommended to have at least 65 defence before using this script, as the Abyss can be dangerous and you'll take damage when passing through.
Skill Requirements for Abyss:
While not required, it is recommended to have at least 50 in the skill used to pass your chosen obstacle in the Abyss. Lower levels can slow down your run times.
Quest requirements: Complete the mini quest, Enter the Abyss before using this script. To make Cosmic runes requires The Lost City completion To make Law runes requires Troll Stronghold completion. To make Death runes requires Mournings End II completion.  
No Armor Management:
Currently, the script does not support equipping armour automatically (This will be something to add in the future)
How to Use
Preferably Start at any bank with all required items and equipment in the bank or inventory. Choose your preferred rune to craft in the GUI. Select whether to use pouches and which food to eat. Select the tool you would like to use (You can only use the Tinderbox if making Law runes) Make sure you have your teleportation items ready (Glory or Ring of Dueling depending on the banking method). Press Start and let the script handle the rest. Suggestions & Feedback
Feel free to share any suggestions for improvements or new features you'd like to see in future versions. Post your ideas below or reach out via DM.

Aw  mate, it's fantastic.
Yes, sorry! colossal pouch would be the perfect addition. Fantastic script given it's just a hobby. Hopefully you manage to fit in the time for it, would top this off! keep up the good work.

Glad you like the script! What do you mean by that you can’t use the giant pouch? Do you mean the colossal pouch? I’d like to add support for the colossal pouch. Although time is short and I only make scripts as a hobby in my spare and it’s been super busy lately. I’m sure I will add support in the future. I wish I had more time tbh.