CamDawg

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.

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:

Quote

Also, every time this hits a target, the victim must make a save vs. death at +4 or be disintegrated.

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:

1. You can branch transitions in state 0 using the same methods and limitations as discussed for DAMBERE.
2. 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.

1. 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.
2. 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.
3. 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.
4. 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.

6 hours ago, subtledoctor said:

Or, I can’t figure out what that “DO 0” is doing. Does it limit the ADD_TRANS_TRIGGER to the first transition?

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.

6 hours ago, subtledoctor said:

Here I would only want to ADD_TRANS_TRIGGER the variable condition to the transition that already has the three triggers, i.e. the third transition from the top.

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.

1 hour ago, Endarire said:

Did you still intend to add party rests along the way for overland travel?

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

29 minutes ago, mickabouille said:

So the difference of duration wasn't to account for differences in altitude ?

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.

On 2/18/2023 at 9:28 AM, jmerry said:

Total travel times may be long, yes - but there isn't a single link on the BGEE world map that's more than 24 hours.

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.

6 minutes ago, Dan_P said:

Thanks. That explains the difference for this. Looks like pretty much every creature in IWD has this flag set, as you said. I don't see this flag in classic IWD (in Near Infinity), so must be added with the EE.

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.

8 hours ago, Guest Notsso said:

I'm not sure if mine is bugged or what, but I can't find a java house anywhere? Can someone point me in the right direction?

The Java House is on the Promenade, taking over an existing area. Coordinates are 1500,1750-ish, directly up from Quataris.

edit: there should be a map note for it as well.

Imoen in BGEE still uses two creature files: she's imoen1.cre in the game file, but npclevel.2da will swap to imoen2.cre if you manage to gain a level before meeting her. All of those imoen2 entries in npclevel should be changed to imoen1 to bring her in line with the other joinables.

h/t to Keneth on Discord for spotting this.