Help Question About Item Categorisation.

[Meydex]

Greetings people,
I've got a question that I'd really like to answer by myself but I've only got basic java knowledge.
Recently, I decided to categorise some custom made items. Here's an example of the method I chose to do it:
 

//This code was written inside L2ItemInstance class
public boolean isCustomItem()
{
  switch(getId())
  {
  case 1311: //random item
  case 2244: //random item
  case 3554: //random item
     return true;
  }
  return false;
}

This works completely fine but it seems pretty sloppy.

Now, I understand that there is another way of doing it through L2Item instead of L2ItemInstance class by creating booleans, updating StatsSet and working on xmls by adding the custom boolean to the respective items.
However, I really can't tell whats the difference in terms of coding efficiency and reliability (if there is any).
Has any of you fellows got this sorted out?
Which way would you choose? Maybe another way not mentioned here?
Thanks! 

[vampir]

If you want to add new custom item, normally you just need to add it to xml(or if you make something advenced you need to make new item handler or skill handler), by adding this code to java class you need to add new "case" and recompile each time you add new item.

If you want to change ID of your custom item, it is very easy to forget that you added some code to java with hardcoded id, this can cause unexpected problems

[Meydex]

If you want to add new custom item, normally you just need to add it to xml(or if you make something advenced you need to make new item handler or skill handler), by adding this code to java class you need to add new "case" and recompile each time you add new item.

If you want to change ID of your custom item, it is very easy to forget that you added some code to java with hardcoded id, this can cause unexpected problems

Well assuming that I've got no problems managing the ids of the new entries on core side, is there any other difference like for example: more allocated memory usage if I don't parse the boolean and go the "hardcode" way, or anything else that I am missing?

[Tryskell]

Hardcoded is probably faster, as you don't use temporary variables or stock anything, but as you said it can become really fast sloppy as it scales really bad (good luck if you got 150 spread ids) and if every data was processed that way I guess it would be a mess.

 

So up to you, if you got few ids you don't have to add a new boolean and feed it via StatsSet, but if you have to edit a lot or want simply to keep it clean (and avoid to roam on your sources to find back what you added and edit values), second case is better.

 

Finally, a simple //reload items is enough with the second case, while the first example needs a server restart.

 

All the data, being HTMs or static SQL/XML, could be hardcoded on sources (and would get better performance as you can forget any parser), but that would be a pain in the ass to edit things and doesn't allow any reload.

Edited January 13, 2017 by Tryskell

[Meydex]

Hardcoded is probably faster, as you don't use temporary variables or stock anything, but as you said it can become really fast sloppy as it scales really bad (good luck if you got 150 spread ids) and if every data was processed that way I guess it would be a mess.

 

So up to you, if you got few ids you don't have to add a new boolean and feed it via StatsSet, but if you have to edit a lot or want simply to keep it clean (and avoid to roam on your sources to find back what you added and edit values), second case is better.

 

Finally, a simple //reload items is enough with the second case, while the first example needs a server restart.

 

All the data, being HTMs or static SQL/XML, could be hardcoded on sources (and would get better performance as you can forget any parser), but that would be a pain in the ass to edit things and doesn't allow any reload.

Oh I see, so technically speaking the first way is better in terms of performance but less efficient. Since I've got very few ids I think I am gonna stick with the first one .

Thanks for your replies guys :)

You may lock it.

[vampir]

Maybe it doesnt apply in your case, but you should also think of other developers that work on the project. Having such option in XMLs looks are lot more obvious and consistent with rest of pack.

 

Though yeah, you can stick to the first one. It should be fine :)

Edited January 13, 2017 by vampir

[Meydex]

Maybe it doesnt apply in your case, but you should also think of other developers that work on the project. Having such option in XMLs looks are lot more obvious and consistent with rest of pack.

 

Though yeah, you can stick to the first one. It should be fine :)

Yeah I thought about that parameter too but I am running the project on my own so it is ok :)

[SweeTs]

Locked then :)