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.

On 8/9/2019 at 9:00 PM, Sam. said:

While we're at it, what's the best way to execute on-the-fly code?  Right now I'm writing to a temporary file and then INCLUDE ing it, but I feel like there has to be something better...

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.

5 hours ago, DavidW said:

Do I need the extra EVAL even if I have AUTO_EVAL_STRINGS set? I ask partly because that bit of code is called a lot, so I don’t think it can be systematically failing or I’d have noticed.

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.

17 hours ago, kjeron said:

This is what I still observe in latest patch:

The -M and -L versions won't both be assigned properly (record/sidebar) unless the "M" and "L" are both capitalized.

The portrait will show up twice (only one of which assigns properly) if only one of them is capitalized.

If neither is capitalized, both will be listed, and the chosen one will be used for both slots.

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.

On 7/4/2019 at 6:00 AM, AL|EN said:

How about we leave mod files intact and let mod manager to preform 'ToLower()' ?

Sure. It's not particularly viable for the EEs, anyway.

On 7/4/2019 at 3:42 PM, kjeron said:

I don't have enough understanding of the issue regarding case-sensitivity, so apologies if these are not relevant:

Portrait files still require uppercase in the EE's to be detected and assigned properly.

You can break a mod if you change it's files to lowercase, and it uses weidu's SOURCE_RES/DEST_RES variables from it's own files assuming them to be in uppercase (the game requires uppercase resource strings in some fields).

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.

16 hours ago, AL|EN said:

The source of the weidu/tools doesn't really matter. But when those tools will be copied by manager into the game directory itself, which directory structure they should have, in order for the tp2 code of the mod to use the path?

<GameDir>\IEModTools\iconv-1.16.0.0\iconv.exe

Or did you have something else in you mind? Like global paths "%userprofile%\IEModTools\iconv-1.16.0.0\iconv.exe" ?

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.

16 hours ago, AL|EN said:

Should package system allows top-level directory names which are the same as main game folders?

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.

16 hours ago, AL|EN said:

That's off-topic but is this is also valid for tp3? (If it's not one line answer, we can move this part of the discussion into PPG Roadmap 2 topic)

Yes, once the format is well-defined.

On 6/21/2019 at 11:17 AM, AL|EN said:

Project Infinity also doing this. It's fine for me. I can download/include any kind of tool. Weidu would be copied into game directory. Where the other tools should be placed? Also there or maybe something like <GameDir>\Tools\ ?

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.

On 6/21/2019 at 11:17 AM, AL|EN said:

But what is the reason of bringing this matter now? What's the problem?

There's no problem. You mentioned cross-platform upthread and I got curios.

On 6/21/2019 at 11:17 AM, AL|EN said:

I really need you stance at the filename and package content validation.

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.

On 6/21/2019 at 2:07 PM, AL|EN said:

Not at all. It's a new feature for modders to pin weidu version so they will be sure that new weidu version won't break/change how it installs/act. Then, there is no more of 'backwards compatibility' because mods operate at the defined level of features/functions which won't change unless modder want's implement new feature. You can read more about it at the PPG Roadmap 2 'Stack management'.

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.