Experience distance (OSB2)

[Botre]

Well using it correctly, and I mean by not calling every time onLoop or onPaint, it will literally amount to a minuscule difference in usage.

 

So I don't see the point in looking like a idiot who recorded all the level XP, and stored them in a int[], when you can use less code, and achieve the same job, but dynamically, and not by hard coding which is a common bad practice.

 

But don't listen to me, I don't know anything.

 

I didn't have to record it manually.

All I had to do is use use a snippet similar to yours to automatically generate that array, a 30 seconds job.

You don't need dynamic code considering the experience caps are static.

Some people like small refresh rates so their data is constantly updated.

Bad practice, fair enough, but in this case it's actually the best solution.

[NotoriousPP]

I didn't have to record it manually.

All I had to do is use use a snippet similar to yours to automatically generate that array, a 30 seconds job.

You don't need dynamic code considering the experience caps are static.

Some people like small refresh rates so their data is constantly updated.

Bad practice, fair enough, but in this case it's actually the best solution.

 

Once again, it's still not the best solution, like @Swizzbeat said right after me:

Well, the whole idea behind OOP is that your code should be designed to be reusable and extended upon, hence the whole concept of polymorphism. If Jagex suddenly updated the skill cap to be 120 then your code would be broken and need the correct level indexes added to that array. In the case of a massive business application, a minor change like that could mean weeks of bug fixing and updating.

[Botre]

Well, the whole idea behind OOP is that your code should be designed to be reusable and extended upon, hence the whole concept of polymorphism. If Jagex suddenly updated the skill cap to be 120 then your code would be broken and need the correct level indexes added to that array. In the case of a massive business application, a minor change like that could mean weeks of bug fixing and updating.

 

This isn't a massive business application.

I'll extend the table to level 9999999.

That way I won't ever have to worry about updates + have the best method performance-wise at the same time.

Edited June 14, 2014 by Botrepreneur

[Swizzbeat]

This isn't a massive business application.

I could add any addition skill level in less than 10 seconds because I have a way to automate it.

You're correct, it's not, however you should always strive to be using best practices no matter whether you're building a piece of computer software or printing out every prime number between 1 and 100. If you start now you won't have trouble adhering to proper concepts later on.

 

None of us are attacking you mate, we're just giving you advice that we think you would find beneficial

Edited June 14, 2014 by Swizzbeat

[NotoriousPP]

You're correct, it's not, however you should always strive to be using best practices no matter whether you're building a piece of computer software or printing out every prime number between 1 and 100.

 

If you start now you won't have trouble adhering to proper concepts later on.

 

I just don't understand why were arguing over a few bytes of difference here.... 

 

Because OP has it set in his head that that is the best way, it must be the best way.

[Swizzbeat]

I just don't understand why were arguing over a few bytes of difference here.... 

 

Because OP has it set in his head that that is the best way, it must be the best way.

In my opinion I think that's one of the most beautiful things about programming. There's always multiple ways to do something and finding a different way to accomplish the same task has both benefits and disadvantages.

[Botre]

You're correct, it's not, however you should always strive to be using best practices no matter whether you're building a piece of computer software or printing out every prime number between 1 and 100.

 

If you start now you won't have trouble adhering to proper concepts later on.

 

I chose the best solution to a specific problem, how's that bad practice?

Deliberately ignoring conventions or standard practices can be rewarding (I ended up with a better end result, can't deny that).

 

You're all convention slaves

Clarification: Better in terms of performance in this specific situation: small refresh cycles (constant data updates) + in a scenario where jagex doesn't update the skill caps (I extended the levels to 200 in my local snippet just to make sure, though we all know that extension was quite unnecessary).

Edited June 14, 2014 by Botrepreneur

[NotoriousPP]

I chose the best solution to a specific problem, how's that bad practice?

Deliberately ignoring conventions or standard practices can be rewarding (I ended up with a better end result, can't deny that).

 

You're all convention slaves

Clarification: Better in terms of performance in this specific situation: small refresh cycles (constant data updates) + in a scenario where jagex doesn't update the skill caps (I extended the levels to 200 in my local snippet just to make sure).

 

Well considering were playing RuneScape, and I can run my method in a onLoop for a 8 hour run without it crashing or seeing a noticeable difference, just kinda of shows how unneeded using a static arrays is.

[Dog_]

Well using it correctly, and I mean by not calling every time onLoop or onPaint, it will literally amount to a minuscule difference in usage.

 

So I don't see the point in looking like a idiot who recorded all the level XP, and stored them in a int[], when you can use less code, and achieve the same job, but dynamically, and not by hard coding which is a common bad practice.

 

But don't listen to me, I don't know anything.

That experience table has been floating around the interwebz for years, he could've just copy-pasted it which would take less time.

 

[Botre]

Well considering were playing RuneScape, and I can run my method in a onLoop for a 8 hour run without it crashing or seeing a noticeable difference, just kinda of shows how unneeded using a static arrays is.

 

I like to account for weaker systems and people running multiple instances at the same time.

Anyways, both methods have their merits, I won't deny that

 

Yours respects conventions, mine doesn't, this was a deliberate choice but thanks for pointing it out anyways Now... let's all have java make-up sex.

Edited June 14, 2014 by Botrepreneur

[Ziy]

You both have valid approaches to the problem but why not try to achieve the pros of both implementations in one?

 

Performance is key, right?

 

I would go for the lookup table approach similar Botrepreneur, why?

• It is way faster as all values a precomputed, here are some test results (100,000 function calls timed in nanoseconds)
  
  Test 1 (Botrepreneur 100,000 random 1-99 values) : 11839527
  Test 2 (NotoriousPP 100,000 random 1-99 values): 467340188
  Test 3 (Botrepreneur 100,000 calls just for value 99): 224877
  Test 2 (NotoriousPP 100,000 calls just for value 99): 918205715

But it might be a good idea to keep extensibility by precomputing the values in the lookup table using NotoriousPP's method rather than hardcoding the values

 

Therefore we will have both extensibility and performance (using both your arguments)!

 

[Botre]

Updated

[Joseph]

What you updated?

[Botre]

What you updated?

 

On top of some renaming and clearer formatting, getDistanceBetweenLevels will now calculate the difference between both level arguments even if the second argument is smaller than the first one.

 

That's it I think, nothing too special ^^