Hello Tribot community!
The team has been working hard at creating better value propositions for the community with the new repository on its way.
We have two questions that will help us better serve you:
1. Would you like to see scripts being bundled and sold together at a discount?
2. Which scripts do you think compliment each other best?
Need Tribot credits for scripts/VIP etc? You're at the right place!
Do you have credits you want to SELL? Message me!
I accept cash & 07 Gold/ Rs3 Gold / CS:GO Skins.
1-5 credits is 3m each, other amounts = 1.8-2.3m per credit
Skype is live:realistgold
Unique Discord ID: 194091681836957696
I've written down almost everything in half machine language and a logic syntax so it will be easier to code it for you.
It contains things like:
- Checking specific Items in Bank if available
- Withdrawing x items
- Combining x and y item
- Once done, sell item on GE for Price P (selected in GUI)
- Check if sell Order done (if not lower price P by P% (selected in GUI)
- Calculate max equal amount of item x and y you could buy (with prices set before in the GUI)
- Try to Buy each item
- Check if Order is finished
- Else increase price N by % (set in GUI)
start over again.
As i said i wrote it down even more in detail that will be handed to the person willing to script this for me
Add me on discord: deua#1132
I'm somewhat new to this and am looking for some guidance. Money is of no concern, I just need the communities best recommendations. I'm looking for scripts meeting the following criteria:
I've also been using LG with OSBuddy, however; My accounts seem to be getting hacked within 48 hours of using the OSB. Not sure what the problem is there, but I've heard of it happening with that particular client before. Let me know what clients you recommend. I don't think it has anything to do with my botting hours as I've only been experimenting with a few scripts in 1-2 hour sessions every 24 hours on innocent accounts several hours old using proxys. Look forward to your opinions.
A while back I had to create an implementation of a Server and Client communications system for a personal script of mine. My implementation was shit. Here's a much better one. It's still a bit unrefined so if you have an improvement, post it and I'll consider it for revision. The implementation for a lot of the class events is abstract, meaning the user determines what he wants to do when those events fire. Both Server and Client feature a heartbeat system, where after a certain time interval, the Client will send some info to the Server to let it know it's still alive. Likewise every time interval the Server does the same, but for each Client Connection it has saved. Servers and Clients both always have threads open which wait for Objects to be read. When an Object is read, an event will be fired as mentioned below. If the Object read is a Request (covered later on), then it will be displayed through a separate designated event. Implementations of the following events are not mandatory. If you don't want to handle certain events, simply create a constructor for the Server/Client, but leave the blocks for the unused event blank.
public abstract void onConnectionGain(Connection connection); Fired whenever a Client successfully connects to the Server, providing you the Connection that was just established. public abstract void onConnectionLoss(Connection connection, Exception e); Fired whenever a Connection is dropped, except when the Server closes a Connection manually when its shutdown() method is called. The Exception describes the circumstances that lead to the Connection being dropped. public abstract void onWrite(Serializable object); Fired whenever an Object is written to every Connection in the Server's list of current Connections. public abstract void onWrite(Serializable object, Connection connection); Same as above, but fires once for each Connection in the Server's Connection list at the time of writing the Object. public abstract void onRead(Object object, Connection connection); Fires whenever an Object is received on the Server's end from a Client Connection. Does not fire when a Request is received, the following event handles those cases. public abstract void onRequest(Request request, Connection connection); Fires whenever a Request is received on the Server's end from a Client. This class should handle implementation of how exactly you want to handle Requests. Requests will be covered in detail later on in the post. public abstract void onShutdown(); Fires at the end of Server#shutdown(). Client events
public abstract void onConnectionGain(); Fired when the Client successfully established a Connection to the Server. public abstract void onConnectionLoss(Exception e); Fired when the Client's Connection to the Server drops. The Exception describes the circumstances that lead to the Connection being dropped. public abstract void onRead(Object object); Fires when the Client receives an Object from the Server. This again does not fire when a Request is received, that is handled by the event below. public abstract void onRequest(Request request); Fires when a Request is received on the Client's end, from the Server. public abstract void onShutdown(); Fires at the end of Client#shutdown(). Functionality
The primary function of a Server/Client implementation like this is to facilitate communication between the Client and Server. Communication can happen across multiple scripts and even multiple computers. They must all be on the same network, however. Reading more than one Object at a time is unsupported (would corrupt underlying streams), and the same for writing. You can, however, read and write at the same time. To set this up, the user must specify which port the Server will be set up on, and then create Clients that attempt to connect to that port. You can do this through the constructors like so:
Note the implementations of each event in the example above do not need to contain any actual code, they just need to have their headers. Clients will automatically attempt to re-connect to the Server with their designated port number. If the Server connection is lost while a Client is still online, it will fire a onConnectionLoss(...) event and wait 1 second before reconnecting. If a Client connection drops while the Server is still online, the Server will simply fire onConnectionLoss(...) and do nothing special.
When a Connection is dropped, either Server or Client, you won't know about it until you try to read/write to it. This is why both Server and Client implement a "heartbeat" system. Every time interval (0.5 seconds) the Server sends a null Object to each Client, and each Client does the same for its Server. This simply ensures a minimum read/write frequency between the Server and Client so that dropped connections can be handled properly. On read/write from a disconnected Connection, an error will be thrown, which will properly remove the Connection from the Server's list and fire onConnectionLoss(...).
Communication between Server and Client is two-way, meaning the Server can send Objects and Requests to any of its Connections and the Client can do the same to its designated Server. A Server can have as many Connections as your heap space allows, however a Client can only have 1 Server Connection. Reads happen automatically via their own threads, however writes must be handled directly by the user. Anything you want to write must be Serializable, otherwise you'll get an Exception. Here's how the write methods work:
public void write(Serializable object) Simply writes the given Serializable to every Connection in the Server's current Connection list. Fires onWrite(Serializable object); public void write(Serializable object, Connection connection) Writes the Serializable to only the specified Connection. Fires onWrite(Serializable object, Connection connection); Client
public void write(Serializable object) Writes the given object Fires onWrite(Serializable object); When writing Requests, if the Request is unfulfilled (see section below), it will appear in the recipient's onRequest(...) event.
Finally I'll get to Requests, which is one of the main things I built this system to handle. A Request is a specialized Object, sent to a recipient, with the expectation for it to be returned, but with some modification. A Client may want to send a Request containing a Point with coordinates (-1, -1), expecting it to be returned with different coordinates. Here's an example of what that might look like:
Simply extend Request<T> where T is the type of Object you want to be able to modify and implement Serializable so that the Request can actually be sent. When you initialize the Request<Point>, it will contain a Point (or otherwise specified type) variable called "target" which will be null until the Request is fulfilled. To fulfill the Request, simply call Request#fulfill(Object ... args) with the proper argument parameters (in this case 2 ints). The Request will automatically process the parameters in the way specified by your abstract implementation of Request#execute(Object ... args), and update the "target" from null to whatever the result actually is. If Request#execute(...) throws an Exception at any point, the Request will simply be processed as unfulfilled and ignored, even if it is written back to the sender. Here's what Request fulfillment looks like:
To send Requests, simply call the Client or Server's fulfill(...) method. It will write the specified Request to the target(s), wait for it to be returned as fulfilled, and then return it. If it doesn't receive the Request within a designated time frame, it'll throw a RequestTimeoutException. Requests use System.nanoTime() as an identifier to ensure the originally sent Request is returned at the end of the method call. This is a failsafe to ensure you don't accidentally return a different Request to the one that was originally sent out.
That's it. Here are the classes:
TRiBot 12 Release Candidate
The TRiBot team has been hard at work creating the last major version of TRiBot before the TRiBot X release. We've noticed many problems with TRiBot 11 with a lot of users preferring TRiBot 10 over 11. We've heard you, so we took TRiBot 10, added the new features introduced with 11, introduced some other new things, and created TRiBot 12. So without further adieu, here's TRiBot 12.
Gradle is a build tool used to accelerate developer productivity.
We recently setup a Maven repository (TRiBot Central) to make it easier for scripters to create scripts. Check it out here: https://gitlab.com/trilez-software/tribot/tribot-central/-/packages
Furthermore, we've released a simple Gradle project to make it easy to run TRiBot and develop scripts for it. Check it out here: https://gitlab.com/trilez-software/tribot/tribot-gradle-launcher
The goals of TRiBot Central are to:
Deliver updates to TRiBot faster
Better organize TRiBot's dependencies (AKA dependancies)
Make it easier to develop scripts for TRiBot
Make it easier to use and run TRiBot
Note: TRiBot won't be able to run scripts from within this project until TRiBot's next release.
I'd like to thank everyone for their patience in this transition period. Since last week, we've worked out the remaining bugs with this integration.
Some users have still been having issues with connecting their forums account to their Auth0 account. To resolve this, we've imported all forums accounts into Auth0.
Unfortunately, the accounts which were imported today were using an unsupported password hashing algorithm. Hence, random passwords were set during the import.
What does this mean for me?
If you've previously linked your forums account to your Auth0 account, you don't have to do anything. Nothing changes for you.
If you haven't logged in via our new login yet,
Try logging in with your forums email address and the last password you used
If you are unable to login, please use the "Forgot password" tool on the login page:
Follow the instructions to reset your password
Last week we tried to roll out Auth0 Login, but we lost that battle. Now it's time to win the war!
When logging into the client, you'll now have to enter your Auth0 account credentials instead of your forums credentials
Note: 2FA is still handled through your forums account (for the time being)
Changes for existing users
You'll have to link your Auth0 account to your forums account here: https://tribot.org/forums/settings/login/?service=11
Auth0 accounts have been created for most existing users. Please use your forums email address and password to login.
Make sure to verify your email address upon creating a new Auth0 account
When we mention your Auth0 account, we mean your account used for auth.tribot.org as displayed below
To better support the upcoming changes (TRiBot X, new repository), we're switching our login handler to Auth0. Instead of logging in with the standard form, you'll now be required to login through our Auth0 application.
All existing accounts which have been used within approximately the past year have been imported into Auth0 using the same email and password combination which has been stored on the forums.
What does this mean for users?
Your account credentials are now even more securely stored
You'll be able to login via Facebook, Google, and others in the future
Is there anything users have to do differently now?
Existing users: You'll have to login with the standard login, open your Account Settings, then link your Auth0 account
New users: You'll be redirected to our Auth0 app (auth.tribot.org) where you'll be able to create an account
Why was this change made?
The new apps we are creating (such as the new repository) aren't able to use the forums to handle user logins
To centralize all user accounts in one area
To ensure that the client login doesn't go down when the forums are having problems
To speed up our development
There's no documentation or official support for using Invision Community combined with Auth0, so there are still a few kinks we're working out
We're in the works of creating an account management panel specifically for Auth0 accounts (ETA August)
It's not possible to change email addresses for the time being (this will be resolved this August)
Changing passwords is a weird process for the time being. To change your password, you'll have to use the "Don't remember your password" tool on the Auth0 login page
Recently Browsing 0 members
No registered users viewing this page.