NWNX2 Issue

[Legacy_BelowTheBelt]

               

sorry about that - change the "oPC" to "GetFirstPC()"

               
               

               
            

[Legacy_Demkey]

               

Still no message at all. Wow, this thing is really busted. I loaded a backup I made just prior of adding in NWNX2 just to make sure it wasn't something more sever, and the script runs fine on that backup copy.

               
               

               
            

[Baaleos]

               

What I would consider is this

 

1. Your script is using GetUserDefined  - which suggests it needs to run from the OnUser Defined event on your module. This event will fire when a UserDefined event is triggered- to be honest, I am not an avid user of this, so I cannot guide you with regards to this.

 

2. In most conventional modules, the onAcquired event of the module is used for onAcquire of items. If you remove your GetUserDefined, and the switch statement from your script and then have the script in the onAquire event of the module, it would normally work.

 

From what I can see you are using your script like a 'super script' or a 'god file'

This from a coding point of view is when a script/class starts doing too much.

 

If you are open to the idea, I'd recommend you take

ExecuteScript("aq_"+GetTag(GetModuleItemAcquired()),OBJECT_SELF); break;

 

and place it in a script of its own.

Then put that script in the onAcquire event of the module.

 

Other lines like 

ExecuteScript("ue_"+GetTag(GetPCItemLastUnequipped()), OBJECT_SELF); break;

 

I would recommend they also go in separate scripts and in the events related to them as well.

Eg: onUnequipped script into the onUnequipped module event etc

               
               

               
            

[Legacy_BelowTheBelt]

               Agree with Baaleos.  Best solution is really to break your script up and put the pieces into their respective Module events.  


Barring that, how do you have the User Defined event triggering?   User Defined events need some code to tell the engine to run that script.  Is there something in your module OnAcquire that sets a User Defined condition?


Post your mod's OnAcquire script.


Compare the scripts of the NWNX mod (the two above plus your module's OnAcquire script) with that if your working version to check for differences.  Since you can't have two mods open simultaneously, use Notepad or something to copy the scripts from one mod, close the mod and open your other mod.
               
               

               
            

[Legacy_Demkey]

               

I got it to work!! WOO HOO!!

 

Thanks to you guys I started really taking a hard look at the scripts in the module properties. The NWNX2 OnModuleLoad (aps_onload) replaces out the original script (x2_mod_def_load). I started reviewing the original scripts and noticed the below lines were missing from the NWNX2 script, which seemed to me to be a critical component to what I was experiencing. So I went ahead and added those lines into the aps_onload. I received an compiling error when doing that so I just did a copy&paste of the whole x2_mod_def_load into the aps_onload and rebuilt the module, and it now works.

 

   SetModuleSwitch (MODULE_SWITCH_ENABLE_TAGBASED_SCRIPTS, TRUE);

   if (GetModuleSwitchValue (MODULE_SWITCH_ENABLE_TAGBASED_SCRIPTS) == TRUE)

 

Thanks so much guys for your time and help, I would have never had looked that closely if it weren't for you two.

 

Hopefully I won't run into any issues with the NWNX2 stuff after doing this. What are your thoughts on that?

               
               

               
            

[Legacy_Shadooow]

               

According to Lilac I have to use the below coding and name the script the same as the Resref of the object that I'm placing in the encounter's inventory as the drop (which would be soulstone50). Then I'm suppose to create a second file that contains the above script with the same name but with a leading aq_ so it would be aq_soulstone50. Like I mentioned earlier the script was running fine up until yesterday when I installed NWNX2.

 

Here is what I have in the soulstone50 file:

 

#include "x2_inc_switches"

void main()

{

int nEvent =GetUserDefinedItemEventNumber();

switch (nEvent)

   {

   case X2_ITEM_EVENT_ACTIVATE:

ExecuteScript("ac_"+GetTag(GetItemActivated()),

OBJECT_SELF); break;

   case X2_ITEM_EVENT_EQUIP:

ExecuteScript("eq_"+GetTag(GetPCItemLastEquipped()),

OBJECT_SELF); break;

   case X2_ITEM_EVENT_UNEQUIP:

ExecuteScript("ue_"+GetTag(GetPCItemLastUnequipped())

, OBJECT_SELF); break;

   case X2_ITEM_EVENT_ACQUIRE:

ExecuteScript("aq_"+GetTag(GetModuleItemAcquired()),

OBJECT_SELF); break;

   case X2_ITEM_EVENT_UNACQUIRE:

ExecuteScript("ua_"+GetTag(GetModuleItemLost()),

OBJECT_SELF); break;

   case X2_ITEM_EVENT_SPELLCAST_AT:

ExecuteScript("sp_"+GetTag(GetModuleItemLost()),

OBJECT_SELF); break;

   case X2_ITEM_EVENT_ONHITCAST:

ExecuteScript("on_"+GetTag(GetSpellCastItem()),

OBJECT_SELF); break;

   }

}

Im late to the party it seems but...

 

Where have you digg this crap? Thats a probably worst way how to deal with that seriously. Creating 7 scripts for each item, omg.

 

Baaleos advice is fine and Im using that method often, but if you have more items it might blow up your module scripts and make them disorganized. Probably the best way to do this is still using an UserDefined but with a single script for each item. Read this tutorial.

               
               

               
            

[Legacy_Demkey]

               

I would agree with you that it's allot of scripts to do simple functions. When it comes to these Soul Stone I have 20 different levels of them that do essentially the same thing but have some subtle differences to them. What that means is that I now have 40 scripts to hand those 20 object. But I'm not a scripter/programmer so I have to rely on Lilac, and that's the method that Lilac says to handle OnAquire scripting. I wish I knew a better way!

               
               

               
            

[Baaleos]

               Hi Demkey,
Lilac Souls Generator is good for getting your foot in the door,
but I really do recommend you try to ween yourself off it soon.

There is only so far it can take you, and then you will eventually run out of ground and either have to fly or fall.

With the scripting language, the limitation really is whatever your imagination allows for.
Lilac Souls generator doesnt really allow you to stretch those muscles.

Generate some code, and then study it, and try to understand what its doing, and then try writing the same code yourself in future, and do slight optimizations as you go.

At the end of the day, the better scripter of the two (yourself and lilac souls generator) will always be you.
Because Lilac Souls Generator
1. Is only as smart as Lilac Soul was able to code it to be. Computer programs really aren't that smart.
2. It is incapable of that imaginative thinking mentioned, that a human can do.
3. It kinda promotes reliance on a 3rd party - you need to flex those muscles and learn from what you have.


The best way to do your scripting is to use
nwnlexicon.com

If you want to do a script that fires everytime 'something' is acquired, then study the
Events -> Module Events -> onAcquire
http://www.nwnlexico...e=OnAcquireItem

This is definitely your first step towards learning how to fly.
               
               

               
            

[Legacy_BelowTheBelt]

               

What that means is that I now have 40 scripts to hand those 20 object.

 

You can probably do it with 1 or only a couple scripts and 1 soulstone object by applying local integers on the soulstone item when it's created.

 

Start with a generic soulstone that is given to a PC.  When the item is created, have the script creating the object look at the circumstances of how it is created (the tag of the area, the level of the PC, or whatever the key differentiating factors are, etc...).  Then, SetLocalInt "SoulStoneType" on the item between 1 and 20.  Now you can tell what type of item it is just by using GetLocalInt on the item to look for that variable (rather than having 20 separate items).

 

In the OnAcquire, have it look for that variable, rather than the object tag/resref and take action accordingly...Int 1 = give 50gp/50xp.  int 2 = give 75gp/100xp, etc...  

 

This is much less to maintain and requires fewer resources.  What's more, it's scalable - you can add a limitless number of different variations of soulstones without having to make new scripts, items, etc...  Plus, a good challenge to learn!

               
               

               
            

[Legacy_Demkey]

               

Thanks for all the advice guys, and your help, I appreciate it. I just don't have the logic skills to code, somethings I can understand, but how to go about putting together anything complex is beyond my brain to figure out. What I need is my Coder back, but I don't think he has the time anymore so I'm going to have to make this module ugly I guess. LOL