lynx

Thief/Mage/Cleric and Mage/Druid would be classes, not kits, so it's only possible in iwd2 or with GemRB (I sometimes test with a sorcerer/monk). But yeah, not much interest in this in general. Everyone gets access to innate spells, so I guess adding fake spellcasting would be possible that way, however, like with modifying cleric books to also have arcane spells, there is a namespace limit involved. So I doubt a whole spellbook could be hacked in that way.

We try to have peer review for every change and addition, so either post in this forum or directly submit a pull request for a change.

It turns out 0x2000 was already used by PST, before EEs added it and two more to the list. They're only set in animations in two of the Fortress of Regrets areas, so they're easy to overlook if you aren't doing a systematic search. I've reconfirmed other games don't use it. A: AR1201 Anim name: A1201G1R Anim flags: 9625 Only high bits: 8192 A: AR1201 Anim name: A1201G3R Anim flags: 9625 Only high bits: 8192 A: AR1201 Anim name: A1201G1L Anim flags: 9625 Only high bits: 8192 A: AR1201 Anim name: A1201G1R Anim flags: 9625 Only high bits: 8192 A: AR1202 Anim name: A1202GB2 Anim flags: 9497 Only high bits: 8192 A: AR1202 Anim name: A1202GB3 Anim flags: 9497 Only high bits: 8192 A: AR1202 Anim name: A1202GB4 Anim flags: 9497 Only high bits: 8192 What it actually does is still an open question, but it may complicate the meaning of the existing bits. For a picture and investigation details: https://github.com/gemrb/gemrb/issues/163 Does anyone perchance know something about it?

It's in active development, but if you want more speed, there's no other way than to help out somehow. For non-programmers that could be researching/testing the originals, recruiting contributors, artsy stuff ...

Bodhi tree.

There are so many engine differences it would make you cry.

Sorry, I somehow overlooked this thread. The tooling for creating assets can be quite a PITA for these games. Anyway, you want to do something similar to iwd2, so just focus on the content, it'd be a large mod or total conversion like any other. So I suggest you read up on modding on the infinity engine before complicating matters with engine changes.

Nice writeup! Are you sure it requires a new partition though? tune2fs can be used to set extended options on an existing partition.

I'm not sure what the "bad thing" refers to. Either way, running weidu doesn't need a console, you just have to manually tell it when clicking (usually only once btw, double clicking is not the default to trigger actions) ... unless the mime type has been registered like Wisp already mentioned. In which case it works automatically and there's no need for per-mod hacks whatsoever. But yes, something has to do it initially and it's not clear what should bear that responsibility.

By invoking weidu? Nothing changes there, this is the way we have used it since the start.

Nah, it'd still be the user's responsibility, the same it is now. The only benefit is that it's easier to uninstall this way, at the cost of lower portability, since the static binaries mostly just work and there's no need to figure out what tools are needed. btw, arch has weidu in abs.

Yes, otherwise some of the table entries would be inaccessible, also interfering with the fixed 5% chance.

linux users don't care about desktop files or their misuse. So you don't need to lose sleep over that.

The first linux command line has an errant "fi". There's no need for the exports. The test for weidu is incorrect — would only work from the same dir. If you force the dependency on bash, then it could be looked up via hash (shell builtin), otherwise "which" is the standard approach and just running it and inspecting the return value the one that will definitely work everywhere (rc is 127 in case of failure).

Jarno, it needs to be consistent in reference, not necessarily naming.

Linux doesn't need it either, unless the mod author is inconsistent in their casing of the same filenames. Or unless weidu requires it, which I doubt (it comes with tolower to fix the original chitin/files).

Or code, but it's essentially the same thing and I don't see how you could solve it any other way. IMO this should be done on the weidu level, but that of course requires changing mods.

The first part is usually handled in the package itself, for which they include script snippets (I don't think it can be solved in a declarative way, at least in the general case). Whatever BWS had may be sufficient, but you'll know better. Since mods are not to be touched, but the package files have yet to be written, all the info and/or logic needs to be in there. The external stuff is the usual bread and butter of package managers (conflicts, providers, subdependencies).

The whole point is that it doesn't need to be implemented, since it has already been done and done well. It's just about reuse, however it can affect the packaging format, since every solution comes with its own and it may be a waste of time to change it.

"conflicts + dependencies" is no minor feat, that's why I keep bringing up existing package managers that have had this solved for ages. In that sense python would be a better choice than powershell, but maybe there are some written in csharp too (eg. the windows contenders like chocolatey, nuget?).

Those mac/linux instructions only need to be done once; the same way you may need to install a non-free zip handler. 5. People who don't want to use your tool will use whatever they're using now. Only windows releases are currently bloated with weidu, so there'd be no change for the rest. If the modders want to support installs without the tool, they'll either have to complicate their instructions or still provide classical formats anyway. And since it's not at all obvious, I'm not complaining because of slow internet, but because of environmental impacts.

This is not true. Even if the user's distro does not provide a package for weidu, you still just have to download and extract it. The manager is a 3rd party tool. Not much of an upgrade there, unless the mod was packed with something really exotic. 1. Not true, but not far from it. Can be ignored. 2. File extension is irrelevant, but why have it different, if it will just be a zip archive? 3. Why does the file name matter at all? 5. This sounds ridiculous — every mod would currently pack ~10M of extra crap. If people are supposed to use a mod manager, have that ensure it has all the necessary tooling. The packages can never be self-contained, since the payload is programmatic, so there's no point in exploding the sizes with redundant files. @subtledoctorIt's up to the browser to implement, so at least for firefox the extension with a new protocol handler is possible — by the user.

Eh, it's just a name. I don't know if they changed anything with D:OS2, but in general Larian made more hack'n'slashy titles, so eh.

They're not externalised spells, just constructed and applied internally. Well, unless you're running gemrb, of course.

You're missing the point of git — all history is preserved, so even force pushes can be undone. Of course, if you rely on just the browser to interact with your repos, then you're already using a very limited subset of the power and safety git offers.