DavidW

There is a typo in '2da/dualfc.2da' - a missing space between two iterations of 'AP_D5_DUAFC', so that the file has 'AP_D5_DUAFCAP_D5_DUAFC' instead of 'AP_D5_DUAFC AP_D5_DUAFC'. I doubt it has much visible effect in-game in of itself (it only applies at 25th level) but it means the CLAB files are malformed, and that confuses SCS.

There is a typo in the file 'dualfc.2da' in Tweaks Anthology that's causing this (it's used in component 2450, 'give PnP class restrictions'). If you uninstall that component you should be fine. (Or you can fix it yourself if you like - edit 'cdtweaks/2da/dualfc.2da' in Notepad or similar, find 'AP_D5_DUAFCAP_D5_DUAFC' and replace it with 'AP_D5_DUAFC AP_D5_DUAFC', and then reinstall that component.)

You're welcome. The bug was actually quite general, albeit only showing up on some install choices - I'm pleased to have had the chance to catch it early.

v33.6 is now out, fixing the problem with grodrigues's install.

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

I don't support that tool.

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

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?