agb1

Are there any trigger regions or static animations in the map area where you encounter the crashes? I've seen crashes when switching to area map view due to problems with a BAM file somewhere in an area (recent fixed example with Foundling's L#Fou0.are and L#FoWall.bam).

Seems there is something in the area that is causing the crash, then. I will try to reproduce locally in a few minutes; I have an install running right now.

BWS is using the Fixpack which, when it sees that you have also selected Spell Revisions, applies the most recent published revisions by kreso. The patches from the Fixpack also add EET compatibility which is missing from the package published by kreso on this thread, but will be included next time kreso updates the link here as I gave him the combined package.

Basically: if you use BWS, you're getting exactly the same revisions as in this thread, automatically.

If you walk around in the Lighthouse area to the place where you would normally arrive if you walked in from Bassilus' area, does it crash? i.e., do you crash near the arrival / entry point of the area even after a console MoveToArea(), or is it specifically the act of traveling from Bassilus' area that causes the crash?

Certainly the right place to report it. Not previously reported, I think. If I'm understanding correctly, the map icon is either not appearing on the world map or the icon is appearing but is not clickable? Are you using the default world map or BP-BGT-Worldmap?

I vote for making aTweaks check and skip as appropriate if your SCS/SR tweaks is detected.

It is fully playable already. Bugs are minor at this point. For me personally, what remains before I commit to a long game is making more mods compatible, which is happening on an almost daily basis for smaller mods, while larger mods are in progress too.

Right, the update-if-needed will grab the latest for you. That old spell_rev.exe ... hmm.. I guess that must've been it.

BWS has a backup/restore feature that you can use to delete everything that wasn't there before you backed up the game folder. You would have been promoted about making a backup at the beginning of your install. You can do a restore from the screen following the folder selection screen (Continue button).

I usually reinstall the game from the original installers each time as a "clean" test case.

Edit: I am very puzzled. BWS is set up to use the following link for Spell Revisions: http://lynxlynx.info/ie/modhub.php?Gibberlings3/SpellRevisions&preonly

I just entered that URL in my browser and the package downloaded is in fact SR v4 beta 13. So ... where did 11 come from ?!

Can you confirm that you downloaded the latest BWS from https://bitbucket.org/BigWorldSetup/bigworldsetup/get/master.zip ?

Check the File Properties of weidu.exe - the first size value should be 984,576.

You can manually download it from www.weidu.org/~thebigg/weidu.exe

"WARNING: File "spell_rev/setup-spell_rev.tp2" contains 'VERSION ~v4 Beta 11~' instead of expected 'VERSION ~v4 Beta 13~'! This is the file targeted for patching in "SETUP-SPELL_REV.TP2.PATCH" in "Big World Fixpack/spell_rev". This might mean that the patches for this mod were made for a different version of the mod than the one that you are using, or this might mean that the mod was already patched and then removed from the list in the "BWP_Fixpack.installed" file without restoring the original pre-patched files."

You might have the older version of Spell Revisions in your BiG World Downloads folder. With my changes late yesterday it should be smart enough to get the newer one now, but I think your install predated my changes. Please let me know if it happens again.

"WARNING: file "setup-scs.tp2" does not exist (this is the file targeted for patching in "SETUP-SCS.TP2.PATCH" in "Big World Fixpack/scs"). This might mean you did not extract all of the files of the mod, or it might mean that the patches for this mod were made for a different version of the mod than the version that you are using (you would see this message if the version you are using moved or renamed the tp2 file)."

Actually this was a very old patch for SCS v21/v28 that wasn't needed. I've removed it from the fixpack for future installs. Thanks for noticing and reporting it!

1. Not sure. Good suggestion.

2. Hadn't noticed. Will update - thanks!

3. BP-BGT-Worldmap covers more of Faerun. Depending which mods you use it might be necessary to use the huge map. EET default world map looks great too. So I would only use the map mod if required, but it is still personal preference otherwise.

4. Rules are shared across game types and we don't filter out the mods that aren't available. I agree it can be confusing. Maybe I'll make that optional.

5. Not tested recently. Historically had issues installing, I think. I enabled them all in my current test install but haven't had time to test yet.

6. Not sure. Argent77 undoubtedly considered this given the popularity of SCS, but I don't know the compatibility situation.

@agb1

 

I think the Big World Fixpack confuses versions of Spell_rev!

 

edit: Or maybe this latest beta version of SR says v11 when it's not?

It used v4 beta 13 on my test install just now, but I also just made a change to how BWS identifies new versions of GitHub downloads (we're using a redirect link to the latest GitHub pre-release of SR). Luckily the GitHub branch doesn't include the gibberlings exe...

PRINT shows up in the WeiDU debug log, but not in the WeiDU.log record of mods/components chosen. The WeiDU .debug log already records READLN responses, so the PRINT is not necessary there.

My point was that you have to ask for the .debug file in addition to the WeiDU.log. And it's more an issue when considering replicating a user's installation including multiple mods that use READLN, where you must request the .debug files from each of those mods to know what they chose.

I'm going to suggest prompting the user with a quick READLN for the stack values. I personally like very different values for different type of things (80 for ammo, from 20 to 40 for daggers/axes, 12 for potions and 999 for gems because why not).

READLNs are a pain to support in BWS. If you must have one, please use subcomponents, so there are a few standard amounts as other subcomponents and then a "custom amount" subcomponent where it does a READLN and asks for a number.

Choose a maximum stack size for potions:

1] 12

2] 20

3] Custom (prompt for a number)

Etc.

Also as noted, various other mods already tweak this (Tweaks Anthology and the Difficulty and Tweak mod are prime suspects), so I'd question the necessity of tweaking it at all here also...

Edit: Another argument for minimizing READLN use -- what the user entered doesn't show up in the WeiDU.log, which means you have to ask for additional info when supporting users of the mod.

The drake/wyvern thing reminds me of a certain encounter along those lines in the Cloakwood forest.

http://www.d20srd.org/srd/spells/summonMonsterIX.htm

I've added HANDLE_CHARSETS patches for the following BG2-classic mods to the BiG World Fixpack:

1. Haer'Dalis Swords v2 - http://www.shsforums...erdalis-swords/

2. Lucy the Wyvern v4 - http://www.shsforums...ucy-the-wyvern/

3. The Minotaur and Lilacor v1.6 - http://www.shsforums...ur-and-lilacor/

As none of these mods use GAME_IS checks or Chapter checks, and they exclusively modify BG2 content, I believe they are now also BG2EE and EET compatible.

Summoning trolls sounds like fun!

Plus, golems can be had with Argent77's new mod that everyone will use!

The BiG World Fixpack has been updated to apply this new latest version whenever stratagems folder and spell_rev folder are both unpacked in the game directory before running the Fixpack script.

I guess the key idea I'm trying to advocate is that instead of having fixed components for various NPCs, the core definition of what changes the mod will make can live in a text file that can be easily read and modified. That would make it easy for people to reuse their favorite config across installs... especially if the definitions are mapped to a scriptname/DV (and you just run a patch across all CREs looking for a match instead of having to worry about platform-specific differences or making sure you have cre, cre5, cre10, cre15 etc.).

Just curious, are you using cpmvars? If so, https://github.com/K4thos/EET/tree/master/EET/other/cpmvars

Alternatively, follow subtledoctor's lead with https://github.com/subtledoctor/NPC_EE#readme and make it dynamic. Read DVs from pdialog and follow the trail, maybe? What's the best way to build a dynamic list of all party-joinable CREs?

Here's an idea for a redesign of L1NPCs:

Build a dynamic list of all party-joinable CREs in the game. Generate code for a "customize everything about this NPC" menu component for each and write them into (separate, or a single monolithic) tph file(s). Then INCLUDE that/those tph file(s) to present a dynamic list of components. WeiDU does let you add components via INCLUDE, right?

Then... make it output the player's selections to an .ini file with a section for each CRE so it's easy to modify by hand afterwards, and process that same ini file to actually apply the changes.

Something like this:

BEGIN ~Use my ini file settings as-is~

SUBCOMPONENT ~What do you want to do?~

DESIGNATED 0

INCLUDE "apply the changes defined in the ini file"

BEGIN ~Show me each NPC so I can customize its settings~

SUBCOMPONENT ~What do you want to do?~

DESIGNATED 1

INCLUDE "code that generates dynamic component tph files"

INCLUDE "all of the generated tph files that let me customize the ini file"

INCLUDE "apply the changes defined in the ini file"

... By having the first option, automated install scripts or personal batch scripts that just want to apply the ini file don't have to worry about dynamic components.

Actually, you don't even need to have multiple components. You could present all of the menus in the customize component without actually making each one a genuinely separate WeiDU component. And you could even append the WeiDU log with "fake component" entries if you want to log exactly which NPCs were changed.

The out of memory issue with EET is still unresolved, so I must caution that BWS cannot provide a flawless EET installation experience yet. I recommend minimizing the number of pre-EET BG1EE mods you select, for now.

MOD COMPATIBILITY LIST FOR EET

Last Updated: 05.10.2016

 

Installation tips and notes on compatibility

- after EET becomes officially released the Big World Setup installation utility will be updated to support this platform, which means at least Windows users will be able to automatically make installations with huge selections of mods without worrying about install order and technical stuff.

The BiG World Setup (BWS) tool now supports EET installations, including all mods from the first post on this thread. Simply choose BG2EE / EET as your installation type and provide the path to both your BG1EE and your BG2EE folders. If you set the BG1EE folder path to a single dash "-" then BWS will revert to BG2EE-only (non-EET) mode.

Your BG2EE folder should be clean of all mods (exactly as it was after running the official installer) before starting a BWS installation, but you must start the game once and create a saved game.

Your BG1EE folder should also be clean of all mods, but you must additionally run the MODMERGE tool (only once) in the BG1EE folder if you have the Steam or GoG version of the Siege of Dragonspear expansion. If you use BWS, it will remind you when you provide your BG1EE folder path if you forgot to run modmerge. If BWS accepts your BG1EE folder path, modmerge is already done or not needed (as is the case if you purchased the expansion directly from Beamdog).

While using BWS, it will allow you to select which mods you want to install (while not showing you any mods that are not yet EET-compatible), inform you of known conflicts and dependencies and it also lets you export your chosen selection for later use.

Once you start the installation process (click the Continue button enough times), BWS will first download the latest versions of each mod you selected (you can manually provide zip/rar/etc. mod archives into the "BiG World Downloads" folder if you already have the mods downloaded; the location of that Downloads folder can be set on the same screen where you set the game folder paths). After downloading is complete, BWS will inform you if any mods could not be downloaded and will ask you if you want to provide them. If you say yes, BWS expects you to put the zip/rar/archive in the Big World Downloads folder before you tell BWS to continue, because that is where it will look, not in whatever Downloads folder your Internet browser uses.

After the download phase, BWS will unpack the mods you selected into the appropriate game folders, apply the latest available patches, and then run the installers. Once BWS finishes installing BG1EE mods that have to be installed before EET, it automatically starts working in your BG2EE folder and repeats the process, including running the EET installer itself at the appropriate time (after applying patches, before installing other mods on BG2EE).

Just to make sure this is clear, since there have been many questions about it: You do NOT run BWS separately first for BG1EE and then again separately for BG2EE+EET. It is a single continuous process. Also, you can restart BWS as many times as you want and play around with different mod selections without having any effect on your game folders. BWS only touches your game folders when it is in "install mode", which only happens when you click Continue on the final configuration page (don't worry about doing this accidentally - it will ask first).

To address another commonly asked question: BWS has an auto-update feature that is used to update its internal database of mod versions, download links, conflict rules, etc before it brings up the user interface and starts interacting with you. Updating BWS has no effect on your game folders at any time. BWS also has a startup script labeled "without update" that skips its auto-update, and it is recommended to use this "skip start" only if you restarted BWS in the middle of an installation. That's because during an installation, BWS is relying on its internal files to know which mods to install next, and it's possible that an auto-update might include a change in the recommended sequence. This might confuse BWS in the middle of an installation (we haven't tested it much), so it's safer to avoid any changes to BWS' internal data until the current installation is done.

3. Mods that can be installed after EET main component on BG2:EE but MUST BE PATCHED FIRST

For now you can't just install these mods on top of EET. You first need to download proper patch and extract it on top of the mod to add EET compatibility. Patches simply overwrites existing files which means they are designed for a mod versions as listed below. The patch will become outdated as soon as the author updates a mod, so if this happens the patch should not be used and the mod will become not compatible. That is why we're trying to get in contact with every mod author to make these patches officially internalized. Hopefully this list will shrink over time.

 

Patches are available on GitHub: https://github.com/K4thos/EET-patches-for-BG2EE-mods

All of K4thos' patches linked above are now included in the BiG World Fixpack, which can be used manually and is used automatically by the Windows-only BiG World Setup tool. Unlike the EET-patches-for-BG2EE mods, which contain complete replacements of modified files and should only be used with the exact mod version indicated, the BiG World Fixpack contains line-by-line patches and checks each line before patching to make sure it hasn't changed, so it is often the case that patches in the Fixpack still can be applied to newer versions of a mod (if those particular targeted lines haven't changed). Of course we regularly update patches in the BiG World Fixpack when we learn about new mod versions, and you can also look at the patches yourself (in the BiG World Fixpack/>>modname<< subfolders) to see exactly what is being changed.

The BiG World Fixpack includes additional patches for many of the mods listed in this thread (fixing issues that have been discovered in the time after K4thos last updated his compatibility patches on GitHub), so it is recommended now to use only the BiG World Fixpack, and not to use the EET-patches-for-BG2EE-mods. You can click HERE to download the latest BiG World Fixpack if you are doing a manual installation.

The BiG World Fixpack has a new WeiDU-based cross-platform install script (Windows: run _ApplyPatches.bat, OSX/Linux/other: run weidu _ApplyPatches.tp2) and will validate each patch before applying it by checking the VERSION of the target mod in your game folder and comparing it to the VERSION in the Fixpack patches. If there is a mismatch, it will pause and ask you whether you want to patch anyway or skip that mod. It is also safe to run the WeiDU Fixpack script multiple times, because it will skip mods that have already been patched.

The Fixpack is different from other WeiDU patches because it does not modify content in the game directly: instead, it modifies specific files in each unpacked mod folder in your game directory, which will affect what those mods do to the game when you run their individual installers later. For example, the Fixpack patches WeiDU .baf script and .D dialogue and .tra translation files before they are compiled into the game. This type of patching has no effect on any mods that have already been installed, so only run the "setup-modname.exe" (or weidu installer equivalent for OSX/Linux/other) for a mod after running the Fixpack script (so: unpack a mod, run the Fixpack script, then at some later time run the mod's own installer).

Note that you can (and should) run the Fixpack script separately in both your BG1EE and BG2EE folders, after unpacking the mods you plan to install there, because it includes fixes for BG1EE mods.