jastey

Sarah is a female human ranger of chaotic good alignment for BGII. The mod offers romance possibilities for a female protagonist.

Version 6 fixes an EET install error, some minor fixes, and adds a Russian Translation by tipun.

• Readme
• Project Page
• Download

Auren Aseph is a is a NPC mod for BG2, featuring a young and eager fighter from Beregost. She was born to a middle class merchant and his wife, and grew up a headstrong girl. Her father would tell her stories of adventurers he'd run into while on his caravan routes, and Auren became more and more interested at the thought of adventuring as she got older. She'd spend hours every week at the famous blacksmith Thunderhammer's shop, staring at all of the many types of weapons and armor, both magical and non-magical. Auren also features an original soundtrack, which is also available separately on the downloads page.

Version 11 fixes an EET install error and provides an .ini file with mod metadata to support Project Inifnity.

• Readme
• Project page
• Download

Added the following mods for SoD compatibility:

• Ajantis BG1 Expansion
• Endless BG1
• Jastey's SoD Tweakpack

Imoen4Ever updates to v5! Because of the new content and the changed components structure with more optional choices the mod package will have a beta tag until I get more feedback and bug reports.

Version 5 comes with SoD content: Imoen will rejoin the group at the first camp after marching out against the crusade. Just leave the camp via the road in northeast direction and Imoen will appear and ask to be taken back into the group. After that, she will be available as a normal joinable NPC until after the PC's fall at the end of teh game where the original game content will kick in again.

The changes to her dialogue after the poison attack was moved into an optional component, as well.

New content is also the possibility to chose Imoen's BG1 or SoD portraits in SoD, make her a continuous NPC in all of SoD (including the end), and seeing the "Imoen trains with Duke Jannath" scene from the scrying pool as a separate cutscene when the PC sets out against the crusade.

Version 5 also comes with non-destructive disabling of Imoen-related reply options. Thank you very much to @argent77 for the coding help!

The mod has now 12 components, 5 for BGII and 7 for SoD. For detailed descriptions, please refer to the readme directly:

1. I4E in BGII: Imoen Returns after Talking to Gaelan in Chapter 2 (required for BGII content)
2. I4E in BGII: Give Imoen Dialogue Content in SoA
3. I4E in BGII: Yoshimo Comes to Brynnlaw
4. I4E in BGII: Give Imoen Protection Spell in Chapters 2 & 3
5. I4E in BGII: Compatibility with Alternatives and Saerileth (note: this component should be installed after the Alternatives and/or Saerileth mods.)
6. I4E in SoD: Imoen Remains in Group in Korlasz' Dungeon (this or component 7 is required for other SoD content)
7. I4E in SoD: Imoen Returns to PC in First Coalition Camp (bd1000) (this or component 6 is required for other SoD content)
8. I4E in SoD: Imoen Gives Better Reason to Stay Behind in Palace
9. I4E in SoD: Play Cutscene With Imoen and Duke Jannath
10. I4E in SoD: Give Imoen Dialogue Content in SoD Chapters 8-12
11. I4E in SoD: Imoen at the End of the Game Should be the One that Was in Party (SoD Only)
12. I4E in SoD: Unify Imoen's Portrait:
    1. Use Imoen's SoD Portrait after Korlasz' Crypt
    2. Use Imoen's BG1 Portrait in all of SoD

Added Imoen Friendship (v3.6) to the list of compatible mods.

First post updated with new description of the changed mod structure for v5.

Transitions will also overwrite EBG1's Imoen-Duke Jannath component with own content from it's main component.

4 hours ago, Lauriel said:

You can have a home with a chest whose contents will transfer to SoD camp chests

EBG1 transfers the contents from the "PC's chest" and "Imoen's chest" (3rd floor Palace) to the SoD equivalents and did so from v1.

@AL|EN did you ask @Wisp for a feature request? I wouldn't mind posting one but I still don't exactly get what exactly is needed here.

On 9/7/2020 at 9:28 AM, AL|EN said:

the only workaround would be to to this 'sync' thing which might fail.

What would that be? Is giving this weidu support an option? As much as I would like to support this, I have several mods where global install orders for the whole mod really doesn't make sense.

51 minutes ago, Guest ArcNKD said:

I would like to use ARC-X as my prefix, if anyone is still around to register them?

In addition to what Jarno said, also keep in mind that the max letter count of IE files is 8, and for areas it's 6 (because of the light map, search map, and height map which have LM/SR/HT in their names by default).

2 hours ago, Endarire said:

I wrote what I saw in the documentation.  I've not yet played with these mods enough to fairly state otherwise.

Ah, yes it gives a warning in the readme indeed. I wasn't aware of that.

@Clockwerkthank you, I just wanted to make sure it's not a bug report that needs to addressing.

@Endarire why do you write that Region of Terror's kits do not work for BGII:EE?

4 hours ago, DavidW said:

My main concern about reliability is that I don't really trust people to reliably work out the preferred install order for mods, including their own mods, so I'm unconvinced this will converge on truth rather than ending up messy or self-contradictory. But I'll be happy to be proved wrong.

I see this more for the things where the modders *know* about dependencies. I am thinking about included crossmod content (which only works if the mod is installed after the one it has crossmod for), known dependencies, known incompatibilities depending on install order etc. Almost all of my mods have some such and I would appreciate a possibility to be able to specify the ones I know about. The reason for the idea of putting this into the mods themselves was the knowledge that an overall mod order list will not work because noone will contribute to it (in the long run).

But yes, of course there could be cases where modders tagg their mod wrongly and PI might take the blame. But would this be a reason not to integrate something like this? It's a good question.

Aah, that makes a lot of sense! This is one of the things where I see it clearly afterwards but needed a second pair of eyes to realize.

Thank you - again! - for your insight and patience.

I hit one problem I am sure is on my side. If I use an OUTER_SPRINT for the stringref numbers, e.g.   %63960% => 1. Is there anything obvious why it would work for SoD, but not for EET?

This is what I use for both games inside a tpa:

This is from my tp2:

For SoD, it installs and patches fine.

For EET, it does not patch anything in BDIMOEN, and gives error messages for the other dialogue files:

Since the definitions of the OUTER_SETs are set and the structure is completely the same for both games, I am at a loss what the problem for EET would be.

Oooooh. Nice. I didn't understand that's how this works. Awesome! Thanks for your patience.

Thanks for the list @Endarire!

This is not my field of expertise. If anything should be done to DSotSC and/or NTotSC how the spells are added / compatibility checks / better coding standard etc. let me know and I will integrate it. That also goes for Region of Terror, I suppose..

What do you mean by this?

9 hours ago, Endarire said:

Region of Terror
Adds new spells that, according to the readme, are "mostly kit-specific."  These kits also don't work with Baldur's Gate II: Enhanced Edition.

Sorry for being daft. I don't see how I would call several reply option indeces in the same state. Currently, I get one idex per state. E.g. for state 39, the reply option index with the matching string is stored in %responses_39%. I call it inside the d with:

ADD_TRANS_TRIGGER ARAN 39 ~Global("C#IM_ImoenStays","GLOBAL",0)~ DO %responses_39%

For calling more than one I would need several variables for the different reply option indeces of one state which I do not see in the current version of the code.

I see. That's a very powerful feature you are planning there for mod install order, awesome.

Would you consider writing a best practice tutorial how to make a mod compatible and ready for PI? For example I had no idea the LABELs would be so important (and also not in this global range). I am absolutely willing to make my mods PI compatible but I need good instructions so I know what to add where without the feeling that I do extra rounds because I didn't know everything on time or - even worse - didn't know how to implement it so it would be useful.

And: if I name my LABELs tp2name_componentname (without my prefix) it would still be unique, no? Because there are no two mods with the same tp2 name due to compatibility reasons. So, including the prefix to me is less of making the label unique, it's more of being able to spot quicker which other mod(der) the referenced LABEL belongs to (?).

I still don't understand. What does PI do with LABELs, i.e. use them for? I thought they are for mods to be able to detect/forbid other components, either from its own or from different mods. But that's code that is coded into mods. Why would get PI confused if a mod component moves and gets a new LABEL if all mods using it would be updated, too?

I would need help to adjust this structure so it also can store several reply option indexes for one dialogue state, and would be very happy for help.

// List of all potential response strrefs to check
ACTION_DEFINE_ASSOCIATIVE_ARRAY response_strrefs BEGIN
  43058 => 1
  49175 => 1
END
  
COPY_EXISTING ~aran.dlg~ ~override~
  // scanning listed dialog states
  PATCH_FOR_EACH state IN 39 70 BEGIN
    LPF GET_RESPONSE_STRREFS INT_VAR state RET strrefs RET_ARRAY strrefs END
    TEXT_SPRINT indices ~~  // a temporary variable for building the index list
    FOR (i = 0; i < strrefs; ++i) BEGIN
      SET value = $strrefs(~%i%~)
      // Include index only if strref is listed in the response_strrefs array
      PATCH_IF (VARIABLE_IS_SET $response_strrefs(~%value%~)) BEGIN
        TEXT_SPRINT indices ~%indices% %i%~ // building list of indices
      END
    END
    // prevent adding a trigger if index list is empty
    PATCH_IF (~%indices%~ STR_EQ ~~) BEGIN
      TEXT_SPRINT indices "IF ~a_nonexisting_trigger()~"
    END
    // initialize variables responses_39, responses_40, ...
    // EVAL is used to create the variable name dynamically
    TEXT_SPRINT EVAL ~responses_%state%~ ~%indices%~
    PATCH_PRINT ~Variable %state%: %indices%~
  END
BUT_ONLY

Is this already ready for implementation? I thought we got stuck in discussion about features. Is the problem about tagging mod components differently solved? Because I'd definitely need that.