Sam.

Does anyone have any information about work done to make one of the following mods compatible with EET?

• [...]
• Aurora (I made a tp2 version - similar TDDz - for private use, just to install the creatures, shops and story without the animations and tweaks but could get no feedback from the original author on it)

Thank you all for feedback on this topic

@Sam

I think the condition list you posted is very helpful - even if such should be common horsesense among modders, it is a useful and readable guideline for all those interested in the topic.

 

PS - I have no intention to publish my attempt at Aurora anywhere as it does not fulfill condition 3). It was just to proof the concept that such a conversion can be accomplished by just modifying tp2 and without altering much of original content (maybe encouraging the original author to try it). In the specific case of Aurora however, condition 3) is not applicable in my opinion as the original mod is fully functional in the old game while for EE/EET only a slightly modified subset of the mod can be used (minus the animation and tweak parts). Something like Aurora Lite for EET.

I would be very interested to see what you have done so far. If the core components are there and EE(T) compatible, that's the majority of the strictly necessary work. The optional/animation/tweak components need not be EE-ized immediately. It would be enough simply to leave the existing code (which would still install on classic engines) intact but exclude those components from being installed on EE-based games for now. Such an approach would still adhere to condition #3.

Does anyone have any information about work done to make one of the following mods compatible with EET?

• Aurora (I made a tp2 version - similar TDDz - for private use, just to install the creatures, shops and story without the animations and tweaks but could get no feedback from the original author on it)

• Aurora ... - if you have working version without duplicated tweaks from other mods, that's great news

I have permission from Miloch to oversee updates to his mods, including I believe any mods that he was in charge of maintaining. As his name is on the copyright of Aurora/Aurora's Shoes and Boots combined with the fact that he "owns" the upload to some of the files themselves, I believe this mod falls into that category.

While I lack the WeiFu skills to perform the greatly needed code modernizations myself, I will support and oversee such efforts by others* and do my best to see to it that such updates receive official hosting (on GitHub if SHS admins are unresponsive).

*My support hinges on the following conditions:

1. Updates to the mod shall stay true to the original content: significant content shall neither be added to nor removed from the mod.
2. Updates shall primarily be limited to the following areas: code and file format modernization, bug fixes, compatibility improvements, and to a minor extent the completion of unfinished business.
3. Updates shall strive to maintain a single, unified mod: updates shall strive to add compatibility with modern Enhanced Edition game platforms/engines (including EET) WITHOUT sacrificing backwards compatibility with existing supported "classic" platforms/engines.
4. Updates shall include all existing relevant bug fixes (e.g. from Big World Fixpack) for the mod, as long as said fixes do not contradict any of these other conditions.
5. Updates to the mod shall cease and all file hostings of such updates shall be taken down upon request of the original mod author(s).

I am certainly willing to help with such an update, where time and skills allow. My support of updates to any and all of Miloch's mods (and the mods he maintained), including a fairly large one that was never officially released (but was probably 95% complete), is contingent upon these conditions. PMs on the topic are welcome.

Sincerely,

Sam.

Yeah but this component is just an XP cap remover

I disagree. This component installs a lvl 20, 30, or 50 ruleset, which includes updated XP cap, spell and THAC0 progression tables, backstab multipliers, etc. Everything is included to properly progress through these levels. Everything that is, except the ability to obtain HLAs.

1) HLAs are a BG2/TOB thing. In BG1/SoD/IWD getting to high levels not anticipated by the game design should not necessarily shunt you into the BG2/TOB ruleset.

I view things differently. I see the BG2/ToB ruleset as an extension of the BG1/SoD ruleset, just adapted for higher levels. This is particularly true for the EEs where all of these games (plus IWD) are all truly using the same engine (or soon will in the case of IWD). Considering the vast majority of players are likely now playing the Enhanced Editions instead of the original engine, this interpretation is not likely unpopular.

2) Adding HLAs to BGEE/SoD more or less means adding a spell pack to the mod component. Look at how much work it's going to be for us to add IWDEE spells in FnP... that's what Camdawg would have to do, and it seems like he's a busy guy.

 

I mean, ideally, thus should have two subcomponents. Option 1, just uncap the XP limit. Option 2, uncap the XP limit and add HLAs at appropriate levels.

But the spells and 2DAs already exist: they just need to be copied from BG2EE to the other games. A component adding HLAs is certainly not going to be available for every version of every game engine, but adding them to the EEs is mostly a matter of copy/paste.

But one of those options can reasonably get done in a day or two, while the other might take weeks or months. For the guy who can't level up and play the game, that's a pretty immediate problem and the quicker solution is, for now, the better one.

I certainly agree that removing any reference the the HLAs is the quickest and easiest solution, but I also very much hope that a better one will be developed.

Respectfully,

Sam.

Beta 4 Changelog

• Change Experience Point Cap should now work on Siege of Dragonspear

I can confirm that Beta 4 seem to have fixed the issue where the transition to SoD was nerfing your XP down to 500,000. That is excellent. However, I am experiencing more (possibly indirect) issues with this component.

Using Tweaks Anthology Beta 4 and SoD v2.1.63.2, attempting to level up a character past a certain level (usually around 3,000,000 XP) results in you getting stuck in the menus. You are unable to dismiss or complete the level up dialog, and so must quit the game. This seems to occur whenever the character would have been given a choice of HLAs, but the HLA files do not exist in BGEE or SoD so the menus hang. Here is what it looks like in SoD v2.1.63.2. Note that the "Done" button is greyed out and can not be selected.

In BGEE v2.2.66.0, you no longer get stuck in the menus when trying to level up, but there are still no HLAs in the game, so you end up with this fugly screen:

However, these modifications to the level up menus do not seem to have made it to SoD v2.2.66.0, so it still hangs on level up.

Even in BGEE v2.2 where you can successfully dismiss the blank HLA menu, transferring your game to BG2EE will not retroactively give you the X number of HLAs you missed in BG1/SoD because of missing files. This isn't good, and it doesn't seem true to the spirit of the Change Experience Point Cap -> Remove completely component. Can Tweaks Anthology do anything about these issues? Including the HLAs from BG2EE should be fairly straightforward, it's modifying the UI that is a bit more complex.

The documentation for Unique Containers claims to be installable on BGEE, but the code for the component is missing that entry:

REQUIRE_PREDICATE GAME_IS ~soa tob bg2ee eet bgt tutu tutu_totsc how totlm iwdee iwd_in_bg2~

This is true for all 3 sub-components.

Do you still take tweak requests?

I would love a "Convenience Tweak and/or Cheat" that enables stores to buy all item types. Just one small example, but it would be super convenient if The Friendly Arm Inn bought books (and ammunition)... I realize it doesn't make much sense for a potions shop to buy Plate Mail, but it sure would be convenient .

Input for analysis

 

One of the important sources of information for analysis in the game is Weidu.log.

In EET there are now two such files one from BGEE and one from BG2EE starting with EET.

Would it not be helpful to copy the BGEE Weidu.log during EET install and append the succeeding installation to it?

You would always be able to determine in which part of the game a mod is by the reference to EET in the log, but only one log would provide you with the complete information about what is in the game at a glance.

I think you might need to comment out the part from BGEE so that WeiDU doesn't trip out if you ask it to uninstall everything in the log...

I had thought of this as well - but what would be the real-life scenario to do such a thing? Would it not be easier to simply delete your BG2EE game and start fresh? If you roll back, the last thing to uninstall would be EET and that leaves you with the unmodded BG2EE - same result but more cumbersome to achieve.

I agree a clean install is the most efficient and effective method, but there will invariably be people who won't do that, and they will end up posting here because their uninstallation failed or threw errors. I like the idea of having a unified WeiDU.log, but what you are proposing falls outside of WeiDU's standard operational procedures. Many people won't recognize that, and people love complaining when their computer does what they tell it to instead of what they want it to...

Input for analysis

 

One of the important sources of information for analysis in the game is Weidu.log.

In EET there are now two such files one from BGEE and one from BG2EE starting with EET.

Would it not be helpful to copy the BGEE Weidu.log during EET install and append the succeeding installation to it?

You would always be able to determine in which part of the game a mod is by the reference to EET in the log, but only one log would provide you with the complete information about what is in the game at a glance.

I think you might need to comment out the part from BGEE so that WeiDU doesn't trip out if you ask it to uninstall everything in the log...

There is some more information on the internal handling of the BAM format here. Specifically: the supported BAM frame blending modes, the BAM frame dimension limit (which has essentially been lifted in the EEs), and when/if the shadow color of the palette is used.

I would like to know how the engine implements transparency/translucency (from a mathematical standpoint) into BAMs that themselves store no Alpha channel transparency information.

This is a great resource.
http://www.andersriggelsen.dk/glblendfunc.php

We support the following blend modes

Translucent(7) checked off
glBlendFunc(GL_ONE_MINUS_DST_COLOR, GL_ONE);

Blended(9) checked off
glBlendFunc(GL_DST_COLOR, GL_ONE);

And in IWD
Translucent(7) and Blended(9)
glBlendFunc(GL_SRC_COLOR, GL_ONE);

It seems the BAM frame size limit of 255x255 px (or perhaps 256x256 px) has been lifted in the EEs. Can you confirm this?

256x256 has been lifted(ish). If it's compressed the engine still needs to decompress that bam to render it, so going over that should still be avoided. If it's a bamv2, then we can send that data directly to the card, so it renders much faster(but then you skip the fancy effects you can do to a bam)

In which scenarios does the second entry in the BAM's Palette take on the special properties of being the "shadow" color, or does it always?

When the bam is rendering, it asks the palette system how many entries are reserved. If the 2nd entry matches the shadow color of 0x00000000, then it returns 2 Otherwise it returns 1. So basically if the 2nd entry is the shadow color, then it will treat it as such. Otherwise it just uses the 1 reserved entry of the color key green.

-Sam.

Which effects.dat files should be used with DLTCEP: the ones that come with the latest version of DLTCEP (v7.7 at the time of this posting) or the ones found on the IESDP? A side-by-side comparison of the corresponding files from each source shows they are not the same.

I am unclear on which I should choose for two reasons. First, while the latest version of DLTCEP was released more recently than the latest version of the dat.zip file from the IESDP, some of the "Date Modified" (aka "Last Write") dates on the .dat files files from the IESDP are newer than those that came with DLTCEP. For example, the BG1Effects.dat that comes with DLTCEP appears to have been last modified in 2007 whereas the one that came from the IESDP appears to have been modified as recently as 2013. Secondly, the .dat files from the IESDP include a bgEEEffects.dat which logically would be used for BGEE, BG2EE, and IWDEE, whereas the DLTCEP installation does not come with a .dat specifically for the EEs. Presumably, BG2Effects.dat should be used instead.

Whatever the case may be, it would be nice (and reduce confusion) if the two sources were consistent...