Salk

Valygar and Edwin there do sound like they have unfinished business... 

But I actually agree here with the Imp: it seems like this belongs to the Fixpack.

Hello!

In the past, Hurricane opened a now archived topic called Unusability Woes. I found some other more items whose usability is questionable and possibly inconsistent. 

Gloves of Missile Snaring (brac18.itm): other than the customary Wizard Slayer and Kensai classes, these gloves cannot be worn by Clerics (single or multiclass), Mages (single class) and Druids (single or multiclass). No such usability restriction is mentioned in the description. The gloves give a simple bonus vs missile attacks.

Gloves of Healing (brac20.itm): other than the customary Wizard Slayer and Kensai classes, these gloves cannot be worn by Clerics (single class), Druids (single class) and Mages (single class). No such usability restriction is mentioned in the description. These gloves heal up to 10 HP and cure poison. The usability restrictions here are odd, to say the least.

Boots of Phasing (boot08.itm): they are for some unfathomable reason unusable for Mage and Avenger.

Moon Dog Figurine (misc7t.itm): it seems it can be used by monks when I believe it should be usable by rangers only.

Blue Dragon Plate (plat20.itm): it has redundant usability flag set for all bard's kits.

Harp of Discord (misc3m.itm): it has redundant usability flag set for Wizard Slayer.

Azlaer's Harp (misc3n.itm): it has redundant usability flag set for Wizard Slayer.

Methild's Harp (misc3o.itm): it has redundant usability flag set for Wizard Slayer.

Wong Fei's Ioun Stone (helm34.itm): It is reserved to Fighter and Monk but standard usability includes Barbarians while in this case Barbarians are excluded.

I will update the above list with more items worth of our attention.

Cheers!

Changing from 60 or 90 ft. to 40 ft. does not actually seem to make any difference in terms of gameplay.

From what @Bartimaeusafter testing the actual max range in the BG game, it appears to be 26 feet. Having any spell description provide a farther distance for range is, in fact, misleading. The so called "visual range of the caster" information should be replaced with 25 feet (a fair approximation to the nearest multiple of 5 number) and so should every and each range changed when it exceeds 25 feet.

That's what I have been doing for a new version of the BG2 GTU. 

I vote for solution 2 as well.

The departure from the original intent is not egregious and the gain for the item is rather negligible.

The BG2 Fixpack is only for the original game.

Congratulations on this new release, CamDawg!

And thanks for all your hard work through the years. 

Bartimaeus was also kind enough to test the actual max range for spells in the game.

It seems that such range is 26 feet. So 4 feet shy of the 30 feet that I thought was the max range.

Due to the fact that some spells (10) DO have a range of 25 feet, I opted for textually capping the range limit for spells to 25. It's not ideal because:

1) The true max range is one foot bigger

2) It sort of breaks a canon 30 ft. description that will be systematically replaced together with the inane "Visual range of the caster" that doesn't mean anything

but I thought it was better than misleading the player with a much less acceptable approximation where the range would be described as 4 feet bigger than it actually is.

This takes care also of the ludicrously big ranges (120 ft.+) that are found in some spell descriptions.

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!

19 minutes ago, Bartimaeus said:

How would you handle this, Casiel's Soul? In IRR, it's currently...

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.

19 minutes ago, Bartimaeus said:

Well...for example, Revised Armors revises the bonuses vs. different damage types, so the listed bonuses would be incorrect; components like "you can cast spells in armor" are likely to place the spellcasting failure/speed cast penalty in the incorrect spot in the EE format style; the Revised Helmets component won't know how to update the helmet text in the EE format; Weapon Changes may not be able to parse updating proficiencies (or even changed damage/THAC0 bonuses for e.g. ammunition) as it stands with the EE formatting. All those text changes are performed on the fly by identifying particular key fields in particular formats, so if you're using IR's secondary components and changing text around, you may run into those kinds of inconsistencies. DavidW was kind enough to fix the most major one, the "bonuses vs. different damage types" one, and I've fixed SOME of the other ones, but I'm still working on others.

This worries me much more instead and will require some thinking.

19 minutes ago, Bartimaeus said:

That's much more like what I had in mind, I should probably adopt it. I wonder how the intelligence requirements of vanilla wands compare - perhaps they already do do that and I simply did not recognize it at the time.

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!

55 minutes ago, Bartimaeus said:

I do base classes first in alphabetical order, then kits in alphabetical order. I find placing all of them strictly in alphabetical order to be displeasing from a usability standpoint, since it becomes more difficult to parse which base classes are restricted quickly.

Can you give me a practical example of usability woe by having a strict alphabetical order for classes? 

55 minutes ago, Bartimaeus said:

The EE-ized description file currently included in the latest repository version of IRR may be of interest to you, in that case...or not, depending on where exactly you took your own revised descriptions.

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...

55 minutes ago, Bartimaeus said:

Be warned that by making your own formatting changes, you may very well break the description-updating components of all the other secondary components, which is the current trouble Cahir and I had been running into for a long time

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.

55 minutes ago, Bartimaeus said:

I thought so too, but then I considered that if you were to follow this formula to its logical extreme, a wand that casts a level 9 spell would require 19 intelligence, which is absurd - indeed, any wands that would cast high level spells would have unreasonably high intelligence requirements and make it so some actual NPC mages would be unable to use them.

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. 

3 minutes ago, DavidW said:

(Though to some extent, if you want to prevent a generic combat script from being SCS-ified, you might want to ask if you want SCS at all.)

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?

5 hours ago, AnnabelleRose said:

So other than Vlad's mods, can we just flush the rest down the toilet?

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.

14 minutes ago, Guest Morgoth said:

Isn't the change you made in the .ini countering SCS purpose ? If I read a reasonable explanation I can think about changing the .ini setting too, because I had never thought why you would do that at all. 

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.

33 minutes ago, Luke said:

@Salk

Just out of curiosity, open your local copy of "STATS.IDS" with something like NearInfinity and check what's the ID of stat #109. It'll be most likely different from WEAPON_ENCHANTMENT...

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?