Skip to content

New Domain Scipting Functions

Greetings everyone! I have a bit of a problem since the 1.80 patch and I believe it has to do with the new Domain constants in the patch. My deity core definitions scripts for my module no longer compile. They worked for many years and now suddenly they go ka-boom! on a compile. I'm using The_Krit's Dynamic Deity Populated Pantheon.
Does anyone have any insights on this? My guess is I need to redefine the constants?:
const int DOMAIN_AIR         = FEAT_AIR_DOMAIN_POWER;
const int DOMAIN_ANIMAL      = FEAT_ANIMAL_DOMAIN_POWER;
const int DOMAIN_CHAOS       = FEAT_CHAOS_DOMAIN_POWER;
const int DOMAIN_DEATH       = FEAT_DEATH_DOMAIN_POWER;
const int DOMAIN_DESTRUCTION = FEAT_DESTRUCTION_DOMAIN_POWER;
const int DOMAIN_EARTH       = FEAT_EARTH_DOMAIN_POWER;
const int DOMAIN_EVIL        = FEAT_EVIL_DOMAIN_POWER;
const int DOMAIN_FIRE        = FEAT_FIRE_DOMAIN_POWER;
const int DOMAIN_GOOD        = FEAT_GOOD_DOMAIN_POWER;
const int DOMAIN_HEALING     = FEAT_HEALING_DOMAIN_POWER;
const int DOMAIN_KNOWLEDGE   = FEAT_KNOWLEDGE_DOMAIN_POWER;
const int DOMAIN_LAW         = FEAT_LAW_DOMAIN_POWER;
const int DOMAIN_LUCK        = FEAT_LUCK_DOMAIN_POWER;
const int DOMAIN_MAGIC       = FEAT_MAGIC_DOMAIN_POWER;
const int DOMAIN_PLANT       = FEAT_PLANT_DOMAIN_POWER;
const int DOMAIN_PROTECTION  = FEAT_PROTECTION_DOMAIN_POWER;
const int DOMAIN_STRENGTH    = FEAT_STRENGTH_DOMAIN_POWER;
const int DOMAIN_SUN         = FEAT_SUN_DOMAIN_POWER;
const int DOMAIN_TRAVEL      = FEAT_TRAVEL_DOMAIN_POWER;
const int DOMAIN_TRICKERY    = FEAT_TRICKERY_DOMAIN_POWER;
const int DOMAIN_WAR         = FEAT_WAR_DOMAIN_POWER;
const int DOMAIN_WATER       = FEAT_WATER_DOMAIN_POWER;

Comments

  • SherincallSherincall Member Posts: 387
    Yes, there is a collision between those constants and the new ones added to nwscript. Unfortunately there has never been a good way to handle this (e.g. if Bioware/Beamdog added a function with a name you were already using).

    Since Bioware didn't plan for this immediately, e.g. by prefixing all the builtin identifiers with NW_, there's not a whole lot of options. For your immediate problem, I suggest changing those constants to KRIT_DOMAIN_XXX or something, and all their uses - or even just replace them with their FEAT_XXX values.

    going forward, it's generally a good idea to prefix your own functions and constants in some way; or be ready to update your scripts after a patch with new functions/constants drops.
  • KamirynKamiryn Member Posts: 74
    NWN 1.80 also defines constants DOMAIN_AIR, DOMAIN_ANIMAL... so you would have to rename your constants. But why do you need these constants? Why not use FEAT_AIR_DOMAIN_POWER directly?
  • ShadowMShadowM Member Posts: 573
    edited March 2020
    Kamiryn wrote: »
    NWN 1.80 also defines constants DOMAIN_AIR, DOMAIN_ANIMAL... so you would have to rename your constants. But why do you need these constants? Why not use FEAT_AIR_DOMAIN_POWER directly?

    One is defining the feat.2da row and one is defining the domain.2da row.
    It best to only define custom rows or use custom headers and leave bd alone. This help avoid conflicting constants which is important now with patches coming out.

    It be nice if we could get a 2 in the PickDomains column of classes.2da would go to a Deity selection screen instead of a domain select screen that read off a deity.2da and would be nice if domains work off domain feats on the players hidden skin or a SetDomain function. I already suggested this stuff but I figured I would mention it again.
    Post edited by ShadowM on
  • KamirynKamiryn Member Posts: 74
    ShadowM wrote: »
    Kamiryn wrote: »
    NWN 1.80 also defines constants DOMAIN_AIR, DOMAIN_ANIMAL... so you would have to rename your constants. But why do you need these constants? Why not use FEAT_AIR_DOMAIN_POWER directly?

    One is defining the feat.2da row and one is defining the domain.2da row.
    But that's not what the OP is doing (it's what Beamdog is doing).

  • ShadowMShadowM Member Posts: 573
    edited March 2020
    No, He defining feats which have already been defined, that is not needed. Could just point to though constants that already there in his functions.
  • Old_GithOld_Gith Member Posts: 152
    I see, thank you gentlemen. So in addition to redefining the constants in the core definitions script, I would also need to update the domains.2da and feats.2da, yes? And possible any other scripts associated.

  • ShadowMShadowM Member Posts: 573
    edited March 2020
    Old_Gith wrote: »
    I see, thank you gentlemen. So in addition to redefining the constants in the core definitions script, I would also need to update the domains.2da and feats.2da, yes? And possible any other scripts associated.

    Did you add some custom feat / domain? Like law, luck, chaos? Though are not in the base game (so will not conflict but should change them for consistency. Weird I added them my base for my custom deity system. I understand krit wanted to make it easier to read by connecting the domain with the domain feat, but that not good practice. Should of just pointed to the domain feats in the functions(like all three of us have said, sorry Kamiryn I see what you mean now in your previous comment) You should be fine on .2da you just have to fix all the call in the custom functions he made to point to the new names or have them point to the feats and delete/comment out this section of constants.

Sign In or Register to comment.