DavidW

Can I have your weidu.log?

Great - glad you got it sorted.

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.

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.)

Still can't manage to reproduce. Can you find the file 'stratagems.debug', zip it, and post it?

Odd. I can't reproduce on a clean install with SCS only. Just a quick sanity check: (i) are you on the latest version of BGEE? (2.5) (ii) did you make sure the game wasn't running while you installed? If the answer to (i) and (ii) is 'yes', can you find the file override/gtimes.ids, zip it, and post it?

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.

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.)

Actually this weekend. v33.5 is now out and should be 247-compatible.

v33.5 is now out, addressing the WEIDU v247 issues.

As general advice when REPLACE_TEXTUALLY fails on a dlg or bcs file: use WEIDU itself to decompile it and look at, instead of NI. You can do it at the command line.

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.

SCS is supposed to do that already, so this looks like a bug somewhere. Do you have the ‘improved demon cult’ component installed?

What other mods do you have installed?

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.

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

Probably this weekend.

I wrote it, and I think it's supposed to work that way. Does that count?

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.)

SCS doesn’t include any of IWDification, so I don’t know what you mean.

The condition is fairly elementary - REQUIRE_PREDICATE (!GAME_IS ~eet~ || MOD_IS_INSTALLED ~eet_end.tp2~ ~0~ ) @24123 - and hasn't been changed since the original release of v32. I've no idea what could be causing the OP's issues.

Noted. This kind of assumes I put it in just to be annoying and make difficulty, rather than because I actually need it for something concrete that I can't work around on the current version of WEIDU.

2.0.14 is now out, fixing that issue with non-English translations and removing obsolete uses of LONG_BOW as a synonym for MAGE_ALL. Apologies to prowler et al that it took a bit longer to get to than I'd hoped.

Define 'works'. Versions 1.5-1.7 were written for 1.3, but they have quite a few bugs.

Sorry, I missed this when you first posted it, but in any case you're probably better off doing your own first pass - I probably wouldn't have had a chance for a while.