Jump to content

Welcome to DreamBot

VIP Enhancement

Want to upgrade your DreamBot experience? Consider signing up for VIP!
VIP allows you to run as many accounts as you want, view the forums ad-free, receive 10% off all script purchases, and so much more!
Visit the store to learn about all of these great features!

Upgrade to VIP Now
News Ticker
  • New Forum Theme!
  • New Forum Chatbox (on the way)
  • Chatbox Mods Soon Needed
  • Suggest Forum Rank Colors
  • Forum Updates

DreamBot is the only Deadman Mode supported bot on the market!

Download the DreamBot client today!


Crondroid | Bot control software | #Cronscript

Recommended Posts




Table of content


1. Introduction

2. Features

3. Media

4. Current to-do list

5. Tech list

6. Credits


1. Introduction

Crondroid is web-software which is written to both remotely monitor and command your bots. We've never seen a botpanel publicly used on Dreambot before and I think it's a step towards making botting less of a hassle in terms of maintaining your bots. 

I've had several projects before (Remember Volucron? Yeah that's a dead fucking meme), but never really went through with the idea of public use. Turns out writing a scalable application is a bigger job than I initially expected.


The reason I started from scratch is because I want to grow in writing web services in Python, as well as server-sided javascript libraries. I hope to be able to push through with Crondroid (and CronApp too  :ph34r: ) . One of the main problems I'm faced with is having to pay for my servers' hosting, but money are worries for later when it's actually finished  :P


The question that everyone asks: "Will you be able to use this with scripts in the store?" has a simple answer:
Yes, but only if the script is written by a Cronscript squad member. The protocols Crondroid runs on are approved by @@Pandemic as store material  B)


2. Features

  • Dashboard layout (With announcements, so you're up to date with changes to Crondroid)
  • A web-token "room" based system
    • This essentially means that users don't have to register on the crondroid application. It's the same principle as an IRC-room: A user can register a "web-token" and a password tied to that token through the GUI of a Crondroid script. Those credentials can be used to add bots to that web-token (or room). This way, you can even categorise your bots inside different web-tokens.
    • A practical example: You're using an AIO Fighter script that has Crondroid implemented. You're killing chaos druids on 10 bots, and killing seagulls (to prep for chaos druids) on 50 other bots. The user can create a web-token for both categories "dreambot-chaos" and "dreambot-prep", in which they can drop the bots seperately.
  • Bot alias system
    • I can imagine that you're skeptical about linking your bots to software which is external to Dreambot. This is why you're given the option to give your bot an alias. This is the credential that will be saved on our servers. If you apply this to the example I gave before: you can essentially call all your chaos druid killers 'chaoskiller1', 'chaoskiller2', 'chaoskiller3' ,... 
      This way, even if information gets leaked one way or another, it's essentially useless to the intruder.
  • (Semi) realtime tracking of your bots
    • The stuff that is being tracked will differ depending on the script you're running. A fighter might track the loot profits and experience gained in the combat skills, whilst a fletching script would perhaps track bows strung, money made,... Crondroid is written in such a way that it is able to track anything the scripter decides to track.
    • The reason it's semi-realtime is because it will depend on the type of script you're running. if you're running a free script & you are
      non-VIP, the update rate will be once / 30 seconds. If you're a VIP, this decreases to once / 20 seconds. Premium scripts get the highest priority, ranging between actual realtime and 10 seconds.
    • The only things that are tracked by default are your current inventory and script runtime. Runtime especially is important for graphing data (more on this later on).
  • Remote commands (Premium scripts only)
    • The commands available to you will depend on the script you're running. The scripter decides beforehand which commands he wants to make available to the public. For example: A fighter might not have a muling command, but a fletcher/blast furnace script might, if the scripter decides to support it.
    • Due to the restrictions given to me by Pandemic, a remote command might have a max latency of 5 seconds before being picked up by the client. 
    • The interface itself gives you the option to easily group commands to the bots you like: You can send a command to 1 singular bot, a group of bots, or all of your bots. 
    • The processing of the command is shown in realtime. An example: A mule command on a BF script: you will get processing reports on the command (For example -> withdraw bars, finding mule, currently trading mule, trade complete). After the remote command has finished, the command is archived.
  •  Botting history (Premium scripts only, WIP)
    • Each botting session will be archived (categorised per date). You will see the progress report last recorded by the tracker, alongside a list of any remote commands which have been dispatched to the bots (and time stamps).
    • Filter logs on several criteria like "bots who had the remote command...", "bots with runtime > ....", bots on certain days,...
    • The max log range is still up in the air, but I think it will range somewhere between 1 month - 3 months.
  • Data graphing (Experimental)
    • Dynamic signatures / room
    • Graphs which can be generated with data from 1 singular bot, multiple bots, or all bots (based on botting history logs).
      Again, the graph-able data is determined by the scripter.
  • Suggestions? Give it to me baby

3. Media

Probably the section most people are interested in. 

  • Login page


  • Dashboard home: 


  • Bot list: 


  • Bot details (WIP, will include a history list of remote commands issued in that session): 


  • Remote commands: 



4. Current to-do list

  • Remote commands
    • Write script-sided listeners
    • Write script-sided emitter bridges for realtime information
    • API backend handling of commands (queueing of commands)
  • Bot history
    • Design of the webpage
    • Backend structuring for saving sessions
    • Linking commands with botting logs (OTM relationships)
  • Data graphing
    • ​...

5. Tech list


List of important principles/libraries/frameworks used:



6. Credits


Edited by Articron

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now