Wisp
-
Posts
1,185 -
Joined
-
Last visited
Content Type
Forums
Events
Downloads
Gallery
Mods
News
Store
Posts posted by Wisp
-
-
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.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.)
-
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.(or indeed Wisp) release a non-interactive GUI install tool
-
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.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.
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.
-
Out of curiosity, what language are you using?While the ALPHA version works only on windows, I'm not using "windows only" language like AutoIT. So the cross-platform is definitely possible.
-
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.
-
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.
-
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.
-
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.)edit: Or, duh, the even easier option from the command line: weidu foo.dlg will output foo.d in your game folder.
-
What? Like Mike says, that's what `revert` is for. No rewriting history at all.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).
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.
-
What? Like Mike says, that's what `revert` is for. No rewriting history at all.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).
-
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.
-
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.creERROR: [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 stateWill 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.
-
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.
-
Item Randomiser is compatible with all mods that move or remove items provided it is installed after those mods.
-
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.
-
@Wisp: cool - is that in the current WEIDU or queued for the next one?
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).
-
I've added an option for controlling where the output ends up:3. is a newer problem and trickier to solve
- 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)
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).
-
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.
-
So it was an old, already fixed bug, at that. I would expect the macro to sort just as well.
-
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.
-
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. -
Will do.
-
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.
-
Issues with ADD_ITEM_EFFECT
in Modding Q&A
Posted