suy

No. AsciiDoc is the input, HTML the output, and the tool is the generator. I don't update the HTML along the AsciiDoc, because I preview the AsciiDoc either directly in my browser via an extension, or on Github/Gitlab/etc. Same as any other generated file. I don't diff those, as different parameters to the generation create different outputs. I just ship it to users because they have no use of the source, but of the output. Same that I don't diff the generated assembly of the code that I just compiled. I feel like you are mixing stuff here. The IEMOD format has no binary embedded inside, like IMHO, it should be. It's just a ZIP file. The claim that the ZIP file doesn't have a Linux binary because "for Linux is impossible" is wrong, and I just pointed out that. You said that you meant something else, which is fine, but then I point out that then it makes even less sense any claim that you can't put a Linux binary (and I insist, Linux binary... Linux-only binary), because it can just have a different name than the other two. The MacOS version already has a wrapper to run it, so the Linux one could have it as well, and pass the arguments to WeiDU so it can be "double clicked to run", if anyone is interested in that. I'm not asking for you to do the work (I'm not asking anyone to do the work, because I don't think any Linux users are gonna care at all). Then I mention an example of an entirely different approach. Apologies for bringing that up if that was confusing, but that's an example of something entirely different that sidesteps the previous discussion because it's a single binary for many platforms. And yes, it requires working on the OCaml side of things (a lot less than what you implied, though, it's a different toolchain, which is not uncommon in compiled projects), which few are going to be motivated to even look at. So I would like to focus on the previous points. To summarize: IEMOD seems fine to me, and I don't see why the need of a ZIP package with binaries inside, but if it has to have them, better do it right. I see more Linux users on Discord than Mac ones (though might be survivor bias), and with the Steamdeck this can go even higher.

There should be no extra steps. The compressed file manager should handle both at the same time, so does the tar command in the console.

I hate that. Generated files don't belong to a repository alongside the source. This is not a good practice at all. If you make a new package, you change the source, hence you bump the version. I don't see a problem. Otherwise you end up in a communication nightmare: "which version are you using? x.y.z? But the old x.y.z or the new x.y.z?". This is again not a good practice. That's even more shocking (because it wasn't phrased like that in the original post, and it was biased clearly against one of the platforms) and even worse reason to say it so (because the technical solution is so easy that it's trivial). You don't need a file name convention on either Mac or Linux to run a progam, so you can just use different names. And you can use a script that delegates to one or the other, invoking it with the right arguments, so it can be easier. And something which is new, and did not exist (I think) when you wrote the post, is that nowadays you can use the same exact file to run on all those 3 platforms. The OCaml version is called esperanto. Those are usually named 'something.com'.

I've not seen such files with double compression (but it's possible), though note that a .tar.gz is not doubly compressed. The TAR format is just packaging the files together in a stream, but without compression. Then a separate compression program will make them smaller. That's why you find tar.gz (gzip), tar.bz or bz2 (bzip) and lately .tar.xz (xzip).

Well, I was doing a tarball. It's what makes sense for Unix-like, and it helps in distinguishing the Windows and the others apart. I now have a Mac at hand for working, and it's ancient (but with the software updates, which I think it's not the latest, but the previous MacOS version). If it's default app can open it, I'm sure every other reasonable Mac user can do it. Or... they can get the ZIP and ignore the exe. I've found a few mods only packaged like that only, and it's what I do on Linux. And yeah, I agree with you, and I don't like the WeiDU binary being shipped in the compressed package.

I've been working on a mod that now I want to publish, and I want to check out if I might add something to what I'm already doing for "packaging" it for users. Since I work on a git repository, and I work on Linux, I don't have a setup-foo.exe around next to the mod code. Obviously Windows mod users will need that. So I have done a simple Github workflow that simply copies the documentation from the root to the mod directory, adds the weidu exe with the right name, and makes a ZIP package (for Windows). It also makes a different compressed format without any WeiDU inside for Linux and Mac users, and I hope that's OK. I'm not sure if it's worth the time to do anything else. The IEMOD file seems simple enough, as it would just be a ZIP like the existing one, but before the addition of the weidu executable. I cannot test it, though, so I'm hesitant. I see other mods/modding tools creating auto-extracting ZIP files, changing the case of files, and other weird stuff. Am I missing something else? And yes, I know about oggdec, iconv, tisunpack, oggdec and others. Those are not relevant for me yet. I'm thinking of only the necessary for a simple mod, but complete enough so I don't get asked later that the mod lacks something. Thank you.

Additionally, I want to mention something that I am not sure if it's a bug or not, but just in case... I wanted to see exactly the "status quo" of packaging solutions, and what they are providing, so I downloaded the latest stable release of Forgotten Armament, and compared the IEMOD package and the "zip for linux" one. Then I extracted both and, compared them, ignoring file name case, and trying to ignore the changes in line ending (which I don't get... as I don't think any change of this is necessary?). The result was a bit puzzling, as both are almost the same, but: The Linux ZIP version has item-set-bonuses.html, which the IEMOD lacks. The IEMOD version has a g3.ico and a g3banner.bmp that the ZIP lacks. I don't understand this disparity, and I don't suppose is intended nor relevant, but just in case.

No, I meant making just the WeiDU executable an AppImage, not the whole packaging. So, same as the Windows version.

Additionally, I'd like to point out that this is not correct. Not only WeiDU has (as of 249) 3 different Windows versions available to download in its releases, with only 1 for Linux and Mac, but it is perfectly possible to have unique installers for Linux. AppImage has existed since long, and it's only necessary for applications which use shared libraries. WeiDU is statically linked.

I have been finishing the packaging of a mod myself, and I think I suffer the same. I have the documentation written in AsciiDoc in the README.adoc, so browsing it on Github/Gitlab/etc has a pretty frontpage, but I "compile" it to HTML so users can see that in the browser normally, instead of having to see the AsciiDoc markup. I will probably need other steps as well in the future. BTW, I would advice against referencing files or actions at a branch instead of a tag or commit. This breaks any chance of reproducing a build, even though might seem very convenient (to not speak of the security risks).

Partially guilty. I think I mentioned it on a conversation. People ask for publicly available lists of "this works for me", so I think I linked to your file in the Github repo, as well as the repository that contains full weidu.log files hosted by Morpheus562.

And now I see it's added. Thank you for the favor, @JohnBob!

I did not have time yet to check your scripts, nor modda, nor even try using the case insensitive native filesystem (instead of the ciopfs abomination that I'm used to). I just did not have the time. But I appreciate that you shared them! Respect EEex: it enables some nicer menu, and I certainly love the built-in timers. Running the game through wine is not as convenient as doing so natively, but to me is way better than having to reboot on Windows and basically having to do stuff where I'm not used to, and my files and settings are absent.

Thank you for the warning, jastey. I could not find any file named "s_something" inside Fields of the Dead, and I searched to see if anything starting with that prefix was generated, but I couldn't. I suppose is a different person? There is no "echon" mention on the list of registered prefixes either.

Thank you for the effort, JohnBob. I see that you've done a few requests on behalf of G3 forum members, and I appreciate the time you took. About the alternative: I would try to push the "S_" one first, even if it's duplicated. The reason is that I'm skeptical about the whole process, for many reasons. I don't want to bore anyone, and I don't want to cause controversy, so I don't want to elaborate on it too much. But let me briefly state something. Many file names need to follow a convention that the engine recognizes, and can't be with the modder prefix naming anyway. The process for registering, as we can see, it's problematic, given the state of the BWL forum. I don't see a way to check out who a modder on the list of reservation is, or where to reach them, or check out the mods published to see the details of the conflict, etc. I don't see a way to take back the prefix from the modder if actually did not use it in the end. And probably the most important, this naming convention helps somewhat at avoiding installation conflicts, but not all, and does not improve mod compatibility in other areas. In short, I see it OK enough to just state that one will go with putting their own file names with that prefix, but I don't like being forced to choose one that is unused because someone came first. Specially because the list of free two letter ones is just gonna run out soon anyway, and even without the slots being exhausted, there already plenty of duplicates...

For those of you who have been trying installations with and without Wine... have you tried to use a faster Linux installation, but "export it" (transfer it somehow) to a Windows installation to mod the game with EEex as well? Thanks to Bubb's efforts, EEex works fine under Wine, which is a huge boon. Doing the whole mod installation under Wine is annoying.

Since I'm unable to complete the registration either (tried it resending the confirmation email, waiting, checking spam folder, etc.), I'd like to ask a generous soul to post for me on the BWL forum. I want to register the "S_" prefix for suy. I am aware of someone named Echo asked for it on 2013, but I don't know of any mods from that person, and I volunteer to adjust my file names if Echo's mods happen to clash with mine (to the best of my possibilities).

Since SHS is down, seems that Sam's tool is available at: https://github.com/Sampsca/PS-BAM

Which tool is having issues with Windows?? I'm puzzled that this is the case, because the issue has always been Linux and/or case sensitivity. I cannot give perfect details right now, but I can tell one thing: in my very first experiences making my own local modifications to the game, I never had issues with case sensitivity. I was just changing 2DA, ITM and SPL files by hand with NearInfinity, so maybe other files are more problematic. I realized that the game just worked fine, even when some cases where mismatching. I was not using a case insensitive file system for that. When I started to work with WeiDU, it's when I started having to use a case insensitive file system to run WeiDU, and also to start the game (before it was not needed). It was long ago, so apologies if I get something wrong, but if I remember correctly it was WeiDU which was needlessly changing the chitin.key file or similar, and then the game was failing to start.

In what way? I assume that if you publish it, you are not expecting game breaking stuff (at a technical level), but is a lot of dialog seriously broken? Could it be fixed? I'm gonna be honest and admit that editing dialog seems very unrewarding work, so I'm not volunteering for doing it, but I think that making Imoen the protagonist is a great and original idea. I have never been able to play without her yet, so it's a nice way to explore more party compositions or seeing the role-playing in a different and interesting way.

Indeed, amazing how it looks, Lava! "AI as a tool" + talented human sounds great if it achieves stuff like this.

I did play the first of this (with just one class, and trying a bit the others), and to me it did not seem that accurate at all. Given that the combat is driven by user controls, all this things that you mentioned of course go out of the window. I noticed picking the boots of speed, and did not notice any change at all. Also getting the Gauntlets of Ogre Power, and not notice any change. The use of spells seemed based on items, and I did not notice at all memorization or spellbooks. Also, of course you respawn with coins (I mean, the real ones, which of course are just a key press on the computer), which helps at just blasting through the game in an instant unless one self imposes a limit on "lifes". All in all, the game is not bad for sure, but I don't think it felt at all like D&D rules, except for some fluff in the names of things. Maybe I'll check again.

Thank you both. I checked the intro video, and it did look to me as way different to what seemed a faithful D&D (due to the "action" nature, or the spells pausing said action, apparently), but I'll definitely check out the game to judge for real. I've always loved Streets of Rage, so I think I can like it any way it's implemented.

From @subtledoctor: What game is that?

Edit: forum glitch? It was posted twice. Anyway, an addenda: what I don't remember is what was the lore when you summon a creature via a low level spell, like the pack of Gnolls, etc.