fixthissite

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()?

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

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)

Prevents inconsistencies. But can be a victim to deserialization (you can serialize without needing to implement serializable by declaring readObject and writeObject methods) and instantiation through reflection. Not to mention, public enum Singleton { INSTANCE; } Is a lot let verbose ;)

I post programming tips on my twitter, so feel free to follow me or check in every now and then to see if I've posted anything new. You could learn some neat stuff. @emigh_scott If you post neat stuff, let me know. Im always looking for neat stuff. If you know anyone who may be a supplier of neat stuff, let me know. Neat stuff, guys. Keep up the good work

Making it return new GUI() doesn't ensure only a single instance of that class will exist within memory. One of the most important aspects is ensuring new GUI is only called once. Lazy initialization would make that suggestion more reasonable: public static GUI getInstance() { if(instance == null) instance = new GUI(); return instance; } But honestly, creating singletons using classes is extremely tedious, as well as dangerous. For example, 2 threads call getInstance(). First thread sees that instance null, initializes it. Right after thread 1 sees that instance is null, but before it has a chance to initialize it, thread 2 could also see that it's null and attempt to initialize. To prevent this, you'd need double check locking. But even that doesn't prevent new instances through reflection or deserialialization. To me, it doesn't make sense to use a class for a singleton anymore; too much tedious work. Just use an enum. Might actually write a guide on this

This is why I always recommend using enum for singletons. Its almost impossible to mess up a singleton using an enum. Glad to hear you got it working

It would be extremely helpful if I saw the entire singleton class. Im going based off assumpsions right now cause you're leaving out important info, such as if the field is already initialized, or if you're replacing the singleton instance by accident (make the field final). You should NOT be replacing the object in the field AT ANY TIME. You need to call `getInstance()` in your Runnable as well. Not sure why you took that out; you meed to make sure ALL swing code executes on the EDT. That littl3 change could be contributing to the problem..