Jump to content

Wisp

Modders
  • Content Count

    1,142
  • Joined

  • Last visited

About Wisp

Profile Information

  • Gender
    Male

Recent Profile Visitors

42,608 profile views
  1. Wisp

    New to weidu

    How far along in your learning are you? I wrote a quick introduction for getting started with WeiDU: the files and folders you'll need, the basic structure of a TP2 file, posted here. If you have yet to get this far, I'd say it's still a worthwhile read. As for using functions, for a patch function, you would open a buffer, typically with COPY_EXISTING and invoke the function. Function documentation can be found in the WeiDU readme (functions are under the macro listing). The IESDP is also a good resource for documentation of the file structures. This code changes the Wand of Fire into having 1 recharging charge: COPY_EXISTING wand05.itm override LPF ALTER_ITEM_HEADER INT_VAR header_type = 3 charges = 1 drained = 3 END BUT_ONLY As the name implies, the function ALTER_ITEM_HEADER changes values in an item header, which is where charge behaviour is located. Other functions can be used to do other things. The function selects all headers of type 3 and changes the charge field to have the value 1 and the field for charge-depletion behaviour to have the value 3, which is daily recharge (see the IESDP). BUT_ONLY applies to the COPY_EXISTING action and means that the file will only be copied if the applied patches change the contents of the file. It's good practice to have it on all your COPY_EXISTINGs. Updating charges in areas, creatures and stores is similar, but off-hand I can't recall if there are ready-made functions for all of it. It also involves finding the areas, etc, that hold references to the item. Updating the item description is most easily done by writing a new one and using the SAY patch to write it to the item and add it to the game. This is left as an exercise for the reader. I hope that helps and feel free to ask questions.
  2. Wisp

    Version 7 released

    That depends on what you mean by proficiency. Item Randomiser still relies on the BG1-style proficiencies and does not add any BG2-style proficiencies. As far as I could tell, there was no need, as the BG1 ones worked just fine. But I understand that some mods have started patching away BG1 proficiencies and I don't think I've yet updated Randomiser to take that into account.
  3. Wisp

    Question for pure re-installation

    When you start the BG2 portion of your game, it is effectively the same as starting a new game, as far as IR is concerned. You should not encounter any issues at all, not even on account of your slightly different mod setup. You are correct that spawning creatures would not work. The best way to test would be to use to console to take you to one or more areas where you'd find random items. Happy gaming.
  4. Wisp

    Version 7 released

    Do you recall if Hindo's Doom was one of the items you picked up from Abazigal? If so, it wasn't being equipped for some reason, but at least he got a weapon into his inventory.
  5. Wisp

    Question for pure re-installation

    When you say "pure" I imagine you were not prompted by Item Randomiser for whether you wanted the mod reinstalled with save compatibility or not (because the files that would make IR issue such a prompt would not be present in your game). It might still be fine, however, as Mode 1 is light on install-time randomness and stores most or all of its state in your save. If you installed the same mods, none of them were random in a way that would affect IR and installed the same options for IR, the probability of things being fine increases. I'd suggest you continue playing for as long as you don't notice anything amiss. Mode 1 randomises everything [1] at the start of the respective game (Candlekeep, Irenicus' dungeon, ToB starting area). It then uses a system of if variable such and such has this particular value, put the corresponding item in the area you are in, with the area you are in corresponding to the value of the variable. As such, if game state is the same before and after reinstallation, things would continue to work. However, if game state is mismatched, there is likelihood of problems. Your saved game notably stores areas you've already visited in the state they had when you visited them (plus whatever changes your made to them in-game), and if you visited them before reinstallation and their state were different after reinstallation, that state-change would not be reflected in you game. For your question 1, no, items would continue to be randomised, for 2, this is the likeliest kind of issues, if there are issues, and, 3, uninstalling is not without its share of problems either, as randomised items would be missing from areas you've already been to, but would never be found, as they would not be present in the area inside your saved game, because that's one kind of those state changes. 1. Not everything everything. BG1 items in Candlekeep, BG2 items next, etc.
  6. Wisp

    Version 7 released

    Oh, upload the file randomiser.debug as you normally would.
  7. Wisp

    Version 7 released

    I forgot: can you also upload the debug file?
  8. Wisp

    Version 7 released

    I'm glad you had a good time. If you still have the files and have not made any changes to your mods, could you upload the files weidu.log, override/fl#randomseed.2da, override/fl#removeditems.2da and override/randoptions.2da? There's a system for ensuring Abazigal gets a random weapon and he seems to be getting no less than 2 when I test. Possibly some other mod is causing interference.
  9. You need to exclude the legacy files from version control. Tags (and github releases are tags) you create include all tracked files; they are essentially a snapshot of the project. Alternatively, do like Mike suggested and do not mind having the legacy files present in the tag, but exclude them when you create the archive you intend to distribute.
  10. Wisp

    Issues with ADD_ITEM_EFFECT

    Setting the value to less than 0 is the issue-free way of doing it.
  11. I can't reproduce untickable tickboxes, but I did run across a glitch with the radio buttons (affecting Windows only; the joys of cross-platform code). If you remember any more or any other issues, please feel free to report it in the WeiDU forum or on github.
  12. Hey, I have to take issue with that. Zeitgeist is not properly released, but it is today (or indeed, as of years ago) no less useful for (un)installing mods than WeiDU on the command line. It is less a matter of Zeitgeist being unfinished (it is, but that is beside the point) and much more a matter of mods being adapted for interactive installs and more or less unsuited for non-interactive installs, regardless of how they are done (Zeitgeist, command line or otherwise). Supporting all the same mods as WeiDU itself is a given and that includes mods that use READLN. However, if you install mods non-interactively, I'd say it becomes clear that READLN is out of place, in a way that it isn't when the process is interactive. I hope READLN will eventually fall out of style, but it will remain supported.
  13. It's a pragmatic suggestion for WeiDU as it is used today. The main problems I see is that it's another interactive feature that depends on the shell menus. I want to work towards a future where the shell menus can be axed. However, good should not be the enemy of perfect, but that brings us to the second point: READLN today is very accessible. If you can install mods interactively, you can give READLN a value. Editing config files manually is another matter altogether, and something I think a lot of users could find intimidating or bothersome. As lynx has pointed out, there is also the problem of input validation. I'll gladly discuss the subject, but my preferred solution is this TP3 thing, in which config could be just another subsection, right beside, say, the component list. It would solve or side-step problems like what to call the config file, where it would be located, how you could be sure it really was config options intended for the user (as opposed to, say, internal knobs for the modder to tweak) and how to make the options available to programs other than WeiDU. Not writing the user's altered values to the TP3 itself could be solved by writing the config memory object to disk at another location (say, $GAME/weidu/config/$MOD), which would give us a standard directory for "mod state", such as backup files, debug files and other things. More on this flight of fancy will be forthcoming; I just haven't had the time to do a proper write-up.
  14. Out of curiosity, what language are you using?
  15. As for the broader issue, I don't think it needs to be forced. If and when the player base transitions away from the mindset of interactively baby-sitting each mod as it installs, pressure will mount on modders to make the experience smoother than what READLN can offer.
×