Unearthed Arcana presents Faiths & Powers: Gods of the Realms

[subtledoctor]

I think it’s worth testing whether it works as done in the MnG code, if you specify particular spheres instead of “sphere_list = ~%fnpdeity%~” … that’s already something that I’ve identified as potentially not fully working, do we should confirm whether it’s an issue. 

EDIT - wait wait, no, I see a problem. When you use string variables in functions you need to add EVAL for the function to evaluate their contents. Right now your sphere list is not resolving, do FnP is defaulting to giving you a pre-set group of spheres.  (Which, it’s good to know the backup plan is working well!)

So I would try this:

1. Replace

STR_VAR
      clab_name     = ~%kitid%~
      class         = ~%fnpclass%~
      sphere_list   = ~%fnpdeity%~

with

STR_VAR
      clab_name     = EVAL ~%kitid%~
      class         = EVAL ~%fnpclass%~
      sphere_list   = EVAL ~%fnpdeity%~

...

EDIT 2 - ah, you're totally right about that condition in the MnG ranger kits - those were a bad example, sorry about that. They are weird because those kits also exist in FnP itself, so there is an implied assumption that they will be installed after the sphere system when you get to  them in MnG. Those kits existing in two places is one of the things I am  sorting out in the new update.

A better example I should have pointed you to would be the Loresinger cleric/thief kit in MnG. That kit works just as you say:

//DEFINE SPHERE ACCESS_______________________________________________________________
//
LAF ~DEFINE_FNP_KIT_INFO~
  STR_VAR
    clab_name    = ~d5_lors~
    class        = ~cleric~
    sphere_list  = ~milil_spheres~
END

LAM ~READ_FNP_KIT_INFO~

ACTION_IF FILE_EXISTS_IN_GAME ~d5__spheres.d5~ BEGIN
  LAF apply_fnp_spheres STR_VAR clab_name = ~d5_lors~ END
END

ACTION_IF FILE_EXISTS_IN_GAME ~d5__fnp_usability.d5~ BEGIN
  LAF apply_fnp_usability STR_VAR clab_name = ~d5_lors~ END
END

Still need to EVAL those variables, though. (Unless you use  AUTO_EVAL_STRINGS across your whole mod, I guess.)

Edited October 20, 2022 by subtledoctor

[subtledoctor]

Also, worth noting that the  compatibility code doesn't work with FnP's spontaneous casting option. That's also  something I'll (hopefully) address in the new update. Though, I'm not sure anyone is actually using that...

So, notes to self:

• Make sure sphere_list variables work with different sphere systems work when applied before the sphere system is installed.
• Add support for spontaneous casting to compatibility code.

[Dan_P]

I forgot to ask about the spontaneous casting. I've never actually used those options in your mods. I just stick to standard casting, but that's good to know.

I knew about EVAL for functions. I was already using AUTO_EVAL_STRINGS. I have it working smoothly now, in terms of compatibility with the spheres (tested with different sphere options).

[subtledoctor]

15 minutes ago, Dan_P said:

I forgot to ask about the spontaneous casting. I've never actually used those options in your mods. I just stick to standard casting, but that's good to know.

I knew about EVAL for functions. I was already using AUTO_EVAL_STRINGS. I have it working smoothly now, in terms of compatibility with the spheres (tested with different sphere options).

Out of curiosity, did you test with your mod being installed before any sphere system?

[Dan_P]

Works both before and after. I have 2 paladin, 2 ranger, and 1 cleric kits, and they all get correct spheres either way, based on the sphere_list variable. My sphere_list choices aren't even all from the same class as the kit.

 

Usability is another thing. You might want to take a look at the apply_fnp_usability function. I don't think it works right when installed after FnP, at least when using the sphere_list variable. The usability of the kits look like this:

Spoiler

In addition, every kit gets a spl file that restricts a bunch of items, like this one given to a paladin kit: d5_u135.spl

I just removed this function if the mod is installed after FnP, which leaves usability untouched. I'm already handling usability and certain itemtype restrictions in my own files.

[subtledoctor]

31 minutes ago, Dan_P said:

Works both before and after. I have 2 paladin, 2 ranger, and 1 cleric kits, and they all get correct spheres either way, based on the sphere_list variable.

Sweet! Looks like I made this work right the first time. I  guess can cross "fixing" it off my list!

32 minutes ago, Dan_P said:

Usability is another thing. You might want to take a look at the apply_fnp_usability function. I don't think it works right when installed after FnP, at least when using the sphere_list variable

Best I recall, the usability function doesn't work with the sphere list variable. I see that the compatibility instructions imply that it  does... which means  either 1) I intended to make that work, but never got around to it; or 2) it does work with the variable and I'm misremembering things?

35 minutes ago, Dan_P said:

In addition, every kit gets a spl file that restricts a bunch of items, like this one given to a paladin kit:

That is intended - we went into the proficiency/usability area with a decision to follow the game's conventions: when thieves cannot be proficient in a weapon, they also cannot use the weapon. Ditto for clerics and druids etc. - inability to become proficient almost always means you cannot equip the weapon. So the mod programmatically makes a spell for each kit with op181 effect barring the use of item types of any weapons that have '0' in the item use variable in the DEFINE_FNP_KIT_INFO function.

BUT if you don't specify any of those variables it should apply the default set for the class. AND that's only supposed to happen with clerics and druids - paladins and rangers are exempted from the item use code, they can already use everything anyway. Unless, maybe...

2 hours ago, Dan_P said:

My sphere_list choices aren't even all from the same class as the kit

The %sphere_list% variable doesn't matter - you can freely tell the function that your paladin should get druid spheres. But the %class% variable might be more sensitive. For this, you should not use a value that is different from the actual class.

So something is weird. It's possible the compatibility code is outdated and needs to be updated to make sure it doesn't touch warrior classes. Probably just needs some cutting and pasting from the FnP code, which is working as intended. (In my current game I have a bunch of paladin and ranger kits, and none of them re affected by this.)

I am also in the process of adding an .ini option  that will preclude the mod from applying those op181 effects, and instead just let all priests equip all weapons, and only let the function govern their proficiency.

EDIT - also btw 16777216 equals 0x01000000, which is the Helm kit flag value, which means, IIRC, that chain mail is usable but plate is not. So that's actually working as intended. But again, it is only supposed to affect clerics and druids, not warriors. I'll take a look at it and fix what needs fixing.

[subtledoctor]

God, is there anything worse than the "found EOF, but expected END" parse error?  "Just go ahead and comb through every character in the prior 4,000 lines of script and try to find where it's missing." Rather poke my eyeballs out, thankyouverymuch.

[subtledoctor]

@Dan_P try substituting this file for your compatibility file. It should solve  the  item usability issues.

fnp_compatibility.tpa

[Dan_P]

Thanks. I'm just confirming that the updated file fixes the usability issues I was getting.

[subtledoctor]

Excellent. It will be in the next update. 

Which will happen in about ten years, when I figure out this stupid parsing error. 

[subtledoctor]

Okay I’ve put together an alpha version of v85. Changes here:

• No rangers ! Rangers are completely removed. They will be in Might & Guile (but they are not there yet).
• -New versions of paladin kits. Instead of ~9 Champions in the paladin class and ~9 Zealots in the ranger class, there are now 20 Champion kits, all in the paladin class. There are three archetypes or templates for this class: Defenders, Inquisitors, and Zealots. Each kit will be able to choose from among 1-3 of the templates. Which kit can use which template is controlled in the .ini settings. (At some point we might add templates in the ranger class, but that will take s bit more work.)
• The FnP paladin spell table is its own component. 
• If using the revised item usability, kit descriptions will specify which weapons are usable. 
• There is a new .ini configuration option to use a milder version of the item usability component, which allows priests to equip most weapons, but only be proficient in the ones specified for the kit. 
• The newly added FnP spells from b_spells use ADD_SPELL less. (But still a little bit.) 

Edited October 22, 2022 by subtledoctor

[Quester]

You deserve a cookie for all your hard work.

[Quester]

Getting this install error for some kit on v84:

Spoiler

//Copying and patching 1 file ...
//ERROR: COPY ~.../a7-add_kit_ex/inlined/QD_MC_GA.EFF~ ~override/****#.EFF~ FAILED: cannot open target
//Stopping installation because of error.
//ERROR: [A#REDF.2da] -> [override/A#REDF.2da] Patching Failed (COPY) (Sys_error("override/****#.EFF: Invalid argument"))
//Stopping installation because of error.
//Stopping installation because of error.
//Stopping installation because of error.
//Stopping installation because of error.
//Stopping installation because of error.
//Stopping installation because of error.
//Stopping installation because of error.
//Stopping installation because of error.
//kit skipped

 

[subtledoctor]

44 minutes ago, Quester said:

Getting this install error for some kit

Looks like that kit has a malformed .2da table? Try opening a#redf.2da and see if it has anything weird like an entry that says “GA_****” or something. 

[subtledoctor]

Hey @Dan_P just want to let you know that I've been working on inter-mod compatibility while making updates to both this and Might & Guile, and the compatibility code has been updated a bit. The new version of the compatibility file that you can use with your mod is here. It provides compatibility with a few things:

• The spontaneous spellcasting option, starting in FnP v0.85
• The ability for kits to declare their weapon usability, which will also begin in FnP v0.85.

This new version is generally backwards-compatible with the various 0.83 and 0.84 builds of FnP, in all ways except for those two features.

Here is what the code now looks like for rangers in Might & Guile:

//DEFINE SPHERE ACCESS______________________________________________________________
//
INCLUDE ~%MOD_FOLDER%/lib/fnp_compatibility.tpa~

LAF ~DEFINE_FNP_KIT_INFO~
  STR_VAR
    clab_name       = ~d5rdes~
    sphere_list     = ~desert_ranger_spheres~
    class           = ~ranger~
END

LAM ~READ_FNP_KIT_INFO~

ACTION_IF FILE_EXISTS_IN_GAME ~d5__spheres.d5~ BEGIN
  LAF apply_fnp_spheres STR_VAR clab_name = ~d5rdes~ END
END

ACTION_IF FILE_EXISTS_IN_GAME ~d5__fnp_usability.d5~ BEGIN
  LAF apply_fnp_usability STR_VAR clab_name = ~d5rdes~ END
END

ACTION_IF (FILE_EXISTS_IN_GAME ~d5__fnp_spont_option.d5~) AND (FILE_EXISTS ~faiths_and_powers/lib/system_fnp_spontaneous.tpa~) BEGIN
  ACTION_IF (FILE_EXISTS ~faiths_and_powers/language/%LANGUAGE%/fnp_spontaneous.tra~) BEGIN
    OUTER_SPRINT spont_lang ~%LANGUAGE%~
  END ELSE BEGIN
    OUTER_SPRINT spont_lang ~english~
  END
  ACTION_IF (FILE_EXISTS ~faiths_and_powers/language/%spont_lang%/fnp_spontaneous.tra~) BEGIN
    WITH_TRA ~faiths_and_powers/language/%spont_lang%/fnp_spontaneous.tra~ BEGIN
      INCLUDE ~faiths_and_powers/lib/system_fnp_spontaneous.tpa~
      LAF fnp_spontaneous STR_VAR kit_clab = ~d5rdes~ learn_res = ~d5rdesz~ END
    END
  END
END
//__________________________________________________________________________________

That spontaneous casting code is a bit of a mouthful, admittedly, but you can just copy and paste it, all you need to change is the "kit_clab" string and the "learn_res" string. (NOTE: the "learn_res" string can only be 7 characters long! In FnP we mostly use 6-character clab files and add a 'z' for this string. You don't have to use the same convention, but just be aware of the 7-letter length limit there.)

Of course if you don't care about the spontaneous casting option, you can just omit that whole chunk.

Edited October 26, 2022 by subtledoctor