fixthissite

Family? You joined today

The opinion/theory below is going based off what I'm seeing. Please correct me if I'm wrong. If you write a skilling script, there's a very limited amount of things you can do to make your script unique compared to other scripts of the same type. There's really not too much to a script, and honestly, there doesn't seem to be much diversity between bots doing the same skill (pretty simple minded). Please criticize anything I've just said; I'm not TOO familiar with scripting yet. Skilling scripts as they are now can easily be perfected, and there's not much reason to create a script after perfection (all the functionality needed to achieve botting for that skill). There's only so many skills you can cover, and with things like the Node framework, making a script is pretty damn easy. Scripts are too single-minded (in my opinion). They focus on one thing (skill, quest, activity), which people then question why they can't bot for hours on end. Being an ex-runescaper, I know people can play for days at a time without getting banned (from what I remember, the most I've played was 78 hours, legit playing). There's not much room for anti-ban, and it seems people are only focusing on random timing and path traversing for anti-ban techniques. What do you think of having a library of skilling scripts to choose from (or creating your own), "binding" those to your main script, then allow your main script to handle transitions between activities (where you can implement anti-ban techniques, such as unlocking music tracks if you're near an area that has a track you haven't unlocked yet; human-like actions similar to that). EScript A script today would represent a subscript in this, and you could easily create and distribute subscripts (if you feel current subscripts arent to perfection). The syntax would look like: @SubscriptBind(subscripts = { FiremakingScript.class, WoodcuttingScript.class }) public final class MyScript extends EScript { //handle human-like logic; explained later } Your subscript would look like: public final class FiremakingScript extends Subscript<MyScript> { //can use getScript() to access script; recommended to store in field public void process() { //similar to onLoop; framework handles random timing } } Developers could program at 2 different tiers: cognition (human-like logic) and abilities (subscripts). They can implement what they feel a human-like bot would do (some may think unlocking music tracks is a stupid anti-ban technique. I actually used to always love unlocking tracks ), and create diverse scripts by using different combinations of subscripts. You might be wondering about the paint. It's an optional feature. Each subscript has it's own paint (I have yet to create a master paint system), which you can create by subclassing a Paint abstraction, then bind to the subscript: @PaintBind(paint = FiremakingPaint.class) public final class FiremakingScript extends Subscript<MyScript> { //... } public final class FiremakingPaint extends Paint<FiremakingScript> { //getModel() to access script details to be rendered public void render(Graphics2D g) { } } The paint acts as the view, the subscript acts as the model, and the script acts as the controller, so technically this is the Model View Controller pattern if you were interested in knowing. This allows you to keep your code clean, and allows subscripts to be isolated and redistributable. The idea of this API is to take developer's focus away from developing what has already been done (with a few minor added features) which lacks anti-ban support, and directs their focus towards developing different types of "personality" for bots. I have also been working on a Goal system, to simplify the cognition system. The idea is to write Goals for a certain Script (not subscript) which performs switching between subscripts as needed to achieve the goal. Goals will be executed linearly unless you specify your own GoalManager. A custom GoalManager allows you to switch between subscripts mid way, storing an image of the current node's state before switching. This will be the heart of the cognition system, and is currently under construction. Right now, cognition is handled by simple conditional branching, allowing the developer to implement whatever logic he feels would prevent bans (woodcut for 50 minutes or until you get a certain amount of logs, then firemake. while walking, look for music tracks you haven't unlocked yet and see if you're near any locations). The uniqueness of the bot comes from the creativity of the developer. Keep in mind that you don't want your logic to be repetitive. There are many techniques to ensure your bot doesn't perform the same pattern of actions continuously. I am adding an AntibanBind, similar to the SubscriptBind, allowing you to encapsulate AntiBan techniques (such as scanning the chatbox for things that could influence the bot into doing something else). AntiBan instances are independent of your script, and should provide functionality. It doesn't decide when the anti-ban actions are performed; it should know nothing about your script or subscripts that can't be accessed through org.osbot.rs07.script.Script. It's primary goal is to provide your bot's cognition with tools that allow it to perform actions a bot typically wouldn't do. Lots of philosophy to be uncovered there. The main difference between a subscript and an antiban is the responsibility: subscripts process logic, antibans provide logic to be processed. Please, don't go easy on me. If you see something you personally don't find attractive, let me know in detail. I strive for constructive criticism, so let me know what you REALLY think If feedback suggests an alpha model should be released, it will be done so tonight (excludes the Goal system, but might include the AntiBan system).

That's exactly what he means. Java is a multipurpose language, with the verbosity to show for it. It's a lot of power for what's actually needed, and to create a good, clean script, you'd need a decent understanding of an actual programming language.With a language targeted for bot scripting, you can remove a lot of the syntax requirements Java's specification requires, allowing people to focus primarily on script related tasks. The amount of learning someone needs to do to write a script can be cut into a fraction

I sometimes put toilet paper in the toilet before I take a dookie to ensure the water doesn't hit my bum. Science ;)

There's no drawback; it just doesn't seem necessary in this case. My guess is he wanted to encapsulate the creation of node objects.Logically, the client (in this case, the Script class that uses the Node classes) shouldn't be in charge of the amount of instances of a specific node in the first place; being able to do "new MyNode()" is a design flaw itself. Only one instance of each node should exist, and there's no reason the client should be in charge of creating it. This allows you to increase encapsulation by preventing the client from being able to instantiate multiple objects of the same type and taking care of it for them in the framework. So yeah, that's my guess. As for performance, it's perfectly fine. I'd hardly refer to "newInstance()" as reflection, seeing how that's what goes on under the hood anyways. A lot of popular frameworks like Spring use reflection to provide a clean experience for the developer. Performance only takes an impact if you use it excessively through-out the entire application's life-cycle (such as in a loop, using reflection to constantly invoke a method). A few reflective actions performed only at the beginning of the application won't have any noticable effect on performance. I'm actually using reflection in my script related project as well ;) It's just for a more justifiable use.. Long story short, it could break encapsulation, but it can also increase it. Yes, performing things reflectively is more expensive than performing them through the actual language, but with a few simple benchmarks, you'll notice it's not as bad as some people might put it out to be. Just don't use it to continuously invoke methods (like invoking onLoop) or create multiple objects at a fast rate (like particle systems) Just a tip for the OP, you can't expect people to change based on a few tiny aspects

Store occurance.get(i) in a variable to avoid excess accesses to the map. Same with length/2, to lower the overhead from calculations The mode method is pretty expensive. Try something a little less intense: int mode(int...numbers) { int highestNumber = 0, mostOccurrences = 0; int[] counter = new int[numbers.length]; for(int i = 0; i < counter.length; i++) { int currentNumber = numbers[i]; int occurrences = counter[currentNumber]++; if(mostOccurrences < occurrences) { mostOccurrences = occurrences; highestNumber = currentNumber; } } return highestNumber; }

I heard OSBot prevents reflection, probably for security reasons. Are only certain features blocked? Can we still use Class#newInstance()?

From what I see, scripts tend to manually specify the locations and sizes of whatever they have in their paint. If there was an option to create paints using components and layouts, how many people would use that system? I know some people aren't familiar with layouts, but I feel the option to create and use layouts would be pretty neat. Not sure if this is the right section; please let me know if it's not and which section is best for things like this.

What "true knowledge"? And knowing how to work an IDE is not actually programming. Fixing errors is as easy as googling. Can't say you've shown any programming skills yet. I'm not trying to offend, but if you want to show off your status as a programmer, show some of your work. Talk is talk Idk.. From what I see, he simply suggested. You're the one who took it personal, throwing around attacks. I'm not understanding. What are you proving? He didn't say "You have to use a different IDE to fix the error".There's no need for the insults. If you think someone is wrong, whats the problem with nicely letting them know? Please, try to keep it clean man.. If you wanna continue this, send a message so we don't get this thread locked. I'm only willing to continue this if it's not on this thread, or if it's insult free and to the point (on-topic)

0:23 to 0:25

Are live chat agents responsible for resolving disputes? Keep in mind that if someone has a problem, they usually go to the live chat service for quick help. They aren't always happy.. If the agent thinks the payment is low, I'm not sure if they would consider some disputes "worth it". Don't want that affecting your PR. Off-topic: Your ~~~~ is stretching the page (at least it is on my phone). Mind shrinking them a bit?

"In order to learn you must desire to learn, and in so desiring not be satisfied with what you already incline to think" - Charles Peirce Knowledge derives from answers, which derives from questions, which derive from interest. To learn, you must wonder and ask questions. Forcing knowledge can lead to rushing. This results in gaps. If you do not have interest in it, do not force yourself to learn it. Make sure you are familiar with everything you currently think you know. There are TONS of programming pitfalls which you must be aware of when working on the field. Look for subjects that actually interest you. Many things are tied together; learning one aspect could lead you into learning another. If you have interest, you will ask more questions. Try not to make learning a chore. Observe the thoughts of other great developers. Joshua Bloch is one of my favorite developers, although the list of developers I actually follow is rediculous. They could say something that may inspire you to think in a different, more innovative way. A quote that really got to me: "An API should not only be easy to use, but hard to misuse" Don't limit yourself to one language. A lot of new languages are arising, bringing along a lot of innovation and long awaited features. Getting familiar with other language can really strengthen your overall view on programming. You'll find a lot of flaws in other languages, making you reconsider what you think is best for certain situations. Meet other programmers and exchange code. This is always a great way to learn new things. Although beware; if you don't do indepenedent research on what you learn from your partner's code, you could gain bad habits. Search and research. Some neat Java books (will be adding more; it's been a while since I've read any programming books ): Effective Java Code Complete Filthy Rich Clients Refactoring Java Puzzlers Hardcore Java Inmates Are Running The Asylum

Probably because it wasn't in the "roast scripters" section, and was thus considered off topic.If you would like to debate programming, I do not suggest going to a botting community to do so (gotta admit, that's pretty sad itself). You don't need to be a professional programmer to create scripts for bots, so I'm guessing the problem was you assumed otherwise. Although some of the programmers here are very talented, you shouldn't expect professional grade knowledge from every developer here. If you would like to debate programming, feel free to message me; I'm always willing to talk/debate about programming related things. Constructive criticism is nice, but attacking others is not. Please, next time, if you see someone who may lack knowledge, help them; don't attack

This is actually a side project of mine I've been working on a compiler for a less verbose language that accounts for certain design patterns in it's specifications (most design patterns exist due to lack of specification that enforces that structure) for the JVM. On the side, I've been writing up a lexical analyzer that abides by a slightly modified version of the node pattern a lot of scripters seem to use. Pretty funny that you've mentioned that, because you're 100% correct I already got something in the works. As far as I know, you simply upload a JAR containing the binary files to upload a script, yeah? If so, then I see no reason for compatability issues; BotScript would compile to bytecode (until further investigation of possibly using AOT compiled scripts on a native client)

I've heard people found no regrets in the switch. If you have time to get familiar with a new IDE, then by all means, explore.Testing has gotten pretty standard too, although there is a few things you should keep in mind. JUnit is easy to learn and easy to use, but doesn't support mocking (as far as I know/have looked). Mocking allows you to test in TRUE isolation, by creating mocks of dependencies that are needed, rather than including the dependencies in your tests. Mocking libraries exist, such as Mockito. Due to the nature of scripts, it's impossible to implement any true management system (such as the ones supplied in JMX). If you were to use a profiler, such as VisualVM, to view the running details of the bot's process, the resources used from your script will most likely be hard to properly distinguish from the resources used from the bot client. Profiling tools are useful, but be aware that you're testing the entire process; you might wanna come up with your own strategy for profiling in this situation (or look online for an existing solution. Embedding smaller applications into larger ones is actually pretty common) A problem all Java devs come across is how to properly benchmark. Simply creating a timer to measure the elapsed time of execution is not suitable for Java. You need to account for the VM warm-up, as well as optimizations performed by the compiler. Caliper is a great framework for micro benchmarking (benchmarking small units of code) in Java. Seeing how scripts aren't too complex (for now...), I doubt you'd need to explore past micro benchmarking. Do you know what will help you more than tools? Programming advice, of course! I've noticed my strategy for creating applications has changed quite a bit within the last couple of years. People tend to have their own systems, while others don't have systems. My system grew into a TDD (test driven development) mixed with DbC (design by contract). I start by writing out the actual logic of my application, keeping in mind that I should be programming to interfaces. Writing the logic first helps wrap my mind around what is going to be needed, as well as what isn't. TDD encourages the bare minimum. "Good code is not code which nothing more can be added to. Good code is code which nothing more can be taken away" - One of my favorite quotes DbC ensures I keep coupling low by having objects interact through abstractions rather than directly. Don't do what is not needed - that's a very important aspect of programming. Rather than trying to find things to add to your scripts, see how much you can take away while still keeping it's integrity ("ban-free", easy to use, ect..). Unless you NEED something, don't worry about it. It applies all through-out programming. It's actually the reason why people have troubles with design patterns; they try to force it in their code, when really they exist to solve specific problems

The only reason I would switch to IDEA is for the support of other JVM languages like Scala. Seeing how I rarely use Scala or Groovy, I didn't care much for wasting time getting familiar with another IDE. (I heard code completion was better? How about not being lazy? :P Code completion doesn't suck THAT bad on eclipse, especially if you specify your own templates) As you know, I'm not a scripter, so I'm not sure what could be considered useful in that category. The way I see it, all scripts are pretty much the same at their core (from what I hear, you guys use some kind of node system?). Other than IDs and different conditions, what varies between scripts? If you ask me, someone could create their own API specifically for scripting, but there's really no reason (since they should be included in the actual OSBot API, making any other scripting API obsolete). If you informed me on some of the tasks you feel could be managed by an API but are currently not supported in the OSBot API, let me know and I'll see if I know of any handy libraries. But scripting seems too strict to even want a third-party API, let alone need one. There's really not that much to a script (from what I've seen), and everything you could possibly NEED is in the OSBot API. Why add the extra dependencies?

What exception is being thrown? Please post the stack trace

Not sure if answering results in me being nice, or me getting trolled.... ... You screwed up the declaration of your mom's visibility m8.

obama

Favorite: Me Least Favorite: Me Is this staff impersonation?

I suggested an easier alternative. Although you might not need to worry about threading issues for scripts (kinda makes me assume scripts are somewhat primitive), it's a lot less verbose to do it right ;) Lazily initialization for singletons is a strongly flawed design, as there should be no reason to lazily initialize a singleton. The only reason you'd lazily initialize is if you were to call other static members from that class, which wouldn't make much sense single you have a singleton right there.Always good to learn

How about a notification system? Seems as if it would remove the need to monitor the entire game (although I'm not 100% sure what reasons a botter would montior their bot). Something that keeps you notified of what's going on without the need to display the game. Something like that sounds pretty useful

yes, so srs. howd you know i was srs about this? im sure u got a logical explination ya?

There's no way they're putting a "Wocka Flocka" in the white house.. Plus, he's only 28. Don't you have to be 35 to run or some shit?

Although Singleton pattern doesn't support inheritance, the Multiton pattern does. Only a few minor losses I can think of: - The ability to add a contract to a specific multiton value is no longer there; all multiton values must abide by the same contract. - The enum may get a bit bulky depending on what you're doing // Multiton public enum State { WALK_TO_BANK { @Override public void process(Script script) { } }, BANK { @Override public void process(Script script) { } }; public void process(Script script) { } Enum values are eagerly initialized (all multiton values are created as soon as the enum is loaded)