Jump to content

grodrigues

Members
  • Posts

    173
  • Joined

  • Last visited

Everything posted by grodrigues

  1. I have the feeling that what should be a simple change is getting a bit out of hand. Maybe we should resurrect subtledoctor's idea and defer the "charm neutrals" job to a dedicated spell like Friends, maybe even targetting only non-hostiles to prevent douchebaggery. The re-balancing of the charm spells (e.g. the save bonuses) could then be discussed without bringing in the complications of this particular RFC.
  2. There are several types of charm available in the IE engine. For the purposes of this RFC, the two most important are (using the IESDP terminology): neutral and hostile, the main difference between the two being that the former does not change the target's allegiance while the latter does. In practical terms, this means that if the charm is of neutral type, when it ends the victim does not see you as an enemy. This is important because in BG1 many dialogue lines can be unlocked only if you charm the target. Currently in SR, all the charms are of hostile type (the same as vanilla EE by the way), so if you charm the target you make the NPC hostile which is undesirable for obvious reasons. The obvious way to go about it is to change the charm type; unfortunately, there are all sorts of complications, so this RFC is to discuss these. 1. Start with an implementation note. As I said in the preamble, at a very low level this is just changing the first parameter of the Charm opcode. But we can be a little smarter about it and if necessary, use subspells to have a charm type per allegiance (think how Otiluke's Sphere behaves differently whether the target is hostile or not). 2. The second point is the scope of the changes. I think it is clear that Dire Charm and Domination should be left alone (charms of hostile type). To be explicit, the changes would apply to Charm Person (spwi104) and maybe Charm Person or Animal (sppr204) but not to Dire Charm (spwi316), Domination (spwi506) and Mental Domination (sppr405). However, Charm Person or Animal has double the duration of Charm Person and no save bonus, so balance considerations enter the picture when considering whether it should be hostile or neutral. From a gameplay perspective, it would be nice to use divine casters to unlock said dialogue instead of requiring mages. note(s): - in vanilla EE the two spells have the same save bonus. 3. Given that the change is so obvious, one is rightly suspicious that changing the charm type has consequences. @subtledoctor said the following: "I still think it's worth discussing whether/how to make Charm more like a localized Friends effect, than "Domination at 1st level." I know we never found a solution that Demi liked and/or that would play nice with SCS... but I hate this spell as it exists in this engine, and I still hope to find a valid modification of it." So what are the problematic consequences of turning charm into non-hostile, or neutral, and why exactly does SCS have problems with it? Even if we go right ahead and make the changes, we should be aware of the potential pitfalls. note(s): - the ratial immunities are also implemented in a rather olf-fashioned, haphazard way. But this is just a note to self, not really part of the RFC.
  3. Actually like this idea. Sticking it in my notes and will revisit later.
  4. Sorry, save vs. breath. Taking the interpretation that blindness is a side-effect of the fire damage.
  5. By the way, the spell is called Sunscorch not Sunburst. Brain fart.
  6. Sorry replying only now, firefox seems to have a bug making posting in the forums impossible and I did not want to install chromium, or any other browser actually. To answer your question, no I have found nothing yet. The problem, if there is one with SR, is located in the patching code. I have taken up maintenance of SR for the time being, but I will only visit this bit once some other stuff is fixed.
  7. RFC: Greater Malison Currently, Greater Malison has this bit in the description: "Those under the influence of this spell make all their saving throws at a penalty of -2, and take an extra point of spell damage for each die rolled." The latter is implemented has a malus of -1 to luck, which is then counteracted by a bonus of +1 to thac0. The problem is that the luck opcode does much more than a malus to spell damage and thac0, so there are two options here: either add opcodes to counteract the other luck effects (this is bound to be iffy, because the luck opcode is weird) or simply do away with counteracting altogether and just impose the luck penalty. If the latter, the description must be changed by replacing the second part of the sentence with some blurb like being affected by bad luck or whatever (any help with this bit appreciated, as I am not a native English speaker). Subtledoctor expressed preference for the second option, and that is also my preference, so if you favor the first one state your case. A second issue with Greater Malison is that currently the spell does not bypass mr. My gut feeling tells me that it should; that is the second issue to be solved in this RFC. I also note, and as food for thought when rebalancing is revisited latter in a more extensive and systematic way, that one of the great problems with the current spell system is that save-or-else spells lose much of their usefulness in the later parts of the BG saga (roughly SoA onwards) because everyone and his dog has such low saves. So general, mid-high level spells to drop saves are welcomed.
  8. Executive decision: since, of the expressed opinions, we have 1-1, using my executive power and going for the option of only one save type. Implementation will be added to the divine level 1 fixes PR (note to self: do not git squash this one). As far as rebalancing the spell, I will revisit it latter, but for now my idea is that it is the blindness effect that needs toning down, not the damage. Damage is comparable to Magic Missile, but the latter has faster casting, can eat mirror images, magic damage type which is generally better, etc. Since the blindness duration is 1 round already, the only wiggle room there is is to give a bonus to the save, so my proposal is to make the save at +2.
  9. In the current SR implementation, Sunburst rolls two saves, a save vs. breath for half damage and a save vs. spells to avoid blindness. This is either a bug, and only a save vs. breath should be rolled, or it is not a bug and the documentation should reflect it (which it currently does not). Arguments could go either way, but I tend to favor the first option. Spells requiring two types of saves are very rare (actually, off the top of my head, I cannot remember any). The difference in functional behavior is only seen when the victim fails the save vs. breath and receives full damage, but makes the save vs. spell and is not blinded. This is bound to not happen that many times; and if it does not have a big functional impact, choosing the simplest solution makes sense. It also has the benefit of nerfing a tiny bit what is a powerful single-target damaging spell (arguably even OP, but let us leave that discussion for later). But this is hardly dispositive, so if you have a good argument for the alternate solution speak up.
  10. For the time being, I am taking up maintenance of SR. I am proceeding in a piecemeal but systematic frashion, so the first stage is applying the fixes that can be implemented by simply patching the spells that SR copies into the game folder -- this is simply due to how SR is implemented. Once that is done I will proceed to the code itself (e.g. anything that involves petrification, slowing, dispel, etc.), which will involve refactoring and making Bartimeus' job of synching SRR as easy as possible. The first PR is already uploaded. When I upload more PR's I will update the list below: Arcane spells: https://github.com/Gibberlings3/SpellRevisions/pull/41 https://github.com/Gibberlings3/SpellRevisions/pull/47 https://github.com/Gibberlings3/SpellRevisions/pull/49 https://github.com/Gibberlings3/SpellRevisions/pull/51 https://github.com/Gibberlings3/SpellRevisions/pull/53 https://github.com/Gibberlings3/SpellRevisions/pull/56 https://github.com/Gibberlings3/SpellRevisions/pull/58 https://github.com/Gibberlings3/SpellRevisions/pull/61 https://github.com/Gibberlings3/SpellRevisions/pull/63 Divine Spells: https://github.com/Gibberlings3/SpellRevisions/pull/46 https://github.com/Gibberlings3/SpellRevisions/pull/48 https://github.com/Gibberlings3/SpellRevisions/pull/50 https://github.com/Gibberlings3/SpellRevisions/pull/52 https://github.com/Gibberlings3/SpellRevisions/pull/54 https://github.com/Gibberlings3/SpellRevisions/pull/57 https://github.com/Gibberlings3/SpellRevisions/pull/59 They are for the most part an off-shoot of my earlier PR's and my mod spell_rev_rev so they have already had some testing and discussion. I will leave the PR's to stew for a time; if anyone is interested, by all means take a look and if you have any observations comment there. Do note that things get a bit technical and entangled with IE details and WeiDU and that many fixes, while technically correct, have but a small impact on a normal gameplay. Since most of the patched files are in the binary format and there is no good way to generate meaningful diffs, if people are really interested, I can even upload how these fixes are being generated -- it is just a WeiDU mod, with a few bells and whistles to partition the work in digestible chunks, correctly move files from place to place, generate some extra debugging info, etc. Any other fixes that you think should be made, holler in this thread. I stress the word "fixes"; let us leave tweaks, rebalancing, new functionality, etc. for later. Once I am satisfied with this first stage (and whatever other PR's appear; at the moment of writing this up, subtledoctor already submitted four), I will do a public release. In the meantime, if you are feeling adventurous, you can always git clone or download the latest version for a test run. There are a few fixes in which it is not clear how to proceed. For each such would-be fix I will open a new thread with an RFC. If no consensus emerges, or no one cares, I will simply make an executive decision. So if you are bothered by a petty dictator steering things with an iron fist, speak up and present an argument.
  11. @Daft Hunk Hmm, that is indeed strange as that is the version I have, the latest public release, and the one the mod targets. If you click on the code button (or do a git clone) you will get the latest version with all commits that were pushed since the latest release -- you can see their list in the commits link. The really strange thing though is the slow spell that was really borked. I would have to take a closer look to see what is going on.
  12. @Daft Hunk - spwi312 (Slow): the spell is borked, since it misses the remove spell type protection k1#haste and the immunity from Free Action. The other (minor) alterations are not being applied for some reason I do not understand. note(s): - It could happen that your sectype file differs from mine, so I *strongly* suggest you open Near Infinity, load the spell and check that the two Remove Spell Type Protections (221) have the correct parameters: the field Spell Type should read combination and k1#haste (possibly upper-cased) for the two 221 opcodes. - spwi426 (Protection from Elemental Energy): the warning just means that the version of the spell you have is already fixed, which leads me to suspect that you do not have the latest public release of SR but the latest repo snapshot where it is indeed fixed. Harmless and nothing to do. - spwi707 (Summon Death Knight): have no idea why WeiDU is complaining. The code does not even touch this spell directly. - spwi710 (Spell Sequencer): have no idea why WeiDU is complaining. The code does not even touch this spell directly, but only the auxiliary spell "spwi710d". - spwi715 (Power Word Stun): code not deleting the undocumented one-round stun as it should. Do not understand why. Attached is fixed file -- just drop it in the override folder. Or not and go with the SR version that has the undocumented one-round stun, the difference is minor. spwi312.spl spwi715.spl
  13. @Daft HunkNo, it should not happen. What this means is that you have a mod list different from mine, and those spells are not in the exact same state. It may be harmless, but it may be not, as the code may be intentionally relying on said state. Would you please attach your weidu.log and (copies of) those spells so I can take a look?
  14. I am seeing some spell icons with an ugly green-ish tint in SR. Some of these seem to be fixed in the repo, but not all (Animate Skeleton Warrior, Summon Shambling Mound and a few more). I have no idea what is wrong; at any rate, the SRR icons are just fine, so can I borrow them and install them as a patch to SR?
  15. 1. and 2. done, next on the menu 3. (delaying it because there is a further fix I want to add). And contrary to what is stated above, there are some fixes, mostly fixes to my fixes.
  16. PR merged, thanks @AL|EN Next on the menu: 1. Remove dependency on gr-lib 2. improve install instructions 3. make public release. None of this thouches the patches themselves, it is purely an internal refactoring and user-friendly improvement business.
  17. First, apologies for the user-unfriendly release, too much of a lazy bastard (without a suit) to make a git public one. Second, thanks to Bartimeus for his explanation and correct analysis. Will improve things as soon as possible, as currently I'm having some problems on my machine preventing me taking a closer look at this. P.S.: and sure @AL|EN, will gladly accept PR's subject to the caveat above, that is, may take a bit to look at it.
  18. The install of EET_end does not fail, but it spits this at the end: chmod: cannot access './EET/bin/unix/weidu': No such file or directory /bin/sh: line 1: ./eet/bin/unix/weidu: No such file or directory This is on linux. The error is that the weidu executable is located in the subdir x86_64; have to alter lines 701 and 702 of EET_end.tp2 to point to the correct location (or move the weidu executable).
  19. I have used Python since the days of 2.2 and never had, or even have heard of anyone having, the problems you speak of. A Python library for modding would be so much better than WeiDU that it is not even funny. The problem is that, to even have a chance of being adopted and replace WeiDU (as opposed to being used for some one-off project or other) it would have to lure modders with 100% WeiDU compatibility (meaning it could install and uninstall WeiDU mods and WeiDU would be able to uninstall anything installed by it) and then on top offer some really, really good advantages for the non-programming savvy. It is not enough to have something that is better; it must be much better so that the effort in learning pays off. For example, I have written enough of such a library that you can write something like: for p in Path(".").glob("*.itm"): if p.is_file(): with Item.patch(p) as f: if f.type == itemtypes.longsword: f.min_strength = 10 This is, minus some details with working with in-game files that I have elided, a direct translation of the example in the READ_BYTE and PATCH_IF WeiDU tutorial. There are no offsets to remember, error checking is much stricter, you have to try *really* hard to put the item in an invalid state, etc. The syntax is sane, there are no wacky loony things like dynamic scoping to trip you up, you have actual data structures and a vast, solid library of code to reuse, etc. But is it enough? No, not really. 20 years of an established code base amounts to an awful lot of inertia.
  20. Can confirm that the mod now installs in EET. Testing it will have to wait though. Thanks for the speedy response.
  21. Per @AL|EN request, attached is a zip with the debug and the weidu.log file. Nothing jumps out to my untrained eye in the debug -- it seems to be a simple case of WeiDU not locating the (non-existent) file. debug-log.zip
  22. Currently, not installable on my setup. It barfs right at the start with: Copying and patching 1 file ... ERROR: error loading [wheels/bg1_area_list.2da] Stopping installation because of error. Stopping installation because of error. Stopping installation because of error. Stopping installation because of error. Stopping installation because of error. Stopping installation because of error. ERROR Installing [The Wheels of Prophecy], rolling back to previous state Will uninstall 1 files for [wheels/setup-wheels.tp2] component 0. Uninstalled 1 files for [wheels/setup-wheels.tp2] component 0. ERROR: Unix.Unix_error(Unix.ENOENT, "stat", "wheels/bg1_area_list.2da") Any more info needed, just ask.
  23. Also, the change 'fixed cpmvars Beregost_House08 name', seems to clobber BGQE as now I get the following error in the Worried Farmer component: ERROR locating resource for 'COPY' Resource [%Beregost_House08%.are] not found in KEY file: [./chitin.key] Stopping installation because of error. Since the error did not happened beforehand, I am assuming this is a regression in EET and not BGQE, which is why I am posting in this thread instead of the BGQE one.
  24. Currently getting a PARSE_ERROR in compat/bg1npc/include.tph in latest release. Inspecting the file, it seems to be malformed comments leaving a dangling END. Using // to comment out the whole block fixes the problem.
  25. I have 2.6.6 and have not found any problems -- testing included starting games in all campaigns, and in BG, going to Nashkel and doing a reasonable amount of stuff on the way.
×
×
  • Create New...