Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
PickleRick

Automation of Tribot login/running a script at startup

Recommended Posts

Is there a way to run a tribot instance and have it set various things? All I need is:

1) Start an new tribot process with a proxy
2) Have a pre-set script start executing with a specific account when everything is loaded

Are the above two possible? I was hoping I could grab some flags with

jps

but looks like I'd need to go deeper than this. Those values for the loader have to be communicated in some way...

Something like in this thread

 would be nice, however I really don't want to have to go digging around obfuscated code just to fire off a few mouse clicks. It might even be less work for me to just create mouse clicks to press the button with something like Simba/java.awt.Robot/whatever. Plus if I started messing around with the jar, it'd just break in updates... brittleness of this method isn't acceptable for me.

 

Do I have any options? It's been almost 3/4ths of a year since that was posted and adding automation support should not be that hard.

 

Am I missing something or is there some API I can call to do this?

Edited by PickleRick

Share this post


Link to post
Share on other sites
22 minutes ago, theholyone said:

uhh..this is exactly what client starter does?

unless you mean start everything with a single click on windows startup..

i mean you'd probably save 50 seconds doing it that way..but yeah.

I wasn't clear in my post so to clear up the confusion: zero clicking is a necessary condition, the only acceptable one would be starting an external program that manages everything.

The .dat file for the client starter would need to be dynamically generated and loaded as needed, so unless Tribot supports the data changing on the fly and it's just not "loaded into memory and that's it" then the client starter is not sufficient.

Does it support the dynamic nature mentioned above? I can't see it

 

Share this post


Link to post
Share on other sites
3 minutes ago, PickleRick said:

I wasn't clear in my post so to clear up the confusion: zero clicking is a necessary condition, the only acceptable one would be starting an external program that manages everything.

The .dat file for the client starter would need to be dynamically generated and loaded as needed, so unless Tribot supports the data changing on the fly and it's just not "loaded into memory and that's it" then the client starter is not sufficient.

Does it support the dynamic nature mentioned above? I can't see it

 

Yes. But you'll have to  deconstruct it yourself or pay $$$ for someone's private version. Either way, yes to your questions.

Share this post


Link to post
Share on other sites
1 minute ago, atrain0009 said:

Yes. But you'll have to  deconstruct it yourself or pay $$$ for someone's private version. Either way, yes to your questions.

Can you clarify the 'deconstruct it yourself' part? Do you mean that the .dat file format needs to be deconstructed? Or that I have to deob the client to get what I want?

Also I assume once I press "Run" on the client starter, that is it... as in I can't edit the .dat file after it without stopping everything and running it again? My guess is Tribot doesn't keep polling the .dat file and updating as needed, which means this method would still unfortunately not work for me, though if it did do this I would be pleasantly surprised. 

Share this post


Link to post
Share on other sites
Just now, PickleRick said:

Can you clarify the 'deconstruct it yourself' part? Do you mean that the .dat file format needs to be deconstructed? Or that I have to deob the client to get what I want?

Also I assume once I press "Run" on the client starter, that is it... as in I can't edit the .dat file after it without stopping everything and running it again? My guess is Tribot doesn't keep polling the .dat file and updating as needed, which means this method would still unfortunately not work for me, though if it did do this I would be pleasantly surprised. 

Of course it doesn't poll the dat file. It generally deletes it after use. Even then I really can't see a reason you would want that. Unless you are just trying to use a bunch of other peoples scripts to run a farm on and want to chain them together. If you were thinking about using that dat file to switch between accounts I don't understand why you wouldn't just have a web server to feed the account data to your script instead.

You'll have to deob the client to get the methods to generate the dat file among other things to get it working.

Share this post


Link to post
Share on other sites
5 hours ago, PickleRick said:

2) Have a pre-set script start executing with a specific account when everything is loaded

Definitely possible. Some users even implemented a system where the script picks one account from a list and changes it if it gets banned.

Share this post


Link to post
Share on other sites
3 hours ago, Einstein said:

Definitely possible. Some users even implemented a system where the script picks one account from a list and changes it if it gets banned.

I would recommend this to start. This doesn't even require you to deob the client, just set up your own web server like Ludify said.

Share this post


Link to post
Share on other sites
1 hour ago, ludify said:

Probably beyond you then.

Hi, thanks for taking time out of your day to write that - very helpful. 

I doubt it though. Perhaps I should have been more specific for you with what I quoted. 

12 hours ago, ludify said:

have a web server to feed the account data to your script

So maybe we are talking about different things here but let's say I have 5 servers, each running multiple tribot instances. Logging into each VPS individually to manage my magnificent bot army takes time and is tedious. It seems like there must be a more efficient way to manage each VPS, each Tribot instance, and each bot's actions. Let's say I am going to scale my hypothetically already profitable bot farm 10x because of reasons. In theory, I would now need to manage 50 web servers individually. That would suck. Is there a way to use a separate (Windows OS) web server to control my now huge VPS network remotely?

Share this post


Link to post
Share on other sites
7 hours ago, josh_w said:

So maybe we are talking about different things here but let's say I have 5 servers, each running multiple tribot instances. Logging into each VPS individually to manage my magnificent bot army takes time and is tedious. It seems like there must be a more efficient way to manage each VPS, each Tribot instance, and each bot's actions. Let's say I am going to scale my hypothetically already profitable bot farm 10x because of reasons. In theory, I would now need to manage 50 web servers individually. That would suck. Is there a way to use a separate (Windows OS) web server to control my now huge VPS network remotely?

You would have one master web server that all your bot servers connect to through some application. This application controls all the tribot instances as well as sends and receives messages or commands from the master web server. Then from the master web server you could setup a web page to control all clients on each server. This is what I do.

Share this post


Link to post
Share on other sites
On 8/17/2018 at 1:06 AM, Letsmakemoneybitch said:

still not possible... 

I know this is a less stable and probably more problematic approach, but you could make some sort of external higher level script that runs in a sandbox, vim, whatever some way to organize the tribot instances and interacts with each one individually. This would also take a lot of resources though and be prone to break on updates. It could be done though and could work with just a little thinking.

 

Sorry to post on an old thread but figured I'd mention it.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Our picks

    • This update features:

      Fixed broken hooks from today's update


      Fix wilderness level with RuneLite (Thanks @Todd)


      Add support for Kotlin .class files in scripts (Thanks @wastedbro)


      Overhaul Inventory API (Thanks @wastedbro)


      Add List support for common methods


      Change method grouping to make more sense (by functionality)


      Refactor methods to utilize Java 8 streams instead of cumbersome loops




      Recognize chatbox minimization (Thanks @JoeDezzy1)


      Fix Screen#isInViewport when NPC chat is open (Thanks @JoeDezzy1)


      Fix login bot bugs (Thanks @erickho123)


      Fix hint arrow return values (Thanks @Encoded)


      Fix depositAllExcept functionality (Thanks @wastedbro)


      Change containing box interface bound and adjust for Y values (Thanks @erickho123)
      • 148 replies
    • This release will:

      Fix prayers and world hopper API (Thanks @JoeDezzy1 and @erickho123)


      Improve banking API (Thanks @Encoded)


      Adds methods for returning and using Java Lists, rather than arrays


      Slightly randomizes some hardcoded behaviour


      Removes sleeps from waitConditions; the efficiency saving potential is negligible in these use-cases, therefore cleaner code is preferable


      Other back-end improvements





      Note: If you are using LG, please restart both the RS client and TRiBot.
      • 90 replies
    • This release will:

      Add new internal framework for capturing exceptions


      Fix issue with not selecting the last column in world hopper (Thanks @Todd)


      Add a message about pin usage in Banking#openBank (Thanks @Todd)


      Disable the firewall by default (Thanks @Todd)


      Fix handling of the welcome screen after login (Thanks @Encoded)


      Fix wrong amount bank withdrawal (Thanks @Encoded)


      Fix Screen#isInViewport


      Fix Game#isInViewport (Thanks @Encoded)


      Call onBreakEnd for ListenerManager Breaking Listeners (Thanks @Encoded)


      Fix Prayer#getPrayerPoints NumberFormatException (Thanks @JoeDezzy1)



      Note: If you are using LG, please restart both the RS client and TRiBot.
      • 28 replies
    • This release will:

      Fix LG for both OSBuddy and RuneLite


      Fix issue where the resizable client isn't able to be made smaller (Thanks @JoeDezzy1)


      Fix detection of the logout game tab when resizable mode and side panels are enabled (Thanks @JoeDezzy1)


      Add initial support for Sentry to allow us to identify and easily debug exceptions happening with all TRiBot users


      Add methods to determine if the bank is actually loaded, and not just the overarching interface (Thanks @wastedbro)



      Upcoming updates:

      Improved CLI support


      Full Sentry support


      Much more
      • 64 replies
    • This release will:

      Fix NPE in Camera API (Thanks @wastedbro)


      Update deposit box interface ids (Thanks @Encoded)


      Add various bank methods (Thanks @wastedbro)


      Banking#getWithdrawXQuantity


      Banking#getDefaultWithdrawQuantity


      Banking#arePlaceholdersOn




      Fix resizeable minimap bug (Thanks @wastedbro)


      Remove Java 8 requirement


      Please note: TRiBot is not yet fully compatible with Java 10+




      Fix the break handler issues by ensuring the break handler thread never gets paused


      Fix broken settings hooks



      Upcoming updates:

      Improved CLI support


      Much more



      Note: If you are using LG, please restart both the RS client and TRiBot
      • 68 replies
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...