Jump to content

Wisp

Modders
  • Posts

    1,185
  • Joined

  • Last visited

Everything posted by Wisp

  1. Setting the value to less than 0 is the issue-free way of doing it.
  2. 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.
  3. 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.
  4. 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.
  5. Out of curiosity, what language are you using?
  6. 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.
  7. Your post makes no sense. In this context, a schema is a separate document (it does not literally have to be a separate document) that describes the structure and bounds of the first document (the config file). Schema validation is the process of ensuring the config file conforms to the specifications laid out in the schema. There is no incorrect or incomplete input, or validation would fail.
  8. You can verify user input with a schema, either to make the component uninstallable if the user input is incorrect, or by restricting which values the user can input during input time. In either case, you'd be sure installation would not fail or stall due to the input value. No, because there is no established alternative, and even if there were, it would not deprecate READLN because there would still be valid use cases.
  9. Speaking of which, these past weeks I've been working on Zeitgeist and I've always had the intention of eventually adding the ability to perform command-line stuff from the GUI. Adding it is conceptually simple, for the most part; is it something I should give a priority bump? (Up from maybe eventually, perhaps.)
  10. What? Like Mike says, that's what `revert` is for. No rewriting history at all. Revert is only for local commits, DavidW ask about "revert a set of pushed changes" so he want to remove/alter remote ones. No, it's not. `revert` is the proper way to undo a pushed commit. It creates an inverted commit that undoes the targeted commit entirely. The thing you are talking about, rewriting history, is arguably a bad way to work with pushed commits. It's fine for local stuff, knock yourself out, but once the commit is pushed, you should not rewrite it unless you have very good reason. Beyond `revert`, you "alter" a pushed commit by pushing a new commit that makes the desired changes.
  11. What? Like Mike says, that's what `revert` is for. No rewriting history at all.
  12. Something I often see you young whippersnappers trip over is the commit message. The commit message should be readable It should start with a short, one-line title: 72 characters or less. The title should summarise the commit message. Fewer characters is good because commands like `revert` add length to the title in the form: > Revert "Title of commit message" Some advocate a title of 50 characters at most. The title should be written in the imperative mood, so as to match git itself. The title should be capitalised but not end with a period. After the title, there should be a completely blank line, followed by a longer explanation wrapped around 72 characters. Obviously, if the commit is adequately explained by the title, you can leave the commit message as a single line. This style integrates with the rest of git and makes for readable messages. There are various blogs and such opining on the subject and giving it a more thorough treatment. Take this one, for instance: https://chris.beams.io/posts/git-commit/ TL;DR: short title, blank line, longer explanation, omit the last two if desired.
  13. Classic BG2, Polish, Patch 2.5.0.2 It is caused by wiedu 24600, if I use 24200 (shipped with mod), everything is fine. According to your debug file, you were using 245, not 246. The error you experienced was fixed in 246.
  14. Version 7 of Item Randomiser has been released. This is not the fabled version 7, legends of which has been passed down to us by our forebears, which promised to fulfil all those requested features. It's simply the latest dev version with no further changes, released so as to update the painfully old version that could still be downloaded from G3.
  15. Item Randomiser is compatible with all mods that move or remove items provided it is installed after those mods.
  16. Just to be incredibly contrarian about this, Zeitgeist will support INI over my dead body*. It's not a suitable format for abstracted editing, for lack of a better term (that is, parsing it, presenting it with abstracted controls, say GUI widgets, allowing the user to change values within predefined bounds and doing something useful with the results); JSON's where it's at (the offshoots are less widely supported and are thus less qualified). Hell, even XML is better. The only way INI works if it's like today, where the user essentially opens text files in editors and change values at ver own risk. I'm not the dictator here; people can use whatever they like and build whatever ecosystems they like, but don't expect me to not be difficult about it. *My being alive or dead is probably not relevant; INI would be unsupportable, regardless. On the wider point of why metadata shouldn't be stored in the TP2, it's because having to run WeiDU every time you wanted to get to the information is terrible and unreasonable (and having to implement a TP2 parser in your program would be ridiculous) and WeiDU has not use for it, itself. Aside from having to have WeiDU available, in the right version, there are the considerations of needing to run a, possibly non-blocking, inferior process interactively, or at the least needing to run an inferior process and then having to read from whatever file to which you directed the process' output. Having the information in a widely supported standard format is the way to go; with a little luck, whatever tool/language you are using has native support for the format, and away you go. The unfortunate downside is that if you want per-component metadata, you have to duplicate and maintain the component structure in a second file.
  17. Next one (you could pull and INCLUDE the function definitions today, but you'd do well to remember to take them back out when they'd no longer be necessary).
  18. I've added an option for controlling where the output ends up:out_path, defaults to %tra_path% If %out_path% is different from %tra_path%, no TRA files in %tra_path% are changed and no marker files or other new files are created If converted TRA files are arranged in a directory structure in %tra_path%, a mirrored structure is created in %out_path% Created files in %out_path% are uninstalled, but any new directory structures that may be created during install remain (because uninstalls do not reverse-create directories) If you use %out_path%, HANDLE_CHARSETS is obviously no longer transparent, so any references to TRA files you may have in your TP2 need to take this into account, say by LOAD_TRAing ~%tra_folder%/%LANGUAGE%/%etc%~, where %tra_folder% effectively is %tra_path% on non-EE games and %out_path% on EE games. Similarly for USING, etc. The conventional way of using HANDLE_CHARSETS seems to be to do a mass conversion in the ALWAYS block. In legacy mode, the function uses marker files to make sure conversions happen exactly once, but with %out_path%, there is no non-tenuous analogue (the presence of files in %out_path% does not, to my mind, imply the redundancy of conversion), so suggestion is that the mod author will have to handle it verself, or the ALWAYS HANDLE_CHARSETS will be run for every component (which is probably undesirable).
  19. Yes, I'm afraid 6.8 (which is the version you find on the front page) is technically old, and not technically compatible with BG:EE, even. The latest quote version unquote is found here.
  20. So it was an old, already fixed bug, at that. I would expect the macro to sort just as well.
  21. If anyone's still interested, the thing with DS and EE 2.5 was that the DS code would add and delete effects in the same loop, but would not necessarily do so in the correct order, so which would produce incorrect results for some inputs (for example, it deletes an effect located last; delta is -1, then adds an effect at position 0, i.e., at fx_off + delta * fx_size, or 0x30 bytes before fx_off). EE 2.5 contains or contained files that would trigger this oversight. I posted a simple fix here and in the DS thread at SHS, but apparently I toil in obscurity.
  22. WeiDU v245 "Medieval Steel" has been released. Download for Windows Download for GNU/Linux Download for mac OS Download the source code Forum Change log Readme The directory layout in the packages has changed with the introduction of 64-bit binaries for Mac and Windows. bin/x86 has the 32-bit binaries and bin/amd64 has the 64-bit ones.
  23. If the IDS type is guaranteed to already exist, you can retrieve the value like how Argent77 posted. You need to bit-shift the value if you get it from ADD_AREA_TYPE, which you do if you are adding the type for the first time or if you are uncertain whether the type already exists or not. Presumably the variable BG1AREA was improperly set in the code you posted (e.g., because ADD_AREA_TYPE was never called to set it). You'd get the behaviour you describe if the variable was 0.
  24. WeiDU v243 "243 is not a prime number" has been released. Download for Windows Download for GNU/Linux Download for mac OS (pending compiler) Download the source code Forum Change log Readme
×
×
  • Create New...