[Fixed] Failed to install Smarter Beholders due to mod folder symlink

[CrevsDaak]

Edit: The Smarter Beholders component fails to install if the stratagems mod folder isn't actually on the same folder as the chitin.key, which breaks encapsulation.

Looking at the "extend" action function defined in lib_ietool.tph, it will process it as SSL on its own so the call to ssl_to_baf on line 267 is superfluous if line  268 is changed to:

  LAF extend STR_VAR files=~baldur baldur25~ top=global_steal location=ssl ssl=1 END

This fixes the issue of encapsulation and lets you do installs from a symlinked folder again.

Old, incorrect post spoilered;

Spoiler

Note that this might not be occurring on windows (otherwise you would've gotten more messages about it) but here on line 268 in stratagems/beholder/beholder.tpa, there's an extra "..\" that this function doesn't need to find the proper workspace path and might be causing errors on other Unix systems as well due to the backslash.

  LAF extend STR_VAR files=~baldur baldur25~ top=global_steal locbase= ~..\%workspace%/ssl_out~ END

Don't ask me how I actually installed this version on BGT though, I think I just did it through wine (I need to use it at some point to install Improved Abazigal's Lair) in which case, well, that explains it (well, that and 2 full BG1EE runs).

Edited March 3 by CrevsDaak

[jmerry]

There's a function that converts between backslashes and forward slashes in paths; it was broken in the earliest versions of v35, but has been fixed for some time. That shouldn't be the problem now.

[CrevsDaak]

Nope, it isn't that for sure, even with the backslash it still fails, that actually doesn't matter. The reason why it was failing to install is that this is the only component in the entirety of SCS (at the moment) that fails to install if the stratagems mod folder isn't actually on the same folder as the chitin.key, which breaks encapsulation.

Looking at the "extend" action function defined in lib_ietool.tph, it will process it as SSL on its own so the call to ssl_to_baf on line 267 is superfluous if line  268 is changed to:

  LAF extend STR_VAR files=~baldur baldur25~ top=global_steal location=ssl ssl=1 END

Which fixes the issue of encapsulation and lets you do installs from a symlinked folder again.

[DavidW]

I don't think this can per se be about a problem with symlinked folders. Literally all my SCS modding is from symlinked folders - the last time I physically put the stratagems folder in the game directory, Obama was president.

But I agree that the ssl_to_baf call in smarter_beholders.tpa is redundant given current SFO functionality and that your change is an improvement (except that ssl is an INT_VAR, not a STR_VAR). Fixed locally; if that sorts out whatever symlink problem you're having then so much the better.

[CrevsDaak]

It causes issues with symlinked folders because when given locbase, the extend function looks for the script in stratagems/%locbase% which is then stratagems/../%workspace%/ which ends up pointing to a non-existent folder on the directory where I keep my mods. If your system doesn't lazily evaluate relative paths on symlinked directories, that might be why it doesn't break for you, because mine surely does, and depends on that functionality in order to find system libraries. Note that mixing up stratagems/ and %workspace% is a very rare occurrence in the mod, currently it doesn't happen anywhere else.

If I edit back the extend call to locbase= ~..\%workspace%/ssl_out~ and remove the ssl=1, then place a carefully crafted globa_steal.baf on stratagems/../weidu_external/workspace/ssl_out/, it finds but fails to compile the script, and chokes with this error instead.

[stratagems/../weidu_external/workspace/ssl_out/global_steal.baf]  ERROR at line 1 column 0-36
Near Text: crashingthiscomponentwithjustthisfile
    Parsing.Parse_error
ERROR: parsing [stratagems/../weidu_external/workspace/ssl_out/global_steal.baf]: Parsing.Parse_error

 

As for passing INT_VARs as STR_VARs, it's not good practice, but you can do it. It causes WeiDU to convert it into an integer and thus is slightly more inefficient, but it's possible. It does not go both ways, and it doesn't enforce that the variable is an integer, which is why you usually want to actively avoid it, I just overlooked it here, oops. It's useful because it allows for non-typed variables to be input by the caller, though the callee has to be able to handle an expected integer to not be an integer without causing the installation to fail.

[CrevsDaak]

10 minutes ago, CrevsDaak said:

If your system doesn't lazily evaluate relative paths on symlinked directories

I want to point out that this is something that not even among the different shell builtins you can ascertain a particular standard being followed as to what the order of evaluation is, but the prevalent case seems to be lazy evaluation (only "cd" works differently, most likely to avoid circular behaviour). So differences among operative systems are more or less a given.

[DavidW]

4 hours ago, CrevsDaak said:

As for passing INT_VARs as STR_VARs, it's not good practice, but you can do it. It causes WeiDU to convert it into an integer and thus is slightly more inefficient, but it's possible. It does not go both ways, and it doesn't enforce that the variable is an integer, which is why you usually want to actively avoid it, I just overlooked it here, oops. It's useful because it allows for non-typed variables to be input by the caller, though the callee has to be able to handle an expected integer to not be an integer without causing the installation to fail.

The other reason to avoid it is that it triggers a warning if you have the fun_args MODDER flag set.

3 hours ago, CrevsDaak said:

I want to point out that this is something that not even among the different shell builtins you can ascertain a particular standard being followed as to what the order of evaluation is, but the prevalent case seems to be lazy evaluation (only "cd" works differently, most likely to avoid circular behaviour). So differences among operative systems are more or less a given.

Oh, to be clear: referencing "../%workspace%" is dumb, I don't know why I did it. (It looks like very old code.) Just wanted to note that at least my symlink setup has always been fine with it.

[Axatax]

FWIW, I've never been able to install this component on any version of SCS.  And this is the only component of SCS that's failed to install (also Linux).

I have the logs for this in the pre-35 bug thread but I don't know how to find that now.

 

Edited March 8 by Axatax