Jump to content

Wisp

Modders
  • Posts

    1,185
  • Joined

  • Last visited

About Wisp

Profile Information

  • Gender
    Male

Recent Profile Visitors

43,552 profile views

Wisp's Achievements

  1. WeiDU 249 "Master Doom" has been released. Downloads Changes Readme Forum
  2. WeiDU 248 "Enhammered" has been released. Downloads Changes Readme Forum Builds for macOS will probably eventually be available. Mac build is up, with thanks to AL|EN.
  3. So this is a about hash-table lookups. WeiDU does not normalise case when interring or looking up symbols, so it can store different case-variations of the same filename as they were different files. The "file" loaded by the EXTERN is written to disk after the file loaded by the main ALTER_TRANS action, but since it was loaded before ALTER_TRANS made any changes, it ends up overwriting the changes to the first file.
  4. So where (game? version?) would I need to run this code in order to reproduce the problem?
  5. For information: the problem is Randomiser cannot make sense of the weapon proficiencies of the recipient creature (which may be random, such as someone in Drakar's party). It's probably some compatibility code that needs a kick. I made accommodations for Tweak Pack back before it was Tweaks Anthology, but compatibility has probably slipped.
  6. Possibly for posterity: you generally cannot install Randomiser without starting a new game, as area files and such are stored in your saved game. If you know what you are doing, you could probably get away with installing the mod just as you transition into ToB, as ToB is generally a separate game, but there's Watcher's Keep to look out for and if you've already been there before starting ToB, you'll experience problems. As a rule I would advise against installing the mod without starting a new SoA game.
  7. The ICT line of actions do support IF_FILE_EXISTS, but it's not really documented. The error likely means that WeiDU tried to take the first element of an empty list and it's essentially a WeiDU bug that you are getting it, since it's completely unhelpful. However, I'm not able to reproduce the problem. The code in the first post compiles without errors. If it's a better error message that is needed, I can likely take care of that without a test case, but if the error shouldn't be happening, I am going to need some code sample with which I can reproduce the problem.
  8. It's been a while, but version 247 "Return of the Warlock" has now been released. Downloads Changes Readme Forum Unfortunately, the person who has been providing binaries for macOS is no longer able to do so. Unless someone else steps up to fill the void, I have no WeiDU for our macOS users. The build instructions for macOS should still be applicable, with the caveat that WeiDU cannot be built with OCaml distributions that force immutable strings (so-called "safe strings"). I don't know if this is a version thing (likely) or an option when building OCaml, but versions around 4.07 and 4.08 have worked for me. Edit: A Mac build has been posted. Many thanks to everyone who submitted builds!
  9. I have a note in the code that it needs to be updated to account for IWD-style weapon proficiencies (from cdtweaks); do you happen to have that component installed? Or one of the other components that alter the proficiency system? I don't know if IWD-style proficiencies, or one of the other ones, would cause an installation failure. What is happening is that the mod reads proficiencies off the creature, and then encounters a weapon that uses numbers not found on the creature, or some other kind of mismatch between read values and assumptions made. A complete .debug file from one of these failed installation attempts would be helpful.
  10. On the DS/QP issue: I'll look into it, but I'm moderately certain this is a DS issue, rather than a QP issue, meaning you'll probably get it with all mods that use the relevant DS code (the DS included in QP is not modified from "main-line" in this regard). If so, you are probably getting it with QP because QP is the first DS-using mod in your stack. Maybe. As I said, I'll have a look.
  11. @AL|ENCan you elaborate on this feature request? Maybe I'm skimming through this thread too quickly, but I'm not seeing much in the way of descriptions.
  12. @AL|EN Can you expand a bit on observed behaviour versus expected? The CLEAR code stores the current values for MOD_FOLDER et al., and uses these values when restoring the variables. Since the variables are mutable, it is possible the value could remain different from what it first was, even after CLEAR has run.
  13. 2. That and TIZ stuff. IEMOD is platform-agnostic, but it seems unnecessary to demand the contents are, as well. Especially since it means legacy mods could not be repackaged without being re-coded. Archives - right, it is of no particular concern if the IEMOD contains any, and it's unlikely enough that it would. 4. Anyway, I've updated the spec with some technical details, notably I think we need to specify that the contents should be in UTF-8, or extra-ASCII characters won't translate across locales. Seems less restrictive than requiring everything to be in ASCII. Diff.
  14. First draft: https://github.com/WeiDUorg/zeitgeist/blob/master/iemod_spec Some issues remain: 1. A tighter specification of the ZIP format and allowed/disallowed features. I need to do some boning up. 2. I can see legitimate reasons for why a mod might want to include archive files in the mod package, and I really don't think we are at a point where we can safely exclude .bat files from mod packages, so table may-exclude may be trimmed a bit. 3. Possibly some mention of files/directories that differ only in case, or maybe ZIP already has that covered.
  15. It's the same as the last problem. Your REPLACE_TEXTUALLY ~%textToReplace%~ ~\1 !Dead("Sarevok")~ should presumably be REPLACE_TEXTUALLY ~\(%textToReplace%\)~ ~\1 !Dead("Sarevok")~ The back-reference (\1) is a reference to a matched group and as your code is currently written, there is no grouping (for which you use \(foo\). Also it's not necessary to have a newline before Sarevok's trigger: it will be discarded when your DECOMPILE_AND_PATCH closes and the script is compiled. (I think it helps readability to have it on the same line in cases like this.)
×
×
  • Create New...