Jump to content

Bartimaeus

Members
  • Posts

    1,762
  • Joined

  • Last visited

Everything posted by Bartimaeus

  1. The msectype.2da says Spell Shield is #15, which matches your Secret Word and Spell Thrust. Looks like I'll have to do some EET testing tomorrow.
  2. The most basic explanation is that the 230 opcode ("remove one secondary type") removes a type of spell as identified by the "secondary type" field that each spell has set (or not set). Your spwi321.spl (Spell Thrust) casts two spells - spwi321b, and then spwi321c. spwi321b uses a 230 opcode with the type set to 1 i.e. against a spell protection (e.g. Minor Globe of Invulnerability). However, if a creature is protected by Spell Shield, Spell Shield will block spwi321b, thereby protecting the Spell Shield-ed creature from having their spell protection removed. Which is why spwi321c exists, as spwi321c is cast to then cancel the Spell Shield with the same kind of "remove one secondary type" effect, except instead of being set to the secondary type of a spell protection, it is set to the secondary type of Spell Shield. Only thing is, Spell Shield and its particular secondary type don't exist in the game by the default, so SR adds a new one to the game and then patches those files to make sure that the 230 opcode points to the correct secondary type. Having said all that, your spwi321c and spwi419c (the Spell Shield-dispelling part of those spells) point to secondary type "15"...assuming these are the installed versions of those files (i.e. not the versions from (game directory)/spell_rev/xxx, but the ones that actually came directly out of your override). What exactly 15 refers to depends on on what your "msectype.2da", the table that identifies and keeps track of secondary types, says it does. If you would be so kind as to attach your "msectype.2da" file from your override, that might prove illuminating. And also, uh, if you could modify your "clean" installation by reinstalling with the latest repo version of SR... (the "download ZIP" button) ...And making sure that it's still not functioning, then that also would be very helpful - it's possible the problem has been fixed since the last "full" release and I'm just not remembering. If that's the case, it looks like I'm going to have to create your exact install. And if that's the case, please also let me know what particular patch versions of the games you're using.
  3. Yeah, please don't bother with that, haha. It can be hard enough to write special abilities/properties in a reasonably short yet human-readable format when you're hand-writing it, I would never want to see what might happen if you tried to machine-generate all of it. Guess I'll go investigate vanilla descriptions some more. Okay, actually, I did find some examples of this - say, Shuruppak's Plate: I almost feel like this is a matter of ToB vs. SoA, because all of the SoA items I looked at seem to always place it in a "bonus", "special", or "special abilities", "equipped abilities", "combat abilities", or even just "abilities" field or something along those lines, while some ToB stuff like the aforementioned plate (among others) just do...whatever they want. Yeah, to be honest, I don't know what the right call is for vanilla descriptions - I suppose as long as it works for IR's purposes, it doesn't really matter that much. Non-EE's vanilla descriptions are an incredibly inconsistent disaster, it's probably folly to try to repair them. But it's actually for that exact same reason that I have to be careful when I would apply the full re-write, because just doing it on mod-added items en masse is sure to create similar sorts of inconsistencies. So it's probably a fool's errand to run that on anything where you don't already know how it will turn out, . Thanks for the fixes, I'll do some more investigation and testing tomorrow.
  4. That seems like it should be fine, too, honestly. Trying to recall if there's any reason it shouldn't be...thought I put it as late as possible for some reason, but I can't seem to remember what it would be now if so.
  5. So I guess I should move my recommendation of the secondary IRR components to before SCS/EET_END for EE players' sakes?
  6. Doing some different tests. Now it installs on vanilla without crashing while still using the IR list of armors, so that's a good measure for its compatibility. However, vanilla Red Dragon Scale's description goes from... ...to... I don't see anything particularly odd about Red Dragon Scale's description that would leave me to believe that the lore text should be stripped (also, lol @ Monk not being mentioned as an unusability in the original description), but there must be something. Similarly, armors with special bonuses/abilities tend to have said descriptions of bonuses/abilities shunted up directly to the STATISTICS like so: I imagine this is because vanilla item descriptions are a little dumb and don't have enough separation between special bonuses/abilities like either IR or the EEs do (which, now that I think about it, the EEs actually adopted many of the same conventions IR uses, like "equipped abilities" and "special abilities" and including the kits in unusabilities...hmm). Quite frankly, I don't care about vanilla descriptions, though, but many mod-added items are sure to use similarly lax formatting standards. An oddity in IRR's Pride of the Order occurred. From... ...to... I would say this is more the fault of my description of Pride of the Order, though, because simply saying "Lawful Good characters" is obviously a very incomplete description, but it does represent another vector where issues with others' descriptions may arise. Although...it's odd here, because while I originally wrote "Lawful Good characters" (which I'm going to change, by the way), your function split it into the two different lines and THEN also added the unusabilities.Weird. Regardless, this is leading me to believe that because of the variety of different formats offered between games and mods (many of which are sure to not have as strict formatting standards as e.g. IR or the EEs), it's probably not a wise idea to use the the full re-write indiscriminately, not when you do not already know what the results will be - there's just too many possibilities for errors and inconsistencies. I still need to test how this looks converting a non-EE IRR description to an EE description, though. The single line "Armor Class" rewrite, on the other hand, currently results in the same errors as I was getting before with the fuller re-write:
  7. In my experience, because there are no negative consequences to do doing so (unlike SR's secondary components), and to make sure it catches all items added by other mods. If you're concerned about it, do it right before - that particular one is one of the softer recommendations of my suggested install order, . (e): Amended install order for secondary components in the IRR/SRR original posts and readmes for EET's sake.
  8. Yeah, I'll keep you updated, still working on it, .
  9. Post it in a spoiler, like so: If that doesn't work because it's too long, just link to a pastebin that you created with it: https://pastebin.com/ Did you install SR first, then reinstall with SRR, or the other way around? To be honest, even if you did do that, I don't see why that would break e.g. Secret Word, the most basic and unchanged of all anti-magic spells, especially because SRR doesn't make any changes to Secret Word. So I don't really know, and I probably won't be able to figure out anything from your weidu.log to be honest. I guess one thing you could so is post your spwi419.spl, spwi419b.spl, and spwi419c.spl (Secret Word) from your SRR-installed override folder, and then...oh, let's say spwi420.spl (Minor Spell Deflection). If you could upload those, I could at least see whether or not the basic dispelling function looks correct.
  10. That's, uh, that's a new one I haven't ever heard. Your installation, if that's all you have, is very simple, too. Are you in the middle of a playthrough already, or what?
  11. You're right, that seems to be an IR invention that I was not aware of. And of course, the EEs automatically handle it by having their own class/kit unusabilities automatically generated by reading the .itm directly. I'll try out the new semi-soon.
  12. Completely unrelated, but any time I download an attachment from Gibberlings 3, my browser (Firefox) tells me it's malware and I have to manually allow it. Whether it's just an .itm, a .spl, your .zip up there, it always flags everything attached here. I can even upload the same file somewhere else (e.g. my dropbox) without changing it and redownload it, and it doesn't flag it...and then I click on your attachment again, and once more, it is flagged. Really weird. Right now, I'm trying to test the "LPF itemdesc END" with IR's whitelist of "approved" armors, but I'm running into piles of "SET_STRING out of range"s. These seem to occur on unusable .itms that exist in my game (including vanilla items!), such as vischan1, vischan2, et cetera, plat07, plat98, plat99, dleat01, et cetera, et cetera. I can't help but notice that these seem to be all items who have a full unidentified description set as if they were an identified, non-magical item with no identified description set. I removed the ones that exist in my game that break the game from the list, but I am a bit concerned about including this code in other people's games that have many more items in the approved whitelist than I do that will break their installation processes because of the same kinds of errors. This is a huge (+700) list of approved armors to patch, so similar errors are bound to occur...right? Hmm, perhaps a safety measure would be that if there is no identified description, simply set the identified description to the same as the unidentified description (and if neither are set, simply skip the item in question entirely)? For the items that were problems in my installation, doing this in advance does appear to fix the issue. Actually, I'm pretty I can probably do this myself with a couple of byte reads and writes, to be honest, so maybe don't bother unless you think you could do it quickly and elegantly? The "generate the 'not usable by' list" function does not currently include kits, which means e.g. a plate mail armor which originally said... ...turns into... Beyond those two issues, my tests on armor in both ToBEx and BG2EE games seems to suggest it works well. Thanks a ton, @DavidW, . I'll try to test weapons at some point later.
  13. Sorry, I believe I fixed it with the latest repo, but I don't have time to test it right now. It looked like it was simply a matter of a missing "BEGIN" that I didn't add when moving around some stuff.
  14. I was initially confused by what Lianos wrote as well, but it seems as though I made a goof recently where I accidentally replaced two instances of "Damage type: piercing" with "Damage type piercing". The missing colon is breaking Weapon Changes and preventing this sword (and Short Sword of Mask +5) from having their descriptions updated to say "slashing" when you install Weapon Changes (as Weapon Changes makes short swords slashing damage instead, as has been the case for many years). Thanks, Lianos!
  15. One thing I'd suggest is that the main component of Spell Revisions is supposed to be installed after the main component of Item Revisions (but before Store Revisions). Right now, you have it the opposite way around with SR coming first and IR coming second. There will be a number of inconsistencies (none game-breaking, but...some missing spell scrolls from stores, some item abilities that don't get updated, stuff like that) as a result of that decision. What I do is: 1. Main component of IR right exactly where you put it. 2. Then the main component of SR immediately after that, with CD/Anthology Tweaks after both (but it's okay to have other stuff in between). 3. The rest of SR right before starting SCS. 4. Finally, the rest of IR more towards the end (for you, specifically, I'd put the rest of IR maybe right after "BG1NPCSOA"). Besides that, I can't see anything outstanding that immediately jumps out to me, but I am admittedly half-asleep right now.
  16. I'm in the same boat as you right now re: sleepiness, but my understanding is that the first component uses the same values as the vanilla game, but Revised Armors changes all of them up to completely different values. I'm working off of memory here, but I recall Cahir thinking the same thing as you, that Revised Armors does not do that (is it not mentioned in the readme of IR for Revised Armors that it would do that?), but in actuality it does. Yes, I think I have envisioned the solution on a conceptual level, but I do not know at all how to implement it on a technical level especially because I despise doing complicated replacements that are anything more than "(this string)" replaced with "(this string)", .
  17. Being able to import a weidu.log is the best feature I've heard about Project Infinity thus far. It's already possible to automate an entire installation with just any old weidu.exe and weidu.log, but it's...finicky and can lead to broken installs if you don't do it just perfectly. Perhaps next time I complete an install, I'll try using it and seeing how it prepares to my own automation method.
  18. This might be a little complicated, but here goes. This is what the AC line in a BGEE game would look like: The flat AC as usual, then what the AC actually equals vs. the different damage types as (and if they're) modified by the type of armor (as each type of armor e.g. leather, chain, plate, etc. has different inherent bonuses, bonuses that exist in the vanilla game but which are also systematically and globally revised by IR). Notice the lack of mentioning crushing weapons - this is because there is neither a bonus nor penalty to crushing weapons with this particular armor type. This is what the AC line looks like in IR/R currently: No mention of the vs. damage types AC values, so IR/R's descriptions (including even my own EE-specific descriptions) are currently not consistent with EE-type descriptions. I can certainly add that information to each and every armor's description so that it's there, BUT the issue is with IR's Revised Armors components, which, as previously mentioned, systematically and globally revises what those specific vs. damage type bonuses are for each type of armor. So if you add that information, it will no longer be accurate - it must be updated in the event of someone installing that component. One solution that Subtledoctor mentioned was simply having that component manually set each and every vanilla item's description so that it's accurate to the new values, but this is an inelegant solution, to say the least - not just because it becomes a bit unwieldy to upkeep, but also because the "Revised Armors" component actually applies to all armors, including ones that are not currently handled by IR (mostly EE-specific armors) and also a number of other mod-added armors that could potentially be in a user's install. So that system would leave you with armors whose descriptions are still inaccurate, which is obviously an undesired behavior. The system I envision, really, would be something that would scan all items for the following criteria: 1. The item's item type is set to 2 (armor). 2. The item has an identified description. 3. If it doesn't have an identified description, instead check for an unidentified description (and if it has both, it should only try to patch the identified description, not both...I THINK - if that turns out to not be the case, that would be easy to change, though). 4. The selected description of the item must have a line that reads "Armor Class:". 5. The item must have an opcode 0 (Armor Class vs. Damage Type Modifier) with a type of 16 (base AC). If all of these conditions are true, replace the currently existing "Armor Class:" line with a new "Armor Class:" line that is generated by detecting what the base AC (type 16) is, then write the parenthesized information e.g. "(-2 vs. slashing, 0 vs. piercing and missile)" dependent on detecting additional opcodes for AC types 1 (vs. crushing), 2 (vs. missile), 4 (vs. piercing), and 8 (vs. slashing) and using them to increment or decrement (depending on their values) from the flat AC (but don't read AC type 0 AKA "all weapons" - this one should be ignored). If there is no opcode for one of them, then that particular item should not be written. If an armor has the same bonus/penalty for multiple damage types, then they should be combined (i.e. it wouldn't be "-2 vs. slashing, 0 vs. piercing, 0 vs missile", it'd just be "-2 vs. slashing, 0 vs. piercing and missile"). I believe this is everything you would have to do for the style to remain perfectly consistent with the EE's armor descriptions. It seems obscenely complicated to me for so very little benefit, which is why I currently do absolutely nothing about it and stopped trying to investigate it, .
  19. Yeah, I've never used PI, so I really have no advice to give. Your own installation order looks like it should work, though, .
  20. IWD spells: From what I recall, SR/R uses the same identifiers for overlapping spells that prevents SCS from installing similar versions of spells. That is, if SR installs its version of Icelance, then SCS should skip its own version of Icelance and just try to use SR's where possible. Is that not the case? Infinity Animations: I actually have no idea as to the answer of this one. I'm not sure if you can install Infinity Animations on EE games or whether it serves any real purpose. Install order: In what order is Project Infinity installing stuff anyways? I'd be curious to see your weidu.log to see how it's doing things. Anyways, "main component" is the very first component of both mods, the component that installs all the spells and items. The other components are the "patching" components, that patch all of the items and spells after the fact (and should only be installed later in the install order, especially after all other item mods have already been installed).
  21. Maybe, I'm really not sure. Could never come up with something that felt satisfying and effective from a player perspective without seeming weak or outright terrible from an enemy perspective (or the opposite: getting it strong enough for enemies means getting it too overpowered for players), which is why I never developed it any further from that point. The issue of Dispel/Remove Magic will probably never be resolved to everyone's liking... On an unrelated note, does anyone know the current state of SR translations? I believe it's...French and Russian that are currently enabled as alternative languages? Don't quote me on that, but there's at least one other language enabled. What do you do when you want to majorly update a spell's description, either because you changed its function or because it was simply incomplete or inaccurate - like that of Non-Detection? Do you let the translation stay enabled even though it's out of date? With IRR, I knew early on that I was going to add and change enough that updating their translations would be...prohibitively difficult for me, and a ton of upkeep for probably very little benefit given the small playerbase, so I immediately disabled them, and basically the same thinking applied to SRR. So how would that normally work for updating the official versions?
  22. You're only considering it from the player's perspective, but remember that enemies will use Remove Magic as well, and in serious battles, the player is like to have a *lot* of both active. I was never satisfied with whatever I could come up with for these reasons, and why I ultimately prefer the lame-brained saving throw implementation, . It was more designed on just a "if someone wants to test this and provide feedback on it, then we can see where we can go from there" basis. I recall it...mostly working when I tested a few different scenarios, but oddities could occur, especially if you pay strict attention to the order of spells that SCS cast (IIRC, SCS spellcasters would sometimes break SR's "rules" but the practical effect was that they would ultimately still cast mostly the same spells, but perhaps in the wrong order). Hell no, I just provided it as a separate option because...why not? If you're serious about reducing the importance of mage battles, the option is there. In my opinion, neither options should be enabled by default, which is why they aren't, . I am almost a hundred percent certain that Dispel Magic and Remove Magic always bypass spell e.g. Spell Deflection regardless of whether or not you have that component enabled. Although Dispel and Remove Magic would be perfectly fine to patch with that component, they seem to have been deliberately excluded. (e): Yes, the description of Remove/Dispel Magic literally explicitly states Spell Deflection won't protect the caster from the Remove/Dispel Magic (but won't take it down either). It seems to be deliberate, for better or for worse.
  23. Yep, it's Revised Armor that is the issue. Revised Armor changes those bonuses/penalties for all armor types, hence why I haven't included that text (...yet). Basically, it needs to be able to detect what the current flat AC is, then write those bonuses dynamically depending on what the new bonuses/penalties set are (dependent upon the type of armor, like leather or chain mail or plate). Also probably need to be able to account for armor that includes that text OR doesn't include that text, because Revised Armors affects all armor globally. While I've occasionally been able to punch above my weight in figuring out some stuff, that is a little much for me.
  24. Good call, fixed - happened when I was waffling between opening up the backstab modifier for everyone and just rangers a little while back.
×
×
  • Create New...