argent77

Correct. They will gather at designated meeting places where you can either let them join as regular party members or hire them as followers. Yes, their dialogs provide options to freely switch their roles between party members and followers. You can't access their gear while they're just tagging along. But it's easy to make them temporary party members (provided you have a free party slot available). As followers they also don't gain experience. This is one issue I'm trying to solve eventually. That wouldn't be advisable. Game NPCs or dedicated NPCs installed by other mods usually have scripted events, dialogs, quests, etc. which might not work correctly if they are not regular party members.

NPC Generator Have you ever regretted that the game only allowed you to create an initial party consisting of the protagonist and (with some effort) a small number of additional characters? Not anymore! This mod allows you to install any number of pregenerated or exported characters as regular NPCs. They can be met at predetermined locations where you have the chance to invite them into your party or have them tag along without occupying party slots at any time in the game. The following games and game variants are supported: - Original BG2 - Tutu/EasyTutu - BGT (Baldur's Gate Trilogy) - BG:EE - SoD (Siege of Dragonspear) - BG2:EE - EET (Enhanced Edition Trilogy) - IWD:EE The mod is currently available in English and German. Download: GitHub Discussion: G3, Beamdog Readme

NPC Generator Download from GitHub Readme Introduction This mod allows you to install any number of pregenerated or exported characters as regular NPCs. They can be met at predetermined locations where you have the chance to invite them into your party or have them tag along without occupying party slots at any time in the game. Kicked out NPCs can be instructed to wait or return to the original meeting place. Note: The mod isn't registered in the WeiDU.log and can therefore be called at any time and as often as you like to install or remove NPCs to or from the game. The mod supports the following games and game variants: Original BG2 Tutu/EasyTutu BGT BG:EE SoD BG2:EE EET IWD:EE It is currently available in English, German and Russian. Components 1. Add custom NPCs to the game (for BG2, Tutu, BGT, BG:EE, SoD, BG2:EE, EET and IWD:EE) With this component it is possible to install any number of individual characters or all available characters at once. They can be met at predetermined locations based on the game campaign: This component provides two installation modes: Manual NPC installation A character selection menu allows you to select one or more characters for installation. The mod scans the "characters" folder for exported character files and/or characters in the game resources (depending on selected option) and lists available characters with a short summary of gender, class/kit and level. Automated NPC installation This mode is controlled by the file "settings.tpa" which can be found in the mod's base folder. Installation requires no manual input and is therefore the best choice for mod managers or scripted mod installations. 2. Enable/Disable alignment checks for custom NPCs (not available for IWD:EE) By default installed NPCs won't always join or follow the party right away. If their goals don't align with the party's they might ask for a fee or outright refuse to join. With this component it is possible to toggle this check on or off. When disabled then every installed NPC will automatically join or follow your party when asked. NPCs in IWD:EE will always join or follow your party when asked. The requirements for NPCs are as follows: 3. Remove custom NPCs from the game This component allows you to remove installed characters from the game. You can choose whether to uninstall selected characters individually or all installed characters at once.

They're not always true, but triggered only if the party has learned how to build golems. Otherwise the original always-true state takes over. In the former case the party can purchase a good number of materials related to golem construction. Problem is that the opening line of the original state doesn't really fit the party's request or I would have used it instead. Basically this original always-true state is overridden by these two lines if the right conditions are met: For a potential solution, I could return to the original state if the opening line were more fitting. That would at least solve the first part of the conflict.

I see two main issues that have to be solved somehow. 1) GC adds two new opening states which override the original states when the Illithium quest is completed. These states (obviously) don't include the additions from this mod. 2) HA seems to replace Jerlia (and her dialog) by mod versions at some point which (likewise obvious) don't include the additions from GC.

I see one of the mod components affects Jerlia the Ore Merchant. This may conflict with the Golem Construction mod which also expands her dialog quite a bit. Judging from a quick test it looks like the new dialog options from this mod may not be available if both mods are installed.

Yeah, that's basically what I would do. In any case the special naming scheme "SPPR" isn't really needed for this spell.

From what I can see in the list of hidespl.2da versions the spell is most likely added as SPPR738 in HIDESPL.00003.2DA to the table (that's the original SPL resref before being installed by ADD_SPELL). This file appears to correspond to the changelog entry of ~TOMEANDBLOOD/TOMEANDBLOOD.TP2~ 0 13 // Revised Illusionary Clones0.8.52 if I haven't made a mistake. It still doesn't explain why the actual spell file is called SPPR736 instead of SPPR738 though. This spell is special as it's added as potentially available spell to spell.ids and then marked as hidden from the player's spellbook. This mechanism is prone to errors. It might a better solution to turn it into a custom spell. I will also check if it's really needed by the TotLM mod.

If you want to stick with a classic for-loop then I'd recommend this expression instead: OUTER_FOR (npc = 0; VARIABLE_IS_SET $npc_list(~%npc%~); ++npc) BEGIN It works fine even if you later add or remove NPCs.

You can save a lot of time by using the "BAM Session" feature. Simply open the original BAM in the BAM Converter, select BAM Session > Export session and uncheck the "Frame source files" option when asked. When creating a new BAM with the the modified list of frame images, select BAM Session > Import session and select the previously saved session file. It will apply original center coordinates and cycle lists to your current BAM. Btw, both options "compress frame" and "compress BAM" are perfectly safe for original BG2 and all EE games. They can help to reduce file size with "Compress BAM" (usually) being a bit more effective. To set "compress frame" for all frames at once, simply select all frames in the list and enable the option.

Yes, the animations in the screenshots are quick drafts I created with NI's BAM Converter. The Scale2X scaler option for double-sized animation looks good enough, but quality degrades quickly for bigger sizes.

Just chiming in, the globe overlay opcode supports custom animations in EE games. So it is possible to adjust globe size based on some criteria (e.g. foot circle size via opcode 326), or just leave it out for large creatures. Examples: (I leave it to you to decide whether it's an improvement.)

Imo, scripts are the worst kind of "solution" in this case. Classic BG2 uses scripts for troll dying behavior which fails to work on a more or less regular basis. This issue has been fixed in the EE games by using effect opcodes instead. From what I've seen the "Dispel Magic Fix" code assumes that all instances of opcode 112 refer to magically created weapons which is not the case in this instance. There are already a small number of exceptions hardcoded, but only for vanilla BG2. Btw, EE contains some improvements for the dispel magic effect (opcode 58), including options how to dispel magically created weapons.

SR's "Dispel Magic Fix" component conflicts with the Trials of the Luremaster mod by removing "Remove item" effects (opcode 112) from the files CDIWDTR1.SPL and CDIWDTR2.SPL. The referenced items grant various immunities and the minhp effect to trolls and revenants. As a result these creatures can't be killed anymore by normal means.

Generated party members are auto-equipped with items from 25STWEAP.2DA, that's why item importation works in Chateau Irenicus even with newly generated characters. These items are taken away right after the importation process by script. However, taking items from several characters at once if they happen to have the same item in their inventory sounds like a bug to me.

WeiDU provides a compare feature which can be used to autogenerate WeiDU code from the differences between two (binary) files. When you've made your local changes to the search map, simply compare it with the original search map: weidu.exe --cmp-from original.bmp --cmp-to modified.bmp >diff.tpa This call writes the code into the file diff.tpa which looks something like this: COPY ~original.bmp~ ~modified.bmp~ // patches to turn [original.bmp] into [modified.bmp] WRITE_BYTE 0x1e5 85 // 0x55 == U WRITE_BYTE 0x1f9 85 // 0x55 == U WRITE_BYTE 0x1fa 85 // 0x55 == U WRITE_BYTE 0x20d 85 // 0x55 == U WRITE_BYTE 0x20e 85 // 0x55 == U WRITE_BYTE 0x221 85 // 0x55 == U WRITE_BYTE 0x222 85 // 0x55 == U WRITE_BYTE 0x235 85 // 0x55 == U WRITE_BYTE 0x236 85 // 0x55 == U You probably want to change the COPY line to reference the correct search bitmap from the game, e.g. COPY_EXISTING ~AR1234SR.BMP~ ~override~ . I'm using this method in one of my own mods to update area bitmaps in a non-destructive way.

Example from the SoD cutscene BDCUT17B.BCS: IF GlobalLT("bd_cut17b_cycle","bd1000",10) !NearLocation(Player1,4535,550,30) THEN RESPONSE #100 CutSceneId("bdcutid") IncrementGlobal("bd_cut17b_cycle","bd1000",1) Wait(1) StartCutSceneEx("bdcut17b",TRUE) END IF OR(2) GlobalGT("bd_cut17b_cycle","bd1000",9) NearLocation(Player1,4535,550,30) THEN RESPONSE #100 CutSceneId("bdcutid") SmallWait(10) SetCutSceneBreakable(FALSE) SetGlobal("BD_CUTSCENE_BREAKABLE","GLOBAL",0) SetAreaScript("",OVERRIDE) SmallWait(5) SetGlobalTimer("bd_mdd016b_timer","bd1000",TWO_ROUNDS) ActionOverride("bdcaelar",StartDialogNoSet(Player1)) END With StartCutSceneEx("BDCUT17B",TRUE) it executes only one script block depending on the specified conditions. With StartCutSceneEx("BDCUT17B",FALSE) it will execute both blocks regardless of condition. (Btw, this is also an example how to reuse one and the same cutscene script for different purposes.)

I wrote a small function once that returns the container index based on the container name: https://github.com/Argent77/A7-GolemConstruction/blob/master/A7-GolemConstruction/lib/functions.tph#L860 Maybe it helps in your case, too. Another option could be adding the item by (area) script: ActionOverride("Container 1",CreateItem("c#q13le1",1,0,0))

They are one and the same. Terms just differ for a number of opcodes for historical reasons. IESDP tends to use opcode names from DLTCEP while NI came up with their own names in the past.

It's possible for a (single) regular familiar, but not generally for allies, summons or "7th party members". (Well, not unless they are unique and you know their script names.) Add these blocks to all global script files of the game (baldur.bcs, baldur25.bcs, bdbaldur.bcs):

Except when you send someone into another room. There are many maps (usually indoor maps) that can be entered by single party members. AoE spells would also remove the option to control movement speed individually per creature. Right now party members move at increased speed as long as combat mode is not active and they are outside of enemy's visual range. For example, an invisible scout moving into enemy range will stop being hasted while everyone else isn't affected by this change. Apart from that, an AoE spell could at least solve the issue with familiars and companions. (Ideally if the AoE projectile can be configured to exclude regular party members to retain their individual states.)

This tweak, as it's currently implemented, requires a straight target to apply the movement modifier. This is possible for party members who can be targeted by Player1, Player2, and so on. Familiars or allies can only be targeted by group (e.g. [FAMILIAR]), which doesn't work reliably from a global script. It would either target none or just a single randomly chosen creature from the target group. The approach mentioned by @subtledoctor would theoretically improve the situation, but it would also come with a number of potential conflicts or restrictions, such as mod order requirements or creature-specific incompatibilities. And I don't know if it would be supported by original BG2.

Well, PSTEE provides a PartyScriptsActive() trigger, which does exactly what the name suggests. Unfortuntately it hasn't been implemented in the other EE games. This feature would have been useful in some of my mods as well.

The find option "-maxdepth 2" can be used to limit search to the game directory and the first level of subfolders in the search path. However, that might still list bogus files if there are multiple .tp2 files present in a mod folder. find game_folder -maxdepth 2 -iname *.tp2 Alternatively you could use regular expressions for the search. However, they are really messy since you'd have to escape so many special characters: find game_folder -regextype sed -iregex "game_folder/\(\(.\+\)/\)\?\(setup-\)\?\2\.tp2"

ADD_KIT_EX can never be faster than WeiDU's built-in ADD_KIT since it uses scripted commands to perform all the required operations (in contrast to WeiDU's ADD_KIT which executes operations natively). Expect only slight improvements in performance.