Leaving a file with Weidu commands in /Override...?

[subtledoctor]

Just want to leave a note to say that I have now implemented this, in what I think is an acceptable way... kit mods that want to hook into our sphere system can copy over a file with a ".d5" extension to the override folder, which should hopefully be seen as meaningless by the game and the filesystem. The .d5 file will look like this:

 

 

 

// kit sphere access

// you can use the following terms in the right column to define access:

// - focus
// - major
// - minor
// - paladin
// - ranger

ACTION_DEFINE_ASSOCIATIVE_ARRAY EVAL ~d5_%fox%_spheres~ BEGIN

Life             => x
Death            => x
Divine_Aid       => x
Destruction      => x
Protection       => x
War              => x
Knowledge        => x
Deception        => x
Thought          => x
Dread            => x
Vigor            => x
Affliction       => x
Animal           => x
Plant            => x
Earth            => x
Water            => x
Air              => x
Fire             => x
Light            => x
Shadow           => x
Magic            => x

END

 

 

Then our mod will com along, look for any files like this with the .d5 extension, copy them to give them a .tpa extension, INCLUDE the .tpa file, and then give sphere access to the mod kit based on the contents of the array. Simple!

 

And even if Weidu or a mod or the game somehow trigger the execution of that code... all it will do is create an associative array. That shouldn't be able to harm anything. (I suppose if it somehow gets triggered by a mod installer and %fox% is not defined, that could cause an install error for that mod... so maybe I should put the whole thing into an ACTION_TRY block...?)

 

(Note to self, learn how ACTION_TRY works...)

[Mike1072]

Not that this isn't going to work, but it still seems like a "wiser" idea to have other mods put this data into a .2da-like file that your mod would read.

 

Also, there is no need for you to copy this to a .tpa because file extensions don't matter.

[subtledoctor]

Yeah that would definitely be wiser... I just don't know how to do it. (Yet. Maybe I will by the time we release the mod.)

 

Good to know about extensions, if I can INCLUDE a .d5 file that's one less step and one less file in /override.

[subtledoctor]

So, I'm updating the thread because I've reached a final-ish version of this document, and I want to take suggestions for improvement before we release the mod and this gets harder to change.

 

Here is a draft of the document that our mod uses for cleric kits right now:

 

 

ACTION_TRY

ACTION_DEFINE_ASSOCIATIVE_ARRAY EVAL ~d5_%fox%_race~ BEGIN

//... RACE FOR DEITY:_______________________________________________________________
// you can use the following terms to define the deity's racial association:
// - all, human, elf, dwarf, gnome, halfling, orc
//
Race			=> all
//__________________________________________________________________________________

END

ACTION_DEFINE_ASSOCIATIVE_ARRAY EVAL ~d5_%fox%_class~ BEGIN

//... CLASS/ARCHETYPE:______________________________________________________________
// enter "yes" next to whichever archetype(s)/class(es) should represent the kit
//
cleric			=> yes
acolyte			=> x
fighter_cleric		=> x
cleric_mage		=> x
cleric_thief		=> yes
ranger_cleric		=> x
f_m_c			=> x
//mystic		=> x
//druid			=> x
//occultist		=> x
//mystic_fighter 	=> x
//champion		=> x
//inquisitor		=> x
//zealot		=> x
//ranger_1		=> x
//ranger_2		=> x
//ranger_3		=> x
//__________________________________________________________________________________

END

ACTION_DEFINE_ASSOCIATIVE_ARRAY EVAL ~d5_%fox%_spheres~ BEGIN

//... SPHERES:______________________________________________________________________
// you can use the following terms in the right column to define sphere access:
// - focus, major, minor, paladin, ranger
//
Life			=> major
Death			=> x
Benediction		=> major
Destruction		=> minor
Protection		=> major
War			=> x
Knowledge		=> minor
Deception		=> minor
Thought			=> major
Dread			=> minor
Vigor			=> minor
Affliction		=> x
Animal			=> x
Plant			=> x
Earth			=> x
Water			=> x
Air			=> major
Fire			=> x
Light			=> major
Shadow			=> x
Magic			=> minor
//__________________________________________________________________________________

END

WITH
  DEFAULT
	PRINT ~Could not link to Faiths & Powers sphere system~
END

 

 

It defines 3 associative arrays, and wraps them inside an ACTION_TRY block. One of these will be added to /override for every priest kit that participates with our mod's sphere system and/or its kit-choice-by-dialogue system. (%fox% is keyed to the kit's "CLAB.2da" filename.

 

I *think* this is pretty safe; if it gets called somehow and the variable is undefined, or there is another problem, the the ACTION_TRY should result in a simple failure message being displayed. And it if it *successfully* called, somehow, then it will simply define a couple of arrays.

 

I'm pretty well tied to using arrays for this, since switching over to a .2da format would result in rewriting a substantial amount of code. I tried wrapping the whole shebang in

DEFINE_ACTION_FUNCTION EVAL d5_%fox%_spheres

and launching it from Weidu with

LAF EVAL d5_%fox%_spheres

...but I could not get it to work.

 

We have a few more days before we go to press, so if anyone has suggestions for further insulating this, I'd love to hear them. (E.g. I though about maybe using APPEND_OUTER to build the arrays in a file in the mod folder instead of override, and then INCLUDE them from there... but then each kit would need 3 separate documents for the race info, the class/kit info, and the sphere info. I want other mods to be able to drop a single, simple document into override and have our code find it and use it to work them into our system. Right now that is accomplished really really nicely.

[Mike1072]

This solution is probably fine, but if the only reason you're choosing this over a 2da system is because you don't know how to code it, I can assure you it is not at all complicated. I'd be happy to give an example.

[subtledoctor]

Well, I assume it would be some variation of

FOR (row += row)
  READ_2DA_ENTRY row 1 2 X
  READ_2DA_ENTRY row 2 2 Y
  PATCH_IF (~Y~ STRING_EQUAL_CASE ~string~) BEGIN
    INNER_ACTION BEGIN
      [do something with X]
...

Aside from the issue that this might necessarily involve a

PATCH_IF
  INNER_ACTION
    COPY
      PATCH_IF
        INNER_ACTION

... which just seems weird... the biggest issue is the time it would take to plug something like that into the mod in various places and troubleshoot and debug everything. My window of free time to spend on this stuff is closing with alarming speed.

 

But on the other hand once this is decided, it will be difficult to change in the future. That's why I'm so hesitant - I don't want to make the decision lightly.

[subtledoctor]

Thinking more about this... the main issue is, how does our mod find the arrays for kits installed by other mods?

 

Maybe we can instruct mods to put the files with the arrays in a designated subfolder in their mod folder. They can drop a very simple .2da file into /override, which will simply contain the name of their mod folder (so we can find it). Then our code will look in the mod folder, look in the designated subfolder, and INCLUDE the arrays found there.

 

This imposes more of a burden on other mods, and imposes risk of failure if the player deletes the other mod folder between installing it and installing our mod. But those issues seem pretty minor. And this would involve almost no change to our existing, working code.

[Mike1072]

Here's an example of what I'm talking about. There's a couple of files there that you can distribute to kit mods. Using them, they'll just need to invoke a function to provide the info that your mod needs. The function does some validation to make sure the entered info is valid and then it appends to .2da files in the override.

 

There is a macro included for use in F&P that reads from these .2da files and sets a number of variables that you can access similar to the way you access them now.

 

http://mike.vihc.net/bg/FNPTest.zip

[subtledoctor]

It's taking me some time to digest this. It looks like, this creates three .2da files in /override, and each kit that opts in to the system appends the relevant information to the relevant .2da file. So by the time our mod runs, those three files will contain information for every compatible kit in the game.

So far, cool. Then our mod would read those files and... hmm.

Does

TEXT_SPRINT $d5_fnp_kit_class_access(~%class%~ ~%kit%~) ~%access%~

create an array for

~%class%~ , ~%kit%~ => ~%access%~

?
In other words we would make an array from a single row of the .2da file? And that array would be wiped and redefined for each successive row?

So it would be something like (psuedocode)

ACTION_PHP_EACH [iterate through cleric kits]
  LAM ~READ_FNP_KIT_INFO~
  ACTION_PHP_EACH d5_kit_race_access AS race => access BEGIN
    [set race information]
    ACTION_PHP_EACH d5_kit_class_access AS class => access BEGIN
      [do class stuff - trust me, you really don't want to see this code]
    END
  END
END

I suppose I could slot this in... I think. The one thing that's missing is an easy way to assign default spheres to any kits that have not opted in to the system - they are supposed to get spell access comparable to the vanilla game (as close as the sphere system can approximate it). I guess I would read the .2ds files to see if the kit exists in the kit column, and run ~DEFINE_FNP_KIT_INFO~ if it's not there.

And, the most important thing, what does this ask of other mods, how easy is it to opt in? We would basically tell them:
"1) drop the contents of this '/lib' folder into a '/lib' folder in your mod
2) INCLUDE fnp_compat.tpa and run LAF ~DEFINE_FNP_KIT_INFO~

Okay, I think I can work with this. Integration will take a while... meantime I'll point Grammarsalad and Aquadrizzt here and see what they think.

[Mike1072]

Take a look at the coding for the DISPLAY_FNP_KIT_INFO function at the bottom of fnp_compat.2da to see how you might want to access the data retrieved by the READ macro. The macro only needs to be executed once beforehand.

 

The SPRINT lines you referred to set the values of individual variables. Because the array construct was used, the variables can be iterated over later with PHP_EACH.

[subtledoctor]

Got it.

 

What's the most reasonable way to look for kits that have *not* opted in to the sphere system, and apply default spheres? Running the READ function and then a variation of the DISPLAY function and then iterating through the %kit% variables sounds like overkill. And will require it all be done again after the new lines are added to the .2da file.

 

Maybe something like (iterating through %each_kit%)

COPY_EXISTING ~d5_sphere.2da~ ~override~
  ACTION_IF NOT FILE_CONTAINS ~%each_kit%~ BEGIN
    LAF DEFINE_FNP_KIT_INFO
...etc.

?

[Jarno Mikkola]

What's the most reasonable way to look for kits that have *not* opted in to the sphere system, and apply default spheres?

This totally depends on what you wish the sphere system rules to do ?

You could make the ones that have not opted to include themselves to it to give ALL the spells to them, but with less spell charges, have no innate abilities, no metamagic spells, whatever. Meta magic, like Cure Medium Wounds at level 2(as the vanilla spell is a 3rd level spell) for a kit specially kitted as a healer.

 

It all depends on your balancing the effects.

[Mike1072]

Got it.

 

What's the most reasonable way to look for kits that have *not* opted in to the sphere system, and apply default spheres? Running the READ function and then a variation of the DISPLAY function and then iterating through the %kit% variables sounds like overkill. And will require it all be done again after the new lines are added to the .2da file.

 

Maybe something like (iterating through %each_kit%)

COPY_EXISTING ~d5_sphere.2da~ ~override~
  ACTION_IF NOT FILE_CONTAINS ~%each_kit%~ BEGIN
    LAF DEFINE_FNP_KIT_INFO
...etc.

?

 

 

Something like that could work. You could also define these values once for a dummy D5DEFAULT kit and then use those values for any kits that didn't opt in to your system.

    ACTION_IF (VARIABLE_IS_SET $d5_fnp_kit_race_access(~%kit%~)) BEGIN
      OUTER_TEXT_SPRINT race $d5_fnp_kit_race_access(~%kit%~)
    END ELSE BEGIN
      OUTER_TEXT_SPRINT race $d5_fnp_kit_race_access(~D5DEFAULT~)
    END

etc.

[subtledoctor]

Hmmmm... that looks nice and easy... but I think it might choke on the HLA system. No, I think each kit, even those with default access, needs its own row in the.2da files.

 

On the other hand, since those .2da files are just a roundabout way to generate my three associative arrays, I suppose for default kits I could do it the old-fashioned way and define the arrays by hand. The .2da files are really only needed specifically for *other mods* to tie in to the system.

 

(EDIT - right... but then I still need to be able to identify whether they are already in the .2da table...)

 

Damn, I'm away from my computer for a few days. It's so hard to picture how this stuff comes together when you don't have the code in front of you.

[subtledoctor]

Okay. Man, took me a while to wrap my head around that.

 

My *one* nit pick is that I would prefer not to force modders to type their kit's CLAB name into the function; I'd prefer to pick it up automatically somehow. But given the design of these functions, I'm not sure it's possible. (And I guess in my old way, they would still have to type it, in the name of the .d5 file. So I guess the risk of typos is there either way.) EDIT: see below

 

I've got it working with the sphere system and the HLA system. Now I need to see if I can work it into the deity-dialogue-generation system. Which is more complicated... but on the other hand the hardest part so far was the basic comprehension of what I was looking at. So I should be able to make it work.

 

Then, assuming we adopt this method, I'll just have to change ~40 kits over to this format. ("What's that, honey? Netflix tonight? No thanks, I'm going to sit over here and make my eyes bleed a bit more.")

 

------------------------

 

I think I've figured out the CLAB thing. Every mod kit will occupy the last row in kitlist.2da at the time it is installed. So modders can put something like this in their code right after the ADD_KIT routine:

COPY_EXISTING ~kitlist.2da~ ~override~
    COUNT_2DA_ROWS 1 rows
    READ_2DA_ENTRY rows 5 1 ~clab~
BUT_ONLY
ACTION_INCLUDE ~faiths_and_powers/lib/fnp_compat.tpa~
LAF ~DEFINE_FNP_KIT_INFO~
  INT_VAR
    c_cleric         = 1
    c_cleric_thief     = 1
  STR_VAR
    clab_name = EVAL ~%clab%~
    race             = ~all~
    s_life             = ~major~
    .....

 

EDIT - see below for better code.

One less thing for them to do = easier cross-mod compatibility and more fun!

 

EDIT 2 - except, that didn't work. To quote a wise man: what gives?

 

EDIT 3 - This works. Nice!

COPY_EXISTING ~kitlist.2da~ ~override~
    COUNT_2DA_ROWS 1 rows
    READ_2DA_ENTRY (%rows% - 1) 5 1 clab
BUT_ONLY
ACTION_INCLUDE ~faiths_and_powers/lib/fnp_compat.tpa~
LAF ~DEFINE_FNP_KIT_INFO~
  INT_VAR
    c_cleric         = 1
    c_cleric_thief     = 1
  STR_VAR
    clab_name = EVAL ~%clab%~
    race             = ~all~
    s_life             = ~major~
    .....