Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal
LordJashin

Broken/Working/Suggestion List for OSI (Constantly Updated)

Recommended Posts

Here we can update, and put together a list for OSI. For what needs work, what is broken, and what is working!

 

 

Last Updated: October 2nd, 2012

 

1_line_misc_8.gif

 

----------------------------------------------------------

Confirmed Not Working:

----------------------------------------------------------

Randoms - Most are broken

 

 

----------------------------------------------------------

Working:

----------------------------------------------------------

Deposit Box functionsInventory Functions

Majority of OSI

GameTabs

Map

Amount

SMART

 

----------------------------------------------------------

Suggestions:

----------------------------------------------------------

Updated Wiki

Hide command prompt for SMART

Antiban!

Minimap Symbols!

SetFightMode

GetCombatLevel

SetRetaliate

GetCurrentWorld

RestUntil

AdjustSettings

FixAllSettings

DoEmotion

- From Wanted, in

GameTabs.scar

InAbstractBox

GroupDigits (123456778 -> 123,456,778

Numbers to words 1000000 -> one million

- From Wanted, in

OSI\Math.scar

 

 

 

Post a reply or private message me if you wish to add to the list!

Edited by LordJashin

Share this post


Link to post
Share on other sites
Will do!

 

 

I hope we can get SPS really organized, and working too in the future. Then we can move that into OSI as well. The images can be compressed, and etc. It wouldn't change the size of the include too much.

 

Pre-congratz on your 600th post lols.

Share this post


Link to post
Share on other sites

Lol never noticed until you pointed it out. I do have a suggestion but want to take some time to sort out my reasons for it cuz I think it will be a hard sell, simply because of the work involved initially.

Share this post


Link to post
Share on other sites
Lol never noticed until you pointed it out. I do have a suggestion but want to take some time to sort out my reasons for it cuz I think it will be a hard sell, simply because of the work involved initially.

 

Idc about work involved. If its possible with SCAR. Then suggest away lols...If you suggested that we make a new SPS, It could be the same way. LOTS of work initially xD.

Share this post


Link to post
Share on other sites

I was thinking of the +50 pixel offset to accommodate the toolbar specifically. Adjusting the entire client area down 50 pixels got us up and running quickly, but it is not IMHO a proper solution. And it makes it truly a pain in the ass to figure out coords on the screen when writing scripts now. On top of that I have encountered situations where I want to read a color that lies inside that first 50 pixels, which is now outside the client area and thus always returns 0 as the color.

 

The toolbar while annoying and of little use to us (at the moment) is a area of the client window, just as we have a main screen area, an inventory area, etc. A better solution would have been to define a new set of constants defining the boundaries of the new area. (MTX1,MTY1,MTX2,MTY2 perhaps?) And then adjust the other area constants to their proper location (ie. MSY1 would be changed from 0 to 50). Scripts can continue to reference the area constants as before, and if they so choose, reference the new toolbar area as well. For what purpose I can't imagine, but it may become useful in the future; who knows.

 

This would have been the proper solution. Unfortunately it has one huge problem: we scripters (including the include devs) have gotten lazy and taken to using "shorthand". An example: Since we knew MSY1 was always 0 (and would never change...<insert evil soundtrack here>) instead of using (MSY1 + 150) to reference a point on the main screen we simply used 150 (since 0 + 150 is...150). Same with coords referencing inside the chat area, or the inventory area, etc. Instead of using coords relative to (MCX1,MCY1) to reference something inside the chat area we simply hard wired in the absolute coords. Not a problem as long as they never do anything silly such as oh I dunno add a toolbar at the top.

 

To make this work would require rewriting every single absolute coordinate reference in the includes to a coordinate relative to the upper left corner of whatever area of the screen it is in. That is a hell of a lot of work.

 

On the plus side if they ever make changes to the client layout (and this has happened multiple times in the past) we simply adjust the global constants and we are back in business. The includes would become much much more future proof. Is it worth the effort? I don't know. I'm torn.

Share this post


Link to post
Share on other sites

Shinra Tensei!!! - http://subversion.assembla.com/svn/gmrl/RS2%20Rewrite%20Project/RS2%20Tools/RS2_GlobalsConstAdv.scar

 

I stopped development of it, because it got complex, and it just doesn't look good (Shadow says). We should definitely do this though IMO it is the first step in making this include more awesome!

 

Also I wanted to rename, AND DID for a bunch of constants, and added some. There is constants I consider to be seen, and used regularly. AND some for specific things. For instance...Just recently I have pushed to OSI DepositBox functions that have constants defined at the start of the file. Same with the Inventory functions now. I have space between inventory slots, and all sorts of mess to make the functions all dependent on the constants.

 

This is science lols...

Anyway that is a start! IDK how we would do the map constants because you need functions for those I think. But for the constants that use simple math, and no functions we should be good. Another problem is the comments of the constants as well. Need to be rethought.

 

We need to seriously change the comments on OSI. Last updated, and Created By aint enough. We should add a Changed: thing in there too. So I could put on GetItemBounds, Changed: Made it dependent on inventory constants...etc.

 

I'm going to be busy the next couple days messing with this new computer, and cba for this. I added enough to osi this week :P

 

Also note that when you don't start at 0. Say from 100-200, x1 is at 100, and x2 200. To get the WIDTH it is x2 - x1 - 1. Or something like that. Wanted had that messed up a little bit. You do minus 1 because you are not starting at 0! You can even try it out in SCAR, and save a screenshot from (x1, y1, x2, y2) and it will come out on the properties of the saved image as x2 - x1 - 1. yadadadaddaaaaa,

Edited by LordJashin

Share this post


Link to post
Share on other sites

Like I said it would be ton of work and have to be planned out.

 

Nice include btw. Definitely a step in the right direction.

 

Edit: Been thinking...We may have to something similiar with the colors sprinkled throughout the includes. If the now in development HTML5 client becomes the norm the colors will likely change slightly.

Edited by Bixby Sayz

Share this post


Link to post
Share on other sites

I don't think they would dare move away from Java? Or is that toolbar thingy, them moving into html5? Idk.

 

There's not much we can do about the coloring. Just pray they don't come up with a SCAR script to take their RS2 images, and funk with the colors by using tol on them or some craziness. A system to change the items appearance in too many ways to keep up with...

 

Anyway, I think variables/constants could be renamed, but people that have been using OSI for a long time might get distraught by it maybe. That system would not be too hard to implement. Its just really hard to look at...

 

It makes sense to do it that way though, visually appealing or not. The more constants/variables/ and functions we can add to OSI from existing stuff could help the dependence. Like the login functions are just huge, I think they may be able to be broken down. I could add these to the suggestions. Once we do this enough, we could do it for randoms too. Get it down so that all we have to do is update constants/variables and SOME functions. Rather than rewriting much more code any time RS2 changes e.g. randoms, and etc.

Edited by LordJashin

Share this post


Link to post
Share on other sites
I don't think they would dare move away from Java?
Wouldn't they? Think of all the smart phones, tablets, etc. out there. HTML5 support is becoming the norm even on devices that don't support java.

 

In truth I suspect it will be both for a long time to come, in which case we simply continue to target Java.

Share this post


Link to post
Share on other sites
Wouldn't they? Think of all the smart phones, tablets, etc. out there. HTML5 support is becoming the norm even on devices that don't support java.

 

In truth I suspect it will be both for a long time to come, in which case we simply continue to target Java.

 

There will be a steady rise in botting if most games, if they do HTML 5 or through web browser in general. I know of two already that are doing this. One desktop game, and runescape ofc might. If you think about it, having their own client/software is the only way to get rid of most botting. Like with JAVA BenLand100 had to sandbox runescape in order to send it keys, mouse, and input. All you had before that was the browser which ALSO accepts keyboard, and mouse input from SCAR's commands.

 

There would be an insurgence if more popular games were accessible through browser too. Like if League of Legends went browser, I bet you SCAR would get a lot of activity...

Share this post


Link to post
Share on other sites
I was thinking of the +50 pixel offset to accommodate the toolbar specifically. Adjusting the entire client area down 50 pixels got us up and running quickly, but it is not IMHO a proper solution. And it makes it truly a pain in the ass to figure out coords on the screen when writing scripts now. On top of that I have encountered situations where I want to read a color that lies inside that first 50 pixels, which is now outside the client area and thus always returns 0 as the color.

 

The toolbar while annoying and of little use to us (at the moment) is a area of the client window, just as we have a main screen area, an inventory area, etc. A better solution would have been to define a new set of constants defining the boundaries of the new area. (MTX1,MTY1,MTX2,MTY2 perhaps?) And then adjust the other area constants to their proper location (ie. MSY1 would be changed from 0 to 50). Scripts can continue to reference the area constants as before, and if they so choose, reference the new toolbar area as well. For what purpose I can't imagine, but it may become useful in the future; who knows.

 

This would have been the proper solution. Unfortunately it has one huge problem: we scripters (including the include devs) have gotten lazy and taken to using "shorthand". An example: Since we knew MSY1 was always 0 (and would never change...<insert evil soundtrack here>) instead of using (MSY1 + 150) to reference a point on the main screen we simply used 150 (since 0 + 150 is...150). Same with coords referencing inside the chat area, or the inventory area, etc. Instead of using coords relative to (MCX1,MCY1) to reference something inside the chat area we simply hard wired in the absolute coords. Not a problem as long as they never do anything silly such as oh I dunno add a toolbar at the top.

 

To make this work would require rewriting every single absolute coordinate reference in the includes to a coordinate relative to the upper left corner of whatever area of the screen it is in. That is a hell of a lot of work.

 

On the plus side if they ever make changes to the client layout (and this has happened multiple times in the past) we simply adjust the global constants and we are back in business. The includes would become much much more future proof. Is it worth the effort? I don't know. I'm torn.

 

The UpdateRSClient, and Revert is much better for blahblah reasons. But you have a point. What I'll do is make the offset of the +50 a variable, and put it in those two functions (UpdateRSClient, etc).

 

Eventually I might make more constants into variables. But for now I've been changing some of the constants that could have a big impact e.g. the offset, and RS client variables that I'm using ConstrainRSBounds with now.

 

I think if we ever have OSI check the internet for updates. If RS changes one of these things or removes the toolbar finally xD! Then we can just update the variables on some server somewhere, and everyones will be updated too. So we have no broken crap. We could have it check for updates like every x minutes (make that a constant somewhere). ....yadadada

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.

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.


×
×
  • Create New...