Aller au contenu

Photo

Community Patch discussion and development thread


  • Veuillez vous connecter pour répondre
919 réponses à ce sujet

#201
MagicalMaster

MagicalMaster
  • Members
  • 2 000 messages

Assuming you really want to enable those classes, I don't think you really have a choice except to go with option 2 as you can't realistically enable the PrCs otherwise.

 

But basically it matches with the PRC implementation (Shou) except its all hardcoded into engine. Also there is an undocumented feature that upon taking Shou Disciple, the monk's AC continue to work with light armor, but there might be much more.

 

I think the monk AC with light armor is intended for whatever it's worth.

 

One question I would have is whether the "Martial Flurry" simply adds an extra attack for -2 across the board or if also changes the progression to -3 instead of -5.  In other words, would a Fighter/WM/Shou get 18/15/12/9/6/3/0/18 (in terms of BAB progression at level 20) with a Greatsword?  It says "any weapon," so...

 

And yeah, Flurry is selectable.

 

Do you have notes for your implementation of Eye of Gruumsh?



#202
Shadooow

Shadooow
  • Members
  • 4 470 messages

My implementation of Eye of the Gruumsh comes from description (line 110690 in dialog.tlk). The feats were already there only unused and unset, but I had to create a two spells, one for Command Horde and second for the Blinding Spittle.

 

He gets the normal barbarian rage feats - and I believe this is intented - as there were no unused feats for this. And the Swing Blindly feat is coded into standard barbarian rage script (which unfortunately means that this wont work in a modules where a nonstandard barbarian rage script is present - I havent thought of this, might be possible to get around this via making the feat selectable triggering new spell instead.)



#203
Bogdanov89

Bogdanov89
  • Members
  • 139 messages

A rather silly question: where can i download all the latest NWN mods you (ShadoOoW) have made for NWN?

 

I know where to find the latest RC4 patch, but i do not know where to find the latest versions of the other mods you have made (like the 50%/75% empower/maximize mod)?

 

Thanks for helping out.

 

edit: Also is the RC5 coming out anytime soon?



#204
Shadooow

Shadooow
  • Members
  • 4 470 messages

A rather silly question: where can i download all the latest NWN mods you (ShadoOoW) have made for NWN?

 

I know where to find the latest RC4 patch, but i do not know where to find the latest versions of the other mods you have made (like the 50%/75% empower/maximize mod)?

 

Thanks for helping out.

All my work at old vault: LINK. (Not what you are looking for, only for a showcase)

All my newer work is on new vault: LINK.

 

 

 

edit: Also is the RC5 coming out anytime soon?

Next version will be final 1.71. Im waiting for finishing the russian texts corrections from one of the external volunteer, but hes quite busy lately...


  • Squatting Monk et Rolo Kipp aiment ceci

#205
Pstemarie

Pstemarie
  • Members
  • 2 745 messages

Can you fix the TakeNumItems function in nw_i0_plot so it can handle stacks. According to the Lexicon, its broken. While the function isn't used by any core BioWare scripts, it would be nice to have a function that doesn't destroy an entire stack of items when you just want to take one item from the stack.

 

The code currently looks like: 

//:: TakeNumItems
//////////////////////////////////////////////////
//
//  TakeNumItems
//
//////////////////////////////////////////////////
//
//
// Takes the number of items specified from the target.
//
//////////////////////////////////////////////////
//
//  Created By: John
//  Created On: September 19, 2001
//
//////////////////////////////////////////////////
void TakeNumItems(object oTarget,string sItem,int nNumItems)
{
    int nCount = 0;
    object oItem = GetFirstItemInInventory(oTarget);
 
    while (GetIsObjectValid(oItem) == TRUE && nCount < nNumItems)
    {
        if (GetTag(oItem) == sItem)
        {
            ActionTakeItem(oItem,oTarget);
            nCount++;
        }
        oItem = GetNextItemInInventory(oTarget);
    }
 
   return;
}

It should look like (the fixed version from my module):

//:: TakeNumItems
//////////////////////////////////////////////////
//
//  TakeNumItems
//
//////////////////////////////////////////////////
//
//
// Takes the number of items specified from the target.
//
//////////////////////////////////////////////////
//
//  Created By: John
//  Created On: September 19, 2001
//
//////////////////////////////////////////////////
void TakeNumItems(object oTarget,string sItem,int nNumItems)
{
    int nCount = 0;
    object oItem = GetFirstItemInInventory(oTarget);
 
    while (GetIsObjectValid(oItem) == TRUE && nCount < nNumItems)
    {
        if (GetTag(oItem) == sItem)
        {
            if (GetItemStackSize(oItem) > 1)
            {
                SetItemStackSize(oItem, GetItemStackSize(oItem) -1);
            }
            else
            {
                ActionTakeItem(oItem,oTarget);
            }
            nCount++;
        }
        oItem = GetNextItemInInventory(oTarget);
    }
 
   return;
}

  • Rolo Kipp aime ceci

#206
Shadooow

Shadooow
  • Members
  • 4 470 messages

definitely, btw the russian corrections are done, im compiling the installer now, next release is now very close


  • Pstemarie aime ceci

#207
Pstemarie

Pstemarie
  • Members
  • 2 745 messages

x0_i0_treasure - the lance which was added in v1.69 was never defined as a baseitem for this include in the functions CTG_GetIsWeapon() and CTG_GetIsMeleeWeapon(). Lances do not behave properly when using the alternate BioWare treasure system (XP1 Loot Containers).

 

The affected scripts (for compiling the corrected functions) are: 

 

Searching for: x0_i0_treasure
 
nw_c2_default9.nss(31): #include "x0_i0_treasure"
x0_c2_spwn_cowrd.nss(29): #include "x0_i0_treasure"
x0_c2_spwn_cres.nss(11): #include "x0_i0_treasure"
x0_c2_spwn_def.nss(28): #include "x0_i0_treasure"
x0_c2_spwn_defn.nss(29): #include "x0_i0_treasure"
x0_c2_spwn_lhig.nss(13): #include "x0_i0_treasure"
x0_c2_spwn_llow.nss(13): #include "x0_i0_treasure"
x0_c2_spwn_lmed.nss(13): #include "x0_i0_treasure"
x0_c2_spwn_luni.nss(13): #include "x0_i0_treasure"
x0_c2_spwn_rang.nss(29): #include "x0_i0_treasure"
x0_i0_deckmany.nss(18): #include "x0_i0_treasure"
x0_o2_anyhigh.nss(12): #include "x0_i0_treasure"
x0_o2_anylow.nss(12): #include "x0_i0_treasure"
x0_o2_anymed.nss(12): #include "x0_i0_treasure"
x0_o2_anyuniq.nss(12): #include "x0_i0_treasure"
x0_o2_armhigh.nss(12): #include "x0_i0_treasure"
x0_o2_armlow.nss(12): #include "x0_i0_treasure"
x0_o2_armmed.nss(12): #include "x0_i0_treasure"
x0_o2_armuniq.nss(12): #include "x0_i0_treasure"
x0_o2_bookhigh.nss(12): #include "x0_i0_treasure"
x0_o2_booklow.nss(12): #include "x0_i0_treasure"
x0_o2_bookmed.nss(12): #include "x0_i0_treasure"
x0_o2_bookuniq.nss(12): #include "x0_i0_treasure"
x0_o2_clthhigh.nss(12): #include "x0_i0_treasure"
x0_o2_clthlow.nss(12): #include "x0_i0_treasure"
x0_o2_clthmed.nss(12): #include "x0_i0_treasure"
x0_o2_clthuniq.nss(12): #include "x0_i0_treasure"
x0_o2_goldhigh.nss(12): #include "x0_i0_treasure"
x0_o2_goldlow.nss(12): #include "x0_i0_treasure"
x0_o2_goldmed.nss(12): #include "x0_i0_treasure"
x0_o2_mleehigh.nss(12): #include "x0_i0_treasure"
x0_o2_mleelow.nss(12): #include "x0_i0_treasure"
x0_o2_mleemed.nss(12): #include "x0_i0_treasure"
x0_o2_mleeuniq.nss(12): #include "x0_i0_treasure"
x0_o2_noamhigh.nss(12): #include "x0_i0_treasure"
x0_o2_noamlow.nss(12): #include "x0_i0_treasure"
x0_o2_noammed.nss(12): #include "x0_i0_treasure"
x0_o2_noamuniq.nss(12): #include "x0_i0_treasure"
x0_o2_potnhigh.nss(12): #include "x0_i0_treasure"
x0_o2_potnlow.nss(12): #include "x0_i0_treasure"
x0_o2_potnmed.nss(12): #include "x0_i0_treasure"
x0_o2_potnuniq.nss(12): #include "x0_i0_treasure"
x0_o2_ranghigh.nss(12): #include "x0_i0_treasure"
x0_o2_ranglow.nss(12): #include "x0_i0_treasure"
x0_o2_rangmed.nss(12): #include "x0_i0_treasure"
x0_o2_ranguniq.nss(12): #include "x0_i0_treasure"
x0_o2_weaphigh.nss(12): #include "x0_i0_treasure"
x0_o2_weaplow.nss(12): #include "x0_i0_treasure"
x0_o2_weapmed.nss(12): #include "x0_i0_treasure"
x0_o2_weapuniq.nss(12): #include "x0_i0_treasure"
Found 50 occurrence(s) in 50 file(s)
 
AND because the x0_i0_deckmany.nss is in that list:
 
Searching for: x0_i0_deckmany
 
x0_deck_hatch.nss(7): #include "x0_i0_deckmany"
x0_s3_deckavatar.nss(5): #include "x0_i0_deckmany"
x0_s3_deckmany.nss(14): See the library x0_i0_deckmany for how the individual cards
x0_s3_deckmany.nss(26): #include "x0_i0_deckmany"
Found 4 occurrence(s) in 4 file(s)
 
Can we fix these too?


#208
Shadooow

Shadooow
  • Members
  • 4 470 messages

Ok, I looked at it. It might be better to use baseitems.2da lookup like I did in x2_inc_itemprop (for weapon boost spells to enable custom content weapons). This way it would accept all custom weapons like those from CEP?
 
btw, checked your code for TakeNumItems and corrected since you had a minor logical error there - it took always only one item from each stack it found causing a possible exit while it didnt removed all items it should have to.
 
this is the function prototype I added into CPP:

void TakeNumItems(object oTarget,string sItem,int nNumItems)
{
    int nCount = 0;
    object oItem = GetFirstItemInInventory(oTarget);

    while (GetIsObjectValid(oItem) == TRUE && nNumItems > 0)
    {
        if (GetTag(oItem) == sItem)
        {
            nCount = GetItemStackSize(oItem);
            if (nCount > 1 && nCount > nNumItems)//1.71: proper stacked items handling
            {
                SetItemStackSize(oItem, nCount-nNumItems);
                return;
            }
            else
            {
                ActionTakeItem(oItem,oTarget);
                nNumItems-= nCount;
            }
        }
        oItem = GetNextItemInInventory(oTarget);
    }

   return;
}

Modifié par Shadooow, 16 avril 2014 - 08:09 .

  • Pstemarie, henesua et Rolo Kipp aiment ceci

#209
henesua

henesua
  • Members
  • 3 864 messages
I think its better to use the 2da.

#210
Shadooow

Shadooow
  • Members
  • 4 470 messages

I think its better to use the 2da.

Ok. This is it. I please for a revisit my code if I havent made any errors. I dont have a time for playtesting now.

btw, note I added helmet into armor category and fixed bug with no-ammo category - any thoughts?

// Check if the item's base type is a weapon
int CTG_GetIsWeapon(int nItemBaseType)//1.71: made the function custom content weapons compatible
{
 if(nItemBaseType == BASE_ITEM_INVALID)
 return FALSE;
return StringToInt(Get2DAString("baseitems","WeaponType",nItemBaseType)) > 0;
}

// Check if the item's base type is a weapon but not ammunition
int CTG_GetIsWeaponNoammo(int nItemBaseType)//1.71: fixed bug when bolt and bullet were omitted
{
    return ( CTG_GetIsWeapon(nItemBaseType)
             && nItemBaseType != BASE_ITEM_ARROW
             && nItemBaseType != BASE_ITEM_BOLT
             && nItemBaseType != BASE_ITEM_BULLET);
}

// Check if the item's base type is a ranged weapon
int CTG_GetIsRangedWeapon(int nItemBaseType)
{
    return (nItemBaseType == BASE_ITEM_DART
            || nItemBaseType == BASE_ITEM_GRENADE
            || nItemBaseType == BASE_ITEM_HEAVYCROSSBOW
            || nItemBaseType == BASE_ITEM_LIGHTCROSSBOW
            || nItemBaseType == BASE_ITEM_LONGBOW
            || nItemBaseType == BASE_ITEM_SHORTBOW
            || nItemBaseType == BASE_ITEM_SHURIKEN
            || nItemBaseType == BASE_ITEM_SLING
            || nItemBaseType == BASE_ITEM_THROWINGAXE);
}

// Check if the item's base type is a melee weapon
int CTG_GetIsMeleeWeapon(int nItemBaseType)//1.71: made the function custom content weapons compatible
{
    return !CTG_GetIsRangedWeapon(nItemBaseType) && CTG_GetIsWeapon(nItemBaseType);
}

// Check if the item's base type is armor
int CTG_GetIsArmor(int nItemBaseType)
{
    return (nItemBaseType == BASE_ITEM_ARMOR
            || nItemBaseType == BASE_ITEM_LARGESHIELD
            || nItemBaseType == BASE_ITEM_SMALLSHIELD
            || nItemBaseType == BASE_ITEM_TOWERSHIELD)
            || nItemBaseType == BASE_ITEM_HELMET;//1.71: added missing helmet
}

// Check if the item's base type is clothing
int CTG_GetIsClothing(int nItemBaseType)//1.71: any item that can be equipped into boot/arms/cloak/belt slot is now considered to be clothing
{
    string sSlot = Get2DAString("baseitems","EquipableSlots",nItemBaseType);
    return sSlot == "0x00004" //boots
        || sSlot == "0x00008" //gloves/bracers
        || sSlot == "0x00040" //cloak
        || sSlot == "0x00400"; //belt
}

Modifié par Shadooow, 16 avril 2014 - 07:51 .

  • Rolo Kipp aime ceci

#211
Pstemarie

Pstemarie
  • Members
  • 2 745 messages

 

Ok, I looked at it. It might be better to use baseitems.2da lookup like I did in x2_inc_itemprop (for weapon boost spells to enable custom content weapons). This way it would accept all custom weapons like those from CEP?
 
btw, checked your code for TakeNumItems and corrected since you had a minor logical error there - it took always only one item from each stack it found causing a possible exit while it didnt removed all items it should have to.
 
this is the function prototype I added into CPP:

void TakeNumItems(object oTarget,string sItem,int nNumItems)
{
    int nCount = 0;
    object oItem = GetFirstItemInInventory(oTarget);

    while (GetIsObjectValid(oItem) == TRUE && nNumItems > 0)
    {
        if (GetTag(oItem) == sItem)
        {
            nCount = GetItemStackSize(oItem);
            if (nCount > 1 && nCount > nNumItems)//1.71: proper stacked items handling
            {
                SetItemStackSize(oItem, nCount-nNumItems);
                return;
            }
            else
            {
                ActionTakeItem(oItem,oTarget);
                nNumItems-= nStack;
            }
        }
        oItem = GetNextItemInInventory(oTarget);
    }

   return;
}

 You have an error in there that causes any script linked to nw_i0_plot to fail on compile. nStack is not defined anywhere.


  • Shadooow aime ceci

#212
Shadooow

Shadooow
  • Members
  • 4 470 messages

got it, thanks, please take yet a look at the x0_i0_treasure code



#213
Pstemarie

Pstemarie
  • Members
  • 2 745 messages

got it, thanks, please take yet a look at the x0_i0_treasure code

 

Just did - it looks good but I haven't tested it yet.



#214
Shadooow

Shadooow
  • Members
  • 4 470 messages

oh and btw, im just checking which script will be needed to recompile and I do think that only scripts where is specified the nBaseType1-3 parameters, when this parameters isnt specified none of these functions is used - unless I read it wrong <_<



#215
Pstemarie

Pstemarie
  • Members
  • 2 745 messages

Your revisions to x0_i0_treasure appear to be working ok. I still had to customize it a bit more because I use some custom races, but other than that it should be golden. I compiled all the scripts linked in just to be certain.



#216
Shadooow

Shadooow
  • Members
  • 4 470 messages

Your revisions to x0_i0_treasure appear to be working ok. I still had to customize it a bit more because I use some custom races, but other than that it should be golden. I compiled all the scripts linked in just to be certain.

Im pretty sure that my modifications doesnt need to be compiled with all those scripts, just those using the nBaseItem1/2 parameters, but if you also changed the main functions then you indeed need to do it.

 

 

 

There is a little complication in making a new release (trouble with installer) so I had yet time to consider some last additions. One of them is something the Pstemarie told me about earlier and thats a "Cast spell: ****" property cost. This should match this formula:

 

Innate 0 - Cost = 375 * caster level
Innate 1 - Cost = 750 * caster level
Innate 2 - Cost = 1500 * caster level
Innate 3 - Cost = 2250 * caster level
Innate 4 - Cost = 3000 * caster level
Innate 5 - Cost = 3750 * caster level
Innate 6 - Cost = 4500 * caster level
Innate 7 - Cost = 5250 * caster level
Innate 8 - Cost = 6000 * caster level
Innate 9 - Cost = 6750 * caster level

 

however around a 20% of spell cost doesnt match this. Ive already corrected a single spell that I found ingame where this was obviously wrong (Mestils acid sheat - lower cost than elemental shield resulted in possibility to cast it from scroll earlier) but havent notice others in gameplay.

 

The question is, did anyone made a research of why this is? Perhaps its another OC/expansion mismatch? Cant that be an intent?

 

What about of an unification? I rejected this previously, but perhaps its something that should be done?

 

The unification would resulted into minor change of the base cost of the scrolls/wands/potions/other items with cast spell property. I suspect it wouldnt be noticeable in most cases, but it might be a bit more profitable for players since most times the new cost would be greater. In few cases it might change a level required to be able to use that item under ILR/with UMD, but that should be only few of them.


  • Pstemarie aime ceci

#217
Pstemarie

Pstemarie
  • Members
  • 2 745 messages

Im pretty sure that my modifications doesnt need to be compiled with all those scripts, just those using the nBaseItem1/2 parameters, but if you also changed the main functions then you indeed need to do it.

 

 

 

There is a little complication in making a new release (trouble with installer) so I had yet time to consider some last additions. One of them is something the Pstemarie told me about earlier and thats a "Cast spell: ****" property cost. This should match this formula:

 

Innate 0 - Cost = 375 * caster level
Innate 1 - Cost = 750 * caster level
Innate 2 - Cost = 1500 * caster level
Innate 3 - Cost = 2250 * caster level
Innate 4 - Cost = 3000 * caster level
Innate 5 - Cost = 3750 * caster level
Innate 6 - Cost = 4500 * caster level
Innate 7 - Cost = 5250 * caster level
Innate 8 - Cost = 6000 * caster level
Innate 9 - Cost = 6750 * caster level

 

however around a 20% of spell cost doesnt match this. Ive already corrected a single spell that I found ingame where this was obviously wrong (Mestils acid sheat - lower cost than elemental shield resulted in possibility to cast it from scroll earlier) but havent notice others in gameplay.

 

The question is, did anyone made a research of why this is? Perhaps its another OC/expansion mismatch? Cant that be an intent?

 

What about of an unification? I rejected this previously, but perhaps its something that should be done?

 

The unification would resulted into minor change of the base cost of the scrolls/wands/potions/other items with cast spell property. I suspect it wouldnt be noticeable in most cases, but it might be a bit more profitable for players since most times the new cost would be greater. In few cases it might change a level required to be able to use that item under ILR/with UMD, but that should be only few of them.

 

The justification for the reduced cost was to balance when playing in single player. You'll notice virtually every low-level healing spell ignores the referenced formula. That's because in single player BioWare believed that healing items need to be cheap enough that a player could afford to buy lots of them without cutting too heavily into their cash flow. In multi-player, its not a big deal to have healing cost a little more.

 

I made these changes in NwnE and never noticed a big difference when playing. I think it was more a fallacy on BioWare's part than a concrete decision based on balance.



#218
Shadooow

Shadooow
  • Members
  • 4 470 messages

The justification for the reduced cost was to balance when playing in single player. You'll notice virtually every low-level healing spell ignores the referenced formula. That's because in single player BioWare believed that healing items need to be cheap enough that a player could afford to buy lots of them without cutting too heavily into their cash flow. In multi-player, its not a big deal to have healing cost a little more.

Oh, good point. Healing is out, will take a look what remains.



#219
Shadooow

Shadooow
  • Members
  • 4 470 messages

Oh, good point. Healing is out, will take a look what remains.

after closer look, there are few spells I think intentionally overpriced (flesh to stone, stone to flesh, non spells, epic spell), few of the overpriced are imo messed up - SoU cantrips

 

from underpriced, healing is reasonable, some others like barkskin that are also available in standard potions also, the rest is imo messed up - for example both flame weapon itemproperties have the cost of 4500 while they are different level (seems like a copy paste from the preexisting line from OC which however wasnt implemented)

 

My proposal is to keep intented mismatches (healing, flesh to stone, standard potion buffs, non spells and epic spells) and unify the rest.

 

 

 

BTW: found in todo list Worm's hands. I found them better than kurairyu's ones that are included in CPP - any reason not to switch them? And is there anyone who could make the hand module from 1.69 which is missing in worm's hak?


  • Pstemarie aime ceci

#220
Pstemarie

Pstemarie
  • Members
  • 2 745 messages

 

BTW: found in todo list Worm's hands. I found them better than kurairyu's ones that are included in CPP - any reason not to switch them? And is there anyone who could make the hand module from 1.69 which is missing in worm's hak?

 

You and I think alike. I just finished processing these for inclusion in Project Q to replace the plethora of hands we've got. I've got variation for all the default BioWare models and the custom ones. I'll gladly give you the standards I've got.


  • Shadooow et Rolo Kipp aiment ceci

#221
Gruftlord

Gruftlord
  • Members
  • 348 messages

worm's hands look better with weapons, kurairyu's look better with empty hands, especially when casting. i always prefered the latter for this reason. both are an improvement over the vanilla hands, but i find worm's hands too odd when casting, but i'm less put off by the open hands when holding a weapon. somehow it's just less noticable. see the pictures on worms hak page: the angles at which the closed hands are best shown are very rarelly seen ingame. the first pic on the top left wouldn't look much different with kurairyu's hands. now imagine the closed fists with a casting animation, and you see where i'm coming from.

 

so: i'm trowing my vote into the ring in favor of the older kurairyu hands.



#222
Shadooow

Shadooow
  • Members
  • 4 470 messages

worm's hands look better with weapons, kurairyu's look better with empty hands, especially when casting. i always prefered the latter for this reason. both are an improvement over the vanilla hands, but i find worm's hands too odd when casting, but i'm less put off by the open hands when holding a weapon. somehow it's just less noticable. see the pictures on worms hak page: the angles at which the closed hands are best shown are very rarelly seen ingame. the first pic on the top left wouldn't look much different with kurairyu's hands. now imagine the closed fists with a casting animation, and you see where i'm coming from.

 

so: i'm trowing my vote into the ring in favor of the older kurairyu hands.

I see. Havent thought of that. Keeping kurairyu's then - worms will be in Q afterall.
 

*thinking about a nwncx plugin that would be able to show both hands based on whether is hand empty or not*


  • henesua et Rolo Kipp aiment ceci

#223
Gruftlord

Gruftlord
  • Members
  • 348 messages

*thinking about a nwncx plugin that would be able to show both hands based on whether is hand empty or not*

oh hell yes please. if this would be possible, that would be epic.


  • Shadooow et KlatchainCoffee aiment ceci

#224
Shadooow

Shadooow
  • Members
  • 4 470 messages

oh hell yes please. if this would be possible, that would be epic.

Its definitely possible based on the magic the virusman made with open faced helmet nwnx support. The question is whether I am able to do this :).


  • Rolo Kipp et KlatchainCoffee aiment ceci

#225
Pstemarie

Pstemarie
  • Members
  • 2 745 messages

You might be able to do it via a pheno change - an new pheno that has the spellcasting kuri hands - but the stutter during the pheno change might not be worth the effort.