Pocket Plane Group

Friends and Neighbors => Weimer Republic (WeiDU.org) => WeiDU => Topic started by: the bigg on November 15, 2005, 09:50:53 AM

Title: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on November 15, 2005, 09:50:53 AM
See the, um, topic title   :P

All diffs are available from http://bigg.spellholdstudios.net/weidu_diffs, and contain all my diffs from a previous thread, plus the NO_IF_EVAL_BUG tp2 action and some reformatting of a couple of install-time strings (namely, if the mod has more than 4 components, there is no ASK_EVERY_COMPONENT etc, the installer will now display the name of the tp2 file; moreover, you can now nstall one component, not only [Y]es it. This can make it easier to tailor eventual custom tra files (EG @-1006= "Install Component [") can now be expressed as @-1006 = "What do you want to do with component [", or similar.

If you want the compiled executable PM me (according to the GPL under which WeiDU is released, I can distribute it, provided I make it clear that the file was modified by me and list the date of each change, but before embarking in an 'official' role I prefer to bone up on Ocaml a bit more). Don't use this executable for distributing your mods just yet, though!
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Borsook on November 15, 2005, 10:54:08 AM
Does this mean that Weimer is gone for good?
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on November 15, 2005, 11:07:14 AM
I haven't talked to him yet (one of the main reasons why I didn't give a link to a version with these diffs) and I hope not, however I'm sure you noticed a rather... long hiatus.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Borsook on November 15, 2005, 12:24:01 PM
I haven't talked to him yet (one of the main reasons why I didn't give a link to a version with these diffs) and I hope not, however I'm sure you noticed a rather... long hiatus.
Yeah, I noticed, that's why I'm asking...
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Loriel on November 15, 2005, 02:04:34 PM
Regarding the long hiatus:  It was my impression that weimer has a once-a-year long hiatus because of other responsibilities and to regain some semblance of sanity. ::)  Is this hiatus different than previous years?

EDIT: spelling
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Andyr on November 15, 2005, 06:59:21 PM
I don't know if he has finished his doctorate yet, but if not it is highly possible that his end-of-year (or end-of-doctorate) examinations and meetings could be going on around this time of year.
Title: BACKUP directory now created if missing.
Post by: the bigg on November 16, 2005, 07:28:52 AM
I don't know if he has finished his doctorate yet, but if not it is highly possible that his end-of-year (or end-of-doctorate) examinations and meetings could be going on around this time of year.
Well, this'd explain it all  :)
at least he has lots of diffs to apply when he gets back  :D

Also, new addition: the BACKUP directory is created if missing; thanks to this, MKDIR ~a/b/c/d~ is now a shorter equivalent to
MKDIR ~a~
MKDIR ~a/b~
MKDIR ~a/b/c~
MKDIR ~a/b/c/d~
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Grim Squeaker on November 16, 2005, 09:08:00 AM
Regarding the long hiatus:  It was my impression that weimer has a once-a-year long hiatus because of other responsibilities and to regain some semblance of sanity. ::)  Is this hiatus different than previous years?

EDIT: spelling

As well as the point Andy made I'd imagine he's also gotta be busy working on WeiNGINE.
Title: specify language and components to install from the CLI.
Post by: the bigg on November 22, 2005, 10:25:19 AM
CLI options --language X, --force-install X, --force-uninstall X, --force-install-rest X Y..., --force-uninstall-rest X Y... are added, to allow easier making of scripts to replicate an install (soon to follow).

SET_THE_INTERACTIVE_VARIABLE tp2 action added; the tp2 variable %INTERACTIVE% allows to track wether the install session is interactive or not (to emulate AT_NOT_INTERACTIVE_EXIT or whatever).

diffs, as usual, are available from here: http://bigg.spellholdstudios.net/weidu_diffs.
Title: REQUIRE_FILE ~data/25dialog.bif~ works on multiple installs.
Post by: the bigg on November 24, 2005, 07:24:29 AM
- Bugfix to --force-install X resulting in infinite loop if the mod component fails to install.
- REQUIRE_FILE, FORBID_FILE and FILE_EXIST behave as before, except that, if they are fed a bif file, they search it inside the key (so that this works also with multiple installs).

Diffs are available from the same place as the previous posts  :)

May one (or more) Mac users contact me for running a compatibility test for this (rater tricky) diff?
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Borsook on November 24, 2005, 07:34:20 AM
The Clis look very handy. Are the changes being tested (I mean by others then yourself) and will you be releasing 186, or will you wait for Weimer?
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on November 24, 2005, 07:45:35 AM
Heh, I know they're useful - I just built my game yesterday  ;D 

However, before releasing I'll ask Weimer (which I haven't done) and try to learn Ocaml a bit more  ;)

Also, they aren't tested with SUBCOMPONENTS... :/
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Borsook on November 24, 2005, 09:14:52 AM
Also, they aren't tested with SUBCOMPONENTS... :/
BTW SUBCOMPONENTS work not so well with install all option, i.e. the first component is installed, can something be done about it?
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on November 24, 2005, 11:16:13 AM
Also, they aren't tested with SUBCOMPONENTS... :/
BTW SUBCOMPONENTS work not so well with install all option, i.e. the first component is installed, can something be done about it?
Err, how would you propose to change --yes with subcomponents?

BTW, in refinements components 20 and 21 are both part of the same subcomponent group.
setup-refinements --force-install-rest 21 20
and
setup-refinements --force-install-rest 20 21
will install 20, not 21;
setup-refinements --force-install 10 --force-uninstall 10
is not defined (IE don't do that).


EDIT: Seeming unrelated: ADD_KIT/PRO/MUS has better detection routines (EG you can add swashtF if sswashtF is already present as a kit) and will set the variable even if the kit is already present (ADD_KIT ~TRUECLASS~ parameter_list will still set ~%TRUECLASS%~ to 0)
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Borsook on November 24, 2005, 11:23:19 AM
Also, they aren't tested with SUBCOMPONENTS... :/
BTW SUBCOMPONENTS work not so well with install all option, i.e. the first component is installed, can something be done about it?
Err, how would you propose to change --yes with subcomponents?

BTW, in refinements components 20 and 21 are both part of the same subcomponent group.
setup-refinements --force-install-rest 21 20
and
setup-refinements --force-install-rest 20 21
will install 20, not 21;
setup-refinements --force-install 10 --force-uninstall 10
is not defined (IE don't do that).
I rather meant the default option given to user "ask about each, install etc" if one has e.g. 20 components and only one with subcomponenst it's still necessery to use ASK_EVERY_COMPONENT lest should the player choose "install all" and get subcomponent one. I'd propose that the said install all ignored all components with subcomponents.

EDIT>typo... though it was a funny one and maybe should have been preserved...
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on November 24, 2005, 11:27:33 AM
Also, they aren't tested with SUBCOMPONENTS... :/
BTW SUBCOMPONENTS work not so well with install all option, i.e. the first component is installed, can something be done about it?
Err, how would you propose to change --yes with subcomponents?

BTW, in refinements components 20 and 21 are both part of the same subcomponent group.
setup-refinements --force-install-rest 21 20
and
setup-refinements --force-install-rest 20 21
will install 20, not 21;
setup-refinements --force-install 10 --force-uninstall 10
is not defined (IE don't do that).
I rather meant the default option given to user "ask about each, install etc" if one has e.g. 20 components and only one with subcomponenst it still necessery to use ASK_EVERY_COMPONENT lest should the player choose "install all" and get subcomponent one. I'd propose that the said install all ignored all compomponents with subcomponents.

I can't see wether this is possible or not and wether this is a good idea or not (for example in Refinements you get a subcomponent choice for the language for the armor revision part, and then install armor revisions, so you won't get updated descriptions this way).
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Borsook on November 24, 2005, 11:32:53 AM
Also, they aren't tested with SUBCOMPONENTS... :/
BTW SUBCOMPONENTS work not so well with install all option, i.e. the first component is installed, can something be done about it?
Err, how would you propose to change --yes with subcomponents?

BTW, in refinements components 20 and 21 are both part of the same subcomponent group.
setup-refinements --force-install-rest 21 20
and
setup-refinements --force-install-rest 20 21
will install 20, not 21;
setup-refinements --force-install 10 --force-uninstall 10
is not defined (IE don't do that).
I rather meant the default option given to user "ask about each, install etc" if one has e.g. 20 components and only one with subcomponenst it still necessery to use ASK_EVERY_COMPONENT lest should the player choose "install all" and get subcomponent one. I'd propose that the said install all ignored all compomponents with subcomponents.

I can't see wether this is possible or not and wether this is a good idea or not (for example in Refinements you get a subcomponent choice for the language for the armor revision part, and then install armor revisions, so you won't get updated descriptions this way).
Maybe I wasn't clear, I meant that even if the user does not want to be asked about each com and install all he should still be asked about those with subcomponents. In current situation either modder uses ASK_EVERY_COMPONENT and user has to answer Yes 20 times or the modder doesn't use it, user chooses install all and never knows there was a choice to be made.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on November 24, 2005, 11:37:02 AM
Maybe I wasn't clear, I meant that even if the user does not want to be asked about each com and install all he should still be asked about those with subcomponents. In current situation either modder uses ASK_EVERY_COMPONENT and user has to answer Yes 20 times or the modder doesn't use it, user chooses install all and never knows there was a choice to be made.
Ah, OK - after I'm done ironing out a couple of bugs/features from ADD_KIT/MUS/PRO  :D
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Borsook on November 24, 2005, 11:39:49 AM
Maybe I wasn't clear, I meant that even if the user does not want to be asked about each com and install all he should still be asked about those with subcomponents. In current situation either modder uses ASK_EVERY_COMPONENT and user has to answer Yes 20 times or the modder doesn't use it, user chooses install all and never knows there was a choice to be made.
Ah, OK - after I'm done ironing out a couple of bugs/features from ADD_KIT/MUS/PRO  :D
Great.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on November 24, 2005, 12:02:22 PM
Diffs (and executable for those who know the link) have just been updated with the aforementioned ADD_KIT fixes (I didn't touch the discussed issue with subcomponents).
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Borsook on November 24, 2005, 12:05:43 PM
Diffs (and executable for those who know the link) have just been updated with the aforementioned ADD_KIT fixes (I didn't touch the discussed issue with subcomponents).
You work fast! Hmm and where pray is the thumbs up icon? Oh, well, think back to PnP and visualize ;D
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on November 24, 2005, 12:35:18 PM
Nah, this was all the diff (as in diff -p -b -E):

Code: [Select]
*** 2837,2849 ****
          (PE_And(
          (Pred_File_Exists(PE_LiteralString "override/kitlist.2da")),
          (Pred_File_Contains(PE_LiteralString "override/kitlist.2da",
!           PE_LiteralString k.kit_name))))) then begin
          log_and_print "\n\nERROR: Kit [%s] already present! Skipping!\n\n"
          k.kit_name
        end else begin
--- 2904,2916 ----
          (PE_And(
          (Pred_File_Exists(PE_LiteralString "override/kitlist.2da")),
          (Pred_File_Contains(PE_LiteralString "override/kitlist.2da",
!           PE_LiteralString ("^" ^ k.kit_name ^ "\\b")))))) then begin
!         Var.set_int32 (k.kit_name) (Bcs.int_of_sym game "KITLIST.2DA" k.kit_name) ;
          log_and_print "\n\nERROR: Kit [%s] already present! Skipping!\n\n"
          k.kit_name
        end else begin
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on November 25, 2005, 07:59:42 AM
Slight fix to the cli options. Updated fix and executable.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on November 25, 2005, 12:30:56 PM
Maybe I wasn't clear, I meant that even if the user does not want to be asked about each com and install all he should still be asked about those with subcomponents. In current situation either modder uses ASK_EVERY_COMPONENT and user has to answer Yes 20 times or the modder doesn't use it, user chooses install all and never knows there was a choice to be made.
...done  :)
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Borsook on November 25, 2005, 12:35:13 PM
Maybe I wasn't clear, I meant that even if the user does not want to be asked about each com and install all he should still be asked about those with subcomponents. In current situation either modder uses ASK_EVERY_COMPONENT and user has to answer Yes 20 times or the modder doesn't use it, user chooses install all and never knows there was a choice to be made.
...done  :)
Wow. Can I use it for distribution, can I? can I?
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on November 25, 2005, 12:36:12 PM
Wow. Can I use it for distribution, can I? can I?
Once I contact Weimer, yes  :)
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on November 27, 2005, 05:01:02 AM
- MKDIR ~%a_var%~ works.
- embarassing bugfix in my interpretation of FORBID_FILE  ::)
- AT_* ~NOTEPAD this~ and AT_* ~EXPLORER this~ now work like ~AT_* ~VIEW this~.
- --skip-at-view CLI option makes you skip the readme displaying (EG if you were testing a mod and reinstalling it 10^10 times it gets annoying).

Updated diffs & executable.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on November 27, 2005, 10:39:49 AM
- --quick-log doesn't print the name of installed components in the log (saves around 4 seconds per mod for people with large collections).
- Long-time pending tutorial for SET_2DA_ENTRY_LATER/NOW added.
- READ_2DA_ENTRIES_NOW/READ_2DA_ENTRY_FORMER added, they work somewhat like SET_2DA_ENTRY_LATER / SET_2DA_ENTRIES_NOW and are supposed to be faster. See the (rather skinny) tutorial.
- SET_THE_INTERACTIVE_VARIABLE removed, the variable is set implicitly.
- NO_IF_EVAL_BUG promoted to tp2 flag.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on December 13, 2005, 06:53:55 AM
- The new handling of biff files (IE they are searched in the chitin rather than as files) is now only for strings matching ~data[:/\\]25[^.]*\.bif~ (to solve a bug with some Tutu mods).
- COPY_LARGE allows to copy (no patching, no predicates) files that are greater than Sys.max_string_lenght (IE the usual 16 Mb limit). now it's raised to about 1 Gb.
- if you're overwriting a file that is > Sys.max_string_lenght in size, the backup process works without a glitch.

Soon to follow: OGGDEC and TISUNPACK hardwired in WeiDU: you can in your tp2 OGGDEC [options] ~file1~ ~override~ and weidu will oggdec file1 (with usual directory support) and copy the result to the override, including everything in the backup process; this'll work for result files that are >= Sys.max_string_lenght. Stay tuned for when I can complete the C interfacing and get to compile everything  :)

Unfortunately, I can't add WAV2ACM or MAKE_BIFF support: the former for (c) reasons and because the backup process is optimized for the override, the latter because the modified chitin.key cannot be used by WeiDU. Stay tuned for lucky strikes  ;D
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Borsook on December 13, 2005, 06:58:31 AM
Wow! These are really interesting changes! I don't wanna badger you or anything but how goes making it official? I mean it's great but it's a modding tool, we need it to make mods not theoretical exercises!
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Ascension64 on December 13, 2005, 07:03:31 AM
Quote
- The new handling of biff files (IE they are searched in the chitin rather than as files) is now only for strings matching ~data[:/\\]25[^.]*\.bif~ (to solve a bug with some Tutu mods).
What sorts of problems in particular?

Quote
- COPY_LARGE allows to copy (no patching, no predicates) files that are greater than Sys.max_string_lenght (IE the usual 16 Mb limit). now it's raised to about 1 Gb.
- if you're overwriting a file that is > Sys.max_string_lenght in size, the backup process works without a glitch.
I thought OCamL could not support this.

Well done anyway.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on December 13, 2005, 07:27:19 AM
Quote
- The new handling of biff files (IE they are searched in the chitin rather than as files) is now only for strings matching ~data[:/\\]25[^.]*\.bif~ (to solve a bug with some Tutu mods).
What sorts of problems in particular?
See http://forums.gibberlings3.net/index.php?showtopic=4973&view=findpost&p=47520 this thread.

Quote
Quote
- COPY_LARGE allows to copy (no patching, no predicates) files that are greater than Sys.max_string_lenght (IE the usual 16 Mb limit). now it's raised to about 1 Gb.
- if you're overwriting a file that is > Sys.max_string_lenght in size, the backup process works without a glitch.
I thought OCamL could not support this.

Well done anyway.
OcaML has no limitiations on files, however WeiDU loads files as a string for easiness of patching (which is possible since in OcaML strings aren't null terminated like in C), and strings (on 32 bit machines) are limited to 2^24 - 5 characters (or something-like-that), while 'normal' files are limited to something like 2^30 bytes.

Hint: on 64 bit machines WeiDU can handle basically arbitrary file sizes  :D
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on December 13, 2005, 12:54:11 PM
Well, getting the C interface up wasn't the difficult part; however, for some reason or some other I can't get Tisunpack to link correctly with the jpeg library. I'll see wether it's easier to make a variant of AT_*_EXIT that is run when encountered, rather than at the end of the installation or to bash my head against some stupidity.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on December 13, 2005, 01:30:37 PM
AT_*_NOW added, diffs + beta updated.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on December 16, 2005, 04:42:06 AM
  * DEFINE/LAUNCH_ACTION_MACRO (with MACRO_ACTION as synonim) added, they are similar to the so-called functions in bash (or, less precisely, to Basic's GOSUB). On the same line, DEFINE/LAUNCH_PATCH_MACRO (with MACRO_PATCH as synonim). Tutorials pending.
  * OUTER_INNER_PATCH, OUTER_INNER_PATCH_SAVE, OUTER_FOR, OUTER_SET, OUTER_SPRINT added. They work like their non-OUTER cousins, except that they are actions and OUTER_FOR launches actions as well. OUTER_INNER_* have synonims in OUTER_*.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on December 19, 2005, 10:21:20 AM
COUNT_REGEXP_INSTANCES allows you to count the number of occurances of a certain regexp inside the file being edited. Don't assume it's a fast patch, neither assume it'll compute correctly non-trivial regexp.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Idobek on December 19, 2005, 11:45:37 AM
Since you're on a roll, please fix this bug (http://forums.pocketplane.net/index.php/topic,19884.0.html).

If I could have some kind of CLEAR_MEMORY command that would unload all files and clear any saved variables that would be good too. I'm thinking this would be a catch all idea that might solve some hard-crashing bugs and uninstall errors. So, I could use it after an ADD_KIT to ensure that WeiDU no longer has kit.ids and kitlist.2da loaded before I attempt to modify them--it is my hypothesis that this is/was causing the hard-crash reported in the Divine Remix forums. If you could code up a CLEAR_MEMORY (or somesuch) diff I could use that to test my theories. Only if you're bored, of course.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on December 19, 2005, 12:13:27 PM
Since you're on a roll, please fix this bug (http://forums.pocketplane.net/index.php/topic,19884.0.html).
I can try to fix it, but subcomponent coding is a big POS, so I'm not sure if this is doable without changing a lot of the functionality.
I usually workaround this by offering a subcomponent group for each predicate group. (I coded macroes to make sure code repetition is kept to a minimum for such problems).

Quote
If I could have some kind of CLEAR_MEMORY command that would unload all files and clear any saved variables that would be good too. I'm thinking this would be a catch all idea that might solve some hard-crashing bugs and uninstall errors. So, I could use it after an ADD_KIT to ensure that WeiDU no longer has kit.ids and kitlist.2da loaded before I attempt to modify them--it is my hypothesis that this is/was causing the hard-crash reported in the Divine Remix forums. If you could code up a CLEAR_MEMORY (or somesuch) diff I could use that to test my theories. Only if you're bored, of course.
I can add clearing of variables in a minute, while there should be no problem with loading files: they are fopen()-d for reading on the disk, loaded in the memory, fclose()-d, you patch their image in the RAM, and then the destination is fopen()-d for writing/creation, the image is written, and it's fclose()-d.

I'll send you diffs with CLEAR_MEMORY in a sec  :)

ancillary notice: the \ -> / conversion for Mac OS X appears to be working.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on December 19, 2005, 02:16:16 PM
Idobek's 'bug' is fixed in the sense that, when launching again the setup program, it'll uninstall the subcomponent whose patch expression became wrong. In doing this, it'll also uninstall the component adding cdcurse.spl, which then means that you'll still install the subcomponent with NOT FILE_EXISTS_IN_GAME ~cdcurse.spl~. If you prefer a different handling, just ask  :)
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: Ascension64 on December 23, 2005, 06:02:02 AM
Quote
DEFINE/LAUNCH_ACTION_MACRO (with MACRO_ACTION as synonim) added, they are similar to the so-called functions in bash (or, less precisely, to Basic's GOSUB). On the same line, DEFINE/LAUNCH_PATCH_MACRO (with MACRO_PATCH as synonim). Tutorials pending.
Although no one except the bigg knows how to use it yet, this feature looks really useful.  I just have a question regarding these commands, and it is on: whether the patches inside an INNER_* block in *_ACTION_MACRO, and the actions inside an OUTER_* block in *_PATCH_MACRO will work.  Hope that makes sense.
Title: Re: The IF_EVAL bug has been solved maintaining backwards compatibility.
Post by: the bigg on December 23, 2005, 06:18:02 AM
Quote
DEFINE/LAUNCH_ACTION_MACRO (with MACRO_ACTION as synonim) added, they are similar to the so-called functions in bash (or, less precisely, to Basic's GOSUB). On the same line, DEFINE/LAUNCH_PATCH_MACRO (with MACRO_PATCH as synonim). Tutorials pending.
Although no one except the bigg knows how to use it yet, this feature looks really useful.  I just have a question regarding these commands, and it is on: whether the patches inside an INNER_* block in *_ACTION_MACRO, and the actions inside an OUTER_* block in *_PATCH_MACRO will work.  Hope that makes sense.
They work like this (from a mod of mine, soon to be released, contains also example of how to pass parameters via global variables):

Code: [Select]
/* a tp2 flag */
DEFINE_ACTION_MACRO ~FASTER_ROMANCES~ BEGIN
  <<<<<<<< faster_romance/macro/fixme.d
    REPLACE_ACTION_TEXT_REGEXP ~\(^aerie$\)\|\(^kalah2$\)~  ~StartDialogueNoSet()~ ~StartDialogueNoSet([PC])~
    REPLACE_ACTION_TEXT ~baerie~   ~MoveGlobal("AR0607","Aerie",\[1034\.1034\],0)~ ~MoveGlobal("AR0607","Aerie",[1034.1034])~
  >>>>>>>>
/* fix baerie.dlg (and others) ! */ 
  COMPILE ~faster_romance/macro/fixme.d~

  COPY_EXISTING ~sw1h01.itm~ ~override/tb#faster1.txt~
  COPY_EXISTING ~gtimes.ids~ ~override~
    READ_2DA_ENTRIES_NOW ~_#_#_#gtimes~ 2
  BUT_ONLY_IF_IT_CHANGES
 
  COPY_EXISTING_REGEXP GLOB ~.*\.bcs~ ~override~
  DECOMPILE_BCS_TO_BAF
    FOR (i = 0; i < _#_#_#gtimes; i+=1)
    BEGIN
      READ_2DA_ENTRY_FORMER ~_#_#_#gtimes~ i 0 number
      READ_2DA_ENTRY_FORMER ~_#_#_#gtimes~ i 1 string
      REPLACE_TEXTUALLY ~,%string%)~ ~,%number%)~
    END
    REPLACE_EVALUATE ~RealSetGlobalTimer(\(\"[^"]*\",\"[^"]*\"\),\([^)]*\))~
    BEGIN
      temp = multiply * MATCH2 ** (exponentiation nth_root) / divide
      MATCH2 = temp < MATCH2 ? temp : MATCH2
      SPRINT RESULT ~%MATCH2%~
    END
    ~RealSetGlobalTimer(%MATCH1%,%RESULT%)~
  COMPILE_BAF_TO_BCS
  BUT_ONLY_IF_IT_CHANGES
  IF ~^268OB~

  COPY_EXISTING_REGEXP GLOB ~.*\.dlg~ ~override~
  DECOMPILE_DLG_TO_D
    FOR (i = 0; i < _#_#_#gtimes; i+=1)
    BEGIN
      READ_2DA_ENTRY_FORMER ~_#_#_#gtimes~ i 0 number
      READ_2DA_ENTRY_FORMER ~_#_#_#gtimes~ i 1 string
      REPLACE_TEXTUALLY ~,%string%)~ ~,%number%)~
    END
    REPLACE_EVALUATE ~RealSetGlobalTimer(\(\"[^"]*\",\"[^"]*\"\),\([^)]*\))~
    BEGIN
      temp = multiply * MATCH2 ** (exponentiation nth_root) / divide
      MATCH2 = temp < MATCH2 ? temp : MATCH2
      SPRINT RESULT ~%MATCH2%~
    END
    ~RealSetGlobalTimer(%MATCH1%,%RESULT%)~
  COMPILE_D_TO_DLG
  IF ~RealSetGlobalTimer~
  BUT_ONLY_IF_IT_CHANGES
END


/* the components */
/* ****************************************
           FASTER ROMANCES
**************************************** */
/* RealSetGlobalTimer(_,_,x) is changed to be
multiply * x ^ (exponentiation / nth_root) / divide
(but only if the value decreases).

Values for multiply, exponentiation, nth_root and divide are computated
thanks to an external program written in C, included in the mod distribution,
see the file other/compute_faster_romance.c .
If you want me to add different pairs (not necessarily 3600->x and 36000->x),
it can be done fairly trivially, so ask away. (you can even compile and run
the 'compute_faster_romance' program yourself to find out the values yourself).
*/

BEGIN @9001
SUBCOMPONENT @9000
DESIGNATED 2500
// 3600  -> 3300
// 36000 -> 18000

OUTER_SET multiply = 795
OUTER_SET divide = 1000
OUTER_SET exponentiation = 736
OUTER_SET nth_root = 1000

LAUNCH_ACTION_MACRO ~FASTER_ROMANCES~

BEGIN @9002
SUBCOMPONENT @9000
DESIGNATED 2550
// 3600  -> 3000
// 36000 -> 12000

OUTER_SET multiply = 21689
OUTER_SET divide = 999
OUTER_SET exponentiation = 602
OUTER_SET nth_root = 1000

LAUNCH_ACTION_MACRO ~FASTER_ROMANCES~

BEGIN @9003
SUBCOMPONENT @9000
DESIGNATED 2600
// 3600  -> 2700
// 36000 -> 9000

OUTER_SET multiply = 37581
OUTER_SET divide = 1002
OUTER_SET exponentiation = 523
OUTER_SET nth_root = 1001

LAUNCH_ACTION_MACRO ~FASTER_ROMANCES~


basically, all they do is copying-pasting the code in DEFINE where is a LAUNCH (except that they *should* also be recursive), so they should work also in INNER and OUTER.

EDIT: actually, Refinements beta uses INNER_* inside a DEFINE_ACTION_MACRO and it works.

Also, macroes are recursive (IE a macro can call itself), so EG you can calculate a factorial:
Code: [Select]
DEFINE_ACTION_MACRO ~factorial~ BEGIN
  ACTION_IF i != 1 THEN
  BEGIN
    OUTER_SET factor = factor * i
    OUTER_SET i = i - 1
     LAUNCH_ACTION_MACRO ~factorial~
  END
END

BEGIN ~calculate a factioral~
OUTER_SET ~i~ = 5
OUTER_SET ~i_backup~ = ~%i%~
OUTER_SET ~factor~ = 1
LAUNCH_ACTION_MACRO ~factorial~
PRINT ~%i_backup%! = %factor%~
Take your time to make a mental note *never* to use global variables like that in a real programming language. Unfortunately, WeiDU ties our hands  :(