Jump to content
TRiLeZ

TRiBot Beta 7.40_0

Recommended Posts

I am very grateful for the hard work Trilez does and I agree with 99% of his decisions. He is smarter than me and I respect him greatly. However I just can't understand why he is forcing this Positionable change, surely we should still have the option to use RSTile if we wish? (it is only deprecated at the moment, but soon it will be removed fully)

 

 

Old code was like:

RSTile.distanceTo(tile) // <- this will break your script, and give an error since it has been/will be removed soon
New code is like:

RSTile.distanceTo(positionable) // <- now forced to use this
Why did Trilez make this change? I actually have no idea, I personally thought it was more logical to make .distanceTo use "tiles", I felt the new Positionable position interface object is kind of pointless tinkering - like "if it aint broke dont fix it". I think it was a bad move to remove the (tile) option, to force people to use the new Positionable position, they should have left the (tile) option in so that people can choose and so that existing scripts do not break.

 

Also why did he call it (Positionable position)? It would have been more logical to call it "Position". Either "(Position position)", or "(Positionable positionable)". But what he did was a mix and match of both of them (Positionable position). I think this was a bad choice of names. And blocking the option for people to use (RSTile) that don't want to use Positionable was also a bad choice (in my opinion)

 

(This is all just my opinion and most people think that the new Positionable change is good. I am just wondering why it was done? And why was the option for us to use RSTile forcefully removed)

RSTile implements Positionable

RSCharacter/RSNPC/RSPlayer implements Positionable

RSObject implements Positionable

So,

RSTile tile = ...;RSTile tile2 = ...;RSObject object = ...;tile.distanceTo(tile2);//<- Workstile.distanceTo(object);//<- Also workstile.distanceTo(object.getPosition());//<- Works the same as above.
All you have to do is make sure the TRiBot jar is up to date, refresh the java project, then re-compile your scripts.
  • Like 1

Share this post


Link to post
Share on other sites

RSTile implements Positionable

RSCharacter/RSNPC/RSPlayer implements Positionable

RSObject implements Positionable

So,

RSTile tile = ...;RSTile tile2 = ...;RSObject object = ...;tile.distanceTo(tile2);//<- Workstile.distanceTo(object);//<- Also workstile.distanceTo(object.getPosition());//<- Works the same as above.
All you have to do is make sure the TRiBot jar is up to date, refresh the java project, then re-compile your scripts.

 

 

Ah I see, thanks for answering.

 

It seems like a very good change and my initial post was wrong.

 

Thanks Trilez :)

Share this post


Link to post
Share on other sites

4aVM1.png

 

 

Tribot is 100% safe and secure. AVG is not very good, it sometimes says things are a virus when they are not. Why does it do that? It's called a "false positive".

 

What tribot does is some sort of exploit to monitor the OpenGL data of the runescape applet in order to allow you to script. This behaviour in Tribot is normal and 100% safe and what we want.

 

AVG is flagging it because some viruses will change/spy on data without you knowing, which is why Tribot (the safe and good software) is getting flagged for a "false positive" for acting in a way that some viruses might act. Rest assured that Tribot is 100% safe.

 

You can add "Tribot.jar" to your AVG exceptions list, so that AVG is still active it will just ignore Tribot.jar (since it's safe).

 

If you can't do that, it won't work, or you can't figure it out, then just disable/close AVG while you use Tribot.

 

I use BitDefender, it is arguably one of the best antiviruses+antispyware+firewall all in one. (I would say its the best, other people might disagree but they would definitely agree it's in the top 3). You might want to consider uninstalling AVG, and getting BitDefender 30 day trial, just to see if you like it.

 

BitDefender reports no problem with Tribot.jar.

Share this post


Link to post
Share on other sites

this update sucks, nearly double the Pc usage is used now, i can only run 3 bots instead of 5 now.
it seems the login screen holds all the cpu usage and ingame it holds barely anything. could there possibly be an update to fix this soon?
its really letting me down, thanks

Share this post


Link to post
Share on other sites

^ I am still getting my scripts to work, can't even run one.

 

this update sucks, nearly double the Pc usage is used now, i can only run 3 bots instead of 5 now.
it seems the login screen holds all the cpu usage and ingame it holds barely anything. could there possibly be an update to fix this soon?
its really letting me down, thanks

Share this post


Link to post
Share on other sites

13:29:43] Starting TRiBot Loader.
[13:29:44] TRiBot Loader Release 1.66 is up-to-date.
[13:29:45] Attempting to launch TRiBot.
[13:32:16] Java JRE Home: C:\Program Files (x86)\Java\jre7.
[13:32:16] Using "C:\Program Files (x86)\Java\jre7\bin\java.exe" to boot TRiBot.
[13:36:14] TRiBot Loader has finished it's process, but some errors have occurred.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Our picks

    • This update will:

      Fix GE inventory item positioning bug


      Fix broken object hooks
        • Like
      • 24 replies
    • This release will:

      Fix some ClosedChannelException bug


      Fix bug in RSObject#getAllTiles


      Add game tab support for "Kourend Favour"
        • Like
      • 15 replies
    • This release will:

      Fix Settings UI placement bug


      Fix game object location bug


      Fix small layout bug making the client shift up and down


      Fix client crashing bug where loading the client with a small display area will cause the client to crash


      Fix annoying Linux bug relating to painting events and peers


      Fix settings saving bug where settings are saved to disk more often than they should


      Fix RSInterface#isBeingDrawn bug affecting a limited amount of people


      Drop Java 1.7 bytecode version for 1.8


      Important: Since the downloadable RS client uses Java 7, it will no longer be compatible with Looking Glass. To make up for this, we will add support for using other clients such as RuneLite (at a later date).


      This change was necessary to allow us to use Java 8 syntax. It also paves the way for Java 9/10/11 support.
        • Like
      • 40 replies
    • This update will:

      Fix the RSMenuNode bug which also fixes the bug with bank opening


      Fix the incorrect object positions bug


      Fix and re-enable the LG Objects API Accelerator


      Fix the RSObject#getAllTiles bug
        • Like
      • 22 replies
    • Try our development release by checking "Development Release" on the TRiBot Loader. Note that these new features are currently in beta.

      This release features:

      Re-sizable mode support for both LG and the regular client


      Slightly improved login bot


      Removed final access modifiers from API classes


      Added RSServer hook wrapper to get the client's cached list of server/world info


      [NEW] Bug fix for intelligent banking


      [NEW] Improvement to the stability of LG over time


      [NEW] Vastly improved the reliability and speed of Screen#getColorAt on both LG and the regular client


      [NEW] Fix LG login problems


      [NEW] Fixed re-sizable mode container bug


      [NEW] Fixed re-sizable mode mouse bug


      [NEW] Use of public constants in the Banking API


      [NEW] Use of other various constants such as Projection#NULL_PT and Screen#EMPTY_COLOR



      More features to come very soon!

      Please test it and let us know here if there are any new bugs introduced in this release.
        • Thanks
        • Like
      • 12 replies
  • Recently Browsing   0 members

    No registered users viewing this page.

×