Mike1072

I'll try to take a look on Monday.

Updated to v4b9. Changelog: - Fix bug with halved specialization options in Multiclass Divine component preventing changes applying to Cleric/Mages and Cleric/Thieves - Fix helmet detection in Revised Critical Hits component - Update French translation

Awesome. I'll update the package shortly.

I'm not sure if Demi still keeps that archive up to date. The latest version can be downloaded from the first post in this thread.

Upload the screenshot somewhere like imgur and then use img tags to display it here.

Bug report from SHS:

This (old) macro is used by Divine Remix to alter a priest spell to an innate spell. // change regular spell to innate DEFINE_PATCH_MACRO ~spell_to_innate~ BEGIN READ_LONG 0x64 "abil_off" ELSE 0 READ_SHORT 0x68 "abil_num" ELSE 0 READ_ASCII ("%abil_off%" + 0x04) "bam" (8) // reads the bam filename from ability WRITE_SHORT 0x1C 4 // sets spell type to innate (4) WRITE_LONG 0x34 1 // sets spell level to 1 to avoid scripting issues WRITE_EVALUATED_ASCII 0x3A "%bam%" #8 // writes the bam filename from abilities to spell icon FOR ( index = 0 ; index < abil_num ; index = index + 1 ) BEGIN WRITE_SHORT ("%abil_off%" + 0x02 + (0x28 * "%index%")) 4 // changes ability icon location to innate (4) READ_SHORT ("%abil_off%" + 0x12 + (0x28 * "%index%")) "speed" // reads casting speed PATCH_IF ("%speed%" > 3) BEGIN WRITE_SHORT ("%abil_off%" + 0x12 + (0x28 * "%index%")) ("%speed%" - 2) // reduces casting speed END ELSE BEGIN WRITE_SHORT ("%abil_off%" + 0x12 + (0x28 * "%index%")) 0 // makes instant END END END You could use the macro in your mod or just follow the same steps when creating a custom spell using Near Infinity. Yes, your .tra files need to be converted to UTF-8 for BGEE. Download RealMod and follow what it does to automatically convert character sets for EE games. This is accomplished with the iconv folder (inside the languages directory) and the code listed in the ALWAYS block of the .tp2.

Which links aren't working? I was able to access the forum topic at BWL and the linked reservation page.

Apparently, some BWS users don't want to be playtesters. As the old saying almost goes, players want to play play play play play.

No problem.

Yeah, the forum email doesn't work sometimes. I try to manually validate any "awaiting authorization" members when I see one of their posts and confirm they're not a spambot.

Thankfully, that can be changed. And it is done. Don't go making crazy long polls just because you can.

If you're talking about NPC_EE, from what I understand, it only affects a few specific NPCs, much fewer than L1NPCs. The biggest difficulty in making a mod like L1NPCs that would affect any NPC is handling all of the special situations where an NPC might have custom items or scripts that expect them to be a specific class (or one of several classes, like Kulyok's Xan or Cmorgan's Aran). It's hard to find out all of the peculiarities of every single NPC. (I think that's why L1NPCs has a thread for NPC authors to submit their approval along with additional info like custom items.) It's also hard to test a mod like this, because to witness all of the content of all of the NPC mods would require a huge number of runs through the game. And maybe changing X from a Wizard to a Sorcerer doesn't cause any problems, but changing X from a Wizard to a Bard does. It would be completely fair to blame that mod if it got something wrong. Players should know not to expect miracles and that if they are using a mod that affects NPC X and they encounter a problem, then one possibility is that NPC X is to blame and the other is that the mod affecting NPC X is to blame.

I think the inquisitor's inability to memorize priest spells, the barbarian's d12 HD, and possibly the blade's reduced lore value are all tied to their usability flags. Sometimes when people say "valid", they mean "I don't know a reason to do this". Does valid here mean that, or does it mean the engine won't recognize any other value? I haven't messed around with making a kit for a multi-class, because I assumed it wouldn't work very well (e.g. when would it fulfill the level requirements in the CLAB file?). The kit creation tutorial has several mentions of not being able to make sorcerer/monk kits. This isn't technically true for BG2, but if you did make them, they wouldn't show up in character generation and they suffered from some hardcoded issues. AFAIK, you can create sorcerer and monk kits in the EE games perfectly fine. That's too bad. Did any mods in the 12 years (minimum) ever make use of something like this? My use was a melee-focused bard, so I wanted to restrict it from typical damage spells. I can't think of any kits in particular that did this, but I'm sure there are a few out there. Everyone used that tutorial. A lot of kits would be happy with the item restrictions of one vanilla kit, so they could just set their usability value to match that kit.

All this has happened before, and all this will happen again.

Yeah, the Workroom used to have very confusing privileges. We had all these customized privileges for specific people and the point of the Modder group wasn't really clear. Was it just for people who have stuff hosted at G3? That didn't make sense. Now anyone who's sort of involved in modding gets to be a modder (even Jarno).

This seems to be a problem with IPB and it's doubtful we can do anything about it. We may upgrade to IPB 4 in the future and the best we could hope is that they fixed that. You didn't have access to this forum before and now you do.

lol @ changelog

v4 Beta 12 has been released. Changelog: The v4 beta is now open to all playtesters with the understanding that feedback is desired. The latest download links can be found here. Please select the appropriate file for your operating system; if you're on Windows, choose the .exe.

The v4 beta is now open to all playtesters with the understanding that feedback is desired. The latest download links can be found here. Please select the appropriate file for your operating system; if you're on Windows, choose the .exe.

It's not abandoned, it's community-maintained! I have this thread bookmarked for an update later. (There wasn't much that could be done to the official download when this was posted, given the malfunctioning download centre.)

I can install the main component from the latest beta just fine (from the same Dropbox link ALIEN is using). I'm not sure if there's an actual problem with our current code or if someone just has the wrong files. The update_item_descriptions_to_bgee function should be in usability_description.tpa (not descriptions.tpa). The only place where the function is used is the main component, and the main component includes usability_description.tpa right at the start.

Don't worry about it. I deleted the wrong one long ago. Demi must have still had it hanging around his folder when he packaged the beta.

The concept of a .tpa file is very simple. It's just a file with more WeiDU code in it. When you INCLUDE it in your .tp2, it executes the .tpa code as though it was embedded in that spot in the .tp2. I think the add_kit_ee.tpa just defines a function, so if you include it, then you can use the function.

As per the WeiDU readme, it doesn't matter if you name your .tp2 "modname.tp2" or "setup-modname.tp2". I prefer it without the "setup-" prefix because it's unnecessary.