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

Legacy_Bogdanov89

  • Full Member
  • ***
  • Posts: 155
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #630 on: September 22, 2014, 03:04:50 pm »


               

Hello ShadoOoW '<img'>


 


The improvements in the last few 1.72 betas are awesome!


 


Any idea when the 1.72 final would be released?



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #631 on: September 24, 2014, 10:10:25 am »


               

I would like to do it in december, but no promises. I need especially peoples playtesting and buildtesting the new beta with the NWN©X in use.


 


Unlike other packages I cannot afford to release a product with even single bug.



               
               

               
            

Legacy_Prizzard

  • Newbie
  • *
  • Posts: 37
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #632 on: September 30, 2014, 06:03:28 am »


               

I searched this topic for "swift spell" to see if it has been discussed at all. Spells like Wraithstrike and Blade of Blood are almost useless when they take up a full combat turn, so I have a poooossible suggestion for how to implement spells: Why not have the spell in it's root description use the Quicken feat without checking if the player has it? Just activate it silently as part of casting the spell, or copy the Quicken script and rename it Swift to allow the differences. If something like this is implemented, something like an ATB gauge would be nice with tic-marks for when your attacks or spells will take place in order to make timing things easier.



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #633 on: September 30, 2014, 07:25:11 am »


               


I searched this topic for "swift spell" to see if it has been discussed at all. Spells like Wraithstrike and Blade of Blood are almost useless when they take up a full combat turn, so I have a poooossible suggestion for how to implement spells: Why not have the spell in it's root description use the Quicken feat without checking if the player has it? Just activate it silently as part of casting the spell, or copy the Quicken script and rename it Swift to allow the differences. If something like this is implemented, something like an ATB gauge would be nice with tic-marks for when your attacks or spells will take place in order to make timing things easier.




It should be possible to do it with NWNX.


 


Ingredients: nwnx_events plugin (unfortunately I think only linux version has this) and nwnx_funcs (for adding feats)


Plan: in OnSpellCast (which trigger before you actually cast, check for spell id and if matches your spell then add autoquickspell III feat on character. Next spell remove that feat before cast.


               
               

               
            

Legacy_Prizzard

  • Newbie
  • *
  • Posts: 37
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #634 on: October 03, 2014, 12:58:10 am »


               

A few more things I'm surprised big patchers haven't 'fixed.. Chain Shirt should be light armor, objects should be immune to critical hits, and undead shouldn't be able to heal with various 'cure wounds' potions.


 


Edit: And scythes are martial weapons..



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #635 on: October 03, 2014, 02:14:33 am »


               


A few more things I'm surprised big patchers haven't 'fixed.. Chain Shirt should be light armor, objects should be immune to critical hits, and undead shouldn't be able to heal with various 'cure wounds' potions.


 


Edit: And scythes are martial weapons..




because this project is not allowed to do any of this


 


Many players believe that what Bioware implemented is set in the stone and cannot be changed. And that is even better that way. Changing these things would be by the opinion of most gamers too big balance change. Some dislike CPP already because a few changed like this but I think there is minimum of them.


 


The issues you mention are 3.0 / 3.5 differences, while I personaloly agree that 3.0 is broken ruleset and 3.5 is a patch, majority peoples from NWN community disagree and they want 3.0 instead. Or just what Bioware decided.


 


Other than that, there are laos technical difficulties to make some things, like the mentioned immunity to critical hits for objects. But I think that even this would be a big issue for most peoples.


 


And undeads., they are not healed by cure wound spells, neither heal or mass heal, only greater restoration and healers kits (which in 1.72 you can modify in script actually but I havent changed that again because of the issue I mentioned).


               
               

               
            

Legacy_Prizzard

  • Newbie
  • *
  • Posts: 37
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #636 on: October 03, 2014, 11:38:58 am »


               

Aha, alright. Makes sense



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #637 on: October 05, 2014, 03:24:37 am »


               

Anyway, the mentioned critical/sneak immunity for objects (attackable placeables) is doable with NWNX_Patch plugin.


 


Question is, do you want it? Is it worth it, I mean doesnt this turn into another reason why other ppls dont want this patch? Of course, since its NWNX its optional and I will provide a way to deactivate it but it will be by default turned on.



               
               

               
            

Legacy_Grani

  • Hero Member
  • *****
  • Posts: 1040
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #638 on: October 25, 2014, 03:31:28 pm »


               

I've just recently decided to update from 1.70 to 1.71, but I've encountered some compilation problems due to this.


 


First of all, when I tried to modify Epic Warding script, a compilation error popped out in nw_i0_spells.nss on line 552 (variable type error):


 


int clOverride = spell.Level;


 


The whole section of the script is as follows:


 



//1.70: caster level override workaround, since ResistSpell function uses its own values
//and its hardcoded I apply a spell resistance decrease in the appropriate ammount in order to cheat
//this hardcoded function. This works pretty well for non-monks. Unfortunately 12+ lvl monks are immune to this solution.
int clOverride = spell.Level;
int clDefault = GetCasterLevel(oCaster);
 if(GetLastSpellCastClass() == CLASS_TYPE_INVALID && GetSpellCastItem() == OBJECT_INVALID)//fix for bug in SR check formula
 {//internal SR calculates with CL = innate level*2-1, and yes -1 for cantrips
 int clSR = StringToInt(Get2DAString("spells","Innate",GetEffectSpellId(EffectDazed())))*2-1;
  if(clDefault != clSR)//if default CL accidentaly matches CL for SR then its fine
  {
   if(!clOverride) clOverride = clDefault;
  clDefault = clSR;
  }
 }
int SR = GetSpellResistance(oTarget);
effect eWorkaround;
 if(bAOE)//AOE workaround to fix various exploits
 {
 int nResisted = 0;
  if(SR > 0)
  {
   if(d20()+(clOverride > 0 ? clOverride : clDefault) < SR)//resisted
   {
   nResisted = 1;
   DelayCommand(fDelay,ApplyEffectToObject(DURATION_TYPE_INSTANT,EffectVisualEffect(VFX_IMP_MAGIC_RESISTANCE_USE),oTarget));
   }
  string sFeedback = GetStringByStrRef(8342);
  sFeedback = GetStringLeft(sFeedback,GetStringLength(sFeedback)-10);
  sFeedback = GetStringRight(sFeedback,GetStringLength(sFeedback)-10);
  sFeedback = "<c›ţţ>"+GetName(oTarget)+"</c> <cÍţ>"+sFeedback+" "+GetStringByStrRef(nResisted == 1 ? 8343 : 5353)+"</c>";
  SendMessageToPC(oTarget,sFeedback);
  SendMessageToPC(oCaster,sFeedback);
  }
 return nResisted;
 }
 else if(clOverride > 0 && SR > 0)//spell penetration correction
 {
  //if overriden above default caster level we must alter spell resistance of our target...
  if(clOverride > clDefault && clOverride+20 >= SR)
  {                          //do nothing if there is no chance to penetrate SR anyway
  eWorkaround = EffectSpellResistanceDecrease(clOverride-clDefault);
  ApplyEffectToObject(DURATION_TYPE_TEMPORARY,eWorkaround,oTarget,0.01);//temporary workaround to force game use correct values
  SR = -255;
  }
  else if(clOverride < clDefault && clDefault+20 >= SR)
  {                               //do nothing if the default CL has no chance to penetrate SR anyway
  eWorkaround = EffectSpellResistanceIncrease(SR+clDefault-clOverride);
  ApplyEffectToObject(DURATION_TYPE_TEMPORARY,eWorkaround,oTarget,0.01);//temporary workaround to force game use correct values
  SR = -255;
  }
 }//end of caster level workaround

I tried to build my module and check for any other compilation errors I might find and more of them popped out.


zep_o0_death.nss returned a compilation error in nw_i0_generic.nss, line 857 (lack of right bracket error):


 


if (GetLocalInt(OBJECT_SELF,"70_ALLOW_SHAPECHANGE") && TalentShapechange(oIntruder)) return 99;


 


As far as I've found out, these two scripts are the culprits, but there might be more. I only got compilation errors on scripts I modified, after all, and if there are any unmodified ones, like some other spell scripts, then they might not compile without letting me know.


 


Any idea what I should do?


 


Edit: I've also tried opening my modified missile storm scripts. And I couldn't, a message appeared saying that 70_inc_spellfunc content could not be found. Which makes me wonder, is 1.71 compatible with modules made with 1.70? Especially if some of scripts have been modified?


I've tried creating a whole new module and checking things there. When it comes to compilation, it's all the same problems, when I try to compile a spell or something else that caused problems in my module, I get an error in one of these two scripts. The only difference is that it lets me open missile storm scripts (no message about 70_inc_spellfunc content missing), but I still can't compile them.



               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #639 on: October 25, 2014, 04:06:19 pm »


               


I've just recently decided to update from 1.70 to 1.71, but I've encountered some compilation problems due to this.


 


First of all, when I tried to modify Epic Warding script, a compilation error popped out in nw_i0_spells.nss on line 552 (variable type error):


 


int clOverride = spell.Level;


 


The whole section of the script is as follows:




well I changed some of the functions and includes over 70 and 71 so exactly these kind of issues wont happen in future, the scripts and includes from 1.71 are not just backwards compatible but also forwards (ie. you can compile new spellscript from 1.71 with old includes and also compile old spellscript with new includes).


 


Unfortunately, if you built on 1.70 and modified some of the scripts and includes, specifically nw_i0_spells, 70_inc_spells etc. you get this kind of error.


 


If you send me full module (without areas if you dont trust me) I can merge it and fix it for you. Otherwise if you want to do this yourself you need to:


1. isolate includes/spellscripts you modified in your module


2. compare them with vanilla 1.70 includes/spellscripts (to see what have you changed there)


3. take version of the include/spellscript from 1.71 and add the changes youve made into the old versions


4. replace old for new one


5. recompile module


 


It would be really best if you could just send me the module so I can take a closer look and not just guess. PM me.


 


EDIT: oh and yes, 70_inc_spellfuncs no longer exists in 1.71



               
               

               
            

Legacy_Grani

  • Hero Member
  • *****
  • Posts: 1040
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #640 on: October 25, 2014, 04:24:06 pm »


               

Alright, sent you a PM.



               
               

               
            

Legacy_meaglyn

  • Hero Member
  • *****
  • Posts: 1451
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #641 on: November 04, 2014, 07:23:58 pm »


               

On the subject of compile errors... I wonder if you might consider renaming the struct spell definition to say struct spell_st or something?  My external compiler (nwnnsscomp) seems handle that poorly. It does not let me have the struct definition and a variable of that type in the same scope.   It's a very small change to 70_inc_spells to get around this, but a fairly major rework of the compiler to make it handle this right.  I can just pull 70_inc_spells into my code base but I'd prefer not to have to carry


that around forever if possible. Just thought I'd ask while 72 is still pending '<img'>


               
               

               
            

Legacy_Shadooow

  • Hero Member
  • *****
  • Posts: 7698
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #642 on: November 05, 2014, 02:01:05 pm »


               


On the subject of compile errors... I wonder if you might consider renaming the struct spell definition to say struct spell_st or something?  My external compiler (nwnnsscomp) seems handle that poorly. It does not let me have the struct definition and a variable of that type in the same scope.   It's a very small change to 70_inc_spells to get around this, but a fairly major rework of the compiler to make it handle this right.  I can just pull 70_inc_spells into my code base but I'd prefer not to have to carry


that around forever if possible. Just thought I'd ask while 72 is still pending '<img'>




This alredy happened in 1.71.


In 1.70 first cpp version the struct was named struct spell spell; which external PRC compiler wasne able to handle


in 1.71 the struct is named struct spells spell; which PRC compiler handles correctly. Also snce 1.71 spell structure is global.


 


So - check for the definition, it might be possible you have outdated 70_inc_spells? if not and you get error even with this then whats your compiler?


               
               

               
            

Legacy_meaglyn

  • Hero Member
  • *****
  • Posts: 1451
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #643 on: November 05, 2014, 02:58:51 pm »


               

I pulled the scripts from 1.71. The md5sum of the bif I used is here:


 


6998535f96ef94878c8d6b3b8ca1dc34  patch171.bif


 


The spell struct variable _is_ global but the struct definition and variable are both named spell.   Maybe I accidentally got one of the last RCs?


 


I'll try to download the latest 1.71 and see if it's different from what I currently have.


               
               

               
            

Legacy_meaglyn

  • Hero Member
  • *****
  • Posts: 1451
  • Karma: +0/-0
Community Patch discussion and development thread
« Reply #644 on: November 05, 2014, 03:23:46 pm »


               

Drat. Okay. I seem to have just merged in an old version of 1.71 "final" from dec 2013 called NWNPatch171_EN.zip.  The new final version does have the spells change you mentioned (and is 7zipped and has some nwnx files in it). Time to go see what else is different '<img'>


 


Edit: Also the 1.71 builder resources have a lot of script changes including the x3_inc_horse file which I thought was a 1.72 thing.  Is 1.71 still changing?