Jump to content

Salk

Modders
  • Posts

    3,124
  • Joined

  • Last visited

About Salk

  • Birthday 12/30/1973

Profile Information

  • Gender
    Male
  • Location
    Sweden

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Recent Profile Visitors

13,205 profile views

Salk's Achievements

  1. 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.
  2. 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!
  3. 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!
  4. 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!
  5. 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.
  6. 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!
  7. Thanks, DavidW! It is useful information. Is there a place inside SCS I can look for that list you mentioned?
  8. 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?
  9. Ultimately I think that what Bartimaeus said makes the most sense. He'd need someone that played with both the original IR and the current IRR to point out possible issues or flaws in the latter. Or simply give a reason why one or more of the changes made in IRR aren't "right". Personally I enjoyed discussing and brainstorming with Bartimaeus both here and in private tackling different aspects that we both felt needed improvements. I think IRR came a long way now and, despite what Bartimaeus himself says about his own attitude, I find him to be quite open to suggestions and capable of reverting some of his own changes if a valid argument is being made.
  10. 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.
  11. 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.
  12. 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?
  13. 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?
×
×
  • Create New...