Wisp

Jarno wins. The only distinction TP2 makes between stings and integers are which strings are not integers after coercion. This works fine: OUTER_SPRINT myvar "123" OUTER_SET myothervar = myvar COPY_EXISTING sw1h01.itm override WRITE_LONG NAME1 myvar I hate to pick nits but... CamDawg, %string_thats_actually_an_int% is exactly equivalent to "string_thats_actually_an_int". On their own, percentage signs are string delimiters. Inside strings, they delimit variables, but only inside strings.

Well, ninja'd.

So I've been thinking about kit values, because why not? IESDP currently states that the value is stored in a big-endian format, but unless I have really misunderstood the concept, the kit value is not big-endian. It uses a reversed word order, but the words themselves are little-endian. The value 0x80000000 is stored as 00 80 00 00 in the CRE and the value 0x4005 is stored as 00 00 05 40. Were they big-endian they'd be 80 00 00 00 and 00 00 40 05.

aTweaks works differently. Killing the Nabassu does indeed prevent ghastification. But I can't explain this. The spell looks right and in testing a successful save vs. spell prevents all ill effects and a failed save results in strings being displayed (among other things). Incidentally, Death Ward is no protection against Death Gaze.

The version dated 171126 updates the compatibility checks for BG2 Tweak Pack to include Tweaks Anthology.

Note that CREATE takes patches, so you can just write CREATE SPL ~QD_MC_01~ LPF ADD_SPELL_HEADER END

WeiDU's CREATE can make spells.

To find the sectype you can just call ADD_SECTYPE again. There's no need to write new code for the task.

I would be entirely unsurprised if bat files only worked with backslashes.

As far as I know, there are no technical issues. Item Revisions moving items and whatnot is no problem. There might be the odd balance thing, if Item Revisions noticeably changes the power levels of some item compared how I have ranked it in Item Randomiser and if I haven't accounted for Item Revision's change. Say, if Item Revisions were to change the Ring of Efreeti(?) Summoning to be a good deal better, you could end up picking it off the corpse of some comparatively lowly enemy, even though, considering the power of the item, it would be more balanced if you were required to put in more of a fight to obtain it. It might also cut the other way, if Item Revisions nerfs items. In the specific case of the Ring of Efreeti(?) Summoning, it's not a problem, because I have accounted for Item Revisions, but for all I know, there are items that are not yet accounted for. It might also not be noticeable unless you are closely examining things.

I did not want the scripts I wrote to particularly stand out from the ones already written, so running the SSL->BAF process at install-time was largely unnecessary. Yes, it's specific to aTweaks. It's my build script. It runs SSL with input file A, options B to generate BAF C, for all the SSL-sourced BAFs aTweaks needs.

Packaging perl scripts in stand-alone executables is a total hassle. I run SSL locally and ship the resulting scripts. It's less adaptive, but much easier. You can't put your action definitions in your library file. The library file only takes TARGETs and TRIGGERs. Put them in an SSL file called actions.ssl or something and INCLUDE that where needed (this also allows you to group your definitions logically, say one definition file for scripts in bucket A and another for the same in bucket B).

That is correct. Uncombined actions generate BAF like IF Trigger() THEN RESPONSE #such Action() RESPONSE #andsuch // Provided there is such a probability Continue() END A combined action considers all targets and Action()s on the highest-priority target available (or skips the whole thing, on the Continue() branch).

There will a few more component names and probably some new dialogue for Cromwell. Maybe other things, I don't have this whole thing planned out. But feel free to submit you translation anyway. 99 % complete is better than none available.

Thanks for the kind words. It's very belated, but green scrolls have been put on the to-do list (which at this rate, I guess, means they might one day, many years from now, may be randomised; but I promise I'll try to make an effort to do better). Valas Jae'llat is already accounted for. For the rest, I can only account for those I know of, and Firkraag by Revised Battles was not one of them. Most of the issues with Mode 1 are technical engine issues which have no (IMO) satisfactory solutions (or they'd be implemented already). The freeze/slow-down is one of those. It can be made less severe by making the randomisation less parallelised, but that, in turn, makes the total time needed to complete the randomisation (much) longer. But how are items lost? Does the randomisation not finish in time? (I assume there is some form of dungeon-be-gone-ing in that case.) Halting the game (or rather, the party members) would be a rather intrusive thing to do. I'm not fond of the idea of doing it. If you are sufficiently aware of the issue to not be freaked out by the intrusive measure, you should be sufficiently aware to stay put until the randomisation is done.

That's fine. The BGT variable within the function does not affect the environment outside the function. Regardless, I'll probably rename the "outer" variable into Trilogy or something, to reflect its wider use. The rest's been addressed in the version dated 170206.

The version dated 170206 includes less experimental support for EET.

Thanks for checking! I'll be back with a fixed version tomorrow (fingers crossed).

See release thread. Sorry about the delay, my attention has been divided.

The version dated 170205 includes experimental support for EET. It's experimental in the sense I think it should perhaps work, but don't have SoD and can't test it. If someone who has EET could give it a try and report back, that would be super.

Feel free. I can't say I'm immediately sold on the idea. I can foresee several real or potential problems right off the bat, but such a mode would perhaps be feasible. I'm not in a good position to estimate how feasible it would be, or how much work it would entail, however.

I have stuff left on my to-do list. I don't know about 100 %, though. It's been a while and I can't quite remember what kind of coverage the mod has now and how many items remain.

The version dated 160228 fixes a few compatibility issues.

The version dated 160110 introduces the following changes: Randomised potions are not assigned a lore value. Internal changes for fewer bugs. Mode 1 installs on modern Perl environments (only relevant for OS X and GNU/Linux). Add a new framework for allowing specific items and locations to have a unique chance of being included in the randomisation process. The feature is not yet in use. Layene gets a replacement weapon. Reorganise list files into a better-structured system. The Manual of Bodily Health is not randomised on the BG1 engine, due to technical limitations.

This feature is now done. I'll be testing the rewritten code a while longer before I release a new WIP version. I know. As of some version, Perl is stricter about formatting. A fixed version will be included in the next release. Thanks for the report, all the same.