First, some general notes about this update. As soon as 1pp was released, I modified the installation procedure to 1) fix bugs 2) not install some modifications that didn't seem relevant to me 3) modify others accordingly to my own tastes. As WeiDU was updated, I modified the code to make it more efficient.
I never published these modifications because they were intended for my own personal use. It was only after the EE games release that the idea of officially updating 1pp was born. Once the decision was made, the work undertaken respected the following principles:
- Rewrite the code to make it more efficient.
- Respect Erephine's spirit.
- Do not modify the content with "personal" designs.
- Stay as close as EE games for compatibility purpose.
That's the reason why I didn't take up some proposals from players who violated these rules. But of course, they are free to modify the code for their personal use.
On the other hand, I wanted to keep the spirit of the mod which looks more like a Fixpack than a common mod (a bit like Infinity Animations) and should be installed as soon as possible. Modders should adapt their mod to the presence of 1pp, and not the contrary! This document explains how to do it
In a perfect world, SR and IR should really be installed after 1ppv4 and not installing it. I found very painful to add compatibility with two mods that are still in beta versions and don't respect the usual mods install order... So I wrote partial compatibility with them.
- Core v2 component: Cool, seems like you've added virtually all of my fixes and changes from my 1pp_fixes, with the exceptions of Roranach's Horn, Short Bow +3, and Mithral Field Plate. That's like...17/20, I can live with that.
Correct. Most of them were obvious. The others don't respect the above rules.
Projectiles:There's no patching of SR's dvenbolt, dvenarow, or dvenbull - they're all duplicates of the +3 projectiles.
Yes, I made the decision to fix all protection/bounce 1pp new projectiles and let other mods to deal with their own projectiles.
you left Deflection Shield as a tower shield because I suppose it is as well in BG2EE, left HELM13 as its unspiked appearance and left HELM15 as its unhorned appearance (presumably validating EE changes)...all understandable.
Yes. I did not find a solution that pleased me. So I stuck to EE choice...
No support for IR's variants of throwing axes/daggers in this one - may want to add that, especially since you already did in the projectiles component. Also, IR hammer variants compatibility as well.
Good catch! Please give me their code and I will add them.
You are still letting 1pp patch dagg21 and dagg22 (Dagger of the Stars) for the Shadow Thief icon that you have disabled it from installing - the colors will be wrong as a result.
Another good catch. There are so many lines of code I missed it when proofreading...
Borok's Fist/Runehammer: BG2EE is really weird about this, it has HAMM03, HAMM05, HAMM10, and HAMM11 all set to that green-looking hammer icon (though HAMM03 is using the original variant instead of the rest where the contrast was just jacked up to make it look different). What are they doing? Still not an ideal situation here even with the switch (there are other icons that can be used to prevent these duplicates!), but I suppose it makes sense if you're just trying to validate according to the EEs.
I know this part is very confusing. That's the reason why I decided not to install it and keep the Runehammers as in orignal games by default. If players want the new icon and colors, they will have to set 1pp_hammers_icons setting to 1 in config file.
xbow15/16 (Firetooth +4/+5) should get location wpink set (IMO, with gradient 19), otherwise it would appear the Firetooths are shooting blue bolts on the character paperdoll, which seems like a clear oversight.
Good idea. Will give it a try.
No support for BGT's bgmisc89 (Edwin's Amulet).
I guess you missed it.
I think Rashad's Talon and Belm have opposite colorizations, if I'm recalling correctly.
Must check them.
A couple of suggestions:
- Additional linebreaks in between options in the config.ini. It's confusing to read the description and then try to figure out whether the option was above or below the description, especially when some of the settings have very similar names - just put an additional empty linebreak in between each option.
- Set gem lore to disabled by default. Placed into an automated install, mass amounts of gems needing to be identified is virtually guaranteed to annoy most people that get stuck with it not realizing it was the default setting (and it wasn't the default in the original installer, not even if you selected the "let the installer auto-configure everything" option).
1. No problem, if it improves readibility, it is welcome.
2. Why not. tbh, I never installed this part...
Edited by Gwendolyne, 06 August 2020 - 08:14 AM.