Posted by: the bigg
« on: February 13, 2011, 05:46:30 PM »In general, you can put an OUTER_TEXT_SPRINT and then call ACTION_BASH_FOR (or whatever action you're using currently).
Sorry, it appears that I'll have to rewrite too much of the parser to make this worth the effort. Add an extra SPRINT to extract your variables from the arrays in the couple of places where you'd need it.I understand, thanks anyway for checking
ops, I meant directory-file-regexp. I tried to use it in ACTION_BASH_FOR ~directory~ EVALUATE_BUFFER ~%array_%arg%%~, but it did not accept EVALUATE_BUFFER to be put there; the same happened with PATCH_BASH_FOR and MAKE_BIFF.Quoteto allow any number of EVALUATE_BUFFER to be put before the file regexpNot testing before posting doesn't do you any favors. EVALUATE_BUFFER EVALUATE_BUFFER ~%array_%arg%%~ works for me (E.G. in WRITE_ASCIIE).
I'd say: WRITE_EVALUATED_ASCII and similar commandsWRITE_ASCIIE already handles arrays; moreover, "and similar commands" means that I have to read the list of commands available and randomly guess which ones people will want to use with arrays.
to allow any number of EVALUATE_BUFFER to be put before the file regexpNot testing before posting doesn't do you any favors. EVALUATE_BUFFER EVALUATE_BUFFER ~%array_%arg%%~ works for me (E.G. in WRITE_ASCIIE).
Actually, would it be possible, instead of just accepting an array instead of a string on each commands, that every time a string is evaluated (because the command automatically does it or because of E_B), after changing everything between %s, the installer also checks if any string preceded by $ and followed by brackets has been inited as an array? For instance, to interpret ~abc$def(g)~ as ~abc[value of argument g of array def]~?No, but you can use the fact that ~abc$def(g)~ = EVALUATE_BUFFER EVALUATE_BUFFER ~abc%def_%g%%~. It looks like poo, but altering how strings work is even worse.
list the positions where you want array syntax to be enabled - I can't easily enable it globally.I'd say, generally, wherever a string is expected and variable substitution is performed, and where the $ symbol doesn't have a role yet, but I'm not sure that all places I'll list would not create problems; I could also mention places where it does work.
MAKE_BIFF ~biff~ BEGIN ~folder~ EVALUATE_BUFFER ~string%array_%arg%%~ END
COPY, MOVE, APPEND(_COL), EXTEND_TOP/BOTTOM, QUOTE, SPACES, PRINT, LOG, WARN, SAY, REPLACE(_TEXTUALLY), SET_2DA_ENTRYI usually prefer having backed up files in the backup folder, and not scattered around the mod folder, for instance, in the wed folder and so on; I'd also prefer to avoid duplicating all files which will also be biffed (especially as the only files which are usually immediately biffed are wavs, tis, ... , which are all quite heavy).BIFF the files and MOVE them later if you find the thought of leaving them in wed/ rather than backup/ so sickening.
Anyway, I've changed the code using arrays to memorize the names and new locations.
The only thing is, in order not to have problems with 'strange' names, I've seen there's the command 'QUOTE'. Is it possible to introduce an OUTER_QUOTE or ACTION_QUOTE, in order to avoid calling thousands of OUTER_PATCH ~0~ BEGIN QUOTE ... END? And is it possible to allow the array construct $ to be used in more expressions, such as INNER_PATCH, MAKE_BIFF and so on? For example,Sure for all (list the positions where you want array syntax to be enabled - I can't easily enable it globally).Code: [Select]MAKE_BIFF ~biff%i%~ BEGIN ~folder~ $array("%i%") END //results in parse error, as well as
[/code]
OUTER_INNER_PATCH $array("%i%") BEGIN...[code]
Why can't you just leave the physical file there?I usually prefer having backed up files in the backup folder, and not scattered around the mod folder, for instance, in the wed folder and so on; I'd also prefer to avoid duplicating all files which will also be biffed (especially as the only files which are usually immediately biffed are wavs, tis, ... , which are all quite heavy).
MAKE_BIFF ~biff%i%~ BEGIN ~folder~ $array("%i%") END //results in parse error, as well as
OUTER_INNER_PATCH $array("%i%") BEGIN...[code]
[/code]For how I'd use this command, I'd first move any existing file with the same name to the backup folder, and only afterwards inline the new ones.Mixing and otherwise operating on files in the same component sounds like an unsafe design (even if it currently works, there's a risk that I change an implementation detail and break your mod). Why can't you just leave the physical file there?
Enabling that behaviour only if there's a - after the command would not cause problems unless one is intentionally using that option, in which case he should know what the risks are (and do some appropriate tests)
BUFFER_LENGTH is a patch expression, not a variable; as such, it won't be recognized inside PATCH_PRINT or work if quoted with %%s (in the same way as PATCH_PRINT ~%x + y%~ wouldn't work). The following would be correct:I understand, thanks. it works now
SET length = BUFFER_LENGTH // without ~~ or "" or %% around BUFFER_LENGTH
PATCH_PRINT ~%length%~
Regarding ACTION_BASH_FOR - and MAKE_BIFF -, they are possible to code, but there's an issue of code safety here, since you should on principle never have inlined files defined in any actually possible file path (or, even worse, in an existing directory); aside from A_B_F not reading them, you're running the risk of having a physical file and an inlined file with the same name, which leads to undefined results (some commands would read the physical file, other commands the inlined one).For how I'd use this command, I'd first move any existing file with the same name to the backup folder, and only afterwards inline the new ones.
OUTER_INNER_PATCH_SAVE test ~test~ BEGIN
PATCH_PRINT ~%BUFFER_LENGTH%~
END
Instead, the variable was not substituted, and it just printed %BUFFER_LENGTH%. Trying to set a variable to %BUFFER_LENGTH% causes an error: can not convert B_L or %B_L% to an integer. The same happens without the _SAVE and with INNER_PATCHes. Is it a bug or am I using it in the wrong context?