11 réponses à ce sujet

[kalbaern]

I need to dertime the base AC of worn amor. I assume I could reference the "parts_chest.2da", but I'm not sure how. Any help would be greatly appreciated.

[MrZork]

Something like the following will do, unless you have changed the 2DA with the item prices (in which case something similar would still do).

// MrZork 2014/02/17: From the NWN Lexicon GetItemACValue article.
// Returns the base armor type as a number, of oItem
// -1 if invalid, or not armor, or just plain not found.
// 0 to 8 as the value of AC got from the armor - 0 for none, 8 for Full plate.
int GetArmorType(object oItem)
    {
    // Make sure the item is valid and is an armor.
    if (!GetIsObjectValid(oItem))
        return -1;
    if (GetBaseItemType(oItem) != BASE_ITEM_ARMOR)
        return -1;

    // Get the identified flag for safe keeping.
    int bIdentified = GetIdentified(oItem);
    SetIdentified(oItem,FALSE);

    int nType = -1;
    switch (GetGoldPieceValue(oItem))
        {
        case    1: nType = 0; break; // None
        case    5: nType = 1; break; // Padded
        case   10: nType = 2; break; // Leather
        case   15: nType = 3; break; // Studded Leather / Hide
        case  100: nType = 4; break; // Chain Shirt / Scale Mail
        case  150: nType = 5; break; // Chainmail / Breastplate
        case  200: nType = 6; break; // Splint Mail / Banded Mail
        case  600: nType = 7; break; // Half-Plate
        case 1500: nType = 8; break; // Full Plate
        }
    // Restore the identified flag, and return armor type.
    SetIdentified(oItem,bIdentified);
    return nType;
    }

[kalbaern]

I've used that one in the past. The problem is that on rare ocassions (lag spikes) it causes your armor to suddenly unequip when the check is made due to the identified flag being toggled FALSE then BACK TRUE. I am looking to return a simple value equal to the base AC though like that one does.

[MrZork]

Maybe use CopyItem() (or similar) to dup the armor in question, then call the above, then dump the copy?

[Lightfoot8]

The armor's base AC is the

ACBONUS from parts_chest.2da, using the part number of the chest as the index into parts_chest.2da.

 

EDIT:  try this.  UNTESTED

 

int GetBaseAC(object oItem)
{
  return
  StringToInt
  (
    Get2DAString
    (
      "parts_chest",
      "ACBONUS",
      GetItemAppearance(oItem,ITEM_APPR_TYPE_ARMOR_MODEL,ITEM_APPR_ARMOR_MODEL_TORSO)
    )
  );
}

[kalbaern]

Thanks -LF- .. I'll give her a spin tomorrow.

[kalbaern]

 

The armor's base AC is the

ACBONUS from parts_chest.2da, using the part number of the chest as the index into parts_chest.2da.

 

EDIT:  try this.  UNTESTED

 

int GetBaseAC(object oItem)
{
  return
  StringToInt
  (
    Get2DAString
    (
      "parts_chest",
      "ACBONUS",
      GetItemAppearance(oItem,ITEM_APPR_TYPE_ARMOR_MODEL,ITEM_APPR_ARMOR_MODEL_TORSO)
    )
  );
}

 

Thanks Lightfoot8, it works like a charm.

[MrZork]

I like Lightfoot8's approach and am planning to change a couple scripts to use it instead of the one I posted. But, I thought I read at some point that one must be careful with 2DA lookups because they can be slow and may cause lags if used in loops. I might have misread that and it might never have been true in the first place. (I.e. it may turn out that the game reads all the 2DAs on module load and caches them anyway, so the lookup could be very fast as long as the 2DA itself wasn't huge.)

 

Does anyone know if it's generally safe, lag-wise, to use 2DA lookups? Are there any special considerations a scripter should keep in mind in terms of performance when using them?

[Lightfoot8]

1.69 changed the way that 2da are cached.  you can now set the max number of 2da's to be cached in nwplayer.ini.   

 

before the 1.69 update it was preset at only two or three 2da's being cached at a time.   I remember seeing a post on the original boards from one of the developers (Pre1.69) saying that a problem occurred when looping through  3 or more 2da's,  if the loop was not designed to loop through one at a time.    But that is now obsolete news, since 1.69.  

 

 

EDIT:  also Keep in mind that your scripts are not the only thing using 2da's.   suggestions like just create a new item of the same base type and read it,  are in fact still loading the 2da to along with the bluepring to create the item.     

[MrZork]

Thanks. Good to know caching is more effective now. So, is the 10 2DAs cached as set in the standard INI about right, then?

[Shadooow]

I like Lightfoot8's approach and am planning to change a couple scripts to use it instead of the one I posted. But, I thought I read at some point that one must be careful with 2DA lookups because they can be slow and may cause lags if used in loops. I might have misread that and it might never have been true in the first place. (I.e. it may turn out that the game reads all the 2DAs on module load and caches them anyway, so the lookup could be very fast as long as the 2DA itself wasn't huge.)

 

Does anyone know if it's generally safe, lag-wise, to use 2DA lookups? Are there any special considerations a scripter should keep in mind in terms of performance when using them?

also read here

[WhiZard]

also read here

 

From what I remember, BioWare kill XP lookups constituted the following:

 

1) Looping through exptable.2da to determine the PCs effective level.

2) Looking into classes.2da to determine EffCRLevel (abandoned with the HotU release and removed from SoU but not OC).

3) Looking into racialtypes.2da to determine multi-class penalty

4) Looking at xptable.2da to find the experience point value

 

There has also been discussion by the developers concerning xpbaseconst.2da, but I think that was more oriented at encounter spawns than kill XP.