Ardanis

Just a thought - custom settings were specifically put into config file because modder (probably) didn't want to officially support them via tp2 subcomponents, but left a door open for advanced users who know what they're doing. So, I may by now be well behind the train when it comes to mod installation, but isn't BWS supposed to make the installation process easy for normal people, who don't know how to unpack a mod archive or edit a tp2 in notepad? Taking it a step further, IR has its weapon/armor overhaul data stored in easily accessible txt table in the mod's subfolder - done so both for the maintenance ease as well as to allow said advanced players to easily adjust the values. Would it also need to be presented by BWS to the user? Probably not, but I guess you see the direction I'm being a little skeptical of.

ALWAYS OUTER_PATCH ~~ BEGIN PATCH_INCLUDE ~item_rev/settings.ini~ END

Operative question is, does SR need to be fixed for the 2.5 patch? I.e. (I think) does it need this: SORT_ARRAY_INDICES auxil NUMERICALLY? It's identical to SPRINT sort_array auxil LPM sort_array present in v3.95 If you're concerned whether it's better to just use internal WeiDU function, then technically that's what I would've wanted back then. However, if memory serves me well, my macro had a bit of edge over Wisp's implementation either in being able to sort both numerically and lexically in one sweep or somehow else, so I'd rather preserve my macro somewhere in case anybody would ever need its functionality. For the purpose of fixing the v2.5 bug it makes no difference which one is used.

This bug was actually the very reason I asked for WeiDU macro http://forums.pocketplane.net/index.php/topic,28279.msg331141.html#msg331141

Github says "DS v3.95 from RR, with one minor change" is commited by "dawidw", but searching for users only shows one such person from Poland, Poznan. Did David change his name, or github is playing tricks on me?

Ah. If what he has fixed is what has been causing issues, then it should be already fixed in the version I linked above. I knew about the potential issue, but figured it wouldn't normally happen.

I may be stupid or missing something very obvious, but what exactly is broken with DS? I've seen Kjeron's post over there, but I'm not observing anything like that in the builds I have. Is there any link or thread to read about it? The github link is above.

That's easy, but be advised it can't automatically update RR, aTweaks, SCS and Big Picture code to actually use spellstates instead of stats in EE. Someone's gonna bite the bullet and provide platform-sensitive dual triggers to EVAL in their scripts. Also, all AI mods will need to be updated, otherwise if at least one of them installs stats instead of spellstates, then it'll screw whatever Kathos wants regardless.

Unless I'm mistaken, it's still pre-EE version there, without spellstate support. The latest one is https://github.com/Gibberlings3/SpellRevisions/blob/master/spell_rev/lib/ds.tph though I may be unaware if any further issues have been discovered with it.

Exactly. Updating DS to use spellstates in EE games would be very easy and simple, as a matter of fact. However it's up to SCS, aTweaks and RR (and iirc Big Picture too) to use spellstate checks in AI scripts instead of stats - DS can't possibly handle this, as those mods compile their scripts after DS is installed/checked.

I assume the CutsceneID() was that party member? I developed a habit of running all cutscenes by player1 or a dedicated spy actor to avoid potential troubles that may befall the director.

Make c#brxxxx cast c#brxxxy via 146 effect, make your NPC immune to c#brxxxy (via 206), and have it set a global variable you can check in scripts.

Pretty sure HasDLC("SOD") is supposed to do what it says on the tin.

Pretty sure he was heavily involved, at least three years ago when the project was first announced. Btw they've quite improved the graphics since then, character models look rather decent now. Yes, it's nice seeing you back

It's a long story spanning into the second decade by now.

Oh, I see. Thought it was you logging in. I wasn't quite certain, considering how many years have passed, until I saw recent account activity here

Shouldn't that've been posted by your real account... That would at least add more credibility to your claim.

*Checks the pic* You don't look like Jastey to me...

Vanilla is original aka non-EE for me.

Can't see too many people flocking to mod it. BG and NWN stood out because there were few other games to compete with. Today, when games are dime a dozen, it's gotta take a lot more than nostalgia factor for a player to get heavily invested into a rather niche title. So, I think just not putting effort into obfuscating the game's architecture is enough to keep it open for a casual modder.

Congrats... competitors

It's used in BDCUT60.BCS for the dream cutscene.

You pretty much got it. I don't remember if pre disperse was actually working, though. I believe you need to set the fog flag/probability in the area.

Macro alone probably won't be of much help without context. Here is the component launched in tp2 https://github.com/Gibberlings3/ItemRevisions/blob/master/item_rev/item_rev.tp2#L213 And here is the main installation code with links to other required files, so you can simply strip it of the stuff you don't want https://github.com/Gibberlings3/ItemRevisions/blob/master/item_rev/components/weapon_changes.tpa I remember that your unreleased v3 code for updated weapon speed factor component was very much similar to my version, which is basically a smaller variation of the general weapon changes. Yes, translators will need to understand the regexp to adjust the code to new language, but it didn't seem to be much of an issue with IR.

For targets only their highest level matter. Thus F2/M15 is treated as 15th level character.