My OnModule Load - duplicating issue and deity_core issue

Imtherealthing · April 11, 2020, 3:52pm

Can someone please help me…

On my OnModule Load event script I have had this ongoing problem for a long time. It won’t compile because of this error on the deity_core script

Also…

I get duplicating issues on the same OnModule Load script

If I disable the "SetModuleSwitch … (first highlighted line)

Using items in module like “a portable hole”, “Magic Rope”, “Net” (one can throw)…basically using (activating them) any item …it is disabled and won’t work. But I have a Gem crafting script that every time I socket a gem…i.e. a +1 Gem it becomes a +4 on socketing…it quadruples …other issues too is that some potions I drink and blink spell and congregate spell keep firing people keep blinking or teleporting to me with the congregate spell use. My re-generating creatures I get 8 times the xps on killing them.

If I disable the "if (GetModuleSwitchValue…(second highlighted line)

It fixes the duplicating issues…well sort of…It makes my +1 socketable gems a +2 on socketing but disables the use of items(activate them) like my “portable hole”, “Net”, “Magic Rope”

I know those two lines use the same commands…how does one fix these scripts to work without these issues?

I suck at scripting…I’m “ok at it”…help?..anyone?

NWShacker · April 11, 2020, 5:01pm

That error - although vague and unhelpful - means you already defined the DOMAIN_AIR constant in other script you are including in this script.

You cannot redefine a constant you include from somewhere.

Solution: put all your common constants in one file, like constants.nss.

It’s impossible to debug a script when you post only a fragment of it. But you really don’t need tag based scripting. You can easily use the standard OnActivateItem way of dealing with activated items (check the tag, then call specific code). It’s easy and everything is in one place if you can manage the script size. Also check if your OnActivateItem handle script does not conflict with tag based scripts (i.e. same functionality is invoked twice).

meaglyn · April 11, 2020, 7:00pm

Yeah, the newest EE build includes those defines already, but they may have different numbers. This is, they may be the rows in the domain 2da rather than the rows for the corresponding feats in that 2da.

I suspect the second issues is caused by you hooking up the tag based scripts to also run in the specific module events directly so it runs multiple times. So when you turn off tag-based scripts you get the one execution from the module event. But that’s just a guess…

Imtherealthing · April 11, 2020, 8:27pm

Thanks NWShacker…thanks so much for your answer…really really appreciate that. Unfortunately I have next to zero experience in scripting. Oh I can look at it and do a “few” things but not actually fix this. So are you saying I should just basically take out the two Yellow highlighted lines? Would my items with tags still work in the game? If not do you have a script that would fix this? You mentioned you would need to look at my full scripts right? I did post my entire OnactivateItem script as I mentioned in the other posted titled above I mentioned. So you would just need my OnModuleLoad script right? Sorry to pester you.

It’s impossible to debug a script when you post only a fragment of it. But you really don’t need tag based scripting. You can easily use the standard OnActivateItem way of dealing with activated items (check the tag, then call specific code). It’s easy and everything is in one place if you can manage the script size. Also check if your OnActivateItem handle script does not conflict with tag based scripts (i.e. same functionality is invoked twice).> Blockquote

I posted my “OnActivateItem” in a post here titled “I keep getting things to duplicate or quadruplicate”

Imtherealthing · April 11, 2020, 8:29pm

Thanks. I would not even know how to do a “constants.nss” script…lol

SO if I find another DOMANIN_AIR in another script I would just take that one out? Where is the most likely event script I would look?

Imtherealthing · April 11, 2020, 8:33pm

[/quote]I suspect the second issues is caused by you hooking up the tag based scripts to also run in the specific module events directly so it runs multiple times. So when you turn off tag-based scripts you get the one execution from the module event. But that’s just a guess…
[/quote]

Thanks for your reply too meaglyn…you guys are so great for helping. So are you saying I should disable the Set and Get Moduleswitches?

NWShacker · April 11, 2020, 9:00pm

A helpful hint: if you post any code on these boards, you must enclose it in [code] and [/code] tags to make it correctly render verbatim with monospace font. Otherwise it will be simply unreadable and a PITA to copy to the script editor.

For now put this debug code at any problematic place in all your scripts:

SendMessageToPC(GetFirstPC(), "Item <item name> activated");

to send whatever message you want to yourself. This will tell you what is executed and when. You can also put it at the beginning of every script. You will then see if it is executed when it shouldn’t.

Second step is to disable tag based scripting (the yellow thing) and debug OnActivateItem alone. You do that by commenting everything, then slowly allowing more and more code to run while you test each item at a time.

Example - this will never work:

// script1
const string FOO = "asdasd";

// script2
#include "script1"
const string FOO = "whatever";

To make it work, either script2 must not include script1 or it must not try to redefine FOO. If the constant is however defined by the engine (in nwscript.nss, like ABILITY_WISDOM), you cannot redefine it anywhere.

You can create a fresh script and dump all your custom constants in there. Then #include that script in your other scripts.

But if @meaglyn is right, DOMAIN_AIR & co are now in EE constants defined in core nwscript. You have therefore two options to resolve this name clash:

if your constants are value-equal to EE constants then you just delete your definitions as your scripts will pull them from nwscript
if they are different and you want to keep using yours, then you have to rename them, for example to MY_DOMAIN_AIR, etc

First approach is easier, but if you want to make your module backward-compatible with 1.69, you may need to do the second.

Imtherealthing · April 11, 2020, 9:47pm

Here is my OnLoad Script. Should I just disable the line below: “InitializePantheon();” So it pulls from the NWN script? Will it do that if I // InitializePantheon(); ?

Sorry about not using the and …still very newbie here. This is so frustrating for me to fix as I really do not know much about scripting. I tried below with my script I posted not sure if that it worked as you want. I just fake scripting through trial and experiment.

I disabled the lines:

 SetModuleSwitch (MODULE_SWITCH_ENABLE_TAGBASED_SCRIPTS, TRUE);

if (GetModuleSwitchValue (MODULE_SWITCH_ENABLE_TAGBASED_SCRIPTS) == TRUE)

and rebuilt the module…items do not activate…was hoping it would pull from the NWN script. Was I suppose to take something else out to make that work? Sorry for pestering you.

I am very grateful to you for your help…very grateful.

[code]//::///////////////////////////////////////////////
//:: Example XP2 OnLoad Script
//:: x2_mod_def_load
//:: © 2003 Bioware Corp.
//:://////////////////////////////////////////////
/*
Put into: OnModuleLoad Event

This example script demonstrates how to tweak the
behavior of several subsystems in your module.

For more information, please check x2_inc_switches
which holds definitions for several variables that
can be set on modules, creatures, doors or waypoints
to change the default behavior of Bioware scripts.

Warning:
Using some of these switches may change your games
balancing and may introduce bugs or instabilities. We
recommend that you only use these switches if you
know what you are doing. Consider these features
unsupported!

Please do NOT report any bugs you experience while
these switches have been changed from their default
positions.

Make sure you visit the forums at nwn.bioware.com
to find out more about these scripts.

*/
//:://////////////////////////////////////////////
//:: Created By: Georg Zoeller
//:: Created On: 2003-07-16
//:://////////////////////////////////////////////

#include “deity_onload_fr”
#include “x2_inc_switches”
#include “x2_inc_restsys”
#include “blsg_h”
#include “lss_loader”

void main()
{
SetModuleOverrideSpellscript(“spelloverride”);
LSSLoadChest();
ExecuteScript(“trap_on_load”, OBJECT_SELF);
BladeSingerModuleOnLoad();
InitializePantheon();
if (GetGameDifficulty() == GAME_DIFFICULTY_CORE_RULES || GetGameDifficulty() == GAME_DIFFICULTY_DIFFICULT)
{
// * Setting the switch below will enable a seperate Use Magic Device Skillcheck for
// * rogues when playing on Hardcore+ difficulty. This only applies to scrolls
SetModuleSwitch (MODULE_SWITCH_ENABLE_UMD_SCROLLS, TRUE);

   // * Activating the switch below will make AOE spells hurt neutral NPCS by default
   // SetModuleSwitch (MODULE_SWITCH_AOE_HURT_NEUTRAL_NPCS, TRUE);

}

// * AI: Activating the switch below will make the creaures using the WalkWaypoint function
// * able to walk across areas
//SetModuleSwitch (MODULE_SWITCH_ENABLE_CROSSAREA_WALKWAYPOINTS, TRUE);

// * Spells: Activating the switch below will make the Glyph of Warding spell behave differently:
// * The visual glyph will disappear after 6 seconds, making them impossible to spot
// SetModuleSwitch (MODULE_SWITCH_ENABLE_INVISIBLE_GLYPH_OF_WARDING, TRUE);

// * Craft Feats: Want 50 charges on a newly created wand? We found this unbalancing,
// * but since it is described this way in the book, here is the switch to get it back…
SetModuleSwitch (MODULE_SWITCH_ENABLE_CRAFT_WAND_50_CHARGES, TRUE);

// * Craft Feats: Use this to disable Item Creation Feats if you do not want
// * them in your module
// SetModuleSwitch (MODULE_SWITCH_DISABLE_ITEM_CREATION_FEATS, TRUE);

// * Palemaster: Deathless master touch in PnP only affects creatures up to a certain size.
// * We do not support this check for balancing reasons, but you can still activate it…
// SetModuleSwitch (MODULE_SWITCH_SPELL_CORERULES_DMASTERTOUCH, TRUE);

// * Epic Spellcasting: Some Epic spells feed on the liveforce of the caster. However this
// * did not fit into NWNs spell system and was confusing, so we took it out…
// SetModuleSwitch (MODULE_SWITCH_EPIC_SPELLS_HURT_CASTER, TRUE);

// * Epic Spellcasting: Some Epic spells feed on the liveforce of the caster. However this
// * did not fit into NWNs spell system and was confusing, so we took it out…
// SetModuleSwitch (MODULE_SWITCH_RESTRICT_USE_POISON_TO_FEAT, TRUE);

// * Spellcasting: Some people don't like caster's abusing expertise to raise their AC
// * Uncommenting this line will drop expertise mode whenever a spell is cast by a player
// SetModuleSwitch (MODULE_VAR_AI_STOP_EXPERTISE_ABUSE, TRUE);


// * Item Event Scripts: The game's default event scripts allow routing of all item related events
// * into a single file, based on the tag of that item. If an item's tag is "test", it will fire a
// * script called "test" when an item based event (equip, unequip, acquire, unacquire, activate,...)
// * is triggered. Check "x2_it_example.nss" for an example.
// * This feature is disabled by default.
 SetModuleSwitch (MODULE_SWITCH_ENABLE_TAGBASED_SCRIPTS, TRUE);

if (GetModuleSwitchValue (MODULE_SWITCH_ENABLE_TAGBASED_SCRIPTS) == TRUE)
{
// * If Tagbased scripts are enabled, and you are running a Local Vault Server
// * you should use the line below to add a layer of security to your server, preventing
// * people to execute script you don’t want them to. If you use the feature below,
// * all called item scrips will be the prefix + the Tag of the item you want to execute, up to a
// * maximum of 16 chars, instead of the pure tag of the object.
// * i.e. without the line below a user activating an item with the tag “test”,
// * will result in the execution of a script called “test”. If you uncomment the line below
// * the script called will be “1_test.nss”
// SetUserDefinedItemEventPrefix(“1_”);

}

// * This initializes Bioware’s wandering monster system as used in Hordes of the Underdark
// * You can deactivate it, making your module load faster if you do not use it.
// * If you want to use it, make sure you set “x2_mod_def_rest” as your module’s OnRest Script
// SetModuleSwitch (MODULE_SWITCH_USE_XP2_RESTSYSTEM, TRUE);

if (GetModuleSwitchValue(MODULE_SWITCH_USE_XP2_RESTSYSTEM) == TRUE)
{

   // * This allows you to specify a different 2da for the wandering monster system.
   // SetWanderingMonster2DAFile("des_restsystem");

   //* Do not change this line.
   WMBuild2DACache();

}

}
///////////////////////////////////////////////////////////////////////////////
// A module’s OnLoad event handler.
//
// A simple function containing just what the deity restrictions require –
// i.e. a call to InitializePantheon().
//
// I do not have a more complete template for this event, so there is
// no on_load1.
//
// Embellish as needed.
///////////////////////////////////////////////////////////////////////////////

// Include the (single) script that contains the pantheon you want to use.
// Keep the other includes commented out.

//#include “deity_onload_gh” // Greyhawk pantheon.
// // Forgotten Realms pantheon.
[/code]

meaglyn · April 12, 2020, 12:52am

I believe the new constants in nwscript are not the same values. I think in EE they refer to the domain.2da row number whereas in the dynamic pantheon they are just shorter versions of the feat rows. The simple fix here is to replace all the occurrences with the FEAT constants in all the pantheon scripts.

Disabling the InitializePantheon() call will make the deity system not work.

Disabling tag-based scripting will … disable tag-based scripting

Edit: Fixed really poor english sentence structure… geez

Imtherealthing · April 12, 2020, 6:24am

Thanks meaglyn.

I have no real clue nor the ability to fix this

I wish I had your skills

meaglyn · April 12, 2020, 3:14pm

To fix the DOMAIN constant issue:

Comment out the all the constants in that header file.
For each usage of DOMAIN_AIR in your deity files, replace with FEAT_AIR_DOMAIN_POWER.
Repeat #2 for each of the domains.

Mostly these constants will be used in the deity_onload script you are using and some of the deity conversation scripts.

You could also rename them as NWShacker suggested but this is cleaner as you remove a whole pile of unneeded duplicate constants.