sellable/unsellable flag

[GoogleCodeExporter]

http://forums.openkore.com/viewtopic.php?f=36&t=18076#p238617
Store item sellable/unsellable flag inside an auto-generated text file to 
preserve this data while changing maps.

Original issue reported on code.google.com by marcelof...@gmail.com on 11 Mar 2014 at 4:36

[GoogleCodeExporter]

I don't understand.

Whenever you're selling something won't kore receive "npc_sell_list" (thus 
filling the sellable/unsellable attributes of the items)?

Original comment by jefferso...@gmail.com on 27 Mar 2014 at 3:18

[GoogleCodeExporter]

Yes. But when checking if we need or not to trigger autosell, it's desirable to 
check if items are sellable or not. Currently, we store the sellable/unsellable 
flag in the character's inventory object. The problem is, the inventory is 
cleared and then recreated during map changes, losing those flags.

There's a simple way to do it: create a new .txt file inside tables folder and 
parse its contents to a new hash (%items_sell_LUT for example). But I really 
think we should abstract thing (items name, items descriptions) into a 
"database module class".

Think about it like this:

Item slots:
Current: $itemSlotCount_lut{itemID}
After: $itemDB->getSlots(itemID)

Item name:
Current: $items_lut{itemID}
After: $itemDB->getName(itemID)

In this DB object we can use whatever kind of database we like, be it .txt like 
we have currently or SQLite, MYSQL... Other modules won't have to know if we 
are using .txt of SQL, we move this task to DB::Item.

Original comment by marcelof...@gmail.com on 27 Mar 2014 at 5:04

• Added labels: Maintainability, Type-Enhancement, Usability
• Removed labels: Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

There's still a problem with this approach though, you won't have a clue about 
what you can and what you can't sell (based on this file) until autosell 
triggers for the first time. Considering you'll generate it on the run.

Still, you could store all the unsellable item's IDs of RO on 
tables/unsellable.txt, and check it on "ai_sellAutoCheck", something like:

[...]
foreach my $item (@{$char->inventory->getItems()}) {
next if (isUnsellable($item->{nameID}));
[...]

Where "isUnsellable" could check for the item's ID on tables/unsellable.txt

Original comment by jefferso...@gmail.com on 27 Mar 2014 at 7:15

[GoogleCodeExporter]

We could load in right on startup. It's better to auto-generate it on runtime 
because those flags can change between servers. So, kore would trigger autosell 
with unsellable.txt empty, get the sellable/unsellable info from the NPC and 
then save it. Just like it's done with monsters.txt.

Original comment by marcelof...@gmail.com on 27 Mar 2014 at 7:18

[GoogleCodeExporter]

Well, it doesn't seem that hard to implement the file idea. (I'm attaching a 
patch... not sure if that really works 100% though, lol)

But how would you go about the DB module? The global variables do seem a little 
messy to work with, and such module could take a lot of things out of 
Globals.pm (considering subclasses like DB::Item, DB::Monster, DB::Skill, etc). 
But, it would be necessary to rewrite a lot of code. For example, everything 
that relies on %items_lut or %itemSlotCount_lut would have to be replaced by 
$itemDB.(or am I missing something?)

Original comment by jefferso...@gmail.com on 28 Mar 2014 at 1:00

Attachments:

• unsellable.patch

[GoogleCodeExporter]

I messed it up, that was inverted. Correct patch.

Original comment by jefferso...@gmail.com on 28 Mar 2014 at 1:14

Attachments:

• unsellable.patch

[GoogleCodeExporter]

It's implemented since r49. I'll flag this as fixed for now.

Original comment by marcelof...@gmail.com on 5 May 2014 at 11:37

• Changed state: Fixed