Ah, that makes sense. I'm not even installing the Tenya mod. But now I'm worried that I'm just covering up something else being broken in my install if this works. The "actual 185" value in my install may be hosed by something else. Is there a way to go through my logs and see what might be causing that?

I suggest to open Setup-SandrahNPC.tp2 in the SandrahNPC folder with a text editor and at line 7062
delete this block

OUTER_SET actual_185 = (STATE_WHICH_SAYS ~Well I haven't killed anyone yet.~ FROM ~B2#TenyJ~)
COPY ~SandrahNPC/mods/TenyaNPC.d~ ~SandrahNPC/mods/TenyaNPC.d~
REPLACE_TEXTUALLY ~185~ ~¬tual_185%~

I assume that whatever system/setup/configuration you use writes some erroneous symbol into the TenyaNPC.d file that afterwards fails to compile. It is supposed to overwrite a dummy state reference with the actual dialogue state in your game but the overwriting by your system produces the error. This explains why other people do not have this error.

After it extracts everything, I'll try that. The odd thing is that I'm not seeing any weird characters in the SandrahNPC/mods/TenyaNPC.d file. I'll upload that as well. But here is the line 1 it can't parse and notepad++ shows it is in UTF-8 format
 

 

EXTEND_TOP B2#TenyJ 185 #6

https://drive.google...iew?usp=sharing

I try a new maximized-type install every now and then, and I'm still running into the same errors.
 

 

[SandrahNPC/Mods/TenyaNPC.d] ERROR at line 1 column 0-19
Near Text: -
Parsing.Parse_error
ERROR: parsing [SandrahNPC/Mods/TenyaNPC.d]: Parsing.Parse_error
ERROR: compiling [SandrahNPC/Mods/TenyaNPC.d]!
Stopping installation because of error.
Stopping installation because of error.

ERROR Installing [Mod Interactions], rolling back to previous state

 

Then it won't allow me to continue because Mod Interactions isn't installing and I'm forced to kill the BWS install. Obviously SandrahNPC works for other people. This is one of the mods I'm most interested in since it has a story that goes across the entire EET game. Something else in my install is causing problems and I can't figure out what it is.

I am testing on top of the 2.5 EET beta build, but that shouldn't be a problem in theory.

I've uploaded all the log files here. If there are other files I could/should upload or if there is anything else I can do to help with troubleshooting, let me know.

https://drive.google...iew?usp=sharing

1. Players using BWS expect a one-click-works-all solution and will not be happy if they get bugs into their game.
2. Mods included with status "red" will probably stay so or and get a bad reputation of being buggy for no reason along the way although the mod was already updated 25 times in the meantime.

People who want the simple one-click solution aren't manually including red mods.

This becomes a catch 22.

You're saying a mod put into BWS but listed red will never get tested. Except it is hard to test a mod at all in a mega-mod installation unless you put it into BWS to begin with. Most people don't know the ideal place of when to pause an install to manually install the new mod for testing. If you want a mod tested to see how compatible it is with everything else, you somewhat need to put it in BWS to allow people to test it.

Is there any update for fixing the bug Salk listed above?

http://www.shsforums...oject/?p=598414

Eilistraees Song's download is pulling down a v6.6 when BWS is expecting 6.2.

I recommend leaving the Steam versions right where they are in the Steam folders as clean backups. Copy them elsewhere and run BWS on the copies in a new location. If something goes wrong with the install or if you want to change things, you can copy the clean backups from your Steam folder again.

I imagine balancing is tricky because people have different levels of expertise with the game. Some people want more of a challenge than others.

If you do eventually revise and create a "recommended" mod list for the defaults in BWS, you can come up with tweaks/balance changes based on that level of content. If someone else throws in even more mods with more content producing more experience points, it alters the balance of the game significantly. And the game is only partially linear. The fact that a lot of the content can be done out of order makes it hard to target the challenge level of what level you expect the player to be.

Thank you!
Regarding mods to make game harder (eet compatible) someone has ideas?

SCS and all the tactical mods aim to do precisely that. You can also apply tons of tweaks in BWS which reduce gold and experience rewards.

Thank you!
Regarding mods to make game harder (eet compatible) someone has ideas?

SCS and all the tactical mods aim to do precisely that. You can also apply tons of tweaks in BWS which reduce gold and experience rewards.

The Stone of Askavar has been updated to 2.1 and the download link moved.

http://www.users.tot...ft/tsoaV2_1.zip

Also, don't take this the wrong way, but this:

So I just tried an install of most everything available in BWS currently on the 2.5 beta.

...has never worked well in the history of BWS.  You need to be pretty deliberate about which mods you want to opt into and which ones you want to opt out of.

I'm merely testing for the sake of testing to find potential conflicts. I plan on re-doing the install several times before I play.

Honestly, I don't even care if I don't have any new kits in my install. I'm more interested in quests/dialogue.

Might and Guile Component: Add Multiclass Kits leaves some file in a state that later causes Sandrah's multiclass kit addition to fail.

Not sure how - he said M&G multiclass kits did not install.

Sounds more like some other mod is leaving things in a state that messes up both M&G and Sandrah. But I'm not sure what coukd be doing that...

I just quickly installed M&G onto a basic EET game, in the wrong order (multiclass kits last) and the right order (multiclass kits first). It installed fine in both instances.

That's M&G 3.7.4 btw... not sure what version was used in the above reports. In any event more data is needed. A weidu.log, for instance, to see what was installed earlier.

 

I tried M&G with just two other mods last night and M&G installed just fine. I don't think M&G itself is broken. There is just a conflict with some other mod.

Here are my latest logs to find out what broke M&G.

https://drive.google...LGmC6GYLK_N0Prq

So I just tried an install of most everything available in BWS currently on the 2.5 beta. The following four failed:

Mod: Might and Guile
Component: Add Multiclass Kits
Component: The Feat System (for Warriors and Rogues, requires EE 2.0+, includes Revised Stalker and Shadowdancer, disables Scout kit)

Mod: Item Randomiser
Component: Prevent Watcher's Keep statues from disappearing (in case randomisation gave them something)

Mod: EET (Enhanced Edition Trilogy) Tweaks
Component: NPC voices

Mod: Sandrah Saga I - Sandrah Appears
Component: Sandrah EET additions

Of those, Might and Guile seems to conflct when installed with other mods adding kits. I will try to look through and see what the conflict is. The Item Randomizer component outright said some other mod apparently already provided that tweak. I'm not sure why NPC Voices failed in EET Tweaks and will have to look at the log file. The Sandrah failure I think I've seen before. If it thinks Might and Guile is installed, but it isn't really, that causes problems. I don't need Might and Guile. I'm just testing these literally for the sake of testing them. I'll try a new install in a bit.

@enderandrew Thanks for very detailed error report with all important files. EET is not adapted to 2.5 yet.

Are you sure tthat this is the problem?
 

[EET/temp/patch/baf/BDNOREST.baf] PARSE ERROR at line 44 column 1-57
Near Text: )
    unknown object SPECIFIC specifier [CULTIST_NEUTRAL]

[EET/temp/patch/baf/BDNOREST.baf]  ERROR at line 44 column 1-57
Near Text: )
    Parsing.Parse_error
ERROR: parsing [EET/temp/patch/baf/BDNOREST.baf]: Parsing.Parse_error

 
It could be tested by putting this file into BGEE/override before running EET-core
BDNOREST.BCS
 

Thanks, though I think the problem may have been on my end. I may have had a leftover file I didn't clean up between installs (though I restored my backup). I wiped my BGEE and BG2EE folders I was using completely and copied them over fresh from my Steam folder and now the install progressed past EET-Core. I have one Might and Guile component failed, but the install hasn't finished.

So I tried a full install with almost everything. I was going to wait for the final 2.5 patch from Beamdog, but since I was already wiping things and testing BWS I decided why not. Except this time it failed on EET-Core very early on.

https://drive.google...eaeYU0EPeMAPn71

I tried a minimal install with just Might and Guile, Wilson Chronicles and The Bear Walker. Wilson's Chronicles threw an error, but Might and Guile did not. Here are my logs:

https://drive.google...iew?usp=sharing

There are at least two mods in BWS that could have changed that: Wilson chronicles, and The Bear Walker - a Werebear/Ranger kit. Maybe one of these could have duplicate the entry in kitlist.2da.
 
Also, is there a way to install mods compatible with an EET install listed in K4thos' list that doesn't show in BWS, such as Pai'Na NPC? 

I think I had a similiar failure previously. Is there a way to figure out which of these mods is causing the problem?

I suppose I could do a BWS install with just Might and Guile and Wilson Chronicles, or just Might and Guile and The Bear Walker to test.

Just to make sure, after the megamod installs is it safe to run anti-virus for a scan or would it screw up the order?

A scan post-install shouldn't screw up order.

I suspect most people running BWS have Microsoft Defender built into Windows, and likely another anti-virus product as well that came with their PC and are having no problems leaving them on when they do the install.

But every once in a while you could run into an issue with anti-virus (or even Microsoft SmartScreen built right into Windows) blocks one of the installers because it doesn't know what it is. So it is better to err on the side of caution and disable these programs while the install runs.

From www.weidu.org/~thebigg/ right? Do I use 244 or 243?
 
ED - went ahead with downloading 244 then extracting it to the Big World Downloads folder. Applied 4 GB patch. BWS detected the file and there were no errors or other prompts. 
 

I hope that works for you.

Now that the new version of NTotSC is out, I'm tempted to start my BWS install and play-through soon. I'm in the middle of a few other games I started in the mean time.

I made CFF explorer a permanent part of my Windows installs thanks to DA:O and TES. I may try using it on Weidu as well. Is there a particular prompt I should watch for to know when to try it?
 
The memory error is particularly annoying to me as I was waiting for it but I was able to complete removing Item Rev's weapon tweaks and repatch all the way to the end and only saw errors on the UI repatching. Then I tried to remove scales of balance and got that error. 

You could just manually download the Weidu zip, extract it, patch it, zip it back up and leave it in the BWS folder and then just start that way I suppose.

Any tips on avoiding another memory error? Do I need to avoid doing other stuff or something?

Your computer is not running out of memory. Weidu is specifically. It has file limits of how many files it can open, and as a 32-bit process it is limited to 2 GB of memory. It often errors on out on SCS.

Your options are to not include SCS, only include a few components of SCS, or attempt some sort of work around.

The Weidu devs don't seem to have any interest in trying to make a 64-bit version of Weidu to fix this, nor to keep it 32-bit but patch it to allow it to use 4 GB of RAM. The SCS modders could in theory try to rewrite their mod to be more efficient.

When I try my next install, I'm going to let BWS download Weidu and all the mods, but then stop it. Then I'm going to apply the 4 GB patch to Weidu. http://www.ntcore.com/4gb_patch.php

BWS will probably say Weidu doesn't match the checksum it is expecting, I'll tell it to ignore it and then let it proceed with the patched Weidu and see what happens.

deleting my post now that I'm seeing an update on the other forums

As for the Weidu/Tobex issue, it does seem like while semantically you can't say mods are completely to blame because they were using a valid command which has now retroactively broken with a Weidu update. However, it does look like there is a simple fix for the issue by updating the Fixpack to use FILE_EXISTS instead of FILE_EXISTS_IN_GAME. I get that new releases of Weidu should try to avoid breaking old mods and should try to preserve backwards compatibility. If they don't want anyone using FILE_EXISTS_IN_GAME, then they should document that and officially deprecate that command.

Are yousure that it's weidu and not the mods that break themselves by using the WRONG command ... and weidu retroactively just fixing itself for the correct usage of the command. As you can read, CamDawg says, the MOD is using the wrong command.
 

 
 
If the command exists in Weidu, then it is available for people to use. If you don't want people to use the command, then deprecate it and remove it.

You can't blame someone for using something that is made available and in the documentation.

I think it makes sense to change the usage in Fixpack now as the quick and easy solution, but Weidu should also deprecate the command as well in the long run.

Last time that I read WeiDU manual I got an impression that FILE_EXISTS and FILE_EXISTS_IN_GAME works differently and therefore could be used for different purposes with a different result in mind. This post seem to support the conclusion. How on earth can you replace one with another and hope things will work?

You are correct. The command is in the documentation and it serves two different purposes. But when the regression was reported to Weidu devs, they're saying they never intended for the command to really work and they don't want people using it. Again, I'm arguing they should properly deprecate it then. But since we know it is currently broken in the current version of Weidu and the Weidu devs don't intend to fix it, the Fixpack needs to change which command they are using.

@enderandrew

This time mods are not responsible for the issue so no one needs to be notified to fix anything. As for the rest of you post, you will be surprised when you read this: http://www.shsforums...ices-discussion

I read and referenced that thread.

As for the Weidu/Tobex issue, it does seem like while semantically you can't say mods are completely to blame because they were using a valid command which has now retroactively broken with a Weidu update. However, it does look like there is a simple fix for the issue by updating the Fixpack to use FILE_EXISTS instead of FILE_EXISTS_IN_GAME. I get that new releases of Weidu should try to avoid breaking old mods and should try to preserve backwards compatibility. If they don't want anyone using FILE_EXISTS_IN_GAME, then they should document that and officially deprecate that command.

How difficult would it be to do a replace all FILE_EXISTS_IN_GAME/FILE_EXISTS on the Fixpack and call it a day?

The Fixpack is actively maintained. So a simple solution is within grasp.