LordJashin Posted September 5, 2012 Share Posted September 5, 2012 (edited) 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 ---------------------------------------------------------- Confirmed Not Working: ---------------------------------------------------------- Randoms - Most are broken ---------------------------------------------------------- Working: ---------------------------------------------------------- Deposit Box functionsInventory FunctionsMajority 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.scarInAbstractBox 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 October 3, 2012 by LordJashin Quote Link to comment Share on other sites More sharing options...
Bixby Sayz Posted September 5, 2012 Share Posted September 5, 2012 Here we can update, and put together a list for OSI. For what needs work, what is broken, and what is working! Will do! Quote Link to comment Share on other sites More sharing options...
LordJashin Posted September 6, 2012 Author Share Posted September 6, 2012 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. Quote Link to comment Share on other sites More sharing options...
Bixby Sayz Posted September 6, 2012 Share Posted September 6, 2012 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. Quote Link to comment Share on other sites More sharing options...
LordJashin Posted September 6, 2012 Author Share Posted September 6, 2012 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 . Quote Link to comment Share on other sites More sharing options...
Bixby Sayz Posted September 6, 2012 Share Posted September 6, 2012 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. Quote Link to comment Share on other sites More sharing options...
LordJashin Posted September 6, 2012 Author Share Posted September 6, 2012 (edited) 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 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 September 6, 2012 by LordJashin Quote Link to comment Share on other sites More sharing options...
Bixby Sayz Posted September 6, 2012 Share Posted September 6, 2012 (edited) 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 September 7, 2012 by Bixby Sayz Quote Link to comment Share on other sites More sharing options...
LordJashin Posted September 7, 2012 Author Share Posted September 7, 2012 (edited) 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 September 7, 2012 by LordJashin Quote Link to comment Share on other sites More sharing options...
Bixby Sayz Posted September 7, 2012 Share Posted September 7, 2012 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. Quote Link to comment Share on other sites More sharing options...
LordJashin Posted September 7, 2012 Author Share Posted September 7, 2012 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... Quote Link to comment Share on other sites More sharing options...
LordJashin Posted October 3, 2012 Author Share Posted October 3, 2012 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 ! 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 Quote Link to comment Share on other sites More sharing options...
AnthonyPhics Posted April 6 Share Posted April 6 オンライン カジノは、プレイヤーが自宅にいながらにしてポーカー、ルーレット、ブラックジャック、スロットなどのギャンブル ゲームを楽しむ機会を提供する仮想プラットフォームです。 オンラインカジノは、アクセスのしやすさ、ゲームの種類の多さ、そして大金を獲得する機会があるため、年々人気が高まっています。 オンラインカジノの主な利点は、利便性とアクセスしやすさです。 プレイヤーは、通常のカジノの営業時間に制限されず、いつでもゲームを楽しむことができます。 必要なのは、インターネットにアクセスできるデバイスと、カジノのウェブサイトにアクセスできることだけです。 これにより、プレイヤーは従来のカジノによくありがちなストレスや緊張を感じることなく、快適な環境でプレイすることができます。 オンラインカジノのもう1つの利点は、ゲームの選択肢が豊富なことです。 ユーザーは、それぞれ独自のルールと勝利の機会を提供する何百もの異なるゲームから選択できます。 技術革新のおかげで、オンライン ゲームのグラフィックとサウンドは高品質になり、プレイヤーは興奮と情熱の雰囲気に浸ることができます。 さまざまなゲームに加えて、オンライン カジノはプレーヤーにさまざまなボーナスやプロモーションも提供します。 これらは、スロットのフリースピン、プレイのための追加のお金、または貴重な賞品が得られる特別なトーナメントなどです。 このようなボーナスにより、勝利の可能性が高まり、ゲームがさらに楽しくなります。 もちろん、オンラインカジノでのプレイにはリスクがあります。 ギャンブルには依存性がある可能性があるため、自分の感情を監視し、支出をコントロールすることが重要であることを覚えておくことが重要です。 カジノはまた、責任あるゲーミングをサポートし、自己排除や賭け金制限の機会を提供します pornhub app 全体として、オンライン カジノはギャンブル愛好家にとって便利でエキサイティングなエンターテイメントを提供します。 幅広いゲーム、ボーナスの選択肢があり、いつでもプレイできるため、世界中のプレイヤーの間で人気が高まっています。 ただし、責任あるゲームと、ゲームが単なる楽しみと娯楽の源であるように自分の行動を制御する能力について覚えておくことが重要です。 Quote Link to comment Share on other sites More sharing options...
