fixthissite

It's been a pretty fun ride, hopefully I've made a good impact in some way. I came here to drown myself in memories of RS while still keeping a programmer's mindset. After getting in contact with a scripter who allowed me to review their code, I felt some mentoring would be beneficial. I've tried to help as many scripters as I could (with programming, UX design and marketting), and now I feel the current batch of scripters have definitely raised the standards from what they were, and will hopefully continue raising that standard. My ultimate goal here winded up as helping to fix up the API so scripters have a good example to follow. I have now realized that I couldn't have wasted my time in a more shameful way, and have decided to take on a new RS related project (a private server), which I plan to invest all my free time into. Thank you all so much for the appreciation shown towards my previous contributions. I will continue to mentor in programming. PM me on here and my GMail will notify me. You will have to prove that you want to learn though, or I won't invest the time. Farewell!

He was referring to doing something if closest returned null. Your code focuses more on ensuring the player is at the correct area.I got bashed on another forum for this subject, at a time long before I came across the "billion dollar mistake" thing. I expressed it as an opinion, and it was shunned. It's like the time when people were told the world is round. It's like when Sacrotes got sentenced to death for denying belief in gods. But now, there are tons of topics on it, and tons of reason behind it. It can be debated for ages if you'd like, it's not going to change the fact that null pointers were a mistake (as coined by the creator of em). So it's best to leave it at "null grew on some people, so they prefer it" and allow them to code their style

That's micro-optimization and should be avoided. It is true that you COULD be doing other tasks, but you do not need to force it. Most scripters don't. There are situations where you would want to do nothing on null, and that's what the design is aiming for. Look through scripts, and I'm sure you'll see that most of the null checks are there primarily to avoid the NPE. I've seen scripters perform null checks when it isn't needed for the sake of "better safe than sorry".Sleeping will slow the bot down. If a rock/npc appears while the bot is sleeping, someone else could snatch it. It's still possible to do so aswell. It's helping the situations that don't need to branch if a reference is null

It should be optional. Check out my suggestion thread.With a null object, you can still optionally check the reference. The point is it's common to "do nothing" if there is no object to work with, so you should not force the check. The branching should only occur if you want an else (like your example). NPC npc = ...; if(npc == NPC.NONE) { //move } else { npc.interact(...); } The player might not want to go to a new location. There are times where you're waiting for something to spawn, which you don't want to do anything at that exact moment (such as waiting for a tree to spawn). It's common to "do nothing" if null occurs. You should not force this. There are seriously no downfalls. Null pointers were a mistake. Some languages only support it for compatibility with other languages.

He got the null thing from me I wrote a suggestion thread about returning Null Objects rather than null to prevent all the nasty checks, you should go approve that so all the scripters can like it And there is no proper use of null. Come at me with ANY situation, I'll tell you why it's inconcvienent. It was a flaw, hence why it's called the "billion dollar mistake" - it would cost billions to reverse the damage done (code cludder)

That statement means "if inventory does NOT contain Peach" - notice the "!"

So it seems you should use IDs for items to avoid name collisions with noted items and names for objects incase their IDs change. What about NPCs?

When looking for/interacting with an item/npc/object, is it preferred to use the ID or the name? Are there times when one would be preferred over the other? What's the benifit from using a name rather than an ID and vice versa? I haven't seen this question answered publicly, and I'm sure it'll be helpful seeing how it's a common aspect of scripting

Welcome. What questions do you have?

i don't bot, but i do like purple. gl me

Sorry if I seemed a bit jumpy at first, but I've heard too mamy people recommending this without justifiable reason (basically ever since I got here). You should always give reason as to why you'd wanna to something. To get a better idea of how memory is managed in HotSpot, check out the white paper pdf. You should not blindly increase heap. Increasing heap is usually followed by tuning generations, to ensure that memory you are giving is used efficiently. The only reason you should touch heap is to increase the amount of bots, which at that point should be calculated based on a script's settings and set dynamically. Any other reason (such as storing a bunch of path data in memory) usually calls for a weak data structure.

This is a general Java aspect which can be tested with any Java program, not just OSBot (testing in isolation helps achieve more percise benchmarks anyways).Don't assume everyone has 16 to 32gb of ram. I only have 4gb. My point is, what are you gaining from increasing heap? He is telling people how to do it, and I'm sure many will blindly do this assuming it'll make their clients run "better", when really it's having no real effect (other than consuming more memory than needed). What I'm trying to say is don't touch heap size unless you are required to. Encouraging others to do things without justifiable reason behind it will result in questions about why a script is consuming so much memory (or posts along those lines). He should at least tell people when it would be a good idea to increase the heap size. If memory is being wasted (and there is no reason behind it), I'd most definitely care, and I would hope other devs would care as well.

Not sure what you mean by "we would not meet an OutOfMemoryException". I think you're misunderstanding what I'm saying.The VM doesn't free up memory until it has to. If you give the VM more memory, it will have no need to free-up memory as much (since there's still more memory to use). This means blindly increasing the heap size will result in your application consuming more memory than it actually needs to. This is because you are allowing it to consume more memory. That is what I mean by "as much memory as it wants", whch I guess is better worded as "as much memory as it needs", although you are technically giving it more than it needs. Long story short, yes you can specify a max heap size to allow your program to consume more memory. But this can lead to a waste of memory, since the memory you are allowing it to consume is simply more room for dead objects. You should not increase the heap unless you have to. If you are doing so, I suggest profiling the process to see the effects it's having. This option was made available for applications that have high memory requirements.

Don't. Just don't. Java will consume as much memory as it wants. More memory does not mean faster programs in general, it just means fewer GCs in theory. Only raise memory when you need to (encountering an OutOfMemException), or you feel collections are occuring too frequently (which chances are, you need to manage your object creation better, not your memory). For a better idea: objects will stay in heap until memory is needed. If there is still memory to be used, there is no reason to free up memory by "sweeping" dead objects. This means dead objects sit in heap until the memory they consume is actually needed. Raising the memory will do nothing but make your application a memory hog, unless it's actually needed.

Check out this post before you get dragged into the IntelliJ fanboy club. Just try them both out and choose the one you feel most comfortable with. There's nothing that can prove/disprove this. I personally believe it would be pretty stupid not to flag IPs, especially when compared to some of the other suggested heuristics people believe jagex may be using (things like tracking mouse movement, which would be extremely expensive)