GM Skill Point Remaining BugFix *AstralMS Based*

[ExtremeDevilz]

I think pretty much those of you who were familar with astralms source was pretty much noticed this bug..
here is a fix which took me sometime to get it working

In GameConstants:

public static boolean isGM(int job) {
        return job == 910 || job == 900 || (job >= 900 && job <= 910);
    }

In MapleCharacter:

Go to changeJob -> Search for it

Find

if (!GameConstants.isBeginnerJob(newJob) && !GameConstants.isDualBladeNoSP(newJob) && !GameConstants.isZero(newJob)  {
                addJobSkills();

Add

&& !GameConstants.isGM(newJob))

I know pretty much even I have contribute a fix I will be flamed for no reason etc, people will be calling it a useless fix.. but after all I know it matters to some... have fun :) maybe I aspire some of you guys to release fixes too..

also this is for AstralMS Based Sources.

[MentaL]

[xStr0nGx]

Allow me to make it shorter.

public static boolean isGM(final int jobid) {
return jobid / 10 == 90 || jobid / 10 == 91;
}

Great release btw,

Definitely worth a like.

[QuietCrystal]

Allow me to make it shorter.

public static boolean isGM(final int jobid) {

        return jobid / 10 == 90 || jobid / 10 == 91;

    }

Or you know,

return jobid / 100 == 9; 

[xStr0nGx]

Or you know,

return jobid / 100 == 9; 

lol I didnt put much thought into this :P

gj!

[AristoCat]

Your isGM is genius though 910 is not gm is supergm so it sucks.

[Dynamik]

(job >= 900 && job <= 910);

That part is redundant, no? Since there is only two GM jobs. GM and SuperGM, which is at 900 and 910. No point of checking between, is there?

[SilentThief]

(job >= 900 && job <= 910);

That part is redundant, no? Since there is only two GM jobs. GM and SuperGM, which is at 900 and 910. No point of checking between, is there?

Agreed, just do

(job == 900 && job == 910);

:P

[xStr0nGx]

Agreed, just do

(job == 900 && job == 910);

:P

No, this is shorter:

return jobid / 100 == 9;

[SilentThief]

No, this is shorter:

Either way is fine, no matter how short the code is.

[xStr0nGx]

Either way is fine, no matter how short the code is.

Shorter equals proer.

[Fraysa]

I suggest you actually describe the issue you are fixing, because honestly I didn't get what it does/fix.

[SuperLol]

Agreed, just do

(job == 900 && job == 910);

:P

That doesn't work.
edit: Try or instead of and

Shorter equals proer.

Hardly, especially in algorithms. Many of the shortest algorithms for a certain problem is O(N^2) -- let's say traverse through 2 data lists or something idk, which is definitely not that pro. The longer implementations take advantage of certain data structures and reduce the runtime complexity. It does work faster in this case though, at least for the job / 100 == 9 (unless the implementation of division really, really sucks). return jobid / 10 == 90 || jobid / 10 == 91; should run slower than return jobid == 900 || jobid == 910 though.

[SilentThief]

That doesn't work.
edit: Try or instead of and



Hardly, especially in algorithms. Many of the shortest algorithms for a certain problem is O(N^2) -- let's say traverse through 2 data lists or something idk, which is definitely not that pro. The longer implementations take advantage of certain data structures and reduce the runtime complexity. It does work faster in this case though, at least for the job / 100 == 9 (unless the implementation of division really, really sucks). return jobid / 10 == 90 || jobid / 10 == 91; should run slower than return jobid == 900 || jobid == 910 though.

My bad, got the two mixed up. :P