CamDawg

Yes, but IIRC TakeItemReplace doesn't equip the new item so you'd still need to add a few equip actions.

On the EEs, yes. You can check if both items are equipped, and then use TransformItem to swap the old item(s) to the new, cursed item(s). You can also do it on the originals, but you'll need a lot more commands to remove the old item, add the new one, and then equip it.

https://gibberlings3.github.io/iesdp/files/2da/2da_bgee/sltsteal.htm I'm not sure if this is worth noting, but... while you can pickpocket items out of the weapon slots, you cannot steal the target's currently selected weapon. E.g. if the target has a sword and bow, and the bow is currently in use, you can steal the sword but not the bow.

You may have just timed it poorly--there was probably about a ~15 minute period this morning where I was getting the same 403 message on my normal connection. It happened during a routine forum software upgrade this morning. I asked folks on Discord try with Tor, and the two that tried were both able to access the site.

Are you testing from a save game? Areas are stored in the save game, so if you visited the area prior to assigning the area script, then (as far as that save is concerned) the area has no script.

Are you testing from a save game? Areas are stored in the save game, so if you visited the area prior to assigning the area script, then (as far as that save is concerned) the area has no script. edit: It looks like this topic was double-posted, so I'm going to lock this one and reply in the other.

Turn off gore.

The spell description:

The line right above that reads "When Dorn holds this blade, any death that it causes has a chance to grant Dorn an increase of +1 to his to-hit rolls for 24 hours".

Yeah, the main branch is named v11 because I essentially rewrote major portions of the code for v11, and then made that the main branch when v11 was released. I've never bothered to rename it because it doesn't really matter in the grand scheme of things.

On HP tables, the engine will ignore the static modifier column if a die roll is indicated. If you specify e.g. 1d6+2 the engine will simply roll 1d6 and call it a day.

In BG2 the Patrol leader's Helmet (misca6) is usable by thieves, but shouldn't be. Edit: Kensai, too.

Right, so a few options here: You can branch transitions in state 0 using the same methods and limitations as discussed for DAMBERE. You can add new dialogue (via APPEND) with a new entry state for these alternative circumstances. You then make it take effect either by weighting it ahead of the existing state 0, or add a mutually exclusive trigger to state 0 so that it'll fall to the new entry state. The benefit of approach 2 is that, if Xyunomei's original line doesn't fit the alternative path, this is the best way have her start with a different line. The downside is that having a second, separate path through a previously unitary dialogue is very bad for compatibility--if you pursue the second option, I'd link it back into the original dialogue flow as early as possible to minimize conflict. (As an aside: while you can change assigned dialogue via script, it's even more worse for compatibility. You can expect someone else may branch a dialogue into something unrecognizable, but at least it's the same file.) It would look something like ADD_STATE_TRIGGER DXYUN 0 ~!sometrigger~ APPEND DXYUN IF ~sometrigger~ THEN BEGIN cd_new_entry SAY #123 IF ~~ THEN GOTO 1 // other transitions as needed END // other new states as needed END or APPEND DXYUN IF WEIGHT #-1 ~sometrigger~ THEN BEGIN cd_new_entry SAY #123 IF ~~ THEN GOTO 1 // other transitions as needed END // other new states as needed END

As a quick aside: unless you're doing something that absolutely requires a complicated regexp, you're better served doing dialogue modifications with d code over Ye Olde DECOMPILE_AND_PATCH. Even in those edge cases, there's likely a d code regexp that you can restrict it to triggers or actions or whatever, making it a better option. Circling back to the compatibility discussion there's not really an ideal way to do this. You can follow the original example and EXTEND_TOP. This is bad for compatibility as any other mods targeting transitions in this state will now be off by one. The odds on this actually occurring will vary--if you're doing this to Commoner #8 in Athkatla you're probably fine; if you're doing this to the Tree of Life gut check you're in trouble. You can EXTEND_BOTTOM. This is good compatibility-wise as it preserves the existing transition order. The downside is that your new reply sticks out like a sore thumb because it's no longer in its original order. This is especially true for IWD where the reply options hew to a pattern. You can fork the dialogue before or after. In the DAMBERE example, you could leave the transitions in 9 and look if you could fork them afterward (in state 18) or try to intercept transitions into state 9. This is a hit-and-miss prospect, and you won't be able to do it everywhere. Combining 1 and 2, you add a new trigger to all existing transitions in the targeted state, and then EXTEND_BOTTOM all of the transitions with the opposite trigger added. So instead of A-B-C turning into A1-A2-B-C you end up with A1-B1-C1-A2-B2-C2. It's more complicated and a little more fragile but it will provide a seamless insertion of a reply while not re-ordering the existing transitions.

Yes, the 'DO' clause is how you target individual transitions. In this case it's 'DO 0' so it'll only add the specified trigger to the first transition (numbered starting with 0). If you omit the DO clause it will indeed add the trigger to all transitions. Yep: ADD_TRANS_TRIGGER dialogue_name 17 ~newtrigger~ DO 2

A dialogue state is a state in WeiDU parlance, and replies are transitions. In d code this is trivial: ADD_TRANS_TRIGGER DAMBERE 9 ~Global("D5_IWD_REAL","GLOBAL",0)~ DO 0 EXTEND_TOP AMBERE 9 IF ~CheckStatGT(LastTalkedToBy,12,CHR) !Global("D5_IWD_REAL","GLOBAL",0)~ THEN REPLY #21915 DO ~SetGlobal("Ambere_Family","GLOBAL",1) AddXP2DA("Level_2_Easy") DisplayStringNoNameDlg(Myself,18518) AddJournalEntry(23781,INFO)~ GOTO 10 END EXTEND_TOP isn't the friendliest way to do this, as it re-orders the transition numbers which can impact compatibility with other mods. However, there's no way to avoid this if you want to preserve the reply order. So we're basically adding a new trigger to the original transition 0 in state 9, and then using EXTEND to add a brand new transition.

If the effects are applied via ability tables, they're already removed/re-applied as the NPC joins and leaves. However, I don't think this is the case for any subspells that get invoked unless it's done in a way to preserve the spell source in the effects. Alternatively, if the concern is that you're going to get multiple sets of the same effects you can add a 321 at the top of an effect stack to prevent stacking of unnecessary effects, the same way that normal spells prevent stacking.

In a fixpack, no, and it seemed like someone else was already working on it as a tweak.

From just the appearance on the map I'd say Severed Hand is at the lowest elevation, sitting in a valley. However the uphill trips from the Hand to Dragon's Eye, Wyrm Tooth, or Dorn's Deep are shorter than the downhill trips from those areas. Then just to be contrary the downhill trip from Kuldahar to the Hand is shorter than the uphill trip from the Hand. If there's some information that consistently applies longer travel times in one direction that checks out with the variance, I'm not seeing it. I'm going to circle back to the oIWD maps to see if there's anything to be learned from those.

Well, I thought I had this sorted with the fixes from IWDFP, but after this post I decided to take another look. Here's the current (as of 2.6) worldmap and my proposed changes: Where you see an x/y time listed it means the times are different depending on which way you're traveling, e.g. going from Dragon's Eye to Severed Hand takes 80 hours but Severed Hand to Dragon's Eye only takes 48 hours. As of the current commits, EEFP fixes the aforementioned Dragon's Eye-Severed Hand travel time to 48 hours and standardizes the Severed Hand-Wyrm's Tooth travel time to 288 hours. However, after looking at it, I'm increasingly convinced that times between Wyrm's Tooth to Severed Hand (288 hours) and Wyrm's Tooth to Kuldahar (384 hours) didn't account for the 4x multiplication in link times, and that 72 and 96 hour travel times, respectively, are correct. (Currently you never actually get these huge travel times in game since the engine will route you through Dorn's Deep since it's a shorter travel route, but with the proposed fix you'll get direct, and slightly faster, travel between these areas.) For the others links it's just a matter of standardizing the times to be the same in both directions; like the BG worldmap I chose the lower times. The Heart of Winter map has no issues.

I imagine something like this would be way more useful for something like IWD. From Kuldahar, the Kuldahar Pass and Vale of Shadows are a reasonable eight hours away, but after that you've got the Temple of the Forgotten God (40 hours), Dragon's Eye (72), Severed Hand or Dorn's Deep (80), or Wyrm's Tooth (a mere 384 hours or 16 in-game days). (For what it's worth, I'm pretty sure the Kuldahar-Wyrm's Tooth time is supposed to be 96 hours, but even with the correction it's still four days of travel for a single link.) edit: in case anyone's wondering, no, you don't actually see the 396 travel time in game since the engine routes you through an existing area (either Dorn's Deep or Severed Hand) to get a slightly more reasonable 112 hour travel time.

This is unchanged.

The component is not designed to expand the weapon categories a thief can backstab with--thieves can't backstab with axes, so the component doesn't enable backstabbing with them. What it does is a little more subtle: weapons in categories that thieves can normally use to backstab but are, for one reason or another, restricted from single-class thieves (and therefore can't be used to backstab) are changed so that you can backstab with them. The easiest example is the Staff of the Magi, which is otherwise usable by mage-thieves and fighter-mage-thieves but (without this component) cannot be used in a backstab despite staves being a legal backstab weapon. Other items in BG2 that fall under this: Staff of Curing, Staff of Thunder and Lightning, Rod of Smiting, and the Ninjatō of the Scarlet Brotherhood. I'm not sure if any of the items in the base game from BGEE/SoD and IWDEE qualify, though it's still available so that it can catch mod-added items.

oIWD just works like this by default, which is why IWDEE uses the flag. oIWD Icasaracht (icasa.cre) sets 'icasa' as the script name in the creature file, but all the scripts target her with "icasaracht" which is her value in the actor listing.

The item is g3java2. However, based on the issues you're having I'm guessing you're playing from a save game prior to installing the mod. This may cause problems in the finale as the mod makes a few edits to the worldmap. If you have issues trying to leave the area of the final fight, be warned you may need to use the console (MoveToArea) to get out.