DavidW

OK, I think I've fixed this and the smart quotes.

I hadn't realized you were a convert to external backup - I thought you did it that way in EEFP just to humor me. If you are using it, my suggestion is to back up to weidu_external/backup/[my_mod], just to control clutter. But of course if you just create a modder-prefixed folder in weidu_external and do everything in there, everything will work fine. The way I set up weidu_external, you should be able to do all of this in weidu_external/workspace - the assumption is you should only ever use that subfolder for fire-and-forget on-the-fly creation, so it doesn't need a modder prefix. It's my method originally (since 2013) - see this thread. Originally it required a bit of hackery, because HANDLE_CHARSETS didn't support choosing a directory. Wisp added it in v247 to accommodate my encapsulation goal, and Alien did a very nice tutorial. For the 'course in WEIDU' I was inclined to leave multiplatform installation out just on scope-management grounds, but that may have been a mistake.

I had in mind that if you ship your mod once it's installed, its backup folder will be full of cruft. Actually the more serious reason to use weidu_external is for mods being installed on multiple different games: in development, you can have one copy of your mod that's linked through a virtual directory link to the game folders of many games, and not have the install structure on one game confuse another game.

I can't reproduce this on EE: even if my test PC is protected from undead, Kangaxx still initiates dialog with her at 1hp. And that seems to fit what the IESDP says about StartDialogueNoSet - if the target is invalid it defaults to Player1. (But possibly I'm missing something?)

How did I miss those highlighters? Good advice, will add.

That's a pain: noted.

This is a course in basic-to-intermediate WEIDU. The level is somewhat uneven: Chapter 1 explains the basics of WEIDU without assuming any prior modding or programming experience, and I hope should be helpful to new modders. Chapter 2 is a more sophisticated and in-depth discussion, focussing on using WEIDU as a programming language (and de-prioritizing specific applications to IE games); I hope intermediate WEIDU users will find it a good way to get to the next step, and even advanced users might learn something. Chapter 3 discusses some specific programming tasks relevant to IE games. (background: For a while, and in odd moments, I've been writing up some notes for a guide to modding in WEIDU - covering the basics, but then moving on to more advanced, programming-language, aspects. There's certainly more that could be done to improve it but I think it's probably solid enough to be worth posting. Comments welcome.) Course link (HTML) Edit, 14/12/23: Version 1.1 of the course is now available. Changelog: Moved to HTML. New chapter on advanced techniques (immutability, encapsulation, optmization). New section on error handling. New section on mod component structure. New section on the APPEND function. Variable section discusses scope. Function section discusses macros. New appendix that explains what's where in the official WEIDU readme.

So this is a broader issue about the extent to which descriptions should be updated. My own view is that a Fixpack should not be writing its own text for descriptions (or anything else) except as an absolute last resort, because 1) It is really stretching 'developer intent' to actually write new text. 2) It localizes the Fixpack to those languages in which we can provide our own translations. Since IWDEE's version of the Summon Nishruu description is demonstrably what the developers actually intend the description to look like, I think there is a very strong developer-intent case for using it, even before we get on to the translation issue. But clearly there's room for discussion here.

Just noticed this example... this is why I came across this issue lots in SCS. My mage code runs into the Cult Enforcer, thinks, 'oooh, a 15th level fighter/mage', and hands out appropriate spells and scripting. But of course if the level isn't reliable, you can end up with some bizarrely over/underpowered creatures. Later versions are a bit more assiduous at choosing sensible levels. Come to think of it, you might want to look at 'stratagems/initial/bg1fix.tph', in SCS. It's my old list of fixes to BG1 files (going back to 2007) and it fixes a bunch of oddCRE file assignments (though of course SCS could work with a laxer standard for 'is it a bug?').

This just came up in another thread so I thought it might be worth writing general instructions. There's a function in EEFP ('get_strings_from_game') that will collect a set of specified strings from the tlk files of any IE game. (For instance, if a spell description is more accurate in IWDEE, we might want to get the IWDEE line and bring it over.) The advantage of automating this is that we can get the strings from all languages at once, without worrying about having to have the line translated. The function runs offline - i.e. it shouldn't appear in live code. To use it: 1) Install the fixpack in the game you want to copy from. (I tend to put directory junctions from my master copy to all the games, but you can just copy it.) 2) Add a temporary component to the tp2 that looks like this: INCLUDE "%MOD_FOLDER%/files/tph/dw/get_strings_from_game.tph" OUTER_SPRINT $strings("35786") "" // 35786 is the strref of the string you want // add any other strings you want in the same format LAF get_strings_from_game END 3) Run that component. The string(s) will be added to a tra file in the %LANGUAGE% subdirectory for every language in which the game is installed. (For instance, if you copied from IWDEE, it will be entered in %MOD_FOLDER%/lang/%LANGUAGE%/copy_from_iwdee.tra.) The tra ref is the same as the original strref: in the example above, @35786 will be set to the string at strref 35786. 4) Uninstall the component. (The edit is permanent: it won't be wiped on uninstall.) 5) Remove the temporary component, and make sure your master copy of eefixpack is updated with the contents of the local copy you've been working with.

OK, @35786 in lang/%LANGUAGE%/copy_from_iwdee.tra is the IWDEE description for Summon Nishruu.

Just take the documentation from IWDEE (which actually mentions the energy damage). Then we get all languages simultaneously. There is code in the FP to autoextract a string from all the different tlk files in a game - hang on a sec and I'll run it for that string.

It's more that I can't see any advantage. Why not (e.g.) be able to extract a subspell with different bits that affect characters at different levels, or that has some opcodes where those fields aren't interpreted as min/max level?

It's not being ignored. It's present on the subspell. It is certainly relevant if the subspell scales with level... Point.

From experience with SCS: this is a can of worms. At least in oBG2, it's fairly clear that the developers started off with a bunch of creature stats imported faithfully from AD&D, but then built a large fraction of creatures by ad hoc copy-paste-and-tweak from the existing creatures, with little or no attention paid to any overall logic. Beyond the most egregious cases, I'd probably recommend leaving well alone - I think finding any stable consistent definition of 'fix' will be difficult.

Do it in the Calling?

This is a bit puzzling actually. Both the Nishruu and the Hakeashar use the same weapon (nishruu.itm), which both drains charges and removes spells. In oBG2 Summon Nishruu is described as draining both charges and spells. BD intentionally changed the description of Summon Nishruu at some point to remove the mention of charge draining, but didn't change the actual spell (Nishruu definitely drain charges in BG2EE, I've just checked directly). The BD change clearly happened after IWDEE's spell resources were cloned from BG2EE, so IWDEE has the unchanged description. My inclination would be to say that the description change was erroneous and revert BG(2)EE to the old description (we can steal it from IWDEE). But I'd be interested if @CamDawgor someone has inside information here.

Theoretically yes, though in both cases I think it's harmless.

Makes sense. I suspect something as subtle as those opcodes probably should be treated manually anyway, but noted. That I'm not seeing. What's the advantage? (The obvious disadvantage is that it means all effects need to have the same min/max level Does type do anything relevant here? This is sensible. This I don't understand. It's a subspell - when can its icon be seen?

The same problem with any naming scheme that doesn't use a modder prefix: you can't be confident that someone else isn't occupying the same region of namespace. In practice it's probably safe in the context of a FP, but I think there is a good general principle that says it's better to always use modder prefixes rather than deciding on a case-by-case basis whether it's safe enough. I don't think there's any particular advantage in doing so, not least because if you did, the extracted blocks indeed need to conform to a constraint they wouldn't otherwise have to conform to. (But persuade me otherwise, I could be missing something.)

There are a couple of functions I've written for the fixpack that make rearranging block order (and also extracting effects to subspells) a bit easier -

I've written two functions for the FP, both in %MOD_FOLDER%/lib/dw_functions.tph. permute_effects is a patch function: here's its documentation. extract_effects_as_subspell is an action function: Please use freely (and let me know if you find bugs; one of the reasons I code this way is so that the nastier bugs stay in central places and can be fixed centrally).

Doing spell/item immunities properly requires some rearranging of the order of effects in spell/item headers, and some extraction of effects into subspells. I wrote a generalized framework to do this, which might be useful for some other bugs. It's controlled by the rearrange_itm_spl function, in %MOD_FOLDER%/files/tph/dw/rearrange_itm_spl.tph. That function runs at the beginning of the dw_fixes section of the FP (though it could easily be moved elsewhere). It looks at the (hand-generated data) in this folder: %MOD_FOLDER%/data/rearrange/[game]. ([game] is bg2, bg1, iwd, sod - as appropriate). That folder contains 3 files. reorderings.txt defines permutations of effects, and looks like this (all examples are from bg2): object ability permutation ax1h10.itm -1 1,0,2 blun12.itm -1 1,2,0 blun25.itm -1 1,2,0 hamm10.itm -1 1,2,0 hamm11.itm 0 1,2,0 dwfpdeva.spl -1 2,1,0 dwfpohdv.spl -1 2,1,0 In each row, the first entry is the object (an itm or spl file) that needs its blocks rearranging. The second is the header that gets rearranged (-1 if all should be). The third entry is a permutation: a comma-separated list of the first N nonnegative integers. So the permutation '1,0,2' says: put block 0 in location 1; put block 1 in location 0; put block 2 in location 2. (In all cases, these entries are to organize an undead-disrupting weapon's effect stack so that damage comes first, then the death effect, then the 'you die' message.) item_subspells.txt looks like this: itm ability subspell extract deva 0 dwfpdeva 4,5,6 ohbdeva 0 dwfpohdv 0,1,2 spermel 0 dwfpsmst 11,12,13 spermel 0 dwfpsmsl 1,10 wand12 0 dwfpwwfs 5,15 wand12 0 dwfpwwhs 3,4,14 note the interweaving of the last two In each row, the first entry is the resref of the item to be patched. The second says which ability block is to be patched. The third is a new spell (and so needs to be unique, with a modder prefix - and in my case a modder subprefix so I don't worry about overwriting SCS!). The fourth is a comma-separated list of effects. All those effects (counting from 0) are extracted from the item and placed in a new subspell that the item casts. Probabilities and saving throws remain on the parent item; everything else gets moved to the subspell. (So all the extracted blocks need the same probabilities and saving throw data, and it doesn't make sense to extract a damage-doing effect that uses save-for-half.) (Incidentally, you can reuse a subspell if you're 100% confident that the contents will be exactly the same.) spell_subspells.txt looks like this: spl track_levels subspell extract insanity 0 dwfpdgfb 6,7 insanity 0 dwfpdgcn 0,1,2,3,4,5 It works basically the same way, for spells rather than abilities. The main difference is that all headers get the rows extracted (so this shouldn't be used with spells that have different effect structures at different levels). By default the code assumes that the effects are exactly the same at each level; if not (e.g. a varying duration) set the second column to 1. (In the example above, note the order - we need to extract the later effects first, because extracting the earlier ones will renumber the later ones.) rearrange_itm_spl first does the subspell extractions, then the permutations (so you can permute a subspell). It then does a small number of rearrangements that are too complicated for this automated structure (currently, only 3 White Doves). You can also do permutations and extractions on a per-item basis, using the underlying functions that these tables rely on (located in dw_functions.tph, currently loaded in the ALWAYS block). I'll put them in a separate post.

SCS actually has enemies summon elemental princes, as a point of interest. I don't recall if I nixed their XP, but anyway, that's a mod issue where the rules are different.

Elemental princes are never summoned by your enemies in the unmodded game (not least because you might accidentally end up with two of them). So the designers can't have intended that you get experience for fighting enemy-summoned princes. The only function that their XP serves is that the player can summon them specifically to kill them. (In BG2EE, they won't even fight back.) It seems really unlikely that that's intentional, especially since the elemental princes are obviously clones of actually-fightable princes and it's extremely easy to see how the XP could have been left in place.