Ardanis

I believe it wasn't updated to 3.1 or 3.95, hence it used its own fix for sorting problem discovered later: ...which is the same thing. I requested SORT_ARRAY_INDICES some years ago, and in the meantime coded a local function for DS. Stat names have been updated in EE v2.0 to better reflect what they do, so MELEE_THACO_BONUS have become "official". DMWW_SLOT_xxx were mostly older "don't use it" names first introduced in SCS long, long ago. 3.95 should have all the issues discovered since 2010 fixed and be sufficient for normal users who just want the spells flagged correctly. The 3.95_dw shipped with SCS v32 has a bunch of updates and new functionalities added, which I have briefly checked by diagonal and they seemed fine. They're still new though, and at least one issue have been discovered and fixed between release candidates. It should be noted that David doesn't exactly qualify as "normal" user so I can trust he knows what he's doing and why. One possible point of concern - his version may have some dependencies on SCS-specific environment, so I'd wait until updated SCS is out before trying to update other mods to it. It's fine. DS re-installs itself each time, and tries to fix known issues in previous versions if they can't be eliminated by mere re-install. Hmm, probably not...

Think of ~a~ STR_CMP ~b~ as a shorthand for NOT (~a~ STRING_EQUAL ~b~).

I'm getting old... Same as \2, i.e. the match to second regular expression (blue) in the string: ~\(RESPONSE #[0-9]+[%WNL%%LNL%%MNL%][ %TAB%]+\([^ %TAB%%WNL%%LNL%%MNL%]+\)\)~ These can be nested, and WeiDU counts them as it reads the string, rather than respecting parentheses. ~\(one \( two\) \(three\) \) \(four\)~

COPY_EXISTING_REGEXP GLOB ~.+\.bcs~ override DECOMPILE_AND_PATCH BEGIN x = 0 SPRINT debug ~~ REPLACE_EVALUATE ~\(RESPONSE #[0-9]+[%WNL%%LNL%%MNL%][ %TAB%]+\([^ %TAB%%WNL%%LNL%%MNL%]+\)\)~ BEGIN PATCH_IF ~%MATCH2%~ STR_CMP ~NoAction()~ BEGIN x += 1 SPRINT debug ~~~~~ActionOverride(Player1,DisplayString(Myself,~Running block %x% of %SOURCE_RES%.BCS~)) ActionOverride(Player1,DisplayStringHead(Myself,~Running block %x% of %SOURCE_RES%.BCS~))~~~~~ END END ~\1 %debug%~ END BUT_ONLY

Same issue as Luke's - it's trying to run reindex, and it fails without file extension. Frankly, those functions have been written well before CREATE (in fact, the library file they're from has its own CREATE_SPELL function), so this is a new conflict... but if you only need header additions to new files, then you can just comment the reindex out at line 84.

Strictly speaking, if you create them from scratch then you don't need FJ_SPL_ITM_REINDEX in the first place, it's just a safeguard against non-standard structuring in some files - just comment it out in your code.

I think he wants a full list of names, not values? As long as he avoids overlapping them with duplicates assigned to the same value, it shouldn't matter, as the function will simply read and return the already assigned value. PS So I can't even copy and paste the quote. **** Invision.

Is there some specific reason you need complete list of stats? DS is hardly the only function that adds dynamic IDS entries, e.g. ADD_PROJECTILE is far more widespread and chaotic.

The function checks file's extension to determine its type (spl or itm), and CREATE action doesn't seem to provide one.This works CREATE "SPL" "GTPENAL" WRITE_LONG 0x018 (BIT14 | BIT25) // Castable when Silenced, Ignore Dead/Wild Magic WRITE_SHORT 0x01c 4 // Innate ability WRITE_LONG 0x034 1 // Spell level COPY_EXISTING "GTPENAL.SPL" override LPF ADD_SPELL_HEADER INT_VAR type = 1 // Melee location = 4 // Ability target = 1 // Living Actor range = 1 required_level = 1 projectile = 1 // NONE END

I almost thought there'd be Spanish included

Don't think so, SoD AI works fine with the former. On the other hand, NearestEnemyOf and NearestEnemyOf() do differ, as the latter defaults to by myself, but the former iirc has been also returning objects from non-myself actors as well.

Problem is, it's the door she's trying to add. But otherwise yeah, if something crashes then wipe obvious suspects, and then everything else including scripts, to see if it stops. Then narrow it down bit by bit. PS Assuming IA stands for Infinity Animations, there might indeed be some indirect relation. Check if the code works without it? PPS Maybe a conflict between IA's area patching code and what's built into WeiDU? If there was an update for something EE-specific, and IA is using old code, I imagine it *could* conflict.

I also tried it on vanilla IWD setup, also works fine. Pretty sure it's either something local on your end, or you're doing something else to the area that causes CTD when combined with the door addition. I can suggest to try it on a clean install, and failing that upload/link the whole package that is having the issue.

Works fine for me (tried it in ar0700). There was a parsing error with "fj_closed_box_bottom = 1512" line when I copied it from your post, had to retype it manually. Could be just Invision pulling its usual crap, though.

This may be a pain to do, because unlike vanilla BGs there is a shitload of interconnected conversations pertaining to joining/departure. Will it be enough to severe just "we're leaving together" checks for manual party restructuring, while keeping "we're joining together" and reputation departures intact?

That sounds familiar. Actors will appear at their destination coordinates rather than current ones when the game is saved and reloaded. Namely, JumpToPoint() can cause that, as unlike MoveToPoint() it only updates the current coordinates but not destination. Are your actors spawned via scripts, or embedded into ARE? Any scripted positioning involved?

No idea what's so wonderful about wysiwyg-only interface that trips over itself every minute.

I can't seem to quote or reply in G3 News and Announcements subforum. Intended? I can't find a button in reply form to disable rich text mode. I can't find a switch to paste in plain text mode by default. And this version of Invision seems even worse at formatting overall, I wanted to add some text in the middle of sentence and it instead jumped me to the end of line. How can you possibly keep using this horse shit of a forum software...

Yeah, same as Chaotic Commands. I thought it's been checked more often by AI, but either I've tweaked it out later or only wanted to effectively keep fighters from drinking more than a single combat potion, aka barring the use of innates and healing. It's fine. This message can happen if newer DS uses old launch syntax, but otherwise it's harmless and accounted for.

I think BUFF_ENHANCEMENT may be extraneous here, since it's primarily for stuff like DUHM, Tenser, Fire Shield etc. most of which are not breachable.

Balance wise, I think it makes sense. Too bad you can only be immune to each individual hit but not the whole ticking projectile.

Make sure to test that 0 in script triggers doesn't also return true for "any" kit, like iirc crushing damage type does.

Actually, I now definitely remember you've been reading stats.ids as array (?) and then using 1-200 range to append a blank file. That is, completely destroying any 200+ stat added for ToBEx

As far as IDS files are concerned, the order of entries is irrelevant. Unlike 2DAs, they exist purely for user's convenience when compiling scripts, and might as well have been empty. I'm pretty sure the sorting algorithm was first introduced by David when he updated DS to meet SCS' demands about ten years ago. That version still had inherited some compatibility issues, which I needed to resolve for SR+SCS installations and which brought me to update DS to v3. While I suspect SCS' version didn't actually *need* readability of stats.ids, with the advent of ToBEx and its 200+ extended stats there came a potential problem of multiple ToBEx mods adding their own custom stats with possible conflicts. Since maintaining yet another community list of things hardly seemed like a good choice, I wrote a function to dynamically add new stat entries into the first unoccupied slot - much like ADD_SPELL works nowadays, - and for that purpose sorting entries beforehand was actually useful. Though I'm pretty sure one could do with unsorted mess as well, it just seemed extra work when the file was already being sorted even before I jumped in for maintenance. 318, 324 and 326 only reference either a row in SPLPROT.2DA, or an index in specified IDS. The former does depend on the order of rows, the latter doesn't.

Well shit. This time it's a different error. This one is more opaque to me, but it looks like a counter is going out of bounds in the hidespl.2da, in addition to being copied into override loaded into memory a few hundred times prior to the error. .DEBUG [override/hidespl.2da] loaded, 7171 bytes Copying and patching 1 file ... Copied [book03.itm] to [override/dw#allsp.itm] Copying and patching 1 file ... [./override/stats.ids] loaded, 4606 bytes ERROR: cannot convert ind or %ind% to an integer ERROR: [stats.ids] -> [override] Patching Failed (COPY) (Not_found) Stopping installation because of error. edit: totally understand if you can't get to it tonight, but if there's a file modification or two you'd like me to try, I've got a few more runs of this script left in me tonight. Looks to be happening at stratagems/initial/initial.tpa, line 78: END ELSE BEGIN LAF ds_resolve_stat INT_VAR index=109 STR_VAR id=~WEAPON_ENCHANTMENT~ END // since we use this occasionally even in BG1 scripts, we need it in stats.ids END Best wild guess I have is that something went wrong with stats.ids file, that its entries can't be properly read (the ds_resolve_stat function assumes the rows in the file consist of integer (stat number) followed by string (stat name). If you have some time for debugging, can you add this line COPY_EXISTING + stats.ids debug_stats.ids just before where it throws an error, like this: END ELSE BEGIN COPY_EXISTING + stats.ids debug_stats.ids LAF ds_resolve_stat INT_VAR index=109 STR_VAR id=~WEAPON_ENCHANTMENT~ END // since we use this occasionally even in BG1 scripts, we need it in stats.ids END then run it again and upload somewhere the debug_stats.ids file it will create in the main game directory? This won't solve the issue, but since neither David nor I have an idea what's happening, it may be a step towards discovering the cause.