PK Cleaner NPC Problem

[~~Darius~~]

Here Is Error:

http://s6.ifotos.pl/img/Przechwyt_rqrwxsr.JPG

Here Is File:

http://pastebin.com/U6zhf8PU

Pack: H5

Ty For Help.

[vampir]

change line:

if(player.getInventory().getItemByItemId(Config.PK_CLEAN_ID).getCount() < Config.PK_CLEAN_PRICE)

to:

L2ItemInstance item = player.getInventory().getItemByItemId(Config.PK_CLEAN_ID);
if(item != null && item.getCount() < Config.PK_CLEAN_PRICE)

[~~Darius~~]

[PL] teraz  dziala ale choc kiedy mam pk i nie mam itema zeruje mi pk a gdy nie mam pk i klikne zeby wyczyscilo caly czas  mi pisze "Your karma cleaned, continue to play"

i mam tez :

http://s6.ifotos.pl/img/Przechwyt_rqrweep.PNG

 

[en]

when i no have item and have pk  npc clean mine pk

and  when no have pk  and click "clean" i have messesage

"Your karma cleaned, continue to play"

and i have :

http://s6.ifotos.pl/img/Przechwyt_rqrweep.PNG

how to fix it?

 

 

[EdenEternal]

It working perfect on interlude packs.

H5 have very different core from interlude...

I don't know H5 core as good as interlude so I can't give you my opinions. sorry.

[vampir]

[PL] kurwa, zly znak, sorry :D

zmien < na >

[Joκκєrino]

First of all , i really love that

 

/**

* Author: Leki

*/

 

Good job Leki with your share .

Anyway , keeping onpost , all gonna work for sure , i read the whole code and didn't found something wrong . Maybe there should be the problem :

 

 else if(player.getKarma() == 0)
                                player.sendMessage("You don't have any karma, i cannot change it any lower!");
                else // here should be added another if ? Not sure 

As Leki said , " I don't know H5 core as good as interlude ". The best developers for hi5 that i know are from "L2jHidden" project .You should contact them.

 

Good luck in fixing your problem .

[adenaman]

add the {} to the else block

before

                               player.setKarma(0);

{

after

                                player.sendMessage("Your karma cleaned, continue to play!"); 

}

add an else before the super(...) call, we dont need it if it was CleanPK

 

add "final" to

L2ItemInstance item = player.getInventory().getItemByItemId(Config.PK_CLEAN_ID);

this is not an error but will have better performance

[~~Darius~~]

[pl] Vampir i tak choc nie mam itemka a mam pk czysci mi to pk :/ choc zmienilem znak

 

[vampir]

[pl] Vampir i tak choc nie mam itemka a mam pk czysci mi to pk :/ choc zmienilem znak

 

masz caly kod:

http://pastebin.com/8C2A3PgM - teraz bedzie dzialac :)

[~~Darius~~]

[pl]dziala czescioowo :P

to jest error keidy mam karme a nie mam itemka :

http://s6.ifotos.pl/img/Przechwyt_rqrqshn.PNG

 

[vampir]

http://pastebin.com/fAe11P4Z masz, nie mam pojecia czemu zrobilem tak duzo bledow w tak malym kodzie, chyba mialem mozg wylaczony, teraz bedzie spoko :)

[Tryskell]

As wrote vampir, if you haven't the item, it tries to find setCount from a null item, so you will have a NPE in case you haven't the item and try to speak with the PK remover dude. And that will happen on every chronicle, even IL, until you edited method.

 

"final" keyword doesn't impact performance at all, but it's a security for coder. He knows this stuff won't be edited by future edition. You could drop entire final keys from the code with no change. You're right to use "final" when you can, cause it's a good use.

 

A contrario, "static" keyword improves performance, as that method/variable will be shared amongst instances of that class (case of loggers, for example : you use static, only one logger is created for all instances). It means too if you edited (in case of a variable) it, it will affect all instances. So it must be used only when you need it.

 

Just saying.

 

About

super.onBypassFeedback(player, command);

, generally it's with a "else" before. Like that even if that npc hasn't the command, he inherits of others commands "in case of".

 

Finaly, L2PcInstance got a useful check you're using, but you use it bad.

 

					if (!player.destroyItemByItemId("SevenSigns", stoneType, stonesNeeded, this, true))
					return;

 

destroyItemByItemId returns a boolean which mean you can drop the previous check about count. You get ride of one check, and of the NPE in same time and reduces code.

 

---

 

@Override
public void onBypassFeedback(L2PcInstance player, String command)
{
if (command.startsWith("CleanPK"))
{
	if(player.destroyItemByItemId("CleanKarma", Config.PK_CLEAN_ID, Config.PK_CLEAN_PRICE, this, true))
	{
		player.setKarma(0);
		player.sendMessage("Your karma is cleaned.");       
	}
	else
		player.sendMessage("You don't have enough required items.");
}
else 
	super.onBypassFeedback(player, command);
}

[~~Darius~~]

[pl]dobra wszystko  dziala thx Vampir i sorry ze ci zawracalem przyslowiowa dupe :P tylko mi wyskakuje gdy nacisne clean "L2PKCleanerInstance:

Unkown NPC bypass: "cleanPK" npcid: 9999" ale to chyba nic waznego. aa ps moge z 1 sprawa do ciebie na PM ?

[adenaman]

"final" keyword doesn't impact performance at all

they do, since you have a var that can only de intialized once, the VM can use it read-only, and that will increase the performance.

 

[...] declaring a final field helps the optimizer make better optimization decisions, because if the compiler knows the field's value will not change, it can safely cache the value in a register.

http://www.ibm.com/developerworks/java/library/j-jtp1029/index.html

 

The revised memory model proposed by JSR 133 includes special provisions for final fields, provisions that are absent from the existing specification. Newer VMs already implement this specification, and treat final fields accordingly. Because final fields are assigned exactly once, aggressive optimizations in a multithreaded context become possible. Specifically, a field doesn't need to be ever reloaded, since its value is guaranteed never to change.

http://renaud.waldura.com/doc/java/final-keyword.shtml

 

Example of Strings differences (final/ not final). nothing to do with our case, but still a relation between "final" and "performance"

http://www.coderanch.com/t/518466/Performance/java/Compiler-optimization-final-variables

 

 

This is a minimal impove. And there are things that can give a lot more than this (for example direct access and not getters/setters, inside the class) or use C++. But still impact on performance

[Tryskell]

In your own IBM link, you can read

While performance is not a good reason to declare a class or method as final, there are still good reasons to sometimes write final classes.

 

Seems only variables worth to put final. I don't believe you gain something like even 1%, the main point is immutation (or whatever it's named).

[vampir]

I agree, so best thing is to make variables final if they are outside methods, otherwise it's not that important and code isnt readable that well as before.