WeiDU questions

[Miloch]

From the development wiki:

The following self-explaining tp2 code will automatically perform all EXTEND_TOP, EXTEND_BOTTOM, REPLACE_BCS_BLOCK actions for you.

COPY ~nalia_romance/extend_bottom~ ~nalia_romance/extend_bottom~
 SPRINT file ~%SOURCE_RES%~
 INNER_ACTION BEGIN
EXTEND_BOTTOM ~%file%.bcs~ ~nalia_romance/extend_bottom/%file%.baf~
 END
BUT_ONLY_IF_IT_CHANGES

Currently used for: Developed for the (later dropped) resurrection of Arnel's Nalia Romance by Bigg

Please note that WeiDU v188 will allow to handle this in a somewhat cleaner way.

I kind of suspected WeiDU would now handle EXTENDs in batch, but I don't see it explicitly in the WeiDU doc. What's the syntax? Basically, I want to tack a bunch of snippets onto similarly-named area scripts, or create them if they don't exist (probably doing EVALUATE_BUFFER for Tutu/BG1 variables while I'm at it).

 

Also, if I want to use any of this stuff (longer than the snippet above) that isn't now a native WeiDU function, I'll just shove it in a .tpa or .tpp (based on whether it's an action or a patch) then INCLUDE or PATCH_INCLUDE it, yeah? Not that the extension makes that much of a difference, but standards and all...

To better differentiate between PATCH and ACTION, *.tph files will 'officially' be renamed *.tpa.

Is there any reason why I would or wouldn't want to include a macro in the tp2, performance-related or otherwise, apart from keeping the tp2 cleaner, and would there be any different types besides those two?

[Nythrun]

ACTION_BASH_FOR ~nalia_romance/extend_bottom~ ~^.+\.baf~ BEGIN
 EXTEND_BOTTOM ~%BASH_FOR_RES%.bcs~ ~nalia_romance/extend_bottom/%BASH_FOR_FILE%~
EVALUATE_BUFFER
 USING SHUT_UP_MODDER.tra
END

is the upgrade the_bigg was referring to.

 

\(ACTION\|PATCH\)_BASH_FOR don't evaluate variables, so if you want multiple directories there's either a dirty hack:

<<<<<<<<extend_bottom_batch.tpa
DEFINE_ACTION_MACRO extend_bottom_batch BEGIN
 ACTION_BASH_FOR ~%directory%~ ~^.+\.baf~ BEGIN
EXTEND_BOTTOM ~%BASH_FOR_RES%.bcs~ ~%directory%/%BASH_FOR_FILE%~
  EVALUATE_BUFFER
USING SHUT_UP_MODDER.tra
 END
END
>>>>>>>>
ACTION_FOR_EACH directory IN
~nalia_by_arnel/extend_bottom~
~nalia_by_jay_cromlech/you_other_brothers_cant_deny~
BEGIN
 COPY - extend_bottom_batch.tpa extend_bottom_batch.tpa
EVALUATE_BUFFER
 REINCLUDE extend_bottom_batch.tpa
 LAUNCH_ACTION_MACRO extend_bottom_batch
END

 

...or being the first kid on your block to use GET_FILE_ARRAY:

ACTION_FOR_EACH directory IN
~nalia_by_arnel/extend_bottom~
~nalia_by_jay_cromlech/you_other_brothers_cant_deny~
BEGIN
 GET_FILE_ARRAY a ~%directory%~ ~^.+\.bcs~
 ACTION_PHP_EACH a AS i => s BEGIN
OUTER_PATCH_SAVE s ~%s%~ BEGIN
  REPLACE_TEXTUALLY ~\.baf$~ ~~
END
EXTEND_BOTTOM ~%s%.bcs~ ~%directory%/%s%.baf~
  EVALUATE_BUFFER
USING SHUT_UP_MODDER.tra
 END
 OUTER_PATCH action_clear_array_yeah BEGIN
CLEAR_ARRAY a
 END 
END

 

INCLUDE can include either patches or actions, but it's an action.

 

External macros are slightly easier for other people to rob borrow, and may come with with a minor parse time upgrade for people installing mods after yours is already installed (you won't notice it with anything this short, however).

[Miloch]

ACTION_BASH_FOR ~nalia_romance/extend_bottom~ ~^.+\.baf~ BEGIN
 EXTEND_BOTTOM ~%BASH_FOR_RES%.bcs~ ~nalia_romance/extend_bottom/%BASH_FOR_FILE%~
EVALUATE_BUFFER
 USING SHUT_UP_MODDER.tra
END

is the upgrade the_bigg was referring to.

Cool, that'll probably work.

 

The "phatter" sort of code raises another question:

  REINCLUDE extend_bottom_batch.tpa
 LAUNCH_ACTION_MACRO extend_bottom_batch

In ordinary circumstances, I wouldn't really need to REINCLUDE unless I were changing the actual macro code, would I? And would one need a LAUNCH_ACTION_PATCH after an INCLUDE, or a LAUNCH_PATCH_MACRO after a PATCH_INCLUDE (i.e., doesn't the INCLUDE execute the code immediately)?

if you want multiple directories there's either a dirty hack

I like phat hacks, I cannot lie...

you_other_brothers_cant_deny

<Insert various sordid EXTEND_BOTTOM-themed lyrics here.>

[the bigg]

I kind of suspected WeiDU would now handle EXTENDs in batch, but I don't see it explicitly in the WeiDU doc. What's the syntax? Basically, I want to tack a bunch of snippets onto similarly-named area scripts, or create them if they don't exist (probably doing EVALUATE_BUFFER for Tutu/BG1 variables while I'm at it).

The improvement was ACTION_BASH_FOR, not a blanket EXTEND_* mydir.

 

Is there any reason why I would or wouldn't want to include a macro in the tp2, performance-related or otherwise, apart from keeping the tp2 cleaner, and would there be any different types besides those two?

It's going to be faster to parse by a zillionth of a second (although in the end it matters when you're installing 60 mods and each tp2 is parsed to look for the component names). Also, clean tp2 = better. In my ideal world, the tp2 should just be an empty skeleton (so that you can more quickly look for a specific component):

BACKUP
AUTHOR

ALWAYS BEGIN
 INCLUDE mymod/lib/always.tpa
END

README
VERSION
// MODDER

OTHER_FLAGS

LANGUAGE

BEGIN whatever
GROUP whatever
SUBCOMPONENT whatever
DESIGNATED whatever
OTHER_FLAGS
INCLUDE mymod/lib/component0.tpa

BEGIN whatever
GROUP whatever
SUBCOMPONENT whatever
DESIGNATED whatever
OTHER_FLAGS
INCLUDE mymod/lib/component0.tpa

 

 

In ordinary circumstances, I wouldn't really need to REINCLUDE unless I were changing the actual macro code, would I?

Yes.

 

And would one need a LAUNCH_ACTION_PATCH after an INCLUDE, or a LAUNCH_PATCH_MACRO after a PATCH_INCLUDE (i.e., doesn't the INCLUDE execute the code immediately)?

It depends on how your INCLUDE is coded. If it contains code, then no LAUNCH_ACTION_MACRO. If your INCLUDEd file contains one hundred of DEFINE_ACTION_MACRO and zero code executed, then you'll need the LAUNCH_ACTION_MACRO otherwise.

[Miloch]

Also, clean tp2 = better. In my ideal world, the tp2 should just be an empty skeleton (so that you can more quickly look for a specific component)

Yeah, that's probably the best way to go, especially for huge multi-component mods like Tweaks. The mods I'm working with tend to have one huge main component and maybe a couple smaller components. So I might end up subdividing the main component for easier editing purposes, not that the players probably would ever notice.

[Miloch]

So I'm using Gort's macros to add a bunch of effects to spells. Let's take Minsc's berserk in BG1, which lacks all the protects and icon blocks that the BG2/Tutu version of the spell has:

COPY_EXISTING ~spin117.spl~ ~override~ //Berserk
 PATCH_IF SOURCE_SIZE > 0x71 BEGIN
pd = 101 //Opcode to delete (Protection from opcode)
PATCH_INCLUDE ~mymod/lib/spl_eff_del.tpp~
pc = 101 //Opcode to add
tg = 1 //Target (self)
dr = 120 //Duration
p2 = 5 //Parameter 2 (Charm specific creature)
PATCH_INCLUDE ~mymod/lib/spl_eff_add.tpp~
pc = 101 //Opcode to add
tg = 1 //Target (self)
dr = 120 //Duration
p2 = 24 //Parameter 2 (Horror)
PATCH_INCLUDE ~mymod/lib/spl_eff_add.tpp~
pc = 101 //Opcode to add
tg = 1 //Target (self)
dr = 120 //Duration
p2 = 39 //Parameter 2 (Unconsciousness)
PATCH_INCLUDE ~mymod/lib/spl_eff_add.tpp~
 END
BUT_ONLY

I'm adding a lot of effects, so these blocks where I'm calling the macro go on for some time. Is there a more efficient way of doing this, via PATCH_FOR_EACH or PHP_EACH or something?

 

On an unrelated note, a lot of folks (fixpackers included) use "PATCH_IF SOURCE_SIZE > 0x71 BEGIN" etc. to protect against "invalid" files. But in a mod, wouldn't you want to know if a file you were trying to patch was "invalid" - particularly if it were pretty important to your mod? Because otherwise that SOURCE_SIZE check will just skip the patch as if it didn't exist, right?

[Miloch]

I'm adding a lot of effects, so these blocks where I'm calling the macro go on for some time. Is there a more efficient way of doing this, via PATCH_FOR_EACH or PHP_EACH or something?

Nevermind. This was easy I guess.

COPY_EXISTING ~spin117.spl~ ~override~ //Berserk
 PATCH_IF SOURCE_SIZE > 0x71 BEGIN
PATCH_FOR_EACH p2 IN 5 24 39 ... BEGIN
  pc = 101 //Opcode to add
  tg = 1 //Target (Self)
  dr = 120 //Duration
  PATCH_INCLUDE ~mymod/lib/spl_eff_add.tpp~

Still wondering about this though:

On an unrelated note, a lot of folks (fixpackers included) use "PATCH_IF SOURCE_SIZE > 0x71 BEGIN" etc. to protect against "invalid" files. But in a mod, wouldn't you want to know if a file you were trying to patch was "invalid" - particularly if it were pretty important to your mod? Because otherwise that SOURCE_SIZE check will just skip the patch as if it didn't exist, right?

[Bearwere]

i guess it comes from patches with regexp and copypasted by folks

[cmorgan]

Concious decision, I think - if i remember correctly, the ALLOW_MISSING usage creates 0 byte files, and trying to patch them errors out an install. So a combination of I_F_E_I_G/PATCH_IF SOURCE_SIZE gets around the problem of installing.

[erik]

And for a mod intended to have a look at all *.itm or *.spl files, you can bet there are mods out there adding invalid files. Perhaps even using a 0-byte itm file as a marker. Better to skip those than to error out.

 

Besides, for a known file, the else clause could INNER_ACTION COPY in a known good variant instead of patching a known bad.