Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by DavidW

  1. 3 hours ago, grodrigues said:

    Sure. Below is a zip with the weidu.log and the SCS debug file. The error appears first in the Improved Shapeshift component, but is not fatal, and then explodes in the NPC customization.

    I should add that this is a regression as with SCS v33.4 and weidu 246 everything installed fine.


    Can you try unzipping the attached file, putting it into stratagems/sfo/general, and seeing if it fixes the problem?


  2. 49 minutes ago, Guest Rudolf289 said:

    Smarter beholders component fails to install on BG2EE v2.5.16.6 due to the following error:

    SFO: Installing and patching SPL file(s) dw#betel => spin176...
    Copying and patching 1 file ...
    [STRATAGEMS/beholder/resource/dw#betel.SPL] loaded, 442 bytes
    ERROR: No translation provided for @100
    ERROR: No translation provided for @100

    ERROR: Not_found in apply_standard_function: inputs were func=say_name, arguments=100
    ERROR: [STRATAGEMS/beholder/resource/dw#betel.SPL] -> [override/spin176.SPL] Patching Failed (COPY) (Not_found)
    Stopping installation because of error.

    Here's the debug file: https://ufile.io/je4st6ag

    Are you installing directly, or using PI or some other auto-installer?

  3. 6 hours ago, desmond_lochart said:

    I have tried restarting the computer, tried deleting gtimes.ids and replacing it with a blank file, tried simply deleting it and tried uninstalling most of my mods, but no luck. I have even tried uninstalling the game completely and running 'setup_stratagems.exe' on a clean install (only the 'initialize AI components' part of the mod). In all cases, it gives me the same error. 

    If you're getting that error when trying to install that component on a clean install, I'm afraid I can't help you, because on my machine it installs fine, and ultimately I can't fix something I can't reproduce. I think these error messages mean that your OS isn't letting the mod have access to the files it needs to access, but I've no idea why that might be. Maybe try installing the game somewhere else on your HD?... I'm out of ideas, sorry.

  4. OK. For some reason the operating system (on your system, but not mine) isn't allowing WEIDU access to 'gtimes.ids'. I can't see why that would be, though. At the risk of sounding like every computer helpdesk ever, have you tried restarting your computer? That might break whatever lock it's got. Failing that, try deleting gtimes.ids and replacing it with a blank file. (SCS will fill in all the details it needs anyway.)

  5. 4 hours ago, AL|EN said:

    Thanks for quick update. And for switching back to VERSION using actual value instead of translation refference.

    It's because MOD_VERSION is now available in WEIDU. (And, actually, because Weidu v247 accidentally broke TRA references in VERSION, but I'd have shifted off it even if it didn't.) As a matter of logic, mod version number should only be recorded once in the mod; in v246 the only way to do that is through TRA references.

  6. SFO (the 'stratagems functional overlay' function-library in which SCS is written) has undergone some significant changes to take advantage of WEIDU v247, specifically the fun_args MODDER flag. Since I know a few people use SFO for their own projects, I thought I'd describe those changes here. (This will mean little or nothing to anyone who isn't already familiar with SFO syntax.)

    The point of the 'fun_args' flag is that with it set, WEIDU will throw a WARNING if you call a function using an argument that isn't defined for the function. This catches a nasty kind of silent bug, where you mistype the name of a function's argument and so the function uses the argument's default value. I've wanted this for ages, and it's in v247 at my request. It does, however, cause two problems for SFO.

    The first is that fun_args enforces strong typing: it will complain if you send a value as an INT_VAR to a function that has it defined as a STR_VAR or vice versa. SFO (and SCS code written in SFO) was quite sloppy about this, so I've had to go through quite systematically identifying places where it needed tightening up. (I wrote automated code to find these cases, since fun_args itself doesn't give much telemetry: it's in the function_analysis.tpa library in stratagems/lib if you want it.) In doing so, I caught a number of small bugs in SFO itself.

    The second is more complicated. An SFO patch is a set of function=>argument pairs (strictly, it's a set of function=>code pairs, where code evaluates to an argument). But when the patch is executed, not only the argument is sent to the function, but also the variables 'filename', 'file_ext', 'entry_index', 'offset_base', and 'offset_secondary'. A patch command like   do_this=>thing, for instance, ends up generating a WEIDU command like this:

    LPF CRE_do_this_thing INT_VAR offset_base=78 offset_secondary=144 entry_index=0 STR_VAR arguments="thing" filename="firkra01" file_ext="cre" END

    But very few of the functions used in SFO patches actually need all of this information. Many need only 'arguments'. Plenty don't even need that. And so most of them are only defined with only "arguments" (if that) as a variable. Previously this didn't matter, but under fun_args it throws lots of false-positive warnings.

    Since I don't want to have to add a bunch of unused arguments to all SFO's functions, I've changed the conventions. Now, a function used in an SFO patch can have at most one argument, 'arguments' (STR_VAR). It can access filetype, file_ext, entry_index, offset_base, and offset_secondary because they're set in the environment where the function is called; they no longer need to be, and indeed must not be, defined as explicit arguments. (I try not to do this sort of thing more than I can help because it violates function encapsulation, but here I think it's the least worst option.) 

    This also means that if you call an SFO function explicitly (and not via the patch framework) you need to make sure any of the relevant variables it needs are set. The officially recommended way to do this is 

    LPF apply_patches_inline STR_VAR editstring="<function>=><argument>" filename=<whatever> file_ext=<whatever> END

    In addition, if a patch contains 'function=>null' or 'function=>""' it's called without any argument at all. (So the 'null' or "" value won't be seen by the function.)

    There is one additional change unrelated to WEIDU v247. The ini handling in SFO has been broken out into a new function library, lib_ini.tph, which lives in stratagems/lib. This needs to be loaded and then set up separately from, and before, SFO itself is loaded. The new ini library works pretty much the same as the old one, except that if you check an ini entry that isn't actually in the ini file, it throws a WARNING. (You can suppress this with INT_VAR silent=1.)

  7. OK, looking at this more closely: the cult wizard (cult2.cre)definitely needs a level reduction. There are two cult enforcer files: cult3.cre and cultt1.cre . Of these, cultt1 should be being lowered to level 10/10 by the demon-cult component. cult3 doesn't actually fight you - he's just there for the cutscene where the dagger is stolen, and he disappears at the end of that cutscene. Can you confirm that cultt1.cre is also level 15/15 ? That's very odd if so.

  8. I don't need a debug file (not yet, at any rate). 

    Are you installing components in an unusual order (i.e., not in the order they were presented to you)? If so, try installing in the standard order and see if that sorts it out.

  9. On 10/7/2020 at 8:15 AM, Guest madfiddler said:

    Is it intended that player-summoned celestials and fiends do not have instant-casting spells unless the general mage AI is set to tactical or higher? (Newest SCS + some tweaks anthology and rogue rebalancing options)

    Yes. Though it sounds as if it may not be working quite correctly.

  10. It's inert in SCS (as Cam knows) - just leftover test contents. The 'test' subdirectory' of SCS tends to contain random bits of cruft, but they're not actually touched by the mod installer.

    There's some discussion of this particular edge case here as regards PI. My line there was (and still is) that an auto-installer ought to be applying an appropriate logic to identify the 'real' tp2 file, not blindly parsing the subdirectory structure and treating any .tp2 file it finds as a live mod. This particular copy really is just there because I haven't got around to cleaning out SCS's test folder, but there are real (if rare) cases where you'd want to include other tp2 files in a mod - IWD-in-BG2 did it, for instance. (Admittedly, if you're trying to install IWD-in-BG2 via a mod autoinstaller you might want to rethink your life goals.)


  • Create New...