Bartimaeus

It's probably unlikely anyone knows for sure except DavidW himself, and he's currently on hiatus. If you don't feel like testing and experimenting, then it's probably best to stick with an older version.

I removed it, still not actually updating the .tp2 to 1.2.9.

When you summon a creature via opcode 177 (use EFF), you use self-targeting there as well even when you're casting the spell at a distant point, and using any other kind of targeting seems to break it. I'm not sure why the engine interprets it that way, but I imagine it's a similar thing here.

I tried to implement the new version with IRR, and it no longer seems to work. Smartgit says this when committing: C:\GitHub\IR_Revised> git.exe -c "credential.helper=C:/Program\ Files/SmartGit/lib/credentials.cmd" rm -- "item_rev\settings - Copy.ini" rm 'item_rev/settings - Copy.ini' C:\GitHub\IR_Revised> git.exe commit --file=C:/Users/BARTIM~1/AppData/Local/Temp/smartgit-5881788229702730413tmp/commit-15882150802797423814.tmp -o -- "item_rev\settings - Copy.ini" Old version: V1.2.8 New version: V1.2.9 LF will be replaced by CRLF in item_rev/item_rev.tp2. The file will have its original line endings in your working directory [master 4db5888] Test versioning again again again again again 1 file changed, 31 deletions(-) delete mode 100644 item_rev/settings - Copy.ini C:\GitHub\IR_Revised> git.exe -c "credential.helper=C:/Program\ Files/SmartGit/lib/credentials.cmd" push --porcelain --progress --recurse-submodules=check origin refs/heads/master:refs/heads/master Delta compression using up to 8 threads Total 3 (delta 2), reused 0 (delta 0) To https://github.com/BartyMae/IR_Revised.git refs/heads/master:refs/heads/master d8dc415..4db5888 Done 'master' pushed: d8dc415..4db5888 Delta compression using up to 8 threads Total 3 (delta 2), reused 0 (delta 0) The correctly ECHO-ed "Old version" and "New Version" suggests it's able to find the correct field and knows how to increment it, but it isn't actually taking on the .tp2 itself even after multiple tries. I guess that would suggest there's something not working with the "sed" command (which I'm not familiar with).

Area of Effect: 1 creature That's really weird. Could swear I fixed that eons ago. At least the actual spell description makes it clear that it's multiple targets. Thanks. Fixed on the latest repo along with familiars' inventory items' now being correctly set to "Familiar", plus Fighter HLA's should get the correct names and descriptions again. (e): @Hoverdawg "Another one that's broken is Giant Spider's webbing ability." Giant Spider's webbing ability? Giant Spiders don't have webbing, could you explain more?

I did notice I was getting yelled at every time I made a commit now by SmartGit for that. Thanks, .

If I had to guess, when IWD1/HOW are installed, the installers set a number of registry values and install a few files in pre-determined locations that the Trials of the Luremaster patch attempts to confirm are correct before it goes ahead. Most likely what's happened is that Windows 10 has changed how it handles something in that process from previous versions of Windows, so that a file or registry value gets put somewhere that the patch does not expect and cannot account for. Windows 10 has also undergone a number of majors revisions at this point, it's possible that it could even be a subversion problem. I attempted to identify all the checks that the patch checked for, but was unfortunately unable to successfully identify all of them. (e): Why does trying to use spoilers break every single one of my posts whenever I try to use it every single time on these forums? Ugh. Registry values it seemed to need: [HKEY_LOCAL_MACHINE\software\WOW6432Node\Black Isle] [HKEY_LOCAL_MACHINE\software\WOW6432Node\Black Isle\Icewind Dale] [HKEY_LOCAL_MACHINE\software\WOW6432Node\Black Isle\Icewind Dale\1.00.000] "Language"="English" [HKEY_LOCAL_MACHINE\software\WOW6432Node\Black Isle\Icewind Dale - Heart of Winter] "Path"="%Game Folder%" "FullPath"="%Game Folder%\\IDMain.exe" [HKEY_LOCAL_MACHINE\software\WOW6432Node\Black Isle\Icewind Dale - Heart of Winter\1.00.000] [HKEY_LOCAL_MACHINE\software\microsoft\Windows\CurrentVersion\App Paths\IDMain.exe] "Path"="%Game Folder%" @="%Game Folder%\\IDMain.exe" It also needed some file called like ISInstall.exe or something in the C:\Windows folder, and some files in the C:\Program Files (x86)\Common folder. It also, of course, needed IDMain.exe in the Icewind Dale directory (but nothing else). Removing one of these would each cause the Trials of the Luremaster patch to fail - but transposing all of these to a clean system that hadn't already had IWD+HOW installed before owuld still not let me run the Trials of the Luremaster patch, so it seems as though there is still at least one other check I am missing. Very strange, since I ran it in a sandbox and should've been able to see every single change made to the system by these two installers, and I did a complete registry hive comparison, but still was not able to find whatever it was missing. Sorry!

That stinks. The Trials of the Luremaster install .exe is 71.2MB, right?

That's pretty cool. Would be quite the spectacle to get blasted by a bunch of them at once.

Seems to work with IR and SR, thanks!

@Hoverdawg Okay, inventory items I'll fix. I'll take a look at some of the lower level creatures in a BG1:EE-only environment at some point and see what I can do to either fix or remove improper strings (depending on what's available in BG1).

Yeah, sure.

Sorry, I meant more...are you on the BG1:EE engine? As in, not a BG2:EE/BGT:EE game. Based on your mod install, that's my presumption. Basically, SR was made for the BG2 engine, and so strings (text messages like "Spell ineffective", or names of creatures like your familiar) are assumed to match values from BG2, while BG1 often times has different values for those strings, leading to mismatches. Specifically in regards to your cat, do you mean the creature or the item? From what I can see, I set the text fields for every familiar creature to make sure they were set properly, but I didn't enforce it for the items, so my presumption is that's the problem. I'll have to look into the ogre one. Sound Burst: Can't confirm. Used the same exact SRR components as you did and cast it on a hostile kobold, instant death for them. The spell specifies only enemies - are you using it on neutrals/friendlies?

If I was doing it that way, I guess I'd have to get rid of displaying the final number anywhere but the version field, since that'd get so annoying to keep updating elsewhere. Sure, tell/link to me how! @The hash: Ahh, I thought the commit number...was...derived from the change itself, but it being a hash of the entire thing makes a lot more sense and does make it impossible, yeah.

@Hoverdawg BG1:EE only?

Yes, that's correct. "Master" always contains the latest fixes, and I always try to make sure I never put anything in the master that won't work if someone downloads it instead of the latest retail release, although I am not always perfect, .

See, I recommend people do the opposite for my mods, because I'm not going to increment a version number for every last little minor bug fix I commit to the latest version...and I only commit things when I believe they are working (...which hasn't been true a couple of times over the years, but overall, not a bad record).

There are a number of people good with github here - I am not one of those people. Basically, the idea I'm wondering is if there's a way to automatically have the mod version number update to the latest commit number? For example: VERSION ~V4 Beta 10~ ...-> VERSION ~V4 Beta 10 (%Commit Number%)~ ...where "%Commit Number%" is simply whatever the latest commit number is from when they downloaded it. That way, when someone posts their weidu log, you can see the exact version of the mod that they downloaded from github if you're the type of person that makes a number of changes before officially incrementing a new version number. I did some cursory searches, but didn't find anything too related to what I was looking for.

Yeah, I patched that part out and it's on the latest github repo. I do not know why it was doing that to begin with - I am sure there was some kind of reason, but it certainly seems way out of scope of the component. Sorry for the trouble - pretty surprised nobody saw it in either IR or IRR beore, guess it must be a not very used option.

The component that I presume is causing the problem is "Revised Backstabbing" - specifically the "More Weapons Usable for Backstabbing" subcomponent. IRR has never touched this, so it's a bug in the normal mod as well. The problem is that the mod detects literally any item that's usable by a thief multiclass (e.g. thief/fighter, thief/mage) and makes it so that a base thief can use it. Which the description of this subcomponent does not in any way, shape, or form imply it would do. So that means every weapon and armor that's normally not usable by a thief - axes, chain mail, halberds, plate, robes, etc. - is usable by a thief. Do you have this subcomponent installed?

Issa bug! Sorry for the trouble but thanks for reporting, let me know if you see any others, .

What edition and version of the game are you running? Give us the exact resources you're attempting to use and let us see if it works and modify it until it does if necessary. (e): Okay, wait, I just read the other thread right after this - I guess you finally solved it?

Soul Reaver looks like it could be a car key, Dragonslayer is anime, and somebody thought a sword split down the middle was a good idea for the Equalizer.

I'm not even sure how you're supposed to hold these - are these architectural masterpieces or weapons?

Yeah, to try and clear it out and make the OS think it's not installed anymore. If you haven't any experience with regedit, it's probably not the safest to mess around with, though.