81 réponses à ce sujet

[kevL]

sweet,

[CPK87]

Having a weird issue with a certain 2da file..

I've altered iprp_spells.2da and put the modified version in my override folder, just like I do with the other altered 2da files. However, it seems to be prioritizing the one in the original 2DA_X2 zip file over the one in override. To test, I extracted the original iprp_spells.2da out of the zip file to a different location, and after doing so, it used my file in override. However, that won't pass on other players' machines, not to mention the zip file re-creates any missing files upon launching the game, so it'll just replace my file again. Why would it not use the override folder for this particular file?


Edit:  Upon further testing, it seems the spell itself actually does get updated, but the name of the bonus spell's prop on the item remains the same as what was originally in the 2da file.  For example,  if you change a level 5 flame arrow to a level 1 fireball, when you cast the spell, it will use the level 1 fireball, but if you examine the item, it will say 3 casts per day of a level 5 fire arrow.  So while not entirely broken, this can still end up being very confusing for players, and I'm not sure why it wouldn't update the name.

Modifié par CPK87, 18 février 2014 - 03:02 .

[kevL]

in Iprp_spells,

didja change the "Name" column ( not just the "Label", which is only for human readability ) to reference a new Dialog.Tlk entry?

If you want the itemprop to read "Fireball (1)" or something you may have to go with a Custom.Tlk,

[CPK87]

Yeah, the name column is just a number so I'm not sure what to change it to. Would you happen to know where those numbers are defined? Otherwise, I'll look into doing a custom .tlk.

[kevL]

They're entries in Dialog.Tlk

viewable with TlkEdit2, and maybe the toolset has an internal viewer...

For example, it seems like - in Dialog.Tlk - most of those ip spell-descriptions are defined by entries #1097 to #1387. 5th level Flame Arrow with Name #1214 -> "Flame Arrow (5)" in the .Tlk. But it looks like Fireball only has levels 5 & 10 supported in Dialog.


the best way to add custom descriptions would be google "custom.tlk" - there are already some good threads on it here at BSN. ( i think the Custom will support this usage but never tried it - note that this type of thing might be supported IG but not in the toolset )

oh, you know what you can try : simply replace the Name # by a string in quotes, eg "Fireball (1)" in Iprp_spells.2da

could get lucky.

[CPK87]

kevL wrote...

They're entries in Dialog.Tlk

viewable with TlkEdit2, and maybe the toolset has an internal viewer...

For example, it seems like - in Dialog.Tlk - most of those ip spell-descriptions are defined by entries #1097 to #1387. 5th level Flame Arrow with Name #1214 -> "Flame Arrow (5)" in the .Tlk. But it looks like Fireball only has levels 5 & 10 supported in Dialog.


the best way to add custom descriptions would be google "custom.tlk" - there are already some good threads on it here at BSN. ( i think the Custom will support this usage but never tried it - note that this type of thing might be supported IG but not in the toolset )

oh, you know what you can try : simply replace the Name # by a string in quotes, eg "Fireball (1)" in Iprp_spells.2da

could get lucky.

Unfortunately no, putting it in directly as a string doesn't work.  I'll look into .tlk later.

Modifié par CPK87, 18 février 2014 - 07:57 .

[Lance Botelle]

Hi CPK87,

Sorry about getting back to you late ... I lost track of where I was posting! It seems you are getting further help though (from others), which is good.

Some of the questions are a little difficult to answer (not because they are hard to do necessarily), but because I have all the crafting systems (from all renditions of NWN2) running through my head at once when I consider crafting stuff nowadays.

For instance, I have combined functions from "kinc_crafting" and "ginc_crafting" to form one new include script to cover all the crafting systems. Then the different systems are activated different methods, either by recipes (new system) or workbenches (old system). On top of that I have amalgamated some aspects to make them compatible with each other! It all makes sense when you see it working, but it is hard for me to recall which parts were from one system and which parts were from another.

However, I believe the bottom line is .. for what you were asking about restricting certain enchantments to certain weapons, lies as much in adding a new "restriction function" to the appropriate include script, as opposed to altering any 2da's specifically. (Although see bold text next.)

For example, kinc_crafting (which I believe is the newer crafting system include, which uses recipes if I recall correctly), has a function in it called CheckCanEnchant. This function calls the various "checks" to see if a PC meets the conditions to perform the enchantment on said item. (E.g. Check if the PC has enough gold using CheckGoldCost function.) Now, my point is, you can add your own "check" function to this CheckCanEnchant function ... or even add the check prior to this function being called (which means you would not even have to touch the include script) as it is called from the module's OnActivate script.

So, if you have a recipe that fires, simply give it a unique tag, that you can refer to prior to the CheckCanEnchant fires in the module's OnActivate, and make sure the target meets your requirements even before the rest of the script fires! The same argument can be made for the old system when casting a spell at the workbench.

This is actually a lot simpler that you may think from how I understand your question.

Hope that gives you some guidance.
Lance.

EXAMPLE SCRIPT (USING A SECTION FROM MY OWN ON ACTIVATE SCRIPT)
THIS WONT COMPILE AND IS JUST TO SHOW YOU WHERE YOU CAN ADD YOUR CHECK

 if(GetBaseItemType(oItem) == 146) //Incantations are itemtype 146    
  {   
  object oItemToEnchant = GetItemActivatedTarget();  
  
  if(GetObjectType(oItemToEnchant) == OBJECT_TYPE_ITEM)   
  {
   string sTag = GetTag(oItem);   
   
   // REJECT UNIDENTIFIED TARGET ITEMS  
   if(GetIdentified(oItemToEnchant) == FALSE)
   {DelayCommand(0.1, SetNoticeText(oPC, "YOU CANNOT WORK WITH UNIDENTFIED ITEMS")); return;}
   
   // RECORD ENCHANTMENT RECIPE TYPE USED (ARMOUR OR WEAPON)
   string sType = GetSubString(sTag, 4, 1); // E.g. nx2_a_ench_01 = "a"
   SetLocalString(oItemToEnchant, "RECIPETYPE", sType);
   
   // PREVENT CRAFTING SYSTEM GIVING EXTRA ITEMS
   SetLocalInt(oPC, "STOPSCRIPT", 1);
   DelayCommand(0.1, DeleteLocalInt(oPC, "STOPSCRIPT"));     
  
   // GET THE ROW NUMBER FOR THIS ENCHANTMENT RECIPE (E.g. nx2_w_ench_01 returns 1)
   int nIncantIndex = Search2DA(NX2_ENCHANTING_2DA, "INCANTATION_TAG", sTag, 1);
   
   /////////////////////////////////////////////////////////////////
   // INTERCEPT YOUR RECIPE HERE & MAKE CHECK AGAINST THE TARGET TAG
   /////////////////////////////////////////////////////////////////
   
   if(nIncantIndex == MY_ROW_NUMBER && GetBaseItem(oItemToEnchant) != BASE_ITEM_QUARTERSTAFF)
   {
    SendMessageToPC(oPC, "CAN ONLY ENCHANT STAVES");
    return;
   }   
  
   if(CheckCanEnchant(nIncantIndex, oItemToEnchant, oPC, NX2_ENCHANTING_2DA))
   {
   EnchantItem(nIncantIndex, oItemToEnchant, oPC, NX2_ENCHANTING_2DA);         
   DestroyObject(oItem);
   DelayCommand(0.1, CheckOtherProperties(oPC, oItemToEnchant, OBJECT_INVALID));
   }
  }
  }

Modifié par Lance Botelle, 20 février 2014 - 02:28 .