Jump to content

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


Recommended Posts

Here's the situation: I'm working on creating a sphere system for priests. It applies sphere access to kits via their CLAB.2da files. I'd like to make it super-easy for other modders to create kits that my system can recognize and I corporate into the system.

So, I'm contemplating telling modders to include a text file with their kit, with the same name as their CLAB but with my modding prefix as the extension. So e.g. if their kit uses "mykit.2da" as the CLAB, then they would include another file called "mykit.d5" and copy it into the override directory with the kit.

The content of the file would be a Weidu copy command indicating which spheres the kit should have access to:

COPY_EXISTING ~mykit.2da~ ~override~
   APPEND ~sphere_system/major_access_protection.txt~
   APPEND ~sphere_system/minor_access_earth.txt~

That file would sit in the player's override directory waiting for my sphere system kid to be installed. When my mod sees mykit.2da, it will then look for mykit.d5, copy it out of the override folder to a temp directory as a .tpa file, and then run it -

COPY ~override/mykit.d5~ ~sphere_system/temp/mykit.tpa~

INCLUDE ~sphere_system/temp/mykit.tpa~

That will append my sphere spells into the kit's CLAB and boom! it's in the system.

I'm not asking for advice on how to do it - I have it working. I'm asking whether it is somehow dangerous or stupid to have those .d5 files in a player's override folder.


Link to comment

And you can't say to people to please, copy the file to a custom folder that is not in the override folder, say to like sphere_system/permanent/ -folder, that the mod can use to include during the installation, why ?

That would be the best approach "in my honest opinion".


The override folder is rarely not dealt with mods that do not, and the ones that do usually do, should have good coding to not die if you put unspecified file in it, but there's always someone that will try to compile all it's content while they intent to compile things into it. As it's a really small coding mistake.

Now the Generalized bBiffing actually had to deal with all the files in the override folder, and it sets the files that cannot be biffed into it's own folder, .txt file and others, so knowing this, you might also with so avoid the unassociation factor that biffing before installing your mod might bring. And in my opinion, your best bet is to do that by setting the permanent folder (you read the above about this).

Link to comment

And you can't say to people to please, copy the file to a custom folder that is not in the override folder, say to like sphere_system/permanent/ -folder, that the mod can use to include during the installation, why ?

Because the sphere system will not be installed - maybe not even downloaded - until after the other guy's kit mod. So "/sphere_system/whatever/" will not exist yet. I assume nothing.


Essentially I'm telling other modders, "if you want to glom onto my sphere system, drop this seed into the game, and if the player decides to *use* my sphere system, the system will find your seed and make the two mods work together correctly."


The override folder is looked out by most mods, but there's always someone that will try to compile all it's content while they intent to compile things into it. As it's a really small coding mistake.

Yes, I'm aware of that mistake, it's very common. That's why I'm asking. If someone COMPILEs the whole override folder and there's a text file that says

COPY_EXISTING ~myclab.2da~ ~override~
APPEND ~spheres/this_text.txt~
... will that Weidu command run or something?


There's another at I could do this, by telling other modders to put actual lines of a CLAB file into the text file, and then my mod would come along and do the APPENDing. But this is much cleaner - how easy is it for a modder to just say


"APPEND ~major_access_protection.txt~"


when they want their kit to have major access to the Protection sphere?


Maybe the text file could only contain the APPEND lines... then I could read that file and APPEND it to a .tpa file of my own, and then INCLUDE the .tpa... that way there's no executable commands hanging around the override folder.

Link to comment

Essentially I'm telling other modders...

This is exactly like with the Worldmap mod, and the mods themselves add files to one of the Worldmap/ -subfolders, append files if they exist etc, even when the Worldmap mod itself is not installed (nor extracted yet), if it ever will be, as normally it has to come last. Code from BGT-weidu v1.18:

ACTION_IF FILE_EXISTS ~worldmap/map_mods_areas.tbl~ THEN BEGIN
  COPY ~worldmap/map_mods_areas.tbl~  ~worldmap~
    APPEND_FILE ~bgt/worldmap/areas.tbl~
  COPY ~worldmap/map_mods_links.tbl~  ~worldmap~
    APPEND_FILE ~bgt/worldmap/links.tbl~

  //preliminary step - making LANGUAGE temporary file until the new WeiDU
  COPY - ~bgt/worldmap/%LANGUAGE%/worldmap.tra~  ~tmp_worldmap.tra~
  COPY ~worldmap/map_mods_trans.tra~  ~worldmap~
    APPEND_FILE ~tmp_worldmap.tra~
  MKDIR ~worldmap~
  COPY ~bgt/worldmap/areas.tbl~ ~worldmap/map_mods_areas.tbl~
  COPY ~bgt/worldmap/links.tbl~ ~worldmap/map_mods_links.tbl~
  COPY ~bgt/worldmap/%LANGUAGE%/worldmap.tra~ ~worldmap/map_mods_trans.tra~
  COPY ~bgt/base/map~ ~override~
Note that the BGT itself overwrites the current .wmp file becuase it has to in the second to the very last line, but it also includes .tbl files earlier when they do not exist yet, and appends then if they do, which probably contains all the info the (BP-BGT-)Worldmap mod needs to append the created file(as you have to overwrite the .wmp and then patch it).


You yourself can of course set up the needed files and example in what ever way you wish... the easier it is to proceed with the adding of the feature, the likelier it is that it will be featured in the other kit mods.

Link to comment

Yeah but look at all that - it's complicated. I don't want to ask other modders to think too hard or do my job for me. Just, essentially, list out the spheres they want their kit to have access to, and leave the list where I can find it so I can do the work of parsing it and implementing it.


I think a text file, with a nonsense extension like .d5, and with just a few lines that say

should be pretty safe. Lynx knows his stuff, if he says it's safe I trust him.


sounds fine to me. But if only the 2da name will change, why not just have them append to a table you then read?

I'm not going to change the name of the .2da file, rather, I will add my stuff to it. I want these hypothetical other modders to name the "seed" file the same as the .2da because I'll detect it from kitlist.2da, and then I'll use the contents of the seed file to guide how I edit their .2da file.


I could tell people "if you want to join the sphere system, provide an alternate .2da file and I'll rename to be the one that gets used... but even that is asking too much. I want this to be as drop-dead-simple for them as possible.

Link to comment

Make it a function, then you can keep the back end to yourself. When I was trying to update Divine Remix, I was going to do exactly that - provide a function that updates a table in override, then runs the sphere code if sphere system has been installed. This way it would have worked regardless on the install order.

Link to comment

Wait - just so I understand, by "make it a function" do you mean drop an actual .tpa file in the override folder? Then the kit mod itself can check and say "if the sphere system is already installed, run this function and join it," in case the kit is installed later; and the sphere system can say "if that kit mod is installed, run the function it left in the override folder so it can join the system," in case the kit was installed first.


That's very elegant, and like I say it would be super-simple for other modders to exercise the option. I just wanted to make sure I'm not playing with fire. Thanks guys!

Link to comment

I'd avoid dropping code into override, unless you make it check for its version before overwriting itself. A simpler option is to ACTION_TRY (or what have you) load the install code from your mod's folder path - this way, if you ever update the code, you won't need to worry about shipping it across the globe and into other mods' packages.


So, after a bit of thought, I see it like this - one func to append/alter the spell table, and another one to install it. In tp2 it may look like this:


Launch Function "append/alter the spell table in override" "spell1"

Launch Function "append/alter the spell table in override" "spell2,spell3,spell4,etc"
(at the end of component)
Launch Function "install sphere changes (load code from subltedoctor/spheres/code path"
Sure it's also possible to install changes immediately, but if it's made able to re-install itself multiple times, then this potentially may add up some installation time. Although modern CPUs are sufficiently fast, so...
A bit of advice, though - there's a good chance it will require much more intricate code (comparative to most mods) than you may anticipate, if you want a robust platform that can handle re-installations, Cleric/Ranger multiclass headache, alignment exclusions etc.
Link to comment

A bit of advice, though - there's a good chance it will require much more intricate code (comparative to most mods) than you may anticipate, if you want a robust platform that can handle re-installations, Cleric/Ranger multiclass headache, alignment exclusions etc.

Are you referring just to the idea of aiding integration by other mods? Or the whole idea of a sphere system itself?

Link to comment

Probably a bit of both... Back few years ago I was tasked (ultimately unsuccessfully) with updating Divine Remix code, not in the least to fix the compatibility issues. So, I ended up with "spell name => sphere list" and "kit => sphere access" tables, with everything else handled automatically by code (reading MXSPLPRS.2DA, NPC spellbook patch, removal of non-allowed spells upon level-up etc.). That everything's ended up slightly more complex than an average Wei-fu mod.

Not trying to dissuade you or anything, just saying you're about to step into big forest :D

Link to comment

Yeah, I know. There's a lot of stuff that just won't be included at first. I don't have a method to read mxsplprs.2da and change the for of my CLAB-appended text, so instead, for now, we'll probably just overwrite that file with our own version.


Non-joinable NPCs will not have their spellbooks patched, for the first version it will just be too complicated. They'll be able to cast whatever spells the game already gives them, for 'reasons.' Joinable NPCs can be handled, they are a manageable group.


Spell alignment restrictions will mostly be eliminated. If you have access to the Affliction sphere you'll be able to cast Wither, whether you're good or evil.


So it will start out pretty basic, and my Weidu techniques are far, far less advanced than the stuff in DR. But for now I'm counting that as an advantage - it's not so simple that it doesn't work, but it's simple enough that it's easy to work with.


I already have it giving correct sphere access to kits that specify it, and giving arbitrarily-defined default access to unkitted priests and mod kits that don't opt in. It already does a bunch of spell conversions to fill out the spheres. Every sphere has 1-2 spells per level so balancing is going to be as simple as "give every kit minor access to 12 spheres and major access to 6 of them." The next step is working on spell description patches - the vanilla spells uselessly list their PnP spheres so I'll have to do text replacements to make them correctly show my spheres. But that's totally doable, it'll just need some clever regexp work.


For v1 that will basically be it - a working, if simple, sphere system that doesn't break other mod kits. Right now that doesn't really exist. (I love DR but it's a bit in limbo atm.) Later, we can add and refine features.

Link to comment

Okay, here's something that isn't working. I have made an associative array of priest spells, like so:

//1st digit = sphere, 2nd digit = spell level
SPPR101 => 11  // bless
SPPR203 => 12  // chant
SPPR316 => 13  // prayer
SPPR307 => 13  // remove curse
SPPR417 => 13  // lesser restoration
SPPR421 => 14  // recitation
SPPR518 => 15  // righteous wrath of the faithful
SPPR504 => 15  // raise dead
SPPR601 => 16  // aerial servant
SPPR612 => 16  // bolt of glory
SPPR710 => 17  // holy word
SPPR715 => 17  // unholy word
SPPR713 => 17  // greater restoration

Then I would like to use this to populate a spell that uses opcode 171 to add the proper spells to the player (also change the level if necessary for balancing purposes, and edit the spell's description). I have base spells with a 171 effect adding Grease; I want use CLONE_EFFECT to add new effects adding any relevant spells from that associative array. So I write this:

ACTION_PHP_EACH spellsphere AS spl => sph BEGIN
   ACTION_IF (%sph% = 11) AND (FILE_EXISTS_IN_GAME ~%spl%.spl~) BEGIN
      COPY_EXISTING ~%spl%.spl~ ~override~     
         WRITE_LONG 0x34 1
         READ_LONG 0x50 "valid"
         PATCH_IF (%valid% >= 0) BEGIN // verify desc is valid
            READ_STRREF 0x50 ~desc~
            INNER_PATCH_SAVE new_desc ~%desc%~ BEGIN
               REPLACE_TEXTUALLY ~^Level:.*$~ ~Level: 1~
               REPLACE_TEXTUALLY ~^Sphere:.*$~ ~Sphere: Divine Aid~
            SAY_EVALUATED 0x50 ~%new_desc%~
      COPY_EXISTING ~d5phdiv1.spl~ ~override~
         LPF CLONE_EFFECT INT_VAR match_opcode=171 STR_VAR match_resource=~SPWI101~ resource=~%spl%~ END

So that captures any 1st-level spells in the array that are designated as being in the Divine Aid sphere. It sets the spell's level to the one in the array, and updates the spell's level and sphere in its description. But the last bit doesn't work. When I look at d5phdiv1.spl after installing the mod, it has a 171 effect with "%spl%" in the resource field instead of "SPPR101." Can I pass the variable %spl% from the ACTION_PHP_EACH into the CLONE_EFFECT function?

Link to comment


This topic is now archived and is closed to further replies.

  • Create New...