Wisp

Could you run something like the following from your game directory: mkdir tmp && weidu --change-log ar1202.bcs --out tmp > tmp/log and zip and upload the tmp directory? The error is being issued by WeiDU's decompiler, so it's within the realm of possibilities that one of your other mods has done something bad, or that WeiDU has done so.

1. Looks like a copy-paste error. The doc was presumably adapted from ADD_ITEM_EFFECT. As it's unused, it's safe to remove (and I've done so). 3. Yes, TP2 integers are signed 32-bit. It was not a good choice for every conceivable situation. 4. SET and [ SET ] are not strictly equivalent. SET takes a syntactic type that allows EVAL and the array construct on the left-hand side, whereas [ SET ] only allows plain strings in the same position. As Mike said, an inlined file is the same thing but is entirely memory-resident and does not leave anything on the file system. Using REINCLUDE on an inlined file is the closet you get to invoking eval on a string in TP2, assuming that's what you want to do.

No, AUTO_EVAL_STRINGS is fine in this case. Sorry, I should have checked. (If you ever find yourself in a situation where you'd need two EVALs, AUTO_EVAL_STRINGS only counts for one of them.)

Questpack's General AI improvements do not touch Kruin. The component compiles a few scripts, EXTEND_TOPs a few more and patches a few spells. But if you install SCS on top, you are probably not going to see much benefit from QP's component (so it's not like you are missing out by removing it). What I'm guessing is the cause of this is this code from sfo/filetype/lib_cre.tpa PATCH_IF VARIABLE_IS_SET ~%spellname%_LEVEL~ BEGIN SET ~spell_level~= ~%%spellname%_LEVEL%~ When you want to evaluate a double variable like that, you need an extra EVAL, I'm afraid. Also, a small note: if you can be sure the variable is, or need the variable to be, an integer, it is safer to use IS_AN_INT instead. It will not return true if the variable is set but is not an integer, the way VARIABLE_IS_SET will. Also, also, another small note: you can give spell level to ADD_MEMORIZED_SPELL as a variable with the kind-of undocumented form: (variable). The form is documented under values, there's just nothing to indicate that it's valid in place of the #number notation.

Are you sure you posted the crashing version of the file? I can't see anything wrong with it [1] and it loads fine into my game. 1. Well, if I look while paying better attention: his items and inventory is all messed up, with many garbage items and the item assignment all wrong. I was just looking for structural defects, so I missed this the first time.

@AL|EN In that case, I don't understand. You want to propose a second new packaging convention, only this one retains platform-specific stuff inside the mod archive? And at that, one that does not include WeiDU in the mod archive, but instead downloads a mod-specific WeiDU at run-time? It seems nonsensical. You are still including WeiDU in the mod archive, just in a roundabout way. Or have I misunderstood? Edit: yes, I have. The WeiDU would be shared amongst mods. Perhaps also relevant is that the interactive-installer parts that setup-mymod.exe and equivalent solutions rely on are slated to be removed (when this happens is, of course, a fun guessing game).

@AL|ENThat's not what desktop entries are for. To associate a file type with a program, you edit one of the mimeapps.list files, or use the desktop file to announce which types the program supports. The desktop file is for the program, not the mod archive.

Can you describe your testing method? When I assign lowercase portraits to Imoen, they show up properly in the dialogue window, sidebar and record screen (BGEE 2.5.17, picking her up after the cutscene with Gorion). They are also in lowercase in the GAM file. Worth noting is perhaps that NI will always show the resrefs in uppercase, even though they are not in uppercase on disk.

I'm okay if people prefer to continue distributing mods as they do now. Hopefully a unified distribution format and graphical front-end for installation has enough merit to stand on their own. But a mod mananger is a de facto requirement for Skyrim, for example, and it does not seem to be any source of unrest.

Worldmap, link entries: IESDP. I can't remember how the probability works. There is the SetEncounterProbability() script action, too.

Sure. It's not particularly viable for the EEs, anyway. OT, but I can't reproduce this. Lowercase portrait resrefs seem to work fine.

A regexp in balthazar_compatibility.tpa is incorrect. swap_out=~IsValidForPartyDialog?u?e("Edwin")~ (? is a postfix construct.)

fj_add_are_structure is the first version of the function. The name was shortened when it was added to WeiDU. OP: you might want to switch to using WeiDU's version. In addition to being supported, there has already been bugs fixed. It also comes with documentation. Vertex values are calculated by bitshifting the y-coordinate of the point into the high word (y << 16) and adding that to the x-coordinate.

Oh, you mean like that. For Zeitgeist I solve this by running the WeiDU process with its working directory set to the game directory and a local process environment that has the tools directory on its PATH. That way the location of the tools is transparent to mods. I have not yet gotten around to making the corresponding change to the relevant WeiDU functions; to allow them to use system executables and optionally free the modder from needing to include the executables in the mod itself. If it's agreeable to you, I imagine you could do the same. The guarantee would then be that if a mod manager is running the show, the relevant tools exist on the PATH and can be called without specifying their location. Excluding all top-level features of the base games is a good idea, yes. Mods should not overwrite anything (but possibly themselves, or an unfortunately named other mod, I suppose) when extracted. Yes, once the format is well-defined.

Zeitgeist keeps WeiDU in the same directory as itself, which could be anywhere the user has appropriate permissions. On account of the version-pinning thing, I am considering more complicated systems, since we'd no longer be talking about 1 WeiDU executable; rather, it would be 1 for each version in play. I propose the location of WeiDU be left as an implementation detail of the front-end, but I would suggest it's in some location that is user-wide, rather than game-wide. If there is benefit in consolidating in the future, it would be safe to do so then. There's no problem. You mentioned cross-platform upthread and I got curios. If I get to decide, I say .iemod. I have no real objections to those restrictions on filenames or package contents, but I see no reason to prohibit override/, tmp/ and temp/. As long as it is not $GAME_DIR/override, it seems kind of arbitrary. I suggest dot-files (and directories) should also be filtered out, or at least the ones used by git. Off-hand I can't think of a good reason for wanting to include dot-files, and if there are any present in the mod tree, chances are they are not intended for distribution in this context. That is not quite an accurate assessment. Backward compatibility will still very much be a thing. Version-pinning would be optional, so all unpinned mods would need WeiDU to remain backward-compatible. It would allow those modders so inclined to get off the ride, as it were, and remain on some specific version indefinitely. Very hypothetically, it would also allow breaking changes to be made, since you could branch off the last non-breaking version and put it on life-support; breaking changes would be opt in. However, it's both exhausting and infuriating to be working against something that makes frequent breaking changes, so I wouldn't expect a great many of those, in any event.

2. Is this not just you basically saying it's so. I might as well say it's an IE mod, hence .iemod. It also has the advantage of being less letter salad. You seem to suggest the distinction has something to do with "source" files, but there's meaningfully no such thing. The "source" files are the mod. 5. Regarding the proposed extension for WeiDU-Linux: absolutely not. WeiDU has been weidu since the beginning (or at least, since it was lowercased by default) and changing it would break all existing scripts and tooling that relied on it. GNU/Linux conventions are overwhelmingly that executables have no extension. You don't get to impose a new convention because you think it would be more convenient. 6. Including copies of WeiDU in every mod was ridiculous in the 1990s, it remains ridiculous today and it would be pants-on-head silly if "mod managers" were to get involved. The "mod manager" can simply include or download the appropriate version of WeiDU and essentially have it all handled behind the scene. Zeitgeist already does much of this. As a side note: ALIEN, have you investigated the possibilities for cross-platform support for your tool? I'm not at all knowledgeable about C#, mostly because while the language is cross-platform, the libraries and frameworks you'd use to create a Windows program were not. The corresponding stuff that were available for GNU/Linux is obsolete on Windows and on macOS you'd use something different that only worked on macOS. But maybe that's changed by now. Sweet dog is the quote button an exercise in frustration now!

How far along in your learning are you? I wrote a quick introduction for getting started with WeiDU: the files and folders you'll need, the basic structure of a TP2 file, posted here. If you have yet to get this far, I'd say it's still a worthwhile read. As for using functions, for a patch function, you would open a buffer, typically with COPY_EXISTING and invoke the function. Function documentation can be found in the WeiDU readme (functions are under the macro listing). The IESDP is also a good resource for documentation of the file structures. This code changes the Wand of Fire into having 1 recharging charge: COPY_EXISTING wand05.itm override LPF ALTER_ITEM_HEADER INT_VAR header_type = 3 charges = 1 drained = 3 END BUT_ONLY As the name implies, the function ALTER_ITEM_HEADER changes values in an item header, which is where charge behaviour is located. Other functions can be used to do other things. The function selects all headers of type 3 and changes the charge field to have the value 1 and the field for charge-depletion behaviour to have the value 3, which is daily recharge (see the IESDP). BUT_ONLY applies to the COPY_EXISTING action and means that the file will only be copied if the applied patches change the contents of the file. It's good practice to have it on all your COPY_EXISTINGs. Updating charges in areas, creatures and stores is similar, but off-hand I can't recall if there are ready-made functions for all of it. It also involves finding the areas, etc, that hold references to the item. Updating the item description is most easily done by writing a new one and using the SAY patch to write it to the item and add it to the game. This is left as an exercise for the reader. I hope that helps and feel free to ask questions.

That depends on what you mean by proficiency. Item Randomiser still relies on the BG1-style proficiencies and does not add any BG2-style proficiencies. As far as I could tell, there was no need, as the BG1 ones worked just fine. But I understand that some mods have started patching away BG1 proficiencies and I don't think I've yet updated Randomiser to take that into account.

When you start the BG2 portion of your game, it is effectively the same as starting a new game, as far as IR is concerned. You should not encounter any issues at all, not even on account of your slightly different mod setup. You are correct that spawning creatures would not work. The best way to test would be to use to console to take you to one or more areas where you'd find random items. Happy gaming.

Do you recall if Hindo's Doom was one of the items you picked up from Abazigal? If so, it wasn't being equipped for some reason, but at least he got a weapon into his inventory.

When you say "pure" I imagine you were not prompted by Item Randomiser for whether you wanted the mod reinstalled with save compatibility or not (because the files that would make IR issue such a prompt would not be present in your game). It might still be fine, however, as Mode 1 is light on install-time randomness and stores most or all of its state in your save. If you installed the same mods, none of them were random in a way that would affect IR and installed the same options for IR, the probability of things being fine increases. I'd suggest you continue playing for as long as you don't notice anything amiss. Mode 1 randomises everything [1] at the start of the respective game (Candlekeep, Irenicus' dungeon, ToB starting area). It then uses a system of if variable such and such has this particular value, put the corresponding item in the area you are in, with the area you are in corresponding to the value of the variable. As such, if game state is the same before and after reinstallation, things would continue to work. However, if game state is mismatched, there is likelihood of problems. Your saved game notably stores areas you've already visited in the state they had when you visited them (plus whatever changes your made to them in-game), and if you visited them before reinstallation and their state were different after reinstallation, that state-change would not be reflected in you game. For your question 1, no, items would continue to be randomised, for 2, this is the likeliest kind of issues, if there are issues, and, 3, uninstalling is not without its share of problems either, as randomised items would be missing from areas you've already been to, but would never be found, as they would not be present in the area inside your saved game, because that's one kind of those state changes. 1. Not everything everything. BG1 items in Candlekeep, BG2 items next, etc.

Oh, upload the file randomiser.debug as you normally would.

I forgot: can you also upload the debug file?

I'm glad you had a good time. If you still have the files and have not made any changes to your mods, could you upload the files weidu.log, override/fl#randomseed.2da, override/fl#removeditems.2da and override/randoptions.2da? There's a system for ensuring Abazigal gets a random weapon and he seems to be getting no less than 2 when I test. Possibly some other mod is causing interference.

You need to exclude the legacy files from version control. Tags (and github releases are tags) you create include all tracked files; they are essentially a snapshot of the project. Alternatively, do like Mike suggested and do not mind having the legacy files present in the tag, but exclude them when you create the archive you intend to distribute.