Jump to content

Wisp

Modders
  • Content Count

    1,162
  • Joined

  • Last visited

About Wisp

Profile Information

  • Gender
    Male

Recent Profile Visitors

42,722 profile views
  1. Largely because it's not a structurally important detail. A null value does not cause the game to crash and does not cause patches to fail or to corrupt the file. However, if you think 0x2020 is a better no-value value, I can certainly change it; it's the same deal with strrefs: -1 is a better no-value value than 0.
  2. WeiDU is printing this warning because "target" evaluates to something other than its own string literal (the variable is set in the same scope from which you are calling the function). There are no facilities for not having this warning under these circumstances, short of turning off the MODDER option. If "target" does not need to be set in the scope of the function, you can try to isolate it with another function or WITH_SCOPE.
  3. Ok. If you wish to continue troubleshooting, perhaps the WeiDU forum would be a more appropriate venue, or maybe whichever forum Beamdog uses for bug reports? From what I can gather, this does not seem to be an issue with Item Randomiser, but it's curious nonetheless.
  4. Could you run something like the following from your game directory: mkdir tmp && weidu --change-log ar1202.bcs --out tmp > tmp/log and zip and upload the tmp directory? The error is being issued by WeiDU's decompiler, so it's within the realm of possibilities that one of your other mods has done something bad, or that WeiDU has done so.
  5. 1. Looks like a copy-paste error. The doc was presumably adapted from ADD_ITEM_EFFECT. As it's unused, it's safe to remove (and I've done so). 3. Yes, TP2 integers are signed 32-bit. It was not a good choice for every conceivable situation. 4. SET and [ SET ] are not strictly equivalent. SET takes a syntactic type that allows EVAL and the array construct on the left-hand side, whereas [ SET ] only allows plain strings in the same position. As Mike said, an inlined file is the same thing but is entirely memory-resident and does not leave anything on the file system. Using REINCLUDE on an inlined file is the closet you get to invoking eval on a string in TP2, assuming that's what you want to do.
  6. No, AUTO_EVAL_STRINGS is fine in this case. Sorry, I should have checked. (If you ever find yourself in a situation where you'd need two EVALs, AUTO_EVAL_STRINGS only counts for one of them.)
  7. Questpack's General AI improvements do not touch Kruin. The component compiles a few scripts, EXTEND_TOPs a few more and patches a few spells. But if you install SCS on top, you are probably not going to see much benefit from QP's component (so it's not like you are missing out by removing it). What I'm guessing is the cause of this is this code from sfo/filetype/lib_cre.tpa PATCH_IF VARIABLE_IS_SET ~%spellname%_LEVEL~ BEGIN SET ~spell_level~= ~%%spellname%_LEVEL%~ When you want to evaluate a double variable like that, you need an extra EVAL, I'm afraid. Also, a small note: if you can be sure the variable is, or need the variable to be, an integer, it is safer to use IS_AN_INT instead. It will not return true if the variable is set but is not an integer, the way VARIABLE_IS_SET will. Also, also, another small note: you can give spell level to ADD_MEMORIZED_SPELL as a variable with the kind-of undocumented form: (variable). The form is documented under values, there's just nothing to indicate that it's valid in place of the #number notation.
  8. Are you sure you posted the crashing version of the file? I can't see anything wrong with it [1] and it loads fine into my game. 1. Well, if I look while paying better attention: his items and inventory is all messed up, with many garbage items and the item assignment all wrong. I was just looking for structural defects, so I missed this the first time.
  9. @AL|EN In that case, I don't understand. You want to propose a second new packaging convention, only this one retains platform-specific stuff inside the mod archive? And at that, one that does not include WeiDU in the mod archive, but instead downloads a mod-specific WeiDU at run-time? It seems nonsensical. You are still including WeiDU in the mod archive, just in a roundabout way. Or have I misunderstood? Edit: yes, I have. The WeiDU would be shared amongst mods. Perhaps also relevant is that the interactive-installer parts that setup-mymod.exe and equivalent solutions rely on are slated to be removed (when this happens is, of course, a fun guessing game).
  10. @AL|ENThat's not what desktop entries are for. To associate a file type with a program, you edit one of the mimeapps.list files, or use the desktop file to announce which types the program supports. The desktop file is for the program, not the mod archive.
  11. Can you describe your testing method? When I assign lowercase portraits to Imoen, they show up properly in the dialogue window, sidebar and record screen (BGEE 2.5.17, picking her up after the cutscene with Gorion). They are also in lowercase in the GAM file. Worth noting is perhaps that NI will always show the resrefs in uppercase, even though they are not in uppercase on disk.
  12. I'm okay if people prefer to continue distributing mods as they do now. Hopefully a unified distribution format and graphical front-end for installation has enough merit to stand on their own. But a mod mananger is a de facto requirement for Skyrim, for example, and it does not seem to be any source of unrest.
  13. Worldmap, link entries: IESDP. I can't remember how the probability works. There is the SetEncounterProbability() script action, too.
  14. Sure. It's not particularly viable for the EEs, anyway. OT, but I can't reproduce this. Lowercase portrait resrefs seem to work fine.
  15. A regexp in balthazar_compatibility.tpa is incorrect. swap_out=~IsValidForPartyDialog?u?e("Edwin")~ (? is a postfix construct.)
×
×
  • Create New...