Jump to content

Wisp

Modders
  • Posts

    1,185
  • Joined

  • Last visited

Posts posted by Wisp

  1. I'm really happy to stand corrected - but last time I tried Zeitgeist it looked as if it wasn't in official-release mode - there were some quite serious graphical glitches. (I couldn't get it to untick tickboxes, in particular.)

    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.
  2. (or indeed Wisp) release a non-interactive GUI install tool

    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.
  3. Let throw out an idea, and see if this is viable to the parties involved here. Imagine something like CONFIG as a tp2 flag, a la README:

     

    CONFIG activefile [templatefile]

     

    WeiDU would prompt if you wish to view (and or modify) the file, like README. It would give the modder the flexibility to name the file as they wish (and makes no imposition upon the file's actual format, content, or naming convention) and gives an easy flag for external installation tools to key off. Tweaks currently ships with cdtweaks.disabled.txt that, when renamed as cdtweaks.txt, becomes a config file. So Tweaks could use

     

    CONFIG ~cdtweaks/cdtweaks.txt~ ~cdtweaks/cdtweaks.disabled.txt~

     

    Where the first argument is the active config file, and the second (optional) one is a template file. If the active file is present, it's simply presented; if it's not then the template is copied to the active filename and then presented. The file itself would not be loaded or processed; that would remain for the mod itself.

    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.

  4. 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.

  5. Really ? So how would the install behave if the input would be restricted to a number, and it was given a letter ? It would STALL, right there and then, as it would require an additional input that is not provided. Or at least that's how the schema usually works:

    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.

  6. 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.

     

     

     


    @wisp, can you mark READLN as "DEPRECATED" and display warring?

    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.

  7. edit: Or, duh, the even easier option from the command line: weidu foo.dlg will output foo.d in your game folder.

    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.)
  8.  

     

    As long as you didn't push you local repo, you can pretty much do almost everything "after the last remote commit". But when you pushed it, that's tricky one. You want to revert data which was already send to remote repository. In git terms, such operation is called "rewriting history". Because git history is atomic, you can't delete data without reverting all git history. This include even changing commit messages (for security reasons).

    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.

  9. As long as you didn't push you local repo, you can pretty much do almost everything "after the last remote commit". But when you pushed it, that's tricky one. You want to revert data which was already send to remote repository. In git terms, such operation is called "rewriting history". Because git history is atomic, you can't delete data without reverting all git history. This include even changing commit messages (for security reasons).

    What? Like Mike says, that's what `revert` is for. No rewriting history at all.
  10. 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.

  11. Got a nasty bug:

     

     

    Install Component [bG2 Fixpack - Core Fixes]?

    Installing [bG2 Fixpack - Core Fixes] [v11 Beta 4]

    ...

    Copying and patching 6 files ...
    ERROR: illegal 2-byte read from offset 3682620 of 2692-byte file nalia8.cre
    ERROR: [nalia8.cre] -> [override] Patching Failed (COPY) (Failure("nalia8.cre: read out of bounds"))
    Stopping installation because of error.
    ERROR Installing [bG2 Fixpack - Core Fixes], rolling back to previous state
    Will uninstall 3058 files for [bG2FIXPACK/SETUP-BG2FIXPACK.TP2] component 0.
    Uninstalled 3058 files for [bG2FIXPACK/SETUP-BG2FIXPACK.TP2] component 0.
    ERROR: Failure("nalia8.cre: read out of bounds")

    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.

  12. 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.

  13. 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.

  14. 3. is a newer problem and trickier to solve

    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).

  15. Still getting a huge amounts of scrolls and wands with BG:EE 2.5.17.0 and randomiser v6.8... inventory management has become a nightmare! I have like 120 charges of wand of the heavens and a stack of 15 chaos scrolls.

    Did I download an old version of this mod or something?

    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.

  16. 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.

  17. 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.

×
×
  • Create New...