Salk

Will do. Thanks!

Thanks for the answer, lynx. I had kind of figured the geometrical shape of the area of effect. It's the size that I need to nail as numerical value though. It's what needed for the spell's description.

Hello! I hope this is the right place to ask. Can someone tell me what the actual size of the AoE of a cone projectile (like CSPRAY.PRO) is? NI shows me two values (being the same, 250) for both "Trap size" and "Explosion size" with an angle of 90 degrees. What kind of geometric figure does it produce? And another question: can someone tell me what the Trap size and Explosion size values indicate in particular? They are often the same but not always (for ex, CONECOLD.PRO has 250 for "Trap size" but 300 for "Explosion size"). I checked IESDP's info about .PRO files and from what I understand the size would be derived by dividing the "Explosion size" by 8.5. Does this mean that CSPRAY.PRO's covers an area that is ca 29.4 feet long? Or since it is a diameter we should just halve that value? Thanks!

Kudos for the big effort in pushing out version 700 for both SRR and IRR, Bartimaeus.

Congratulations on this new release, Bartimaeus! And thanks TotoR for spotting a bug right after it... Good catch!

I agree with Lianos here. The +X bonus to the stat is preferable to the flat value but I understand what Bartimaeus says about making the item even more abusive.

Hello! The person who worked on the EE port of my modification is @flamewing. I don't remember encountering this kind of problem with my latest version of the modification. But it has already been reported in 2018 (see here: https://github.com/flamewing/WTPFamiliars/issues/1) and it doesn't seem there has been any kind of progress in solving the matter.

Hello! I don't have alignment requirements mixed with the class requirements. Here is an example of the revised text for the original Robe of Good Archmagi: @10037 = ~This powerful mage robe offers protection from all forms of physical attack while at the same time increasing one's Magic Resistance and Saving Throws. Due to the nature of its enchantment, it can only be worn by wizards of good alignment. STATISTICS: Equipped abilities: – Armor Class: 5 – Saving Throws: +1 – Magic Resistance: +5% Requires: Good alignment Weight: 6 Only usable by: Mage Sorcerer~ Note that I don't always go for the "Not usable by:" list. When the entries become too many they'd impair readability I simply switch to "Only usable by:" instead. This worries me much more instead and will require some thinking. I don't have at the moment a chance to check this for you but I wouldn't be surprised if it was already so. All the best!

Hi again! Can you give me a practical example of usability woe by having a strict alphabetical order for classes? Yes, I had no idea you were working on something like that. The last time I checked on your progress with IRR and SRR was well over a month and half ago. I used the original BG2 EE dialog.tlk as base for my revision. My own changes are really minor and have mostly to do with punctuation and compatibility (mostly, the EE text lacking usability descriptions for items). And that takes me to the next part... Can you give me an example of this too? I don't think there should be any problem because, as I mentioned, this is almost a straight port of the BG2 EE original dialog.tlk file but I surely don't want to make a mess and cause compatibility problems. I have been careless in what I wrote above. What I wanted to say was that the INT requirement for arcane spells wands should be the very same we apply for learning the spell itself: 1-4 Int 9+ 5 Int 10+ 6 Int 12+ 7 Int 14+ 8 Int 16+ 9 Int 18+ It might seem harsh but I favor internal consistency over the rest. If you create your own character you are responsible about how you spend your ability points. When it comes to joinable NPCs instead, it just becomes a matter of whether or not they are intelligent enough to cast high level spells. Note that a measly Int of 9 would still allow them to use many, if not most, wands. Cheers!

Hello again! Thank you for replying to my query. This thing about the EE description is interesting because I have been working on a revamped BG2 GTU which is based on the BG2 EE. I like both IRR's classic and the new EE approach to items and spells descriptions but for the work I am doing I became much more familiar with EE text style so I am quite confident that'll be my choice. Incidentally, for the class requirements I decided to go for a simple alphabetical order rather than the current implementation because I think it makes most sense. It won't be a problem sticking to v247 for IRR, SRR and SCS though. It is possible to use the "--noautoupdate" argument when launching the installer from the command window so that v247 won't update the other WeiDu .exe files it finds. A few comments about your remaining points in your list: 1. I think you have it right with what you wrote last about it. Let WeiDU check the standard values for different shield types and patch the item if they are a match and just skip them if they aren't. At the moment I can't seem to think of a better solution myself. 2. Nothing to comment here. 3. I do trust your aesthetics sense but I cannot give you my direct opinion here since I never saw any comparison shots. Generally, I don't feel particularly attached to original graphics if it can be replaced with better. Of course the requirement being that it should be a seamless change (same style and bonus point if the drawing is close to the original). 4. Here I must say I pretty much like the original formula. It's simple and it makes sense. Matching the requirement for wand use to the Int requirement for casting the spell is a very sensible change, in my opinion. Good luck!

Hey Bartimaeus! I noticed you upgraded to WeiDU 247 and I have a question. Would the IRR installation (and possibly SRR) work even with older WeiDU versions? I have had unpleasant experiences with v247. I was hoping for v248 to be out soon but apparently it's going to take a while longer so I am sticking to v246 for the time being for every mod that does not require v247.

No, I do want SCS to handle all combat scripts except for 3-4 cases for which I created custom scripts for a few NPCs. Since they are not generic combat scripts then there should not be any compatibility problems after what you told me. Cheers!

Thanks, DavidW! It is useful information. Is there a place inside SCS I can look for that list you mentioned?

Hello, DavidW! I don't know if it might have escaped your attention but I asked you a question here about SCS and I would be grateful for an answer, if possible. I might add another question: is there a way to manually exclude some specific CRE scripts from being changed by SCS prior to installation? Thanks! EDIT: One last curiosity. It seems the size of SCS increased with 30-35% since v33. What's the cause?

And what is this supposed to mean?

A question, DavidW. If I modify some creature's original script(s) and/or swap the original script(s) with a new one(s) before installing SCS, what does SCS do when it comes to it? I'm asking because I customized a few combat scripts for some BG1 NPCs and was wondering if they'd be affected. Thanks.

Not the way I see it. DavidW kindly produced that particular .ini setting quite a few years ago for my own benefit and for a few others' that did not like the fact that the AI was capable of opposing a strategy that benefits of the perfect knowledge of the party's protective items. My view was very different. The AI should only be allowed to learn about protection against spells only after being unsuccessful. This is how it is for the Player and I felt it was only fair that it should be so for the AI as well. Since v32, the AI became less effective at detecting the party's protective items (unless the AI_Is_Omniscient flag is set to 1). They would now need to fail once in order to stop using an ineffective spell. That is a good compromise overall. But the reason for a spell to fail may well lie in the target's successful saving against it. A spell could be ineffective because the target simply resisted it or because of a temporary buff. I personally still prefer keeping the AI oblivious to protective items because of that. Despite "crippling" their strategy, I found that the SCS AI is still way better than the original's. Especially in the BG1 portion of the game when playing BGT.

It's PROFICIENCYGUN, but isn't that the same for all people installing SCS on classic BG2 or BGT? I mean, if it was indeed the culprit, wouldn't we have the SCS Forum full of reports about those nasty parse errors?

Yes.

Hello @Luke! Thanks for the assistance. I was convinced that the problem came from the .ini setting I (and few others) use to prevent the AI to detect protective equipment but If that is not the case and the issue comes from the different named stat #109, is there something I can do on my side to remedy it?

Oh okay. I thought it was an easy change in your SSL code. I do think it's harmless like you say but it's a bit annoying to have almost 300.000 parse errors during installation. Thanks for v34!

Hi DavidW! I read to the change-log for v34 but I didn't find any mention about this issue. Is there something that can be done about it?

Thanks, CamDawg. I suspected that much but I needed some confirmation If anyone does know of pertinent changes, I would be grateful for additional information.

Hello! I am in the process of working on an updated GTU for the classic BG2 game, using the BG2:EE revision's own GTU as base and reference. I would like to know if someone could point me to a detailed list of major changes between the two games that might affect the game text. For example, difference between classes. When comparing the description for the Wizard Slayer class there are substantial differences: the cumulative chance of spell failure for successfully hit target is 10% in the classic and 25% in EE and the magic resistance is reported to be 1% / level in the classic while it is 1% up to level 19 and from level 20 onwards it alternates between 1% and 5%. Thanks for your help.

I personally do not like any possibility of turning any neutral character hostile by attempting any kind of charm spell. It would only lead to reload.