Ind Posted July 12, 2012 Posted July 12, 2012 this is a problem present since eAthena, bugreport:309 details it. the item hash or "tagging" prevents exploits like card a combos with card b and gives 3 str when combod w/o that hash code if you wear 2 of card a and 1 card b you get +6 str instead of 3 thanks to kenpachi's item_combo_db we can now store all combos away from the items preventing the above scenario from taking place w/o the hash stuff, e.g. looping through the combo db once and checking for matching pairs, however that is quite inefficient (you see, we have about to 200 pairs of combos and 14 equipment slots, the loop would be awful), we need a clever way to fix this bug (preferably away from that awfully huge loop). discuss / post your opinions / scream at me, whatever you like :3
Trojal Posted July 12, 2012 Posted July 12, 2012 What about a data structure with a link from every item_id in a combo to the combo struct information, then check for the presence of that combo? combo_db: ... 14: 4001, 4002, 4003, 4004. ... find equipment at slot 3: 4003. Look at combo 14. Look for equipment 4001, 4002, 4003, 4004. If found, enable combo 14. Also, this algorithm can be improved, but as a basis it's much faster than looping over all of them. 1
Kenpachi Posted July 12, 2012 Posted July 12, 2012 Basically a combo ID like in AEGIS... Yes, I like the idea. 2
Ind Posted July 27, 2012 Author Posted July 27, 2012 there is no need for a id entry in the combo db -- since the id value is not used in any other files the reference is not required, we can assign ids for them as they are parsed. Applied the update here: r16508
xazax Posted July 27, 2012 Posted July 27, 2012 Great, darling! I had some spare minutes today in work, and implemented SQL export into my database editor, and I noticed a few diffs from item_db.The most important one, combo codes weren't removed from item_db.sql files, so maybe they are applied twice on some servers, using SQL item dbs.
Kenpachi Posted July 27, 2012 Posted July 27, 2012 Thanks xazax. I'll convert the TXT DBs later today.
Kenpachi Posted July 27, 2012 Posted July 27, 2012 Done in r16513. http://rathena.org/board/tracker/issue-6349-sql-file-syntax-error
Kenpachi Posted July 28, 2012 Posted July 28, 2012 Exactly as in the TXT version. The only difference to item_db.sql is that it's stored in a VARCHAR field instead of INT. Finally done in r16523 and r16524.
xazax Posted July 28, 2012 Posted July 28, 2012 the "-s in itemscripts are not escaped. Is this intentional?
Kenpachi Posted July 28, 2012 Posted July 28, 2012 Actually it's not required excepting they are included in double quotes themself.
Recommended Posts