Functional WEIDU

[Galactygon]

At some point I have written a set of macros (they work just as fine as functions) that can dynamically search for, copy, change, or add effects to extended headers (.spl, .itm). However they significantly slow down the install.

 

The problem with the different types of ADD_something functions is (was?) that they give you no control on where the new effect will appear in the effects list. This can be crucial in places where you have different combinations of 177s, 101s, and 206s with durations of 0 in the beginning of the effects list. That's why I've resorted to changing them to fit my style.

 

I'm willing to offer them for some sort of greater good.

 

-Galactygon

[Wisp]

The problem with the different types of ADD_something functions is (was?) that they give you no control on where the new effect will appear in the effects list. This can be crucial in places where you have different combinations of 177s, 101s, and 206s with durations of 0 in the beginning of the effects list.

Since some time back, ADD_SPELL_EFFECT and ADD_ITEM_EFFECT take a variable called insert_point that specifies that the effect should be inserted as the last or nth effect (also last if n is greater than the existing number of effects).

[Miloch]

I am interested in the concept behind this but have withheld commentary thus far due to my hitherto discussed lean development philosophy. On one hand, I think it makes sense to alias a bunch of arcane WRITE_BYTE/SHORT/LONG "pokes" (to use an ancient software development term) to more sensible references such as STR=18 and so on. On the other hand, I would be leery of bloating the existing codebase or slowing down install time significantly, since in essence, the developer can do one as well as the other - if it is the player (installer) who suffers, then we should mitigate that and make things as easy as possible for the player even if we developers have to suffer a code inconvenience or two (and really, WeiDU coding is not that difficult when it comes down to it). Nevertheless, I would be interested to see how this pans out, DavidW. There is no question in my mind that even code-heavy functions (such as Nythrun's fj_are_structure) have vastly improved modder performance without bogging down WeiDU/installer performance.

[DavidW]

My impression is that there is some slowdown, but not a serious amount. It takes about ten seconds for WEIDU to load the function library, which is a bit of a nuisance for testing but fairly irrelevant for end users. My experience with SCS is that install time is massively dominated by a small number of large tasks, mostly compiling scripts and doing complicated COPY_EXISTING_REGEXPs, and so I tend to keep a fairly careful eye on how long those take, and be fairly casual with the rest.

 

The comparison with functions like Nythrun's is instructive. In some ways the idea of the framework I've set up is to make it easier to write functions, just as the functions make it easier to write first-order code. If I want to, say, put together a function that clones any actor in an ARE file that has the WTASIGHT script, I can write it in about a minute.

 

I don't entirely agree with the line you're taking here (we've discussed this before). I'm actually quite blase about doing things that make my life easier even if they make things less optimal for players - after all, I'm not getting paid to do this. But I think the main end-user advantages of heavily automated coding are:

 

(i) content can be produced much more quickly. If you assume that a coder has a finite amount of time available to mod, then the less time something takes, the more content can be produced. I've certainly noticed that I'm much more casual now about making little changes to improve smoothness or immersion, when doing so just requires a couple of lines rather than a massive block of PHP_EACH and READ_LONG.

 

(ii) it's easier to catch mistakes. Typical first-order WEIDU code is a mass of hex offsets and WRITE_SHORTS. If you get an offset wrong, or WRITE_ASCII rather than ASCIIE, or COPY_EXISTING ~oldscript.bcs~ ~newscript.bcs~ rather than ~oldscript.bcs~ ~override/newscript.bcs~, or READ_LONG rather than READing_SHORT, very often the code will still run but there'll be a subtle mistake. Abstracting out the structure makes that kind of thing much less likely to happen. Code I write in this system generally takes longer to get working in the first place, but has fewer problems once it works. (Of course, it's possible to make mistakes in coding the function structure in the first place- the alpha I uploaded a couple of weeks ago is far from bug-free - but errors there are likely to show up relatively quickly and, once fixed, are fixed for good.)

 

(iii) the code is a lot more readable, which makes it easier to maintain, update, and come back to some while later. Something like

COPY_EXISTING ~firkra01.cre~ ~override~
 WRITE_BYTE 0x273 255
 WRITE_BYTE 0x234 24
 WRITE_BYTE 0x235 24
 WRITE_BYTE 0x236 24
 WRITE_BYTE 0x59 100
 WRITE_BYTE 0x5a 0
 WRITE_BYTE 0x27b 35
 WRITE_BYTE 0x273 17
 ADD_MEMORIZED_SPELL SPPR314 #2 ~priest~ (3)
 ADD_MEMORIZED_SPELL SPWI112 #0 ~wizard~ (5)
 READ_ASCII 0x248 script1
 READ_ASCII 0x250 script2
 WRITE_ASCIIE 0x250 ~%script1%~
 WRITE_ASCIIE 0x258 ~%script2%~
 WRITE_ASCII 0x248 ~dw#firkr~

is relatively opaque six months hence;

MAKE_PATCH
  allegiance=>enemy
  level_all=>24
  resist_fire=>100
  resist_cold=>0
  class=>FIGHTER_MAGE_CLERIC
  alignment=>NEUTRAL_EVIL
  add_spells=>~HOLY_SMITE(3) MAGIC_MISSILE(5)~
  insert_script_high=>dw#firkr  
END
LAF edit_creature STR_VAR creature=firkra02 END

is pretty much self-documenting. (And - coming back to (ii) - if I misremember resist_cold as cold_resistance, the code just won't run. If I misremember 0x5a as 0x6a, it'll run, but not behave as desired, which is much worse.)

 

My view is that a slightly longer install time is a price worth paying for those advantages. (Of course, it depends very much what kind of mod you're writing.)

[lynx]

I also find this install time prolongation as an odd counter. The game itself takes several minutes to install, so why wouldn't players have that tiny bit more patience? On top of that hardware is still getting faster, plus there is likely room for optimisation.

[Jarno Mikkola]

I also find this install time prolongation as an odd counter. The game itself takes several minutes to install, so why wouldn't players have that tiny bit more patience? On top of that hardware is still getting faster, plus there is likely room for optimisation.

Well, there's people that install the mods several times... the ones playing the Weidu game, for particular reasons... not the BG2.

 

But indeed in my opinion on the matter is, that one should first go and make a functional mod... and then worry about the optimizing later.

[DavidW]

I also find this install time prolongation as an odd counter. The game itself takes several minutes to install, so why wouldn't players have that tiny bit more patience? On top of that hardware is still getting faster, plus there is likely room for optimisation.

 

The main annoyance I find with install times in SCS is that WEIDU doesn't let you select your options in advance, so you have to wait around for each component to install before choosing the next one. The next version of SCS should have a workaround for that, though.

[Jarno Mikkola]

The main annoyance I find with install times in SCS is that WEIDU doesn't let you select your options in advance, so you have to wait around for each component to install before choosing the next one. The next version of SCS should have a workaround for that, though.

Is that to say you lessen the component numbers and add in more inserted line readings... and "complex functions" that use all the choices on one go ? As you only need to use these with the usual functions:

ACTION_READLN function
END

ACTION_IF (%function% = 1) THEN BEGIN
....

[DavidW]

No, that's a pain for uninstall purposes. In v22 of SCS, pretty much any component has the form

 

BEGIN @xyz DESIGNATED abc GROUP @blah 
REQUIRE_PREDICATE [whatever]

OUTER_SPRINT component_loc
LAF run STR_VAR file=my_component version=my_version END

 

Normally the "run" function INCLUDES and runs a function which contains the guts of the component. But by changing the definition of that function, the same tp2 file can instead be used to build a list of required components that then get installed all at once.

[lynx]

A short Expect script could be used as an alternative. The whole (sub)language was designed for cases like this, testing interactive apps.

[DavidW]

That went over my head. Can you say more?

[Adanedhel]

This looks really interesting for a profane modder like me. As someone mentionned before it's all really arcane, if these functions allow me to modify anything without learning offsets, the difference between a LONG and a SHORT, etc... then yay!

[Ardanis]

Somebody invite Baronius, his dream of better-than-WeiDU tool is coming to life.

[Adanedhel]

I also want to add about installation length concern that they shouldn't really matter (at least to me). If someone wants to install a mod, they just do it, they won't stop in the middle of it because it's taking too long. Few examples of long installs on my 2005-old computer :

 

- Installing BG1+ToTSC+patch+BG2+ToB+Patch = ~20 minutes

- Installing BGT without biffing = up to ~45 minutes

- Installing SCS(1&2) with most components and AI enhancements = up to 1 hour

- Installing a medium-sized BWP game = up to 24 hours

 

So I don't think I will mind a couple more minutes loading functions.

[DavidW]

Somebody invite Baronius, his dream of better-than-WeiDU tool is coming to life.

 

Well, I vaguely recall saying in that conversation that most of what Baronius wanted was achievable via WEIDU functions. What was daft about Baronius's idea wasn't the general concept, it was his casualness about breaking away from WEIDU altogether.