fixthissite

Rather than manually typing out the experience table, you can use the formula Jagex uses to calculate it dynamically. Here's a little snippit if you want to use it in the future: public static int[] createTable(int level) { int[] table = new int[level]; for(int i=1, b=0; i < level; b += i + 300 * Math.pow(2, i / 7d), table[i] = i == 99? 200000000 : b/4, i++); return table; }

If it weren't for competition, the gaming industry will be no where near where it is today. We wouldn't have Sonic if it weren't for Sega wanting to compete with Mario. We wouldn't have pushed towards 3d as we did if it weren't for the bit wars.Competition drives innovation.

Java would never remove primitives. Even with Java 9's value type, which lowers the footprint of object creation, they will not be removed. It would break too much code. Check this out

I understand why you prefer it that way, especially seeing how you're already a scripter (probably familiar with that style). But for a beginner scripter, or even a beginner programmer, it could be quite easy to forget to add a condition to getState() or possibly forget to call the "brain" methods (I call em behavioral methods) in the onLoop. The style I proposed doesn't require the scripter to focus on 4 sections independently (the decisions, the decision makers, the executor and the brain). After setting up the onLoop method, they are forced to implement everything that's needed (decision, decision maker, the brain) as soon as they create a new decision. It's nearly impossible to forget to add a condition with this style, since everytime you create a new decision, a compilation error occurs if you forget to create the "decision maker" or the "brain" for a decision. In the functional style, if you were to forget something, you wouldn't realize you accidentally left something out until after you've ran the script. Compilation errors are always preferred to runtime errors, since they inform you of a problem right away. As the script grows in size, there's more potential to mess up if the code doesn't enfornce such rules (every state must have a condition and behavior)

You are doing !cow.isVisible before checking if cow is null. Change if(!cow.isVisible() || cow == null) to if(cow == null || !cow.isVisible())

What does this have to do with this thread?I suggest creating your own thread for this, or better yet, read the tutorials (I have a tutorial on creating a GUI for settings)

First, I'd like to say that you shouldn't decide that a coding style is good for beginners soley due to the fact that it uses primitive coding techniques (which programmers tend to learn at an early stage). Code which requires to to focus on only one thing, rather than changing 3 different things to implement what you want, is good code for a beginner. To give you options, there's another way of handling the states, which I find to be a lot cleaner: class MyScript extends Script { public int onLoop() { for(State state : State.values()) if(state.canProcess(this)) state.process(this); } enum State { DROP { boolean canProcess(MyScript script) { return script.inventory.contains(...); } void process(MyScript script) { script.inventory.drop(...); } }, STEAL { boolean canProcess(MyScript script) { //... } void process(MyScript script) { //... } }; abstract void process(MyScript script); abstract void canProcess(MyScript script); } } I understand a few people aren't syntax savvy, and would love to point and yell at my code. Please read below first.. In the functional style code (creating getState() method and what not), there's quite some room to mess up. 1. Forget to specify the state condition in getState() 2. Forget to account for the state in onLoop 3. Forget to call the behavioral methods in onLoop 4. Forgetting break statements With this new, object oriented way, you no longer need to worry about the onLoop method (once you have created it, that is); it will not change, so you won't forget to account for states. To create a new state, you simply create a new enum value (with a body to declare methods). Each enum value is forced to declare a conditional method and a behavioral method, so the user will not forget to account for those. Rather than being required to focus on onLoop() and getState(), all you need to do (literally) is define your state. Adding states is easy as pie.

Get ready for a long post, buddy. It depends. The easiest way to handle this would be to hardcode the settings into the DefaultAPI and pass that around as you've mentioned, more preferably creating a Settings type to decompose the DefaultAPI: class MySettings { private int logId; public int getLogId() { return logId; } public void setLogId(int id) { logId = id; } } class DefaultAPI extends API { private MySettings settings; public void setSettings(MySettings settings) { this.settings = settings; } public MySettings settings() { return settings; } } You could then create an instance of MySettings whenever the user clicks the "start" button on your GUI, passing it to the API. The code above does not account for (im)mutability; it does what you mention, but it's decomposed for easy maintenence. It allows you to adjust the settings at just about anytime, and you can modify the settings in different ways. So now comes the encapsulation, which strongly depends on how you want this to function. If the settings are handled at the start of your script, and should not be modified afterwards First, remove the ability to modify the settings property in DefaultAPI. You can do this by creating the API when you create the user clicks the "start" button to start the script. The idea is that the GUI handles the "arguments" of the script (similar to how the VM has VM arguments and command-line programs have command-line arguments): class GUI { private Object lock = new Object(); //used for waiting public DefaultAPI create() { GUI gui = new GUI(); gui.setVisible(true); //halt thread until user clicks "start" button try { synchronized(lock) { lock.wait(); } } catch(InterruptedException e) { //... } MySettings settings = ...; DefaultAPI api = new DefaultAPI(settings); return api; } private ActionListener listener = event -> { synchronized(lock) { lock.notify(); } }; } class DefaultAPI { private MySettings settings; public DefaultAPI(MySettings settings) { this.settings = settings; } public MySettings settings() { return settings; } //can no longer switch instance of Settings } class MyScript extends Script { void onStart() { DefaultAPI api = GUI.create(); //pass api to nodes } } So once you've passed the API the settings, it can not be modified by passing the API a new MySettings instance. Although, nodes can still adjust the settings through the setter methods of MySettings. For situations like this, where we want to be able to optionally set values on creation, but prevent them from being modified after creation, we would use the builder pattern: class MySettings { private int logId; private MySettings(Builder builder) { logId = builder.logId; } public int getLogId() { return logId; } //no mutators; cannot adjust settings after creating public static final class Builder { private int logId; public Builder setLogId(int id) { logId = id; return this; } //other builder methods go here... public MySettings build() { return new MySettings(this); } } } When you create the API in GUI.create(), simply use the builder: MySettings settings = new MySettings.Builder() .setLogId(/* grab from component */) .build(); DefaultAPI api = new DefaultAPI(settings); In this situation, a builder is an overkill; you could simply pass the logId to the constructor. But as the amount of settings options increase, so will the amount of constructor arguments. If you have 10 settings, all which are of type int, it could easily confuse the developer, which is why a builder is preferred. Not sure why theres no support for this in the API already. If I were you guys, I'd request more support for things like this (GUI, script settings). Just to clear the air, it is prefered to use static getter/setters rather than accessing a static field directly. You can read more on my "Use Getter Methods, Not Public Fields" thread - the idea is to hide implementation details, allowing you to change how you store a property without breaking code that relies on it. As for using static getters/setters for this, it would make it a LOT easier. Although, when it comes to unit testing, difficulties arise (hard to isolate code that relies on global state). It could also make graphing your code a mess, with edges that fly all over the place. It's best to keep things as encapsulated as possible. Rather than accessing something globally (accessing a dependency globally), pass in the dependency through a method/constructor. This is called dependency injection, and makes code crazy easy to unit test. Don't do class MyClass { public void doSomething() { int answer = OtherClass.number + 5; } } Do class MyClass { public void doSomething(int number) { int answer = number + 5; } } Passing in the number when you call the method. Sorry for the long post, I like to be fluent.

Never been to college, but I study a lot, and I feel it has more to do with how you use your time, rather than how much time you put in. It would probably be better to ask for study tips. I like knowledge, so I do personal studies (consider me a nerd). Through my studies, I have came up with a few tricks to decrease the amount of time I spend in a subject, while still learning a vast majority of it, which I'm sure that's something you'd be more interested in knowing First thing you gotta do is realize a few things: As I said before, I've never been to a physical college, but Coursera offers free online college courses, which is how I've came to realize most of the things I stated above. I really believe independent studies, along with a mentoring, is the best way to achieve knowledge. So, now for those tips.. Hope these tips help in your studies. Keep in mind, these are based on my experiences, so don't take it as complete fact; they are just things I seemed to have realized over the years.

You asked me to take a look at your code, which I gave a small review here. I got on a computer and was able to run this, got an error right away: java.io.FileNotFoundException: gLEPkie8@4MCmCD.txt (The system cannot find the file specified) This is because you never check to see if the file has already been created; you assume the file already exists on my system, which it doesn't. You should be doing: File file = new File("gLEPkie8@4MCmCD.txt"); if(!file.exists()) file.createFile(); You aren't setting the location of your frame. Usually, people center it, although even that can cause problems (people not realizing they accidentally opened multiple windows). Try implementing JFrame#setLocationByPlatform(boolean) and tell me how you like it. I see you attempted to add a hints to your text field (shadowed text). The problem is, it doesn't have that "shadow" feel, and doesn't disappear when you click on the field. Here's a little class I built up, which supports hints: import java.awt.Color; import java.awt.event.FocusAdapter; import java.awt.event.FocusEvent; import javax.swing.JTextField; public class JHintedTextField extends JTextField { private String hintedText; private boolean hintDisplayed; public JHintedTextField(int columns, String hintedText) { super(columns); this.hintedText = hintedText == null ? "" : hintedText; addFocusListener(adapter); displayHint(hintedText); } public JHintedTextField(String hintedText) { this(0, hintedText); } private FocusAdapter adapter = new FocusAdapter() { public void focusGained(FocusEvent e) { if(hintDisplayed) removeHint(); } public void focusLost(FocusEvent e) { if(!hintDisplayed && getText().isEmpty()) displayHint(hintedText); } }; private void displayHint(String hint) { setText(hint); setForeground(Color.GRAY); hintDisplayed = true; } private void removeHint() { setText(""); setForeground(Color.BLACK); hintDisplayed = false; } } Rather than using whats referred to as a stream loop [while((line = in.readLine()) != null)] is redundant when using a BufferedReader ever since Java 8: BufferedReader reader = ...; reader.lines().forEach(line -> { ... }); I can add the same user/pass to the "Saved Passwords". You should instead be using some kind of Set to store your entries. It would also be better practice to combine the label and field into it's own panel (a new panel per entry), so you could add functionality such as right clicking an entry to remove it. As for the problem you told me earlier (preserving the state of a map between shutdowns of your app), here's a little example of storing a Map object onto your drive, then loading it back into memory: void saveObject(Map<String, String> map) throws IOException { ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("name.anyAbbreviation")); out.writeObject(map); } Map<String, String> loadObject() throws IOException, ClassNotFoundException { ObjectInputStream in = new ObjectInputStream(new FileInputStream("name.anyAbbreviation")); Map<String, String> m = (Map<String, String>) in.readObject(); return m; } Rather than using a map, though, you should create a new type, PasswordEntry, which contains the information for the entry (such as the name and password as you have now, but also things such as suggested expiration dates, date created, and possibly details about the account it's saved for such as "This is for a woodcutting account" or something"). I have to hop off the computer, but hopefully what I've said so far helped. I'm sure there's more that can be fixed up, so let me know if you want me to take another look once you've fixed it up a bit.

Of course, why should I have thought OSBot was consistent? Silly me...

Why wouldn't it? "Write once, run anywhere (assuming you have a JVM)" - Java

Sounds like a job for serialization (preserve the state of an object after shutdown). Create an ObjectOutputStream and call writeObject, passing in the map as the parameter. You can then read it back in using an ObjectInputStream. This will prevent the need to read text from a file as you currently are. I'm not at a computer, so I can't run your app. But looking at the code, there are a few things you should do: 1. while (x < SliderT) { randomNum = rand.nextInt(random.length()); password += random.substring(randomNum, (randomNum + 1)); x++; } You should be using a StringBuilder for password. Right now, you are using String concatenation, which actually uses a StringBuilder under the hood (view the bytecode). The problem is, each time you do "+=", a new StringBuilder is created, which means you are creating a bunch of excess objects which may impact performance. You should instead do: StringBuilder password = new StringBuilder(); while(...) { ... password.append(random.substring(...)); ... } 2. Boolean Button1, Button3, Button4, Button5; Button1 = jToggleButton1.isSelected(); Button3 = jToggleButton3.isSelected(); Button4 = jToggleButton4.isSelected(); Button5 = jToggleButton5.isSelected(); I'd usually ask why you are declaring and assigning in different locations, but there is a bigger problem here: autoboxing. Unless this code was being called within a long running loop, it doesn't matter as much. But there's still no reason why you should be doing it. Don't use the Boolean reference type, use the boolean primitive type. Otherwise, you're basically doing Button5 = new Boolean(...); Creating excess objects that aren't needed. You would also be able to finally do if(!Button5) rather than if(Button5 == false). 3. if(jToggleButton4.isSelected()){ jToggleButton4.setText("ON"); } else { jToggleButton4.setText("OFF"); } Use a ternary: String text = jToggleButton4.isSelected() ? "ON" : "OFF"; jToggleButton4.setText(text); 4. Try to go through an replace all ActionListener anonymous classes with lambda expressions. This will reduce the amount of class files generated, reducing the amount of files needed to be loaded by a classloader. 5. p.removeAll(); p.repaint(); This shows me you have yet to understand the component system Swing provides you. I highly suggest taking a deeper look into it. You need to revalidate after affecting the component hierarchy (add/remove), not repaint. There are a few other things I wanted to note down, but my phone is dying so I'ma have to come back to this. If you'd like me to post this on your code thread, let me know and I'll transfer it over.

After giving another look, it seems you're trying to add components to an already visible panel. I had a hard time understanding your problem, but forgetting to validate() a container (which is already visible) after adding components to it will result in an empty container: "Layout-related changes, such as setting the bounds of a component, or adding a component to the container, invalidate the container automatically" If I'm understanding this correctly, you want to iterate through the entries of a map, and display a label and field for each entry. Here's a little example (which performs what you want) that shows what I'm referring to about validating. Simply uncomment the pack() to make the code below work: public class Demo { public static void main(String[] args) { Demo demo = new Demo(); EventQueue.invokeLater(demo::init); } void init() { Map<String, String> map = createMap(); JFrame frame = new JFrame(); frame.setLayout(new FlowLayout()); frame.setDefaultCloseOperation(3); addComponentsTo(frame, map); frame.pack(); frame.setVisible(true); } void addComponentsTo(JFrame frame, Map<String, String> map) { JPanel panel = new JPanel(); GridLayout layout = new GridLayout(0, 2); layout.setHgap(0); panel.setLayout(layout); JButton button = new JButton("..."); button.addActionListener(event -> { map.forEach((key, value) -> { JLabel label = new JLabel(key); JTextField field = new JTextField(value); panel.add(label); panel.add(field); //frame.pack(); }); }); frame.add(button); frame.add(panel); } Map<String, String> createMap() { Map<String, String> map = new TreeMap<>(); map.put("First", "FirstItem"); map.put("Second", "SecondItem"); map.put("Third", "ThirdItem"); return map; } } I used a TreeMap to retain order in the map. Although "validate()" will display the items, it will not size the frame to fit them. You should instead "pack()" as I did, which validates the entire component hierarchy.

1) Not enough code, and please elaborate a little more on what you mean (when does it appear? is it consistent behavior, as in does it happen every time?) 2) Add the panel to a JScrollPane Is there a reason why you're casting so much? Why are you referencing the keySet using the Object type, rather than Set<String>?

I haven't shown any examples of BotScript. And keep in mind, this has to run on the JVM. I'm sure people have created subsets of the ECMA that compile to bytecode, but I don't think anyone in their right mind would write a compiler that targets the JVM which is fully compatable with the specification.Bugs arise from complex specifications. It would be a lot easier for a beginner to create a bugged script using Java than they would using a language with very strict specifications, not to mention a compiler which can give script related warnings/errors. Verbosity is a huge factor in programming. It's not about being lazy. It's about saving time. I can understand if you don't feel it's worth it. You could just use a project template to do all the boilerplate typing for you. But a new language will allow us to do things other languages have not accounted for if we find something suitable.

So you're saying anything other than Java would be a bad idea? Even if it supports creating type hierarchies?

Thats fine, everyone has their opinions. But what system are you referring to? Any new language in general?

I like the declarative style you got going on Are you using an interpreter or are you compiling to Java source code? Very nice The declarative style you use for the transitions is extremely appealing. I fixed up the grammar a bit (I might come back to this as a reference), just made Condition recursive to allow "if bool and bool or bool ..." instead of the kleene closure on the "if Condition". The lexical analyzer I currently have does not account for whitespace. Would you find it preferable if it did? Wasn't sure if I should account for it or not, as most languages now-a-days (excluding python and a few others of course) don't account for it.

I'm not focused on teaching people through this language (not trying to kill 2 birds with 1 stone), nor should bot scripting be strongly related to learning Java (standards should be a bit higher...). If you script to learn Java, neat. Java would still be an option. But this is focusing on cutting down the production time of writing/maintaining a script, which could be extremely beneficial in the case that true AIO scripts go mainstream. As for those who just want to write scripts, and don't care for learning Java so they can take it home with them, they can now do their thing. Learning BotScript will require a lot less time than learning Java, since you do not need to explain general aspects (like what a class is or what an object is)

I already have my own parser (LALR), which I would love to make improvements to (such as supporting advance attributed grammars). I could have taken the lazy way and went with bison, but I figured the implementation practice would be nice. I'm not sure what you're referring to by "interpret first, the compile once the grammar is final", as the grammar shouldn't require constant updates (that would require updating the compiler consistently, redistributing, ect..). Mind elaborating on what you mean? I didn't want the syntax for the grammar I have now influencing the ideas of others, as there could be a better view on how scripts should be looked at. I'm not a dedicated scripter myself, so I'm not 100% sure if what I currently have is fit. I don't really mind showing (a few people have already seen it), but I'm really hoping to keep my influence on other's ideas to a minimum right now. Feel free to message me if you're really interested! Although it would be much better if you first gave input as to what you think would be a good syntax for writing scripts. Do you understand what I mean by "overkill"? Sure it's easier to get Java atm. Tons of IDEs support it. Can probably get easy debugging help too. But as I said before, the flexability of Java results in excess syntax for what we are trying to do. If we could cut out half of the letters we are required to type to write a script, then why not (laziness not being a valid answer...)? The change is bound to happen, so might as well sooner than later. It's a big project, which is why I came to the community for help. This needs more manpower. The outcome of this project strongly depends on the community's motivation and determination. If you guys don't put enough into this, then it's obvious people don't care about it as much as I thought they would, and they probably wouldn't use it (especially if it didn't have an IDE, which would take a while by myself). At that point, it wouldn't be worth the effort.

Check out my reply

The API has nothing to do with the grammar of Java. There are tons of reasons why a new language would benefit, the biggest being speedy production time. We can exclude "extends Script", the identifier for the script class (why even use a class at this point; script type anyone?), could make methods easier and quicker to declare, allow automatic abstraction... the list goes on and on. Basically, Java is an overkill for this. We need to work in the flow of Java to achieve our goal, which means understanding reference and primitive types, understanding object creation, having extra (and unneeded) syntax pushed on us, some of which you may not even notice is completely useless (such as the "extend Script" I mentioned earlier; should be implicit). So although the language will support classes (for interoperability reasons), the client will not be forced to learn about such things. A new language could lower the specification one must learn to properly write a script. This has nothing to do with an API; the API is accessable through the language, as this language will be interoperable with Java.

This project is highly dependent on the community's contribution. Without contribution, this language might not get finished. This could be the first step towards the future of writing scripts, and help is needed to make it work. It's up to you guys. After messing with a few grammar designs, I decided not only would it be best to get opinions from dedicated scripters, but allow any developer interested in contributing to this project to help. __________ Why a new language? Java is a divine language, which allows complex structures and ecosystems. But a few problems arise when using a powerful language for scripting: __________ With that said, there are a few ways you can contribute. If you would like to help with the implementation, please post here, and I will message you. __________ Thank you for taking the time to read. For anyone who was waiting on a release from a different project (not including EScript, as I decided not to distribute scripts), let me know so I can clear that up (sorry for any delays).

I did. We found out that1. I forgot to set the retention policy for the annotations. For some reason, AIDE (my mobile IDE) doesn't care for the retention of annotations 2. He was attempting to use the two systems (link and fragment) as one, which I have mentioned does not work with the first release. I created an integrated version, but apparently I forgot to release it. I'll be revamping this entire thread, with a working, cleaner version of these systems that wirk seemlessly together. Sorry for the inconvienence people. Take this as an example of what not to do when releasing snippits :P