Author Topic: Community Patch discussion and development thread  (Read 21033 times)

Legacy_Pstemarie

  • Hero Member
  • *****
  • Posts: 4368
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #210 on: April 16, 2014, 08:56:02 pm »


               


 


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.


               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #211 on: April 16, 2014, 09:09:05 pm »


               

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



               
               

               
            

Legacy_Pstemarie

  • Hero Member
  • *****
  • Posts: 4368
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #212 on: April 16, 2014, 09:15:25 pm »


               


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.


               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #213 on: April 16, 2014, 09:23:54 pm »


               

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 '<_<'



               
               

               
            

Legacy_Pstemarie

  • Hero Member
  • *****
  • Posts: 4368
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #214 on: April 17, 2014, 04:47:24 pm »


               

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.



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #215 on: April 19, 2014, 09:44:58 pm »


               


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.


               
               

               
            

Legacy_Pstemarie

  • Hero Member
  • *****
  • Posts: 4368
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #216 on: April 19, 2014, 10:16:43 pm »


               


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.


               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #217 on: April 19, 2014, 10:44:25 pm »


               


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.


               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #218 on: April 20, 2014, 02:39:59 am »


               


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?



               
               

               
            

Legacy_Pstemarie

  • Hero Member
  • *****
  • Posts: 4368
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #219 on: April 20, 2014, 04:14:55 am »


               


 


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.


               
               

               
            

Legacy_Gruftlord

  • Sr. Member
  • ****
  • Posts: 490
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #220 on: April 20, 2014, 01:50:54 pm »


               

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.



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #221 on: April 20, 2014, 01:59:21 pm »


               


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*


               
               

               
            

Legacy_Gruftlord

  • Sr. Member
  • ****
  • Posts: 490
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #222 on: April 20, 2014, 02:21:38 pm »


               


*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.


               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #223 on: April 20, 2014, 02:29:40 pm »


               


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 '<img'>.


               
               

               
            

Legacy_Pstemarie

  • Hero Member
  • *****
  • Posts: 4368
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #224 on: April 20, 2014, 02:42:38 pm »


               

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.