Jump to content

Discuss: item combo scripts in separate database

Kenpachi

By Kenpachi
in Implemented

 Share

Recommended Posts

Kenpachi Poring

Kenpachi

Posted
Posted

Hi.

Referring to bugreport:309 I want to ask for your opinion.

I think it's more clean to have those scripts separated simply because you don't have to search the item that holds the combo script.

My idea would be something like this: (TXT format)

itemID1:itemID2:itemID3,{ bonus bStr,1; }
itemID1:itemID2,{ bonus bDex,2; }

BTW; I'm aware of the fact that this wont solve the issue but I think it could be done in the same task.

Ind Poring

Ind

Posted
Posted

i think that would solve the issue actually o-o that way we could process solely combos after all item processing was made -- then stacking combos would be made possible

Kenpachi Poring

Kenpachi

Posted
  • Author
Posted

i think that would solve the issue actually o-o that way we could process solely combos after all item processing was made -- then stacking combos would be made possible

Okay. That's nice... one more argument for doing this. :)
Kenpachi Poring

Kenpachi

Posted
  • Author
Posted

No labels. oO

It's like in AEGIS. Normal bonuses are stores in one file (item_db) and combo bonuses are stored in a separate file (not existing yet).

Take a look at our leaks and check the end of special.sc plus comboItem.sc; this will explain everything. :)

//EDIT:

Oh, I think I misunderstood you.

I didn't think about combos in OnEquipScript and OnUnequipScript but actually there is no reason to have combo scripts in those fields.

Ind Poring

Ind

Posted
Posted

Sure. If one of the combo items is unequipped the combo script runs out.

If you write the file (with the combos in it) with your pattern and send me I'll write the code to read it.

  • Upvote 1
  • 4 weeks later...
JayPee Poring

JayPee

Posted
Posted

Hi.

Referring to bugreport:309 I want to ask for your opinion.

I think it's more clean to have those scripts separated simply because you don't have to search the item that holds the combo script.

My idea would be something like this: (TXT format)

itemID1:itemID2:itemID3,{ bonus bStr,1; }
itemID1:itemID2,{ bonus bDex,2; }

BTW; I'm aware of the fact that this wont solve the issue but I think it could be done in the same task.

Im not good at source but is this possible like in the groups.conf

item: {
 itemC1:  { bonus bAgi,1; },
 itemC2:  { bonus bStr,1; },
}

Kenpachi Poring

Kenpachi

Posted
  • Author
Posted

Hi.

Referring to bugreport:309 I want to ask for your opinion.

I think it's more clean to have those scripts separated simply because you don't have to search the item that holds the combo script.

My idea would be something like this: (TXT format)

itemID1:itemID2:itemID3,{ bonus bStr,1; }
itemID1:itemID2,{ bonus bDex,2; }

BTW; I'm aware of the fact that this wont solve the issue but I think it could be done in the same task.

Im not good at source but is this possible like in the groups.conf

item: {
 itemC1:  { bonus bAgi,1; },
 itemC2:  { bonus bStr,1; },
}

You should explain your sample... I don't understand it. And well, everything is possible.

JayPee Poring

JayPee

Posted
Posted

For example: I have a footgear which has an ItemID of 1504 and I want to have an item combo it to ItemID 1505(Armor) and 1506(Headgear). I think this kind of format is easy to read.

1504:{
     1505: {
                bonus bStr,1;
                bonus bAgi,1
               /** Item Bonus Script **/
      }
     1506: {
                bonus bDex,1;
                bonus bVit,1
      }
}

Hope you understand my english

Kenpachi Poring

Kenpachi

Posted
  • Author
Posted

Yes, I understand now. :)

And well, I thought about that problem (one item in multiple combos), too.

I like your idea but not the syntax you used. I'll talk to Ind (and probably WIlcard because he's really good in finding solutions for problems like that) about a nice layout.

(I think we should get this done over the weekend...)

Ind Poring

Ind

Posted
Posted

as i was about to wrap up the code of this i stepped by this comment in script.c

* Check whether another card has been
* equipped - used for 2/15's cards patch [celest]
* -- Items checked cannot be reused in another
* card set to prevent exploits

since i has no idea what kind of exploit it can create i'm liek wtf and stagnated the development on this feature, do any of you know what this could be related to?

Kenpachi Poring

Kenpachi

Posted
  • Author
Posted

That comment is pointless.

There is no reason to prevent an item from being used in more than one combo.

See the original discussion of the bug: http://www.eathena.w...ker&showbug=309

Aegis has a special notation for item combos. It's name { item1 item2 item3 }, you get the idea. Combos are defined separately, and apparently execute separately. We tested the alch+merch combo a month before, and confirmed that on aegis, both combos kick in even though they share half of the cards.
Ind Poring

Ind

Posted
Posted

so you think skotlex would code a whole item hash system out of no reason? i disagree, there should be something or at least there was a good reason for that. i don't think moving forward with this without finding out first is wise

Ind Poring

Ind

Posted
Posted

Skotlex replied

Meh, sorry for the delay, I haven't checked this site in a while. Anyway, I reviewed the code and found a flaw on it. Try the fixes suggested at the bug-report you mentioned, that should take care of it.

I realized I forgot to quote his post in the bug tracker O_O

http://rathena.org/board/tracker/issue-309-holden-card-combo/

isequipped keeps a hash to know which cards are already used by a previous "isequipped" check. It is in place to avoid issues such as using the same card multiple times for a combo.

Example: Crab Card + Aster + Shell Fish card combo is scripted in the Crab card. Without the hash, you'd be able to trigger the bonus multiple times if you have one Aster card, one Shell Fish card, and multiple Crab cards.

However, the code itself SHOULD work if you have multiple cards. The hash value is different for each card in each slot position.Notice how the hash value is "1<<((equip position)*4 + (slot number)). If this is failing, it might be that the hash variables are not large enough to hold the shifted number. Though the max value to hash is 1<<(4*4+3), 1<<19.... oops. An "int" normally is just 4 bytes long (16 bits). This might explain why it isn't always working?I guess the solution here to use four hash variables instead of two.

So change setitem_hash1/2 to "setitem_hash1/2/3/4" and make them unsigned long (long is better than int for this case).

Set the hash according to the equip index (script function isequipped):

hash = 4*(equip_idx%3) + slot_idx;

unsigned long *sd_hash;

switch (equip_idx/3) {

case 0: sd_hash = &sd->setitem_hash1; break; //EQI_ACC_L, EQI_ACC_R, EQI_SHOES

case 1: sd_hash = &sd->setitem_hash2; break; //EQI_GARMENT, EQI_HEAD_LOW, EQI_HEAD_MID

case 2: sd_hash = &sd->setitem_hash3; break; //EQI_HEAD_TOP, EQI_ARMOR, EQI_HAND_L

case 3: sd_hash = &sd->setitem_hash4; break; //EQI_HAND_R, EQI_COSTUME_TOP, EQI_COSTUME_MID

default: continue; //Unsupported gear piece, cannot hash it.

}

if ((*sd_hash)&hash) continue; //Card already used

//We have found a match

flag = 1;

(*sd_hash) |= hash;

...And with this change, you should properly support up to four slots on equipment pieces with index from 0 to 11 (I don't think EQI_COSTUME pieces have any cards, otherwise if you want to support EQI_COSTUME_LOW you need a fifth hash variable :/)

Damn, this is a lot of variables. I think it could be optimized by setting a temporary structure on status calc pc to hold all hashes, and free that at the end.... oh well, that's a talk for another day.

Sorry, but I can't run rA servers on my machine right now,so I can't test my fix. But it should point you guys on the right direction.

  • Upvote 1
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...