Tentative changes for next version

[Wisp]

Thus far I have:

Code: [Select]

  * Add --ask-only command-line option.
  * --parse-check does not fail on trarefs in BAF.
  * MODDER FUN_ARGS report name of function and type of argument.
  * WeiDU does not terminate if it fails to resolve a traref for
    MOD_VERSION.
  * Having the VERSION string be a traref does not result in an error.
  * The variable WEIDU_VER is set correctly.
  * HANDLE_CHARSETS can convert non-TRA files. Thanks, the_bigg.
  * Attempts to load movie files are made with the WBM extension on
    EE-type games.
  * Fix failure to re-run WeiDU after auto-update if the file name
    contained spaces.
  * Fix regression that mangled Latin-1 characters.
  * TP2_BASE_NAME once again does not include a file extension, to
    match previous de facto behaviour.
  * Fix regression involving SUBCOMPONENT predicates.
  * Fix bug that had GET_UNIQUE_FILE_NAME returning non-unique results
    if variable base was empty. Thanks, DavidW.
  * Fix variable leak in ADD_JOURNAL.
  * Changes to fj_are_structure parameters to better reflect file
    structure, as well as additions for EE.
  * Optimise processing of LABELs in own TP2.
  * Fix incorrect line-breaking in DLGs that resulted in broken IDS
    symbols, and possibly other problems. Affected DLGs need to be
    recreated.
  * WeiDU does not fail to load, for example, the file ".BCS".
  * Support EE 2.6's MISSILE.IDS.

Have I overlooked anything? Is there something you think should be fixed for or included in v248?

[AL|EN]

You asked you shall receive:

Bugs:
1. WeiDU 247 %MOD_FOLDER% has an incorrect value, 246 works - https://forums.pocketplane.net/index.php?topic=29956.0 - fixed!
    AFAIR, the above bug caused yet another bug: mods can't use %MOD_FOLDER% variable inside LANGUAGE statement because the component names are "UNDEFINED STRING: ..." - fixed!
2. WeiDU is destroying every executable which is called 'Setup-xxx' even if the returned version is -1. - https://forums.pocketplane.net/index.php?topic=29925.msg340248#msg340248

Inclusion:
3. Add evaluate variables to AUTO_TRA - https://forums.pocketplane.net/index.php?topic=29971.msg340545#msg340545 - done!
4. Add evaluate variables to  REQUIRE_COMPONENT - https://forums.pocketplane.net/index.php?topic=29974.msg340459#msg340459

[Graion Dilach]

WeiDU 247 %MOD_FOLDER% has an incorrect value, 246 works - https://forums.pocketplane.net/index.php?topic=29956.0
    AFAIR, the above bug caused yet another bug: mods can't use %MOD_FOLDER% variable inside LANGUAGE statement because the component names are "UNDEFINED STRING: ..."

This is listed actually, as

Code: [Select]

TP2_BASE_NAME once again does not include a file extension, to match previous de facto behaviour.

[AL|EN]

@Graion Dilach I think you are confusing MOD_FOLDER with TP2_BASE_NAME, those variables aren't related and they serve different puporse.

[Wisp]

1. WeiDU 247 %MOD_FOLDER% has an incorrect value, 246 works - https://forums.pocketplane.net/index.php?topic=29956.0

Done.

AFAIR, the above bug caused yet another bug: mods can't use %MOD_FOLDER% variable inside LANGUAGE statement because the component names are "UNDEFINED STRING: ..."

If you by that mean LANGUAGE has never evaluated variables or claimed it does, no, no it hasn't. I might be able to add that, but not for this release and I'd have to sort through all the stack-management code to make sure LANGUAGE would never be evaluated against a stale or incorrect variable environment before I could provide an answer.

[AL|EN]

1. WeiDU 247 %MOD_FOLDER% has an incorrect value, 246 works - https://forums.pocketplane.net/index.php?topic=29956.0

Done.

Thanks!

AFAIR, the above bug caused yet another bug: mods can't use %MOD_FOLDER% variable inside LANGUAGE statement because the component names are "UNDEFINED STRING: ..."

If you by that mean LANGUAGE has never evaluated variables or claimed it does, no, no it hasn't. I might be able to add that, but not for this release and I'd have to sort through all the stack-management code to make sure LANGUAGE would never be evaluated against a stale or incorrect variable environment before I could provide an answer.

No, I simply mean this:

LANGUAGE "English" "english" "%MOD_FOLDER%/lang/english/setup.tra"

and with Ad.1 being fixed, this problem is gone!

P.S. So making AUTO_TRA evaluate variables won't make it?

[Wisp]

P.S. So making AUTO_TRA evaluate variables won't make it?

I can't very well say it's done until it's actually done, can I?

I figure I'll give this thread a few days, maybe release on saturday. I'll keep adding stuff as time allows until then.

[_Luke_]

Inclusion:
4. Add evaluate variables to  REQUIRE_COMPONENT - https://forums.pocketplane.net/index.php?topic=29974.msg340459#msg340459

I'd also add REQUIRE_PREDICATE...

Thus far I have:

Code: [Select]

  * Changes to fj_are_structure parameters to better reflect file
    structure, as well as additions for EE.


What about making sure this function works as intended when MODDER fun_args is enabled – https://github.com/WeiDUorg/weidu/issues/182#issuecomment-775031472 ?

[AL|EN]

P.S. So making AUTO_TRA evaluate variables won't make it?

I can't very well say it's done until it's actually done, can I?

I figure I'll give this thread a few days, maybe release on saturday. I'll keep adding stuff as time allows until then.

I'm sorry for my impatience. I was under impression that a reply from your side means "I did what I could, I'm done now". Now it seems that this new process of asking about 'personally needed stuff before the new release' is wonderful and already exciting my expectations. Many thanks!

[Wisp]

[What about making sure this function works as intended when MODDER fun_args is enabled – https://github.com/WeiDUorg/weidu/issues/182#issuecomment-775031472 ?

You can still use FUN_ARGS with array arguments (unless you've set MODDER to FAIL), can't you? While the false positives are unfortunate, I don't think it's a pressing issue.

Edit: oh, and the AUTO_TRA thing is done, as well as the auto-update thing.

[_Luke_]

[What about making sure this function works as intended when MODDER fun_args is enabled – https://github.com/WeiDUorg/weidu/issues/182#issuecomment-775031472 ?

You can still use FUN_ARGS with array arguments (unless you've set MODDER to FAIL), can't you? While the false positives are unfortunate, I don't think it's a pressing issue.

I usually set fun_args fail since it's quite important for me...
Having said that, this advice (https://github.com/WeiDUorg/weidu/issues/212#issue-1052634054) should be enough to warn modders about how to silence the false positives...

Separately, what can you tell me of this?

Inclusion:
4. Add evaluate variables to  REQUIRE_COMPONENT - https://forums.pocketplane.net/index.php?topic=29974.msg340459#msg340459

I'd also add REQUIRE_PREDICATE...

As of now, the following mod will fail to install

Code: [Select]

BACKUP ~test/backup~ // location to store files for uninstall purposes
SUPPORT ~~
AUTO_EVAL_STRINGS

ALWAYS
OUTER_SET "foo" = 67
END

VERSION ~v1.0~

LANGUAGE
~English~
~english~
~test/lang/english/setup.tra~

BEGIN "Does REQUIRE_PREDICATE evaluate variables?"
REQUIRE_PREDICATE (VARIABLE_IS_SET ~foo~) ~Should not happen~

PRINT "~%foo%~"

[Argent77]

Separately, what can you tell me of this?

Inclusion:
4. Add evaluate variables to  REQUIRE_COMPONENT - https://forums.pocketplane.net/index.php?topic=29974.msg340459#msg340459

I'd also add REQUIRE_PREDICATE...

As of now, the following mod will fail to install

Code: [Select]

BACKUP ~test/backup~ // location to store files for uninstall purposes
SUPPORT ~~
AUTO_EVAL_STRINGS

ALWAYS
OUTER_SET "foo" = 67
END

VERSION ~v1.0~

LANGUAGE
~English~
~english~
~test/lang/english/setup.tra~

BEGIN "Does REQUIRE_PREDICATE evaluate variables?"
REQUIRE_PREDICATE (VARIABLE_IS_SET ~foo~) ~Should not happen~

PRINT "~%foo%~"

I can imagine that a change like this will introduce compatibility issues with existing mods which expect the ALWAYS block to be executed *after* the mod requirements have been evaluated.

There is already the ABORT action available which can be used to terminate a mod component in a safe manner.

[Wisp]

Separately, what can you tell me of this?

That will never work, as Argent77 is correct in that ALWAYS is executed before your component's actions, but well after its predicates are evaluated.

So I may as well ask, what kind of variables are you and  AL|EN planning on evaluating here? REQUIRE_PREDICATE does already evaluate variables, those occurring inside each value.

[_Luke_]

I can imagine that a change like this will introduce compatibility issues with existing mods which expect the ALWAYS block to be executed *after* the mod requirements have been evaluated.

There is already the ABORT action available which can be used to terminate a mod component in a safe manner.

@Wisp
Ah, yes, you're right.
The only real case scenario I can think of is the following one:

For some unknown reason, the BGEE version of SPELL.IDS has the entry 2610 WIZARD_MONSTER_SUMMONING_4.
However, the file spwi610.spl does not actually exist as a game resource, so checks like this one

Code: [Select]

REQUIRE_PREDICATE (RESOURCE_CONTAINS "SPELL.IDS" "[ %TAB%]WIZARD_MONSTER_SUMMONING_4[ %TAB%%WNL%$]")are not reliable.

As a result, checking if a var is set

Code: [Select]

REQUIRE_PREDICATE (VARIABLE_IS_SET "WIZARD_MONSTER_SUMMONING_4")would be more reliable in this case (provided that such variable has been defined in your ALWAYS block, along with making sure that "%WIZARD_MONSTER_SUMMONING_4%.spl" does exist as a game resource).
But as you said, the ALWAYS block is executed *after* the mod requirements have been evaluated, so I can't use that either...

Sure, I could write

Code: [Select]

REQUIRE_PREDICATE (FILE_EXISTS_IN_GAME "SPWI610.SPL")but you know better than me that functional programming is the way, so nope, that's not ideal either... Moreover, it won't work on IWDEE (since WIZARD_MONSTER_SUMMONING_4 is SPWI627 there...)

So to sum up, guess I'll use ABORT...

[_Luke_]

Is there something you think should be fixed for or included in v248?

What about including all of this – https://github.com/Argent77/A7-add_kit_ex ?

[Wisp]

What about including all of this – https://github.com/Argent77/A7-add_kit_ex ?

If Argent77 thinks it's a good idea, I can see about adding it for next version.

[Argent77]

What about including all of this – https://github.com/Argent77/A7-add_kit_ex ?

If Argent77 thinks it's a good idea, I can see about adding it for next version.

I have no problems with having the library added to WeiDU. It's pretty much feature-complete and well enough tested by now.

[AL|EN]

Separately, what can you tell me of this?

That will never work, as Argent77 is correct in that ALWAYS is executed before your component's actions, but well after its predicates are evaluated.

So I may as well ask, what kind of variables are you and  AL|EN planning on evaluating here? REQUIRE_PREDICATE does already evaluate variables, those occurring inside each value.

FWIW, this is my use-case:

 BACKUP "weidu_external/backup/RCVar"
SUPPORT "RCVar"
VERSION "0.1.0"


ALWAYS
    // for internal components only
    OUTER_SET RCVar-C1 = ID_OF_LABEL "%TP2_FILE_NAME%" "RCVar-Component-1"
    PRINT "%RCVar-C1%"
END


BEGIN "RCVar-1" DESIGNATED 1000 LABEL "RCVar-Component-1"
PRINT ""


BEGIN "RCVar-2" DESIGNATED 2000 LABEL "RCVar-Component-2" NO_LOG_RECORD
// dosen't work: REQUIRE_COMPONENT "%TP2_FILE_NAME%" "%RCVar-C1%" "This component require: RCVar-Component-1"
REQUIRE_COMPONENT "RCVar.tp2" "1000" "This component require: RCVar-Component-1"


PRINT ""

My main motivation for the request was the inability to use ID_OF_LABEL for REQUIRE_COMPONENT combined with the awful syntax required for REQUIRE_PREDICTATE+ID_OF_LABEL.

[Wisp]

...

So shall I close the issue? You are better off requesting some semantic sugar, or whatever would be the proper term for it. I have not looked at it and I reserve the right to tell you it cannot be done, but I could probably do something like REQUIRE_LABEL tp2 label.