argent77

WeiDU v247 has several compatibility issues. Afaik, only a small number of mods is affected by it. However, replacing all WeiDU installers by earlier versions doesn't work either because some mods make use of features introduced by the latest WeiDU version.

That error appears to be triggered only if you use WeiDU v247 to install the mod. Try installing the mod with WeiDU v246 (the version included in the mod archive).

Strrefs are more than just the strings. They also include associated sounds and flags that describe how these strings are displayed. Moreover, some languages contain separate female strings. Using string references is the most accurate way to reproduce the content of a dialog structure. To adjust BG1 dialogs for EET you simply have to add 200000 to their strref values (provided all string references are available in vanilla BG1 or SoD).

It's mentioned in the IESDP (if you know what you're looking for).

SetGlobal() and SG() are different script actions. Only actions listed in INSTANT.IDS are executed within dialog states by the engine. Everything else is added to the action queue and executed only when the dialog ends. SetGlobal() is listed, SG() is not.

It's certainly possible with the WeiDU commands GET_DIRECTORY_ARRAY and GET_FILE_ARRAY. Arrays can be expanded dynamically simply by assigning new values to the array. Example: // Retrieve list of subfolders GET_DIRECTORY_ARRAY ~paths~ ~%MOD_FOLDER%/mypath~ ~.+~ // Collect file entries OUTER_SET index = 0 ACTION_PHP_EACH paths AS _ => current_path BEGIN // Skip special folder names "." and ".." ACTION_IF (~%current_path%~ STRING_MATCHES_REGEXP ~.*/\.\.?~ != 0) BEGIN GET_FILE_ARRAY ~files~ ~%current_path%~ ~.+~ ACTION_PHP_EACH files AS _ => file_name BEGIN OUTE

Judging from the answer on this page it's most likely a raw OCaml error message which isn't really helpful for the modder since it references an internal implementation detail.

If you simply want to use an existing weapon animation without making any changes then it's much simpler to change the weapon item's equipped appearance to that weapon animation code.

A bit of technical information and why so few modders have tried to add more weapon animations in the past. Weapon animations (as well as shield and helmet animations) are separate sprites that are drawn on top of the avatar sprite. These overlays correspond with the individual animation sequences of the avatar sprites. For example, the character animation uses three different animation sequences for one-handed weapons (slash, backslash and thrust). The same is true for two-handed weapons which use a different set of three animation sequences. Since spears are two-handed weapons in the ga

It's a spelling error (Saphire -> Sapphire). I was able to reproduce the looping issue with the full script. After a bit of testing I could determine the culprit. The action DestroyItem() appears to block further script execution. I remember that lynx (or Avenger?) mentioned some time ago that only script actions listed in INSTANT.IDS are safe to be used in dialogs. Most other script actions block further script execution.

The code looks fine (apart from a minor typo ) and it worked fine in BG2 when I compiled it as a standalone dialog. It's possible that previously executed script actions in the dialog are somehow blocking execution of the current script actions.

A single call of EXTEND_TOP ~script.bcs~ ~mymod/scripts/nuscript.baf~ EVAL should be enough. EXTEND_[TOP|BOTTOM] automatically fetches the game script from BIFF or override (and even creates a new SCRIPT.BCS if it doesn't exist yet), compiles the .BAF and extends the game script. EVAL can be omitted if you don't need to evaluate variables in the .BAF.

The structure information was based on reverse engineered data from the EE executable. However, after some more testing it looks like several key features I mentioned in my previous post can't be used because they are still hardcoded in the engine. I have updated the animation structure description in my previous post to make it more clear. These features might become relevant again if Beamdog or modders can fix/patch the game executable to remove the hardcoded restrictions.

@Acifer Thanks to Bubb's excellent reverse engineering skills I can provide a more accurate description of the dragon animation type: Animation type "multi_new", 9-part BAM animations (slot ranges 1200..12ff): - naming scheme: [prefix][sequence].BAM - prefix: an arbitrary BAM file prefix (e.g. MDR1, MDR2, ...) - sequence: (Numbers behind WK/SC/SD/... indicate cycle numbers) - if attribute split_bams=0: <-- NOTE: This mode is currently ignored in EE games - G1[quadrant]: WK=0-8 - G2[quadrant]: SD/SC/SP=0-8, SD(unused)=9-17, SC(unused)=18-26 - G3[quadrant]: A1=0-8, A2(unu

These script actions are available to all animations in slots range 3000-3fff. This includes the new Neothelid animation in SoD. The D-type BAMs are just used as an extra layer for this animation type and rendered behind the creature sprite for the ground part. The number of frames in these BAMs don't have to be in sync with the creature sprite BAMs. They are simply played back repeatedly until the creature animation sequence has ended.