DavidW

The original issue is definitely a bug, for sure.

11 hours ago, suy said:

Becaue I very much would like to write this:

for effect in item.effects
    if effect.code == 216
        print("I drain", effect.parameter1, "levels")
    end
end

Rather than:

  GET_OFFSET_ARRAY ab_array 0x64 4 0x68 2 0 0 0x38
  PHP_EACH ab_array AS int => ab_off BEGIN
    GET_OFFSET_ARRAY2 fx_array ab_off ITM_V10_HEAD_EFFECTS
    PHP_EACH fx_array AS int => fx_off BEGIN
      READ_SHORT fx_off fx_type
      PATCH_IF fx_type = 216 BEGIN
        READ_LONG fx_off + 0x4 amount
        PATCH_PRINT "I drain %amount% level(s)"
      END
    END
  END

 

I should do this one too, I guess:

[
	m.ab_fx.alter{PATCH_IF s_opcode=216 BEGIN PATCH_PRINT ~I drain %s_parameter1% levels~ END}
]

Some belated thoughts:

1) The obvious constraint in a WEIDU replacement (for the moment setting aside the question of whether we want one) is that the existing mod ecosystem is coded in WEIDU (and, at this stage in the community's life cycle, the existing mod ecosystem is much bigger than the mods that will be created in the future). That means any WEIDU replacement will have to be able to handle an install order containing WEIDU mods, and hence must have a complete implementation of WEIDU inside it. That's a horrendously large overhead on what is already a horrendously large task. (Doubly so assuming the replacement is not to be coded in OCAML, which I assume most people wouldn't want, and so has to reimplement WEIDU and not just borrow code.)

2) What is *possibly* realistic is to have WEIDU call out to some external tool (using AT_NOW, I guess) to do file edits, rather than doing them natively. I think that's what Suy has in mind. And certainly there is lots of high-level functionality that WEIDU can't do, or can do only clunkily, using its base tools and the core function library it ships with. The question I'd ask is: what is the advantage of implementing that high-level functionality in a new language that gets called from WEIDU, rather than as functions within WEIDU itself. After all, WEIDU is a fully functional programming language. It has its disadvantages (its syntax is sometimes clunky; its variable typing is rudimentary; it doesn't allow functions as first-order values; it lacks a large library of preexisting resources) but its low-level functionality is very tightly connected to IE mods and of course using it natively avoids a lot of awkward interface issues between WEIDU and an external tool.

3) Ultimately I think the problem with a new tool that replaces WEIDU's functionality is the same as the problem with a rich function library within WEIDU: building and maintaining that resource is a huge outlay of time and no-one has been willing to put it in. My 'SFO', especially in its newer form, is the closest I'm aware of, and I think solves most of the problems that WEIDU critics raise, and one of these days I may get around to finishing documenting it and making it available to others to use, but ultimately I don't have that much free time for modding and what I have is mostly devoted to my own mods rather than maintaining community tools. I think that problem generalizes beyond me.

4) Part of people's problem with WEIDU is just unfamiliarity. This isn't a good reason to look for change. Programming concepts are largely transferrable between languages and the time taken to learn a new language is short compared to the time taken to implement a complicated project. It is true that the resources to learn WEIDU are limited (my Course in WEIDU was an attempt to address this) and that reading mods is a very imperfect way to learn it (90% of WEIDU mods use only 10% of WEIDU's capacities).

18 hours ago, suy said:

In another language it would be very similar to the following pseudocode:

spell = Spell::read(file)
for effect in spell.effects
	effect.parameter1 -= 1
end
spell.write(file)

 

In SFO it looks like this:

spl.edit[SPCL822]
[
	m.ab_fx.alter{s_parameter1 = s_parameter1 - 1}
]

I don't know a way to adjust carry weight. The rest is in principle possible but most of it requires UI edits, in some cases quite drastic ones. (I did look at the hidden IWD2 kits when writing ToF but mostly didn't find things worth the effort of implementing.)

On 3/12/2024 at 3:05 PM, CamDawg said:

There's no upside to changing the component number of a mod once it's released, only downside, and that's true regardless of whether LABELs are being used. There's no queue of modders desperately wanting to change component numbers, being held at bay only by downstream compatibility concerns.

To be fair, I have had occasional edge-case issues when I've had sequential mod components with non-increasing DESIGNATED values, and have very occasionally renumbered for that reason.

I'm not sure I like the idea that every single werewolf is able to suppress both peer pressure and their savage nature because the player helps them out.

Thanks for the bug report.

FYI: you can also avoid killing Carsa by using any other effect that confuses or immobilizes her or knocks her unconscious, though I don't know if this bug recurs for those routes too. 

'Call' for help is an abstraction: it covers creatures engaging opponents when they see that their allies have engaged. And in DnD it's never been the case that a group of skeletons only partially engage.

I think this is on NTotSC. SCS works with what it's given, which in this case is a bunch of spellcasters who are flagged at 12th level. I can adjust for this kind of thing in the core game but I draw the line at handling every mod. If NTotSC doesn't want 12th level orc mages, it should use lower level ones.

I’d be concerned that if you go too far in this direction you start changing the essentially tragic theme of the island. (I mean, you could advance that as a criticism of the Calling change too, but hopefully it gets away with it).

Still, implementation is what matters, and if someone wants to write that mod and can do it in a way that works, more power to them.

OK, updated the hotfix to address this too. Sorry about this, it's seriously annoying and I'm not really sure how it crept through.

Updated the hotfix to address a somewhat-related issue.

I see the problem, yes. Chapter variables need to be localized to allow for EET: that 'Global("chapter","GLOBAL",5)' needs to be 'Global("chapter","GLOBAL",%bg2_chapter_5%)'. The same thing occurs in a few places in stratagems/tactical_bg2/ssl/dw#random.ssl. Fixed locally, will be in 35.11. You can hotfix by dropping the attached file into stratagems/tactical_bg2/ssl before installing (no need if you're not playing EET).

dw#random.ssl

Provisions are intentionally disabled, but if inn buffs don’t work that’s a bug (a weird one, can’t guess where that comes from) and probably the provision display should be turned off entirely.

It doesn’t have the same issue! But it looks as if there’s another issue too… will check.

Found it. (I have no recollection how this happened, and the files are from 2018.)

Hotfix: before installing Smarter Mages, go to stratagems/mage/iwd/top and delete the files 'uddrow1.baf' and ''uddrwswd.baf'.

This must be a relic of some test code that snuck into the live mod. Let me see if I can find it.

I haven’t yet (though to be fair I haven’t had much chance to look). What party slot was he in?

(2) is hotfixed here.

The startscreen critical bug is hotfixed here. (The LeUI gender issue will have to wait a bit.)

.

A critical bug in beta 8 slipped through just before I finalized it, sorry.

I'm currently travelling and can't straightforwardly upload a new version. For the moment here's a hotfix, that works before or after installing.

BEFORE INSTALLING: drop the attached files 'ui_system_call.tph' and 'ui_externalize_hlas.tph' into the dw_talents/sfo/lua folder, and the file 'systemcall.ini' into the dw_talents/sfo/lua/data folder.

AFTER INSTALLING: drop the attached files 'm_dw_osd.lua' and 'm_dw_osf.lua' into the override folder. If you have installed the 'low level abilities' or 'revised high-level abilities' components, also drop 'm_dw_hlf.lua' into the override folder.

m_dw_osf.lua

ui_system_call.tph

ui_externalize_hlas.tph systemcall.ini m_dw_osd.lua m_dw_hlf.lua

In general amalgamate_class_checks is doing some fairly sophisticated substitution, not just a regexp replace - it has to substitute into OR() and ! contexts and preserve logical structure. Looks like it's not doing so perfectly.

OK, this is helpful, and clearly related to the IWD startscreen issues identified elsewhere - some late change must have slipped through. Will investigate.

To be clear, I'm not interested in giving all NPCs kits. Priests are a bit of a special case.