Jump to content
Frequently Asked Questions
  • Are you not able to open the client? Try following our getting started guide
  • Still not working? Try downloading and running JarFix
  • Help! My bot doesn't do anything! Enable fresh start in client settings and restart the client
  • How to purchase with PayPal/OSRS/Crypto gold? You can purchase vouchers from other users
  • Client Release 2.9.8.9.8


    Nuclear Nezz

    Recommended Posts

    Hello Everyone!

    I've got a few bug fixes and a few minor additions for the release this time around.

    • Added the isNormal method to the World class itself.
    • Added more null checks into both the bank pin solver and our widgets methods, this should solve that error on quickstart.
    • Added checks for 0 and less than 0 to the sleep methods.
    • Added more checks to keyboard for the WPM errors, now it should 100% not throw errors if you set it high.
    • Map canReach and isTileOnMap now check against your player's Z, if they're different then it will return false. I believe this may also fix the bug with walking out of Lumbridge Bank.
    • Added some more synchronization locks to the random manager methods to catch any edge case concurrency issues.
    • Added a getSolver method to the random manager.
    • Added more logs to the solver handlers to reflect when solvers are disabled due to not working correctly.
    • Custom web nodes that are added in scripts should now be removed on script stop.

    Now here's a little bit of a larger one for you guys.

    • Added use of library jars in a separate folder, DreamBot\Libs\yourLib.jar [1]
    • Fixed some local loaders issues [2]

     

    [1]

     

    So now if you use JSON library in your script, you no longer need to build it into the script itself. You can throw your json library jar into the Libs folder (which should be created next time you run the client) and it *should* be good to go. I tested this, but obviously with libraries I can't test everything.
     

    Be careful with libs, they will all be loaded into the loader on start, if you get too large with them it may slow down the script loading process.

    I'm pretty excited about this one, and I'd like to start looking into using this for SDN scripts as well, I just have to dive a little more into some other areas of the loaders. This may not happen anyway, because security.

     

    I'm working on the following (as of this time, not in the current release but may be added as another quick release):

    You will be required to have a file named "libs" that is built into the root of your jar, you will put the name of the library (case sensitive, until someone says they'd like it otherwise) on each line of the file. This way we aren't loading every single lib into every single script jar, and you don't have to worry about complications with other libraries a user may have.

     

    [2]

     

    I was previously closing the class loaders after the initial load, which then popped up issues with classes not being found. This was my fault. I have reverted that change, so the loaders will now be open until you stop your script, the loaders will be closed and refreshed when you refresh your local scripts as well.

    You can still make changes to your jars while these loaders are open, we make a temp copy of the jars to load from, and that's what the loader will use until it is refreshed. Every time the loader is closed it should close out the temp files it was using as well. Previously I believe this was leaving behind some temp files, which we weren't even using.

    We make temp copies of the script jars as well as the library jars, so again, if you get too large with your files it may slow down the script loading process.

    I double checked that this didn't mess with anything using multiple tabs in the client, but again obviously I'm unable to test every edge case that is possible. If these changes cause you issues please let me know.

     

    Thanks as always!

    The Dream Team

     

    Link to comment
    Share on other sites

    2 minutes ago, Nuclear Nezz said:

    Hello Everyone!

    I've got a few bug fixes and a few minor additions for the release this time around.

    • Added the isNormal method to the World class itself.
    • Added more null checks into both the bank pin solver and our widgets methods, this should solve that error on quickstart.
    • Added checks for 0 and less than 0 to the sleep methods.
    • Added more checks to keyboard for the WPM errors, now it should 100% not throw errors if you set it high.
    • Map canReach and isTileOnMap now check against your player's Z, if they're different then it will return false.
    • Added some more synchronization locks to the random manager methods to catch any edge case concurrency issues.
    • Added a getSolver method to the random manager.
    • Added more logs to the solver handlers to reflect when solvers are disabled due to not working correctly.
    • Custom web nodes that are added in scripts should now be removed on script stop.

    Now here's a little bit of a larger one for you guys.

    • Added use of library jars in a separate folder, DreamBot\Libs\yourLib.jar [1]
    • Fixed some local loaders issues [2]

     

    [1]

     

      Hide contents

     

    So now if you use JSON library in your script, you no longer need to build it into the script itself. You can throw your json library jar into the Libs folder (which should be created next time you run the client) and it *should* be good to go. I tested this, but obviously with libraries I can't test everything.

    Be careful with libs, they will all be loaded into the loader on start, if you get too large with them it may slow down the script loading process.

    I'm pretty excited about this one, and I'd like to start looking into using this for SDN scripts as well, I just have to dive a little more into some other areas of the loaders. This may not happen anyway, because security.

     

     

    [2]

     

      Reveal hidden contents

     

    I was previously closing the class loaders after the initial load, which then popped up issues with classes not being found. This was my fault. I have reverted that change, so the loaders will now be open until you stop your script, the loaders will be closed and refreshed when you refresh your local scripts as well.

    You can still make changes to your jars while these loaders are open, we make a temp copy of the jars to load from, and that's what the loader will use until it is refreshed. Every time the loader is closed it should close out the temp files it was using as well. Previously I believe this was leaving behind some temp files, which we weren't even using.

    We make temp copies of the script jars as well as the library jars, so again, if you get too large with your files it may slow down the script loading process.

    I double checked that this didn't mess with anything using multiple tabs in the client, but again obviously I'm unable to test every edge case that is possible. If these changes cause you issues please let me know.

     

     

    Thanks as always!

    The Dream Team

     

     

     

     thank you! Thank you especially for the local libs! compiling libs with my scripts made my life a living hell

    Link to comment
    Share on other sites

    1 hour ago, Neffarion said:

    I assume the lib jars part is not for SDN use? How will it be done?

    It is not, if you read the thread again you'll see that it is meant for local scripts, not SDN scripts.

    Link to comment
    Share on other sites

    Perfect! Thank you!

     

    Edit - There's a bug with the local script manager. It won't display all of the scripts in the folder and will duplicate one of the scripts. To get the desired script to show up I had to move the scripts out of the folder and leave the one I wanted to run in the folder.

    ZcIegX9.png

    Link to comment
    Share on other sites

    34 minutes ago, RetroBot said:

    Perfect! Thank you!

     

    Edit - There's a bug with the local script manager. It won't display all of the scripts in the folder and will duplicate one of the scripts. To get the desired script to show up I had to move the scripts out of the folder and leave the one I wanted to run in the folder.

     

    It may be an issue with having multiple versions of the same script in different jars. I'll have to take a look at that.
    If your scripts are not appearing, it's because there's an error in one of your jars. If you look at cmd when you launch you may get the error messages as to which jars are causing issues.

    Otherwise, as you said, keep removing jars until the scripts show up again, that's your jar with the error.

    Link to comment
    Share on other sites

    I have found an issue with the removal of custom nodes though, erroring out when the script stops.

    I'm releasing a quick fix for that right now (same version number)

    If you haven't ran your launcher since this message was posted, run your launcher.

    Link to comment
    Share on other sites

    Golly this is embarrassing guys.

    I just released *another* quickfix for having multiple jars with the same class names in them.

    I'm going to work on adding in something for people to specify libraries that they're using so that we don't have to load all of the libs into all of the class loaders for every script jar.

    Link to comment
    Share on other sites

    Archived

    This topic is now archived and is closed to further replies.

    ×
    ×
    • Create New...

    Important Information

    We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.