fixthissite

The guy on the left's head seems like it should be a little more forward. Other than that, it looks amazing man, keep it up! Do you do game sprites?

What decode said. This kind of stuff should be handled by the OSBot client anyways

What's with all these wack requests? One guy wanted code which determined if there were 10 buckets on the ground.. Mind if I ask the reason? Go look at the code I posted on that topic; a simple modification can make it work for what you want. It takes advantage of the Stream API. Simply add a Position parameter, and compare it against item.getPosition() using equals

Have you seen Saving Private Ryan? If you like war movies, that's a good one

Accidental repose - Ignore this message

class PaintTimer { private static final long NANO_SECOND = 1000000000L, BOUNDS = NANO_SECOND * 2; private long previousFrameTime; private long timeElapsed; private int secondsPassed; public int countDownUntil(boolean condition) { if(condition) secondsPassed = 0; long currentFrameTime = System.nanoTime(); timeElapsed += currentFrameTime - previousFrameTime; previousFrameTime = currentFrameTime; if(timeElapsed > BOUNDS) timeElapsed = 0; else if(timeElapsed >= NANO_SECOND) { secondsPassed++; timeElapsed = 0; } return secondsPassed; } } Your script would look something like: final class MyScript { private PaintTimer timer; public void onStart() { timer = new PaintTimer(); } public void onPaint(Graphics2D g) { int secondsPassed = timer.countDownUntil(getCondition()); //use secondsPassed } private boolean getCondition() { return ...; //your condition } }

After checking out the API, it seems there is no script field. But it seems getGroundItems() is declared in the Script class, so use that knowledge to fix up your code

It's not really about safety measures. It's the exact same execution; the null check is just performed in the equals method, hidden away.And count() returns a long, which is why I suggested casting. But depending on the situation, you could avoid the overhead of casting (trading memory for runtime performance) by keeping it a long.

No need for allGroundItems.size() > 0 The for loop already does this kind of check. Also, you could switch groundItem.getName() != null && groundItem.getName().equals(groundItemName) to groundItemName.equals(groundItem.getName()) Allowing the equals call to perform the null-check on getName. __________________________________ Using the Stream API: public long getAmountOf(String itemName) { java.util.List<GroundItem> groundItems = script.getGroundItems().getAll(); long numberOfItems = 0L; if(grounditems != null) numberOfItems = groundItems.stream().filter(item -> itemName.equals(item.getName())).count(); return numberOfItems; } This is based off Mysteryyy's use of script.getGroundItems().getAll(); I've never actually used this myself (yet). If you want to return an int, simply cast when you return. Although, you could just have a boolean method: public boolean near10Buckets() { return getAmountOf("Bucket") > 10L; } To prevent casting overhead.

Sounds more like the OSBot API needs some fixing, removing those "beginner's traps", making it easier to use.Sorry to hear about the potential fustration. Although, I believe a list of "pitfalls" would be better suited for the "Client Bugs & Suggestions" section. Fix the problem at it's core

That used to be the prefered way of avoiding tons of parameters (pass a map) until the builder pattern came around. A map doesn't enforce concrete configuration. When the client is setting the config using a map, they are unaware of what configuration options are available; it requires you to document what SHOULD go in the map. I actually came across a question on StackOverflow about this. The answers all suggest using a more type-safe solution. Maps aren't bad, and they are definitely less verbose than the builder pattern. But compile-time safety is a HUGE aspect. It's the reason why Oracle is choosing Jigsaw over OSGi for modularizing the JDK; OSGi enforces runtime modularization while Jigsaw enforces compile-time modularization

..What about ban evading?

That doesn't enforce any compile-time safety, which is a pretty big factor in API design. Imagine if the entire JDK was built without compile-time saftey measures; the cognition required to write a program would be rediculous. It's best to inform the developer of a problem as soon as it happens (compile-time). If not possible, inform them at runtime (excpetions). Logical errors should be prevented at all costs, reducing the amount of "wtf moments" (not being able to easily explain the result of the code) and undocumented rules

This was a design I use in cases where configuration should be set by the client (person using your code) for a framework. The idea is to allow the client to specify the configuration, but prevent the client from storing an instance of the Config so it can be modified later on; a truely immutable config. This is a design I came across myself through experimenting. It started by simply passing the client a Config object, which is used to specify type-safe configurations as well as guide the client by showing them their options (which properties should/can be set) through templates. This means when you put a period after config, it'll give you all the available methods you can choose from, leaving out any irrelevant methods. public final class Config { //details needed by the framework, but not by the client Config() { } //declare setters so the client can specify //declare getters so the framework can access } public abstract class Framework { public final void start() { //check if running Config config = new Config(); init(config); //use config } protected abstract void init(Config config); } public final class MyApp extends Framework { protected void init(Config config) { //set config through setter methods } } The idea was to hide the ability of creating a Config from the client. The framework would pass in the config, ensuring the client couldn't create "garbage" config objects. The problem with this is that MyApp can store the config object in a field, allowing the client to mutate it (change it's state) later. Our Config is not immutable, because we NEED to set the values in a place other than the constructor. We could implement validations in the config's setter methods, to ensure each field is only set once, but that would be quite a bit to manage. To fix this, I implemented a Builder for Config. The Builder pattern allows the developer to specify the properties of an object, then build it afterwards, allowing immutability after building. To do this, we pass the responsibility of creating the Config class to it's builder. The developer uses the builder to specify the properties (which are stored in the builder). Once you decide to build() the object, the Builder passes itself to the constructor of the object we want, initializing the fields with what we specified in the builder: public final class Config { //private final fields private Config(Builder builder) { //use builder to init final fields } public static final class Builder { //config properties; will be transfered to Config public Builder setProperty(...) { //assign to field return this; } public Config build() { return new Config(this); } } } Instead of passing a Config object to the client, we would pass a Config.Builder object. This will allow them to set the properties of the config, while ensuring the properties are immutable. There's a downside to this: Framework doesn't have any access to the config the client builds right now; it simply creates the builder and passes it to the client. We need to have the client return it: public abstract class Framework { public final void start() { Config.Builder builder = new Config.Builder(); init(builder); } protected abstract void init(Config.Builder builder); } public final class MyApp extends Framework { protected void init(Config.Builder builder) { return builder.setProperty(...).build(); } } The client can hold a reference to the Config, but is unable to mutate it. Although this works, we can see that the client doesn't have any reason to know about the Config. We can remove the client's ability to access the Config by removing their ability to build it, and forcing them to return the builder after they specified the properties (allowing the framework to build it). Simply protect the Builder#build method (as well as Builder's constructor; no reason the client should be able to instantiate it). The final API design looks like: public final class Config { private Config(Builder builder) { } public static final class Builder { Builder() { } Config build() { return new Config(this); } } } abstract class Framework { public final void start() { Config config = init(new Config.Builder()).build(); //use config } protected abstract Config.Builder init(Config.Builder builder); } public final class MyApp extends Framework { protected Config.Builder init(Config.Builder builder) { return builder.setProperty(...); } } I don't expect this to be used, seeing how a system like this is not needed in scripting. I just thought some programmers may be interested in such development processes. I also criticise this as being verbose, but it's a step up from "no design". Responsibilities, encapsulation and enforcing a "hard to misuse API". This also may seem like a complete overkill to those who don't care for strong design, so if you're a "if it works, good enough" kind of developer, this is obviously not a topic for you :P Feel free to leave feedback!

Reminds me of South Park: Human Centipad ;) Just don't use his services

Feel free to message me at any time to chat about programming I also have a few guides in the Programming Help > Tutorials section, so feel free to drop by there and criticize where possible! Welcome!

Hey, I'm Vince, a computer scientist in the making If you need any advice, feel as if you might be able to teach me a thing or two, or just want to chat about computers, feel free to message me! I'm still somewhat new when it comes to the botting scene, but I'm slowly getting the hang of it. If you have any botting questions, I'm probably not the best person to go to right now for that (as I still don't know ALL the details), but I could probably assist on anything else programming. So don't be shy Welcome!

I don't get it. He's getting in trouble for being social? Is he posting spam or something? If not, I see nothing wrong. Make friends, socialize.. Especially since the chat box is not currently available, you would expect such behavior. People get bored and want to chat.

What is the purpose of this question? Why do you want to know the things you can and can't do in a script? What are your plans? Would be easier to mentioned what you were planning on doing. That way, we wouldn't have to exhaust every stupid possibility (like no porn, no hacking, no killing the president, no hunting til hunting season...)

Same here (until I sold my account). Was a level 3 skiller with all 50+ skills, a few 90s, 79 slayer, finished lost city (zanaris peng ;)), about 5 tracks from air guitar, and not a single 99

Don't think he has ever said "Forghetti". You mean "vomiting on his sweater already, mom's spaghetti"? Or am I missing a joke here

That's not correct; Windows 8.1 actually consumes LESS resources. You should try profiling it. Lower memory usage, better clock times which results in faster response times.Not downing your opinion that Windows 7 has a better UI; I share the same opinion, which is why I actually still use Windows 7

There we go; an actual argument I gotta agree, I'm not a fan of the UX of windows 8, especially since I don't own a touch screen. But performance wise, 8.1 definitely takes the cake.Keep in mind, this is about windows 8.1, not the initial 8.0, and he is asking in terms of power, not UX. Windows 8.1 takes less power (allowing for longer battery life). On top of everything mentioned, account for factors like boot time and it's hard to believe Windows 7 could ever be considered the "more powerful system". I gotta agree with the fact that Windows 7 has a better user experience. If possible, look into linux. Although it lacks support for mainstream programs like Word and Photoshop, the stability is unmatchable. If you're looking towards performance, Linux is your answer. Windows actually tends to degrade with time, mostly due to your registry getting cluttered. Believe it or not many Windows users actually understand how to properly take care of their Windows systems, which leads to slower performance over time. From what I've seen and experienced, this is not a problem for Linux machines

Could we at least get some reasons why you think Windows 8.1 sucks so much? From what I've researched, less memory usage, better mutlicore support... Haven't heard much bad about Windows 8.1 other than lack of support for legacy apps and games. Also, how could you give an opinion on Windows 10 if you haven't even used it yet? Why should people 'not hesitate to upgrade'?

Family? You joined today